[ros-users] costmap_2d questions

Tue Sep 21 18:33:01 UTC 2010

Jack,

On Mon, Sep 20, 2010 at 6:36 PM, Jack O'Quin <jack.oquin at gmail.com> wrote:

> Thanks for the helpful reply, Eitan.
>
> More comments (in context) below...
>
> On Mon, Sep 20, 2010 at 1:13 PM, Eitan Marder-Eppstein
> <eitan at willowgarage.com> wrote:
> > Jack,
> > I'm sorry that you haven't found the documentation on the costmap to be
> > up-to-snuff, though we've tried to put enough information on there to get
> > people up and running. There aren't other docs besides those that you see
> > here: http://www.ros.org/wiki/costmap_2d and
> > here: http://www.ros.org/doc/api/costmap_2d/html/.... so if you've found
> > those, there's not much else out there besides example code.
>
> I would not describe the documentation as lacking, but say that it
> appears not to be aimed at my use case (which is probably not
> typical). Most real users of costmap_2d are likely focused on the C++
> APIs and not the provided ROS nodes.
>
> I am mainly just using the costmap_2d_node for a proof-of-concept to
> see if it can handle sensor fusion for our autonomous vehicle. I have
> some old code I could port to ROS instead, but this looks like a
> better option, if it can scale up to the distances and speeds required
> for driving a car.
>

Makes sense. I'm happy to help answering whatever questions you have that
the documentation doesn't address.

>
> > I had hoped that the obervation_sources section of the sensor management
> > parameters documentation
> > (http://www.ros.org/wiki/costmap_2d#Sensor_management_parameters) would
> take
> > care of the distinction between the <name> and <source_name> namespace
> > distinction, but perhaps that section is unclear? Or was it just lost in
> the
> > noise? I can work to make it better or more prominent, but it would be
> > useful first to know which was the reason for it being so confusing.
>
> Since I am using costmap_2d_node, I needed to figure out what <name>
> to use for its parameters. Looking at the code quickly reveals that
> the node uses "costmap", so I need to define parameters like
> /costmap/footprint, /costmap/front_sick/sensor_frame, etc. But, I
> could not find that in the documentation.
>

The node uses "costmap" by default, but its actually given a name on
construction which may be something totally different, and in most cases is.
That's why <name> is used. To attempt to make it clear that the namespace
the costmap reads its parameters from varies. This is described here:
http://www.ros.org/wiki/costmap_2d#Costmap2DROS, but I can see it being a
bit unclear. In the example listed in that section, however, <name> would be
replaced with "my_costmap" everywhere parameters are read. Perhaps I'll bold
it.

>
> If the three nodes built in that package (costmap_2d_cloud,
> costmap_2d_markers, and costmap_2d_node) are intended for stand-alone
> use, I would suggest an additional doc section for those ROS
> interfaces. There would be the appropriate place to document the fact
> that costmap_2d_node sets <name> to "costmap", for example.
>

You're right that these nodes need some documentation. In the case of
costmap_2d_cloud and costmap_2d_markers, the only purpose of these nodes is
to help visualize the voxel grid published by the costmap in rviz. I have a
few rviz launch files that bring them up, and never really intended people
to have to deal with the nodes themselves, but some documentation is still
warranted. The costmap_2d_node was meant to serve as an example of how to
use a costmap... I never really envisioned it being used standalone, but
there's no reason why it couldn't be... so it too could use some docs.

> The overview section immediately dives into the
> costmap_2d::Costmap2DROS class. Perhaps it could mention the nodes,
> while still making it clear that Cosmap2DROS is the main interface for
> this package.
>

I guess to echo what I said above. I never really intended for people to be
running those nodes. I always thought that if people wanted to use a costmap
they'd use the C++ interface since the ROS interface is pretty lacking. All
you really get over ROS are visualization topics that can be conveniently
used for other things. I want to rework the costmap in nodelet form at some
point to change this, but that's a ways in the future.

>
> The <source_name> doc section you mention is fairly clear and easy to
> find. The only uncertainty I had about that is whether the source name
> can itself contain a '/'. One of my sources is (currently) named
> "/velodyne/obstacles". Do I need to rename or remap this, or can I
> just define parameters like /costmap/velodyne/obstacles/data_type? I
> have not been able to figure that out yet.
>

I believe that the '/' should be OK.... but typically, I'll use a name
without a slash for the source_name, and then just set the topic parameter
within the namespace to point to the correct place. So... I might have a
source called velodyne_sensor:

/costmap/velodynce_sensor/topic = /velodyne/obstacles

Would that solve your use case?

>
> > You're right in your recollection about max_range readings being treated
> as
> > unknown. If you want the costmap to use this information differently,
> you'll
> > have to write a laser filter that takes max_range values in your laser
> scan
> > and assigns them slightly less than max_range values. When we've done
> this,
> > we typically set up one observation_source that only puts marking
> > information into the costmap that uses the unfiltered scan and one
> > observation_source that clears obstacle information in the costmap and
> uses
> > the filtered scan topic. In this way, we don't put max range hits in as
> > obstacles, but we do use them to clear obstacles out.
>
> That helps. I don't think I could have figured that out from the docs.
> It would help if there were an explicit statement that cells traversed
> by max range readings are unknown.
>
> What is the rationale for not treating max range reading as clearing
> intervening cells? Is it mostly a performance issue due to the ray
> tracing overhead?
>

The rationale is that you can't actually tell the difference between an
error and max_range with a laser range finder. Points that come back as
max_range may, for example, have actually hit a black surface. So, treating
them as valid hits may actually be unsafe and cause you to clear obstacles
out that shouldn't.

>
> On further reflection, our application can probably ignore this
> problem and just look for explicit obstacles. We use a road map to
> drive on, and can generally assume that any unoccupied part of the
> road is drivable. The performance savings when driving in wide open
> areas could be considerable.
>
> > Hopefully this helps, if you have suggestions for specific documentation
> > that you'd like to see, do let me know. Also, if you'd like to document
> your
> > experience getting the costmap up and running standalone in tutorial form
> on
> > the wiki, I'd be more than happy to look it over.
> > Hope all is well,
>
> Your reply was very helpful, thanks.
>
> I made several documentation suggestions above. I am busy right now
> trying to get it working. I am not certain how generally useful my
> example is, but I am willing to work on a tutorial, it that seems
> worthwhile.
>
> I have some other questions, which would probably better be asked in a
> separate subject heading.
>

Thanks a bunch for the input.

Hope all is well,

Eitan

>
> Regards,
> --
>  joq
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20100921/6c0d0232/attachment-0004.html>