PaperlayerView exact revision on arXiv

Source-linked AI summary

Cybflight: An Embedded Rust Autopilot for Aerial Robotics Research

Yifan Lin, Chao Qin, H S Helson Go, Hugh H. -T. Liu

arXiv:2609.31232v1cs.RO

TL;DR

Changing an estimator or controller in a mature autopilot can demand substantial firmware-specific work, while companion computers add costs that matter on small high-speed aircraft. Cybflight uses typed, replaceable interfaces and compile-time selection to run MPCTC and INDI on a flight-controller microcontroller; fully onboard flights reached 12.38 m/s indoors and 31.4 m/s outdoors.

  • Problem

    Replacing a core estimator or controller in a mature autopilot can require substantial firmware-specific work, while companion computers add mass, power, wiring, integration effort, and cost.

    Source: §I · p. 1

  • Method

    Cybflight uses typed, replaceable interfaces and build-time selection to compile Rust implementations of MPCTC and INDI with estimator and hardware support for one flight-controller microcontroller.

    Source: §I · p. 1

  • Results

    12.38 m/s indoors and 31.4 m/s outdoors were reached in fully onboard autonomous flights.

    Source: §I · p. 1, B. Indoor validation · p. 3, C. Outdoor validation · p. 3

  • Takeaways & Limitations

    The flights validate a complete onboard perception-to-actuation path on one STM32H743 using MoCap indoors and RTK GNSS outdoors.

    Source: A. Experimental configuration · p. 3, B. Indoor validation · p. 3, C. Outdoor validation · p. 3

    Some algorithms, including aggressive predictive controllers, exceed the flight microcontroller’s computational budget.

    Source: §V · p. 4

Abstract

from arXiv · show

Bringing an aerial robotics method from simulation to flight should not require rebuilding a mature autopilot or adding a companion computer. Cybflight is an open-source embedded Rust research autopilot whose typed, replaceable interfaces connect hardware access, perception, state estimation, trajectory planning, and control. This modular development and compile-time optimization workflow is demonstrated with replaceable Rust implementations of model predictive contour-tracking control (MPCTC) and incremental nonlinear dynamic inversion (INDI) running on one STM32H743 without a companion computer. Using this configuration, the vehicle reaches 12.38 m/s during indoor flight, while an outdoor flight using global navigation satellite system (GNSS) position updates reaches 31.4 m/s. These flights show that running demanding estimation and nonlinear control entirely on a flight-controller microcontroller need not come at the expense of a modular autopilot structure.

I. INTRODUCTION

Cybflight addresses the firmware-specific effort of changing mature autopilots and the costs of companion computers with a modular embedded Rust autopilot. Its MPCTC–INDI demonstration runs on one flight-controller microcontroller and supports high-speed indoor and outdoor flights.

I. INTRODUCTION

  • Changing a core estimator or controller in a mature autopilot can require substantial firmware-specific work across device abstractions, configuration layers, and coupled subsystems.That adaptation effort can rival the effort of evaluating the method itself.Source: §I · p. 1
  • A Linux companion computer adds compute but also mass, power, wiring, integration work, and cost to small high-speed aircraft.Payload margin is scarce, and crashes risk another expensive component.Source: §I · p. 1
  • Cybflight uses typed interfaces to separate hardware access, perception, estimation, planning, control, and actuation, so implementations can be replaced without reorganizing neighboring modules.Vehicle descriptions select implementations at build time, allowing compile-time specialization for the target microcontroller.Source: §I · p. 1
  • Replaceable Rust implementations of MPCTC and INDI compile with the selected estimator and hardware support into one flight-controller microcontroller program.This demonstrates the modular development and compile-time optimization workflow.Source: §I · p. 1
  • 12.38 m/s indoors and 31.4 m/s outdoors were reached in fully onboard autonomous flights.The outdoor flight used GNSS position updates and fully onboard MPCTC–INDI.Source: §I · p. 1, Figure 1 · p. 1

II. RELATED WORK

Existing aerial-robotics platforms differ in how they accommodate new algorithms and where computation runs. Cybflight combines replaceable interfaces across the perception-to-actuation path with state estimation, nonlinear MPCTC, and INDI on one microcontroller.

