Tips about indoor mapping with laser scan.

[Mikor]

Hi Mathieu,

I am using a lidar for mapping and I need your help, again. I am in a situation where I get some noisy results and I do not know how to make things better. Here is the trajectory. It does not seem to be weird.



But my results are noisy here is what I mean.


 
I suspect the noise comes from the turn on the left because when I split the bag in 2 parts the right side part gives better results.



So, I think it'd be nice if I could decrease the range of the observations from the lidar, is this possible to do from rtab or I can only do that from the lidar configuration? Also, I do not know if this is a suitable solution or there is something else I should try. Here are my parameters and I'd like to know if you have any tips for indoor mapping or any general guidelines?

roslaunch rtabmap_ros rtabmap.launch       use_sim_time:=true    depth:=false    subscribe_scan_cloud:=true    frame_id:=velodyne    scan_cloud_topic:=/velodyne_points     icp_odometry:=true    approx_sync:=false    args:="-d  \
      --RGBD/CreateOccupancyGrid false \
      --Rtabmap/DetectionRate 2 \
      --Odom/ScanKeyFrameThr 0.8 \
      --OdomF2M/ScanMaxSize 100000000  \
      --OdomF2M/ScanSubtractRadius 0.25   \
      --Icp/PM true \
      --Icp/VoxelSize 0.25   \
      --Icp/MaxTranslation 2   \
      --Icp/MaxCorrespondenceDistance 1.5 \
      --Icp/PMOutlierRatio 0.7 \
      --Icp/Iterations 50 \
      --Icp/PointToPlane true \
      --Icp/PMMatcherKnn 3 \
      --Icp/PMMatcherEpsilon 1 \
      --Icp/Epsilon 0.0001 \
      --Icp/PointToPlaneK 10 \
      --Icp/PointToPlaneRadius 0 \
      --Icp/CorrespondenceRatio 0.01 \
      --RGBD/NeighborLinkRefining true"

EDIT: After further investigation I noticed that this happens when I reduce the publish rate and I include every scan in the solution, but when i increase it and cover the area sparsely the noise/mild misalignment does not exist and it got me confused, do you have any suggestions ?

Thanks in advance,
Anthony.

[Mikor]

Question update.

The update concerns the following quote but the "spirit" of the question does not change that much in order to start a new thread.

Mikor wrote

EDIT: After further investigation I noticed that this happens when I reduce the publish rate and I include every scan in the solution, but when i increase it and cover the area sparsely the noise/mild misalignment does not exist and it got me confused, do you have any suggestions ?

So in a few words, the problem is that the highest the publishing rate the less the nodes that I get as an output. And to connect it to the initial question, it seems that when the nodes are less things work better or more clearly, for example when the publishing rate is set to 0.001 many more nodes are being created and there are misalignment issues but when the publishing rate is too high the registration is clean with no misalignment but with poor point density. For every test the detection rate remains at 0.

When I play the bag with publishing rate of 1 I get 84 nodes and with publishing rate set at  0.05 I get 793 nodes.

I try to understand why is this happening. First of all, since the ICP parameters seem to be working at the sparser data, I can not understand why is not this the case when the data are not sparse (publish rate 0.001 for example), is it possible to set the publishing rate too low?

Also, I understand that rtabmap "catches" a scan and starts working on it and after it is done with it it starts with the next scan that is passed at the current moment so this is why it gets sparser with less nodes, am I correct?

If you need need extra information, feel free to ask everything that would be helpful to examine the case.

Thank you in advance,
Anthony

[matlabbe]

Hi Anthony,

It is difficult to see the issue without the bag, but I feel that --OdomF2M/ScanMaxSize 100000000 is quite huge. The highest I tried is 60000. Indoor, Icp/MaxCorrespondenceDistance could also be decreased to 0.5 (while you are using 0.25 voxels).

For the rate, it depends if icp_odometry adds new a keyframe every frame, if so there could more drift over time than when using less scans. --Odom/ScanKeyFrameThr could be decreased to add less often new keyframes.

cheers,
Mathieu