Uncertainties of the measurements / point cloud

[Mauritz]

Hi Mathieu,

I'm trying to figure out how uncertainties are handled by the algorithm. Correct me if I'm wrong, but every measurement should be associated with an uncertainty (sensor noise, current pose estimate uncertainty).

Questions:

1. Is it possible to access the uncertainty associated with a point in the point cloud, and/or mapData?

2. Does proj_map and grid_map contain these uncertainties? That is, when the grid_map is created, and an obstacle is detected by e.g. a laser reading, the pose estimate of the robot is associated with a certain uncertainty, meaning that the obstacle could be in the "area of uncertainty". Are these uncertainties considered when creating the proj_map and grid_map?

I hope that I made myself understood. The reason I'm asking is that this information about uncertainties of the occupied cells in the grid, or the uncertainty of the points in the point cloud could be exploited for navigation.

Thank you for sharing this nice piece of software, I am using it as a part of my masters thesis. The thesis explores the use of a Kinect sensor, mounted on a Pioneer 3-DX robot, for autonomous exploration, that is, I'm trying to use the maps produced by RTAB-Map "on-the-fly" to autonomously navigate and explore the environment.

Best regards,
Mauritz

[matlabbe]

Hi,

Only the uncertainties of the links are saved in the graph. These uncertainties are used when optimizing the graph. There are no uncertainties kept for the visual words. The point cloud is saved as a RGB image and a depth image. If you want the uncertainties of each point in the cloud, you may add it (depending on the sensor) when reconstructing the clouds. The mapData contains the links with the rotation and translation variances (diagonal of the covariance matrix).

The occupancy grid maps don't contain uncertainties, only unknown, free or obstacle cells. When a laser scan hits something, the value is set to obstacle, if not the value is set to free (erasing the previous cell value). Evaluating the probability of an obstacle with consecutive laser scans is something that could be implemented in future. That could filter people walking around the robot when it is moving (keeping corresponding obstacle cells in the global map but with a lower probability).

Indeed, when doors open and close over time (mapping at different time), knowing that it "may" have an obstacle can be useful for planning (the door has 50% to be open or close, do we plan by there or use the "always" 100% opened door just some meters farther?).

cheers,
Mathieu

[Mauritz]

Hi,

Thank you for the answer. I followed your suggestion and tried to reconstruct the point clouds using MapData. However, it seems that there is only a depth image, and RGB image saved in the last added node, in the NodeData array of the MapData, that is, all measured data is in one node, is this correct? All other NodeData structures in the MapData have empty depth, image, and wordPts fields.

I had assumed that each node in the NodeData array would contain the measurement, i.e., laser scan, RGB-D image, and RBG image from the sensor and the pose associated with that node.

The idea was to loop over this structure, and create mappings from the uncertainty of the pose at which each measurement was acqired to the measurement, as well as add an uncertainty with respect to a spatial uncertainty model of my sensor, and thus get a point cloud map with the uncertainties associated with each point. However, since all the data seems to be in one node, it is not possible to know at which pose each measurement was made. Is there something that I may have misunderstood about the MapData structure?

The goal would be to create a point cloud with "ellipsoidal" uncertainties associated with each point, as well as publish new grid maps where these uncertainties are contained. That is, instead of being "unknown", "occupied" or "free", each cell would have a probability of being occupied.

Best regards,
Mauritz

[matlabbe]

Hi Mauritz,

The MapData topic publishes only the data of the latest node added to the map, thus your observation is correct. The reason is for bandwidth efficiency. A node subscribing to MapData topic would keep in cache on its side the data of each node, just incrementally add new data for the latest node added to the map. The graph with the updated poses for all nodes (in the local map) is always published.

The rviz MapCloud plugin and rtabmapviz work like that, it keeps in cache the data. map_assembler is also an other example, you can take a look at its code to see how the nodes' data are cached.

In the case where a client node is started after the map is created (or rtabmap is starting with a previous map) and you need to update its whole cache, you can call the 'publish_map" service:

$ rosservice call /rtabmap/publish_map 1 1 0"

(note the last 0) to force rtabmap node to publish MapData again but with ALL data for every nodes. You can also call the "get_map" service with the same arguments to get the map directly (this is what rviz MapCloud plugin calls when you click on "Download Map").

cheers,
Mathieu

[Mauritz]

Hi Mathieu,

Thank you very much, that explains the behaviour I have observed. I will follow your suggestion and incrementally reconstruct the new datastructures.

cheers,
Mauritz