search

luxonis / depthai-ros

Official ROS Driver for DepthAI Sensors.
MIT License
238 stars 172 forks source link

Accel data not found. Dropping data from OAK-D (humble-v2.7.0) #278

Open Embedded1993 opened 1 year ago

Embedded1993 commented 1 year ago

Check if issue already exists I check but I can't anything

Describe the bug I'm trying to run stereo_inertial_node.launch.py on Raspberry Pi 4(Ubuntu 22.04, Depthai-ros humble v2.7.0 ) But I'm getting these warning message.

[stereo_inertial_node-2] Device USB status: SUPER [rviz2-4] [INFO] [1680761254.478996620] [rviz2]: Stereo is NOT SUPPORTED [rviz2-4] [INFO] [1680761254.480716590] [rviz2]: OpenGl version: 4.5 (GLSL 4.5) [rviz2-4] [INFO] [1680761260.239201318] [rviz2]: Stereo is NOT SUPPORTED [component_container-3] [WARN] [1680761260.852396817] [point_cloud_xyzrgb_node]: New subscription discovered on topic '/stereo/points', requesting incompatible QoS. No messages will be sent to it. Last incompatible policy: RELIABILITY_QOS_POLICY [rviz2-4] [INFO] [1680761269.411916689] [rviz2]: Stereo is NOT SUPPORTED [stereo_inertial_node-2] [WARN] [1680761292.300578585] [IMU INTERPOLATION: ]: Accel data not found. Dropping data [stereo_inertial_node-2] [WARN] [1680761325.237649197] [IMU INTERPOLATION: ]: Accel data not found. Dropping data [stereo_inertial_node-2] [WARN] [1680761387.052965352] [IMU INTERPOLATION: ]: Accel data not found. Dropping data [stereo_inertial_node-2] [WARN] [1680761411.059457041] [IMU INTERPOLATION: ]: Accel data not found. Dropping data [stereo_inertial_node-2] [WARN] [1680761438.817423207] [IMU INTERPOLATION: ]: Accel data not found. Dropping data [stereo_inertial_node-2] [WARN] [1680761445.537712292] [IMU INTERPOLATION: ]: Accel data not found. Dropping data [stereo_inertial_node-2] [WARN] [1680761456.934432074] [IMU INTERPOLATION: ]: Accel data not found. Dropping data

Minimal Reproducible Example it works fine when run python3 depthai_demo.py

Expected behavior want to see Accel and Gyro data

Screenshots image

Pipeline Graph image

Attach system log

Package: ros-humble-depthai-ros Version: 2.6.4-1jammy.20230303.010530 Priority: optional Section: misc Maintainer: sachin sachin@luxonis.com Installed-Size: 42.0 kB Depends: ros-humble-depthai, ros-humble-depthai-bridge, ros-humble-depthai-examples, ros-humble-depthai-ros-driver, ros-humble-depthai-ros-msgs, ros-humble-ros-workspace Download-Size: 5232 B APT-Sources: http://repo.ros2.org/ubuntu/main jammy/main arm64 Packages Description: The depthai-ros package

Package: ros-humble-depthai-bridge Version: 2.6.4-1jammy.20230302.223904 Priority: optional Section: misc Maintainer: Sachin Guruswamy sachin@luxonis.com Installed-Size: 69.4 MB Depends: libc6 (>= 2.32), libgcc-s1 (>= 3.3.1), libopencv-core4.5d (>= 4.5.4+dfsg), libopencv-imgcodecs4.5d (>= 4.5.4+dfsg), libopencv-imgproc4.5d (>= 4.5.4+dfsg), libstdc++6 (>= 11), libboost-dev, libopencv-dev, ros-humble-camera-info-manager, ros-humble-cv-bridge, ros-humble-depthai, ros-humble-depthai-ros-msgs, ros-humble-image-transport, ros-humble-rclcpp, ros-humble-robot-state-publisher, ros-humble-ros-environment, ros-humble-sensor-msgs, ros-humble-std-msgs, ros-humble-stereo-msgs, ros-humble-vision-msgs, ros-humble-xacro, ros-humble-ros-workspace Download-Size: 13.4 MB APT-Sources: http://repo.ros2.org/ubuntu/main jammy/main arm64 Packages Description: The depthai_bridge package

