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.
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:
1.1.6
1.1.8
1.1.10
If your robot has a different battery firmware version, contact MiR Technical Support.
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.
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".
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.
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.
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.
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.
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.
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.