II. RELATED WORK

  • Research platforms vary in how they admit new algorithms and whether execution is on the flight-controller microcontroller, a companion computer, or offboard hardware.That execution choice shapes the research workflow.Source: §II · p. 1
  • Related platforms include PX4’s NuttX tasks and uORB middleware, Betaflight paired with Jetson-based autonomy, and MonoRace’s split between Jetson vision and estimation and an embedded neural policy [4],.The passage notes that adding an estimator or controller to PX4 often requires firmware-specific work.Source: §II · p. 1
  • Agilicious co-designs open hardware and software around interchangeable estimators, controllers, and flight-controller bridges.Cybflight’s flight graph depicts hardware interfaces mapping sensor observations and actuator commands to a hardware-independent research core.Source: §II · p. 2, Figure 2 · p. 2
  • MPC’s online optimization is computationally demanding, so aggressive MPCC commonly runs on companion computers; embedded MPC work narrows the online problem through linear dynamics or short horizons and real-time iterations.MPCC++ uses a 100-Hz optimizer on an Intel processor and sends thrust and body-rate commands to Betaflight; TinyMPC uses linear dynamics, and embedded NMPC uses short horizons and real-time iterations [10].Source: §II · p. 2
  • Cybflight brings Rust migration, shared embedded/host estimation, and educational flight-stack work,, [13] together in one Rust-native embedded program.Its replaceable interfaces span perception to actuation, while state estimation, a 20-step nonlinear MPCTC, and INDI run on the same microcontroller.Source: §II · p. 2

III. CYBFLIGHT ARCHITECTURE

Cybflight combines modular interfaces with an embedded numerical core to keep research algorithms replaceable while supporting readable, predictable model-based code on the microcontroller.

III. CYBFLIGHT ARCHITECTURE

  • Modular interfaces separate hardware support from replaceable research algorithms.This is one of Cybflight’s two stated design choices.Source: §III · p. 2
  • An embedded numerical core keeps model-based code readable and predictable on the microcontroller.This is the second stated design choice.Source: §III · p. 2
  • Cybflight’s architecture pairs hardware/algorithm separation with an embedded numerical core.The passage presents these as complementary design choices.Source: §III · p. 2

A. Separating hardware from research algorithms

Typed interfaces pass information rather than device handles between hardware-facing modules and a board-independent research core. Build-time selection and fixed-capacity resources support implementation changes without restructuring neighboring modules.

A. Separating hardware from research algorithms

  • Typed observations, vehicle states, references, and actuator commands form module boundaries, exchanging information rather than device handles.Hardware interfaces isolate hardware-facing perception and actuation from the board-independent research core.Source: A. Separating hardware from research… · p. 2
  • MoCap and GNSS adapters publish the same vehicle-odometry type, allowing position sources to change without changing estimation or control.Trajectory representation is also separated from reference sampling.Source: A. Separating hardware from research… · p. 2
  • At build time, a vehicle configuration selects implementations for compiler specialization, while fixed-capacity channels and workspaces make memory use known before flight.These boundaries support replacing a board, estimator, controller, or learned policy without restructuring neighboring modules.Source: A. Separating hardware from research… · p. 2

B. Embedded numerical core

Cybflight uses fixed-size numerical types to keep embedded mathematics explicit and avoid dynamic allocation. The shared attitude Hessian and related fixed-size patterns support both MPCTC and NMPC.

B. Embedded numerical core

  • Fixed-size nalgebra types keep vectors, matrices, rotations, and unit quaternions explicit without dynamic allocation in no_std code.The compiler can catch dimension mismatches in code that stays close to the equations.Source: B. Embedded numerical core · p. 2
  • The Gauss–Newton attitude Hessian is shared by MPCTC and NMPC, with operand types encoding matrix dimensions.Listing 1 presents the fixed-size Hessian.Source: B. Embedded numerical core · p. 2
  • The STM32H743 flight controller shown executes all estimation and control.Source: Figure 3 · p. 3
  • The same fixed-size pattern is used for model Jacobians, cost derivatives, and horizon workspaces.Source: B. Embedded numerical core · p. 3

IV. HIGH-SPEED FLIGHT VALIDATION

