[ros-users] base_local_planner and ackerman kinematics?

[Jack O'Quin]

On Tue, Sep 21, 2010 at 11:48 AM, Domenico G. Sorrenti
<sorrenti at disco.unimib.it> wrote:
> Dear all,
>
> we are trying to use ros for an autonomous driving project, i.e., involving a car-like vehicle.
>
> We passed through the documentation that we have been able to find in the web (i.e., the list of ros packages), and we could not find an alternative to base_local_planner. BTW, given the size of the list and ourselves being 1st-time users, we would really appreciate a confirmation about this inference being correct.
>
> The work most related to ours that we could find is the Marvin Darpa Urban Challenge autonomous car (U.Texas at Austin, P. Stone lab.), which is reported having been ported to ROS. In the art_vehicle stack we could find the art_nav package and the pilot node, which looked to us as the one that might be including the solution to the problem. We might have mis-understood the description of its working, but it appears to us as a node accepting ros commands, not issuing them.

I maintain the utexas-art-ros-pkg repository.

The art_nav pilot node accepts CarCommand (velocity, steering angle)
commands and issues servo comands to the brake, steering and throttle.
The Ackermann steering is approximated by the bicycle model, which is
encapsulated in <art_servo/steering.h>.

BTW, I intend to subdivide the art_nav package into smaller
components. It's getting too big and monolithic. All our current code
is correctly labelled "experimental". The packaging and interfaces are
still very much subject to change.

Some of that code may be useful to you, and you are welcome to share
whatever makes sense. But, it is currently a fairly specific port of
our DARPA Urban Challenge code from Player to ROS. That work is
ongoing. We are making reasonably good progress, but far from
finished. We can navigate autonomously using the RNDF (Road Network
Definition File, a map format defined by DARPA), but currently without
any sensor input.

> Assuming base_local_planner to be a required package (beside a global planner), we thought we need to have it to avoid issuing "rotation in place" commands. In other words, as the vehicle cannot rotate in place, we thought we should inhibit base_local_planner to consider rotation in place as an admissible motion primitive, during planning.

We would like integrate our work more with the ROS code base. I am
currently experimenting with using costmap_2d for sensor fusion as a
step in that direction.

But the problem of navigating a road network is rather different from
the general problem of navigating in an unstructured environment.
Driving in a parking lot is probably the closest unstructured
equivalent for cars. There, steering constraints tend to dominate
planning options.

> Unfortunately, we have not been able to devise a way to push base_local_planner to disregard such rotations.
>
> We apologize if we missed relevant online documentation about our question.
>
> Do you have some suggestion about how to force base_local_planner not to use rotation in place or, in general, on how to deal with ackerman kinematics in ros?

I don't know how to do that, but I am interested in cooperating with
any work taking it in that direction.

There are several groups interested in using ROS for autonomous
vehicles. How much code we can share remains unclear, but I think
there is great potential for working together to define common
interfaces and messages.

Feel free to contact me directly, as well as through the ros-users mailing list.
-- 
 joq