Software 2.13.0.2

Released 2021-09-30

New features

The 2.13.0.2 software supports the following new features:

• Support for MiR600 and MiR1350
  This software supports two new products from Mobile Industrial Robots: MiR600 and MiR1350.

   

  MiR600 and MiR1350 can carry payloads of up to 600 kg and 1350 kg respectively. They are equipped with the same lithium ion battery that MiR250 robots use and have the same 3D camera configuration. This gives them a larger field of view than MiR500 and MiR1000 and a different internal structure that uses industrial quality connectors and cables.

  The top modules known from MiR500 and MiR1000 are also available for MiR600 and MiR1350: MiR shelf lift, MiR EU pallet lift, and MiR pallet lift. The top modules are used the same way as before, but have been modified to make mounting easier and to increase the maximum payload.

• Support for MiR250 Hook
  This software supports a new product from Mobile Industrial Robots: MiR250 Hook.
  
  MiR Hook 250 is a top module for the MiR250 robot. The combined application is called MiR250 Hook and can be used to tow carts autonomously.

  In Setup > Footprints, there is a new option for choosing if the robot has a hook top module and the robot type.
  

• Introducing new endpoint to retrieve metric data for robots and MiR Fleet
  If you want to gather more information about the performance of your fleet, it is now possible to retrieve metrics data about all of the robots and MiR Fleet from a new metric endpoint.

  The endpoint is compatible with Prometheus and OpenMetrics. For more information, see the guide How to use the MiR Fleet metrics API.
  

  For MiR Fleet Server Solution, this feature is only available when you update with the installation file. It cannot be applied with a .mir software file alone.

• It is now possible to abort ongoing robot missions through MiR Fleet REST API
  It is now possible to abort ongoing robot missions through MiR Fleet REST API. When a mission is canceled on MiR Fleet, the mission goes into an Abort state, and MiR Fleet sends a request to the robot to abort the mission. When the robot receives the abort request, it replies with a message indicating whether the mission has been aborted or if the robot finished the mission before the robot received the abort request.

• The AI camera configuration page is now password protected
  When you connect to an AI camera and open the camera's configuration page, you now need to enter a password to access the page. This is the same password used to connect to the camera's access point. In the MiR AI Camera web-based configuration page, you can change or reset the password used to access the camera's access point and the configuration page itself.

• You can define the area of interest in the AI camera's field of view
  If you want your AI camera to only detect objects within a certain area, it is now possible to select an area of interest in the MiR AI Camera configuration page. The camera will only trigger actions when it detects an object of interest within the selected area.

Quality improvements

This update introduces the following quality improvements:

• Improved WiFi settings and WiFi API
  We have introduced an improved system for controlling WiFi connections on MiR robots. The new system provides more options that can help you better control the WiFi connection between your network and MiR robots. There are two main features that are introduced in the new WiFi control system:

  • Background scan: You can set how often a MiR robot should scan for the purpose of roaming within a single network, i.e., across all the access points using the same SSID. MiR provides presets of the parameters that you can select between: the default scan frequency and the fast scan frequency. The fast scan option makes the robot scan more often for a better WiFi signal.
    You can also configure this with your own parameters upon API request, however we recommend only doing so if you have a WiFi expert that recommends the adjustment.

  • Channel selection: By default, the robot scans on all 2.4 GHz and 5 GHz channels. You can now limit which channels the robot should scan on, reducing the WiFi scan time. You can use this if you know which channels the robot needs to listen to on the WiFi network. There are some predefined combinations you can select, or you can enter a custom list of channels across 2.4 GHz and 5 GHz bands.

  For IT security reasons, you can only connect the robot to networks that are password protected

  This software version contains both the new WiFi system and the legacy system. You can always toggle between them in case there are any compatibility or performance issues. The legacy system will still be the default after you update the robot.

  When you toggle between systems, the robot will disconnect from the network briefly.

  The new WiFi system comes with its own APIs. But once you have the new system activated, all the legacy API requests will be translated into the new API internally. So you're able to interact with the new WiFi system with the legacy API.

  When you update your robot to this software version for the first time, the WiFi connections you have defined previously will automatically be migrated into the new system, meaning you do not need to recreate your WiFi connections.

  The system can only be recreated once. After updating, if you roll back to a previous software version and create any changes in the WiFi settings, then update to this software version again, the changes will not be migrated.

  It is required to restart your robot once you have updated the system related to this software version.

  Under the advanced WiFi settings, the WiFi watchdog settings are still available, but they should no longer be necessary if you use the new system. By default, we do not recommend using these advanced settings along with the new WiFi system.

