We’re excited to announce a new release of Open-RMF, available in the Iron Irwini ROS distribution (and available for Rolling after the next sync).
We’re introducing new capabilities and behavior improvements, with an emphasis on the
EasyFullControl API. The changes in this release were battle-tested in a live deployment that uses the
New capabilities include:
- Mutex Groups: Now lanes and vertices can be assigned to a “mutex group”. Before a robot can begin using a lane or vertex that belongs to a mutex group, the robot must lock the mutex group for itself. A mutex group can only be locked for one robot at a time. This allows graphs to be designed with improved traffic flow in cases where a system integrator can anticipate clutter.
- Localization Hook: The
EasyFullControlAPI now has a hook that will trigger a localization request whenever the robot has arrived at a new floor after taking the lift. This reduces the effort needed by integrators since you no longer need to infer when the robot has changed maps.
- Dynamic Charging: You can dynamically update which chargers each robot should use while idle (or provide a location for them to park). We also provide a charger schedule node that lets you pass in a schedule configuration (.yaml) and will automatically send out charger updates according to the schedule.
- Lift usage behavior is improved
- Robots now set the horizon of their traffic schedule to be the point where they will begin waiting for their lift session to begin.
- While using a lift, robots are stubborn, i.e. they will not participate in negotiations, forcing other agents to give way to them
- After any replanning that happens while a robot is using a lift, the adapter will reliably determine if the lift session must remain locked or should be released. Previously there were edge cases where the state machine might fail to realize that the lift needs to be released after a replan.
- “Finishing tasks” (e.g. returning to charger) will now be immediately canceled when a new task request comes in instead of needing to finish before the new task will begin.
- Doors will be opened or released reliably as needed after a replan occurs. Previously there were some edge cases where a replan would confuse the state machine about whether a door needs to be opened or closed.
- Task bidding calculations are done outside of the main worker loop so that task auctions no longer have a risk of slowing down normal operations