I’m excited to share that Black Coffee Robotics has open-sourced a ROS2 package implementing the Vector Pursuit algorithm. This geometric path-tracking algorithm considers both the position and orientation of a path, offering high accuracy and speed while remaining computationally light and simple to deploy.
Motivation for the work
My team and I have been working with AMRs, and other vessels for nearly a decade, and have often utilized ROS (and now ROS2) packages for navigation. Those in the industry would note that most startups begin by utilizing open-source projects such as move_base, or nav2, and the default controllers such as Pure Pursuit, or DWA/DWB. On edge devices with limited computing power and memory, usage of TEB/MPC-based approaches can be ruled out, if not DWA/DWB itself.
While Pure Pursuit based approaches have been the load bearer of most open-source-reliant industrial deployments, its limitations are easy to see at any place involving tight turns, and general oscillations at higher speeds (also described in the original paper itself). Vector Pursuit, a lesser-known algorithm has been around for a few years, and we have had success using and deploying it on real-world AMR applications in the past (we wrote a different ROS1 version at the time). In our experience (and consistent with theoretical expectations), it substantially outperformed Pure Pursuit in terms of tracking performance, and “smoothness” of motion. More details and comparisons are in the original thesis
While RPP (ROS2 default controller) improves upon the native Pure Pursuit, primarily utilizing a dynamic lookahead distance, it still lacks the orientation tracking that Vector Pursuit provides - that’s just how the algorithm was designed back in 1992
We have now decided to open-source this implementation and make it available to the wider community. The goal is to make robot navigation easier, and better for everyone - especially those in the early stage of their development and business.
Potential benefits:
Improved tracking performance compared to Pure Pursuit.
Better performance, and lower computational requirements than DWB
Some Design Choices
We have decided to release this as a nav2 controller plugin because many robots run nav2, and it makes natural sense to have it as a plugin, instead of a standalone package.
We have kept the package parameters, and code structure as close to the default nav2 controller (RPP) as possible. This should make it easier for existing users to switch to this controller, or use it in parallel.
Planned next steps
Binary release for easy installation
More hardware trials and feedback: While the algorithm itself is field tested, this plugin has thus far been tested in simulations and a home build robot. We will try to test it on industrial-grade hardware during our future projects, and also look forward to hearing from anyone else who does.
Potential merge with nav2: We would like to do this asap, but we need to ensure that the community is happy with the implementation and stable enough for a merge. @smac - we would love to hear your thoughts on this, and if there are any set of steps/guidelines/tests for a new plugin to be - either merged by nav2 or if not that - be listed in the documentation as a “nav2 compliant” unofficial plugin that can be maintained separately.
We hope it proves beneficial to the community, and we look forward to your feedback and contributions!
My general thoughts for new packages is that there has to be at least ~1-2 companies or industrial research projects using it so that its not abandoned-ware, has been shown to meet some niche that other components did not meet, and is sufficiently stable that at least ~1-2 groups can show it working in long-duration testing/deployments/R&D/etc. Optimally, some maintenance support from the original developers - but I’m pretty lax on that.
I think there are a couple of key directions:
Understand the practicality of integrating the selection of angular velocity that this controller uses into RPP itself to make it more powerful and give folks the option to use it most easily. It would also open up more users to try out this variant by just flipping a parameter. I think this is the best way to go, +/- some refactors along the way to make the code more maintainable and understandable. RPP has grown over time into having a lot of bells and whistles and this seems like a natural extension.
Integrating it as a stand-alone controller. I would generally prefer not to do this unless (A) it is infeasible to integrate the feature into RPP, (B) by popular demand, and/or (C) it has gained sufficient popularity as a stand-alone controller its less disruptive to users to leave it as-is (+/- adding some required features to be feature complete w.r.t. other controllers → I haven’t looked enough in detail to know what might be missing)
One of the nice things about the ROS ecosystem being federated is that not all integrations with Nav2 need to be inside of Nav2 itself - it can still be released on the build farm and folks that want to use it, can. Happy to have it listed in the Navigation Plugins index for searchability.
In light of these, I think it’d be best for us to maintain is separately and wait for a much needed user review, and deployment stories.
Precisely the reason we developed a Nav2 plugin! Great architecture, and flexibility in development. Perhaps a discussion for later - the idea of a “Nav2/ROS2 app store” would be great!
For the time being though - it’d be great if we can have Vector Pursuit listed in the Navigation Plugins Index. How can we go about doing that?
This would be a fantastic addition, MPPI is probably more reliable but without a Jetson or a high end onboard PC it might as well not exist.
Pure Pursuit is noticeably more consistent than DWB on low end hardware, at least in my Turtlebot 4 tests with Clearpath’s configs both in the sim and on the actual robot, but also still gets consistently stuck in not even that demanding situations. I’ll give yours a test once it’s set up as a plugin.
P.S. No chance of getting that old Noetic version out too?
Hey, the controller is implemented as a Nav2 plugin so please do try it out. We are still working on the binary release but in the meantime you can build it from source. We are unsure of releasing and maintaining a Noetic Version as of now.
Yeah it’s probably not worth going through too much effort on the Noetic side given the EoL date, and integrating with the old move_base is definitely more trouble than it’s worth. Still I see the codebase itself is not that large in absolute terms (300 lines headers, 1k lines controller). I’ll see how it works on my end in ROS 2 and might try to port it as a standalone path following node at some point.
Precisely, please share your experiences with the controller - any issues/improvements. We would love to see some videos too if you get the chance - happy to put them up on Github, other release media
