Systen Level Testing
Firmware Tests
There are a multitude of testing methods throughout the firmware development process. At the lowest level tests are the unit tests, which cover almost all the firmware not directly related to the actuator control. These tests ensure firmware robustness and full error case coverage, thus ensuring higher reliability. One level above this is the Simulink simulation, which allows us to test the ability of our firmware to fly the drone in different weather conditions and circumstances. Another level above are the dry run integration tests, where firmware is loaded onto the UAV and each actuator response is verified.
Flight Tests
As the final level of testing, flight tests are performed once all subsystems are functional. These typically focus on the newly added and/or modified systems, as well as the overall process in successfully executing the mission. Flight tests also provide an opportunity for team members to become familiar with their roles at competitions, and identify issues therein.
Features and Capability
ZeroPilot
The two components making up ZeroPilot’s firmware system are the safety firmware and the autopilot firmware.
The Safety firmware runs on an STM32F0 microcontroller and it generates actuator commands for onboard servos and electronic speed controllers (ESC) using commands from our autopilot or ppm input form a hobby receiver. It contains five main modules: the ppm receiver module, which receives and packages ppm input from our hobby receiver; the inter-chip module, which receives and packages commands from our autopilot firmware; the Attitude Manager, which converts ppm and autopilot commands into actuator commands using PIDs and inverse kinematic (IK) modules; an IMU sensor driver, which provides data for our IK models to run; and a PWM module that sends actuator commands to our servos and ESCs. The safety firmware is purposefully designed to contain only the modules needed to allow for manual flight, helping the safety code base be as simple and reliable as possible. The figure below illustrates the architecture of the safety firmware.
// Insert some diagram here…
In ZeroPilot, the autopilot firmware runs on a separate STM32H7 microcontroller. The decision to have the autopilot and safety firmware run on separate microcontrollers was made in order to ensure that there was a layer of redundancy. In this way, even the hardest failure in the complex autopilot firmware cannot crash the Safety firmware, which defaults to being human controlled in times of emergencies. The Safety and Autopilot microcontrollers communicate using Serial-Peripheral Interface as a result of the low complexity of the system and high data transfer speed. The figure below shows the safety firmware’s state logic.
// Insert some diagram here…
The autopilot firmware, on the other hand, is responsible for gathering all sensor data and communicating with a ground station during normal operation. Using this information, it makes all decisions about what the aircraft needs to do and sends the commands to the safety firmware, which then uses the commands to generate actuator commands. The autopilot architecture consists of four FreeRTOS threads that each manage either a state machine, sensor data acquisition, or inter-chip communication. The two state machines are the Path Manager; responsible for navigation of the drone by instructing the safety firmware to generate actuator commands to achieve certain attitudes and airspeeds, and the Telemetry Manager; responsible for all communication with the ground station and onboard CV Jetson. At the same time, there will be a thread for the Sensor Fusion module, ensuring data is collected and fused at well timed intervals. There also is a thread dedicated to inter-chip communication between the autopilot and safety chips so information is passed at well-timed intervals. The figure below depicts these threads as well as the communication between them, with black arrows representing inter thread communication while the white arrows represent communication with an external piece of hardware.
// Insert some diagram here…
The firmware thus has the capability to fly the aircraft in a stable manner across any desired flight plan. Further, if so commanded, Path Manager can switch from flying mode to takeoff/landing modes. This allows fully autonomous takeoffs and landings.
Automation
Comms
Controls
Navigation
The navigation of the drone is handled by the waypoint manager, which lives inside the Path Manager state machine. It is responsible for storing and modifying the drone’s requested flight path and determining the desired heading to stay on course. It does so by navigating around a series of GPS waypoints.
In flight, Path Manager can change the drone’s requested flight path as a result of a new instruction from telemetry by calling the appropriate methods in the waypoint manager. This will change the number and order of the waypoints in the flight path array. The modifications that are available include appending, inserting, updating, and deleting waypoints.
Apart from waypoint following, there are two special cases that the waypoint manager also considers: when the drone needs to hover at a specific location and when the drone needs to head back to a predefined home base - in the competition’s case, the launch site.