| ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
AFAIK the navigation stack in its current state does not work for a carlike robot. The last time I checked, base_local_planner required the robot to be able to turn in place.
Would I have to implement an alternative to base_local_planner or is there an easier way to make base_local_planner work for carlike robots?
That's correct, base local planner can only handle holonomic/differential drive robots and assumes roughly circular shape.
The global path currently can be constructed using the sbpl lattice planner. This planner follows the BaseGlobalPlanner interface, so it will output a valid global path for use by a local planner. Be sure to check out the list of motion primitives (section 3.1.2). We have had luck using the unicycle.m and it has generated k-turns for our diff drive robot when we forgot to tell it to turn in place. Base Local Planner took one look at those and ignored them. :)
This code will provide a (probably!) valid plan for Ackermann drive vehicles. Once you have this working, you will need to write your own local planner to take in the desired x, desired y, and desired heading output by the lattice planner. This is more complicated, but you could easily take a systems approach and calculate x_err, y_err, and yaw_err and then perform some sort of PID approach to the steering.
That's the takes effort to implement approach, so I'm hoping someone else knows of a package to do precise path following as the potential based approach in the base local planner will fail for avoiding obstacles in Ackermann (it wants to descend the gradient each step no matter what, not always possible for a car). If you do write your own base planner, be sure to follow the interface given.
I recently added the possiblity to navigate car-like robots with the navigation stack and the teb_local_planner as plugin for local planning. It's still highly experimental! Maybe someone of you wants to give it a try and possibly provide me with some feedback, issues or further improvements/extensions? I've added tutorials describing how to set up the planner. Thanks!
Cheers, Christoph
I guess the adaptations that would have to be made in base_local_planner are managable. When you have a look at the files trajectory_planner.cpp and trajectory_planner.h, you will find the motion equations in the header file to be x(t+1) = x(t) + (v(x)cos(theta) + v(x)sin(theta))*dt, so the ones of a differantial drive robot. They are used within the function TrajectoryPlanner::generateTrajectory() and are simply sampled over a finite time horizon with given time resolution. So the only thing here would be to replace these equations with the ones of an ackermann steering vehicle (that is more or less introducing the steering speed, have a look e.g. at link to paper on how to describe such a system).
Furthermore, one should review the sampling of the input space: for differantial drive robots, it makes sense to sample longitudinal and rotational velocity, for ackermann vehicles it would make more sense to sample longitudinal velocity and steering speed, as this refers to the system's inputs. You will have to make these adaptions probably at quite a few places in the code, but mainly in trajectory_planner.cpp line 461-490. Also you would have to remove lines 532-574 to remove the sampling of in-place rotations. One could also remove the code for holonomic robots, but this can just be deactivated by a ros parameter. As far as I see, these are the major changes to the code.
The sampled trajectories are then scored with respect to their proximity and alignment to the global path given by the base_global_planer, but it should not be necessary to change anything here. One could even try for the beginning to use the standard base_global_planner (NavFn) and do the adaptions to the base_local_planner, but one would have to expect suboptimal behaviour, due to the fact that the global path does not respect the system's kinematics correctly.
Please correct me, if I am wrong.
I believe that the nav stack is currently set up to only handle holonomic and differential drive robots.
In order to get it working with an Ackermann steered robot, it would require rewriting large chunks of move_base and base_local_planner in order to accomodate this chassis type.
There is now an Ackermann interest group, which is actively working on code and interfaces: http://www.ros.org/wiki/Ackermann%20Group
The following message on the mailing list goes a little more into detail on how the local planner would have to be modified:
Asked: 2011-02-14 21:15:31 -0500
Seen: 10,688 times
Last updated: Feb 03 '16
ROS Answers is licensed under Creative Commons Attribution 3.0 Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.
