# Revision history [back]

### 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

### 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 w.r.t. ROS time

Okey except for the original pictures (left and right) where I have this message: secs= -1 and nsecs: 982463066 for example, for the others processing nodes (stereo_image_proc, depth_image_proc and disparity_image_proc), I have nothing appear on the terminal that is to say echo --offset /camera/depth_registered/image/header/stamp give me nothing.

• 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...

Very slow. I have ros::Rate(0.5) . If I put 5, it's too quickly and it's worst !

• 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

Yes for all my new nodes. I Put 100 instead of 5 and it's better when i run rqt_image_view. The pictures seems synchronized, but when i launch the visual odometry algorithm, in Rviz I have still the shift and I have the impression that it's worst that is to say that It process 10-15 messages in 3-4 seconds (so only see the first and last picture of my little bag) if you know what i mean ? It's like it pass pictures or maybe there is a big shift and try to catch up its late.

• 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

No

• 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.

Yes I launch all my node and nodelet from one launch file. I can show you but even if I read the documentation, I still confused with the concept of nodelet. (for example in my launch file some process are nodelets)

### 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
/home/isg/Documents/dataset_odometry/image_2/000006.png
/home/isg/Documents/dataset_odometry/image_3/000006.png
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 w.r.t. ROS time

Okey except for the original pictures (left and right) where I have this message: secs= -1 and nsecs: 982463066 for example, for the others processing nodes (stereo_image_proc, depth_image_proc and disparity_image_proc), I have nothing appear on the terminal that is to say echo --offset /camera/depth_registered/image/header/stamp give me nothing.

• 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...

Very slow. I have ros::Rate(0.5) . If I put 5, it's too quickly and it's worst !

• 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

Yes for all my new nodes. I Put 100 instead of 5 and it's better when i run rqt_image_view. The pictures seems synchronized, but when i launch the visual odometry algorithm, in Rviz I have still the shift and I have the impression that it's worst that is to say that It process 10-15 messages in 3-4 seconds (so only see the first and last picture of my little bag) if you know what i mean ? It's like it pass pictures or maybe there is a big shift and try to catch up its late.

• 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

No

• 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.

Yes I launch all my node and nodelet from one launch file. I can show you but even if I read the documentation, I still confused with the concept of nodelet. (for example in my launch file some process are nodelets)

### 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 w.r.t. ROS time

Okey except for the original pictures (left and right) where I have this message: secs= -1 and nsecs: 982463066 for example, for the others processing nodes (stereo_image_proc, depth_image_proc and disparity_image_proc), I have nothing appear on the terminal that is to say echo --offset /camera/depth_registered/image/header/stamp give me nothing.

And in the result of the keypoints detected by the algorithm, the output show me the following message

secs: -1428984024
nsecs: 326797009


Whereas wih the dataset of the authors, for the same topic I have

secs: -1428985017
nsecs: 322918892

• 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...

Very slow. I have ros::Rate(0.5) . If I put 5, it's too quickly and it's worst !

• 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

Yes for all my new nodes. I Put 100 instead of 5 and it's better when i run rqt_image_view. The pictures seems synchronized, but when i launch the visual odometry algorithm, in Rviz I have still the shift and I have the impression that it's worst that is to say that It process 10-15 messages in 3-4 seconds (so only see the first and last picture of my little bag) if you know what i mean ? It's like it pass pictures or maybe there is a big shift and try to catch up its late.

• 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

No

• 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.

Yes I launch all my node and nodelet from one launch file. I can show you but even if I read the documentation, I still confused with the concept of nodelet. (for example in my launch file some process are nodelets)