Using an RTOS for data acquisition?

During the latest thesis coaching session, Toto suggested using an RTOS to synchronize the external devices (and thus their clock signals).

First, I will give a short problem overview. Then, I will document my search for a fitting RTOS.

• Problem
  • Sensor-provided timestamp
  • Host-timestamp
• RTOS
• What now
• Tried options:
  • Wind Linux

Problem

The thesis topic is in the field of visual-inertial SLAM. For this topic, I could only find one fitting dataset, and thus will need to make another dataset.

Earlier, I have written about synchronization problems between external devices with their own, independent clocks:

• 25 February 2019: Synchronization statistics of Structure Core and RealSense D435i
• 21 October 2014: Polling, or why ROS’s timestamps still might work
• 16 October 2014: Why ROS’s timestamps are not enough

A short recap: when external devices record timestamped data, that timestamp is either:

1. provided by the recording device itself, assigned before/after/during capturing the data;
2. provided by the receiving device, assigned when the data is requested/received.

Both of these approaches have their pros and cons, but spoiler: multi-sensor setups mess things up royally.

Sensor-provided timestamp

Pro:

• Exact time w.r.t. recording moment

Con:

• It’s a different clock from the collecting device’s clock. They have slightly different offsets, will run out of sync, … This is not a problem until you need to know the capturing order of data from two different sensors.
• The device’s clock might count in seconds, ticks, nanoseconds, … Not easy to translate to „wall clock time”.
• The timestamps are not comparable with timestamps of another device’s clock. You know nothing about the time-relation between captured data of different sensors.

Host-timestamp

This will be mostly about timestamping at arrival of a package at the host, This is the model ROS uses for all the timestamped messages.

Pro:

• Only one clock, which can be translated to „wall clock time”. Seems easy to understand.

Con:

• Packages don’t arrive at regular intervals to your software under non-RT OS’s. That means that, given equal time \(d\) between all captured data, on the host system you won’t see anything of that. The average is not even guaranteed near \(d\).
• Correlated to the above, receiving data from sensor 1 with frequency \(n\) Hz and data from sensor 2 with frequency \(k \cdot n\) Hz, you are not guaranteed to have \(k\) packages of sensor 2 between two packages of sensor 1.
• Depending on the transfer protocol, the order of arrival at the host is not guaranteed. That means that, given data \(D_1\) captured at (real-world time) \(t_1\) and data \(D_2\) captured at \(t_2 > t1\), the timestamp of \(D_1\) might even be after \(D_2\).

RTOS

According to Wikipedia, „A real-time operating system (RTOS) is an operating system (OS) intended to serve real-time applications that process data as it comes in, typically without buffer delays.” Sounds like what might solve the above issues!

Requirements for the RTOS are given by the connected devices:

• Needs to run on an x86 (either 32 or 64 bit) architecture
• USB 3.0 support
• Ethernet support
• UNIX/Linux-compatibility (preferably even supporting a .deb)

Also, proper documentation would be nice, for my first try with an RTOS ;)

A good starting point might be Wikipedia’s comparison of real-time operating systems. Some interesting highlights, in a pretty meaningless order (I’m CTRL+F’ing for Linux and x86 my way through the list):

So the top interesting ones for now are

• Full Linux:
  • Community-driven: RIOT, Xenomai
  • Commercial but free: Wind River Linux
  • Paid (maybe educational license?): LxWin, RedHawk Linux
• RTOS-kernel patch for Linux, free: ChronOS, RTAI

What now

1. Contact RedHawk Linux
2. Try out Wind River Linux
3. See if RIOT will cooperate, maybe need this blog post?

Tried options:

Wind Linux

I have downloaded Wind River Linux 10.19.BASE from https://github.com/WindRiver-Labs/wrlinux-x, and generated an image:

mkdir udoo-os
cd udoo-os
git clone https://github.com/WindRiver-Labs/wrlinux-x
./wrlinux-x/setup.sh --machines intel-x86-64 --recipes openssh cmake make libgcc gcc glibc boost mesa mesa-gl libusb1 libxcursor libxi libxinerama libxrandr