Package: ros-humble-depthai-ros-msgs Version: 2.6.4-1jammy.20230302.210403 Priority: optional Section: misc Maintainer: Sachin Guruswamy sachin@luxonis.com Installed-Size: 1310 kB Depends: libc6 (>= 2.17), libgcc-s1 (>= 3.3.1), libpython3.10 (>= 3.10.0), libstdc++6 (>= 11), ros-humble-fastcdr, ros-humble-builtin-interfaces, ros-humble-geometry-msgs, ros-humble-rclcpp, ros-humble-rosidl-default-generators, ros-humble-sensor-msgs, ros-humble-std-msgs, ros-humble-vision-msgs, ros-humble-ros-workspace Download-Size: 106 kB APT-Sources: http://repo.ros2.org/ubuntu/main jammy/main arm64 Packages Description: Package to keep interface independent of the driver

Package: ros-humble-depthai-ros-driver Version: 2.6.4-1jammy.20230303.005120 Priority: optional Section: misc Maintainer: Adam Serafin adam.serafin@luxonis.com Installed-Size: 844 kB Depends: libc6 (>= 2.34), libconsole-bridge1.0 (>= 1.0.1+dfsg2), libgcc-s1 (>= 3.3.1), libopencv-core4.5d (>= 4.5.4+dfsg), libopencv-imgproc4.5d (>= 4.5.4+dfsg), libopencv-stitching4.5d (>= 4.5.4+dfsg), libstdc++6 (>= 11), ros-humble-ament-cmake-auto, ros-humble-camera-calibration, ros-humble-cv-bridge, ros-humble-depthai, ros-humble-depthai-bridge, ros-humble-diagnostic-msgs, ros-humble-image-pipeline, ros-humble-image-transport, ros-humble-image-transport-plugins, ros-humble-rclcpp, ros-humble-rclcpp-components, ros-humble-sensor-msgs, ros-humble-std-msgs, ros-humble-std-srvs, ros-humble-vision-msgs, ros-humble-ros-workspace Download-Size: 213 kB APT-Sources: http://repo.ros2.org/ubuntu/main jammy/main arm64 Packages Description: Depthai ROS Monolithic node.

component_container_41778_1680763615275.log launch.log python3_41759_1680763614807.log robot_state_publisher_41774_1680763615233.log rviz2_41780_1680763616955.log stereo_inertial_node_41776_1680763615645.log

saching13 commented 1 year ago

It's just dropping a gyro reading where accelerometer readings are not there for timestamp around it. You can Ignore it.

Embedded1993 commented 1 year ago

New subscription discovered on topic '/stereo/points', requesting incompatible QoS. No messages will be sent to it. Last incompatible policy: RELIABILITY_QOS_POLICY

Can I ignore it?

Embedded1993 commented 1 year ago

https://github.com/introlab/rtabmap/issues/742#issuecomment-1259965385

I'm trying to run it.

saching13 commented 1 year ago

There is a launch file for rtabmap in depthai_ros_driver. Try that.

Embedded1993 commented 1 year ago

I tried rtabmap in depthai_ros_driver. So I'm getting this warnings

[rgbd_odometry-1] [WARN] [1680765628.850452548] [rgbd_odometry]: The time difference between rgb and depth frames is high (diff=0.133347s, rgb=1680765627.328484s, depth=1680765627.461831s). You may want to set approx_sync_max_interval lower than 0.02s to reject spurious bad synchronizations or use approx_sync=false if streams have all the exact same timestamp.

I'm waite sometime. Thenk showing this errors

[rtabmap-2] [ERROR] (2023-04-06 07:59:27.617) Rtabmap.cpp:1336::process() RGB-D SLAM mode is enabled, memory is incremental but no odometry is provided. Image 0 is ignored! [rtabmap-2] [ERROR] (2023-04-06 07:59:29.023) Rtabmap.cpp:1336::process() RGB-D SLAM mode is enabled, memory is incremental but no odometry is provided. Image 0 is ignored! [rtabmap-2] [ERROR] (2023-04-06 07:59:29.718) Rtabmap.cpp:1336::process() RGB-D SLAM mode is enabled, memory is incremental but no odometry is provided. Image 0 is ignored! [rtabmap-2] [ERROR] (2023-04-06 07:59:32.345) Rtabmap.cpp:1336::process() RGB-D SLAM mode is enabled, memory is incremental but no odometry is provided. Image 0 is ignored! [rtabmap-2] [ERROR] (2023-04-06 07:59:33.620) Rtabmap.cpp:1336::process() RGB-D SLAM mode is enabled, memory is incremental but no odometry is provided. Image 0 is ignored! [rtabmap-2] [ERROR] (2023-04-06 07:59:33.981) Rtabmap.cpp:1336::process() RGB-D SLAM mode is enabled, memory is incremental but no odometry is provided. Image 0 is ignored! [rtabmap-2] [ERROR] (2023-04-06 07:59:37.330) Rtabmap.cpp:1336::process() RGB-D SLAM mode is enabled, memory is incremental but no odometry is provided. Image 0 is ignored!

