Re: Troubleshooting mapping with kinect v2, rplidar and jetson tx2

Posted by matlabbe on
URL: http://official-rtab-map-forum.206.s1.nabble.com/Troubleshooting-mapping-with-kinect-v2-rplidar-and-jetson-tx2-tp5517p5612.html


For the topic name /rgbd_image/compressed, maybe I typed wrong the output remapping in this code:

<!-- pre-sync kinect images before sending them over network -->
<node pkg="nodelet" type="nodelet" name="rgbd_sync" args="load rtabmap_ros/rgbd_sync kinect2">
    <remap from="rgb/image"         to="/kinect2/qhd/data_throttled_image"/>
    <remap from="depth/image"       to="/kinect2/qhd/data_throttled_image_depth"/>
    <remap from="rgb/camera_info"   to="/kinect2/qhd/data_throttled_camera_info"/>
    <remap from="rgbd_image"        to="/rtabmap/rgbd_image"/> <!-- output -->
    <param name="approx_sync"       value="false"/>   <!-- exact sync for kinect2 topics -->
</node>

Make sure that approx_sync is false in both data_throttle and rgbd_sync. To make sure its the correct images that are synchronized, you may even echo the stamp for those topics and see if they have all the same stamps:

$ rostopic echo /kinect2/qhd/data_throttled_image/header/stamp
$ rostopic echo /kinect2/qhd/data_throttled_image_depth/header/stamp
$ rostopic echo /kinect2/qhd/data_throttled_camera_info/header/stamp

The registration between color and depth seems okay when not moving. The registration is independent of the odometry. IF the stamps are equal between color and depth image and they don't match when the robot is moving, this is mostly an issue coming from kinect2_bridge that is not able to process enough fast the frames coming from USB3. Is kinect2_bridge built with CUDA support for depth processing and opencl for registration?

cheers,
Mathieu