Drones running (and compiling) Linux

Andrew "Tridge" Tridgell may be best known for his work on Samba, but in recent years his interest in unmanned aerial vehicles (UAVs) threatens to become even more popular. On the last day of linux.conf.au 2015 in Auckland, Tridgell gave an update on his recent UAV development work—complete with a live demonstration conducted via video link from Australia.

This year's talk, Tridgell said, was the follow up to his LCA 2014 talk, during which he promised to start porting the ArduPilot UAV autopilot software from the Arduino to a Linux system. In 2014, he had shown the PixHawk autopilot board and announced a plan to create a PixHawk "cape" for the BeagleBone Black (BBB).

As it turns out, far more has happened than that. The cape that was promised (called the PixHawk Fire) is complete, but the ArduPilot software is regularly running not only on the BBB, but on several other Linux devices as well. In addition, there are several other Linux-based autopilot projects, a new collaborative project has been created, and multiple companies have been launched to make Linux-based UAVs.

He then moved straight into a demonstration, opening a Skype call to Grant Morphett, who was standing by at an airfield in Canberra. Tridgell logged into the UAV remotely, putting the telemetry data and a terminal window from the plane onto the projector screen. The UAV itself was a Skywalker 2013 model (a modest-sized all-electric plane), loaded with a BBB and PixHawk cape running ArduPilot 3.2.1. Just to add some additional challenge, Tridgell started compiling the Linux kernel on the BBB before starting the flight.

For the demonstration, Morphett simply picked up the plane and threw it; sensors on board detected the movement and started the propeller in response. The UAV flew a pre-determined course, making three loops around the airfield, then coming in for an unassisted landing. All the while, the telemetry data on Tridgell's laptop displayed the location and orientation of the plane overlayed on a satellite image of the field—he pointed out how the wind direction was discernible through the orientation of the plane's wings and the variations in ground speed.

During the test, he continued, the UAV performed about 1200 Serial Peripheral Interface (SPI) transactions per second from its sensor array: gyroscopes, accelerometers, barometers, and magnetometers. "Usually we have some LiDARs on board as well, so we not only get to tell people that we have flying Linux robots, but that they have lasers attached to them." There are also a set of real-time units on the PixHawk cape, he explained, to handle the I/O load.

As expected, the demonstration was a success: the UAV landed without incident (although it did not finish compiling the kernel). Tridgell then provided some more detail about the specifics of device: which sensors were used and how they are connected, for example.

SPI is used for the "fast" sensors like the accelerometers and gyroscopes, which need to be sampled at around 1KHz. For maximum performance, they have to sit very close to the BBB, a centimeter or less. In contrast, the "slow" sensors (such as GPS, magnetometers, and radios) are connected over I2C and, fortunately, perform best when they are placed as far away from other components as possible, where there is less interference. "The rule with drones is that every component wants to be as far away as it can be from every other component."

The BBB, he said, ran kernel 3.8.13 with the realtime patch set. It is rather slow by modern CPU standards, but is capable of handling 4000 transactions per second without exceeding 25% CPU load—and with no loss of sensor data.

A year ago, it was an open question whether or not Linux on the BBB would be capable of handling that kind of sensor and I/O throughput using userspace drivers. So it was welcome news to learn that the system was up to the task. In addition, the ability to use userspace drivers has the benefit that the driver code only needs to be written once; non-Linux UAV projects can—and do—reuse the ArduPilot code.

The Linux-based ArduPilot system manages all of that sensor data with six realtime threads using the FIFO scheduling policy. One is a 1KHz timer thread for regularly scheduled tasks, one is a UART thread for serial operations, one is an RC (radio control) input thread for handling RC input pulses, one is a thread dedicated to the on-board buzzer (which generates diagnostic tones), one is dedicated to filesystem I/O, and one is used for the main logic and navigation loop.

In a recent test, Tridgell said, he ran a test system for 11 hours, executing 2 million loops with an expected loop time of 20ms. Only 19 of those loops exceeded 30ms, and only one exceeded 40ms—although that one took 1.7 seconds, he noted, which is quite troubling. The challenge now is to find the cause and fix it, he said, and he had already had several valuable conversations on the subject at LCA.

Only two tasks are not handled by Linux at the moment: processing RC input and generating pulse-code modulation (PCM) output for the servos that control the UAV's steering. Both of these tasks require microsecond timing, and Linux is not good at these things—"at least, not if you're also doing other things," he added. The solution for the PixHawk is to include two programmable realtime units (PRUs), which share 8K of memory with the main CPU and have direct access to the necessary I/O pins. Unfortunately, he said, there is only a proprietary C compiler available for the PRUs as of today.

Still, Tridgell's project has published its PRU code, hoping to make it available for all platforms. In 2014, he reported, the team participated in the UAV Outback Challenge, a "search and rescue" contest in which drones had to locate a life-sized dummy and drop a parachute packet as close as possible to it. Tridgell and the Canberra team had taken first the 2012 contest, although it did not win the "grand prize," because its parachute landed too far from the dummy.

In the 2014 edition of the contest, he said, he was happy to report that the Canberra team had won the grand prize—and, just as importantly, that every team in the competition was using at least some of his team's code. Some might have argued that releasing all of the code to the public was a bad idea from a competitive standpoint; Tridgell said that the results demonstrated that sharing information with everyone was the right strategy after all.

Along the same lines, Tridgell highlighted how much the Linux-based UAV community had grown over the past year. There have been several ports of the ArduPilot software to new hardware that are now commercially available, including the PixHawk Fire Cape, the Erle Brain from Erle Robotics, and the navIO line for the Raspberry Pi from Emlid. There are still other prototype ports, such as an i.MX 6 port done in-house at 3D Robotics and the Zynq ARM-and-FPGA port by John Williams. In fact, he added, the newest had arrived during LCA 2015 itself: during a talk earlier that week, he saw a pull request arrive for the BBBMINI port by Mirko Denecke. Not only was the patch good, he said, but it added support for a new hardware platform in just 43 lines.

Erle Robotics, he noted, was founded by a former Google Summer of Code (GSoC) student—and it was only one of several new Linux-based UAV companies launched in the past year. In October, the Dronecode project was launched to provide an umbrella under which these companies and other open-source UAV efforts could collaborate. The first Dronecode conference is scheduled to take place in March 2015, co-located with the Embedded Linux Conference. Tridgell encouraged everyone to come along and to get involved.

[The author would like to thank LCA 2015 for travel assistance to Auckland.]