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.
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.