Jack,

On Tue, Sep 21, 2010 at 3:01 PM, Jack O'Quin <jack.oquin@gmail.com> wrote:

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

We're actually working on a node to turn OccupancyGrid messages into
PointClouds, which are then fed into the costmap. Once we get it finished,
tested and some usage documentation done, we'll be sharing it.

- Eric

--
>  joq
> _______________________________________________
> ros-users mailing list
> ros-users@code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>