As the outcome of #2174, we should have an analog server using the work of #1595 to allow for "route planning" versus "freespace planning" that the planner server enables.

For indoor applications like warehouse and service robot applications, you're in largely planar space. It makes alot of sense to work with an occupancy grid for planning in these situations since you're typically using 2D or 3D SLAM that can be easily formatted in this way. Then you want to do freespace planning from any A to any B. This is often required as you're going to really different places all of the time.

For larger scale outdoor applications, this is very different. A delivery robot in San Francisco doesn't want to work in cartesian coordinates of a map (navigate from 403432, 4302432 to 90655498, 430200), but GPS or a route graph made up of the city streets. "Freespace planning" like what the planner server via grid costmaps and search algorithms aren't the right way to go (even if you could have an occ grid of all of san francisco, it would be memory inefficient to store it, it would constantly need updating, and planning in it would be very slow). Most of the time, its going to be via GPS or VSLAM which don't provide you this occupancy information even if you wanted it. So instead, we plan using routes just like Google Maps provides to accomplish your mission (or via other pre-defined via points / semantic labels).

Instead, we should allow users to use their semantic representation of the environment (GPS, pre-defined route graphs, city route graphs, etc) to plan a route for the controller server to follow. So rather than a plan built off of a searching algorithm on a gridmap, these will be routes built from the semantic navigation graph.

For the controller, this is no different than before, it still seeks to follow a path/route. But now the route is computed via this semantic method versus a freespace map. In this case though, having a dynamic obstacle avoidance local planning system is more important since the route doesn't take into account any of the current information about that area (nor could it with costmaps anyhow from 2 miles away). So that controller should be able to avoid things locally to continue to progress along the route.

This will enable VSLAM, 3D SLAM, and GPS systems to plan in all-terrain and urban environments and use the Nav2 system where it is not possible now. The use of height maps in #1278 would also aid in general out-door navigation for the local planner server, but keep in mind that if you were working on a national-park scale or a city scale environment, you would still not have a global height map of the space the same way you could not have the grid occupancy map from SLAM. Thusly, this is useful for enabling all-terrain outdoor local trajectory planning and control but this route server is required for route and path planning regardless if the height map solution is available currently.

The completion of this ticket and #1278 represents a full solution to indoor, outdoor all-terrain, outdoor urban, and mixed use navigation system design whereas (assuming a valid SLAM/localization solution is available like Visual, 3D and 2D):

• Indoor: costmap local representation + planner server with costmap representation
• Outdoor Urban: costmaps or height maps (dependent on how planar) local representation + route planner
• All terrain: Height maps local representation + route planner
• Mixed use: route planner + planner server running simultaneously for each situation called out in the behavior tree.