Hi Rene,

> To synchronize both data sources in software the best technique I'm
> aware of is to calibrate and track the measurement frequency of each
> source, recover timestamps based on sequence numbers to keep jitter to a
> minimum, and fuse based on these "rectified" timestamps.  Is there any
> generic component in ROS that does this?

Have a look at trigger_matcher.h in timestamp_tools. It is not
currently documented or officially supported, but has been in use in
the wge100_camera_node for over a year now, and is pretty simple.

It basically assumes that data is arriving at a known rate, and that
most of the time there will be pretty deterministic latency between
the data being aquired and its arrival on the computer.

> Secondly, in my experience the above strategy only gives satisfying
> results if all the driver nodes involved run under a realtime scheduling
> priority with recent Linux kernels (preferrably with the -rt patchset
> applied).

In the case where the sensor is streaming data at a fixed rate, having
the software run realtime hasn't been very important in my experience.
Most of the time, the driver is invoked as soon as data is available.
In the rare cases where that does not happen, the trigger matcher is
able to figure out that the data was delayed. Of course on a very
heavily loaded system, this approach will fail.

How low are you trying to get for jitter anyway?

> This requires acquiring relevant capabilities, setting the
> respective scheduling parameters and monitoring realtime processes with
> a watchdog/canary approach. Is there any infrastructure in ROS to handle
> that?

roslaunch's launch-prefix may be able to help you get the node running
as a real-time process.

Blaise