Posted by @[Missing data]:
Hi @mxgrey
Please consider the following scenario:
I have two robots A and B in the fleet
- submit a task to A , from P4 to place P13
- submit a task to B, from P6 to place P18
- P17 is the T-shaped intersection of the two scheduled itinerary
- Sometimes, my adapter will detect that there is a risk that A and B maybe collide at P17, so it will stop A and B by itself in advance. That is to say, the stop command is not from RMF but my adapter itself.
- Then, after commanding the two robots stop, my adapter will wait for the next follow_new_path from RMF.
In this case, the next follow_new_path will come after about 10 seconds. I wonder why RMF will delay so long time to send next command. Is the 10-seconds value configurable?
In addition, could you please explain how max_delay affects the traffic plan?
max_delay # allowed seconds of delay of the current itinerary before it gets interrupted and replanned
In fact, I change its value as 5, 10 ,15 respectively, it seems there is no difference.
Thanks
Stella
Posted by @mxgrey:
In this case, the next follow_new_path will come after about 10 seconds. I wonder why RMF will delay so long time to send next command. Is the 10-seconds value configurable?
The 10 second delay is a last resort retry if it seems that your integration code is not responding to the last command it was given. The assumption is that such a long delay means the integration code has a bug that has caused it to lose track of the previous command entirely.
If you have a specific reason that you want RMF to issue a new plan or a new path command to your robot then you can trigger replan (Python, C++) on your update_handle at any time. You shouldn’t call this function too frequently or else it could be disruptive to normal traffic flow. But the case you’ve described, where another system has detected a problem with the traffic and that a new plan is needed, is exactly what this function is meant for.
Posted by @[Missing data]:
The 10 second delay is a last resort retry if it seems that your integration code is not responding to the last command it was given.
When you say the integration code is not responding to the last command it was given, do you mean the integration code do not call
next_arrival_estimator to respond the duration to the next arrival
or
path_finished_callback to respond that the given path is finished
In fact, when my adapter stops the robot itself, it does do not use next_arrival_estimator or path_finished_callback, just return and finish _follow_path thread.
Posted by @mxgrey:
I mean both. But you absolutely should NOT call path_finished_callback if your robot has not reached the end of the path because that would create severe confusion in the task management.
The current API is not tailored to the use case you’re describing, but you could spoof it by periodically calling next_arrival_estimator as if your robot is heading to the next waypoint but stuck at its current distance from the waypoint (arrival time = distance / velocity). Then when you think it’s an okay time to replan, call the update_handle.replan() function.
I’ll keep this use case in mind as I design the next generation of the API. I should be able to make this much easier and cleaner with a new API.
Edited by @mxgrey at 2023-05-22T10:00:15Z
Posted by @mxgrey:
Or a cleaner approach might be to use update_handle.interrupt to pause the task and then use unstable_declare_holding to say that the robot is standing in place. Just make sure that when you use interrupt, you hold onto the handle that the function returns until you’re ready to resume. Once you’re ready for the robot to continue, just delete the handle and the fleet adapter will automatically replan based on the latest traffic conditions.
Posted by @mxgrey:
could you please explain how max_delay affects the traffic plan?
The value given to set_maximum_delay is no longer being used. It used to trigger a replan if a robot was experiencing significant delays, but we removed that behavior when we introduced the traffic dependency system because the maximum delay behavior was causing more problems than it solved. We might resume using the parameter in a more intelligent way in the future, but for now it won’t have any effect.
