Improving a lidar-only setup
Posted by Robin on
URL: http://official-rtab-map-forum.206.s1.nabble.com/Improving-a-lidar-only-setup-tp11071.html
Hi,
We're using a Livox Mid360 as the single sensor with rtabmap.
For mapping, we use its IMU for the guess frame for icp_odometry, which in turn provides the odom frame for rtabmap.
For localization, we use wheel odometry instead (250Hz and very accurate) and don't use the IMU or icp_odometry anymore.
Rtabmap is running at 1Hz, the livox pointcloud output is running at 10Hz (we don't assemble pointclouds).
Lidar deskewing is set up and synced with the Livox clock using PTP.
This gif is rviz visualizing the deskewed lidar topic in the odometry frame (tf2) (no rtabmap here, just visualizing the input for rtabmap), I see barely any theta accumulation error and neither do I see distortion in the scan, so I assume this is set up correctly.
The area we're working in is a warehouse with ceiling about 30m high and walls 50m away. The majority the livox sees is those and some large pillars, as there's very little tall structures above 2m of the ground and the livox just sees a few parts below 2m above the ground. (and things there often change as well)
Now we're wondering how to improve the accuracy of rtabmap. It's a bit tricky to understand what parameters would improve/worsen certain observed problems. If you have input on any of these or general recommendations, that would be greatly appreciated.
1. Arriving on a location from opposing directions doesn't align up well sideways. For the same location the difference is very consistent (within 1cm), but the amount of consistent sideways difference varies from location to location (in ranges up to 15cm)
2. When driving towards a predefined location, the pose rtabmap reports is consistent within 1cm as long as the speed at which we arrived there is the same. If we drive faster towards there, the reported pose tends to lean more towards the right. (up to 10cm further to the right then driving there slowly). This difference is consistent on the same location, but other locations have a different consistent difference.
3. Scan assembling: I assume this is less useful during localization. However, can we have scan assembling during mapping and not during localization? Or does rtabmap require to get a similar scancloud as it got for keypoints?
4. The livox has 360 view, but let's say we mapped in a straight line going e.g. east, it seems that you can't localize in that map if you drive that straight line going west. I assume this is because the pose-graph doesn't related keypoints with different angles but with the same coordinates. Is there some setting to change that?
5. Variances for odometry: If we want rtabmap's 'best absolute pose guess' is it good to put these to e.g. 1e-1, to give higher weight to rtabmap's guess? The aim would be to get as consistent absolute poses regardless of how you got to that location. I would assume putting this to 1e-3 or 1e-4 would make it heavily dependent on odometry not making any mistakes.
6. Voxel size: Can we freely adjust these even if we use a map made at a different voxel size? (similar question for other parameters, are there some that are constrained by what you set them as during mapping?)
7. MaxCorrespondenceDistance: lowering/increasing this, what effect does this have on accuracy and/or rtabmap being able to keep tracking where it is?
We're running ros2 jazzy and using the rtabmap binaries.
The parameters we're using:
rtabmap.yaml
Example to hopefully clarify what I mean with the 'sideways' difference. Depending on speed and direction, the vehicle ends up differently (this is due to localization, not control of the robot, I verified)
URL: http://official-rtab-map-forum.206.s1.nabble.com/Improving-a-lidar-only-setup-tp11071.html
Hi,
We're using a Livox Mid360 as the single sensor with rtabmap.
For mapping, we use its IMU for the guess frame for icp_odometry, which in turn provides the odom frame for rtabmap.
For localization, we use wheel odometry instead (250Hz and very accurate) and don't use the IMU or icp_odometry anymore.
Rtabmap is running at 1Hz, the livox pointcloud output is running at 10Hz (we don't assemble pointclouds).
Lidar deskewing is set up and synced with the Livox clock using PTP.
This gif is rviz visualizing the deskewed lidar topic in the odometry frame (tf2) (no rtabmap here, just visualizing the input for rtabmap), I see barely any theta accumulation error and neither do I see distortion in the scan, so I assume this is set up correctly.
The area we're working in is a warehouse with ceiling about 30m high and walls 50m away. The majority the livox sees is those and some large pillars, as there's very little tall structures above 2m of the ground and the livox just sees a few parts below 2m above the ground. (and things there often change as well)
Now we're wondering how to improve the accuracy of rtabmap. It's a bit tricky to understand what parameters would improve/worsen certain observed problems. If you have input on any of these or general recommendations, that would be greatly appreciated.
1. Arriving on a location from opposing directions doesn't align up well sideways. For the same location the difference is very consistent (within 1cm), but the amount of consistent sideways difference varies from location to location (in ranges up to 15cm)
2. When driving towards a predefined location, the pose rtabmap reports is consistent within 1cm as long as the speed at which we arrived there is the same. If we drive faster towards there, the reported pose tends to lean more towards the right. (up to 10cm further to the right then driving there slowly). This difference is consistent on the same location, but other locations have a different consistent difference.
3. Scan assembling: I assume this is less useful during localization. However, can we have scan assembling during mapping and not during localization? Or does rtabmap require to get a similar scancloud as it got for keypoints?
4. The livox has 360 view, but let's say we mapped in a straight line going e.g. east, it seems that you can't localize in that map if you drive that straight line going west. I assume this is because the pose-graph doesn't related keypoints with different angles but with the same coordinates. Is there some setting to change that?
5. Variances for odometry: If we want rtabmap's 'best absolute pose guess' is it good to put these to e.g. 1e-1, to give higher weight to rtabmap's guess? The aim would be to get as consistent absolute poses regardless of how you got to that location. I would assume putting this to 1e-3 or 1e-4 would make it heavily dependent on odometry not making any mistakes.
6. Voxel size: Can we freely adjust these even if we use a map made at a different voxel size? (similar question for other parameters, are there some that are constrained by what you set them as during mapping?)
7. MaxCorrespondenceDistance: lowering/increasing this, what effect does this have on accuracy and/or rtabmap being able to keep tracking where it is?
We're running ros2 jazzy and using the rtabmap binaries.
The parameters we're using:
rtabmap.yaml
Example to hopefully clarify what I mean with the 'sideways' difference. Depending on speed and direction, the vehicle ends up differently (this is due to localization, not control of the robot, I verified)
| Free forum by Nabble | Edit this page |