• Improved position tracking of robots with missing encoder data
  Sometimes, robots can lose some of the data from the encoders which can make the calculated robot position on its map less accurate. To reduce the effect of missing encoder data, the robot now relies more on the IMU data when the encoder data is missing.

• More consistent fleet behavior
  This software version introduces a new set of operating modes that MiR Fleet uses to reliably handle connected robots. The modes ensure that there is a clear definition of to what extent MiR Fleet can control the robots in different scenarios and how the robot changes from one operating mode to another. This results in more consistent behavior in your fleet. For more information about the new operating modes and structure, see the latest versions of the MiR Fleet getting started guides.

  The operating modes are not displayed in the robot or fleet interfaces. They are only used for defining the internal states the robot can be in relative to MiR Fleet.

• Synchronization improvements
  The initial synchronization of robots added to MiR Fleet has been improved making it more robust and faster.

• Better error handling when a robot to fleet connection error occurs
  Error descriptions when an error occurs in the connection between a MiR robot and MiR Fleet have been improved. When the error occurs, the related robot is immediately deactivated from MiR Fleet, and in the MiR Fleet system log, it is identified which fleet features failed and what the reason may be. Once the issue is resolved, you can activate the robot on MiR Fleet without having to remove the robot first.

• The file name of MiR Fleet error logs starts with the MiR Fleet’s name
  When you download an error log from the MiR Fleet interface, if you have given a name to your MiR Fleet, this name is now used in the file name of the error log just like the error logs from MiR robots.

• MiR Fleet elevators supporting special characters in the elevator name
  You can now add special characters in the names of elevators on MiR Fleet.

• New fields added to the mission_scheduler endpoint
  When you use a GET request on the mission_scheduler endpoint in MiR Fleet, there are now two additional fields:

  • mission_name: The name of the mission

  • label: The names of the parameters you can set for the mission

Issues solved

This update solves the following issues:

• Making an invalid REST API call to a Boolean (True/False) setting causing the setting to reset to the default value
  Since software version 2.10.0, if you tried to set a Boolean parameter to an invalid value, for example, a number, you would receive a positive response (response 200), and the Boolean value would reset to the default value. Now, the system checks that you have entered either true or false, otherwise you receive an error response, informing you that you have not entered a valid Boolean. The parameter is case-insensitive, so any combination of upper and lower case letters is accepted.

MiR Fleet

• MiR Fleet is more robust at handling large numbers of missions
  If there were many missions that MiR Fleet had to manage (except missions under Done), and MiR Fleet was restarted, sometimes MiR Fleet was not able to schedule missions again afterward. This has now been solved, making MiR Fleet more robust at handling over 300 missions at once.

• Robots blocking charging stations causing Auto charging to fail
  If a robot that occupied a charging station entered a state where the robot cannot be operated (for example, Pause, Protective stop or an Error state), it could cause the Auto charging function to fail. This would happen if a robot tried to swap positions with the robot in an inoperable state, and MiR Fleet would try to send the inoperable robot to an available Staging position. Since the robot cannot drive to the Staging position until it is in an operable state, MiR Fleet would continue to try sending the robot to all available Staging positions until no positions were left. When this happened, MiR Fleet could not send any charging robots to staging positions, meaning all charging robot would stay in charging stations while other robots would run out of power. This has now been solved, by making sure MiR Fleet only sends robots that are in a Charging state to Staging positions.

