Implementation of nav2_bt_waypoint_follower

Navigation Stack
1

Hello everyone!

Our team is moving towards using Nav2 for our autonomy system, and i like to know how far in development is the nav2_bt_waypoint_follower package. I have tried on my own to use NavigateToPose action node but i could not get it to work. Is there some working repo that I can build upon and try to help with the development on it.

2

Hi!

I’m not sure what you’re referencing with nav2_bt_waypoint_follower, something of that name isn’t in our roadmap or described in our ticketing system. You’d have to clarify what you mean by this to see if there are others in the community that might be open to collaborating with you to develop something new!

I suspect you mean just having a behavior tree XML that does waypoint following - which would not require a new package - that’s just a new BT configuration :slight_smile: I’d recommend looking over the resources that Davide has provided https://www.behaviortree.dev/ and this fantastic overview of behavior trees [1709.00084] Behavior Trees in Robotics and AI: An Introduction.

Steve

3

Thanks for the reply, i’ve seen nav2_bt_waypoint_follower in your documentation here https://navigation.ros.org/concepts/index.html#waypoint-following, upon reading it again it could be under another name.
My plan is to make a new higher BT and use bt_navigator as subtree using the NavigateToPose action node. Am fairly new to this and I am now trying to implement this in my project and i am a little bit lost in the code. I hope that there is a repo where you use the action to see what I am doing wrong.

4

I’d recommend starting with the resources I pointed you out above!

5

You can.
There is an unresolved philosophical question that was never answered in my opinion.

If we have a high level BT that works as Task Planner and the BT in Nav2, shall we merge them together or keep them as two separate sub-system?

At some point this is a question that needs to be addressed by the community, because even for me it is unclear.

1 Like
6

I think that question has been answered, at least from my perspective. You have them separated. It would be a massively bloated thing with alot of lack of general separation of concerns to try to embed your autonomy system with your navigation behavior at one time.

That’s not to say that’s the right answer for 100% of applications, but I think its the right answer in at least 90% of applications.

There are certain primitives interface though that could be expanded, why we have the Navigator plugins now. If, for instance, you wanted to make a WPF interface in addition to NavigateToPose and NavigateThroughPoses (though you could probably just use the NavigateThroughPoses as WPF has the same information and largely the same intent). But the things driving the navigation request primitives should be a higher level system, which could be another behavior tree, FSM, custom application or what have you.

7

Coming from an academic angle, behavior based design for robotics has a long literary history. One publication I still recall from attending Prof. Ronald C. Arkin’s robotics course was his entire book on the subject:

@book{arkin1998behavior,
  title={Behavior-based robotics},
  author={Ronald C. Arkin},
  year={1998},
  publisher={MIT press}
}

The book is out of print, but you can search for it online using the the ISBN. Rereading the epub I found, I think these chapters are relevant:

  • Chapter 4 Behavior-Based Architectures 123
    • 4.1 What is a Robotic Architecture? 124
    • 4.3 Subsumption Architecture 130
    • 4.4 Motor Schemas 141
    • 4.5 Other Architectures 165
    • 4.6 Architectural Design Issues 172
  • Chapter 6 Hybrid Deliberative/Reactive Architectures 205
    • 6.1 Why Hybridize? 206
    • 6.3 Traditional Deliberative Planners 209
    • 6.4 Deliberation: To Plan or Not to Plan? 211
    • 6.5 Layering 213
    • 6.6 Representative Hybrid Architectures 214

Although the 1998 publication date predates much of the modern literature on behavior trees, it does provide a time capsuled perspective on the decades of robotic behavior based design research predating itself, particularly reflecting separation of concerns and subsumption between autonomy and navigation behaviors. Of course, simply perusing through more recent articles that either cite or are relate to this book could also be fruitful:

1 Like
8

This is a very interesting question! :slight_smile:

I think that the most BT-esque way would be to have all behavior in one behavior tree. At least that’s how I read [1709.00084] Behavior Trees in Robotics and AI: An Introduction.
But I am with @smac in that the separation of concerns is an important aspect of any architecture and it facilitates (among other things) testability of a system.

And I think we can do both by coupling the two (or more) BTs by a ROS action. This makes them functionally coupled, such that they can to a degree viewed as on behavior tree. While still allowing the two subtrees to be tested and architecturally viewed as separate.
Limitations of this are of course in the interface. I can not judge how tight the coupling via ROS action is, in terms of latency, different tick frequencies and how well the action return states can be mapped to BT return states (Running, Success and Failure).