Add costs to path

[jwallace42]

Hello,

I have been doing some work on the nav2 stack @SteveMacenski and I wanted to add in a cost attribute to the Path.msg.

This change will help ros-navigation/navigation2#2880.

Cheers,

Josh

[SteveMacenski]

float32, not ints!

[tfoote]

Following an offline discussion with @SteveMacenski I just wanted to capture some planned followups for this.

To make the case for updating this message we'll need the following:

• The updated data needs to stand on it's own semantically, with a clear type and be well documented. Potentially even having a data structure to capture different types of costs/scoring. Such that the message data will stand on it's own without knowing the context in which it was generated. Aka introspecting a rosbag recorded on a robot by someone else at another time.
• An analysis of the impact on current users. Paying attention to overhead, as well as any required usage changes and/or migration guide. As well as fallback behaviors for unset values.
• And a functional demonstration of using the new variation to make sure that we are confident that it will work for the designed use case.

[SteveMacenski]

We'll circle back in the coming weeks on this.

The only mention worth of note is that since this message is so central to Nav2, it is impossible for us to merge in a solution that would depreciate this message in order to show case a demonstration of its use in the main branches. To temporarily replace nav_msgs/Path in rolling with a nav2_msgs/Path would instantly break hundreds of users application-level software that relies on Nav2, and only for a short while during the process of these changes rae being analyzed.

The hot-swap of a new nav_msgs/Path would not have this effect since we would not make any API breaking changes to existing users' use of this message: simply adding a new field.

So I suggest the following: We will create a practical and necessary application of the changes we will later propose to add costs to the Path message, but it will have to be reviewed as a pull-request that would be merged in tandem with the merging of the message modification. I'll wait to poke back on this until we have not only the PR but an approved PR that is ready to be staged to production, so there is no misunderstanding that they are immediate and necessarily tied PRs (e.g. so there's no delay in changes here resulting in an instance of use of it). This will make sure that (1) you can see a use case of it for review, (2) immediately once this is merged, that will also be merged to use it and (3) we break as few people's systems as possible.

Does that seem fair / doable?

[tfoote]

Yes, the demonstrated use of the enhanced message would not need to have been merged to allow review of the message. It can still be staged on the branch or branches ready for a merge once this is approved and merged. And hopefully with this being an extension only it can be managed to land in a way that does not break systems in the intermediate state either. But we should be giving high visibility warnings of the changes when it is landing if there's any potential breakage on rolling.

[tfoote]

Since this is still under iteration I'm going to move this to draft status so that it doesn't appear on our triage lists.

[jwallace42]

We have completed a use case for the message change here. ros-navigation/navigation2#3100.