Vicinity and Footprint

[cwrx777]

With reference to this, I have a few questions:

1. Does open-rmf currently support changing footprint after initialization, or during task execution, e.g. after the AMR picks up a shelf, there'll be an increase in footprint, and after drop-off, the footprint will decrease.
2. Consider AMR with size of 600 mm x 900 mm. Due to space constraints in the charging room, AMR manufacturer allows that the AMRs are placed about 200 mm with each other. Even if the vicinity is set to 450mm (the length of the AMR), this will be considered as collision. Is there a workaround to avoid the AMRs from being de-conflict when they are at charging stations?

[mxgrey]

Theoretically the footprint and vicinity can be modified at any time by sending a new ParticipantDescription in a RegisterParticipant request to the rmf_traffic/register_participant service. When a participant with the same name as the description has already been registered, this service request will just update its values, including the footprint and vicinity.

We have tested and confirmed that the service request correctly updates participant information when restarting a fleet adapter, but we have never tested the result of using that service request in the middle of performing a task, which is why the rmf_fleet_adapter API does not provide a stable API for changing those parameters. However there is nothing to stop you from using this service request manually in your fleet adapter integration code.

One issue you might need to watch out for is that changing these parameters could mean that the existing traffic plans for your robots are no longer valid or no longer optimal, and the traffic schedule would not recognize that because it only checks for conflicts when a new plan comes in. If you manually send that service request, you should also manually trigger the RobotUpdateHandle::replan function for the robot whose values you are changing.

[osama-z-salah]

between boxes and circles moving along splines

Hi @mxgrey , does this mean that if I only use boxes, it will work correctly? Is the issue only occurring when combining circles and boxes?

[mxgrey]

Is the issue only occurring when combining circles and boxes?

The investigation happened quite a few years ago at this point so I don't remember for certain.

But I wouldn't be surprised if there are subtle issues with box-box collisions as well. Even circle-circle collisions needed fixes, which is why we have a fork of fcl in the rmf_traffic repo.

Given the risks involved, we're going to stay locked into only circles until we can introduce a new collision library in the next generation.

[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.

[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.

If your robots are AMRs (navigate around obstacles, do their own path-finding)

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:

1. Mutex groups

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.

2. Separated grid traffic flow

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.

3. Tune your AMR to be like an AGV

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 your robots are AGVs (follow straight lines, do not deviate from their paths)

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.

[osama-z-salah]

@mxgrey thank I really appreciate your help