Aerial Autonomy Stack
Develop, simulate, and deploy perception-driven multi-drone autonomy across PX4, ArduPilot, ROS2, and Jetson.
- Source repo
- JacopoPan/aerial-autonomy-stack
- Stars
- ★ 642
- Last updated
- 1d ago
- License
- MIT
- Primary language
- C++
- FA score
- 68/100 · Some gaps
At a glance
- How it runs
- Works with
- Platform-specific
- Cost
- Free, no paid service needed
- Setup effort
- High · needs real infrastructure
- You'll need
- Typical use
- A drone autonomy team needs to exercise the same high-level ROS2 actions against both PX4 and ArduPilot on quadrotors, VTOLs, or tailsitters.
- Not a fit if
- Teams without NVIDIA GPUs or CUDA
- Users needing a native Windows runtime
- Hobbyists wanting a quick laptop-only trial
- Source review
- 68/100 · Some gaps 1 safety controls not found
What does this agent do, and when should you use it?
Aerial Autonomy Stack (AAS) is a flight-proven open framework spanning multi-vehicle development, faster-than-real-time simulation, and Jetson-based deployment. It packages PX4 or ArduPilot, ROS2 Jazzy, Gazebo Sim, YOLO, KISS-ICP LiDAR odometry, and ground-system services into Docker containers. Quadrotors, quadplane VTOLs, and tailsitters can be flown through ROS2 actions, behavior-tree missions, or a synchronized ground formation controller. Its simulator supports adjustable real-time factors, parallel instances, camera and 3D LiDAR data, and a steppable Gymnasium interface. The documented deployment boundary is an NVIDIA Jetson Orin aircraft computer connected to a Pixhawk, plus an optional ground computer; this is a robotics autonomy stack, not a ChatGPT, Codex, or model-API agent.
The end-to-end simulation begins with sim_run.sh: a simulation container runs Gazebo worlds and one or more PX4 or ArduPilot SITL vehicles, then sends camera, LiDAR, UDP, and MAVLink data to aircraft containers. On each aircraft, yolo_py acquires GStreamer video and publishes YOLO bounding boxes, while kiss_icp supplies LiDAR odometry; mission, offboard_control, autopilot_interface, and drone_traffic_client turn missions or references into PX4 Offboard or ArduPilot Guided commands. In the ground container, drone_traffic_controller publishes formation commands and ground_system publishes tracks, with Zenoh bridging selected ROS2 topics between the ground and aircraft domains. Operators can invoke Takeoff, Land, Orbit, and Offboard actions, reposition and speed services, and gimbal topics. Flight data can be recorded and inspected through flight_review, MAVExplorer, or PlotJuggler. The aas-gym package exposes manual, accelerated, and vectorized Gymnasium execution, while deploy_run.sh runs the aircraft container on a physical Jetson Orin.
- A drone autonomy team needs to exercise the same high-level ROS2 actions against both PX4 and ArduPilot on quadrotors, VTOLs, or tailsitters.
- A perception engineer wants repeatable Gazebo scenes for testing YOLO camera detection alongside KISS-ICP LiDAR odometry.
- A swarm researcher needs synchronized formation control, per-aircraft behavior-tree missions, or several isolated simulation instances.
- A reinforcement-learning researcher needs to step, accelerate, or vectorize the drone simulation through
aas-gym. - An avionics team wants to validate Jetson compute and inter-vehicle networking in multi-Jetson HITL before installing the stack on real aircraft.
- A flight-test engineer needs ROS bags, PX4
.ulglogs, or ArduPilot.binlogs that can be inspected with the documented analysis tools.
How do you install or deploy this agent?
The documented host path requires Ubuntu 24.04, an NVIDIA driver, Docker, and NVIDIA Container Toolkit; the example development machine uses an RTX 3060. Install and build with:
sudo apt update && sudo apt install -y git xterm xfonts-base wget unzip
git clone https://github.com/JacopoPan/aerial-autonomy-stack.git
cd aerial-autonomy-stack/tools_and_docs/
./tests/check_requirements.sh
./sim_build.shThe first build is documented as taking about 45 minutes with a good connection. Prebuilt GHCR images for aircraft, ground, and simulation are also rebuilt from main every Friday. No API credentials or paid-service keys are documented.
How do you use this agent?
Start a simulation containing one quadrotor and one VTOL with:
cd aerial-autonomy-stack/tools_and_docs/
NUM_QUADS=1 NUM_VTOLS=1 WORLD=swiss_town RTF=3 PLOT=true ./sim_run.shFrom the Ground terminal, start synchronized control with:
ros2 run drone_traffic_controller dtc_controller --ros-args -p use_sim_time:=trueFrom an aircraft terminal, run the example behavior-tree mission with:
ros2 run mission mission --conops yalla.yaml --ros-args -r __ns:=/Drone$DRONE_ID -p use_sim_time:=trueAlternatively, send ROS2 goals to /Drone${DRONE_ID}/takeoff_action, land_action, orbit_action, or offboard_action. After installing aas-gym, a first Gymnasium invocation is:
python3 gym_run.py --mode stepFor physical deployment, run ./deploy_build.sh on the Jetson and then, for example:
DRONE_ID=1 CAMERA=true LIDAR=false AIR_SUBNET=10.223 HEADLESS=true ./deploy_run.shAircraft type, autopilot, sensors, headless mode, and rosbag recording are selected through environment variables.
What are this agent's strengths and limitations?
- PX4 and ArduPilot are first-class choices behind a shared set of high-level ROS2 actions.
- The project covers SITL, faster-than-real-time and multi-instance simulation, Gymnasium execution, and multi-Jetson HITL in one stack.
- Camera ingestion, YOLO inference, 3D LiDAR, KISS-ICP, wind effects, and dynamic wave simulation are integrated into the container workflow.
- The aircraft software is packaged for both amd64 simulation and arm64 Jetson deployment, reducing the gap between simulated and onboard execution.
- Users can choose among ground-coordinated formations, per-aircraft behavior-tree missions, and direct ROS2 action control.
- The documented build depends on NVIDIA drivers, CUDA, cuDNN, and NVIDIA Container Toolkit; deployment adds JetPack, DeepStream, and Jetson Orin dependencies.
- Initial setup is heavyweight: about 45 minutes for the simulation build, about 50 minutes for the Jetson arm64 build, and roughly three minutes for the first TensorRT cache.
- Development is documented for Ubuntu 24.04, while Windows 11 support is through WSL rather than a native Windows runtime.
- Gazebo wind is not reflected by the simulated airspeed sensors on VTOLs and tailsitters, so the documentation limits wind testing to quadrotors.
- ArduPilot 4.6.3 is listed while migration to 4.7.1 remains a TODO, creating potential upgrade work for teams standardizing on the newer release.
- Physical testing is documented around a Holybro Jetson Baseboard, Pixhawk 6X, Orin NX 16GB, X650, IMX219, and Livox Mid-360S; evidence for other hardware combinations is not provided.
How does this agent compare with similar options?
AAS presents PX4 Offboard and ArduPilot Guided as alternative autopilot paths. PX4 supports low-level references such as CTBR/VehicleRatesSetpoint, while the ArduPilot examples use velocity and acceleration setpoints. They share high-level ROS2 actions, but controller names, parameter effects, and limitations differ; the documentation notes, for example, that speed changes are ineffective on ArduPilot VTOLs. The autopilot communication layer likewise offers XRCE-DDS or MAVROS paths.
Key facts side by side with the most closely related agents.
| Agent | Source review | Form / cost | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|---|
| Aerial Autonomy Stack This agent | 68 · Some gaps | CLIFree | ★ 642 | 1d ago | C++ | — |
| Jev Drone | 60 · Some gaps | CLIFree + model costs | ★ 289 | 1mo ago | Python | — |
| RAI — Embodied AI Agent Framework for Robotics | 55 · Major gaps | FrameworkFree + model costs | ★ 610 | 14d ago | Python | — |
| Stream Vision Agents | 43 · Major gaps | Library / SDKFree + model costs | ★ 8.2k | today | Python | OpenAI API · Claude API |
How does FollowAgents rate this agent?
Why each dimension lost points
The architecture identifies containers, ROS 2 topics, UDP/TCP and MAVLink links, sensor paths, and the two subnets, earning full data-flow transparency. Some CI jobs narrow permissions to contents/packages, but the runtime stack needs Docker, networking, GPUs, flight-control access, and sudo installation without a systematic least-privilege model. Actions can be cancelled and QGroundControl supervision is suggested, yet takeoff, landing, parameter changes, and cleanup commands execute directly without a consistent high-risk confirmation gate. External effects are documented, including ArduPilot parameter overwrites, development mounts, and container cleanup, but restoration of parameters, aircraft state, or host configuration is thin. No policy covers credentials, log privacy, camera data, or sensitive telemetry. CI checks installation and dependencies, but latest images, mutable external dependencies, and tag-pinned Actions are used without demonstrated locks, checksums, an SBOM, or vulnerability scanning. The project, paper authors, and many third-party assets are attributed, although the relationship among “The Drone Mafia,” the repository account, and the listed authors is not fully explained.
The README, prerequisite checker, installation CI, and PX4/ArduPilot integration jobs are broadly consistent and provide concrete diagnostics for Ubuntu, NVIDIA drivers, Docker, and the container toolkit. Deductions reflect that many capabilities remain README assertions, while shown CI integration covers only one quad without camera or LiDAR on two autopilot paths; numerous external images, hardware components, and network dependencies can also drift. Environment-variable and prerequisite errors are informative, and the performance script retries and reports critical failure, but the evidence does not show uniform actionable error handling and recovery across the complete multi-container flight path.
The material thoroughly identifies development, simulation, Jetson deployment, HITL, Gymnasium, PX4/ArduPilot, multiple airframes, and sensor scenarios, with precise environment variables, enumerated values, and entry commands. Ubuntu 24.04, WSL, amd64/arm64, Jetson Orin, and tested hardware requirements are well described. Several boundaries are explicit, such as wind-model limitations for VTOL sensors, SetSpeed caveats, and ArduPilot readiness delay. The deduction is for the absence of consolidated boundaries around real-flight safety envelopes, link-loss behavior, supported swarm scale, and the maturity of optional advanced modules.
The README is well organized around installation, simulation, deployment, HITL, RL, architecture, and repository structure, with extensive usable examples, expected build times, platform requirements, and a prerequisite checker. Naming and options are generally consistent, but no formal API or configuration stability policy is provided. Several limitations are recorded, though there is no consolidated known-issues section or FAQ. The complete MIT license earns full credit. No release/versioning policy or changelog is supplied, and maintenance responsibility is only inferable from the account, copyright label, and paper authors rather than a stated owner, support route, or update policy.
The documented outputs are directly usable, spanning build and launch procedures, flight actions, log analysis, and Gymnasium operation. Combining PX4, ArduPilot, ROS 2, perception, simulation, and Jetson deployment offers substantial marginal value. Hardware specifications, first-build estimates, and performance figures from a named environment support cost assessment. The deduction reflects single-repetition benchmark cases and the lack of a systematic account of maintenance burden, scaling limits, real-flight risk cost, or comparison against alternatives.
Many README claims point to concrete scripts, source files, configurations, workflows, and architecture nodes. CI and prerequisite scripts internally corroborate installation and a limited subset of integration claims, while performance notes identify a commit, date, and hardware environment. Deductions apply because “flight-proven” and “simplest/fastest” are not substantiated by the supplied files, the cited paper cannot be independently checked from this material, and benchmark results are self-reported comments based on one repetition. Factual descriptions, promotional judgments, and inference are not consistently separated.
- Not found in source: sensitive-data handlingUse dedicated, low-privilege, revocable API keys — never production credentials — and keep secrets out of logs.
- This is a static review of only the supplied files; no build, simulation, HITL, or real flight was run, and the paper, CI outcomes, and performance figures were not independently verified.
- Real-aircraft commands can initiate flight and overwrite ArduPilot parameters. Validate missions, failsafes, link-loss behavior, and parameter restoration in isolated simulation before connecting hardware.
- Do not rely directly on latest containers or mutable dependencies for safety-critical deployment; pin image digests and dependency versions, and add SBOM generation, vulnerability scanning, and provenance checks.
- Camera, LiDAR, telemetry, flight logs, and bridged network traffic may contain sensitive or regulated data, but the supplied material provides no retention, access-control, or privacy policy.
Recent releases
Latest entries from the project's GitHub Releases. Notes are quoted from upstream as written, not rewritten or tested by FollowAgents.
-
v3.0.0 Betaflight Release
Release notes excerpt
New Features: - Multi-drone Betaflight SITL simulation and ROS2 interfaces for autopilot actions and MSP override control #192 - Non-contiguous drone IDs and stereo CSI camera in deployment #181 Fixes: - Handle external mode change during an Offboard action #188 Updates - ONNX Runtime 1.31 #193View on GitHub ↗ -
v2.0.0 JetPack 7 Release
Release notes excerpt
New Features: - MCAP rosbag recording https://github.com/JacopoPan/aerial-autonomy-stack/pull/171 Fixes: - Time-aligned multi-drone logs plotting https://github.com/JacopoPan/aerial-autonomy-stack/pull/173 Updates - Upgrade to ROS Jazzy, Ubuntu 24, JetPack 7.2.1, DeepStream 9.1 with support for NVIDIA Driver 595/610, CUDA 13 https://github.com/JacopoPan/aerial-autonomy-stack/pull/84View on GitHub ↗ -
v1.6.0 Advanced SITL Release
Release notes excerpt
New Features: - New cave world based on DARPA SubT's [simple_cave_02](https://github.com/osrf/subt/tree/master/subt_ign/worlds) for LiDAR odometry and SLAM #168 - SiK f90546a95e28b964e9d821723e2d69a754e50d84 and Microhard 592ce00e746d18215d301e6b4db8a51ddc077162 telemetry configuration with AT commands Fixes: - Revised which links/plugins/SITL sensors interact with Gazebo's WindEffects for all vehicle models, tuning of force_approximation_scaling_factor for the multicopter models #167 …View on GitHub ↗
FAQ
Does it require a cloud service, model API, or secret key?
Can it run without an NVIDIA GPU?
Can it control a physical drone?
Can I use only the simulator or Gymnasium layer?
sim_run.sh supports SITL, parallel instances, and real-time-factor control, while aas-gym includes step, speedup, and vectorenv-speedup examples without requiring a physical aircraft.