Automated Testing of Flight Hardware

Doc

Role

Solo project — automated flight-hardware testing for Huia

Timeframe

2026

Manual testing of flight hardware, where control inputs are adjusted manually and measurements are recorded individually, introduces inconsistency into test data. Human reaction time, configuration drift, and recording errors make it difficult to reliably compare results between runs. To improve repeatability, I developed a Python terminal application that automates flight hardware characterisation testing using a Cube Orange+ flight controller as both a control interface and data-acquisition platform.

Rather than developing custom embedded firmware, the application communicates with the flight controller using MAVLink, a standard communication protocol widely used across autonomous vehicles and robotics systems. Through this interface, it can command flight-controller outputs including throttle, servos, and other PWM channels, monitor connected sensors, and record system performance data. This approach allowed existing, previously validated flight-controller hardware to be reused with consistent results.

The application was structured to keep hardware control, data collection, and user interaction independent from each other. This separation improves reliability by ensuring that communication issues, logging tasks, or user actions cannot interfere with the accuracy of test results. It also provides a scalable foundation for adding additional sensors and automated test procedures in the future.

The system collects data from multiple sources through the flight controller. Electrical measurements are obtained from a Mauch PL200 power sensor through the Cube’s battery-monitor interface, while five MCP9600 thermocouple amplifiers provide temperature measurements.

Automated test procedures are defined using YAML configuration files, allowing repeatable test sequences to be created without changing application code. Each procedure is validated before execution to ensure parameters such as output limits, ramp rates, and test duration remain within safe operating ranges.

Safety was a key design requirement throughout the project. The system was designed so that safety limits are enforced regardless of where a command originates, whether from an operator or an automated test procedure. Output changes are rate-limited to prevent sudden unexpected movements, communication loss automatically places the system into a safe state, and activation requires explicit operator confirmation. Test-specific settings are also isolated between runs, preventing changes made for one experiment from unintentionally affecting future tests.

To improve development and verification, the application includes a simulation mode that replaces the physical flight controller and sensors with software models representing realistic system behaviour. This allows the control logic, data logging pipeline, and user interface to be exercised without physical hardware connected. An automated pytest suite validates the core application functionality, ensuring changes can be tested without requiring full hardware access.

Safety features need to be designed around failure cases, not just normal operation, which is something the initial version got wrong. Early safeguards lived in the user interface, but that didn’t protect against unexpected inputs or automated test errors, so moving them closer to the hardware interface meant every command hit the same safety limits regardless of where it came from. Cutting the project’s scope back to power and thermal characterisation only made the tool noticeably more reliable.