• Updating MiR Fleet without removing all robots first causing issues
  
  MiR recommended to always remove all MiR robots from MiR Fleet before you updated the fleet to avoid any potential issues or errors that may occur during the update process. With the new MiR Fleet software structure, this is no longer necessary. You can now safely update MiR Fleet and all connected robots without removing the robots from the fleet.

  Deactivated robots missing a clear state definition
  
  When you deactivated a robot in MiR Fleet, it was not properly defined what this entailed. Now, when the robot is deactivated, it releases all its resources and positions in the resource queues, and it suspends all key features (Collision avoidance, Auto charging and staging etc.) from MiR Fleet. The robot will essentially operate as a robot that is no longer connected to MiR Fleet. MiR Fleet will keep the ID number of the robot and can still use the information from the robot for Collision avoidance for other robots and to read the status of the robot.

• Deactivated robots disrupting communication between MiR Fleet and other robots
  
  If you deactivated a single robot that was connected to MiR Fleet, this could partially or completely prevent MiR Fleet from communicating properly with other robots in the fleet. Now, the state of robots has no affect on how MiR Fleet handles communication with other robots, so MiR Fleet can synchronize and share data with all robots, even if there is a deactivated robot.

• Unavailable robots causing MiR Fleet to fail to release all resources after a fleet restart
  If you restarted MiR Fleet while a connected robot was in Unavailable state, MiR Fleet would fail to release all resources when starting up. Robots would still occupy the same resources as before MiR Fleet was shut down. This has now been solved, so all robots go through a sequence of operating modes when starting up, ensuring that they do not occupy any resources that they shouldn’t.

• MiR Fleet not releasing resources occupied by a robot removed from the fleet
  If you removed a robot from MiR Fleet, all resources that the robot occupied were not released when the robot was removed. This resulted in robots waiting for resources that would never become available. The new Deleted operating mode ensures that robots being removed from MiR Fleet do not occupy any resources.

• Unavailable or deleted robots blocking other robots from charging or staging
  If a robot connected to MiR Fleet became unavailable or was deleted from the fleet, MiR Fleet would still assign it to a charging station or staging position once the idle time had passed. The robot could occupy the resource indefinitely until it was reconnected to MiR Fleet. Now, when robots are deleted, they release all resource, and when they are unavailable, they cannot occupy new resources and can only keep the ones they occupied before becoming unavailable.

• Robots failing initial synchronization could not be removed from MiR Fleet
  In the unlikely event that a newly added robot failed to synchronize with MiR Fleet, it was not possible to remove it completely from MiR Fleet without help from MiR Technical Support. Now, if the initial synchronization ever fails, the robot enters Deactivated operating mode where you can remove it correctly from MiR Fleet and try to add it again.

• MiR Fleet not assigning closest robot to execute missions that use template missions to pick up shelves
  When MiR Fleet assigned a mission that used template missions for picking up shelves, it would not assign the mission to the robot that was closest to the shelf. This has now been solved.

• Changing the driver type of a newly created elevator not possible
  After you created an elevator in MiR Fleet, it was not possible to change the driver type of the elevator. You had to create a new elevator and fill out all of the elevator information again. Now, you can change the elevator driver after creating the elevator.

• Activating an evacuation in MiR Fleet failing and resulting in a mission scheduler error in the system log
  
  For some MiR Fleet PCs that were updated from a software version older than 2.10.3.1, when you activated an evacuation in MiR Fleet, the robots would fail to receive the missions that bring them out of the Evacuation zones and to an Emergency position. Instead the Mission scheduler manager would report an error in the system log. The only way to resolve the issue was to factory reset your MiR Fleet. This has now been solved so robots evacuate correctly without factory resetting the fleet.

• Adding and removing the same robot to MiR Fleet many times crashing the API system
  Over approximately 12 hours, if you added and removed the same robot multiple times (100+) from MiR Fleet, you could eventually cause the API to crash, so you could no longer communicate with the fleet endpoints. This has now been solved.

• Generating error logs on MiR Fleet fails
  If you tried to generate an error log under Monitoring > Error logs, sometimes, you would receive an error message and no log was created. This has now been fixed, so you can always create error logs on MiR Fleet.

• Mission scheduler time showing UTC time on MiR Fleet Server SolutionOn MiR Fleet Server Solution, the mission scheduler would sometimes set the time to UTC time and thereby disregard the timezones of the host system. This has now been solved so the time is shown correctly for your host region and system.

