[ros-users] costmap_2d questions

[Jack O'Quin]

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.

> 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.

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.

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.

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.

> 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?

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.

Regards,
-- 
 joq