Replanning because of an interruption (#111)

Posted by @RValner:

Hi,

While the robot is following the RMF’s navigation goal, the RMF frequently prints Replanning because of an interruption and makes the robot go back a bit (video).
The robot is simulated via Gazebo on ROS1 Noetic while RMF is on ROS2 Foxy. The RMF repos are up to date. In the video the left Rviz window shows the map, the robot, lidar scan and the global path generated by move_group based on goal sent by RMF. You can see how the global plan changes unexpectedly. The right Rviz window shows the RMF nav graph and the planned trajectory for the task. Each time the Replanning because of an interruption is printed, the yellow dot that represents the robot, dissapears. Also the dot’s location is pretty unstable, going back and forth.

The error could be originating from my setup but I have no clue what is the likely cause for the Replanning because of an interruption. Any help is highly appreciated.

Chosen answer

Answer chosen by @RValner at 2021-11-01T12:13:46Z.
Answered by @mxgrey:

The “Replanning because of an interruption” is a behavior that exists for historical reasons because it’s known to help out with certain edge cases, but it can also cause serious problems (like what you’re seeing), especially when the velocity and acceleration parameters for a robot don’t match up very well with the robot’s actual motion (i.e. if the robot’s actual motion is significantly slower than the velocity and acceleration parameters would suggest).

We intend to make some improvements to the traffic planner so that this automatic replanning behavior is never needed for dealing with any edge cases. At that point we’ll remove this behavior entirely. Until then, you can disable it in your testing by setting the disable_delay_threshold parameter to true (*edited), or you can reduce its occurrence by setting delay_threshold to a much higher value (e.g. 60.0).

Posted by @mxgrey:

The “Replanning because of an interruption” is a behavior that exists for historical reasons because it’s known to help out with certain edge cases, but it can also cause serious problems (like what you’re seeing), especially when the velocity and acceleration parameters for a robot don’t match up very well with the robot’s actual motion (i.e. if the robot’s actual motion is significantly slower than the velocity and acceleration parameters would suggest).

We intend to make some improvements to the traffic planner so that this automatic replanning behavior is never needed for dealing with any edge cases. At that point we’ll remove this behavior entirely. Until then, you can disable it in your testing by setting the disable_delay_threshold parameter to true (*edited), or you can reduce its occurrence by setting delay_threshold to a much higher value (e.g. 60.0).


Edited by @mxgrey at 2021-11-01T13:42:49Z


This is the chosen answer.

Posted by @RValner:

Thanks! That did the trick. Minor remark though, I assume you meant disable_delay_threshold = true not false. Again, thanks a lot!

Posted by @mxgrey:

Correct, I’ve edited my comment, thanks!