Released 2022-09-15
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.
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.
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.
Quality of Service cycle time on MiR Fleet increasing with API integration
The Quality of Service is impacted by the number of robots in a fleet and API integration with that fleet. This software introduces improvements in performance for the Quality of Service.
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.