Mobile Industrial Solutions – MiRCapra RoboticsTemi Robotics
Digital Signage Robot
- Robot Accessories
- Content Hub
- About Us
- Contact Us
|Label||Software release 2.14.x|
|Product||MiR robots and MiR Fleet|
|Released by||Odin Skovsted|
Shelf legs triggering Protective stop on MiR600 and MiR1350
When MiR600 or MiR1350 were transporting shelves, the shelf legs could sometimes cause the robot to enter Protective stop, even though the shelf design met MiR specifications. If you have this issue, you can apply SICK configuration file version 6.5 where the shelf leg cutouts have been extended on the inner side to increase the shelf leg tolerance. You can download this file from the robot interface on software 2.14.4 under System > Robot setup. You need to use the latest version of SICK Safety Designer software to apply the new configuration file.
The new SICK configuration file does not have any other effect on the robot’s performance or safety. All new robots shipped with 2.14.4 software have the new SICK configuration applied in production.
CAN bus nodes disconnected after updating
Sometimes, after you update a MiR robot, the CAN bus nodes would not boot up correctly. When this happened, the robot could not connect to the proximity boards, GPIO board, and brake controller board even after restarting the robot multiple times. This has now been solved so the CAN bus nodes boot up correctly.
Robots failing to swap charging stations automatically if one of the charging robots can not be sent to Staging position
If all Charging stations in a fleet are occupied, and a robot needs to be sent to charge, the Auto charging function tries to swap this robot with one of the charging robots. If the first robot that MiR Fleet evaluated for being swapped could not be sent to any Staging positions, the swap failed. MiR Fleet did not evaluate any of the other charging robots, and the waiting robot was never sent to a Charging station. This has now been solved.
MiR Fleet canceling Charging and Staging missions immediately after assigning them
MiR Fleet would sometimes assign a Charging or Staging mission to an idle robot and immediately cancel the mission with the reason that the robot is still executing its previous action. This has now been solved so robots are sent to and from charging stations correctly with MiR Fleet.
Wrong voltage readings during charging
On rare occasions, an incorrectly calibrated voltage reading would cause the robot to report a false voltage out-of-bounds error during the end of the charging phase when at maximum voltage. This issue has now been solved by correctly offsetting the voltage reading.
Motor controller failing on MiR250 robots running on 2.14.0 or 2.14.1 software
Sometimes, MiR250 robots running on 2.14.0 or 2.14.1 software would suddenly stop moving because the motor controllers did not receive drive commands. This was caused by a change of parameters in the motor controller’s default configuration. In SW 2.14.2, the motor controller’s default configuration is always loaded correctly into the motor controller, which ensures this issue will not occur.
Robots with replacement batteries not charging at high battery percentages
If you have a MiR100 HW version 1.9.1 or lower or a MiR200 HW version 1.0.1 or lower, and you replaced the original battery with a replacement 24V Standard battery without setting the battery state of charge limit to 100%, the robot would not charge the battery until it went below 73% battery percentage. This has now been solved so the robot will charge the battery at any battery percentage.
Wi-Fi not connecting if password includes an equal sign (=)
If you added a Wi-Fi connection and used a password that included an equal sign (=), the Wi-Fi connection would be lost. This has now been solved.
MiR600 and MiR1350 loosing localization after protective stops
If a MiR600 or MiR1350 went into Protective stop or Emergency stop while driving at high speeds, or if it went into many stops in close succession at low speeds, the robot would sometimes loose localization, especially when driving with heavy payloads.
The issue was caused by a safety measure that disconnects the motor controllers whenever STO relays are switched off, for example, during a Protective stop. When the motor controllers are disconnected, they do not communicate any encoder values (the motor encoders measure how many times the motor of each drive wheel has rotated).
With this software, the robot uses its Inertial Measurement Unit (IMU) to calculate the distance the robot travels while the STO relays are switched off. This solves the issue.
Fleet scheduler freezing or lagging when receiving many REST API calls
Sometimes when the fleet scheduler received many REST API calls, the fleet would lag or seem frozen, or the user would receive a “500 Internal Server Error” response on the API call. This was mainly an issue on large fleets that received very large numbers of REST API calls. This issue has now been solved.
Brake voltage showing in millivolts
In the robot interface under Monitoring > Hardware Health > Motors > Brake, the voltage was shown in millivolts and not in volts. This has now been solved so the voltage is shown in volts.
Power board not sending information for up to five seconds
In rare cases, the power board on MiR robots would not send any information for up to five seconds. This could, for example, cause the robot to loose localization or to fail its current mission. This has now been solved.
Improved camera filter description
The description of the camera filters has been improved in the robot interface to avoid confusion. It explains that higher filter values mean lower sensitivity to obstacle data. The following description has been added: “A higher filtration makes the robot less sensitive to camera obstacle data, meaning it is less likely to detect obstacles.”
This software release includes a firmware update for the Intel D435 3D cameras and includes support for Intel’s new hardware version of the cameras. If a robot has the newest hardware version of the cameras, it must run on software 2.14.1.
MiR robots that was shipped after 2023-05-25 with the following serial numbers have the new hardware version of the Intel D435 3D cameras:
MiR100: 201804193 and higher
MiR200: 201905042 and higher
MiR250: 204803414 and higher
MiR600: 204903381 and higher
MiR1350: 205003362 and higher
Spare part numbers 450113, 450113, 450115, 450116, 450126, 450221, 450222, 450314, and 450489 that was shipped after 2023-05-2 also have the new hardware version of the Intel D435 3D cameras
Updating the firmware of the cameras also resolves an issue that reduced the docking and navigation performance of MiR robots.
The 3D camera laser emitters turning off randomly
The 3D cameras have a laser emitter module that improves the quality of the camera 3D data. Sometimes, the laser emitter module turned off randomly, which could negatively affect the robot’s navigation and docking performance. This has now been solved by updating the camera firmware. Restart the robot after updating to make sure the firmware update is applied.
From this release, the deprecated 24V and 48V batteries are no longer supported by the software. If you have robots that are still using the deprecated batteries, you cannot use this or any future software updates—see the Batteries section on MiR Support Portal for more information.
If you have a deprecated battery, you must replace the battery. Contact MiR Technical Support for assistance—see Contact information.
If you update a MiR100 or MiR200 robot that has a deprecated battery that does not have a CAN bus connection to the battery, the software assumes you have replaced the battery, so the interface will not report an error and the battery capacity is increased to 100%. There is a risk of deprecated batteries overheating and causing a fire if this happens.
You can distinguish a battery with CAN bus connection from a battery without by the extra connector next to the blue battery connector. You can also check the battery serial number. Numbers that include the letters “CB” are for batteries with CAN bus communication connection.
Do not update the software if your robot is still using a deprecated battery.
Software 2.14.0 is the first software release to support MiR250 hardware version 2.0. Hardware version 2.0 is not backwards compatible and cannot run on any software below 2.14.0.
There will be a separate MiR250 hardware 2.0 release note.
MiR Fleet is slow to respond or fails to respond to REST calls after modifying the site
If you have made many changes to the MiR Fleet site or you have been running MiR Fleet for a long time, it can become increasingly slow at registering changes to the site, which can prevent it from responding to requests. This has now been solved.
MiR Fleet aborting Charging and Staging mission shortly after assigning them
If you have enabled Auto charging or Auto staging, MiR Fleet sends missions to idle robot to send them to charge or stage. Sometimes, MiR Fleet aborts the missions seconds after sending them so the robot remaining idle in the same position as before.
MiR Fleet slowing down when many resources are added to the map
If your site has a high number of resources (positions, markers, and Limit-robot zones), for example, over 1400 positions in a fleet, it would cause the communication time, QoS (Quality of service), between robots and MiR Fleet to increase. This would result in MiR Fleet operating slower. This made MiR Fleet operations and response times slower.
MiR Fleet now only communicates information about the resources that a given robot needs to use, decreasing the amount of communication to each robot. The higher the number of robots connected to the site, the fewer resources you can make before affecting the performance of MiR Fleet.
Robot becoming unresponsive after a few days if it runs missions that execute many actions
If you had a robot run a mission that made the robot constantly run many short actions, it would eventually cause the robot’s action log to take up too much space and make the robot unresponsive. This would often happen if you had missions that continuously looped around short actions that take less than a second to complete. This included If and While statements. This has now been solved so the action log is purged more often.
MiR600 and MiR1350 reporting motor stall errors after stopping
When MiR600 or MiR1350 was brought out of Protective stop, sometimes the motor controller would not initialize completely before the robot tried to move, resulting in the robot reporting a motor stall error. Once you cleared the error, the robot could operate again. This has now been solved.
Entire rear status light turning red when MiR100 and MiR200 stop
If you enabled Indicator light under System > Settings > Planner on a MiR100 or MiR200 robot, the whole rear status light would turn red when the robot was stopping instead of just the ends. This has now been solved.
Updated robots with Improved Wi-Fi enabled losing Wi-Fi connection
If you created a Wi-Fi connection on the robot using the Improved Wi-Fi settings and you limited the channels to only 5 GHz, next time you updated the robot the robot would report an error and not be able to connect to Wi-Fi. This would only occur if you were updating from software version 22.214.171.124 or lower to software 126.96.36.199 or higher. The issue has now been solved.
Corrections in the interface texts
The following texts have been corrected:
The Auto charging and Auto staging settings texts are now formatted correctly.
The Pallet lift feature has been renamed to Lift since it is also used for shelf lifts.
The Port parameter in I/O actions has been corrected from SMTP port to Port.
Robots reporting errors at startup until you swap network connections
Sometimes, robots reported power board, charger, and motor error at startup that were not cleared until you disconnected the robot from the current network, connected to another network, and then reconnected to the original network. This has now been solved.
Robots failing to startup due to power board errors
Sometimes, the robot would fail to startup correctly if you were updating to a version with a power board firmware update. The robot could lose connection to the power board while uploading firmware files. You had to restart the robot to try the startup process again. This has now been solved.
Error logs growing beyond the set limit
In rare cases, the log rotation could fail and would cause the logs to start taking up a lot of space on robots. This would slow down the robot, and eventually make it unresponsive once the hard drive was completely full. This has now been solved.
Missing scanner data when navigating and detecting markers
Sometimes, robots would fail to dock reliably or have a hard time navigating around obstacles due to blind spots in the scanner data. The robot’s Personnel detection safety function was not affected by this issue, it was only data that could be used for navigating and docking that is missing. This has now been solved.
Robots reporting Turn speed violation errors
Sometimes, robots would stop and report a turn speed violation error while turning normally. The robot turn speed limits have now been adjusted to ensure adequate headroom to the limits configured in the safety system. There can also be other reasons for the robot reporting Turn speed violation errors—see Troubleshoot Turn Speed Violation error on MiR600 and MiR1350.
Maps not updating correctly after removing multiple zones of the same type
If you created multiple zones of the same type, saved the changes to the map, and then removed two or more of the zones you just added, not all of the zones would be deleted after you save. This has now been solved so all zones you delete remain deleted after saving the changes.
Robots driving with choppy motion and loud motors
Sometimes, not all of the motor controller parameters would load correctly when starting up MiR250, MiR600, or MiR1350, resulting in choppy and loud driving. For MiR600 and MiR1350 robots, the parameters would be set as soon as the robot entered Protective or Emergency stop. This has now been solved, so the behavior is not seen on any robots.
Robots turning off after 5 minutes of low battery instead of 10 minutes
When the battery percentage is low on robots, they should turn off automatically after 10 minutes so they can be moved to a charger. Some robots turned off after 5 minutes of low power. This has now been solved.
Incorrect battery manufacturing year in Hardware health
Under Monitoring > Hardware health > Battery Management System, the year under Manufacturing week/year was incorrect. This has now been solved.
CAN nodes disconnecting briefly and causing errors
Sometimes, the CAN nodes (Proximity sensors and GPIO module) could disconnect shortly, possibly interrupting robot operation. This has now been solved.
Improved description of the elevator Turn in place function
In the help text for the Turn in place function used when setting up floors for elevators, the text now describes that the function just makes the robot automatically pivot 180° in the elevator before planning a route out of the elevator.
You can find the list of known issues on MiR Support Portal. Go to https://supportportal.mobile-industrial-robots.com/ and select Software. Select the Known issues document for the latest minor release.
Restarting the robot before the update is complete may result in a malfunction of the robot system
Do not turn off the robot until the update is complete.
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 the software, and then export them again after the update.
All robots that are connected to MiR Fleet must be running the same software version as MiR Fleet.
If you are running a software version below 188.8.131.52, remove robots from MiR Fleet before updating the robots.
Always update the hook software before the robot software. Hooks are updated under Hook > Software versions, and robots are updated under System > Software versions.
It is important to use the correct procedure when updating MiR products 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.
All connected robots must be updated to the same software version as MiR Fleet.
To correctly update your product, see the guides:
How to update a MiR robot’s software
How to update MiR Fleet