Hello @webvenky! good question and insights, I will try to answer this to the best of my understanding, feel free to correct me, especially when navigation is involved.
The navigation graph that houses the waypoints, are generated using the traffic_editor and building_map_toolspackages in https://github.com/osrf/traffic_editor. This allows users to draw up their environment starting from a 2D floor plan, populating it with walls and models to best represent the real physical environment. With a close-enough representation of the real environment, lanes and waypoints can be placed in areas where the robots can navigate, while being mindful that lanes don't intersect with any existing furniture, for example. This allows users to generate a perfectly viable global navigation graph without a cost map.
The global graph of waypoints and lanes are used for robot traffic monitoring and resolving conflicts or dead-locks that may arise between robots or fleets of robots that are unaware of each other's presence, you can take a look at https://github.com/osrf/rmf_core. It is not meant to be used as a global planning graph for any single fleet of robot. RMF assumes the various robots or fleets are using their own fully-functional navigation stacks to do global and local planning, while nudging them out of the way of each other ahead of time whenever conflicts will arise in the near future.
The slotcar plugin allows us to simulate the motion and behavior of robots without worrying about the navigation stacks that might be running under the hood of different vendor robots. This will also allow us to run large scale simulations without being bogged down by large number of sensors and multiple navigation stacks running on that single machine.
If users are keen on running their own navigation stacks on simulated robots, I believe navigation2 is a good option to start with, I have had good experience with it on Turtlebot3s.
Great question - I'd also like to know a little on this. On the planner side, from what I'm aware, it is routing through an annotated graph, so you shouldn't need a freespace planner. I think you'd just need a controller to follow the path and avoid obstacles. In practice it would be wise to still use a planner with soft constraints on the route for large obstacles a controller isn't well suited to handle, but good enough for a first order demo (especially in simulation).
We on the navigation side in ROS2 are looking at annotation methods and formats so this may be something to consider if we can get support to do some integrations.
@stevemacenski Thanks for your quick response. It's a good idea. I also understand your point about a planner with soft constraints on the route for large obstacles. We'll think about it. Suggestions/packages in that direction, if any, are welcome.