Software 2.13.5.3
Released 2022-11-25
MiR600 and MiR1350 robots failing to start up
Sometimes, when you turned on a MiR600 or MiR1350 robot, it would fail to start up completely, and the status light would continue to waver yellow. This has now been solved so the robots always finish the startup process.
Restarting MiR100 or MiR200 robots triggers an error regarding missing hardware configuration
If you restarted MiR100 or MiR200, they would sometimes start up with the following error: Unable to detect hardware configuration. To clear the issue, you had to disable then enable the battery under System > Processes. This has now been solved so the false error does not occur.
I/O module feedback from MiR lifts not updating when the lift is raised
On MiR600 and MiR1350 robots with MiR lifts, input 3 from the I/O module connection to the lift would not update when the lift was raised. This meant that any missions that waited for input 3 to indicate that the lift was raised would timeout eventually and the mission would fail. This has now been solved.
MiR600 and MiR1350 stopping randomly and reporting brake feedback errors
Sometimes, MiR600 and MiR1350 robots could enter Protective stop randomly and would report ‘13099’ Message: ‘Safety system error: The brake is supposed to be released, but the feedback indicate it isn’t’. You had to press the Resume button to make the robot clear the false error and continue operation. This has now been solved.
Improved power board communication at start-up
An issue related to how the power board sets up its communication with the robot computer at start-up has been resolved. This solves some power board-related issues that could occur at start-up.
Proximity sensor data shown incorrectly under Hardware health
Under Monitoring > Hardware health > Sensors > Proximity sensors, the data that was specified as raw data was actually the calibrated proximity sensor data. The correct data is now displayed.
Cameras on MiR600 and MiR1350 not detecting small objects
MiR600 and MiR1350 robots would sometimes fail to detect small obstacles with the cameras. The camera transformations have now been improved to resolve this issue.
Errors reported after you replaced the router or switch
If you replaced the router or switch on a MiR robot, sometimes the robot would report an error due to an incorrect setup in router or switch. This has now been solved.
Serial numbers for MiR250 ESD Dynamic not accepted after USB restoring
If you had a robot with a serial number starting with 2052 (MiR250 ESD Dynamic), and you had to re-enter the serial number (for example, after a USB restore), the robot would not accept the serial number as valid. This has now been solved so the serial number is accepted.
Software 2.13.4.1
Released 2022-09-15
MiR robots
Robot sounds being played with jumping pitch frequencies
MiR250, MiR500, MiR600, MiR1000, and MiR1350 robots running on software 2.13.3.2 or newer would sometimes play sounds with a pitch frequency that jumped up and down. The sounds played when they were supposed to in a mission, but the sound itself was somewhat distorted. This has now been solved.
Drift corrections causing MiR100 and MiR200 robots to lose localization
MiR100 and MiR200 robots would sometimes make drift corrections while moving and not only when standing still, causing the robots to lose localization. This has now been solved.
Indicator lights displaying wrong on robots with 24V Extended Capacity battery
On MiR100 and MiR200 robots that have a 24V Extended Capacity battery, status lights were not mapped correctly on the rear panel status light. This meant the status lights would not appear correctly when the robot was charging or when the robot was using signal lights to indicate its driving direction (the Indicator lights setting enables the signal lights). This has now been solved so the status lights are mapped correctly.
Entered WiFi password being visible in error message
When you added a WiFi connection to the robot, the robot reported an error if the password length for the WiFi were below eight characters or above 128 characters. The password you entered for the WiFi connection was displayed in the error when this occurred. Now, the password is no longer included in the error message.
Unable to create WiFi connection with PEAP authentication when using Improved WiFi settings
If you had Improved WiFi settings enabled and you tried to create a WiFi connection using a PEAP security type, the connection profile would be invalid, and the robot could not connect to the network. This has now been solved so PEAP authentication is supported correctly.
Robot connecting to unspecified channels during first connection
The first time the robot tried to connect to a network, it would first scan on all frequencies and sometimes connect to an access point with a frequency outside of the specified channels, even if you had specified a limited number of channels the robot should scan on. If this happened, the robot would drop the connection to the access point the next time the robot scanned for connections since it would then apply the specified channel limits. This has now been solved.
This also meant that if you had specified the wrong channels, it might appear that the robot connected correctly at first, but would then drop the connection during the next scan.
Gateway persisting after disconnecting from WiFi
If the robot disconnected from a WiFi connection, the default gateway for the connection was still shown under Monitoring > Hardware health > Computer > Network > Gateways. Additionally, if you tried setting a static gateway after the robot disconnected from the WiFi without first removing the WiFi profile on the robot, it would cause the robot to repeatedly attempt to delete the old gateway. This would make the robot report errors in the system log until the robot connected to WiFi and allowed the system to delete the old gateway correctly and set the static gateway as specified. This has now been solved.
MiR Fleet
Fleet aborting missions when leaving charging stations
Sometimes, robots charging in a fleet with Auto charging enabled would discard a mission or a Move action it received while charging. The robot would then wait until it received another mission or Move action or until being sent to charge via Auto charging again. This issue has now been solved.
Zones multiplying in MiR Fleet
Sometimes, zones created in the fleet interface would create multiple copies of itself. The zones could sometimes not be deleted in the interface again, and the issue would necessitate removing all robots from the fleet and importing an older copy of the site file. This issue has now been solved.
Two robots being sent to charge in the same charging station
If two robots in a fleet with auto charging enabled entered a ready state simultaneously and one of the robots entered an Emergency stop, both robots could be sent to charge at the same charging station once the Emergency stop was cleared. This issue has now been solved.
Robots in MiR Fleet driving too close to each other, causing them to go into Protective stop
Sometimes, a robot’s Collision avoidance data would be missing on one or more robots in MiR Fleet, which would cause the robots to drive too close to each other and therefore go into Protective stop. This issue has now been solved.
Robots in MiR Fleet not releasing a resource when obstacles forces the robots more than 15 m away from the resource
If a robot in MiR Fleet were assigned a resource, for example a position, it would keep the resource even if a dynamic obstacle forced the robot more than 15 m away from the resource. This has now been solved so that a robot in MiR Fleet always releases resources when the robot is more than 15 m away from the resource.
Many mission actions executed in a short period of time slowing down the execution of these actions
MiR robots have a mission action rate limiter to ensure that a robot is not overloaded in case of bursts of many mission actions. The limit was 30 mission actions every 10 seconds. This limit has now been raised to 100 mission actions every 10 seconds, allowing bigger bursts of mission actions while still ensuring the robot is not overloaded. If the limit is reached, the robot will limit the number of mission actions to be executed to 4 every 10 seconds until there has been a 10 second window with 3 or less mission actions executed.
Software 2.13.3.2
Released 2022-08-15
1.2.2 battery firmware update failing and shutting down batteries
The battery firmware update for 48V batteries has failed in multiple instances and has caused the battery to shut down permanently. To ensure that no other batteris are shut down until the update process has been made more robust, the firmware update has been removed from the software.
Status lights not updating to the correct colors
Sometimes for robots with hooks mounted to them, the status lights could fail to change to the correct color according to the robot’s status. You could sometimes resolve the issue by restarting the robot. The issue has now been solved so the status lights always update correctly.
Robots not receiving proximity sensor data
On robots running software 2.13.3, the data from the proximity sensors was not received by the robot computer. This meant the robot would not plan paths around nearby obstacles below the laser scanner height when beginning to move. This has now been solved.
Software 2.13.3
Released 2022-07-15
On MiR600, MiR1350, and robot with MiR hooks, after updating to software 2.13.3 or higher, you cannot roll back directly to a lower software version. If you want to roll back, see the guide How to roll back from 2.13.3 on MiR600, MiR1350, and robots with MiR hooks.
1.2.2 battery firmware update failing on robots docked to 110 V chargers
If you were using a 110 V version of MiR Charge 48V to initiate the 1.2.2 battery firmware update, the update could sometimes fail. This has now been solved so the firmware update is applied correctly regardless of which version of MiR Charge 48V you are using.
This issue was also described in the 2.13.2 release note, but is only resolved in the 2.13.3. software.
Robots losing their location on the map randomly
MiR250, MiR500, MiR600, MiR1000, and MiR1350 robots could localize themselves incorrectly on the map due to unsynchronized IMU data. This would cause the robot to report a localization error, and you had to manually help the robot localize itself again before it could continue its mission. This has now been solved.
This issue was also described in the 2.13.2 release note, but is only resolved in the 2.13.3. software.
MiR robots entering Protective stop due to lost Ethernet connection
Sometimes, the Ethernet connection to the robot computer could be lost due to an issue with initializing the network link. When this happened, the robot would enter Protective stop and would report errors regarding missing connection to the safety PLC or the hook top module. This has now been solved by ensuring that the network connection to the robot computers is configured correctly at startup. This means your robot may take a few minutes longer to start up.
MiR robots using Improved WiFi settings unable to parse PKCS 12 WiFi certificates
If you uploaded a PKCS 12 (.pfx/.p12) WiFi certificate to a robot where Improved WiFi settings were enabled, it would not be able to connect to the associated WiFi. This has now been solved.
MiR Fleet
Synchronizing paths causing delays and issues on MiR Fleet
Up until now, all robot paths have been synchronized between all robots connected to MiR Fleet. Synchronizing paths led to a lot of data being exchanged through the network because:
Paths change a lot, due to dynamic obstacles.
Paths become invalid and must be replanned if the map changes.
Paths are related to a specific footprint and coordinates of the map, meaning that most paths could not be reused between individual robots and that there were many almost duplicate paths.
This would lead to general slowdown of the MiR Fleet system and delay more time critical functions such as resource management, collision avoidance, and mission scheduling.
The issues were more prominent the larger the site and the number of connected robots were. In some cases, when synchronizing a robot after restarting MiR Fleet or adding a robot to MiR Fleet, the initial synchronization could fail.
To prevent these issues, MiR Fleet no longer synchronizes paths. Benchmark tests showed that the benefits of the path synchronization did not outweigh the problems. Robots will still save and reuse paths on their own system, but they can no longer use paths created by other robots.
MiR Fleet not releasing resources for Auto staging and Auto charging
Sometimes, MiR Fleet would not correctly register a Staging position or a charging station as released. This has now been solved.
Missions-scheduled counter recording incorrect values briefly
If you used the MiR Fleet metrics, the mir_fleet_mission_scheduler_missions_scheduled counter would not count any missions that were in the middle of changing states. This meant the value could briefly drop if the value was calculated when one or more missions were changing state. This has now been solved.
Missions stalling in the mission scheduler
Sometimes, a scheduled mission could get stuck in the Outbound state if you restarted MiR Fleet. This resulted in the robot assigned to the Outbound mission never receiving new missions. This has now been solved.
Software 2.13.2
Released 2022-06-23
1.2.2 battery firmware update failing on robots docked to 110 V chargers
If you were using a 110 V version of MiR Charge 48V to initiate the 1.2.2 battery firmware update, the update could sometimes fail. This has now been solved so the firmware update is applied correctly regardless of which version of MiR Charge 48V you are using.
MiR100 and MiR200 robots stop charging or do not begin charging at charging stations
In rare cases, MiR100 and MiR200 robots could stop charging while at a charging station for no apparent reason, or the robots wouldn’t begin charging once docked to a charging station. This has now been solved so the robots reliably charge when they are docked to charging stations.
Robots losing their location on the map randomly
Sometimes, MiR robots could incorrectly localize themselves on the map due to unsynchronized IMU data. This would cause the robot to report a localization error, and you had to manually help the robot localize itself again before it could continue its mission. This has now been solved for MiR250, MiR500, MiR600, MiR1000, and MiR1350 robots so they navigate maps more reliably.
Ethernet connection to robot computer failing
Sometimes, the Ethernet ports on the robot computer were not handled correctly, meaning that the robot would not finish starting up, or you were not able to connect to the robot interface. This has now been solved.
Maps losing existing zones when being saved
In rare cases, when you saved changes to a map, it could result in some zones being deleted from the map. This could happen if a timeout in the browser caused there to be differences in the map data in the browser and the data in the database. This has now been solved by ensuring that the browser data can not affect the data on the MiR product’s database.
Aborting a mission in MiR Fleet causing MiR Fleet to stop sending missions to robots
Sometimes, if you aborted a mission from MiR Fleet, it could result in MiR Fleet entering a state where it could no longer send missions to robots. MiR Fleet had to be restarted before it could assign missions again. This has now been solved.
Removing a robot from MiR Fleet and then adding it again resulting in double metrics from the robot
If you removed a robot from MiR Fleet and then added it again shortly after, in some cases, MiR Fleet could record data twice from the robot, resulting in double data in the metrics from MiR Fleet. This has now been solved.
MiR100 and MiR200 robots with deprecated batteries starting up with error messages regarding a skipped firmware update
Sometimes, when you started up a MiR100 or MiR200 robot with a deprecated battery that had a state of charge outside of 45–95%, the robot would report that it has skipped a firmware update due to missing CAN communication to the battery, even though there was a connection and the firmware had already been updated. This has now been solved so the misleading errors are no longer reported at start-up.
Switching to or from Improved WiFi settings disconnecting the robot from WiFi
Sometimes, when you switched between the default and improved WiFi settings, the robot’s WiFi module would stop working and the robot could no longer connect to a WiFi network until it was restarted. This has now been solved.
Robots missing all Hardware health diagnostics and displays unstable driving behavior
Under System > Settings > WiFi, if you enabled one of the watchdogs and set an invalid IP address, the robot would sometimes continue to operate without checking if the IP address was valid. This would cause a delay in other diagnostics while the robot waited for a response from the invalid IP. When this happened, under Hardware health, many of the diagnostics would be missing and the delayed responses could also affect the robot’s driving behavior. This has now been solved.
MiR robots can enter Limit-robots zones to wait for a resource, provided the limit is not reached
If a robot is waiting in queue for a resource inside a Limit-robots zone, the robot used to wait outside the zone until the resource became available. Now, waiting robots can enter the zone, provided that any robots already ahead in the queue for the resource are already inside the zone and the zone’s limit is not exceeded.
MiR robots generate error logs if an auto charging mission fails
If a MiR robot is sent to charge at a charging station automatically and for some reason fails to start charging, it now generates an error log.
Software 2.13.1.4
Released 2022-04-29
MiR600 and MiR1350 entering Protective stop randomly
In rare cases, MiR600 or MiR1350 robots could enter Protective stop randomly when beginning to move after being at standstill. When this happened, the robot would report the error: The brake is supposed to be released, but the feedback indicate it isn’t. This issue has now been solved.
MiR250 robots losing connection to safety laser scanners randomly
MiR250 robots could lose connection to the safety laser scanners for no apparent reason. Robots went into Protective stop when this occurred. You could restart the robot to resolve the error temporarily, but it could reappear again. This issue has now been solved.
Software 2.13.1.3
Released 2022-04-22
Robots continuing a Relative move after being interrupted moving to the wrong final position
When any MiR robot begins executing a Relative move action, if it is interrupted by an error or is paused within the first 100 ms of the movement, it is possible that the saved X, Y, and orientation values for the movement change. In the unusual case that this occurs, the robot does not complete the Relative move correctly. Note that this issue can also occur in actions that contain Relative move actions such as Docking, Pick up, and Place actions. This issue has now been solved.
Software 2.13.1.2
Released 2022-04-11
Software 2.13.1.1
Released 2022-04-05
The 1.2.2 battery firmware update for the 48V replacement batteries 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. To make sure the firmware is applied correctly, see Battery updating procedure.
For more information about the improvements in the firmware, see MiR 48V Battery Technical Guide.
The battery firmware update is applicable to following robots:
MiR500 and MiR1000 hardware version 1.0–1.1 robots that you have installed a replacement battery in—see the guide How to install the replacement battery on MiR500 and MiR1000.
MiR500 and MiR1000 hardware version 2.0 robots.
All MiR250, MiR600, and MiR1350 robots.
Battery updating procedure
After installing the MiR software, the 1.2.2 firmware for the 48V batteries will automatically be applied next time the robot is docked to MiR Charge 48V. You can check the current firmware version of the battery in the robot interface under Monitoring > Hardware health > Power system > Battery Management System (BMS) > Firmware version.
If the battery in your robot has one of the following firmware versions, it will automatically be updated to 1.2.2:
If your robot has a different battery firmware version, contact MiR Technical Support.
While the robot is updating the firmware, do not interrupt the robot, move it, shut it down, or turn off the charging station.
When the battery firmware is updating:
Make sure the robot stays connected to the charger during the battery update process. Otherwise you risk the battery shutting down permanently to an unrecoverable state. The robot will not begin executing any missions it is assigned (by you or MiR Fleet) until it has finished updating the firmware.
Wait for the update process to finish. A message is shown in the robot interface indicating the progress of the update. You can check if the 1.2.2 battery firmware version has been applied under Monitoring > Hardware health > Power system > Battery Management System. Updating the battery takes about 2-5 minutes.
Once the robot is finished updating, you can drive the robot from the charger.
If the robot turns off when removed from the charging station or some other unforeseen event causes an interruption in the updating process, the firmware update did not succeed. On MiR250, MiR500 and MiR1000 the battery can still finish updating by connecting a MiR Cable Charger Lite 48V 3A to the robot. When doing this, make sure to leave the charger connected to the robot long enough for the battery firmware to finish updating.
On MiR600 and MiR1350, the battery must be removed from the robot and updated using another robot.
New centripetal force limit setting
Under Planner settings, it is now possible to limit the Centripetal force of the robot. By default, the setting is set to 100% and does not affect driving behavior. You can lower this percentage down to 40% at the lowest. Lowering the value makes your robot drive around corners more slowly. This is useful if you have a very heavy or tall load on the robot and want to ensure the robot maintains a steady driving behavior.
New control-loop responsiveness setting on MiR250
On MiR250 under Motor controller settings, you can now increase the aggressiveness of the motor controllers’ control-loops. This makes the robot’s motors faster at correcting their speeds to achieve the intended driving behavior. This can be useful if your robot is carrying a heavy load and you need it to react faster at correcting its driving path, such as when it’s docking. Adjusting this setting can potentially increase running noise and power consumption.
Changing the default gateway IP address
It is now possible to set the robot’s default gateway IP address without a WiFi connection being activated. This is useful when you want to utilize a 5G CPE that is connected to the robot via Ethernet to extend the robot’s wireless capabilities. You should NOT use this feature along with the normal WiFi connections.
To use this setting, under Settings > WiFi > Advanced settings, you must set the Default gateway to Static, and then you can enter a valid IP address under Gateway IP. The IP address must be in the 192.168.12.1–192.168.12.99 range and not reserved for internal use. If the entered address cannot be reached or is invalid, the robot will report an error.
Battery and charging issues
MiR250 starting up after turning off while connected to a cable charger
If you turned off a MiR250 robot while it was charging through a cable charger, it would turn on again shortly after. This has now been solved so the robot stays off until you press the Power button to turn it on again.
MiR100 and MiR200 robots not changing between charging and discharging states correctly
When MiR100 or MiR200 either finished charging or began charging the battery, sometimes the robot could take over a minute to change to the correct charging or discharging state. In some cases, this resulted in robots running out of power at a charging station because the robot did not begin charging after docking to the charger. The issue only occurred on robots with the 24V Standard or 24V Extended Capacity batteries. This issue has now been solved so the robot changes charging states correctly.
MiR100and MiR200 robots not detecting faulty batteries
When you connected a 24V Standard or Extended Capacity battery to MiR100 or MiR200, the robot checked the battery’s current state. Sometimes, the robot could fail to detect that the connected battery was faulty and would instead report other issues related to the battery. This has now been solved, so the robot reports the correct error if the battery is faulty.
Mission actions randomly failing when using battery percentage logic on MiR100 and MiR200
If you had a mission that included an action that involved retrieving information from the battery, MiR100 and MiR200 robots with 24V Standard or Extended Capacity battery could sometimes fail to retrieve the data and would fail the mission with an error regarding missing data. This issue has now been solved.
MiR250 robots with low state of charge not charging when connected to MiR Charge 48V
If MiR250 could not be turned on and you be pushed it manually onto a MiR Charge 48V, it would not begin charging. You had to use a cable charger to first turn on the robot and then push or drive it onto the charger. This has now been solved, provided that the robot has enough power to make the Power button flash red when you press it. If the Power button does not react when you press it, you must use a cable charger to charge the robot.
State of charge of deprecated batteries dropping to 0% suddenly
On robots using the deprecated batteries—see the Safety notice released July 26, 2021—the state of charge of the battery can drop to 0% very quickly if the cell imbalance is above 230 mV. This issue has now been solved, so the SoC does not drop faster than it should. Additionally, we have also improved the accuracy of the state of charge shown in the robot interface, so that it now it takes into account how worn out the battery in the robot is.
Misleading battery firmware update error message
Sometimes the robot could display a misleading error message at startup stating that “Battery firmware does not match recommended version: Current Installed: 2.9. Recommended: 2.9”. This issue has now been solved, so a more accurate error message is reported: “Battery parameters have not been updated”.
Navigation and planning issues
Robot entering Protective stop when Fast docking
If your robot uses Fast docking, on rare occasions the robot could mute its Protective fields sets too late while docking and trigger a Protective stop. This has now been solved so the fields are muted at the correct time while docking.
Blind spots in scanner data
For MiR250, MiR500, MiR600, MiR1000, and MiR1350, if the laser scanners classified data as “contaminated” due to detected contamination on the laser scanner optics cover, the data was disregarded by the robot’s navigation system. This could result in the robot planning paths without assessing all of the obstacles around it. This has now been solved by using data regardless of the detected contamination amount. If the optics cover is very contaminated, this may cause the robot to detect the contamination as a nearby object and stop. If you experience your robot stopping randomly or driving around non-existent obstacles after updating, you must clean the laser scanner optics cover—see the maintenance section in your robot’s user guide.
Robot reporting “Planner died unexpectedly” during angle correction
In rare cases, the robot could report that the “Planner died unexpectedly” while planning a path. The issue occurred when a certain angle was used in the planned path, so the issue would seem to occur randomly. This issue has now been solved.
MiR250 Dynamic getting stuck in Protective stop near obstacles
The Protective field sets on MiR250 Dynamic would sometimes increase too much when the robot was accelerating in a turn. This resulted in the robot entering Protective stop without it being able to maneuver away from the triggering obstacle, making the robot stuck in Protective stop. This has now been solved.
Cameras detecting non-existent objects due to cover design
The front covers on all MiR robots with two upward facing cameras are slightly within the field of view of the 3D cameras. This could result in the cameras detecting the covers as obstacles. The field of view is now masked so the data of the detected cover is ignored, improving the driving performance of the robots. This has been introduced previously in SW 2.10.4.1 but was removed in the preceding software due to various camera issues. It is now being reintroduced with improvements.
Other robot issues
MiR robots disconnecting from the WiFi and not reconnecting automatically
On rare occasions, a robot could be disconnected from the WiFi and be unable to reconnect automatically even with WiFi watchdogs turned on. The user had to manually reconnect the WiFi in this case. The WiFi watchdogs have been improved to prevent this from happening. The WiFi ping watchdog will be able to restart the network connection if multiple reassociation attempts were unable to bring back the connection. Previously it was only capable of triggering reassociations. Additionally, the Auto-reconnect watchdog has been improved to better identify a network disconnection.
MiR100 and MiR200 robots reporting encoder errors when starting up
MiR100 and MiR200 robots would sometimes report errors regarding the encoders when starting up. These errors were caused by the robot computer being busy during startup. They were not related to any actually faulty hardware and could be cleared a few seconds later. This has now been solved, so the error is not incorrectly triggered at start up.
Error logs failing to download
Error logs could sometimes fail to download from the robot. This has now been solved.
Sounds failing to play are handled better
If a sound failed to play correctly from the robot, the robot would continue to try to play the corrupted sound which would increase the CPU load over time leading to other unrelated errors. Now, if a sound fails to play, the robot retries to play a new instance of the sound once more and then reports an error if the sounds does not play.
Failing to import sites with double recursive missions
If a site included recursive missions that were used twice in the same mission, you could not import the site to another robot. This has now been solved.
Robot inoperable and reporting issues with power board communication
Sometimes, robots with power boards would continuously report errors regarding missing communication with the power board. While reporting this error, the robot could not run. This has now been solved by improving the communication between the robot computer and power board.
Robots reporting “Process died” error regarding the 3D cameras
Sometimes, robots with the left and right camera configuration could stop operating and report a “Process died” error regarding the RealSense 3D camera software. This could wrongly occur if the connection to the camera was disconnected briefly but automatically reconnected. This has now been solved so brief disconnections are handled without stopping the robot. If the camera is disconnected for too long, a correct error regarding missing data to the camera is reported.
MiR Fleet issues
Footprints of other robots connected to MiR Fleet jumping when Collision avoidance in enabled
The Collision avoidance feature enables MiR Fleet to communicate the robot footprints and positions between all robots connected to the fleet. Sometimes, the positions and footprints of the other robots could jump irregularly in the map interface, making an inaccurate representation of the other robots’ positions. This could affect the driving behavior of the robots in the fleet. The Collision avoidance feature has now been improved to reduce the effect of this.
Robots not receiving Auto-charging missions from MiR Fleet
In rare cases, MiR Fleet would create a mission to send a robot to a charging station but would never send the mission to the robot. This issue has now been solved.
Two robots connected to MiR Fleet being sent to the same charging station simultaneously
In rare cases, MiR Fleet could send a robot to a charging station and release it immediately afterward. While that robot continued to drive to the charging station, MiR Fleet could send another robot to the same charging station. This has now been solved so that if a robot is sent to a charging station, MiR Fleet does not release the resource immediately afterward, unless the mission sending the robot to the charger is canceled. If the robot continues the mission, it occupied the charging station correctly.
Description field in the mission_queue/(mission ID) endpoint not working when a mission is assigned by MiR Fleet
If you scheduled a mission using a POST request to the mission_scheduler endpoint and you utilized the optional field Description, the description data would not be forwarded to the assigned robot. This issue has now been solved.
Auto-charging or Auto-staging sending robots to impossible positions
On very rare occasions, MiR Fleet could try to send a robot to a Staging position or a charging station on maps that the robot could not reach and ignore the available resources on the robot’s current map that should have been used instead. This has now been solved.
Deadlocks occurring with Limit-robots zones in front of markers
Inconsistency in the order in which resources were assigned could cause a deadlock between an Entry position of a marker and a Limit-robots zone. This has now been solved, so that the robot has to occupy the Limit-roobts zone before being able to occupy the Entry position to the marker, just like with a robot position
AI cameras not being added in the MiR Fleet interface
Since software 2.13.0.1, MiR Fleet could not distinguish between new and added AI cameras. They were all considered added, even though the new cameras could not be used. This issue also resulted in the status of the cameras being shown as numbers instead of text. Both issues have now been solved.
Robots connected to MiR Fleet factory resetting each time MiR Fleet starts up
When you added a MiR robot to MiR Fleet and the robot failed to factory reset, if you restarted MiR Fleet while the robot was in a Factory reset failed state, the robot would factory reset each time you restarted MiR Fleet. This has now been solved, so the robot does not continue to factory reset after failing the first time.
Battery and charging improvements
Implemented cell monitor to avoid overvoltage events on 48V batteries
While a robot is charging, there is a chance that the cell voltage in the battery may exceed the battery’s safety threshold. This will trigger an immediate shutdown of the battery. To prevent the uncontrolled shutdown of the battery, the robot now monitors the cell voltage so it stops charging if any battery cells are approaching the overvoltage threshold. When the cell voltages drops to a safe value, the robot begins charging again automatically. You are more likely to experience this event with a used battery.
Reduced the risk of overcurrent events when simultaneously connecting a cable charger and charging station
The robot will no longer charge using both types of chargers simultaneously in order to prevent overcurrent events on the battery. The robot will use only the charger that was first connected. It is still unintended use to connect two charging interfaces at once, as potential defects may still cause overcurrent events if you connect two chargers at the same time. For more information about overcurrent events, see MiR 48V Battery Technical Guide.
Improvements in battery and power board diagnostics
The following improvements have been applied to the Hardware health diagnostics:
All power board or battery related diagnostics previously shown under Other have been moved to Power board > Diagnostics.
Under Power board > CAN communication bus there are now more diagnostics that can be used to evaluate the CAN bus communications to the motor controllers and indicator lights.
The current drawn from the GPIO interface are shown under Power board > Power supply monitor.
Robot improvements
Poorer WiFi performance on robots with NUC8 computers
If your robot has a NUC8 robot computer, the WiFi card firmware will be updated with this software. This may improve the WiFi performance.
Cleaning up data that is included in error logs or is too large to be handled
To ensure that the robot does not run out of space for log data:
The robot now removes data that is too large to be handled effectively.
After you create the error log, the robot now removes the data from its disk that is now saved in the error log.
Power board firmware updating faster and is more robust
When you applied the most recent power board firmware update, it could take over 20 minutes to upload and report multiple errors during the process. The time it take for future power board firmwares to be applied has been reduced significantly, and they are less likely to fail, provided you have update your robot to this software version first.
Unnecessary to apply NUC8 support update files after replacing the robot computer
If you replaced the robot computer with a NUC8 robot computer, you had to apply and install an additional support package on your robot so it is compatible with the new computer. This is no longer necessary. If your robot is running software 2.13.1 or higher and you replace the robot computer with a NUC8, the robot software detects this and automatically applies the necessary NUC8 related updates.
MiR Fleet improvements
Better handling of invalid data to and from robots connected to MiR Fleet
When MiR Fleet or a connected robot received invalid data, the robot would enter a non-defined state leaving the robot non-operational. We have implemented better handling for invalid data, so the robot enters Deactivated state if any data is invalid. This means that if a robot receives unexpected invalid data, you can recover the robot quickly by re-enabling it after taking corrective actions.
We have also resolved the known issues that have previously caused the robot to receive invalid data.
Aborting ongoing robot missions through MiR Fleet interface
In software 2.13.0.2, it became possible to abort ongoing robot missions through MiR Fleet REST API. This has also been implemented in the interface, so when you cancel a mission 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.
Software 2.13.0.6
Released 2022-01-20
MiR250, MiR500, and MiR1000 robots detecting chargers that are not there
Due to a rare issue with the charging detection circuits on the power board, some MiR250, MiR500, and MiR1000 robots would sometimes detect chargers that were not there. This could occur at any time and would stop the robot from moving while the incorrect detection was in effect. If you have experienced this with one or more of your robots, updating with this software solves the issue.
The battery being inoperative by using a charging station and a cable charger at the same time
Charging MiR250, MiR500, and MiR1000 robots using a charging station and a cable charger simultaneously would trip a fail-safe in the battery, making the battery inoperative as the batteries’ charging limits would be exceeded. This software solves the issue by excluding other chargers when the robot is charging.
Software 2.13.0.5
Released 2021-12-22
Joystick control on MiR100 and MiR200 inoperable at charging stations
If you tried to use the joystick to move a MiR100 or MiR200 robot that was charging at a charging station, the robot would enter Manual mode, but could not be driven from the charging station. This only occurred with robots that have replacement batteries installed and have a CAN bus connection to the battery. The issue has now been solved, so the robot stops charging and can be driven away safely.
Robots carrying full loads “wiggling” in place when arriving at positions
When a fully loaded robot reached a position, it could sometimes “wiggle” from side to side to adjust its position until it was within the allowed orientation tolerance. This has primarily been observed when robots moved to Entry positions for markers. The issue has now been solved by making sure the robot stops while it is within the allowed orientation tolerance.
This issue only affects 2.10.5 and 2.13 software versions and is also solved in the upcoming 2.10.5.x software release.
MiR100 and MiR200 taking longer time to undock from charging stations
Sometimes, when a MiR100 or MiR200 robot undocked from a charging station, it would take around 30 seconds longer to reverse from the charger. This has now been solved, so the robot undocks as expected.
This issue is also solved in upcoming 2.7.9.x, 2.8.3.x, and 2.10.5.x software releases.
MiR100 and MiR200 entering Error mode when undocking from a charging station
Sometimes, when a MiR100 or MIR200 robot undocked from a charging station, it would enter Error mode before finishing the undocking sequence and could report errors regarding a collision with the footprint or missing IMU data. This has now been solved so the robot undocks correctly.
This issue is also solved in upcoming 2.7.9.x, 2.8.3.x, and 2.10.5.x software releases.
MiR100 and MiR200 stop charging randomly at charging stations
Sometimes, when a MiR100 or MiR200 robot was charging at a charging station, it would stop charging for no apparent reason. This issue has now been solved.
This issue is also solved in upcoming 2.7.9.x, 2.8.3.x, and 2.10.5.x software releases.
Software 2.13.0.4
Released 2021-11-11
Robots failing to release brakes
MiR250, MiR500, MiR600, MiR1000, and MiR1350 robots running on 2.13.0.2 software would sometimes fail to release the mechanical brakes. This would cause the motor to stall when the robot tried to drive. This issue has now been solved.
Enabling improved WiFi causing the robot to lose its WiFi settings upon restart
If you enabled the feature Enable improved WiFi settings in System > Settings that was implemented in software 2.13.0.2, the robot could lose all its WiFi settings upon restart. You would therefore have to reconnect the robot to the company WiFi again. This issue has now been solved.
Enabling improved WiFi causing the robot to lose its connection to the power board upon restart
On MiR250, MiR500, MiR600, MiR1000, and MiR1350 robots, if you enabled the feature Enable improved WiFi settings in System > Settings that was implemented in software 2.13.0.2, the robot would sometimes lose its connection to the power board upon restart, causing the robot to stop moving and show a message in Hardware health that the power board is disconnected . This issue has now been solved.
Improving driving behavior
On MiR250, MiR500, MiR600, MiR1000, and MiR1350 robots it is now ensured that the brakes are fully released before the robot starts driving. This results in a more smooth driving behavior.
Software 2.13.0.2
Released 2021-09-30
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.
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:
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.
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:
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.
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 to 2.13.x, 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.
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:
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.
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:
Inovo Robot
Digital Signage Robot
