On Tue, Sep 21, 2010 at 1:33 PM, Eitan Marder-Eppstein
<eitan@willowgarage.com> wrote:

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

Personally, <name> seems clearer to me. A note that <name> would be
"my_costmap" in the example might help some readers, but it would not
answer my original question, which was: "what <name> is used for
costmap_2d_node?"

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

If these three nodes are just example code, then there is no necessity
to document them (though it would not hurt).

Perhaps the overview should say: "This package provides a C++ API. The
costmap_2d_node, costmap_2d_cloud and costmap_2d_markers nodes are
provided as usage examples. Look at their sources to see what they
do."

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

I'll give that a try, thanks.

Has there been any consideration of accepting nav_msgs/OccupancyGrid
or nav_msgs/GridCells as input?
-- 
 joq