[ros-users] Extending Costmap_2d with Custom Values

David Lu!! davidvlu at gmail.com
Wed Feb 22 20:15:54 UTC 2012


Eitan -
Thanks for your thoughtful response. Comments inline.

On Tue, Feb 21, 2012 at 6:46 PM, Eitan Marder-Eppstein <
eitan at willowgarage.com> wrote:

> The move_base node is a single binary because it was built long before ROS
> had a good way to pass data efficiently between nodes. At the time, if you
> wanted to avoid a TCP connection and data copies, throwing things into a
> single node was the only way to go. In place of nodelets, move_base uses
> pluginlib (http://ros.org/wiki/pluginlib) and ROS wrappers (
> http://ros.org/wiki/navigation/ROS_Wrappers) to try to keep things
> reasonably modular.
>
> Re-factoring move_base to use nodelets would take a significant effort to
> do well, but there's no technical reason that it cannot be done. However, I
> don't think that it will actually make custom cost values any easier to
> implement. You can already modify the costmap ROS wrapper to subscribe to
> new topics. The real benefits of nodelets for the navigation stack would be
> improved introspection along with the ability to run components of
> move_base in separate processes when desired.
>

My thought was that if you refactored, you could remap the costmap to go to
a new node and modify it it arbitrary ways, and then pass it back to the
path planner. Currently, the new topics will only add to the costmap with a
single inflation function.


> Overloading the PointCloud message for custom cost values doesn't make
> much sense to me. I think that it will only serve to confuse people and
> will likely make for some difficult code to read. It would be far better to
> modify the costmap to subscribe to a different message type for custom cost
> values. That message would probably just be an OccupancyGrid.
>

An occupancy grid makes sense, and might be the right way to go, except
there would need to be some decision of how to integrate two non-aligned
grids. (I guess unless you required that the OccupancyGrid have the same
orientation/resolution as the costmap. The Point Cloud solution builds on
the current architecture and might be more mathematically elegant.


> This option makes the most sense to me. I could see a service that allows
> users to set cost values on cells that are guaranteed not to be overwritten
> by any observation source. This service could consist of an OccupancyGrid
> that encodes the desired custom cost values.
>

This is actually not precisely what I was thinking, but I like it. In the
same way that the current implementation caches the costmap values for all
distances, I figured you could instead specify an inflation function via a
service, and each observation source would be associate with one of these
inflation functions. However, I like yours better.

The ideal I think would be a combination of 1 and 2, but for the time
being, my inclination is to attempt just 2, since it mirrors the existing
functionality more than the service. I'd be happy to listen to other
arguments though.

-David!!

P.S. Does anyone know who fmarques is (from answers.ros). They were also
looking for this functionality and I'd like to hear them weight in.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20120222/b877a551/attachment-0004.html>


More information about the ros-users mailing list