Incomplete depth cloud and no loop closures with Realsense R200
Posted by danmou on
URL: http://official-rtab-map-forum.206.s1.nabble.com/Incomplete-depth-cloud-and-no-loop-closures-with-Realsense-R200-tp2934.html
Hi Mathieu,
First of all, thanks for your awesome work with RTAB-Map! It is nice to see a piece of open-source software that is both well-developed and well-supported.
I'm using RTAB-Map with the Intel Realsense R200 on the lowest depth resolution (320x240) because I need the minimum depth of 31cm which that gives (and I don't have much processing power available either). However, I'm having two issues, which I think could be related:
1. In rtabmapviz the depth cloud seems to be missing points, giving sort of a checkerboard pattern:
The pattern becomes less apparent as the robot drives around, because it seems to be fixed relative to the camera.
I think it might be related to the way the depth image is upsampled in the registration process:
As can be seen above, 3/4 of the pixels are missing because the rgb image is 640x480, but I don't know why this would lead to the larger checkerboard pattern seen in rtabmapviz (is it just a rendering artifact?).
2. The other problem, which is more critical, is that I have not been able to get a single loop closure. The loop closure view in rtabmapviz stays blank even though I drive the robot back to the same places, and statistics shows both zero loop closures detected and zero rejected. I haven't been able to find the correct parameter to make it detect loop closures more easily. Could the problem be caused by the lacking depth data?
The robot is quite small and it also navigates in a fairly small area (it's supposed to stay within a 4x5m area) but the odometry is not great so I need some loop closures to get a more accurate map. I am not using visual odometry because there was too much delay and it would loose tracking too easily. Also, if I try to fuse the visual odometry with wheel odometry and IMU using robot_localization, the location jumps around a fair bit, even when the robot is standing still - which seems to indicate that the VO is underreporting its covariance?
I still run the odometry node, because it is needed to be able to get loop closures right? Is there a way to optimize it so it uses less CPU when I am not using it for odometry?
Thanks,
Daniel
URL: http://official-rtab-map-forum.206.s1.nabble.com/Incomplete-depth-cloud-and-no-loop-closures-with-Realsense-R200-tp2934.html
Hi Mathieu,
First of all, thanks for your awesome work with RTAB-Map! It is nice to see a piece of open-source software that is both well-developed and well-supported.
I'm using RTAB-Map with the Intel Realsense R200 on the lowest depth resolution (320x240) because I need the minimum depth of 31cm which that gives (and I don't have much processing power available either). However, I'm having two issues, which I think could be related:
1. In rtabmapviz the depth cloud seems to be missing points, giving sort of a checkerboard pattern:
The pattern becomes less apparent as the robot drives around, because it seems to be fixed relative to the camera.
I think it might be related to the way the depth image is upsampled in the registration process:
As can be seen above, 3/4 of the pixels are missing because the rgb image is 640x480, but I don't know why this would lead to the larger checkerboard pattern seen in rtabmapviz (is it just a rendering artifact?).
2. The other problem, which is more critical, is that I have not been able to get a single loop closure. The loop closure view in rtabmapviz stays blank even though I drive the robot back to the same places, and statistics shows both zero loop closures detected and zero rejected. I haven't been able to find the correct parameter to make it detect loop closures more easily. Could the problem be caused by the lacking depth data?
The robot is quite small and it also navigates in a fairly small area (it's supposed to stay within a 4x5m area) but the odometry is not great so I need some loop closures to get a more accurate map. I am not using visual odometry because there was too much delay and it would loose tracking too easily. Also, if I try to fuse the visual odometry with wheel odometry and IMU using robot_localization, the location jumps around a fair bit, even when the robot is standing still - which seems to indicate that the VO is underreporting its covariance?
I still run the odometry node, because it is needed to be able to get loop closures right? Is there a way to optimize it so it uses less CPU when I am not using it for odometry?
Thanks,
Daniel
| Free forum by Nabble | Edit this page |