Avoiding Negotiations to the Docking, Charging, and Parking Stations (#577)

Open-RMF Open-RMF General
1

Posted by @alex-roba:

How can I avoid Negotiations into Docking, Charging, and Parking Stations? Currently, rmf resolves conflicts by directing robots to these stations, but I want to eliminate this behavior.

2

Posted by @mxgrey:

The reservation system was introduced to prevent the need for robots to do traffic negotiations into parking spots and chargers.

To turn it on you’ll need to launch the reservation node and then turn on the reservation system for your fleet adapter using either:

  1. robot.use_parking_reservation_system(True) for the original full control API, or
  2. use_parking_reservations: True if you’re using an Easy Full Control config file
3

Posted by @alex-roba:

@mxgrey Thanks for your reply how about for docking station that are not parking spots or chargers they just target points to do some job how to avoid traffic negotiations to them

4

Posted by @mxgrey:

I might need you to give a more concrete explanation of your workflow, but when you use the reservation system, any go_to_place action that your robot does will lock in the destination by name before the robot goes there.

As long as the docking behavior happens on the destination waypoint then your use case should be covered.

5

Posted by @alex-roba:

When you said it won’t negotiation to a parking/charging station, do you mean by occupied parking/charging station. I’ve set the reservation system to True however it still negotiates to an unoccupied charging station.

6

Posted by @mxgrey:

I’m not sure if I understand what you mean when you say “negotiate” here. It may help if you share a video of whatever problem you’re running into.

When I talk about “negotiating” I’m referring specifically to how robots will replan their paths when they run into traffic conflicts with other robots.

What the reservation system does is ensure that the final destination for each robot is not simultaneously the final destination for any other robot. Also that destination will be locked in until the robot is ready to move elsewhere.

The reservation system is separate from the traffic negotiation system that I was referring to, but if you don’t use the reservation system then you will experience a lot of traffic conflicts around waypoints that multiple robots have as their destination simultaneously, and that will lead to a lot of negotiating.

7

Posted by @alex-roba:

Yes, I’m referring to the general traffic negotiation system where it often negotiates to the charger if it is nearby the traffic, the charge dock is slow and not often accurate and may take multiple retry which will mess with the traffic, I want to avoid this kind of behavior. How can we exclude the charging point from the negotiation?

8

Posted by @mxgrey:

The solution is going to be very situational.

If the docking is happening in an area that other robots need to pass through then you need to have some way to prevent or resolve traffic issues.

If negotiations are causing disruptions because the robots need space to do retries then you probably need to use mutex groups. You would put the docking lane and its starting waypoint into one mutex group so that any other robot passing through will have to wait until the whole docking sequence is finished.

However mutex groups require some careful thought and manual setup, so whenever possible I would recommend keeping traffic completely away from areas where sensitive actions are being performed by designing the traffic routes to keep bypassing traffic away. Mutex groups are a good last resort when you have tightly constrained high traffic density zones.

9

Posted by @alex-roba:

@mxgrey, using a mutex isn’t a viable solution for my situation. The problem arises when negotiations occur while the robot is carrying a load. Due to mechanical constraints, it becomes impossible for the robot to dock for charging while carrying the load, as this could result in a collision.

The only solution I see is to exclude the charging station, parking areas, and docking stations from the available graph for the robot, except when these are the robot’s specific goal (e.g., charging, parking, or docking). However, I am unsure how to implement this exclusion effectively. Could you provide guidance on how to achieve this?

10

Posted by @mxgrey:

Okay I think I understand now, but let me check to make sure:

The problem is that negotiations are happening near the charging station, and a robot which does not want to enter the charging station is being commanded to go there in order to resolve the negotiation, is that right?

If at all possible, I would recommend fixing this by designing that area to have no possibility of negotiations occurring. That can come in a few different forms depending on the situation:

  1. Best case scenario, set up the traffic flow to have one-way lanes running in each direction so that robots don’t have to move out of each other’s way. This only works if you’re spoiled for free floor space.
  2. If you don’t have enough floor space and need to have bidirectional lanes in the area, then you’ll probably want to apply one big mutex group to the whole region with a designated entrance and exit lane, like this diagram. This means that only one robot can operate in the region at a time, but you’ll have much smoother traffic.

In the next generation I want to introduce good support for the feature you’re really asking for: Enabling/disabling the use of certain lanes or waypoints for negotiation, and/or based on runtime conditions. That capability won’t be feasible to introduce into the current generation, but there is one potential workaround if you have to resort to it:

  • When spinning up your fleet adapter, create a different fleet adapter for each robot
    • If you’re using the typical easy full control config file, you’ll need to remove all robots from that config and then call the add_easy_fleet function, reinserting one robot at a time
    • I don’t know if the overall system will work with every “fleet” instance having the same name… rmf-web might or might not work correctly, so it might be necessary to override the fleet name with a unique name for each instance
  • When the robot’s payload changes, use the lane management API to change which lanes the robot can enter.

You’ll notice that the lane management API is per entire fleet. That’s why it’s necessary to make one fleet per robot, because otherwise you would be closing lanes for robots that may need to use them.