The robot stop-and-go when its traffic plan is conflict with the other robot (#384)

Open-RMF Open-RMF General
1

Posted by @[Missing data]:

Hi, @mxgrey

Considering the following scenario:

  1. robot A is moving from SU to C1，robot B is moving from T64 to B3
  2. robot A starts off firstly，robot B followed with robot A

The scheduled traffic for robot A is : SU->T1->T2->B1->B2->B3->T4->C1
The scheduled traffic for robot B is : T64->T1， T1->B1, B1->B3

I wonder why RMF always gave segamented-path to robot B, which made robot B stop-and-go.

Thanks
Stella

map
map1219×916 263 KB

2

Posted by @mxgrey:

We do know about this less-than-ideal behavior, and I have plans to fix it for the next generation of RMF. The main hold up is that the current stabilized API for fleet adapters doesn’t have a good way of communicating the idea of “Follow this line, only up to [here] until/unless I give you a signal that you can proceed”.

There is a risk that if robot B is told to simply travel T1 → B1 → B3 right away then it could collide or pile up with robot A, which is traveling along that same path ahead of robot B. Instead we tell it to move up incrementally and then each time the robot finishes part of the path, we can check if the rest of the path is clear.

In the next generation of RMF I’m planning to offer an API which is more similar to the VDA 5050 spec where you will be given a full path with checkpoints along the way that can change from being closed to open. If a checkpoint is closed while you’re approach it, then the robot needs to come to a stop. If the checkpoint is open then you can keep moving. Most robot vendor APIs that we’ve come across don’t support this kind of communication, but any mobile robot platforms that are compatible with VDA 5050 should have an easy time.

For now, it may be possible to improve the behavior with the existing API. What I could do is issue a new path command each time the fleet adapter receives confirmation that the path ahead is clear instead of waiting for the robot to reach the last command’s endpoint before checking. Do you think this kind of command interruption approach would work for your platform, or would it be equally disruptive? Different mobile platforms respond differently to incoming commands, so I’m not sure if this would be an improvement for all of them.

3

Posted by @stella-ccyydy:

Do you think this kind of command interruption approach would work for your platform, or would it be equally disruptive? Different mobile platforms respond differently to incoming commands, so I’m not sure if this would be an improvement for all of them.

Yes, this kind of command interruption approach does work for my platform。 :slight_smile: Any time one new follow_new_path command is received, the robot will discard the current path and apply the new path immediately.

Edited by @stella-ccyydy at 2023-08-21T09:55:42Z