Progress and ETA in feedback

[Timple]

For better feedback in our application we would like to know how far the ExePath action is and at what time it thinks to finish.

The dist_to_goal is not useful for this because U-shaped paths will initially have an increasing dist_to_goal value.

Therefor we propose to add these to values to the feedback:

float32 progress  # Progress in distance of the path traveled
time    eta       # Estimated (optimistic) time of path completion

However these values are probably only known to the local planner so the local planner should provide these.

Alternative:

float32  progress  # Progress in distance of the path traveled
duration eda       # Estimated (optimistic) duration remaining

Any comments / suggestions?

[spuetz]

Hi @Timple, I think that would be great! I think one could estimate the current position on the global plan by a radius search. First I would suggest to add the functionality to MBF and later also adding an optional interface to the plugins for these two feedbacks. PRs are welcome, regarding this idea ;) Cheers.

[Timple]

Nice to see you agree. Since it's a little more effort than 'just' extending the action definition I'll put it on our backlog in the separate items you propose. Hopefully we'll get to this soon!

[Rayman]

Nice idea!

The radius search, or closest point of the path to the robot could be implemented without changing the interfaces to the planners and controllers.

[corot]

As stated in #216, we can incorporate this on Noetic. But also I'm planning to include waypoints in the GetPath action. Would make sense to pass the waypoints also to ExePath and provide the reached waypoints in the feedback?

[Rayman]

What is the difference between GetPath with waypoints and calling GetPath multiple times to get a path trough waypoints?

[Rayman]

In general I would try to stick close to the interfaces provided by base_local_planner and the interface of navigation2. That would make it easy for developers (me) to make local and global planners that work in multiple frameworks. This way we have a backup when move_base_flex doesn't provide a feature or the way around.

I see that navigation2 has a FollowWaypoints.action. Is that the same idea? I have not that much experience with navigation2 but I would be curious to try it soon.

[corot]

What is the difference between GetPath with waypoints and calling GetPath multiple times to get a path trough waypoints?

That's why we didn't include the waypoints in the initial version. However, I have found that in some cases you really want waypoints:

• Smoothing and checking for collisions a rough sparse plan (typically coming from a sparse graph)
• Allow the planner to roughly follow the given waypoints (e.g. within path_tolerance), without reaching each exactly.
• Even if the path must pass by each waypoint, you probably don't care about the orientations. If you stitch together paths from multiple calls to GetPath, yo must impose the orientation at each waypoint (or have discontinuities that will require rotations in place).

But in any case, using the waypoints will be optional (and most planners will simply ignore them), so it will make no difference if you don't want the feature.

[corot]

I see that navigation2 has a FollowWaypoints.action. Is that the same idea? I have not that much experience with navigation2 but I would be curious to try it soon.

Not exactly the same, as I'm thinking in ExePAth getting both a smooth path as now plus some sparse (optional) waypoints. But maybe a new action like that FollowWaypoints makes more sense. I have exactly the same usecase. By now I go on with ExePath and provide the current waypoint in the feedback message, what is rather hacky.

[artemiialessandrini]

• Any ideas on how to get the best radius for the searching area? Could it be computed based on path_distance_bias param?
• Also what about uncommon controller's trajectories such as a teb_planner backward "parking"?
• Finally, do we need to have a prediction based on the previous state to speed up the thing?

I'm trying to make it up in Python and facing those questions

[Timple]

Also what about uncommon controller's trajectories such as a teb_planner backward "parking"?

This is exactly why I would leave this feedback up to the local planner. That one knows best. And if the local planner thinks a radius search is the best estimate, it can be implemented there.

[corot]

I was thinking in a very crude, best case estimation, like remaining path length / current linear speed. Otherwise, it will be NaN most of the times, as commonly used controllers as DWA don't implement MBF interface, much less this ETA. But we can always provide a means to the controller to replace with a better estimate.

[artemiialessandrini]

Regarding ETA, there are also some special cases, such as Restrict max velocity of the robot based on the robot position #905, which is based on a costmap.
Not sure whether it can be taken into account.

[Timple]

@corot A best-effort default is better than NaN, I agree!

@artemiialessandrini We have also velocity restrictions for our planner (both internal as external). The internal ones we can account for, the external once not. That is why we are suggesting an ETA and not a TA :slightly_smiling_face: My first impression is that such a map will be hard to account for and out of scope for this feature.

[reinzor]

I was thinking in a very crude, best case estimation, like remaining path length / current linear speed. Otherwise, it will be NaN most of the times, as commonly used controllers as DWA don't implement MBF interface, much less this ETA. But we can always provide a means to the controller to replace with a better estimate.

+1 , something similar as https://github.com/ros-planning/navigation/blob/melodic-devel/base_local_planner/src/goal_functions.cpp#L96 can be used for this default + base local planner limits. :).