View my account

D435I IMU ISSUE

Comments

8 comments

  • MartyX Grover

    Hi Kimda0  The log states that your camera is being detected as being on a USB 2.1 connection instead of USB 3, which may reduce performance as a USB 2.1 connection is slower.

    [INFO] [1659501073.909382698]: Device USB type: 2.1

    [ WARN] [1659501073.909398538]: Device 040322073715 is connected using a 2.1 port.  Reduced performance is expected.

     

    The documentation of Intel's D435i SLAM guide for ROS that uses opensource_tracking.launch also cautions against making fast turns or movement.

    https://github.com/IntelRealSense/realsense-ros/wiki/SLAM-with-D435i

     

    **********

     

    The built-in IMU can only keep track for a very short time.  Moving or turning too quickly will break the sequence of successful point cloud matches and will result in the system losing track.  It could happen that the system will recover immediately if stopped moving but if not, the longer the time passed since the break, the farther away it will drift from the correct position.  The odds for recovery get very slim, very quickly.  The parameters set in the launch file are most likely not ideal but this is a good starting point for calibrating

    0
    Comment actions Permalink
  • Kimda0

    Thank you for your answer. But even when the cam is not moving at all, the current position on the rviz rotates here and there.
    And is it an error in rtabmap that I wrote terminal warning below?
    May I know the solution?

     

    03/08 17:38:47,127 WARNING [140051023390464] (messenger-libusb.cpp:42) control_transfer returned error, index: 300, error: Resource temporarily unavailable, number: b
    [ WARN] [1659515927.558956940]: /rtabmap/rtabmap: Did not receive data since 5 seconds! Make sure the input topics are published ("$ rostopic hz my_topic") and the timestamps in their header are set. If topics are coming from different computers, make sure the clocks of the computers are synchronized ("ntpdate"). If topics are not published at the same rate, you could increase "queue_size" parameter (current=10).
    /rtabmap/rtabmap subscribed to (approx sync):
       /rtabmap/odom \
       /camera/color/image_raw \
       /camera/aligned_depth_to_color/image_raw \
       /camera/color/camera_info \
       /rtabmap/odom_info
    [ WARN] [1659515932.078102902]: /rtabmap/rgbd_odometry: Did not receive data since 5 seconds! Make sure the input topics are published ("$ rostopic hz my_topic") and the timestamps in their header are set.
    /rtabmap/rgbd_odometry subscribed to (approx sync):
       /camera/color/image_raw \
       /camera/aligned_depth_to_color/image_raw \
       /camera/color/camera_info
    [ WARN] [1659515932.559120776]: /rtabmap/rtabmap: Did not receive data since 5 seconds! Make sure the input topics are published ("$ rostopic hz my_topic") and the timestamps in their header are set. If topics are coming from different computers, make sure the clocks of the computers are synchronized ("ntpdate"). If topics are not published at the same rate, you could increase "queue_size" parameter (current=10).
    /rtabmap/rtabmap subscribed to (approx sync):
       /rtabmap/odom \
       /camera/color/image_raw \
       /camera/aligned_depth_to_color/image_raw \
       /camera/color/camera_info \
       /rtabmap/odom_info
    [ WARN] [1659515936.199965931]: Still waiting for data on topics /imu/data_raw and /imu/mag...
    [ WARN] [1659515937.078309989]: /rtabmap/rgbd_odometry: Did not receive data since 5 seconds! Make sure the input topics are published ("$ rostopic hz my_topic") and the timestamps in their header are set.
    /rtabmap/rgbd_odometry subscribed to (approx sync):
       /camera/color/image_raw \
       /camera/aligned_depth_to_color/image_raw \
       /camera/color/camera_info
    [ WARN] [1659515937.559328997]: /rtabmap/rtabmap: Did not receive data since 5 seconds! Make sure the input topics are published ("$ rostopic hz my_topic") and the timestamps in their header are set. If topics are coming from different computers, make sure the clocks of the computers are synchronized ("ntpdate"). If topics are not published at the same rate, you could increase "queue_size" parameter (current=10).
    /rtabmap/rtabmap subscribed to (approx sync):
       /rtabmap/odom \
       /camera/color/image_raw \
       /camera/aligned_depth_to_color/image_raw \
       /camera/color/camera_info \
       /rtabmap/odom_info
    [ WARN] [1659515942.078490458]: /rtabmap/rgbd_odometry: Did not receive data since 5 seconds! Make sure the input topics are published ("$ rostopic hz my_topic") and the timestamps in their header are set.
    /rtabmap/rgbd_odometry subscribed to (approx sync):
       /camera/color/image_raw \
       /camera/aligned_depth_to_color/image_raw \
       /camera/color/camera_info
    [ WARN] [1659515942.559533702]: /rtabmap/rtabmap: Did not receive data since 5 seconds! Make sure the input topics are published ("$ rostopic hz my_topic") and the timestamps in their header are set. If topics are coming from different computers, make sure the clocks of the computers are synchronized ("ntpdate"). If topics are not published at the same rate, you could increase "queue_size" parameter (current=10).
    /rtabmap/rtabmap subscribed to (approx sync):
       /rtabmap/odom \
       /camera/color/image_raw \
       /camera/aligned_depth_to_color/image_raw \
       /camera/color/camera_info \
       /rtabmap/odom_info

    0
    Comment actions Permalink
  • Kimda0

    The cause was a port problem. Resolved! Thank you.

    0
    Comment actions Permalink
  • MartyX Grover

    It's great to hear that you achieved a solution.  Thanks for the update!

    0
    Comment actions Permalink
  • Ian Riera

    Hello Kimda0 , I'm having the same problem with a d455, that the rviz position moves even with a still camera. How did you manage to solve that problem? Thank you.

    0
    Comment actions Permalink
  • MartyG

    Hi Ian Riera  IMU data can be 'noisy' and prone to fluctuation.  You can use a Python-based IMU calibration tool (at the link below) to calibrate the IMU and save the result to the camera hardware.

    https://github.com/IntelRealSense/librealsense/tree/master/tools/rs-imu-calibration

     

    0
    Comment actions Permalink
  • Ian Riera

    Hi MartyG, thanks for the tutorial, it is well explained and quite smart solution (using the box). However, the rtabmap keeps moving even with the still camera, specially when scanning flat homogeneous surfaces (where it is expected to struggle).

    0
    Comment actions Permalink
  • MartyG

    If the camera is observing a low-detail scene with rtabmap_ros then the warning "Not enough inliers" may occur.  Have you experienced that warning, please?  If you have then stability of tracking may improve if you provide the camera with an "interesting" scene to look at (i.e one that is not too empty of objects and surfaces) and to keep the camera looking at such a scene.

     

    A RealSense ROS wrapper developer also advised switching to rtabmap's pointcloud and using topic /voxel_cloud and frame_id map

     

    An rtabmap_ros guide at the link below provides an example of how to switch to /voxel_cloud.

    http://wiki.ros.org/rtabmap_ros/Tutorials/SetupOnYourRobot#rviz-1

    0
    Comment actions Permalink

Please sign in to leave a comment.