Indoor and outdoor high-speed flights evaluate Cybflight with the complete perception-to-actuation path onboard. Changing only the position source makes these flights a system-level test beyond comparisons between control methods.

IV. HIGH-SPEED FLIGHT VALIDATION

  • The complete perception-to-actuation path runs onboard in both indoor and outdoor flight tests.Source: §IV · p. 3
  • The indoor and outdoor tests change only the position source.Source: §IV · p. 3
  • High-speed flight provides a demanding system-level test beyond comparisons between control methods.Source: §IV · p. 3

A. Experimental configuration

The experiments use an ESKF, MPCTC, and an INDI inner loop on a 480-MHz STM32H743 without a companion computer. MoCap and RTK GNSS provide indoor and outdoor position updates, respectively.

A. Experimental configuration

  • MPCTC commands collective thrust and body rates, while an INDI inner loop tracks them using angular acceleration and a control-effectiveness model before rotor-command allocation.Source: A. Experimental configuration · p. 3
  • The reference is generated using the authors’ previous planning methods,.Source: A. Experimental configuration · p. 3
  • The 0.60-kg vehicle runs the complete feedback path on a 480-MHz STM32H743 without a companion computer.It has a 0.227-m diagonal arm length and nominal thrust-to-weight ratio of 8.2.Source: A. Experimental configuration · p. 3
  • MoCap and RTK GNSS update the ESKF indoors and outdoors, respectively; tracking error is distance from estimated position to the nearest planned-path point.Source: A. Experimental configuration · p. 3

B. Indoor validation

Indoor flights across several path types and aggressiveness levels reach 12.38 m/s with 0.153 m root-mean-square tracking error. The section also reports MPCTC solve times and a time-optimal Split-S flight.

B. Indoor validation

  • 12.38 m/s with 0.153 m root-mean-square tracking error is achieved across circle, figure-eight, slalom, and Split-S flights at three aggressiveness levels.Fig. 6(a) describes the speed–tracking-error correlation; Fig. 4 shows a flight in the image plane and Fig. 5 reports the Split-S trajectory and tracking error.Source: B. Indoor validation · p. 3
  • 4.29-ms mean, 4.27-ms median, and 4.55-ms maximum successful MPCTC solve times are reported for a 10-ms schedule.Source: B. Indoor validation · p. 3
  • The indoor flight composite is shown in Fig. 4.Source: Figure 4 · p. 3
  • 11.90 m/s and 0.278 m root-mean-square tracking error are reported for the 73.7-m planned time-optimal Split-S path.Fig. 5 shows the planned path and speed-colored executed trajectory, plus three-dimensional tracking error with its mean marked by a dashed line.Source: Figure 5 · p. 3

C. Outdoor validation

With reference generation and control unchanged, outdoor validation replaces MoCap with RTK GNSS and reaches 31.4 m/s.

C. Outdoor validation

V. DISCUSSION AND CONCLUSION

Cybflight runs the complete perception-to-actuation path on one STM32H743, with typed interfaces supporting modular changes. Its build-time composition brings constraints and future extensions.

V. DISCUSSION AND CONCLUSION

  • Cybflight runs the complete perception-to-actuation path on one STM32H743, showing that demanding estimation and nonlinear control can run onboard.Source: §V · p. 3
  • Fig. 6 presents indoor speed and tracking error across path geometries and aggressiveness levels, alongside the MPCTC solve-time distribution.The dashed line marks the mean solve time.Source: Figure 6 · p. 4
  • Build-time composition means module changes require rebuilding and flashing; fixed-size types catch matrix-dimension errors but not physical-unit or coordinate-frame mistakes.The paper says configurations are verified on the vehicle and new methods remain local to their modules.Source: §V · p. 4
  • The typed interfaces are intended to connect embedded neural policies through the same state, reference, and actuator boundaries as model-based controllers.Source: §V · p. 4
  • Future swarm support would add typed peer-state and coordination interfaces while keeping perception, estimation, and control onboard.Vehicles would share only information needed for coordination.Source: §V · p. 4
  • Some algorithms may exceed the flight microcontroller’s budget; transport adapters are proposed to move them among onboard, companion, and offboard hardware.Aggressive predictive controllers are given as an example of algorithms that often run on larger processors.Source: §V · p. 4
Loading 2609.31232v1…