Thanks for the helpful reply, Eitan. More comments (in context) below... On Mon, Sep 20, 2010 at 1:13 PM, Eitan Marder-Eppstein 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 and 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 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 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 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