• Missing POST and GET methods for mission_scheduler endpont in the REST API documentation
  The REST API documentation was missing POST and GET methods for the mission_scheduler endpoint. These are now included again. This was only an issue in the documentation, it was still possible to use these methods in your own system.

• User group permissions not synchronizing and missing in exported site files
  
  If you applied any changes in the user group permissions, they were not synchronized between MiR Fleet and the connected robots. Also, if you exported a site file, the user group permissions would be missing. This has now been solved, so the user group permissions are now included in the site files and are correctly synchronized.

• Not possible to set a static IP address on MiR Fleet PC with HW version 1.2
  In software 2.10.4.1 there was an update that enabled you to set a static IP on MiR Fleet using mir_fleet_tool. The update did not resolve the issue on MiR Fleet PCs with hardware version 1.2. This has now been solved, so the static IP can also be set on all hardware versions of MiR Fleet PC.

• Factory resetting robots preventing robots from executing missions
  If you factory reset a robot, there was a small risk that the robot mission queue would break, and the robot couldn’t execute missions until you restarted the robot. This has now been solved.

• Setting a trigger_time value on the fire_alarms endpoint resulting in an error
  In 2.10.3.1, a new evacuation system was introduced to MiR Fleet. The new system uses the evacuations endpoint, but to ensure compatibility with setups that used the legacy system, the fire_alarms endpoint could still be used with the new system. In the legacy system, there was a trigger_time parameter in the fire_alarms endpoint. This parameter is automatically recorded in the new system, so if you PUT a trigger_time value you would receive a response indicating that the request failed. This has now been solved, so setting a trigger_time does not cause an error. The automatic value is still used and any value you manually set trigger_time to is discarded.

• Idle robots not reacting to charging group changes immediately
  If you changed which charging group an idle robot belonged to, it would not always be evaluated as part of that group immediately. Sometimes, it would take a few minutes before it was sent to an appropriate charging station, or it would only be evaluated once the robot was paused and then unpaused. Now, the robot is reevaluated in its new charging group as soon as possible.

• Deleting a robot while it is requesting a resource crashing MiR Fleet
  If a robot requested a fleet resource and was deleted before being allocated the resource, the synchronization in MiR Fleet could fail, preventing all robots from being allocated new resources even if they were unoccupied. MiR Fleet had to be restarted before the fleet could operate correctly again. This has now been solved.

• Short missions receiving a start time of 1970-01-01 00:00:00
  Short missions that took less than a second to execute would sometimes be displayed with a start time of 1970-01-01 00:00:00. This has now been solved so the correct start time is shown.

• Deleted robots not removed completely from charging groups in MiR Fleet
  When you delete a robot from MiR Fleet, all MiR Fleet related settings regarding that robot should be deleted. Before, if you deleted a robot from MiR Fleet and then added the robot again, it would sometimes still apply previous charging group restrictions. This has now been solved, so when you delete a robot from MiR Fleet, all fleet-related settings are discarded, and if you add the robot to MiR Fleet again, only the default settings are applied.

• Missions being executed during a MiR Fleet restart losing their mission names
  Sometimes, if you restarted MiR Fleet while a robot was running a mission that MiR Fleet had assigned to it, the mission’s name would disappear and the name field would be blank. This has now been solved.

• Unable to run several OPC UA elevators on the same IP with different ports
  If you tried to add two elevators with the same IP address, the MiR Fleet interface would report an error that the IP address was already in use. This has now been solved, so you can connect multiple elevators with the same IP address and control them separately using different ports.

• Misleading description of the Auto charging and staging settings texts
  The descriptions of the Auto charging and staging settings have been improved to correctly describe how the settings parameters affect robot behaviour.

• MiR Fleet Server Solution failing after restarting
  In rare cases, after you restarted MiR Fleet Server Solution, parts of the internal system might not reset correctly, and MiR Fleet did not operate correctly after start-up. This has now been solved, so the internal system is correctly reset.

MiR robots

