tf_old_data warning by rtabmap - no map created

asked 2018-09-11 13:32:03 -0500

Boregard gravatar image

updated 2018-09-14 14:32:16 -0500

Hi, I have stereolabs ZED camera with ros_zed_wrapper and rtabmap_ros running on a ubuntu 16.04 kinetic installation. Both packages were built from source because rtabmapviz was crashing before.

Currently only the demo launches for RGBD Mapping are in use. ( http://wiki.ros.org/rtabmap_ros/Tutor... )

Start of ZED

// B) With zed odometry:
$ export ROS_NAMESPACE=camera
$ roslaunch zed_wrapper zed_camera.launch

Start of RTABMAP

// B) With zed odometry
$ roslaunch rtabmap_ros rtabmap.launch rtabmap_args:="--delete_db_on_start" depth_topic:=/camera/depth/depth_registered frame_id:=zed_camera_center approx_sync:=false visual_odometry:=false odom_topic:=/camera/odom

Yesterday, everything was fine. Had several test runs to record a few databases with environment information.

Today I receive from both nodes warning messages regarding TF_OLD_DATA and no database is created. In rtabmapviz the loop closure detection view is empty.

ZED Warning:

Warning: TF_OLD_DATA ignoring data from the past for frame odom at time 1.53669e+09 according to authority unknown_publisher
Possible reasons are listed at http://wiki.ros.org/tf/Errors%20explained
         at line 277 in /tmp/binarydeb/ros-kinetic-tf2-0.5.18/src/buffer_core.cpp

Rtabmap Warning:

[ WARN] [1536688768.585123648]: TF_OLD_DATA ignoring data from the past for frame odom at time 1.53669e+09 according to authority unknown_publisher
...
[ WARN] [1536690433.251155322]: Could not get transform from odom to zed_camera_center after 0.200000 seconds (for stamp=1536690419.817974)! Error="Lookup would require extrapolation into the past.  Requested time 1536690419.817974107 but the earliest data is at time 1536690429.499749414, when looking up transform from frame [zed_camera_center] to frame [odom]. canTransform returned after 0.201604 timeout was 0.2.".
[ WARN] [1536690433.251314047]: We received odometry message, but we cannot get the corresponding TF odom->zed_camera_center at data stamp 1536690419.817974s (odom msg stamp is 1536690419.817974s). Make sure TF of odometry is also published to get more accurate pose estimation. This warning is only printed once.

The only thing I changed was the time / timezone setting of ubuntu. Changed from ? to Berlin. I tried to change the timezone again, but nothing changes.

Reboot etc. was tested of course.

Any hints?

UPDATE: If i start zed_ros_wrapper only and run command:

 rosrun tf tf_monitor zed_camera_center odom

I get zero delay and everything seems ok with tf.

Then i start rtabmap and everything gets wrong. warning from above are posted and rosrun tf... output is:

//RESULTS: for zed_camera_center to odom
Chain is: zed_camera_center -> odom
Net delay     avg = 0.11676: max = 0.25259

Frames:
Frame: odom published by unknown_publisher Average Delay: -2.6757e+08 Max Delay: 0.209381
Frame: zed_camera_center published by unknown_publisher Average Delay: 0.155448 Max Delay: 0.209376

All Broadcasters:
Node: unknown_publisher 62.4184 Hz, Average Delay: -1.7838e+08 Max Delay: 0.209381
Node: unknown_publisher(static) 1e+08 Hz, Average Delay: 0 Max Delay: 0
Warning: TF_OLD_DATA ignoring data from the past for frame odom at time 1.53675e+09 according to authority unknown_publisher
Possible reasons are listed at http://wiki.ros.org/tf/Errors%20explained
         at line 277 in /tmp/binarydeb/ros-kinetic-tf2-0.5.18/src/buffer_core.cpp
Warning: TF_OLD_DATA ignoring data from the past for ...
(more)
edit retag flag offensive close merge delete

Comments

Berlin is CEST (ie: GMT+2 at the moment). If the ZED has its own internal clock and it doesn't take daylight saving into account, it could be at GMT+1, or even GMT. That would put it at -1 or -2 hours, which could explain the "old data".

I don't have ZED. so you'd have to check.

gvdhoorn gravatar image gvdhoorn  ( 2018-09-11 14:57:56 -0500 )edit

Can you try the approach without zed odometry?

matlabbe gravatar image matlabbe  ( 2018-09-13 14:12:29 -0500 )edit

Sure, I updated the question. Thx.

Boregard gravatar image Boregard  ( 2018-09-13 15:02:25 -0500 )edit

With rtabmap odometry, the odometry node is crashing after processing some images: terminate called after throwing an instance of 'std::runtime_error' what(): Duration is out of dual 32-bit range, so it is normal that rtabmap node is not working (it is not receiving any odometry).

matlabbe gravatar image matlabbe  ( 2018-09-13 15:25:31 -0500 )edit

I'll test with latest zed sdk if I have the same error here...

matlabbe gravatar image matlabbe  ( 2018-09-13 15:26:15 -0500 )edit

Well, both approaches (with zed odometry or with rtabmap odometry) are fine here. What does /camera/depth/depth_registered in rqt_image_view look like?

matlabbe gravatar image matlabbe  ( 2018-09-13 15:44:14 -0500 )edit

I would advise to start by looking at the tf tree and see which transformation are off in time from each other.rosrun tf2_tools view_frames.py creates a pdf where you can see latest timestamps. If you detect which transformation is wrongly dated, it will be easier to find an error.

MRWRWK gravatar image MRWRWK  ( 2018-09-13 16:25:17 -0500 )edit

thx. I attached the images and tf tree abve. I think there is the latest SDK version installed. Updated a few days ago, but I will double check this evening.

Boregard gravatar image Boregard  ( 2018-09-14 00:37:17 -0500 )edit