# Data in Rviz not synchronized

Hello,

I have some problems of synchronizations.

• I publish stereo pictures from my dataset (left and right) then i get the disparity and the depth map. Despite the parameters , i have a shift of about 1s between my picture and the publicaiton of the depth map. How I can solve it ? Is it because i have lots of intermediates nodes ? ( left/right -> stereo_image_proc -> disparity -> depth map)
• Then in Rviz, zhen i publish the picture and the depth map, there is at least 5s of shift...And i really don't know why.

Thank you

EDIT:

Actually I try an algorithm for SLAM. With the dataset provided by the authors (depth image provided), it works very well. Now I want to try with my own dataset (so record my own bag and provide my own depth map). So that's why I add others node to process the disparity and depth map from my left and right pictures. I can show my launch file if you want ? But with my dataset, despite I have now a depth map it doesn't work at all and don't know why. I presume that is because of the shift because the process. Maybe there is a relation between their dataset and their algorithm (for example regard to the time)

- Are you sure your messages are published with the correct timestamps, with regard to ros::Time::now()?

When I analyse my bag I have the following (for depth map and my monocular image):

field.header.seq I have 0,1,2.. so it's okey

%time i have a big number for each frame, so I presume it's okey

I think that is the problem maybe ? But When I put in my different nodes (stereo publisher, depth processor) the time stamp by doing for example image_left->header.stamp=ros::Time::now() and image_right->header.stamp=ros::Time::now(), I still have nothing in me stamp and I have a message which appear on my terminal which telling that my message are not synchronized... don't know if I'm doing well or If i did something wrong.

[ WARN] [1428982008.806538635]: [image_transport] Topics '/camera/left/image_color' and '/camera/left/camera_info' do not appear to be synchronized. In the last 10s:
Synchronized pairs:           0
image type 16
[ WARN] [1428982009.859383623]: [image_transport] Topics '/camera/left/image_mono' and '/camera/left/camera_info' do not appear to be synchronized. In the last 10s:
Synchronized pairs:           0
[ WARN] [1428982009.888232403]: [image_transport] Topics '/camera/right/image_mono' and '/camera/right/camera_info' do not appear to be synchronized. In the last 10s:

• Use rostopic echo --offset TOPIC_NAME/header/stamp to examine by how much your messages are delayed ...
edit retag close merge delete

Sort by » oldest newest most voted

Here are some suggestions:

• Are you sure your messages are published with the correct timestamps, with regard to ros::Time::now()?
• Use rostopic echo --offset TOPIC_NAME/header/stamp to examine by how much your messages are delayed w.r.t. ROS time. The delay is the sum of communication / serialization overhead + the processing time of your nodes. Note that the stamp of a header consists of seconds and nanoseconds, e.g. 0 seconds and 500000000 nanoseconds means your time offset is 0.5 sec
• At which frame rate are you publishing the data? Does the delay disappear if you reduce the publishing rate? In this case, maybe your computations are just too computationally complex? Disparity calculations, without GPU acceleration, can be quite slow depending on which stereo matching algorithm you are using, I believe some only achieve 10-15 FPS on common hardware...
• Are you using any message_filters::Synchronizer in your code? If yes, try increasing the queue size of the message_filters::Subscriber that serve as an input
• Are you using any tf::TransformListener and waitForTransform() somewhere which might cause delays if the transforms are delayed? In that case, diagnose transform delays using rosrun tf tf_monitor
• The number of nodes, or length of a processing chain, is usually not a problem in practice. However, message serialization can incur overheads, especially for large data such as images. Use multiple nodelets within a common nodelet manager, instead of separate nodes, to eliminate overhead caused by ROS message serialization (this is what e.g. the rgbd_launch package does). As nodelets are a bit more difficult to debug, I would recommend this only if you are sure that serialization is the most probable cause of your issues.
more

Hi timm! I got the same problem as lilouch. Thanks for providing the list of possibilities that might cause the problem. I strongly believe it's the 5th point (transform delay) that caused the problem on my side. However, the transform I set is important. Do you know of a way I can go about? Thanks!

( 2015-08-15 03:46:33 -0600 )edit

more