search

stereolabs / zed-ros-wrapper

ROS wrapper for the ZED SDK
https://www.stereolabs.com/docs/ros/
MIT License
447 stars 391 forks source link

General subscription to ROS::TIME in zed-wrapper-nodelt to avoid TF error lockup issues. #881

Closed khansel01 closed 1 year ago

khansel01 commented 1 year ago

Preliminary Checks

Proposal

Hello all,

I use the ZED2 camera mounted on a robot head to get stereo vision. I have adjusted the URDF files accordingly, and everything is running smoothly.

For testing, I wanted to check the tf tree. Therefore I started gazebo and launched the zed-wrapper and rviz. The robot is displayed correctly and no error message appears in the tf tree. However, when I try to project data, e.g. a point cloud or images into the base frame, I see the following error message: 

Transform [sender=unknown_editor].
For frame [zed2_left_camera_frame]: No transform to fixed frame [base_link]. TF error: [Lookup would require extrapolation into the future. Requested time 16784588.237012675, but most recent data is currently 42.912000000 when looking up transformation from frame [zed2_left_camera_frame] to frame [base_link]].

The problem is caused because Gazebo uses its own clock while ZED still uses wall time. Therefore, the ZED point cloud expects a transformation from zed2_left_camera_frame to base_link at wall time 1678458888.237012675. However, the base link comes from the pavilion simulation at ROS time 42.9120000.

I solved the problem by adding a sim_true flag that uses the ROS time in the zed-wrapper-node. Like you did with the mSvoMode when playing back logged svo data.

I am curious if it is possible that zed_ros_nodelt (called from zed-wrapper-node) subscribes to the ROS clock in general. When we work on a real robot, the ROS time corresponds to the wall clock time, and everything works smoothly. However, when we work in simulation, e.g., when testing, the simulator time is used.

Would you mind sharing why you do not use the ROS::time in general?

Use-Case

Testing of implemented algorithms in the simulation, which also require ZED data, but without starting the real robot.

Anything else?

No response

Myzhar commented 1 year ago

Hi @khansel01 What you are saying makes sense for your configuration, but it's not good in general because there's no available simulated ZED sensors in Gazebo that can be used with the ZED node. I suggest you modify the source code according to your requirements, that's the advantage of the open source code.

khansel01 commented 1 year ago

Thanks @Myzhar for the reply. I agree that it isn't good in general.

I got it to work by using the ROS timestamp (ROS:Time:now()) instead of the stereo-labs one (sl_tools::slTime2Ros(mZed.getTimestamp(sl::TIME_REFERENCE::CURRENT))) in the zed-wrapper.

I also found the following issue that answered my questions about why we use the Stereolab time stamp and do not use the ROS timestamp in general.