• Robots detecting other objects as VL-markers
  In rare cases, robots would detect objects as VL-markers and try to dock to these objects. The robots' overall validation of VL-markers has now been improved for more reliable detection, solving this issue. However, there is still a risk that robots will see false negatives if VL-markers are made in a very shiny material or if they are not within specifications.

• Robots reporting the error Attempting to reconnect
  Robots with a power board would in rare cases report the error Attempting to reconnect when the light controller lost connection to the power board for even a very short amount of time. The error would in most cases only appear for a few seconds and not require any intervention. This issue has now been solved.
  

• Dragging in the web interface not working on Microsoft Surface tablets
  If you opened the MiR Fleet or robot interfaces on a Microsoft Surface tablet, the interface would not respond when you used the touch screen for drag events, such as the joystick or mission editor. This was only a problem for the Surface tablets. IOS and Android devices did not experience these issues. This has now been solved so that MiR interface correctly responds to touch inputs from surface devices.

• Robots exiting Planner zones not reverting to default Path timeout planner setting values
  When a robot exited a Planner zone, it would sometimes keep the Path timeout planner settings that were set in the zone instead of reverting to the default values. This has been solved so the robot only applies the zone’s planner setting while the robot is in the zone.

• Robots reaching a position with the incorrect orientation not reporting an error
  If a robot was unable to orient itself correctly at a position, this was not reported as an error to the user. The robot only checked that its was at the correct coordinates. Now, the robot reports an error if its final orientation is incorrect by more than 10°.

• 24V_TOP diagnostic displaying incorrect value on MiR500 and MiR1000
  On MiR500 and MiR1000 robots, under Monitoring > Hardware health > Power board > Power supply monitor > 24V_TOP, an incorrect value was displayed. Now it displays the correct value read from the 24 V pin from the Power interface on top of the robot.

MiR AI Camera

• MiR AI Cameras running out of storage
  In rare cases, the system log rotation in MiR AI Cameras would fail and an irrelevant system warning would be sent repeatedly. These two events could cause MiR AI Camera to run out of storage space. This has now been solved by ensuring correct logging rotation based on the size of the files.

• MiR AI Cameraconfiguration page refreshing when losing connection
  If you lost connection to the MiR AI Camera's WiFi while configuring the camera, the configuration web-page would refresh, and you had toto enter all unsaved information again. This has now been solved, ensuring that your changes are no longer lost due to a disconnection.

• Static IP not saving on AI cameras connected with Ethernet
  
  If you set a static IP on an AI camera connected via Ethernet using the MiR AI Camera configuration interface, the IP address was not saved after the page was refreshed. This has been resolved so the static IP is set properly.

• Custom WiFi network and security parameters not saving on AI cameras
  If you set up a custom network connection and security parameters when using the MiR AI Camera configuration interface, the network configuration was not saved after the page page was refreshed. This has been resolved, so your network configuration is now saved and shown correctly.

• No confirmation message displayed after connecting an AI camera via Ethernet
  When you connected an AI camera to MiR Fleet via Ethernet, no confirmation message was displayed to indicate the connection was successful. Now, if a connection is established after selecting Connect a confirmation message is displayed.

• Missing indication that an AI camera is no longer connected to MiR Fleet after being removed while unavailable
  If you remove a camera from MiR Fleet while the camera is disconnected or turned off, the camera needs to be factory reset before you can add it to a fleet again. There used to be no indication that the camera could no longer reconnect. Now, the status light on the camera turns red, and an error is reported in the AI Camera’s configuration page.

• MiR AI Camera not triggering actions when it detects a target object
  If MiR AI Camera detected the same object for several hours, it would sometimes report the object as multiple instances of the same object. This prevented the object from triggering new actions in the fleet even after the object had left the camera’s field of view. This has now been fixed.

• MiR AI camera becoming unresponsive after a few days of activity
  In some cases, after MiR AI Camera was active for two to three days, it would become unresponsive. This has now been fixed.

• Scanning for cameras multiple times on MiR Fleet crashes the AI camera page
  If you selected Scan for camera several time within a short time span, the AI camera page could crash so none of the buttons on the page responded and no AI cameras would be displayed. This has now been fixed.

Quality improvements

This update introduces the following quality improvements:

