ZeroPilot 1.0 Architecture

Overview

From the highest level, one can think of the entirety of the ZeroPilot software engine as being a black box which takes in instructions from a ground station (about the flight plan, amongst other data) and outputs a series of actuator commands in order to fly the aircraft. ZeroPilot runs across 2 separate microcontrollers that communicate with each other over SPI. The first chip, “Autopilot”, is responsible for all aspects of autonomous flight except attitude management and actuator control. The second chip, “Safety”, is responsible for attitude management (generating PWM values for the actuators) and sending instructions to the actuators. Safety is also used for reading in a redundant telemetry link which may be used in the event of catastrophic failure.

As a whole, ZeroPilot is designed to take care of everything from takeoff to level flight to landing and apart from collecting instructions from the ground station about where we want to go, it does all this without the need for any human intervention.

Software design

Open

Safety

The safety firmware is made to contain the bare minimum required to perform manual flight. As seen in the flowchart, the safety component of ZeroPilot consists of a few blocks. These are responsible for collecting data from Autopilot as well as from the secondary telemetry link. Depending on whether an emergency has occurred or not, the Decision Module will either send the Autopilot or telemetry information into the Attitude Manager. The Attitude Manager then converts the inputted data into PWM values that are sent to the actuators. The functionality of each Safety module is detailed in a child page of this one.

Autopilot

Firmware that runs on the AutoPilot chip does so atop FreeRTOS.

The entirety of the autopilot consists of two managers (telemetry and path), a sensor fusion engine, a series of peripheral drivers, and an inter-chip driver. All these components are run at strict rates. The managers each live inside their own threads, as do the sensor fusion module and inter-chip. The drivers are grouped together based on how often they refresh. For instance, all sensor drivers that refresh at 200Hz live inside the same thread. Most drivers, however, will be used across 2 threads, one for beginning a transaction, and one for using the data (this is detailed in the “Sensors” child page).

All threads, with no exceptions apart from a nop “idle task”, are run with the same priority. This design ensures 2 very important things. First, it ensures that every thread is allowed to complete a complete cycle without the OS ever interrupting it half way. That implies that modules do not ever need to worry about concurrent data access, save from any hardware interrupts. Second, it ensures that each thread is guaranteed to execute exactly once within its specified interval. That implies that thread starvation is never an issue, makes the use of FIFOs completely unnecessary, and allows synchronous modules, such as PID and SensorFusion to be time independent.

The functionality of each AutoPilot module is detailed in this page’s child pages, but from a high level overview, the best way to describe AutoPilot’s operation is with an analogy. Imagine a Warship’s control room. You may find a captain, a navigator, and a radio operator. The radio operator is responsible for relaying all data between the ship and a control station on land somewhere. That includes anything from sending updates of the ship’s position to receiving any instructions that would update the ship’s navigation plan. Note that the radio operator never acts on any of this data. His sole responsibility is to relay it. On ZeroPilot, Telemetry Manager is our radio operator, exchanging data with a groundstation. Next, the navigator is in charge of taking instructions as to where the ship needs to go and figuring out what changes to the ship’s heading, speed, etc need to be made to get there. On ZeroPilot, Path manager is our navigator. Lastly, the captain is in charge of collecting the required changes in heading, speed, etc and actuating his ship to achieve those things. On ZeroPilot, attitude manager is our captain. This is a good place to note that a captain intimately knows his ship. If he is to move to another kind of ship, it will take him some time to adjust to it, while navigators and radio operators are generic; the kind of ship they are on makes no difference to their work. The same is true with ZeroPilot; controlling a different aircraft requires no modification of the telemetry or Path managers, but will require tuning of the Attitude manager. Lastly, both the captain and the navigator rely on various instruments to be able to do their job properly. Instruments like compasses, speed indicators, motor strain gauges etc. On ZeroPilot, all “instruments” are contained inside Sensor fusion. Sensor fusion processes all raw sensor data and is public to all modules, so anyone can ask it for any data at any time.

Each of these components along with their sub components has an associated architecture page, listed as children of this page. Here is the hierarchy.