Posted by @lkw303:
Hi, can I ask if the rmf_traffic’s Planner allows for two robots to be on the same waypoint? I have a scenario where this have happened when I was running a live demo of RMF together with Free Fleet using Turtlebot3s. I am running a Full Control Fleet Adapter. The lanes on the nav graphs are all bi-directional. I have linked a video of this scenario here. (Apologies about the video as I was late to record the live scenario portion, however, the screen record of the RVIZ depicts what was happening prior to that.)
Additionally, I have also experienced this same scenario when the RMF sends a path_request to two robots to the same waypoint on startup.
I would expect that the Planner would not allow this to happen since this would mean a possible collision between the 2 robots? Although, in this case the robots were able to avoid head on collision as their navigation stack prevented it from happening by planning for a path to the next waypoint that avoided each other.
Could you please advice on how I can prevent this from happening, or is there anything that I may be missing out (i.e parameters etc) that is causing this to happen?
Thanks!
Edited by @lkw303 at 2021-08-03T08:05:20Z
Chosen answer
Answer chosen by @lkw303 at 2021-08-03T10:36:01Z.
Answered by @mxgrey:
As of right now there is no mechanism inside of RMF to prevent two or more robots from having the same goal waypoint at the same time. Instead it’s up to system integrators to ensure that the robots aren’t issued tasks that will produce that kind of conflict.
We’re working on a reservation system that will resolve this problem by requiring robots to reserve their goal waypoints. The reservation system will prevent more than one robot from reserving a waypoint at any given time. This reservation system work is on hold temporarily as we have an important milestone coming up at the end of this month which doesn’t require the reservation system, but it will be our top priority again starting in September.
I have also experienced this same scenario when the RMF sends a path_request to two robots to the same waypoint on startup.
This is almost certainly related to the ResponsiveWait behavior which tries to station robots onto their nearest waypoint while still allowing them to give way for other robots that need to pass by. Admittedly it’s a stopgap solution that was not designed well enough to deal with multiple robots trying to wait on the same waypoint. I expect this is another problem that can be resolved using the reservation system (once it’s ready), but in the meantime I recommend always starting each robot on its own designated waypoint.
Posted by @mxgrey:
As of right now there is no mechanism inside of RMF to prevent two or more robots from having the same goal waypoint at the same time. Instead it’s up to system integrators to ensure that the robots aren’t issued tasks that will produce that kind of conflict.
We’re working on a reservation system that will resolve this problem by requiring robots to reserve their goal waypoints. The reservation system will prevent more than one robot from reserving a waypoint at any given time. This reservation system work is on hold temporarily as we have an important milestone coming up at the end of this month which doesn’t require the reservation system, but it will be our top priority again starting in September.
I have also experienced this same scenario when the RMF sends a path_request to two robots to the same waypoint on startup.
This is almost certainly related to the ResponsiveWait behavior which tries to station robots onto their nearest waypoint while still allowing them to give way for other robots that need to pass by. Admittedly it’s a stopgap solution that was not designed well enough to deal with multiple robots trying to wait on the same waypoint. I expect this is another problem that can be resolved using the reservation system (once it’s ready), but in the meantime I recommend always starting each robot on its own designated waypoint.
This is the chosen answer.
Posted by @lkw303:
Hi. Thanks for the prompt reply!
As of right now there is no mechanism inside of RMF to prevent two or more robots from having the same goal waypoint at the same time.
Regarding this statement can I clarify also that RMF does not prevent 2 or more robots from having the same goal waypoint but it prevents two or more robots from using the same lane at the same time?
Instead it’s up to system integrators to ensure that the robots aren’t issued tasks that will produce that kind of conflict.
Regarding this, does this mean that system integrators, in general, should create multiple lanes to allow for robots to have alternative paths to travel on rather than share the same path to get to their destination? Because, it seems that there will always be a possibility of two robots ending on the same waypoint when they are required to share the same path in order to get to their goal.
Posted by @mxgrey:
Regarding this statement can I clarify also that RMF does not prevent 2 or more robots from having the same goal waypoint but it prevents two or more robots from using the same lane at the same time?
To be pedantic, it always tries to resolve “conflicts” which approximately means “situations where the intended motions of two or more robots cannot all be satisfied at the same time”. So robots could share a lane if they are moving in the same direction at the same speed, because there would be no interference between them in that situation. But if two robots try to move in opposite directions on the same lane, then that creates a conflict because the robots are not able to pass through each other.
system integrators, in general, should create multiple lanes to allow for robots to have alternative paths to travel on rather than share the same path to get to their destination?
As a rule of thumb, the more options (alternative lanes) you can give to the robots, the more smoothly they’ll be able to operate around each other. There may be some performance trade-offs if you make an extremely dense graph because that would add many more options for the planner to consider, which could potentially slow the planner down. But I think it would take a somewhat absurd number of nodes and edges for that to become a noticeable problem.
there will always be a possibility of two robots ending on the same waypoint when they are required to share the same path in order to get to their goal.
My expectation is that there are only two situations where a robot will need to “end” on a waypoint:
- The robot is parked, idle
- The robot needs to perform some kind of task (e.g. pick up or drop off an item)
In both situations, no other robot should be allowed to be on that waypoint at the same time. For case (1) the parked robot should park somewhere else. For case (2) the other robot should wait somewhere else until the busy robot is finished with its task.
Right now the traffic system doesn’t have a mechanism for the two robots to communicate this, but the purpose of the upcoming reservation system will be to allow robots to communicate their intentions for the waypoint that they are using so that either (1) they can be told to go wait somewhere else, or (2) other robots can be told to wait until the waypoint is available.
Posted by @PVijayaGanesh:
Hi @lkw303 please help me and provide any resource that how to openrmf on two real turtlebot3 ..
please help me..
