ROSflight 2.0: Lean ROS 2-Based Autopilot for Unmanned Aerial Vehicles

TL;DR

This paper presents ROSflight 2.0, a lean ROS 2–based autopilot designed for UAV research that emphasizes clarity, modularity, and ease of transition from simulation to hardware. It details design updates, notably the ROS 1-to-ROS 2 migration, a flexible mixer framework with predefined, custom, and pass-through modes, and empirical motor parameters, all implemented atop a hardware abstraction layer. The integration updates include multiple hardware configurations and a modular SIL simulation environment supporting three simulators, enabling software-in-the-loop testing and rapid development. Hardware demonstrations validate 400 Hz control via a companion computer in pass-through mode and quantify serial RTT performance, illustrating ROSflight’s capability to accelerate research in advanced air mobility. Overall, ROSflight 2.0 enhances usability and modularity, facilitating faster research iterations by moving most autonomy to the companion computer while maintaining a clear, well-documented codebase.

Abstract

ROSflight is a lean, open-source autopilot ecosystem for unmanned aerial vehicles (UAVs). Designed by researchers for researchers, it is built to lower the barrier to entry to UAV research and accelerate the transition from simulation to hardware experiments by maintaining a lean (not full-featured), well-documented, and modular codebase. This publication builds on previous treatments and describes significant additions to the architecture that improve the modularity and usability of ROSflight, including the transition from ROS 1 to ROS 2, supported hardware, low-level actuator mixing, and the simulation environment. We believe that these changes improve the usability of ROSflight and enable ROSflight to accelerate research in areas like advanced-air mobility. Hardware results are provided, showing that ROSflight is able to control a multirotor over a serial connection at 400 Hz while closing all control loops on the companion computer.

Figures (6)

• Figure 1: Overview of the ROSflight archtecture.
• Figure 2: Diagram of how the ROSflight mixer interfaces with other ROSflight modules. The mixer takes in either the output of a controller or setpoints that bypass the controller, called pass-through commands, and outputs actuator signals. The setpoints are created by the onboard computer or the RC safety pilot.
• Figure 3: Diagram of how the ROSflight mixer, $M$, is constructed from the primary and secondary mixers based on which RC overrides are active. Note that the header information (PWM rate and output type) for $M$ is always constructed from the primary mixer's header information.
• Figure 4: Hardware elements
• Figure 5: Recorded RTT for offboard commands published at 400 Hz for both hardware configurations.