Jack,<br><br><div class="gmail_quote">On Mon, Sep 20, 2010 at 6:36 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: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Thanks for the helpful reply, Eitan.<br>
<br>
More comments (in context) below...<br>
<div class="im"><br>
On Mon, Sep 20, 2010 at 1:13 PM, Eitan Marder-Eppstein<br>
<<a href="mailto:eitan@willowgarage.com">eitan@willowgarage.com</a>> wrote:<br>
> Jack,<br>
> I'm sorry that you haven't found the documentation on the costmap to be<br>
> up-to-snuff, though we've tried to put enough information on there to get<br>
> people up and running. There aren't other docs besides those that you see<br>
> here: <a href="http://www.ros.org/wiki/costmap_2d" target="_blank">http://www.ros.org/wiki/costmap_2d</a> and<br>
> here: <a href="http://www.ros.org/doc/api/costmap_2d/html/.." target="_blank">http://www.ros.org/doc/api/costmap_2d/html/..</a>.. so if you've found<br>
> those, there's not much else out there besides example code.<br>
<br>
</div>I would not describe the documentation as lacking, but say that it<br>
appears not to be aimed at my use case (which is probably not<br>
typical). Most real users of costmap_2d are likely focused on the C++<br>
APIs and not the provided ROS nodes.<br>
<br>
I am mainly just using the costmap_2d_node for a proof-of-concept to<br>
see if it can handle sensor fusion for our autonomous vehicle. I have<br>
some old code I could port to ROS instead, but this looks like a<br>
better option, if it can scale up to the distances and speeds required<br>
for driving a car.<br></blockquote><div><br>Makes sense. I'm happy to help answering whatever questions you have that the documentation doesn't address.<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

<div class="im"><br>
> I had hoped that the obervation_sources section of the sensor management<br>
> parameters documentation<br>
> (<a href="http://www.ros.org/wiki/costmap_2d#Sensor_management_parameters" target="_blank">http://www.ros.org/wiki/costmap_2d#Sensor_management_parameters</a>) would take<br>
> care of the distinction between the <name> and <source_name> namespace<br>
> distinction, but perhaps that section is unclear? Or was it just lost in the<br>
> noise? I can work to make it better or more prominent, but it would be<br>
> useful first to know which was the reason for it being so confusing.<br>
<br>
</div>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></blockquote><div><br>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: <a href="http://www.ros.org/wiki/costmap_2d#Costmap2DROS">http://www.ros.org/wiki/costmap_2d#Costmap2DROS</a>, 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.<br>
 </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<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></blockquote><div><br>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.<br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<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></blockquote><div><br>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.<br>
 </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<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></blockquote><div><br>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:<br>
<br>/costmap/velodynce_sensor/topic = /velodyne/obstacles<br><br>Would that solve your use case?<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

<div class="im"><br>
> You're right in your recollection about max_range readings being treated as<br>
> unknown. If you want the costmap to use this information differently, you'll<br>
> have to write a laser filter that takes max_range values in your laser scan<br>
> and assigns them slightly less than max_range values. When we've done this,<br>
> we typically set up one observation_source that only puts marking<br>
> information into the costmap that uses the unfiltered scan and one<br>
> observation_source that clears obstacle information in the costmap and uses<br>
> the filtered scan topic. In this way, we don't put max range hits in as<br>
> obstacles, but we do use them to clear obstacles out.<br>
<br>
</div>That helps. I don't think I could have figured that out from the docs.<br>
It would help if there were an explicit statement that cells traversed<br>
by max range readings are unknown.<br>
<br>
What is the rationale for not treating max range reading as clearing<br>
intervening cells? Is it mostly a performance issue due to the ray<br>
tracing overhead?<br></blockquote><div><br>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.<br>
 </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
On further reflection, our application can probably ignore this<br>
problem and just look for explicit obstacles. We use a road map to<br>
drive on, and can generally assume that any unoccupied part of the<br>
road is drivable. The performance savings when driving in wide open<br>
areas could be considerable.<br>
<div class="im"><br>
> Hopefully this helps, if you have suggestions for specific documentation<br>
> that you'd like to see, do let me know. Also, if you'd like to document your<br>
> experience getting the costmap up and running standalone in tutorial form on<br>
> the wiki, I'd be more than happy to look it over.<br>
> Hope all is well,<br>
<br>
</div>Your reply was very helpful, thanks.<br>
<br>
I made several documentation suggestions above. I am busy right now<br>
trying to get it working. I am not certain how generally useful my<br>
example is, but I am willing to work on a tutorial, it that seems<br>
worthwhile.<br>
<br>
I have some other questions, which would probably better be asked in a<br>
separate subject heading.<br></blockquote><div><br>Thanks a bunch for the input.<br><br>Hope all is well,<br><br>Eitan<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

<br>
Regards,<br>
<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>