Taking a operating system with at least soft real time capabilities is crucial. Nothing is allowed to delay (periodic) execution of the control process(es) for substantial amount of time. INS measurement and control actions would become invalid and this would most probably result in crash.
Personally I have this requirements for RT behavior:
1. Control/INS process maximum execution delay cannot exceed 20ms and if so, then only rarely (all sensors are controlled by a separate board and data sent over UART, servo control frequency is 50Hz)
2. General execution delay should not exceed 5ms (for RT tasks)
3. No data sent to/received from peripherals should be lost (e.g. data over UART due to buffer full)
4. Background tasks should still be executed.
But there are also other criteria like availability of development tools, possibility of cross compilation, cost of the OS (;-)) and wide knowledge base.
For me the best solution RT Linux. Beaglebone has substantial Linux community and several regularly updated Linux distributions. So, Ubuntu port + RT-Preempt kernel patch (with and without CONFIG_PREEMPT_RT flag set) was selected.
If this selection fails at some point (which will not happen) Xenomai or RTAI will be the last resort.
Here are some measured results (running IMU6, storing data on SD card, sending/receiving data over UART, controlling servos) on a kernel with RT patch but without CONFIG_PREEMPT_RT flag.
First picture shows a histogram of delays measured over ~ 30? minutes.
This does not look all that bad. Mean is below 50 micro seconds.
On the second look there are some more significant but very rare delays around 1 millisecond. They are exclusively caused by setting PWM in the motor control/watchdog process. No idea why the kernel blocks for so long because setting PWM duty cycle is a simple operation (only writing to PWM register?). Maybe there is some bug in the kernel PWM module but even with this problem maximum execution delay is not reached.
|System||median [ms]||95% [ms]||99% [ms]||100% [ms]|
|RT patch without CONFIG_PREEMPT_RT flag||0.046||0.065||0.084||1.48|
|RT patch with CONFIG_PREEMPT_RT flag||0.062||0.093||0.116||2.38|
From kernel comparison it can be seen that kernel without CONFIG_PREEMPT_RT has better median to 99% execution delay for this application.
Just out of curiosity, this is how the execution delay looks in time…