Community interest in a Vector Field Histogram global path planning algorithm

[exMachina316]

Hello everyone,

I am exploring the idea of developing a Nav2 path planning plugin based on the Vector Field Histogram (VFH) algorithm. The VFH approach, traditionally used for local obstacle avoidance, has the potential to be adapted and extended for global path planning in robotic navigation systems.

Before I start working on this project, I would like to gauge the community's interest in such a plugin. Specifically, I am interested in:

• Use cases where the VFH algorithm could provide a significant advantage over existing global path planners.
• Potential collaborators who might be interested in contributing to the development, testing, and documentation of this plugin.
• Feedback from those who have worked on similar algorithms or plugins, particularly in the Nav2 framework.

I believe this plugin could add value to scenarios requiring robust obstacle avoidance and efficient path planning in dynamic environments. If there's enough interest, I would be happy to share progress updates, gather inputs, and eventually open-source the implementation for the benefit of the community.

Looking forward to your thoughts and feedback!

[SteveMacenski]

That's a bit of an old technique that doesn't consider robot kinematics / dynamics -- with that said I've found from developing the RPP controller that sometimes the old methods are really what certain, more basic robotics applications need for simplicity. I would however make sure you read S3.2 in that paper to understand its shortcomings. There's a reason that even potential field local planners based on lidar data aren't much used anymore -- they can create really big control jumps, oscillations, and even big snaps in acceleration. As well, they can often suffer in confined environments.

If you think there's a niche that this is the right solution for, please let us know :-)

I think this is probably better suited as a local planner/controller plugin, no? Rather than giving it the objective goal across a potentially large, cluttered space with alot of dead ends, you give it as the "goal" the path's final pose within some window (like the local costmap, but could be a distance too) for it to attempt to achieve. As the robot moves, this is updated as the target carrot on a known possible route through the environment from the global planner

PS: The assisted teleoperation behavior is currently setup to project the footprint forward by a velocity command and simply reduce its magnitude such that it is always N seconds from collision. This does not attempt to adjust the velocity's direction away from obstacles. This is one valid and useful way to do teleoperation, but there's another - arguably more useful way. It uses a very similiar technique to what you describe to create polar segments and if the segment the control lies in is not valid, it adjusts the velocity direction such that it is. If you were looking for a project involving potential fields and something related (if not identical, when applied), this is an area I think you could make a great feature improvement in Nav2.

[exMachina316]

Thank you @SteveMacenski for taking the time to respond and provide clarity on the VFF algorithm. I appreciate the detailed insights you shared and the context you provided about its integration within Nav2.

From what I understand and correct me if I am wrong, the "new functionality" I could contribute to the assisted teleop project will help the robot actively steer clear of obstacles rather than slowing down and eventually stopping.

As a follow up I would really like to start working on this feature although I do remember reading this thread where the purely collision avoidance scheme as it is mentioned was not so desirable.

[SteveMacenski]

From what I understand and correct me if I am wrong, the "new functionality" I could contribute to the assisted teleop project will help the robot actively steer clear of obstacles rather than slowing down and eventually stopping.

Indeed! Rather than just preventing collision, allow the robot to adjust the velocity command a little bit to steer away from the obstacles so you can more coarsely teleop from afar. This is pretty common, but not the first implementation we worked on within Nav2.

As a follow up I would really like to start working on this feature although I do remember reading this thread where the purely collision avoidance scheme as it is mentioned was not so desirable.

I think an important takeaway here is that this was when I was asking A or B, we now have "A", so this is now giving us the "B" option now, which I think is very useful. I think folks were choosing the more conservative one if the option was one or the other. There are papers doing things very similar to the paper you mentioned (if not exactly the same, from the polar regions perspective) but applied to teleop input controls (when the polar directions are blocked or otherwise non-navigable).

If the core laser scan -> polar regions with some metadata and utility functions were done in a cpp/hpp file, then that could be shared with both a teleop behavior as well as potentially a controller plugin. Food for thought, with some good design, you could implement the core of these algorithms once and use them in a few places if we find them useful other places as well!

[exMachina316]

If the core laser scan -> polar regions with some metadata and utility functions were done in a cpp/hpp file, then that could be shared with both a teleop behavior as well as potentially a controller plugin. Food for thought, with some good design, you could implement the core of these algorithms once and use them in a few places if we find them useful other places as well!

Ahh yes, I understand. Somewhat akin to the smooth control law used in the graceful controller and the docking server

[SteveMacenski]

Exactly :-)

Would you be interested in working on this?

[exMachina316]

Yes I am quite interested in working on this. Should I open up a new issue to discuss further details?

[SteveMacenski]

Sure thing! I guess I'll close this thread then