Gaining understanding in the many different filter parameters and options

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Gaining understanding in the many different filter parameters and options

This post was updated on .

I am trying to gain understanding in the many different filter option that exist within icp_odometry and rtabmap, as we are trying to improve the density of our final outputs cloud_map and ocotmap. I started investigating the source code of icp_odometry, but noticed a few strange things.

Our setup uses two 3d lidars that have their pointclouds merged using rtabmap_ros/point_cloud_aggregator.

To sketch the confusion I have, I listed the parameters related to filtering we currently use:
scan_voxel_size: 0.2
Grid/CellSize: 0.05
Icp/VoxelSize: 0.3
OdomF2M/ScanSubtractRadius: 0.5

and the warnings I get

[ WARN] [1659084452.098338173]: IcpOdometry: Both parameter "Icp/VoxelSize" and ros parameter "scan_voxel_size" are set.
[ WARN] [1659084452.435670922]: Parameter "scan_voxel_size" has moved from rtabmap_ros to rtabmap library. Use parameter "Grid/CellSize" instead. The value is still copied to new parameter name.

The first warning I found in In our case we have set both parameters to different values. For icp_odometry.cpp this means that scan_voxel_size (internal variable: scanVoxelSize_) is used in several voxalize steps.

Q1: Does this mean that we filter twice with different values? Once in icp_odometry.cpp (rtabmap_ros) via scan_voxel_size and later again in RegistrationIcp.cpp (rtabmap) using Icp/VoxelSize for commonFiltering()?
Q2: In some cases of the conditional statements in, the Icp/VoxelSize is set to 0. Is this done to prevent filtering twice?

The second warning confuses me further as it suggests that scan_voxel_size is no longer in use. However, from the previous warning and questions we notice it is still in use. I found this warning in Eventhough, this line ( links scan_voxel_size to Grid/CellSize, Grid/CellSize seems to affect a different part of the code, namely, the ocotmap parts in OctoMap.cpp (rtabmap) and OccupancyGrid.cpp (rtabmap).

Q3: Could you clarify if and how the ROS parameter scan_voxel_size has been replaced by Grid/CellSize and how this affects Icp/VoxelSize, as this parameter is also linked to scan_voxel_size?
Q4: Besides these parameters I find other parameters that might do something similar: scan_downsampling_step, Icp/DownsamplingStep, OdomF2M/ScanSubtractRadius, OdomF2M/ScanMaxSize, Grid/PreVoxelFiltering, etc. And at this point I am unable to debug the system as I don't know in which order the filters are applied.

My guess so far for icp_odometry: downsample (using scan_downsampling_step or Icp/DownsamplingStep), voxalize (using scan_voxel_size or Icp/VoxelSize), range filter (using scan_range_min or Icp/RangeMin and scan_range_max or Icp/RangeMax). rtabmap's filters I didn't look at yet.

Q5: As you notice from my guess to Q4's icp_odometry part, there are many duplicate parameters that give rise to a similar questions to Q1. Are filters in some cases applied twice: once in icp_odometry.cpp (ROS layer) and later in the core library during ICP registration? And how about the rtabmap node if we currently load the same settings there, is the filtering then repeated?
Q6: As Grid/RayTracing also functions as a filter on octomap, which we would like to use for dynamic obstacle removal, we wonder how this is done for an aggragated point cloud, which is assembled with two different points of origin. Is this taken into account in the raytracing algorithm or do we unknowingly use an unkown single point of origin?
Q7: As for tuning, I noticed that this example uses the same cell_size for multiple different filter steps, is this recommended and why?

Thank you in advance :)