Eloquent Features

[ghost]

This is a quick summary of major changes and additions we'd like to make to the navigation 2 codebase in rough priority order. This represents current plans but not commitments.

Major Features

Eloquent

• ROS 1 Use Case Parity
  • SLAM compatibility(Nav2 should work with Cartographer, other SLAM packages #595)
  • Multi-robot compatibility (Support multiple robots navigating simultaneously #971, Problem of using namespace  #746) - @orduno
  • Better recovery actions (Recovery Behaviors Roadmap #953) - @mhpanah
  • Better obstacle avoidance ( if set goal from A to B, navigate will auto stop and robot not arrive expect point #926 and Characterize the navigation reliability - The Office Marathon 2 #929)
  • Support for Realsense with voxel layer ([Costmap 2D] Add a system test that includes the voxel layer #955)
  • Reenable some form of dynamic reconfigure (Re-enable runtime configuration of key parameters #956)
  • Facilitate porting TEB algorithm to Nav 2. (Pluginlib adaptors for Local/Global planning, recoveries, BT nodes #943)
  • Support for holonomic robots (Create system test with a holonomic robot #954)
• Quality Improvements
  • Usability improvements
    • Better documentation
    • Fix / mitigate usability problems related to new architecture
    • Backward compatibilty / nav_core adapters (Pluginlib adaptors for Local/Global planning, recoveries, BT nodes #943)
  • Reliable and robust networking (Reliable and robust networking #985)
  • Fix CI stability problems
  • Better test coverage (Need more extensive system tests #539)
  • Better development processes - helps to include community
    • Discuss and review designs in separate issues prior to submitting PR
    • Review tests and docs for each PR
  • Break out generic BT packages from navigation 2 and put them in a separate repo
• Performance/Determinism Improvements @mlherd
  • Determine network performance limits for topics and services (latency and jitter)
  • Investigate ROS and DDS layer performance bottlenecks
  • Determine nav 2 hotspots and latencies
  • Get navigation 2 running on VxWorks

Future

• Improve error detection and recovery
• Add support for system health monitoring
• Add more output data and logging to support debugging and future quality improvements
• Ackermann robot compatiblity
• Run the nav2 stack on an additional robot @mlherd
• Create real world use cases in Gazebo
• Develop new world model and costmap representation @mlherd
• Multi-robot orchestration
• Update core algorithms and provide guidelines
• Map server enhancements
• Outdoor navigation
• Zone support
• Add test capability to enhance interaction with gazebo
  • Update model and world state
  • Dynamically alter world
• Support for maps with elevation, such as ramps
• Support for use cases with elevators
• Optimize Auto Localization
• Add support for a safety monitor that can run on an RTOS
• Investigate machine learning approaches to navigation
• Provide an example for launching nav2 using composed nodes.

[SteveMacenski]

Comments:

• Frontier exploration, I can say from chatting with folks in industry that many of us have given up on that package from inconsistent at best results, I dont think that needs to be a priority
• I think a tier 1 issue needs to be configurability and run-time definitions before the E release. We can't have hardcoded values for recoveries or not be able to define at run-time proprietary plugins. This is a must to get pro-users involved who don't want to contribute back all their stuff or face an uphill integration
• On the processes bullet, 100% agree. I think there's still a little too much internal discussion in Intel resulting in substantial changes without the opportunity for community input, or a record for the future in decisions, discussions, and explanations in searchable methods

[ghost]

Frontier exploration, I can say from chatting with folks in industry that many of us have given up on that package from inconsistent at best results

Is there a better alternative? I agree this package is probably not that important. Mainly, I want to ensure we haven't broken things to prevent a package like this from working. That and I hate needing to teleop around for a while to create a map :-)

We can't have hardcoded values for recoveries or not be able to define at run-time proprietary plugins

If we make the bt navigator configurable with plug-ins, then anyone can easily create plugins and customize the behavior tree however they like. I thought we had an issue for this, but couldn't find it, so I just added #942. Is this what you had in mind? Is there more you are looking for?

[SteveMacenski]

#942 is on the ball. I wouldn't go the route of generic BT node plugins (for that particular recovery example, but in general, yes, having that would be stellar) because sometimes there's contextually important information that a generic API wouldnt help with, kind of similar to the different pluginlib definitions for recoveries vs planners vs controllers so that they are all passed the right stuff.

For example: I imagine the recoveries in the future looking like a server that is running exposing services, and the main thread of the recovery process will create 1 TF buffer and 1 connection to the costmaps and then pass the pointers to each of the recoveries to use so that we dont have a bunch of these things being made for each individual recovery or relying on a service (!!!) to get the position of the robot at 100hz. These recoveries are defined by pluginlib plugins in a configuration file at runtime, and that name also matches the name in the behavior tree with a <recovery name="name"> tag, so that it loads a generic "recovery" node which creates a service caller (or action, whatever makes sense) to name which is running in the server process with all the over recoveries.

This buys us:

• pluginlib-able recoveries
• runtime definition in the behavior tree of which to run
• robust specific API
• decoupling the BT from the recovery

(And then we can largely start removing some of these action wrappers in the behavior tree that drives me nuts to just the basics: RecoveryWrapperAction, PlannerWrapperAction, ControllerWrapperAction, etc, and clearly add the existing recoveries)

---

Frontier exploration? Nothing open source, and even closed source I haven't heard too many have good experiences. Typically the setup I hear from other companies: map once by hand/remotely -> generate a tree of nodes (ordered waypoints to visit, sometimes by a voronoi diagram, sometimes hand engineered, sometimes other) -> every time you remap, visit those ordered nodes to remap knowing something about the space.
Supplement the initial mapping with a floorplan if available.

How frontier exploration works is just a background algorithm that is choosing positions and telling the navigation stack to go to a place, then issuing a new command. If the action API for navigation stack works so that an application can say "go here", "cancel", "preempt", "now go here" then frontier exploration-like algorithms will work just the same as a waypoint follower or more complex scheduler

[SteveMacenski]

@crdelsey can this be closed because eloquent is out? I think the foxy ticket is the new reference

[ghost]

Yes.