...
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, thus ensuring higher reliability. One level above this is the Simulink simulation, which allows us to test the ability flight capabilities of our firmware to fly the 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.
...
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 PPM input form from a hobby receiver. It contains five main modules: the ppm 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) working in tandem with motion control modules; an IMU sensor driver, which provides data for our IK 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.
...
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:// Insert some image here
...
The Telemetry Manager starts its work cycle by obtaining telemetry data from the ground and onboard Jetson, if . 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 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.
...
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
Anthony Luo Dhruv Upadhyay pls halp
The Attitude Manager is designed to maintain attitude and stability of the quadcopterQuadcopter, residing on a separate chip and taking commands from operator inputs or from PM Waypoints. This module functions as an asynchronous (PLEASE CONFIRM) State state machine with 7 (PLEASE CONFIRM) 5 distinct states.
// insert diagram here.
...
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 la place 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.
...
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 that can control ____??___, the pilot can navigate the drone safely.
...
Takeoff: After the takeoff area has been sweeped swept and cleared by CV, the autopilot firmware goes into takeoff mode. The Path Manager which 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.
...