Posted by @gmchoi96:
There seems to be a delay when multiple robots have overlapping paths. Is there a way to reduce or improve the delay?
delay.webm
Edited by @gmchoi96 at 2024-10-17T00:42:04Z
Chosen answer
Answer chosen by @gmchoi96 at 2024-10-18T06:03:04Z.
Answered by @mxgrey:
There are two major factors that cause the traffic system to struggle:
- Density of robots (not just the number of robots but also how frequently they will interfere with each other)
- Low affordances (not providing the robots with ways to avoid or escape conflicts)
The demos you’re showing are a higher density than we’ve been targeting until now, but the grid structure gives the robots a lot of affordances, so it might be workable. I’ll offer some general advice that might help clean up the behavior:
- For waypoints that robots will use as destinations (i.e. points where you’ll explicitly command a GoToPlace) it’s best to make the waypoint a leaf node in the graph so that robots don’t want to drive through it while other robots are sitting there. If it can’t be a leaf node then you should give it a mutex group. I think this should probably fix most of the collisions, although I’m pretty confused about why the simulated robots are colliding since they’re supposed to be able to see each other in the simulation and do an emergency break before making contact. I’m guessing you might have disabled or severely reduced the threshold on that because of how tightly packed the lanes are?
- In such a tight grid setting you’ll want to reduce the
lane_merge_distance parameter to be about half of the distance in between the lanes of the grid. I believe the default value is 1.0m. This should fix the diagonal movements.
There are probably fancier patterns you could try with the lane directional constraints to get smoother traffic flow, especially if you know something about which waypoints will typically be task destinations. But realistically this scenario is pushing past the limit of what kind of robot density we have tested the current generation of Open-RMF against. To make this work nicely you’d probably have to spend significant time on designing the traffic flow or wait until we’re rolling out the next generation fleet adapters with the more advanced MAPF algorithms.
Posted by @mxgrey:
This scenario is reaching a complexity level that pushes the rmf_traffic library to its limits. We’ve developed a new mapf library that will be able to deal with this scale, but that’s going to be part of the next generation Open-RMF which is still a work in progress.
In the meantime, while you’re using the current generation of Open-RMF, the best way to help this scenario work better is to put directional constraints on the lanes. For example if the vertical lanes alternate between only going up and only going down while the horizontal lanes alternate between only going left and only going right, then the planner will be able to find solutions much faster.
You can think of it like how streets are designed in the real world: Traffic flows better when all vehicles are moving in the same direction.
Posted by @gmchoi96:
I tried the method you suggested and it improved a lot. However, it causes various problems such as delay, diagonal movement, stopping, collision, and path deviation…
Running complex scenarios with multiple robots requires more development, right?
Or is there a way to improve the current situation?
collision.webm
diagonal_movement.webm
off_course.webm
Posted by @mxgrey:
There are two major factors that cause the traffic system to struggle:
- Density of robots (not just the number of robots but also how frequently they will interfere with each other)
- Low affordances (not providing the robots with ways to avoid or escape conflicts)
The demos you’re showing are a higher density than we’ve been targeting until now, but the grid structure gives the robots a lot of affordances, so it might be workable. I’ll offer some general advice that might help clean up the behavior:
- For waypoints that robots will use as destinations (i.e. points where you’ll explicitly command a GoToPlace) it’s best to make the waypoint a leaf node in the graph so that robots don’t want to drive through it while other robots are sitting there. If it can’t be a leaf node then you should give it a mutex group. I think this should probably fix most of the collisions, although I’m pretty confused about why the simulated robots are colliding since they’re supposed to be able to see each other in the simulation and do an emergency break before making contact. I’m guessing you might have disabled or severely reduced the threshold on that because of how tightly packed the lanes are?
- In such a tight grid setting you’ll want to reduce the
lane_merge_distance parameter to be about half of the distance in between the lanes of the grid. I believe the default value is 1.0m. This should fix the diagonal movements.
There are probably fancier patterns you could try with the lane directional constraints to get smoother traffic flow, especially if you know something about which waypoints will typically be task destinations. But realistically this scenario is pushing past the limit of what kind of robot density we have tested the current generation of Open-RMF against. To make this work nicely you’d probably have to spend significant time on designing the traffic flow or wait until we’re rolling out the next generation fleet adapters with the more advanced MAPF algorithms.
This is the chosen answer.
Posted by @mxgrey:
But in any case these scenarios will be good for us to test against as we build up the next generation capabilities. If you’re willing to create a repo and share them with us, we’ll be happy to run tests against them when the time comes.
Posted by @gmchoi96:
thank you for your reply @mxgrey
If it can’t be a leaf node then you should give it a mutex group. I think this should probably fix most of the collisions, although I’m pretty confused about why the simulated robots are colliding since they’re supposed to be able to see each other in the simulation and do an emergency break before making contact.
I would like to use the suggested method for referenced mutex group, but I cannot add the mutex property to my traffic-edditor. Was it added recently? Should I install a new version of traffic-edditor?
But in any case these scenarios will be good for us to test against as we build up the next generation capabilities. If you’re willing to create a repo and share them with us, we’ll be happy to run tests against them when the time comes.
I understand that the scenario requires more than the limits of the currently developed RMF.
Currently, i’m temporarily checking whether our scenario can be applied to rmf, and if further development is needed, we will organize and share the repo at that time.
