Dispenser + is_holding_point to avoid 2 robots ending up in Delivery waypoint?

[royito55]

Hi,

I have a setup in which a Dispenser node is activated when a robot arrives to a waypoint at the end of a lane, like this (coffee_bar):

Robots go here with a Delivery Task, where a Dispenser node receives a request and performs some tasks, including moving the mobile robot from that waypoint outside the lane graph for more precise control of the location where it will receive an object.

However, I noticed that when there are two Delivery requests, the second robot does not realize that the first is at the dispensing node because technically it left the RMF lanes in order to do that precise movement. This results in RMF not recognizing a conflict and both robots end up in the dispensing waypoint (coffee_bar) once the first robot comes back to the graph.

My goal is to add holding points in order for the second robot to wait while the first robot leaves that dead end waypoint where the dispensing occurs. But I noticed it does not work 100%

I'd be grateful to get some more ideas on how I can accomplish this.

[Yadunund]

the second robot does not realize that the first is at the dispensing node because technically it left the RMF lanes in order to do that precise movement.

While the robot is performing the precise movement, you can have your fleet adapter continually update the robot's itinerary such that the first waypoint in the itinerary is dispenser waypoint. We do something similar in our rmf_demos_fleet_adapter when docking. ie, the robot's itinerary does not start with the current location of the robot but rather includes the entire docking path regardless of where the robot is. That way that first waypoint where the robot begins docking is part of the schedule submitted by the fleet adapter. This should re-reoute other robot's attempting to reach this same waypoint but it's also subjective to how the graph is setup and whether there are nearby holding waypoints.

This is not ideal but it's a workaround until we have the Open-RMF Reservation system implemented where agents can reserve shared resources such as parking spots. This would also lead in to having a queuing area at pickup/ dropoff locations where robots wait for their turns to interact with the shared dispensers.

[royito55]

Hi @Yadunund,

I was wondering if this reservation system has been implemented.

[arjo129]

Hi @royito55,
I'm currently working on the implementation. You can view its progress here: https://github.com/open-rmf/rmf_reservation/pulls

There's still some work to get it in to main stream RMF as it is written in rust. The original plan was to have this as part of our "next-gen" offering.

If youd like to know feel free to reach out to me.

[mxgrey]

As an alternative to the reservation system (until that becomes available) we're going to be introducing a new "mutex" concept where you can label vertices and lanes with a mutex name. Before a robot can use a vertex or lane that has a mutex label, the robot must "lock" the mutex which ensures that no other robot is traversing any lanes or vertices that share the same mutex label.

The feature is finished but not released yet (I'd anticipate 2 more weeks for the release), so please stay tuned.

[osama-z-salah]

As an alternative to the reservation system (until that becomes available) we're going to be introducing a new "mutex" concept where you can label vertices and lanes with a mutex name. Before a robot can use a vertex or lane that has a mutex label, the robot must "lock" the mutex which ensures that no other robot is traversing any lanes or vertices that share the same mutex label.

The feature is finished but not released yet (I'd anticipate 2 more weeks for the release), so please stay tuned.

is there any example on how to use the mutex and does it solves the following where two robots need to pick up objects from a shared docking station