On Mon, Sep 20, 2010 at 7:45 PM, Jack O'Quin <jack.oquin@gmail.com> wrote:

It may seem nonsensical to ask about the "height" of a 2D costmap, but
I am confused by what we saw today and could use some help making
sense of it and deciding what to do.

As mentioned in an earlier message, I am experimenting with
costmap_2d_node to see if our autonomous vehicle can use it for sensor
fusion. It seems to work OK in stage simulation. We are running ROS
C-turtle on Ubuntu Karmic and Lucid.

Today, we experimented with it on the actual car feeding it an
obstacle point cloud from our Velodyne 3D LIDAR. I can view the
PointCloud in rviz and it looks reasonable. But, when I view the
obstacle GridCells, none appear. However, rviz can display the unknown
GridCells (which is all of them). Strangely, they appear a couple of
hundred meters below the car and the obstacles. This offset looks
close to the actual elevation of our test area (209 meters above sea
level), so I am guessing the map may think it's at elevation z=0.

This seems like a reasonable assumption. The navigation stack just publishes those markers in the global_frame of the costmap and let's rviz display them wherever, so this implies that, perhaps, your map frame is not correct in Z. Have you tried using rviz to look at tf itself? You should see the map and odometric frames where you expect them.

Our GPS odometry source publishes the actual elevation for the
nav_msgs/Odometry message and /odom->/vehicle transform. There is
(currently) a static identity transform from /map to /odom (0,0,0
translation and 0,0,0,1 rotation quaternion). So, I expected the map
to appear at the same elevation as the vehicle and the odometry. I
can't be certain whether this is purely an rviz display issue or
inherent to the costmap, but I suspect the latter, because it would
explain why no obstacles appear in the map, they are all way above the
/costmap/max_obstacle_height parameter setting (2.7m). I did try
adding 209 to the max and min obstacle heights to see if that would
make a difference, and it did not.

Looking at the frames should help here I'd think. Adding 209 to the max and min obstacle heights might not be enough if you're using the voxel grid underlying model for the costmap. I'd also expect you to have to set the origin_z parameter on the voxel grid: http://www.ros.org/wiki/costmap_2d#Map_type_parameters. The correct way to solve this, however, is probably to make sure that the global_frame of the costmap exists at the correct height to begin with.

Another possible explanation is that the velodyne points are published
as "/velodyne/obstacles". I can't tell whether costmap_2d allows a
<sensor_name> containing slash or not. Is it legal to set the
/costmap/observation_sources parameter to "velodyne/obstacles" and
then define parameters with names like
"/costmap/velodyne/obstacles/sensor_frame"?

Any ideas what is going on and suggestions for what to do about it?

As I mentioned in my response to your previous e-mail, I think this could work, but I'd suggest removing the slash from the sensor_name and instead setting the topic parameter to "/velodyne/obstacles." Actually, come to think of it. If you have the leading "/"... I'm not sure things would work as the sensor might look for its parameters in the /velodyne/obstacles namespace instead of the /costmap/velodyne/obstacles namespace. Using a sensor name without a "/" to be safe seems like a good idea.

Hope this helps,

Eitan

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