grid_map versus proj_map for same bag data

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

grid_map versus proj_map for same bag data

Pi Robot
Hello,

I'm using ROS Indigo, rtabmap 0.11.8 binaries and Ubuntu 14.04.

I collected some bag data for a short teleoperated run of my Kobuki robot in my living room and I wanted to compare the 2D map created on the grid_map versus proj_map topic.  The robot has a Hokoyu laser scanner about 0.1m off the ground and an Xtion Pro depth camera about 0.45m off the ground.

The following images show the result of running the demo_robot_mapping.launch file against my bag data under two scenarios.  In the first, I remap grid_map to /map and in the second I remap proj_map to /map.  The first image in each pair includes the map cloud so you can see the objects in the room.

grid_map:





proj_map:





As a final comparison, here is the result when using gmapping:



I'm trying to understand a couple of things about these images:

1. For the grid_map images, why do I see the large arc of free grid cells in the map?  This arc actually moves around with the robot during the mapping process but it does not show up when running gmapping.

2. For the proj_map images, why is the group of cells in the middle of the image not marked as free (white)?  The depth image from the camera should not be projecting anything to the ground so I would have thought these cells should be white.  Or is it because the depth data is out of range of the camera?

Thanks!
patrick
Reply | Threaded
Open this post in threaded view
|

Re: grid_map versus proj_map for same bag data

matlabbe
Administrator
Hi Patrick,

for the arc, it may be because the lidar is upside down. Either set:
<param name="flip_scan" type="bool" value="true"/>
or
<param name="map_negative_poses_ignored" type="bool" value="true"/>
under rtabmap node. I think with "map_negative_poses_ignored=true", you would get something similar to gmapping.

The algorithm used to create occupancy map from projection is labeling ground points as empty and obstacle points as occupied. The camera needs to "see" the ground to add empty cells.

You may try "octomap_proj" topic instead of "proj_map", which is the projection of the OctoMap on the ground. In this version, OctoMap does ray tracing in 3D, so empty voxels just in front of the camera will be projected as empty cells on the ground, this would fill the unknown space in the middle of the map.

cheers,
Mathieu
Reply | Threaded
Open this post in threaded view
|

Re: grid_map versus proj_map for same bag data

Pi Robot
Hi Mathieu,

I had a nagging suspicion that I already asked that question but couldn't remember where I posted it.  So thanks for answer it *again*!  Yes, adding the flip_scan parameter fixed the "arc" in the grid_map.

And thanks for the explanation regarding proj_map and octomap_proj.  It all makes sense now.

--patrick



Reply | Threaded
Open this post in threaded view
|

Re: grid_map versus proj_map for same bag data

brigit
In reply to this post by matlabbe
matlabbe wrote
The algorithm used to create occupancy map from projection is labeling ground points as empty and obstacle points as occupied. The camera needs to "see" the ground to add empty cells.
I have a question regarding this: technically speaking, the ground is still an obstacle (albeit a flat one) with zero or minimal height. As you say, the camera sees the ground plane, but how does the algorithm know to label these ground points as empty? Is there some height threshold that is used?
Reply | Threaded
Open this post in threaded view
|

Re: grid_map versus proj_map for same bag data

matlabbe
Administrator
Hi,

All points with normal close to +z axis (up to a fixed angle) are segmented, then clustered together. The biggest plane is considered the ground. Depending on the parameters, the other planes can be considered as ground or obstacles. We can also set a maximum height for the ground detection. It is similar to rtabmap_ros/obstacles_detection nodelet.

cheers