Calibration of Timing

Microstrain Inertialink

• The inertia-link pushes out data at ~100Hz.
• It makes use of the usb-serial driver cp2101.
• Implicit either in this driver or the imu hardware is a 4 millisecond aliasing of calls to read (relative to system time).
• The discretization can be seen in the plot of differences between subsequent calls to system time immediately following an imu read. Note, additional noise is introduced by variable in latency on the call to system time itself after the read has returned.

• As imu time drifts relative to system time, we see the time difference between system time and the imu growing steadily, but still discretized into the 4ms partitions.

• The inertia-link driver uses a Kalman filter to estimate the drift between the system clock and the inertia-link clock. The Kalman filter has a 2-dimensional state containing the offset between the clocks, and the rate at which the offset changes over time.

• The blue line in the above plot shows the (noisy) time difference between the clocks, while the white line shows the estimated time difference by the Kalman filter.
• The timestamp of the messages from the inertia-link is set to the sum of the clock of the inertia-link, and the estimated offset from the Kalman filter.

Hokuyo TOP-URG

• The hokuyo TOP-URG pushes out data at ~40Hz.
• It makes use of the usb modem driver cdc-acm.
• The responsiveness of the driver/device has different characteristics from the inertialink.
• Read calls return without discretization relative to system time. However, data is only returned from the device on a 1ms clock (regardless of when the data was requested).
• This 1ms device-side discretization can be seen in a plot of differences between system time before and after polled calls to the hokuyo clock. The calls (sync'd to the 100hz imu time) slide into and out of phase with the 1 ms device discretization of the hokuyo.

• As the hokuyo drifts relative to system time, we see a less systematic drift than we do in the imu.

Videre Firewire Stereocam

• The videre stereocam pushes out data at up to ~30Hz
• Once a frame is captured onboard, it is buffered internally and sent over firewire during the next frame.
  • This causes a 1 frame lag in the data
• The stereocam is most likely running on a computer other than the realtime machine. When these tests were run, the NTP offset was less than 30 us.
• To measure the lag, I ran the head_pan_joint through a constant sinewave, and also measured the location of an LED in the stereocam image. Looking at the phase-lag between these signals determines how much time skew there is between the camera and mechanism. Simply from observation, this offset is approx .05 seconds.

Jitter

It seems that CPU load is causing increased timing jitter on the timestamps of stereocam data. I collected camera data under normal conditions, and then with a completely swamped, fully loaded machine. See plots below: