[Feature request]: Add a name field to Waypoint.msg

[chianfern]

Before proceeding, is there an existing issue or discussion for this?

• I have done a search for similar issues and discussions.

Description

Should Waypoint.msg include an optional field to identify the waypoint?
A name or id field would describe the location represented and remain stable when a map is updated.
Without a name, systems that need to associate waypoints with named locations would have to maintain a separate lookup table based on float coordinates.

Implementation Considerations

No response

Alternatives

No response

Additional information

No response

[arjo129]

Thanks for the suggestion! I can definitely see how stable IDs are useful for higher-level state machines and fleet management.

However, I have some concerns about adding this directly to Waypoint.msg. Because Waypoint.msg is heavily used in Plan.msg for free-space planning, adding a name field introduces a few issues:

1. It forces the plan server to take on the logic of tracking and managing string names, which breaks separation of concerns.
2. If a physical location shifts, a replan is required anyway, so the planner still needs the updated float coordinates regardless of the name attached to them.

Architecturally, it usually makes sense to keep semantic mapping (names/IDs) in a completely separate translation layer that feeds coordinates down to the geometric planner.

Could you share a bit more about the specific system or lookup problem you're running into? There might be a way we can support your use case through a higher-level package without changing the core message structure.

[Briancbn]

Could you share a bit more about the specific system or lookup problem you're running into? There might be a way we can support your use case through a higher-level package without changing the core message structure.

This is for interacting with a VDA5050 robot. VDA5050 order accepts Node with name / id being necessary and x, y coordinate being optional (version 2.x, section 6.6.6). We need a way to map the waypoint back to name or id without losing information from the graph.

Thanks for the discussion yesterday, after some investigation, we realized that there is TargetNode within arrival_constraints(DestinationContraints) which is available within the Waypoint message. There is a GraphElementKey inside the TargetNode that we can utilize for IDs. We can try with that first to see if it is sufficient. No actions needed here.