ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

How can I use the navigation stack on a carlike robot?

asked 2011-02-14 21:15:31 -0500

sebsch gravatar image

updated 2014-01-28 17:09:07 -0500

ngrennan gravatar image

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?

edit retag flag offensive close merge delete

5 Answers

Sort by » oldest newest most voted

answered 2011-02-20 15:50:15 -0500

Chad Rockey gravatar image

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.

edit flag offensive delete link more

answered 2016-02-03 09:43:23 -0500

croesmann gravatar image

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

edit flag offensive delete link more


my problem, can you give me some help? Thanks.

ljxiang gravatar image ljxiang  ( 2016-06-13 19:40:24 -0500 )edit

answered 2012-01-29 21:31:02 -0500

uschwes gravatar image

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.

edit flag offensive delete link more


The other problem with the traditional local planner is that it looks ahead several steps along the global plan, and uses this point as the local target. This fails when the global plan contains a backing maneuver and the planner looks past it. I haven't found the right place to fix this yet.
ahendrix gravatar image ahendrix  ( 2012-02-01 18:27:19 -0500 )edit

answered 2011-02-15 01:28:21 -0500

mjcarroll gravatar image

updated 2011-04-19 07:57:04 -0500

tfoote gravatar image

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.

edit flag offensive delete link more


I suspect several groups, including ours, would be interested in collaborating on such a project.
joq gravatar image joq  ( 2011-02-15 15:09:03 -0500 )edit
My group is indeed also using a Ackermann steered robot, so I'm interested in all developments in this direction. We're currently starting looking into what needs to be done for our system. I'll report any concrete steps we´re taking here.
Stefan Kohlbrecher gravatar image Stefan Kohlbrecher  ( 2011-02-19 02:23:38 -0500 )edit

There is now an Ackermann interest group, which is actively working on code and interfaces:

joq gravatar image joq  ( 2012-02-16 12:38:25 -0500 )edit

answered 2011-02-22 03:30:51 -0500

updated 2011-04-19 08:28:54 -0500

The following message on the mailing list goes a little more into detail on how the local planner would have to be modified:

sbpl as local reactive planner for a car like robot

edit flag offensive delete link more

Question Tools



Asked: 2011-02-14 21:15:31 -0500

Seen: 10,690 times

Last updated: Feb 03 '16