The following are a list of known possible improvements or extensions of the Nav2 Route Server that I would like the community and/or users of this work to help implement for their own application needs.

1 Provide a 'force to go through these edges' capability

Its been requested in the requirements section of this work to make it possible to force the robot to go through certain edges as part of its routing solution.

2 Stop / clearance / Shared Resouch Lock -- Open-RMF inspired

Have an option to set clearance for each edge for lock-outs of shared resources. Right now, we can implement this using the DynamicEdgeCost service in the EdgeScorer, but there are probably some good add-ons for full feature parity and/or providing a service client util for submitting and modifying these for a fleet in an easy way.

Then we can lock the current and next edge for each robot to deconflict resources

3 Show lanes effectively implemented using this feature, with demo

This work can be used for creating lanes for the robot to stay within. Show a demonstration of this with the lanes being marked by edges in the graph and the metadata containing the maximum distance it is permitted to be away from the centerline as the lane's width. Use this in conjunction with the BT to ensure enforcement of this constraint. Maybe a costmap layer to demark the max deviation boundaries from the route to prevent over-deviation and/or a controller server critics that calculate this offset and prevent it instead in the formulation. Might also be useful to have local goal for the nodes for achievement knowledge of controller algorithms as part of the controller server API.

Could show the "extreme" version of this with the grid-QR code based solution.

4 Built in path / route turning radius at intersections

Rather than post-processing the route path with the smoother server, it would be ideal to have the server provide a minimum turning radius option to make turns use a fixed turning radius to smooth out turns when closely tracking the route graph.

Completed. Thanks @alexanderjyuen !

5 Dynamic parameter handling

This is relatively straight forward: allow use of dynamic parameters, taking care to mutex lock resources so that changes cannot happen during an active request.

6 Edges have non-straight paths.

Its been requested to have the edges be non-straight paths to symbolize more complex features. This can be implemented with a metadata field of the path and/or vectorized representation. When we reconstruct the route path and/or during Edge Scoring, we can use this path to construct the path to take and compute the length for scoring, respectively. We just need to take care to properly transform it into the current frame or make conventions about how these are represented.

7 Persist blocked edges between calls and the timemarker between sessions

Discuss solutions to persist some data between planning requests and/or sessions. Things like the time markers of how long it takes to go through an edge for later improved scoring or the blocked state of certain edges may be nice to persist for more than a single task request.

Also, be able to set blocked edges on a request (maybe return blocked edges from the last iteration to send in the future and grow as needed)?

We have dynamic edge scoring plugin, perhaps have the operation manager and/or a new operation plugin to send the service to set the blocked edges for later replanning? And a BT Node for clearing them all / specific ones? If the persisting blocked edges route operations plugin is present, do that until manually cleared.

8 Demo showcasing ComputeAndTrack route option, not just ComputeRoute

Basically the same as the 2 demo BT XMLs in the nav2_bt_navigator package, just now with route operations to do something during the task, like change speeds and handling the fact that that server is long-running like the controller server.

9 Tutorial showing how to add route operations to the geojson file and create the new route operation plugin to use that metadata

Related to above, also show how to edge a graph file to include a custom route operation, write that route operation, and show it at work so folks can more easily extend this work to their application specific needs

9 Blocked Route Bypass Only Obstacle

Right now, it is easy to bypass a blocked route either by rerouting around the obstacle or by switching to freespace planning to the next node and then resuming the route (using a behavior tree). However, it would be nice to be able to bypass the route only for the obstacle as needed and then return to the route as early as reasonably possible in case the next node is far away for sparse graphs.

So, it would be good to be able to estimate the blockage and free space plan around the obstacle only until X meters after the obstacle on the route to continue tracking (and this can be estimated online to update with new information about the obstacle's size and shape). This could be either a freespace plan or a trapezoidal off path->around obstacle->back onto path shape deviating the route edge to keep some clearance from the obstacle.