Jack,<br><br><div class="gmail_quote">On Tue, Sep 21, 2010 at 3:01 PM, Jack O'Quin <span dir="ltr"><<a href="mailto:jack.oquin@gmail.com">jack.oquin@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Tue, Sep 21, 2010 at 1:33 PM, Eitan Marder-Eppstein<br>
<<a href="mailto:eitan@willowgarage.com">eitan@willowgarage.com</a>> wrote:<br>
<br>
>> Since I am using costmap_2d_node, I needed to figure out what <name><br>
>> to use for its parameters. Looking at the code quickly reveals that<br>
>> the node uses "costmap", so I need to define parameters like<br>
>> /costmap/footprint, /costmap/front_sick/sensor_frame, etc. But, I<br>
>> could not find that in the documentation.<br>
><br>
> The node uses "costmap" by default, but its actually given a name on<br>
> construction which may be something totally different, and in most cases is.<br>
> That's why <name> is used. To attempt to make it clear that the namespace<br>
> the costmap reads its parameters from varies. This is described here:<br>
> <a href="http://www.ros.org/wiki/costmap_2d#Costmap2DROS" target="_blank">http://www.ros.org/wiki/costmap_2d#Costmap2DROS</a>, but I can see it being a<br>
> bit unclear. In the example listed in that section, however, <name> would be<br>
> replaced with "my_costmap" everywhere parameters are read. Perhaps I'll bold<br>
> it.<br>
<br>
</div>Personally, <name> seems clearer to me. A note that <name> would be<br>
"my_costmap" in the example might help some readers, but it would not<br>
answer my original question, which was: "what <name> is used for<br>
costmap_2d_node?"<br>
<div class="im"><br>
>><br>
>> If the three nodes built in that package (costmap_2d_cloud,<br>
>> costmap_2d_markers, and costmap_2d_node) are intended for stand-alone<br>
>> use, I would suggest an additional doc section for those ROS<br>
>> interfaces. There would be the appropriate place to document the fact<br>
>> that costmap_2d_node sets <name> to "costmap", for example.<br>
><br>
> You're right that these nodes need some documentation. In the case of<br>
> costmap_2d_cloud and costmap_2d_markers, the only purpose of these nodes is<br>
> to help visualize the voxel grid published by the costmap in rviz. I have a<br>
> few rviz launch files that bring them up, and never really intended people<br>
> to have to deal with the nodes themselves, but some documentation is still<br>
> warranted. The costmap_2d_node was meant to serve as an example of how to<br>
> use a costmap... I never really envisioned it being used standalone, but<br>
> there's no reason why it couldn't be... so it too could use some docs.<br>
<br>
>> The overview section immediately dives into the<br>
>> costmap_2d::Costmap2DROS class. Perhaps it could mention the nodes,<br>
>> while still making it clear that Cosmap2DROS is the main interface for<br>
>> this package.<br>
><br>
> I guess to echo what I said above. I never really intended for people to be<br>
> running those nodes. I always thought that if people wanted to use a costmap<br>
> they'd use the C++ interface since the ROS interface is pretty lacking. All<br>
> you really get over ROS are visualization topics that can be conveniently<br>
> used for other things. I want to rework the costmap in nodelet form at some<br>
> point to change this, but that's a ways in the future.<br>
<br>
</div>If these three nodes are just example code, then there is no necessity<br>
to document them (though it would not hurt).<br>
<br>
Perhaps the overview should say: "This package provides a C++ API. The<br>
costmap_2d_node, costmap_2d_cloud and costmap_2d_markers nodes are<br>
provided as usage examples. Look at their sources to see what they<br>
do."<br>
<div class="im"><br>
>> The <source_name> doc section you mention is fairly clear and easy to<br>
>> find. The only uncertainty I had about that is whether the source name<br>
>> can itself contain a '/'. One of my sources is (currently) named<br>
>> "/velodyne/obstacles". Do I need to rename or remap this, or can I<br>
>> just define parameters like /costmap/velodyne/obstacles/data_type? I<br>
>> have not been able to figure that out yet.<br>
><br>
> I believe that the '/' should be OK.... but typically, I'll use a name<br>
> without a slash for the source_name, and then just set the topic parameter<br>
> within the namespace to point to the correct place. So... I might have a<br>
> source called velodyne_sensor:<br>
><br>
> /costmap/velodynce_sensor/topic = /velodyne/obstacles<br>
><br>
> Would that solve your use case?<br>
<br>
</div>I'll give that a try, thanks.<br>
<br>
Has there been any consideration of accepting nav_msgs/OccupancyGrid<br>
or nav_msgs/GridCells as input?<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div>- Eric</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<font color="#888888">--<br>
</font><div><div></div><div class="h5"> joq<br>
_______________________________________________<br>
ros-users mailing list<br>
<a href="mailto:ros-users@code.ros.org">ros-users@code.ros.org</a><br>
<a href="https://code.ros.org/mailman/listinfo/ros-users" target="_blank">https://code.ros.org/mailman/listinfo/ros-users</a><br>
</div></div></blockquote></div><br>