• Improved WiFi settings and WiFi API
  We have introduced an improved system for controlling WiFi connections on MiR robots. The new system provides more options that can help you get a better WiFi connection on MiR robots. There are two main features that are introduced in the new WiFi control system:

  • Background scan: You can set how often a MiR robot should scan for the purpose of roaming within a single network, i.e., across all the access points using the same SSID. MiR provides presets of the parameters that you can select between: the default scan frequency and the fast scan frequency. The fast scan option makes the robot scan more often for a better WiFi signal.
    You can also configure this with your own parameters upon API request, however we recommend only doing so if you have a WiFi expert that recommends the adjustment.

  • Channel selection: By default, the robot scans on all 2.4 GHz and 5 GHz channels. You can now limit which channels the robot should scan on, reducing the WiFi scan time. You can use this if you know which channels the robot needs to listen to on the WiFi network. There are some predefined combinations you can select, or you can enter a custom list of channels across 2.4 GHz and 5 GHz bands.

  For IT security reasons, you can only connect the robot to networks that are password protected

  This software version contains both the new WiFi system and the legacy system. You can always toggle between them in case there are any compatibility or performance issues. The legacy system will still be the default after you update the robot.

  When you toggle between systems, the robot will disconnect from the network briefly.

  The new WiFi system comes with its own APIs. But once you have the new system activated, all the legacy API requests will be translated into the new API internally. So you're able to interact with the new WiFi system with the legacy API.

  When you update your robot to this software version for the first time, the WiFi connections you have defined previously will be automatically migrated into the new system, meaning you do not need to recreate your WiFi connections again.

  The system can only be recreated once. After updating, if you rollback to a previous software version and create any changes in the WiFi settings, then update to this software version again, the changes will not be migrated.

  It is required to restart your robot once you have updated the system related to this software version.

  Under the advanced WiFi settings, the WiFi watchdog settings are still available, but they should no longer be necessary if you use the new system. By default, we do not recommend using these advanced settings along with the new WiFi system.

• Improved position tracking of robots with missing encoder data
  Sometimes, robots can lose some of the data from the encoders which can make the calculated robot position on its map less accurate. To reduced the effect of missing encoder data, the robot now relies more on the IMU data when the encoder data is missing.

• More consistent fleet behavior
  This software version introduces a new set of operating modes that MiR Fleet uses to reliably handle connected robots. The modes ensure that there is a clear definition of to what extent MiR Fleet can control the robots in different scenarios and how the robot changes from one operating mode to another. This results in more consistent behavior in your fleet.

  The operating modes are not displayed in the robot or fleet interfaces. They are only used for defining the internal states the robot can be in relative to MiR Fleet.

• Synchronization improvements
  The initial synchronization of robots added to MiR Fleet had been improved so it is more robust and faster.

• MiR Fleet is more robust at handling large numbers of missions
  If there were many missions that MiR Fleet had to manage (except missions under Done), and MiR Fleet was restarted, sometimes MiR Fleet was not able to schedule missions again afterward. This has now been solved, making MiR Fleet more robust at handling over 300 missions at once.

• Better error handling when a robot to fleet connection error occurs
  Better error descriptions are now shown when an error occurs in the connection between a MiR robot and MiR Fleet. When the error occurs, the related robot is immediately deactivated from MiR Fleet, and in the MiR Fleet system log, it is identified which fleet features failed and what the reason may be. Once the issue is resolved, you can activate the robot on MiR Fleet without having to remove the robot first.

• The file name of MiR Fleet error logs start with the MiR Fleet’s name
  When you download an error log from the MiR Fleet interface, if you have given a name to your MiR Fleet, this name is now used in the file name of the error log just like the error logs from MiR robots.

• MiR Fleet elevators supporting special characters in the elevator name
  You can now add special characters in the names of elevators on MiR Fleet.

• New fields added to the mission_scheduler endpoint
  When you use a GET request on the mission_scheduler endpoint in MiR Fleet, there are now two additional fields:

  • mission_name: The name of the mission

  • label: The names of parameter values you have chosen for the mission.

Known issues

You can find the list of known issues on the Support Portal. Go to https://supportportal.mobile-industrial-robots.com/ and select Software. Select the Known issues document for the latest minor release.

