search

ros-navigation / navigation2

ROS 2 Navigation Framework and System
https://nav2.org/
Other
2.48k stars 1.26k forks source link

Eloquent Features #592

Closed crdelsey closed 4 years ago

crdelsey commented 5 years ago

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

Future

SteveMacenski commented 5 years ago

Comments:

crdelsey commented 5 years ago

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 commented 5 years ago

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:

(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 commented 4 years ago

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

crdelsey commented 4 years ago

Yes.