On Mon, Sep 20, 2010 at 6:36 PM, Jack O'Quin
<jack.oquin@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@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.
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.
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,
--