And these warnings

[rtabmapviz-3] [ WARN] (2023-04-06 08:00:00.606) MsgConversion.cpp:1758::getTransform() (can transform odom -> oak?) Lookup would require extrapolation at time 1680767998.818713, but only time 1680767726.512583 is in the buffer, when looking up transform from frame [oak] to frame [odom]. canTransform returned after 0.204091 timeout was 0.2. (wait_for_transform=0.200000) [rtabmapviz-3] [ WARN] (2023-04-06 08:00:01.469) MsgConversion.cpp:1758::getTransform() (can transform odom -> oak?) Lookup would require extrapolation at time 1680767999.185340, but only time 1680767726.512583 is in the buffer, when looking up transform from frame [oak] to frame [odom]. canTransform returned after 0.206413 timeout was 0.2. (wait_for_transform=0.200000) [rtabmapviz-3] [ WARN] (2023-04-06 08:00:01.972) MsgConversion.cpp:1758::getTransform() (can transform odom -> oak?) Lookup would require extrapolation at time 1680767999.552006, but only time 1680767726.512583 is in the buffer, when looking up transform from frame [oak] to frame [odom]. canTransform returned after 0.205473 timeout was 0.2. (wait_for_transform=0.200000)

And

[rgbd_odometry-1] [WARN] [1680768005.153934941] [rgbd_odometry]: The time difference between rgb and depth frames is high (diff=0.100023s, rgb=1680768004.185086s, depth=1680768004.285109s). You may want to set approx_sync_max_interval lower than 0.02s to reject spurious bad synchronizations or use approx_sync=false if streams have all the exact same timestamp. [rgbd_odometry-1] [INFO] [1680768005.693437468] [rgbd_odometry]: Odom: quality=0, std dev=0.000000m|0.000000rad, update time=0.490479s [rgbd_odometry-1] [WARN] [1680768005.701923551] [rgbd_odometry]: The time difference between rgb and depth frames is high (diff=0.066649s, rgb=1680768004.785063s, depth=1680768004.718414s). You may want to set approx_sync_max_interval lower than 0.02s to reject spurious bad synchronizations or use approx_sync=false if streams have all the exact same timestamp.

sagarvl96 commented 11 months ago

Hello @Embedded1993! Did you resolve this issue? I looked into my tf tree and the problem is that the odom frame is always decoupled from the oak-d-base frame. I have no idea how to solve this. Do you have any idea? My tf tree:

Screenshot from 2023-07-06 15-39-50

Maybe @saching13 could suggest where the problem might be?

saching13 commented 11 months ago

^ @Serafadam

Serafadam commented 11 months ago

Hi @sagarvl96, what's your exact setup?

sagarvl96 commented 11 months ago

Hello @Serafadam!

I am using Ubuntu 22.04.2 LTS. I am running it on the ROS2 Humble. I installed the depthai_ros_driver package from rosdep. The versions of depthai packages I am using are as follows:

Package: ros-humble-depthai Version: 2.22.0-1jammy.20230623.022440

Package: ros-humble-depthai-ros Version: 2.7.3-1jammy.20230624.064620

Package: ros-humble-depthai-bridge Version: 2.7.3-1jammy.20230623.090046

Package: ros-humble-depthai-ros-msgs Version: 2.7.3-1jammy.20230623.055642

Package: ros-humble-depthai-ros-driver Version: 2.7.3-1jammy.20230624.063735

I launched the rtabmap by running the following command: ros2 launch depthai_ros_driver rtabmap.launch.py (I have not made any changes to the parameters)

I am using the OAK-D-S2 USB camera. I have installed the camera on a robot and I am trying to map out the entire floor of a building.

Please let me know if I am missing any other information and I would be glad to share it with you!

This warning is continuously printed:

