Clarify the semantics of if timestamps in nav_msgs/Path

[tfoote]

This is a follwup to the pre Foxy Message API review

Path message is stamped, but each individual pose is also stamped. It's unclear what each stamp means. Is the stamp in each individual pose for the time the robot needs to be at that location? If so, the frame_id that's in each individual header is still redundant with the frame_id on the Path message itself. However, stamping each individual pose seems inflexible to the robot being delayed. If it's slowed down mid path, should it target the pose at the current time, or the next closest to it's current location? This seems hard to answer if the path makes a loop such that two points on the path are physically close but far apart in time. For a little while nav2 had it's own version of Path which had non-stamped poses, though they removed it: https://github.com/ros-planning/navigation2/pull/1107/files#diff-2d8dabb75c11aa980f6c2629eba1e75f

Iterate with navigation to improve documentation of semantics of timestamps. Note that there are multiple valid behaviors for any given path representation.

[tfoote]

@SteveMacenski @mikeferguson Could you take a look at this?

[SteveMacenski]

Path message is stamped, but each individual pose is also stamped

Indeed, This could be interpreted as a temporal waypoint to achieve in some timeframe. It could also be interpreted as a time delta (between wp 105 and 106 your goal is 10ms to be consistent with the plan that presumably has some time-varying obstacle tracking in the formulation). If you fall behind, its not a critical failure necessarily if everything are deltas and you recompute the path on a somewhat regular basis. As one should in a sufficiently dynamic environment that you need a planner making use of those timestamps. I just glanced super quick through my list of known plugins and found one (https://github.com/marinaKollmitz/lattice_planner/blob/master/src/tb_lattice.cpp#L736) that makes genuine use of the timestamp. I don't know of any others but where there's one, there's many. Anything with keywords on dynamic, sampling, or tracking I suspect will make use of it if its well engineered.

For a little while nav2 had it's own version of Path which had non-stamped poses, though they removed it

Yeah, I suspect the Intel folks weren't aware of the nav_msgs (or wasn't released into ROS2 when they started) so they made a bunch of redundant messages. I'm still removing some every now and again when I have some cycles for pedantic work. nav2_msgs should be deleted by the end of it, any remaining actions should be put into nav_msgs long term once we've settled out the API a little more. I'm still adding new feedback or result items now and again. I think of common_interfaces as being relatively static so that may be a little ways away still (H-turtle, perhaps).

header is still redundant with the frame_id

Agreed, I can't think of any particular reason why I'd need to change frame id's across a path. I suppose they could be daisy-chained (each point in the frame of the last) or a planner that assembles sub-results from multiple planners for different parts of your environment. Both could be transformed in the plugin prior to returning it in 1 frame. I'm OK with removing this part.