Feature-Request: Path-Planner should take into account the minimum turning radius and the ability to drive backward.

[AndyPermaRobotics]

I noticed, that the Path-Planner does not take into account the minimum turning radius of the robot and the ability of the robot to drive backward.
Both can be defined for the Driver, but not for the PathPlanner.
So the PathPlanner will calculate a path that avoids obstacles, but the driver may drive a different path.

Currently I have another use case, that underlines the limitations of the PathPlanner:
I want my robot to drive swaths and at the end of one swath it should drive to the beginning of another swath. This means, that the bot has to rotate by 180° and perform a small transition in y direction.

In this case the planned path has a very small radius:

and this is the path that the bot drives:

My interim solution is to add a stopover point:

this mitigates the problem, but still the PathPlanner does not take into account the minimum turning radius and I couldn't figure out how to create a stopover point that leads to a path with a nearly constant curvature.

I tried to create my dream path with Miro and it looks like this:

as you can see, I added 3 control points. I don't know, if this is possible with single spline.

It would be very nice, if you could add this functionality to the PathPlanner!

Best regards
Andreas

[falkoschindler]

Thanks for the great suggestion, Andreas!
You're right, the path planner is more limited than the driver in terms of configurability. We should improve on that.

1. I could well imagine to add an option to disable backward splines. This should be an easy change in the implementation.

2. Limiting the curvature should work as well. We can simply specify the curvature_limit in _is_healthy to discard all hypothetic splines that curve too much.

3. So far this will only generate paths consisting of cubic spline segments based on the underlying triangular mesh we're using for graph-based search. To generate such a beautiful curve like your dream path, we would need to work on the simplification step that merges these initial splines to create a smoother result. We could consider higher-order splines or other shapes, maybe as an opt-in feature so that the performance doesn't decrease for other projects. It's more complicated than points 2 and 3 though.

But after thinking about how to improve the path planner, I wonder if you should even use it in this case. The turning procedure should be pretty similar each time and there are probably no obstacles to consider. This would allow to create a path programmatically, i.e. generate a sequence of splines with geometric operations. One spline from start to some point halfway at 90˚ and one from this intermediate point to the end should be enough for a smooth turning curve. And if the distance between the swaths are roughly constant, the curvature shouldn't change either.

In conclusion, I would support steps 1 and 2, hesitate about step 3 and, in your case, recommend to remove the path planner from the equation.

[AndyPermaRobotics]

Thanks for the fast response @falkoschindler!

It's great to hear, that you can implement the minimum_turning_radius and disable backward splines!

Your explanation concerning my dream path is understandable.
The idea with the intermediate points sounds like my implementation with the stopover point.
I improved my initial attempt by using two extra points to the path and it works quite well.

I'm looking forward to the updates of the path planner!