[component_container-2] [WARN] [1689002971.249866959] [rgbd_odometry]: The time difference between rgb and depth frames is high (diff=0.033365s, rgb=1689002971.121193s, depth=1689002971.154558s). You may want to set approx_sync_max_interval lower than 0.02s to reject spurious bad synchronizations or use approx_sync=false if streams have all the exact same timestamp. [rtabmap_viz-3] [ WARN] (2023-07-10 15:29:28.667) MsgConversion.cpp:1758::getTransform() (can transform odom -> oak?) Lookup would require extrapolation at time 1689002968.321415, but only time 1689002847.290599 is in the buffer, when looking up transform from frame [oak] to frame [odom]. canTransform returned after 0.202297 timeout was 0.2. (wait_for_transform=0.200000) [rtabmap_viz-3] [ WARN] (2023-07-10 15:29:28.871) MsgConversion.cpp:1758::getTransform() (can transform odom -> oak?) Lookup would require extrapolation at time 1689002968.488068, but only time 1689002847.290599 is in the buffer, when looking up transform from frame [oak] to frame [odom]. canTransform returned after 0.202614 timeout was 0.2. (wait_for_transform=0.200000) [rtabmap_viz-3] [ WARN] (2023-07-10 15:29:29.172) MsgConversion.cpp:1758::getTransform() (can transform odom -> oak?) Lookup would require extrapolation at time 1689002968.821391, but only time 1689002847.290599 is in the buffer, when looking up transform from frame [oak] to frame [odom]. canTransform returned after 0.202546 timeout was 0.2. (wait_for_transform=0.200000) [rtabmap_viz-3] [ WARN] (2023-07-10 15:29:29.379) MsgConversion.cpp:1758::getTransform() (can transform odom -> oak?) Lookup would require extrapolation at time 1689002968.988056, but only time 1689002847.290599 is in the buffer, when looking up transform from frame [oak] to frame [odom]. canTransform returned after 0.202516 timeout was 0.2. (wait_for_transform=0.200000) [rtabmap_viz-3] [ WARN] (2023-07-10 15:29:29.583) MsgConversion.cpp:1758::getTransform() (can transform odom -> oak?) Lookup would require extrapolation at time 1689002969.221381, but only time 1689002847.290599 is in the buffer, when looking up transform from frame [oak] to frame [odom]. canTransform returned after 0.201878 timeout was 0.2. (wait_for_transform=0.200000) [rtabmap_viz-3] [ WARN] (2023-07-10 15:29:29.860) MsgConversion.cpp:1758::getTransform() (can transform odom -> oak?) Lookup would require extrapolation at time 1689002969.521363, but only time 1689002847.290599 is in the buffer, when looking up transform from frame [oak] to frame [odom]. canTransform returned after 0.202663 timeout was 0.2. (wait_for_transform=0.200000) [rtabmap_viz-3] [ WARN] (2023-07-10 15:29:30.064) MsgConversion.cpp:1758::getTransform() (can transform odom -> oak?) Lookup would require extrapolation at time 1689002969.688019, but only time 1689002847.290599 is in the buffer, when looking up transform from frame [oak] to frame [odom]. canTransform returned after 0.202606 timeout was 0.2. (wait_for_transform=0.200000) [rtabmap_viz-3] [ WARN] (2023-07-10 15:29:30.268) MsgConversion.cpp:1758::getTransform() (can transform odom -> oak?) Lookup would require extrapolation at time 1689002969.888013, but only time 1689002847.290599 is in the buffer, when looking up transform from frame [oak] to frame [odom]. canTransform returned after 0.202471 timeout was 0.2. (wait_for_transform=0.200000) [rtabmap_viz-3] [ WARN] (2023-07-10 15:29:30.472) MsgConversion.cpp:1758::getTransform() (can transform odom -> oak?) Lookup would require extrapolation at time 1689002970.087991, but only time 1689002847.290599 is in the buffer, when looking up transform from frame [oak] to frame [odom]. canTransform returned after 0.202335 timeout was 0.2. (wait_for_transform=0.200000) [rtabmap_viz-3] [ WARN] (2023-07-10 15:29:30.757) MsgConversion.cpp:1758::getTransform() (can transform odom -> oak?) Lookup would require extrapolation at time 1689002970.421311, but only time 1689002847.290599 is in the buffer, when looking up transform from frame [oak] to frame [odom]. canTransform returned after 0.202737 timeout was 0.2. (wait_for_transform=0.200000) [rtabmap_viz-3] [ WARN] (2023-07-10 15:29:30.961) MsgConversion.cpp:1758::getTransform() (can transform odom -> oak?) Lookup would require extrapolation at time 1689002970.587931, but only time 1689002847.290599 is in the buffer, when looking up transform from frame [oak] to frame [odom]. canTransform returned after 0.20227 timeout was 0.2. (wait_for_transform=0.200000)

tolas92 commented 6 months ago

hello i am also facing the same issue, any updates on this?