Posted by @cwrx777:
Hi,
What could be the reason that my fleet adapter, based on the python template, quite often gets a follow_new_path request while it is currently executing a follow_new_path request? this causes the robot (MiR) to stop unnecessarily.
Chosen answer
Answer chosen by @cwrx777 at 2023-01-09T14:59:18Z.
Answered by @mxgrey:
There are several possible reasons for a follow_new_path request to come in while your robot is already following a path.
- A conflict was detected so the plan for the robot has changed
- Your python code is not sending progress updates often enough, causing the fleet adapter to think you’ve dropped the follow path request which makes it issue a new one
- Your python code is triggering the
replan API somewhere
- The fleet adapter believes your robot is experiencing substantial delays so it thinks there was something wrong with its old plan and therefore attempts to replan. You can use
fleet_adapter.default_maximum_delay = None to turn this behavior off.
There’s also a known issue that’s being resolved where superfluous replanning is done after the robots resume from an emergency alarm scenario, but that will only happen if the emergency alarm has been triggered.
I can’t offer any meaningful guidance without knowing a lot more about the situation surrounding the unexpected behavior, and I doubt I’ll be able to identify the problem without having access to your fleet adapter code. Are you using fleet_adapter_mir or your own custom implementation?
If you can provide substantially more information about the unexpected behavior, I would encourage you to open a bug report on the rmf_ros2 issue page.
@stella-ccyydy are you experiencing this issue separately from @cwrx777 or are the two of you colleagues reporting the same issue?
Posted by @[Missing data]:
I also met the same issue, expecting answers…
Posted by @mxgrey:
There are several possible reasons for a follow_new_path request to come in while your robot is already following a path.
- A conflict was detected so the plan for the robot has changed
- Your python code is not sending progress updates often enough, causing the fleet adapter to think you’ve dropped the follow path request which makes it issue a new one
- Your python code is triggering the
replan API somewhere
- The fleet adapter believes your robot is experiencing substantial delays so it thinks there was something wrong with its old plan and therefore attempts to replan. You can use
fleet_adapter.default_maximum_delay = None to turn this behavior off.
There’s also a known issue that’s being resolved where superfluous replanning is done after the robots resume from an emergency alarm scenario, but that will only happen if the emergency alarm has been triggered.
I can’t offer any meaningful guidance without knowing a lot more about the situation surrounding the unexpected behavior, and I doubt I’ll be able to identify the problem without having access to your fleet adapter code. Are you using fleet_adapter_mir or your own custom implementation?
If you can provide substantially more information about the unexpected behavior, I would encourage you to open a bug report on the rmf_ros2 issue page.
@stella-ccyydy are you experiencing this issue separately from @cwrx777 or are the two of you colleagues reporting the same issue?
Edited by @mxgrey at 2023-01-07T12:52:20Z
This is the chosen answer.
Posted by @cwrx777:
@mxgrey
Thanks for the pointers.
I’m using my custom implementation of mir fleet adapter based on the rmf demos fleet adapter.
- Your python code is not sending progress updates often enough, causing the fleet adapter to think you’ve dropped the follow path request which makes it issue a new one
How often should the fleet adapter send the progress updates?
Posted by @cwrx777:
@mxgrey
Is the API to set fleet adapter default maximum delay available in the python binding?
Posted by @cwrx777:
@mxgrey
My fleet adapter had a bug that caused next_arrival_estimator never get called.
Posted by @[Missing data]:
@mxgrey I am experiencing this issue separately from @cwrx777 .
And I am also using my custom implementation of rmf demos fleet adapter.
My test scenario is
- robot_1 was added to the fleet a
- robot_2 was added to the fleet a
- submit a go_to_place task for robot_1, request robot_1 to go to waypoint wp_5
- submit a go_to_place task for robot_2, request robot_2 to go to the same waypoint - wp_5
- robot_1 and robot_2 both report their progress 10 times per second
- then, I noticed several conflict negotiation happened, and conflict negotiations were all failed except the last one.
- When conflict negotiation was resolved finallly, robot_1 and robot_2 collided with each other at wp_5.
What I expected is, only one robot can get to the destination wp_5 successfullly, the other robot need to wait until wp_5 was released other than colliding with each other.
Could you please help review the above test case? I wonder whether my target can be met by current rmf implementation?
Posted by @mxgrey:
If you can share your test map with me, I can try to find some time to debug it. Feel free to email me at grey@openrobotics.org if you’re not able to share your map publicly.
Posted by @[Missing data]:
ok, thank you very much, will send you via email.
Posted by @[Missing data]:
hi @mxgrey
Is there any update about the above collision issue?
Posted by @mxgrey:
I have a significant backlog of contracted work that I need to attend to so my time for community outreach is very limited right now. I can’t predict when I’ll have an opportunity to debug your scenario, but I’ll certainly let you know when I’ve done so. I do take bug reports very seriously since it’s extremely important to me that Open-RMF is working correctly.
Posted by @mxgrey:
Actually I don’t need to run any tests for your scenario. I can tell what the problem is from your description.
- submit a go_to_place task for robot_2, request robot_2 to go to the same waypoint - wp_5
This is not currently supported in Open-RMF. Commanding multiple robots to go to the same waypoint creates a traffic conflict that has no valid solution. That’s why the negotiations happen repeatedly and mostly fail. That’s also why they “collide” at the waypoint: they’re being commanded to be at the same place as each other.
We have plans to introduce a reservation system to Open-RMF but that feature is not ready yet. In the meantime system integrators need to take on the responsibility of not commanding multiple robots to the same location at the same time.