| Date | 2022-01-07 |
| Label | Software release 2.7.x |
| Product | MiR robots and MiR Fleet |
| Released by | Odin Skovsted |
Released 2022-01-07
Released 2021-09-30
To implement the battery safety measures described in the Safety notice from July 26, 2021, you had to update to the software versions with the safety measures in a specific sequence for them for them to take effect. This issue has now been solved, and you can update the robot to software 2.7.9.6, 2.8.3.5, 2.10.5.7, and 2.12.0.4 that all include the battery safety measures from any software version.
Released 2021-09-03
If you don’t follow the sequences described in this release note, the robot will not receive data from the battery, and the safety measures in the software will not be implemented.
If this occurs, the status a no message is received from the battery is most likely displayed under Monitoring > Hardware health > Power system.
If you have already updated your robot to software version 2.10.5.4 and Power system has the status described above, follow this sequence to upload the software correctly:
If you have not updated your robot to software version 2.10.5.4, follow this sequence to do so:
This software update implements a battery state of charge limit on robots with deprecated batteries. By default, the state of charge limit it set to 50% of the battery’s capacity, but can be increased to 80% or 100% if necessary. For more information about this safety measure and how to apply it correctly, see the safety notice from July 26, 2021.
Robots with deprecated batteries should not be charged with a cable charger for longer than necessary to reduce the risk of overheating—see the guide How to use chargers on MiR robots with deprecated batteries. When MiR500 and MiR1000 robots are limited to a state of charge of 50% or 80%, they emit an audible beep sound once per second when the robot is almost charged to the chosen limit.
The charge current of MIR500 and MIR1000 robots is reduced to 20 amps (from 40 amps) on deprecated batteries with this software.
Temperature control limits are implemented in this software, so the robot will not allow charging if the battery temperature is outside the operating window of 5 to 50°C.
Released 2020-12-17
This software update features a battery firmware update introducing a self-diagnosis feature that monitors the difference between the voltage potential in battery cells.
The robot software also includes more error handling for batteries and displays a new field in the robot interface under Hardware Health > Power system > BMS > Firmware version that enables you to see which firmware version is on the battery.
To apply the firmware update, see one of the following how-to guides for your robot:
The new firmware has a self-diagnosis function that continuously monitors differences between battery cell voltage potentials and takes protective measures when the imbalance exceeds high values:
The software containing the battery firmware has additional battery safety measures that are applied when you update the robot.
Once the robot software is installed, if the robot system detects that there is a cell imbalance above 300 mV, the robot delays the battery firmware update for ten minutes and reports an error in the interface. When the ten minutes are up, the battery firmware is installed, and the battery shuts down internally so it can no longer provide power and must be replaced.
To ensure the battery firmware is correctly installed, the robot will report an error if the firmware update fails. Solutions to each error code are described in the aforementioned how-to guides.
Released 2019-12-05
New setting for improved driving in areas with obstacles in motion
The setting for clearing obstacles in the robots’ memories has been expanded with three new options for adjusting the robots’ behavior toward moving obstacles. These obstacles leave blue ghost clouds in the map that the robots sometimes drive around, even though the obstacle is no longer present.
MiR robots use both laser scanners and front cameras to detect obstacles, but the laser scanners only see obstacles around the robot in a flat plane and fixed height, whereas the cameras have a three-dimensional field of view, but is limited to seeing obstacles in front of the robot. So if, for example, the front cameras have detected an obstacle that is below or above the height of the laser scanners, the robots remember the obstacle and make a new local plan to avoid it.
However, sometimes the obstacles detected by the cameras are not in the robot’s path anymore, but as a precaution, the robot will assume that the obstacle is still there. This can cause the robot to make unnecessary new paths.
To avoid such situations, users now have the option of choosing between three different obstacle history clearing options:
The new setting can be found and applied in:
No clearing is the default setting, in which the robot remembers all obstacles it has detected and only clears the obstacle history within the field of view of the sensors.
This setting produces the normal behavior of the robot and is intended for all environments, especially where the dynamic obstacles in the robot’s path rarely change.
Figure 1.1. The purple cloud indicates a static object only seen by the cameras. The black lines indicate the field of view of the cameras. In this mode, the robot will remember the obstacle history when an obstacle detected by the cameras is out of view of the cameras, but will assume it is still there and make a new local plan to avoid it, if possible, or stop and wait for it to clear.
Clear in front of robot disables the obstacle history in a cone in front of the robot. The cone starts in the width of the robot’s footprint and increases by 30 cm per meter until the end of the cameras’ range.
This setting is intended for all driving configurations in environments where the robot’s path is frequently interrupted by dynamic obstacles in motion, such as people walking by in front of the robot.
Figure 1.2. The purple cloud indicates a static object only seen by the cameras. The black lines indicate the field of view of the cameras. The dark gray cone indicates where the robot will clear the obstacle history as soon as the obstacle is out of view of the cameras and scanners.
Clear all disables the obstacle history entirely, so that the robot only avoids obstacles it can see with the cameras.
This setting is intended for driving in Line following mode. That is, with little or no path deviation and a path timeout set to infinite waiting, and in environments where the robot’s path is frequently interrupted by dynamic obstacles in motion, such as people walking in front of the robot.
When this options is used in the intended way, the robot will stop for all obstacles in the field of view and wait for them to move, thus limiting the risk of hitting unseen obstacles.
Figure 1.3. The purple cloud indicates a static object only seen by the cameras. The black lines indicate the field of view of the cameras. In this mode, the robot will clear the obstacle history detected by the cameras as soon as the obstacle is out of view of the cameras.
Robots would make new global plans immediately after a protective stop or after the robot was paused, even though path timeout was set to -1 in System > Settings > Planner, indicating an infinite waiting time. This release fixes the issue.
On MiR robots with 435 3D cameras, the cameras did not get sufficient data from the floor, causing issues when trying to determine whether a pallet rack was occupied or not via the Check position status action. This update solves the issue.
Robots would not import site files generated on other robots, but only import site files exported from MiRFleet. This update solves the issue.
On rare occasions, when undocking with a custom length from charging stations, markers, and pallet racks, MiR500/MiR1000 robots would reverse too far before doing another move. This update solves the issue.
On rare occasions, MiR robots driven manually or on the edge of a Speed zone would not return to default speed after exiting the zone. This update solves the issue.
The manual in the robot interface not scrolling down
In the manual in the robot interface that you can access through the Help section, it wasn’t possible to scroll down to read the bottom part of a page. This is now fixed.
In the mission action Prompt user, the user group selection would display different groups in the English and non-English versions. With this release, the user groups are the same in all languages.
In Monitoring > Hardware health, long texts would be cropped, even if there was plenty of space to show them in full length. This update solves the issue.
Single dashboard users didn’t have a sign-out button when using devices with small screens, for example smartphones. This update solves the issue.
In Setup > Maps > I/O module zones > Zone settings > PLC registers, Entry action and Exit action would only display text, not a drop-down menu. In this release, a drop-down menu with the three choices Set, Add, and Subtract are added to both Entry action and Exit action.
In Help > Fleet information, the information labels read Robot name and Robot serial instead of Fleet name and Fleet serial. This update solves the issue.
After finishing several missions, selecting Clear all done missions did not remove all missions in the done list. This button has now been removed.
High priority missions were colored green in the As soon as possible list. When they entered the Executing list, they changed to blue. High priority missions are now green on both lists.
When canceling an active order via REST API, the robot executing the mission would still complete the mission. Once the mission was completed, the fleet could not send new missions. This is now fixed, and the fleet can send new missions to robots after an order has been canceled using REST API.
When restarting MiRFleet, information about missions in the mission scheduler was lost. This update solves the issue.
When robots connected one map with another via a transition, robots in MiRFleet could not use the transition. This is now possible, and MiRFleet sends the robot that has the shortest route to complete the mission.
When a robot was supposed to exchange its position at a charging station with another robot, it was sent to a staging position and the other robot to the charging station. If the first robot didn’t receive the request to move to the staging position, the second robot would wait indefinitely for the robot to leave the charging station. Now, the second robot is sent to the charging station only when the first robot has confirmed that it is moving to the staging position, solving the issue.
When a robot was given a new mission, the mission could be registered in MiRFleet as Done immediately. The mission was still executed and completed by the robot. This has now been fixed.
A mission that was canceled on an individual robot through the robot’s interface was registered as Done in MiRFleet. A canceled mission is now registered as Aborted in MiRFleet.
If a staging position was removed in the MiRFleet interface, the robots would still use the removed position until MiRFleet was restarted. This has now been fixed.
If a robot was moved from a staging position or charging station using the Go to function, MiRFleet did not update the status of the resource to available. This is now fixed, so robots can be moved from resources using Go to instead of missions.
Using REST API to change the mission priority of already scheduled missions resulted in the mission scheduler failing, and MiRFleet had to be restarted. This is now fixed.
If a Limit-robots zone was placed on one floor map of a multi-level site, it also applied to other floor maps for the same site. If a robot entered the Limit-robots zone, it locked the area for robots on other floors. This is now fixed.
When robots were sent to staging position by MiRFleet, they would occasionally enter an unknown state. In this state, the robots could not receive new missions. It is now no longer possible for the robot to enter the unknown state.
Released 2019-10-15
The following issues have been solved or improved in SW version 2.7.8:
Robots needed to be removed from chargers and staging positions when restarting the fleet. With this update, MiRFleet will automatically assign robots to chargers and staging positions upon restart, solving the issue.
Having many missions on the mission scheduler caused the browser to become slow and unresponsive due to an overload of graphical elements in the scheduler. With this update, there is added filtering options to the scheduler, as well as a clear all option and the ability to adjust the size of the scheduling groups, solving the issue.
MiRFleet would report robots as executing order, while the robots would report them as done, causing the fleet to stall or operate with a delay. This update solves the issue.
The Delete button on Executing missions did not work.
With this update, the Delete button on Executing missions is removed.
MiRFleet would ignore the importance value of a mission sent via REST call. The mission would show as high importance on the fleet UI but still be placed at the end of the queue and not executed ahead of normal missions.
In the 2.7.8 update, the importance value is deleted altogether and replaced by a high priority value that the fleet recognizes.
Set high_priority to true through REST API as shown below.
Missions queued on the fleet would be assigned to robots in any state. Robots in protective stop, paused, or error mode would all get missions. This update solves the issue.
Missions queued via REST call in the MiRFleet’s mission queue was able to unpause a paused robot. This update solves the issue.
Missions queued via REST calls would sometimes be queued to the same robot, even after several seconds passed. With this update, orders are not marked as invalid if an occupied robot does not respond but are instead reset to an initial state, so they can be assigned to other robots.
If a 3D camera on a MiR robot was unable to connect due to missing calibration tables, it would keep on trying to connect and not go into error state.
With this update, the robot interface will show an error that requires user intervention if a camera is unable to connect to the robot.
The global planner would make plans with a wrong footprint when the footprint was changed in a mission. This update solves the issue.
Robots could use all memory if footprints were changed numerous times, especially when driving on large maps, causing the robots to stop unnecessarily and wait for the memory to be cleared. This update solves the issue.
The update introduces the following quality improvements:
When a robot is given a new command during planning, it will immediately start a new global plan and interrupt the initial planning, improving planning speed.
The docking calibration parameters for the individual robots have been expanded from one global docking offset in System > Settings > Calibration into separate docking categories. The new categories are for charging stations, V-, VL and L-markers, shelves for MiR100/MiR200, and pallet racks for MiR500/MiR1000, so users can change the robot’s offsets in each category, improving docking consistency between robots.
Released 2019-10-03
Released 2019-09-24
With this update, MiR500 and MiR1000 now receive more precise footprint data from the fleet.
The 2.7.4 software introduced an issue in which MiRHook with carts sometimes reversed into obstacles at goal position when executing a Place cart with collision check action. This software update solves the issue and ensures the functionality of the Yes, with collision check option in the Place cart action.
Missions with many actions created on the robots were sometimes not syncronized correctly in Fleet 1, leaving out many actions in the synchronized missions. This software update solves the issue.
On MiR robots and MiRFleet 2, importing sites with missions with many actions sometimes left the imported missions without an action list. This update solves the issue.
In Fleet information, Fleet name, Fleet license, Fleet software version, and Fleet serial did not show the correct information, and in Fleet setup the name of the Fleet did not show. This software update solves the issue.
When adding a marker to MiRFleet 2, the position manager would malfunction, and the robots would display Waiting for resource if the fleet wasn’t restarted. With this update, MiRFleet 2 no longer needs to be restarted after creating a marker.
When making changes to a mission on a phone or tablet, the Leave site? pop-up did not appear when leaving the site without saving the changes. This issue is now solved.
With this software update, the joystick jumps to neutral and the robot stops for an incoming phone call while driving in manual mode with an iOS or Android phone.
Since SW update 2.7.3, the settings in MiRHook could not be changed in the user interface, now they can.
The error log page didn’t show logs when used on phones. This is now solved.
Robots’ calculation of the distance to a resource have often been unprecise, because the robots have assumed that all points in the designated paths have been located equally apart in distance. In reality, they have differed a lot. So, the actual distance to a resource have often been greater than calculated, causing errors in resource handling in MiRFleet.
With this software update, robots now calculate distances to resources more precisely, improving resource handling in MiRFleet.
The range in which MiRFleet can track robots has been increased from 4.5 to 15 meters, and the tracking logic in MiRFleet has been improved, affecting the collision avoidance feature.
With this software, the robots now detect the maximum number of detection points in the pallet rack that the robot receives through the cameras as default when docking, and a buffer for detecting if the pallet rack is occupied before docking has now been added. Also, the robots now assume the pallet racks to be occupied before docking.
These changes will improve docking to pallet racks but will not affect the speed of docking.
