Revision history [back]

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.