RTLWS: Realtime Linux for aircraft

While there was much discussion about realtime Linux at this year's Real Time Linux Workshop (RTLWS)—unsurprisingly—there were few presentations on actually using it. Karl Kufieta's talk on how the realtime kernel was used for aircraft control was one of the exceptions. Kufieta described both the hardware and software components used by him and his colleagues at the University of Braunschweig to develop a Linux-based unmanned aerial vehicle (UAV).

Several different aircraft designs have been used by the University over the years, Kufieta said, for applications ranging from agricultural surveying to boundary layer measurements in Antarctica. Their designs go beyond traditional aircraft to, for example, a helium balloon that won an international challenge to navigate into a building and out through its chimney.

As might be guessed, weight is an important factor. They chose a Gumstix board with an OMAP 3 for the main processor, with a separate data acquisition processor for sensor data. That setup weighs 60g including the GPS antenna. It currently draws less than 2.5 watts, but that should come down once they figure out how to use some of the OMAP power-saving features, he said.

The main processor handles the control algorithms, image processing, and navigation. The data acquisition processor talks to various sensors, actuators, gyroscopes, the GPS, and so on. The two processors communicate over an SPI bus. Depending on the application, there can be more than one data acquisition processor, all of which communicate via CAN bus. In that scenario, one of the data acquisition processors communicates all of the sensor data to the OMAP via SPI messages. This design allows switching to different main processors without changing the design of the rest of the system.

The system is programmed using Simulink, which is an object-oriented simulation and modeling language with a drag-and-drop GUI interface, Kufieta said. It is integrated with MATLAB, which was used to develop some of the navigation and control code. Simulink can generate C code, which can be targeted to run atop an operating system (i.e. on Linux on the main processor) or to run without an operating system for the data acquisition processors. GCC is then used to build the generated code for the ARM processors.

Their goal was to run the Simulink code, particularly the Kalman filter used for navigation, on realtime Linux. To do so, they used the Simulink Real-time Workshop combined with the 2.6.33.9 realtime kernel. Linux has lots of advantages for the project over various commercial alternatives, including drivers for many of the devices (e.g. webcam, WiFi, UMTS), libraries for image processing and other needed tasks, along with support for SSH and other network protocols. The disadvantage is that it "may be a bit complex", and that the delays in thread execution might be too large for their needs.

As it turned out, their testing showed an upper bound of 62µs for the thread execution delay. That was using a "super simple model", but even when running thousands of these simple realtime tasks, the WiFi was still working well, 500-byte SPI messages could be sent in less than a millisecond, and the non-realtime data logging component, which writes debugging data to an SD card, was able to keep up.

To control an airplane, there is a wide variety of complex code that needs to be run. There are equations to turn the various forces measured by the sensors into vectors. The navigation information then needs to be used to determine what kinds of changes to make based on the current position and attitude of the plane. Position and attitude information is derived from a number of different sources, including GPS, an inertial measurement unit (IMU), accelerometers, gyroscopes, and pressure sensors. Those measurements feed into a model that is used to control the actuators to fly the plane.

The Kalman filter is used to rectify the high-frequency, lower accuracy data from the IMU, accelerometers, gyroscopes, and so on, with the low-frequency, but much more accurate GPS data. The IMU and other data can be sampled at 1kHz, though they are currently sampling at 100Hz, while the GPS data is available at roughly 1Hz rates. The Kalman filter then combines that data (along with an estimate of its accuracy) to determine position.

The processing is broken up into several realtime threads, each running at its own realtime priority, based on 10ms slots. The highest priority task reads the UART (IMU and GPU) and SPI bus (other sensors), while the others implement processing with a granularity of 100Hz, 10Hz, and 1Hz. In addition, when the GPS reading is available, that wakes up another thread that may take more than 10ms, which means that it will span multiple slots. The time budget was tight, Kufieta said, until they turned on optimization; now the whole model can run with only 60% CPU utilization on the OMAP 3.

So far, all of the testing has been ground-based, using Simulink's "external mode" to simulate the inputs, and observe the outputs. That allowed the team to "see it fly" in a simulated environment. The first flight tests are planned for later this year. But the question they set out with—"can we run this on realtime Linux?"—has clearly been answered in the affirmative.

[ I would like to thank OSADL and the RTLWS for supporting my travel to Chapel Hill for the conference. ]