Tech Report - Dhruv

System Level Testing

Firmware Tests

There are a multitude of testing methods throughout the firmware development process. At the lowest level of 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, ensuring higher reliability. One level above this is the Simulink simulation, which allows us to test the flight capabilities of our firmware and drone combinations in different weather conditions and circumstances at minimal cost and reduced operator hours. Another level above are the dry run integration tests, where firmware is loaded onto the UAV and each actuator response is verified. All in all, the firmware tests play a critical role in maintaining system stability and catching any errors which may have been in the code before flight tests.

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 from 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 working in tandem with motion control modules; an IMU sensor driver, which provides data for our controls 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.

Open

Safety Controller Inputs and Outputs

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. 

Open

Safety Controller State Diagram

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.

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

Inter-thread communication on Autopilot

The Path Manager and Telemetry Manager state machines run as separate tasks that communicate with each other. For instance, the Telemetry Manager exchanges new instructions from the ground and onboard Jetson along with debug data with the Path Manager. Because the tasks are scheduled by an RTOS, their communication must be handled in a thread-safe way. FreeRTOS features mail queues as a thread-safe method of sending data between tasks. The Telemetry and Path Managers are each assigned a mail queue in which they can store data. Each task continuously updates its mail queue with the newest version of the data it needs to send. The other task reads this mail queue to access the data when necessary. In this way, both tasks are able to send and receive data between each other.

Telemetry Architecture

The Telemetry Manager is the part of the Autopilot firmware responsible for all of the data communication between ZeroPilot, the onboard Jetson, and a custom program running on the ground station. The figure below shows the layout of our Telemetry Manager architecture:

The Telemetry Manager starts its work cycle by obtaining data from the ground and onboard Jetson. If data is invalid, the manager immediately reports this error to the ground station; otherwise, data gets sent to Path Manager as expected. After data is processed by Path Manager, the feedback is processed by Telemetry Manager. If there’s any unusual activity detected, which may indicate that ZeroPilot is unresponsive, an error report would be sent to the ground station. If everything works smoothly, feedback data would get sent to the ground periodically and relevant data will be sent to the onboard Jetson.

Autopilot-Jetson Communication

Communication occurs over a UART line with both Autopilot and the Jetson exchanging data relating to the drone’s current state (pitch, yaw, gps coordinates, etc.) and the position of tracked objects. This exchange of data allows for the computer vision algorithms to produce accurate gps coordinates for tracked objects that autopilot can use to steer the drone in the correct direction.

Autopilot-Ground Communication

Communication occurs over a pair of XBee Modules at 900 MHz with a custom-built protocol. Most of the data sent to the Autopilot are commands that come in the form of a change to the flight path or an indication that the takeoff/landing zones are clear. There is also support for debug data to be sent from Autopilot to the ground so issues in Autopilot can be diagnosed before a failure occurs.

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.

New Attitude Manager

The Attitude Manager is designed to maintain attitude and stability of the Quadcopter, residing on a separate chip and taking commands from operator inputs or from PM Waypoints. This module functions as an asynchronous state machine with 5 distinct states.

Motion Controls Module

This controls module resides within Attitude Manager, and is responsible for keeping the drone in the air in all states of motion. At it’s simplest, the kinematic controls module ensures that our quadcopter always moves from our current position to a target position within a specified distance. It does this by using a variety of PID controllers on a quadcopter modelled in the Laplace domain.

In teleoperated scenarios, our controls algorithms use the remote inputs as target set-distances, before generating trajectories (either as splines, curves, or straight lines) that our controllers will aim to follow. This means that the operator is able to focus on flying to the right locations, instead of having to maintain attitude of the quadcopter. In fully automated flight, our controls algorithms work together with Path manager to define fine splines and curves to follow, allowing more complex flight dynamics using more advanced controllers.

In the event there are unseen variables such as wind gusts or payload balance changes that affect the attitude of the drone, the Controls module will compensate automatically to keep flying towards the location that the operator or Path Management have specified.

BVLOS

The on-board autopilot is fully capable of autonomous navigation. Its main method of doing so is by following a pre-loaded path of GPS waypoints. This path can be adjusted by the groundstation on the fly if need be. To do so, Path Manager constantly reads GPS and altitude data, and uses a waypoint navigation algorithm to determine the optimal real time attitude and airspeed of the aircraft in order to achieve the path as quickly as possible. The Attitude Manager in the safety firmware then reads those commands and uses a series of PID algorithms to produce real time aileron, rudder, elevator and throttle positions in order to achieve the requested attitude/airspeed as quickly as possible.

On the ground, things are different. When undergoing autonomous flight, the ground station can send and receive commands from ZeroPilot via a telemetry link. On the other hand, when flying the drone manually, the pilot can view the drone’s surroundings by viewing a video stream sent down from one of the drone’s cameras. Using a remote, the pilot can navigate the drone safely.

On takeoffs and landings, the CV and firmware systems work together. 

• Takeoff: After the takeoff area has been swept and cleared by CV, the autopilot firmware goes into takeoff mode. The Path Manager is set to command a certain takeoff roll airspeed and execute a climb path to a predetermined cruising altitude. When the cruising altitude is reached, the Autopilot sets Path Manager into cruising flight mode which makes the drone follow a predefined flight path.

• Landings: After the predefined landing coordinates are reached, the drone hovers in position, giving enough time for the CV system to clear the landing area. When the landing area is cleared, a landing command is sent to Path Manager and the state machine switches into Landing Mode which lowers the drone’s altitude at a fixed gps coordinate until contact with the ground is reached.