aerpawlib

AERPAW (Aerial Experimentation and Research Platform for Advanced Wireless) is a National Science Foundation research testbed located at NC State that lets researchers experiment with wireless communications and autonomous vehicle control. Visiting experimenters write software to control custom multi-rotor drones like the LAM6 and SAM4 as well as ground rovers, all of which use Cube Orange flight controllers running ArduPilot. Because these vehicles carry sensitive custom radio payloads like software-defined radios and operate in active airspace, safety is enforced strictly at every step of execution.

Every vehicle command sent from an experiment script passes through an automated safety filter before it reaches the flight controller. This filter only allows a handful of safe operations such as taking off between 20 and 100 meters, returning to land within 5 meters of home, and flying to coordinates that remain inside a predefined field geofence. Telemetry flows back to experimenters freely, but any command that violates boundaries or safety rules gets dropped immediately, which means library code has to conform strictly to these constraints.

The original version of aerpawlib was created by John Kesler using DroneKit and pymavlink, providing simple runner classes and state machines that experimenters could script alongside flight plans exported from ground control software. As DroneKit became unmaintained and vehicle firmware moved forward, I stepped in as the primary maintainer of the official AERPAW/aerpawlib repository to modernize the codebase and migrate the backend to MAVSDK so researchers could run updated firmware without issues.

To keep existing research scripts working without requiring everyone to rewrite their experiments overnight, I kept the original class structure and telemetry helpers in place using a compatibility layer. Alongside that legacy surface, I built an asynchronous v2 API that lets developers write cleaner event-driven flight routines using native Python async syntax, while also maintaining the simulation harnesses, command line utilities, and documentation site.

Writing a flight control library for a testbed is different from building standard drone software because the security filter constantly shapes how commands must be formulated. For instance, standard flight mode switch commands are filtered out, so the library has to issue low-level guided mode commands directly to prevent the drone from entering an unsupported holding state that would sever the virtual machine connection. Similarly, emergency return procedures had to be adjusted so aborted missions would not attempt to navigate home at zero altitude and trigger an immediate filter rejection.

I also resolved several subtle navigation and networking issues while supporting active experiments in the field. Velocity command loops were rewritten so that newer movement updates would not be overridden by older timers, heading calculations were corrected to account for latitude changes across the testing facility, and the inter-vehicle ZeroMQ communications layer was upgraded from basic message publishing to an acknowledged handshake that ensures multi-drone formations do not lose state during coordinated maneuvers.