Why another flight stack?

QUEST is for power-users who were going to connect a powerful Linux SOC and do significant software customization anyway. If you’ve ever been frustrated with the complexity/bulk of MAVLink, mavros, the PX4 pub/sub architecture, and NuttX when you really just want a bare-metal flight controller connected to a Linux box over a customizable UART protocol, QUEST is for you. If you want to move from simulation to hardware, while maintaining an easy link with the ROS packages you create and rely on, QUEST is for you.

QUEST is not for people who expect an out-of-the-box experience without tuning on a wide range of platforms, and does not support many typical 2D drone use cases inside the stack itself (waypoint following, return to land, etc.). Rather, we target a small number of platforms with code for excellent and predictable performance for these use cases: robotics and autonomous high-performance 3D flight. In addition, only functionality with a high degree of reuse and/or a need for tight coupling to the hardware or high loop rates is moved inside the flight stack, while the rest of the functionality can leverage existing open-source software and/or be rapidly prototyped in ROS.

Which middleware?

ROS1 has nonexistent embedded support, with limited ability to generate embedded message libraries for communication over the wire. ROS2 development timelines are long, and nearly all the existing work focuses on the same types of devices that ROS1 already supports.

We use F’, https://github.com/nasa/fprime, a high-performance C++ software framework proven on multiple CubeSat flight missions and many robotics / technology development projects at NASA’s Jet Propulsion Laboratory, CMU / Astrobotic, and Cornell, among other institutions.

Get the COde


One-time setup:

You'll need the submodules and dependencies, so clone like so:

Or, after cloning, run:

  • git submodule update --init --recursive 

To get the F’ dependencies on Ubuntu (all dependencies are available through Homebrew on Mac):

  • sudo apt-get install pkg-config g++ python-pip python-lxml python-tk python-dev

On all platforms (modify the pip command if you don’t want a global install)

  • sudo -H pip install -r Gse/bin/required.txt

Then, go to the ROS/fprime_ws folder, and build the workspace with your ROS environment sourced (tested with catkin):

  1. catkin init

  2. catkin build

To build the simulation example:

Go to the SIMREF folder, and run the following:

  1. make gen_make

  2. make

Then, you can run the executable like so (after starting ROS master):

ROS_NAMESPACE=firefly ./linux-linux-x86-debug-gnu-bin/SIMREF

When you start the RotorS (https://github.com/ethz-asl/rotors_simulator) firefly example, SIMREF will use the /clock message to carry out control cycles. This parallels what happens on hardware targets, where the IMU data-ready interrupt triggers the estimation and control loops.

Supported platforms

  • Snapdragon Flight

  • TI TMS570

  • Simulation (RotorS ROS interface)

Future roadmap

  • px4fmu v5 hardware support

  • Tracking improvements to upstream F’

  • Fixed-wing motion planning and controls

  • Reintegration of TORQ 3D Ground Control Station and trajectory optimization workbench