| ROS Resources: ROS Homepage | Media and Trademarks | Documentation | ROS Index | How to Get Help | Q&A Help Site | Discussion Forum | Service Status |
Posted by @osama-z-salah:
@mxgrey Thanks for your response. I was wondering if there’s a workaround for this issue. My robots have significantly different lengths compared to their widths, and I have limited space where they can move parallel to each other in adjacent lanes. However, they cannot rotate simultaneously due to space constraints. Instead, one needs to wait until the other finishes rotating before it can follow and rotate.
Posted by @mxgrey:
I’ll be upfront with you… You have a very difficult situation to manage here.
Even if Open-RMF’s traffic planner could correctly account for these geometries, Open-RMF doesn’t have total control over the trajectories of the robots. If the robots are AMRs with on-board navigation that uses cost maps, they can arbitrarily decide to swerve to avoid obstacles or minimize cost. They might rotate at any time to relocalize. Those behaviors will involve significant rotation and they may do it without Open-RMF commanding them to.
If your passage isn’t wide enough for two robots to rotate while they are side-by-side then the navigation system may pose a risk to the robots any time they’re side-by-side. I can make some different recommendations which will depend on the characteristics of your space and your robots.
You really can’t risk them passing side-by-side in the same corridor. There are two options will will both depend on what kind of space you’re working with:
You could use mutex groups on the lanes that go through the corridor so that only one robot goes through at a time. You’ll need to identify waiting areas for robots where they can pull aside and wait for the passage to open up while leaving enough room for other robots to pass and turn. These openings might or might not be available to you, which could make this approach ineffective.
It might look something like a roundabout at each junction, like the picture below. Each color represents a different mutex group. Each of the dots is somewhere that the robot is able to rotate without collision.
The specific picture set up here can work for up to three robots per intersection. More than that and there’s a risk of total deadlock. Other arrangements of lanes would be needed to support more robots.
This strategy will be very disruptive if you want to have high robot throughput (many robots operating in a small space). Unfortunately this would even prevent robots that are moving in the same direction from sharing the passage.
You could make every hallway one-way. If you have enough of a grid-like hallway then you can make sure there are ways for the robots to do U-turns or loop around as needed. In the picture below, each lane is one-way and the dots represent points where the robots can wait and turn as needed.
Robots that are moving in the same direction can share the same passage, which would eliminate the risk of deadlocks at intersections.
If you are able to tune your AMR so that it behaves more like an AGV inside of these narrow passages then you can consider the advice in the next section. Behaving like an AGV means it will follow a straight line very precisely and stop for obstacles instead of swerving.
If you can count on your robots to only follow straight lines when commanded along a straight path, then you may be able to have two one-way lanes per passage as you intended. However you’ll need to use mutex groups at the junction and plan out the turning points to make sure they’re spaced out sufficiently.
Below is a graphic of how this could work. Blue lanes/vertices are all part of one mutex group, so only one robot can enter the intersection at a time. Orange lanes/vertices do not belong to any mutex group.
Pay careful attention to the spacing of the blue vertices, every detail is intentional. Each orange lane that leads into the intersection is connected to each blue vertex in a way that allows the robot to proceed down any hallway without needing to turn in the vicinity of another robot.
Leading up to the intersection you can have a series of orange vertices to let robots queue up to enter the intersection. This is optional but recommended if you expect the intersections to get crowded.
Note that every lane in this graph is one-way, which helps ensure the robots will follow the exact path that they need to.
This graph configuration will give the best traffic flow out of any of my recommendations, so this should probably be your top choice. Just bear in mind the requirement that the robots must follow straight lines very consistently.
Posted by @osama-z-salah:
@mxgrey thank I really appreciate your help