Notes on updating

IMPORTANT WHEN UPDATING ROBOTS!

Do not turn off the robot until the update is complete.

Not waiting for the update to complete before restarting the robot may result in a malfunction of the robot system!

• If you have issues during the update process, see the guide How to update a MiR robot's software.

• Site files can only be imported to a robot or MiR Fleet with the same software version as the site file. This means that if you have any saved site files that you want to be able to apply to your updated robots, you must import them before updating the software, and then export them again after the update.

• If you are running a software version below 2.13.0.2, remove robots from MiR Fleet before updating the robots.
  

• Always update the hook software before the robot software. Robots are updated under System > Software versions, and hooks under Hook > Software versions. 

Battery and power board firmware updates

We have released four software packages with battery and power board firmware updates prior to this release. The newer releases include all firmware updates included in the previous ones. Make sure to read the descriptions of any firmware updates that have not yet been applied to your robot, as they each require different sets of precautions that you must employ when the firmware is applied.

First update

The first update is a battery firmware update for the deprecated battery. It was released December 17, 2020 and is exclusively included in the following software versions: 

2.7.9.2	2.8.3.1	2.10.2.4
2.10.3.1	2.10.4.1	2.10.4.2
2.10.5.1

This update includes a self-diagnosis function in the battery firmware that continuously monitors differences between battery cell voltage potentials and takes protective measures if the imbalance is too high—for more information, see the release notes from December 17, 2020 of the software versions where the first update was applied.

Before updating to a software including this firmware, see the guide How to test the battery on MiR100, MiR200, MiR500, and MiR1000.

Second update

The second update modifies some of the parameters in the battery firmware on the deprecated batteries. It was released July 26, 2021 and is included in the following software versions:

2.7.9.3	2.8.3.2	2.10.5.4
2.12.0.1	2.12.0.2	2.12.0.3 and higher

This update includes the features from the first update and a state of charge limit that reduces the risk of the battery overheating and support for the replacement batteries—for more information, see the release notes from July 26, 2021 of the software versions where the second update was applied.

Before updating to a software including this firmware, see the guide How to implement the battery safety measures from Safety notice July 26, 2021.

Third update

The third update is a firmware update for the power board. It was released September 30, 2021 and is exclusively included in the following software versions:

2.7.9.6	2.8.3.5	2.10.5.7
2.12.0.4	2.13.0.2	2.13.0.4
2.13.0.5	2.13.0.6 and higher

This update includes all of the functions from the first and second updates and safety measures that protect the power board on MiR500 and MiR1000 robots from damage due to current spikes. The damage these spikes can do to the power board has no consequences for robots driving with the deprecated batteries, but it can damage the power board on robots using the replacement batteries.

The power board firmware update can cause this software update to take up to 40 minutes extra to finish. Do not restart the robot until all of the statuses for the power board components under  Monitoring > Hardware health > Power board have the status OK.

Fourth update

The fourth update is a firmware update for the 48V replacement battery in MiR250, MiR600, and MiR1350, as well as MiR500 and MiR1000 hardware version 2.0. It was released April 4, 2022 and is exclusively included in the following software versions:

2.13.1.1 and higher

This update includes all of the functions from the first, second, and third updates and a firmware update for the 48V batteries that improves the storage time of the batteries, implements improved quality and reliability features, and improves compatibility with the cable chargers, reducing the likelihood of accidentally damaging the battery or charger due to incorrect use of the cable charger.

Robots will begin updating the firmware the first time they connect to a charging station. For more information about how to correctly update the firmware, see the release note for software 2.13.1.1.

For more information about firmware versions for the 48V batteries, see MiR 48V Battery Technical Guide.

Updating MiR Fleet and MiR robots

It is important to update MiR products with the correct procedure to ensure that the update is successful, that no data is lost, and that the update does not take longer than necessary.

When updating, be aware that:

• Your MiR product will stop running during the update procedure.

• No data will be removed if the update is successful.

• For MiR Fleet, a new license validation is not required.

To correctly update your product, see the guides: 

• How to update a MiR robot's software

• How to update MiR Fleet