New release of Open-RMF on iron and rolling

General
, , ,
1

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 EasyFullControl API.

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 EasyFullControl API 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.

Improved behaviors:

  • 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
5 Likes
2

Hi @grey. Nice to have this functionality till the time reservation and queue comes in.
i wanted to know Can i use this in ROS humble. I tried this but it was not working in humble distro.
Mutex lock is not being accquired by robot and it stops there infinitely.
[tinyRobot_fleet_adapter]: Waiting to lock mutex groups [pan_entry] for robot [tinyRobot/tinyRobot2]

3

We didn’t do a binary release of the new capabilities in Humble since that violates the principle that changes released in existing distros should be limited to only bug fixes. We flexed this principle a bit for the Iron distro since that’s not an LTS and is a relatively fresh distribution.

But there should be no issue at all if you build the latest main of the RMF repos and run that on top of a Humble distribution. Just make sure you don’t have any ros-humble-rmf-* packages installed, because that can lead to messy build issues.

The specific problem you’re running into is that you don’t have the mutex group supervisor running. All you have to do is add this to your launch file:

<node pkg="rmf_fleet_adapter" exec="mutex_group_supervisor" output="both" />

This makes me realize that we should update common.launch.xml in the rmf_demos package to include this line, and we should put out a new map in rmf_demos_maps that demonstrates the mutex groups being used.

1 Like
4

Thanks @grey I added the supervisor node in common.launch.xml file and now its working. I do have one more issue when i want to close any lanes and open it by publishing on topic /lane_closure_requests. The whole planning freezes and everything stuck the purple dot robot and visualizer also stops displaying on rviz.

Do i need to start open_lanes and close_lanes node separately like this in launch file

<node pkg="rmf_fleet_adapter" exec="close_lanes" output="both" />
<node pkg="rmf_fleet_adapter" exec="open_lanes" output="both" />
5

It sounds like whatever you’re doing might be causing the fleet adapter itself to crash if the purple dot disappears from rviz.

I’d appreciate if you can open an issue here with a complete description of how we can reproduce what you’re experiencing.

6

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.