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.
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
You'll need the submodules and dependencies, so clone like so:
git clone --recurse-submodules https://github.com/genemerewether/quest-fw
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):
To build the simulation example:
Go to the SIMREF folder, and run the following:
Then, you can run the executable like so (after starting ROS master):
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.
Simulation (RotorS ROS interface)
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