Repository Summary
| Description | |
| Checkout URI | https://github.com/castacks/airstack.git |
| VCS Type | git |
| VCS Version | develop |
| Last Updated | 2026-09-11 |
| Dev Status | UNKNOWN |
| Released | UNRELEASED |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Packages
| Name | Version |
|---|---|
| airstack_common | 0.0.0 |
| coordination_bringup | 0.0.0 |
| coordination_msgs | 0.0.0 |
| desktop_bringup | 0.0.0 |
| rqt_py_template | 1.0.2 |
| waypoint_rviz2_plugin | 1.0.0 |
| rviz_tasks_panel | 0.0.0 |
| bag_record_pid | 0.0.0 |
| logging_bringup | 0.0.0 |
| airstack_msgs | 1.0.0 |
| behavior_tree_msgs | 0.0.0 |
| task_msgs | 0.0.0 |
| robot_descriptions | 0.0.0 |
| action_relay | 0.0.1 |
| gcs_visualizer | 0.0.1 |
| zed_wrapper | 4.1.0 |
| autonomy_bringup | 0.0.0 |
| drone_safety_monitor | 0.0.0 |
| global_bringup | 0.0.0 |
| global_plan_navigate_bridge | 0.1.0 |
| random_walk_planner | 0.0.0 |
| interface_bringup | 0.0.0 |
| mavros_interface | 0.0.0 |
| robot_interface | 0.0.0 |
| mav_comm | 3.3.3 |
| mav_msgs | 3.3.3 |
| mav_planning_msgs | 3.3.3 |
| mav_state_machine_msgs | 0.0.0 |
| mav_system_msgs | 0.0.0 |
| pid_controller | 0.0.0 |
| pid_controller_msgs | 0.0.0 |
| trajectory_controller | 0.0.0 |
| takeoff_landing_planner | 0.0.0 |
| trajectory_library | 0.0.0 |
| perception_bringup | 0.0.0 |
| lidar_point_cloud_filter | 0.1.0 |
| ms_airsim_ros_bridge | 0.1.0 |
| sim | 0.0.0 |
| hello_module | 0.1.0 |
README
AirStack
**Build the autonomy, not the scaffolding.**
AirStack is an open ROS 2 stack for aerial robots — simulator, ground control,
and layered onboard autonomy that launch as one system. Developed by the
[AirLab](https://theairlab.org) at Carnegie Mellon University's Robotics Institute.
[](LICENSE)
[](https://docs.theairlab.org)
*Three drones flying the real stack in Isaac Sim, the Foxglove GCS, and MS AirSim —
recorded from this repo, unstaged. Watch the live demos on the
[documentation home page](https://docs.theairlab.org).*
Zero → drones flying in sim
git clone --recursive -j8 git@github.com:castacks/AirStack.git && cd AirStack
./airstack.sh install && ./airstack.sh setup
airstack up --play --wait
Then follow the Getting Started guide and the Modular AirStack Walkthrough. No Linux box or GPU? Run AirStack on OSMO from any laptop.
One command brings up sim, robots, and ground control
airstack up starts the simulator, one container per robot, and a
Foxglove-based ground control station, wired together over ROS 2. Flags select
the simulator, scene, and fleet size — no launch-file surgery:
airstack up --sim airsim --scene neighborhood
airstack up --sim isaac --robots 3 --scene full-warehouse
airstack up --fleet sim_three_mixed
airstack ready blocks until the stack is flight-ready — containers running,
sim publishing /clock, autonomy nodes up, PX4 EKF armable — so scripts and CI
know exactly when takeoff is available.
Same code in sim and on the vehicle
The desktop dev container and the Jetson (L4T) onboard container extend one
base service and launch the same stack entry point
(stacks/full_default/launch/stack.launch.xml). What you test in simulation is
what the vehicle runs.
CI flies the whole stack, not just unit tests
Pull requests run pytest campaigns against the live simulators on ephemeral GPU
runners: image builds, colcon builds in every container, bring-up liveliness,
sensor topic rates, takeoff–hover–land, fixed trajectories with cross-track
error, and waypoint navigation judged on the odometry track. Run them yourself,
or comment /pytest on a PR:
airstack test -m takeoff_hover_land --sim isaacsim --num-robots 1 -v
Marks are defined in tests/; metrics regressions fail the report.
AI agents can drive this repo
Module boundaries, an AGENTS.md contract, and 23 step-by-step
skills under .agents/skills/ give coding agents the same
on-ramp as humans: scaffold a package, wire it into a stack, fly it in sim,
document it. Every demo video on the documentation home page was captured by an
AI agent — it brought the stack up, scripted the flights, implemented the
follow-camera it filmed with, and edited the clips.
Modular architecture
AirStack follows a layered autonomy architecture:
``` Robot ├── Interface Layer: Communication with robot controllers ├── Sensors Layer: Data acquisition from various sensors ├── Perception Layer: State estimation and environment understanding ├── Local Layer: │ ├── World Models: Local environment representation │ ├── Planners: Trajectory generation and obstacle avoidance │ └── Controls: Trajectory following ├── Global Layer: │ ├── World Models: Global environment mapping │ └── Planners: Mission-level path planning └── Behavior Layer: High-level decision making
File truncated at 100 lines see the full file
CONTRIBUTING
Repository Summary
| Description | |
| Checkout URI | https://github.com/castacks/airstack.git |
| VCS Type | git |
| VCS Version | develop |
| Last Updated | 2026-09-11 |
| Dev Status | UNKNOWN |
| Released | UNRELEASED |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Packages
| Name | Version |
|---|---|
| airstack_common | 0.0.0 |
| coordination_bringup | 0.0.0 |
| coordination_msgs | 0.0.0 |
| desktop_bringup | 0.0.0 |
| rqt_py_template | 1.0.2 |
| waypoint_rviz2_plugin | 1.0.0 |
| rviz_tasks_panel | 0.0.0 |
| bag_record_pid | 0.0.0 |
| logging_bringup | 0.0.0 |
| airstack_msgs | 1.0.0 |
| behavior_tree_msgs | 0.0.0 |
| task_msgs | 0.0.0 |
| robot_descriptions | 0.0.0 |
| action_relay | 0.0.1 |
| gcs_visualizer | 0.0.1 |
| zed_wrapper | 4.1.0 |
| autonomy_bringup | 0.0.0 |
| drone_safety_monitor | 0.0.0 |
| global_bringup | 0.0.0 |
| global_plan_navigate_bridge | 0.1.0 |
| random_walk_planner | 0.0.0 |
| interface_bringup | 0.0.0 |
| mavros_interface | 0.0.0 |
| robot_interface | 0.0.0 |
| mav_comm | 3.3.3 |
| mav_msgs | 3.3.3 |
| mav_planning_msgs | 3.3.3 |
| mav_state_machine_msgs | 0.0.0 |
| mav_system_msgs | 0.0.0 |
| pid_controller | 0.0.0 |
| pid_controller_msgs | 0.0.0 |
| trajectory_controller | 0.0.0 |
| takeoff_landing_planner | 0.0.0 |
| trajectory_library | 0.0.0 |
| perception_bringup | 0.0.0 |
| lidar_point_cloud_filter | 0.1.0 |
| ms_airsim_ros_bridge | 0.1.0 |
| sim | 0.0.0 |
| hello_module | 0.1.0 |
README
AirStack
**Build the autonomy, not the scaffolding.**
AirStack is an open ROS 2 stack for aerial robots — simulator, ground control,
and layered onboard autonomy that launch as one system. Developed by the
[AirLab](https://theairlab.org) at Carnegie Mellon University's Robotics Institute.
[](LICENSE)
[](https://docs.theairlab.org)
*Three drones flying the real stack in Isaac Sim, the Foxglove GCS, and MS AirSim —
recorded from this repo, unstaged. Watch the live demos on the
[documentation home page](https://docs.theairlab.org).*
Zero → drones flying in sim
git clone --recursive -j8 git@github.com:castacks/AirStack.git && cd AirStack
./airstack.sh install && ./airstack.sh setup
airstack up --play --wait
Then follow the Getting Started guide and the Modular AirStack Walkthrough. No Linux box or GPU? Run AirStack on OSMO from any laptop.
One command brings up sim, robots, and ground control
airstack up starts the simulator, one container per robot, and a
Foxglove-based ground control station, wired together over ROS 2. Flags select
the simulator, scene, and fleet size — no launch-file surgery:
airstack up --sim airsim --scene neighborhood
airstack up --sim isaac --robots 3 --scene full-warehouse
airstack up --fleet sim_three_mixed
airstack ready blocks until the stack is flight-ready — containers running,
sim publishing /clock, autonomy nodes up, PX4 EKF armable — so scripts and CI
know exactly when takeoff is available.
Same code in sim and on the vehicle
The desktop dev container and the Jetson (L4T) onboard container extend one
base service and launch the same stack entry point
(stacks/full_default/launch/stack.launch.xml). What you test in simulation is
what the vehicle runs.
CI flies the whole stack, not just unit tests
Pull requests run pytest campaigns against the live simulators on ephemeral GPU
runners: image builds, colcon builds in every container, bring-up liveliness,
sensor topic rates, takeoff–hover–land, fixed trajectories with cross-track
error, and waypoint navigation judged on the odometry track. Run them yourself,
or comment /pytest on a PR:
airstack test -m takeoff_hover_land --sim isaacsim --num-robots 1 -v
Marks are defined in tests/; metrics regressions fail the report.
AI agents can drive this repo
Module boundaries, an AGENTS.md contract, and 23 step-by-step
skills under .agents/skills/ give coding agents the same
on-ramp as humans: scaffold a package, wire it into a stack, fly it in sim,
document it. Every demo video on the documentation home page was captured by an
AI agent — it brought the stack up, scripted the flights, implemented the
follow-camera it filmed with, and edited the clips.
Modular architecture
AirStack follows a layered autonomy architecture:
``` Robot ├── Interface Layer: Communication with robot controllers ├── Sensors Layer: Data acquisition from various sensors ├── Perception Layer: State estimation and environment understanding ├── Local Layer: │ ├── World Models: Local environment representation │ ├── Planners: Trajectory generation and obstacle avoidance │ └── Controls: Trajectory following ├── Global Layer: │ ├── World Models: Global environment mapping │ └── Planners: Mission-level path planning └── Behavior Layer: High-level decision making
File truncated at 100 lines see the full file
CONTRIBUTING
Repository Summary
| Description | |
| Checkout URI | https://github.com/castacks/airstack.git |
| VCS Type | git |
| VCS Version | develop |
| Last Updated | 2026-09-11 |
| Dev Status | UNKNOWN |
| Released | UNRELEASED |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Packages
| Name | Version |
|---|---|
| airstack_common | 0.0.0 |
| coordination_bringup | 0.0.0 |
| coordination_msgs | 0.0.0 |
| desktop_bringup | 0.0.0 |
| rqt_py_template | 1.0.2 |
| waypoint_rviz2_plugin | 1.0.0 |
| rviz_tasks_panel | 0.0.0 |
| bag_record_pid | 0.0.0 |
| logging_bringup | 0.0.0 |
| airstack_msgs | 1.0.0 |
| behavior_tree_msgs | 0.0.0 |
| task_msgs | 0.0.0 |
| robot_descriptions | 0.0.0 |
| action_relay | 0.0.1 |
| gcs_visualizer | 0.0.1 |
| zed_wrapper | 4.1.0 |
| autonomy_bringup | 0.0.0 |
| drone_safety_monitor | 0.0.0 |
| global_bringup | 0.0.0 |
| global_plan_navigate_bridge | 0.1.0 |
| random_walk_planner | 0.0.0 |
| interface_bringup | 0.0.0 |
| mavros_interface | 0.0.0 |
| robot_interface | 0.0.0 |
| mav_comm | 3.3.3 |
| mav_msgs | 3.3.3 |
| mav_planning_msgs | 3.3.3 |
| mav_state_machine_msgs | 0.0.0 |
| mav_system_msgs | 0.0.0 |
| pid_controller | 0.0.0 |
| pid_controller_msgs | 0.0.0 |
| trajectory_controller | 0.0.0 |
| takeoff_landing_planner | 0.0.0 |
| trajectory_library | 0.0.0 |
| perception_bringup | 0.0.0 |
| lidar_point_cloud_filter | 0.1.0 |
| ms_airsim_ros_bridge | 0.1.0 |
| sim | 0.0.0 |
| hello_module | 0.1.0 |
README
AirStack
**Build the autonomy, not the scaffolding.**
AirStack is an open ROS 2 stack for aerial robots — simulator, ground control,
and layered onboard autonomy that launch as one system. Developed by the
[AirLab](https://theairlab.org) at Carnegie Mellon University's Robotics Institute.
[](LICENSE)
[](https://docs.theairlab.org)
*Three drones flying the real stack in Isaac Sim, the Foxglove GCS, and MS AirSim —
recorded from this repo, unstaged. Watch the live demos on the
[documentation home page](https://docs.theairlab.org).*
Zero → drones flying in sim
git clone --recursive -j8 git@github.com:castacks/AirStack.git && cd AirStack
./airstack.sh install && ./airstack.sh setup
airstack up --play --wait
Then follow the Getting Started guide and the Modular AirStack Walkthrough. No Linux box or GPU? Run AirStack on OSMO from any laptop.
One command brings up sim, robots, and ground control
airstack up starts the simulator, one container per robot, and a
Foxglove-based ground control station, wired together over ROS 2. Flags select
the simulator, scene, and fleet size — no launch-file surgery:
airstack up --sim airsim --scene neighborhood
airstack up --sim isaac --robots 3 --scene full-warehouse
airstack up --fleet sim_three_mixed
airstack ready blocks until the stack is flight-ready — containers running,
sim publishing /clock, autonomy nodes up, PX4 EKF armable — so scripts and CI
know exactly when takeoff is available.
Same code in sim and on the vehicle
The desktop dev container and the Jetson (L4T) onboard container extend one
base service and launch the same stack entry point
(stacks/full_default/launch/stack.launch.xml). What you test in simulation is
what the vehicle runs.
CI flies the whole stack, not just unit tests
Pull requests run pytest campaigns against the live simulators on ephemeral GPU
runners: image builds, colcon builds in every container, bring-up liveliness,
sensor topic rates, takeoff–hover–land, fixed trajectories with cross-track
error, and waypoint navigation judged on the odometry track. Run them yourself,
or comment /pytest on a PR:
airstack test -m takeoff_hover_land --sim isaacsim --num-robots 1 -v
Marks are defined in tests/; metrics regressions fail the report.
AI agents can drive this repo
Module boundaries, an AGENTS.md contract, and 23 step-by-step
skills under .agents/skills/ give coding agents the same
on-ramp as humans: scaffold a package, wire it into a stack, fly it in sim,
document it. Every demo video on the documentation home page was captured by an
AI agent — it brought the stack up, scripted the flights, implemented the
follow-camera it filmed with, and edited the clips.
Modular architecture
AirStack follows a layered autonomy architecture:
``` Robot ├── Interface Layer: Communication with robot controllers ├── Sensors Layer: Data acquisition from various sensors ├── Perception Layer: State estimation and environment understanding ├── Local Layer: │ ├── World Models: Local environment representation │ ├── Planners: Trajectory generation and obstacle avoidance │ └── Controls: Trajectory following ├── Global Layer: │ ├── World Models: Global environment mapping │ └── Planners: Mission-level path planning └── Behavior Layer: High-level decision making
File truncated at 100 lines see the full file
CONTRIBUTING
Repository Summary
| Description | |
| Checkout URI | https://github.com/castacks/airstack.git |
| VCS Type | git |
| VCS Version | develop |
| Last Updated | 2026-09-11 |
| Dev Status | UNKNOWN |
| Released | UNRELEASED |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Packages
| Name | Version |
|---|---|
| airstack_common | 0.0.0 |
| coordination_bringup | 0.0.0 |
| coordination_msgs | 0.0.0 |
| desktop_bringup | 0.0.0 |
| rqt_py_template | 1.0.2 |
| waypoint_rviz2_plugin | 1.0.0 |
| rviz_tasks_panel | 0.0.0 |
| bag_record_pid | 0.0.0 |
| logging_bringup | 0.0.0 |
| airstack_msgs | 1.0.0 |
| behavior_tree_msgs | 0.0.0 |
| task_msgs | 0.0.0 |
| robot_descriptions | 0.0.0 |
| action_relay | 0.0.1 |
| gcs_visualizer | 0.0.1 |
| zed_wrapper | 4.1.0 |
| autonomy_bringup | 0.0.0 |
| drone_safety_monitor | 0.0.0 |
| global_bringup | 0.0.0 |
| global_plan_navigate_bridge | 0.1.0 |
| random_walk_planner | 0.0.0 |
| interface_bringup | 0.0.0 |
| mavros_interface | 0.0.0 |
| robot_interface | 0.0.0 |
| mav_comm | 3.3.3 |
| mav_msgs | 3.3.3 |
| mav_planning_msgs | 3.3.3 |
| mav_state_machine_msgs | 0.0.0 |
| mav_system_msgs | 0.0.0 |
| pid_controller | 0.0.0 |
| pid_controller_msgs | 0.0.0 |
| trajectory_controller | 0.0.0 |
| takeoff_landing_planner | 0.0.0 |
| trajectory_library | 0.0.0 |
| perception_bringup | 0.0.0 |
| lidar_point_cloud_filter | 0.1.0 |
| ms_airsim_ros_bridge | 0.1.0 |
| sim | 0.0.0 |
| hello_module | 0.1.0 |
README
AirStack
**Build the autonomy, not the scaffolding.**
AirStack is an open ROS 2 stack for aerial robots — simulator, ground control,
and layered onboard autonomy that launch as one system. Developed by the
[AirLab](https://theairlab.org) at Carnegie Mellon University's Robotics Institute.
[](LICENSE)
[](https://docs.theairlab.org)
*Three drones flying the real stack in Isaac Sim, the Foxglove GCS, and MS AirSim —
recorded from this repo, unstaged. Watch the live demos on the
[documentation home page](https://docs.theairlab.org).*
Zero → drones flying in sim
git clone --recursive -j8 git@github.com:castacks/AirStack.git && cd AirStack
./airstack.sh install && ./airstack.sh setup
airstack up --play --wait
Then follow the Getting Started guide and the Modular AirStack Walkthrough. No Linux box or GPU? Run AirStack on OSMO from any laptop.
One command brings up sim, robots, and ground control
airstack up starts the simulator, one container per robot, and a
Foxglove-based ground control station, wired together over ROS 2. Flags select
the simulator, scene, and fleet size — no launch-file surgery:
airstack up --sim airsim --scene neighborhood
airstack up --sim isaac --robots 3 --scene full-warehouse
airstack up --fleet sim_three_mixed
airstack ready blocks until the stack is flight-ready — containers running,
sim publishing /clock, autonomy nodes up, PX4 EKF armable — so scripts and CI
know exactly when takeoff is available.
Same code in sim and on the vehicle
The desktop dev container and the Jetson (L4T) onboard container extend one
base service and launch the same stack entry point
(stacks/full_default/launch/stack.launch.xml). What you test in simulation is
what the vehicle runs.
CI flies the whole stack, not just unit tests
Pull requests run pytest campaigns against the live simulators on ephemeral GPU
runners: image builds, colcon builds in every container, bring-up liveliness,
sensor topic rates, takeoff–hover–land, fixed trajectories with cross-track
error, and waypoint navigation judged on the odometry track. Run them yourself,
or comment /pytest on a PR:
airstack test -m takeoff_hover_land --sim isaacsim --num-robots 1 -v
Marks are defined in tests/; metrics regressions fail the report.
AI agents can drive this repo
Module boundaries, an AGENTS.md contract, and 23 step-by-step
skills under .agents/skills/ give coding agents the same
on-ramp as humans: scaffold a package, wire it into a stack, fly it in sim,
document it. Every demo video on the documentation home page was captured by an
AI agent — it brought the stack up, scripted the flights, implemented the
follow-camera it filmed with, and edited the clips.
Modular architecture
AirStack follows a layered autonomy architecture:
``` Robot ├── Interface Layer: Communication with robot controllers ├── Sensors Layer: Data acquisition from various sensors ├── Perception Layer: State estimation and environment understanding ├── Local Layer: │ ├── World Models: Local environment representation │ ├── Planners: Trajectory generation and obstacle avoidance │ └── Controls: Trajectory following ├── Global Layer: │ ├── World Models: Global environment mapping │ └── Planners: Mission-level path planning └── Behavior Layer: High-level decision making
File truncated at 100 lines see the full file
CONTRIBUTING
Repository Summary
| Description | |
| Checkout URI | https://github.com/castacks/airstack.git |
| VCS Type | git |
| VCS Version | develop |
| Last Updated | 2026-09-11 |
| Dev Status | UNKNOWN |
| Released | UNRELEASED |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Packages
| Name | Version |
|---|---|
| airstack_common | 0.0.0 |
| coordination_bringup | 0.0.0 |
| coordination_msgs | 0.0.0 |
| desktop_bringup | 0.0.0 |
| rqt_py_template | 1.0.2 |
| waypoint_rviz2_plugin | 1.0.0 |
| rviz_tasks_panel | 0.0.0 |
| bag_record_pid | 0.0.0 |
| logging_bringup | 0.0.0 |
| airstack_msgs | 1.0.0 |
| behavior_tree_msgs | 0.0.0 |
| task_msgs | 0.0.0 |
| robot_descriptions | 0.0.0 |
| action_relay | 0.0.1 |
| gcs_visualizer | 0.0.1 |
| zed_wrapper | 4.1.0 |
| autonomy_bringup | 0.0.0 |
| drone_safety_monitor | 0.0.0 |
| global_bringup | 0.0.0 |
| global_plan_navigate_bridge | 0.1.0 |
| random_walk_planner | 0.0.0 |
| interface_bringup | 0.0.0 |
| mavros_interface | 0.0.0 |
| robot_interface | 0.0.0 |
| mav_comm | 3.3.3 |
| mav_msgs | 3.3.3 |
| mav_planning_msgs | 3.3.3 |
| mav_state_machine_msgs | 0.0.0 |
| mav_system_msgs | 0.0.0 |
| pid_controller | 0.0.0 |
| pid_controller_msgs | 0.0.0 |
| trajectory_controller | 0.0.0 |
| takeoff_landing_planner | 0.0.0 |
| trajectory_library | 0.0.0 |
| perception_bringup | 0.0.0 |
| lidar_point_cloud_filter | 0.1.0 |
| ms_airsim_ros_bridge | 0.1.0 |
| sim | 0.0.0 |
| hello_module | 0.1.0 |
README
AirStack
**Build the autonomy, not the scaffolding.**
AirStack is an open ROS 2 stack for aerial robots — simulator, ground control,
and layered onboard autonomy that launch as one system. Developed by the
[AirLab](https://theairlab.org) at Carnegie Mellon University's Robotics Institute.
[](LICENSE)
[](https://docs.theairlab.org)
*Three drones flying the real stack in Isaac Sim, the Foxglove GCS, and MS AirSim —
recorded from this repo, unstaged. Watch the live demos on the
[documentation home page](https://docs.theairlab.org).*
Zero → drones flying in sim
git clone --recursive -j8 git@github.com:castacks/AirStack.git && cd AirStack
./airstack.sh install && ./airstack.sh setup
airstack up --play --wait
Then follow the Getting Started guide and the Modular AirStack Walkthrough. No Linux box or GPU? Run AirStack on OSMO from any laptop.
One command brings up sim, robots, and ground control
airstack up starts the simulator, one container per robot, and a
Foxglove-based ground control station, wired together over ROS 2. Flags select
the simulator, scene, and fleet size — no launch-file surgery:
airstack up --sim airsim --scene neighborhood
airstack up --sim isaac --robots 3 --scene full-warehouse
airstack up --fleet sim_three_mixed
airstack ready blocks until the stack is flight-ready — containers running,
sim publishing /clock, autonomy nodes up, PX4 EKF armable — so scripts and CI
know exactly when takeoff is available.
Same code in sim and on the vehicle
The desktop dev container and the Jetson (L4T) onboard container extend one
base service and launch the same stack entry point
(stacks/full_default/launch/stack.launch.xml). What you test in simulation is
what the vehicle runs.
CI flies the whole stack, not just unit tests
Pull requests run pytest campaigns against the live simulators on ephemeral GPU
runners: image builds, colcon builds in every container, bring-up liveliness,
sensor topic rates, takeoff–hover–land, fixed trajectories with cross-track
error, and waypoint navigation judged on the odometry track. Run them yourself,
or comment /pytest on a PR:
airstack test -m takeoff_hover_land --sim isaacsim --num-robots 1 -v
Marks are defined in tests/; metrics regressions fail the report.
AI agents can drive this repo
Module boundaries, an AGENTS.md contract, and 23 step-by-step
skills under .agents/skills/ give coding agents the same
on-ramp as humans: scaffold a package, wire it into a stack, fly it in sim,
document it. Every demo video on the documentation home page was captured by an
AI agent — it brought the stack up, scripted the flights, implemented the
follow-camera it filmed with, and edited the clips.
Modular architecture
AirStack follows a layered autonomy architecture:
``` Robot ├── Interface Layer: Communication with robot controllers ├── Sensors Layer: Data acquisition from various sensors ├── Perception Layer: State estimation and environment understanding ├── Local Layer: │ ├── World Models: Local environment representation │ ├── Planners: Trajectory generation and obstacle avoidance │ └── Controls: Trajectory following ├── Global Layer: │ ├── World Models: Global environment mapping │ └── Planners: Mission-level path planning └── Behavior Layer: High-level decision making
File truncated at 100 lines see the full file
CONTRIBUTING
Repository Summary
| Description | |
| Checkout URI | https://github.com/castacks/airstack.git |
| VCS Type | git |
| VCS Version | develop |
| Last Updated | 2026-09-11 |
| Dev Status | UNKNOWN |
| Released | UNRELEASED |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Packages
| Name | Version |
|---|---|
| airstack_common | 0.0.0 |
| coordination_bringup | 0.0.0 |
| coordination_msgs | 0.0.0 |
| desktop_bringup | 0.0.0 |
| rqt_py_template | 1.0.2 |
| waypoint_rviz2_plugin | 1.0.0 |
| rviz_tasks_panel | 0.0.0 |
| bag_record_pid | 0.0.0 |
| logging_bringup | 0.0.0 |
| airstack_msgs | 1.0.0 |
| behavior_tree_msgs | 0.0.0 |
| task_msgs | 0.0.0 |
| robot_descriptions | 0.0.0 |
| action_relay | 0.0.1 |
| gcs_visualizer | 0.0.1 |
| zed_wrapper | 4.1.0 |
| autonomy_bringup | 0.0.0 |
| drone_safety_monitor | 0.0.0 |
| global_bringup | 0.0.0 |
| global_plan_navigate_bridge | 0.1.0 |
| random_walk_planner | 0.0.0 |
| interface_bringup | 0.0.0 |
| mavros_interface | 0.0.0 |
| robot_interface | 0.0.0 |
| mav_comm | 3.3.3 |
| mav_msgs | 3.3.3 |
| mav_planning_msgs | 3.3.3 |
| mav_state_machine_msgs | 0.0.0 |
| mav_system_msgs | 0.0.0 |
| pid_controller | 0.0.0 |
| pid_controller_msgs | 0.0.0 |
| trajectory_controller | 0.0.0 |
| takeoff_landing_planner | 0.0.0 |
| trajectory_library | 0.0.0 |
| perception_bringup | 0.0.0 |
| lidar_point_cloud_filter | 0.1.0 |
| ms_airsim_ros_bridge | 0.1.0 |
| sim | 0.0.0 |
| hello_module | 0.1.0 |
README
AirStack
**Build the autonomy, not the scaffolding.**
AirStack is an open ROS 2 stack for aerial robots — simulator, ground control,
and layered onboard autonomy that launch as one system. Developed by the
[AirLab](https://theairlab.org) at Carnegie Mellon University's Robotics Institute.
[](LICENSE)
[](https://docs.theairlab.org)
*Three drones flying the real stack in Isaac Sim, the Foxglove GCS, and MS AirSim —
recorded from this repo, unstaged. Watch the live demos on the
[documentation home page](https://docs.theairlab.org).*
Zero → drones flying in sim
git clone --recursive -j8 git@github.com:castacks/AirStack.git && cd AirStack
./airstack.sh install && ./airstack.sh setup
airstack up --play --wait
Then follow the Getting Started guide and the Modular AirStack Walkthrough. No Linux box or GPU? Run AirStack on OSMO from any laptop.
One command brings up sim, robots, and ground control
airstack up starts the simulator, one container per robot, and a
Foxglove-based ground control station, wired together over ROS 2. Flags select
the simulator, scene, and fleet size — no launch-file surgery:
airstack up --sim airsim --scene neighborhood
airstack up --sim isaac --robots 3 --scene full-warehouse
airstack up --fleet sim_three_mixed
airstack ready blocks until the stack is flight-ready — containers running,
sim publishing /clock, autonomy nodes up, PX4 EKF armable — so scripts and CI
know exactly when takeoff is available.
Same code in sim and on the vehicle
The desktop dev container and the Jetson (L4T) onboard container extend one
base service and launch the same stack entry point
(stacks/full_default/launch/stack.launch.xml). What you test in simulation is
what the vehicle runs.
CI flies the whole stack, not just unit tests
Pull requests run pytest campaigns against the live simulators on ephemeral GPU
runners: image builds, colcon builds in every container, bring-up liveliness,
sensor topic rates, takeoff–hover–land, fixed trajectories with cross-track
error, and waypoint navigation judged on the odometry track. Run them yourself,
or comment /pytest on a PR:
airstack test -m takeoff_hover_land --sim isaacsim --num-robots 1 -v
Marks are defined in tests/; metrics regressions fail the report.
AI agents can drive this repo
Module boundaries, an AGENTS.md contract, and 23 step-by-step
skills under .agents/skills/ give coding agents the same
on-ramp as humans: scaffold a package, wire it into a stack, fly it in sim,
document it. Every demo video on the documentation home page was captured by an
AI agent — it brought the stack up, scripted the flights, implemented the
follow-camera it filmed with, and edited the clips.
Modular architecture
AirStack follows a layered autonomy architecture:
``` Robot ├── Interface Layer: Communication with robot controllers ├── Sensors Layer: Data acquisition from various sensors ├── Perception Layer: State estimation and environment understanding ├── Local Layer: │ ├── World Models: Local environment representation │ ├── Planners: Trajectory generation and obstacle avoidance │ └── Controls: Trajectory following ├── Global Layer: │ ├── World Models: Global environment mapping │ └── Planners: Mission-level path planning └── Behavior Layer: High-level decision making
File truncated at 100 lines see the full file
CONTRIBUTING
Repository Summary
| Description | |
| Checkout URI | https://github.com/castacks/airstack.git |
| VCS Type | git |
| VCS Version | develop |
| Last Updated | 2026-09-11 |
| Dev Status | UNKNOWN |
| Released | UNRELEASED |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Packages
| Name | Version |
|---|---|
| airstack_common | 0.0.0 |
| coordination_bringup | 0.0.0 |
| coordination_msgs | 0.0.0 |
| desktop_bringup | 0.0.0 |
| rqt_py_template | 1.0.2 |
| waypoint_rviz2_plugin | 1.0.0 |
| rviz_tasks_panel | 0.0.0 |
| bag_record_pid | 0.0.0 |
| logging_bringup | 0.0.0 |
| airstack_msgs | 1.0.0 |
| behavior_tree_msgs | 0.0.0 |
| task_msgs | 0.0.0 |
| robot_descriptions | 0.0.0 |
| action_relay | 0.0.1 |
| gcs_visualizer | 0.0.1 |
| zed_wrapper | 4.1.0 |
| autonomy_bringup | 0.0.0 |
| drone_safety_monitor | 0.0.0 |
| global_bringup | 0.0.0 |
| global_plan_navigate_bridge | 0.1.0 |
| random_walk_planner | 0.0.0 |
| interface_bringup | 0.0.0 |
| mavros_interface | 0.0.0 |
| robot_interface | 0.0.0 |
| mav_comm | 3.3.3 |
| mav_msgs | 3.3.3 |
| mav_planning_msgs | 3.3.3 |
| mav_state_machine_msgs | 0.0.0 |
| mav_system_msgs | 0.0.0 |
| pid_controller | 0.0.0 |
| pid_controller_msgs | 0.0.0 |
| trajectory_controller | 0.0.0 |
| takeoff_landing_planner | 0.0.0 |
| trajectory_library | 0.0.0 |
| perception_bringup | 0.0.0 |
| lidar_point_cloud_filter | 0.1.0 |
| ms_airsim_ros_bridge | 0.1.0 |
| sim | 0.0.0 |
| hello_module | 0.1.0 |
README
AirStack
**Build the autonomy, not the scaffolding.**
AirStack is an open ROS 2 stack for aerial robots — simulator, ground control,
and layered onboard autonomy that launch as one system. Developed by the
[AirLab](https://theairlab.org) at Carnegie Mellon University's Robotics Institute.
[](LICENSE)
[](https://docs.theairlab.org)
*Three drones flying the real stack in Isaac Sim, the Foxglove GCS, and MS AirSim —
recorded from this repo, unstaged. Watch the live demos on the
[documentation home page](https://docs.theairlab.org).*
Zero → drones flying in sim
git clone --recursive -j8 git@github.com:castacks/AirStack.git && cd AirStack
./airstack.sh install && ./airstack.sh setup
airstack up --play --wait
Then follow the Getting Started guide and the Modular AirStack Walkthrough. No Linux box or GPU? Run AirStack on OSMO from any laptop.
One command brings up sim, robots, and ground control
airstack up starts the simulator, one container per robot, and a
Foxglove-based ground control station, wired together over ROS 2. Flags select
the simulator, scene, and fleet size — no launch-file surgery:
airstack up --sim airsim --scene neighborhood
airstack up --sim isaac --robots 3 --scene full-warehouse
airstack up --fleet sim_three_mixed
airstack ready blocks until the stack is flight-ready — containers running,
sim publishing /clock, autonomy nodes up, PX4 EKF armable — so scripts and CI
know exactly when takeoff is available.
Same code in sim and on the vehicle
The desktop dev container and the Jetson (L4T) onboard container extend one
base service and launch the same stack entry point
(stacks/full_default/launch/stack.launch.xml). What you test in simulation is
what the vehicle runs.
CI flies the whole stack, not just unit tests
Pull requests run pytest campaigns against the live simulators on ephemeral GPU
runners: image builds, colcon builds in every container, bring-up liveliness,
sensor topic rates, takeoff–hover–land, fixed trajectories with cross-track
error, and waypoint navigation judged on the odometry track. Run them yourself,
or comment /pytest on a PR:
airstack test -m takeoff_hover_land --sim isaacsim --num-robots 1 -v
Marks are defined in tests/; metrics regressions fail the report.
AI agents can drive this repo
Module boundaries, an AGENTS.md contract, and 23 step-by-step
skills under .agents/skills/ give coding agents the same
on-ramp as humans: scaffold a package, wire it into a stack, fly it in sim,
document it. Every demo video on the documentation home page was captured by an
AI agent — it brought the stack up, scripted the flights, implemented the
follow-camera it filmed with, and edited the clips.
Modular architecture
AirStack follows a layered autonomy architecture:
``` Robot ├── Interface Layer: Communication with robot controllers ├── Sensors Layer: Data acquisition from various sensors ├── Perception Layer: State estimation and environment understanding ├── Local Layer: │ ├── World Models: Local environment representation │ ├── Planners: Trajectory generation and obstacle avoidance │ └── Controls: Trajectory following ├── Global Layer: │ ├── World Models: Global environment mapping │ └── Planners: Mission-level path planning └── Behavior Layer: High-level decision making
File truncated at 100 lines see the full file
CONTRIBUTING
Repository Summary
| Description | |
| Checkout URI | https://github.com/castacks/airstack.git |
| VCS Type | git |
| VCS Version | develop |
| Last Updated | 2026-09-11 |
| Dev Status | UNKNOWN |
| Released | UNRELEASED |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Packages
| Name | Version |
|---|---|
| airstack_common | 0.0.0 |
| coordination_bringup | 0.0.0 |
| coordination_msgs | 0.0.0 |
| desktop_bringup | 0.0.0 |
| rqt_py_template | 1.0.2 |
| waypoint_rviz2_plugin | 1.0.0 |
| rviz_tasks_panel | 0.0.0 |
| bag_record_pid | 0.0.0 |
| logging_bringup | 0.0.0 |
| airstack_msgs | 1.0.0 |
| behavior_tree_msgs | 0.0.0 |
| task_msgs | 0.0.0 |
| robot_descriptions | 0.0.0 |
| action_relay | 0.0.1 |
| gcs_visualizer | 0.0.1 |
| zed_wrapper | 4.1.0 |
| autonomy_bringup | 0.0.0 |
| drone_safety_monitor | 0.0.0 |
| global_bringup | 0.0.0 |
| global_plan_navigate_bridge | 0.1.0 |
| random_walk_planner | 0.0.0 |
| interface_bringup | 0.0.0 |
| mavros_interface | 0.0.0 |
| robot_interface | 0.0.0 |
| mav_comm | 3.3.3 |
| mav_msgs | 3.3.3 |
| mav_planning_msgs | 3.3.3 |
| mav_state_machine_msgs | 0.0.0 |
| mav_system_msgs | 0.0.0 |
| pid_controller | 0.0.0 |
| pid_controller_msgs | 0.0.0 |
| trajectory_controller | 0.0.0 |
| takeoff_landing_planner | 0.0.0 |
| trajectory_library | 0.0.0 |
| perception_bringup | 0.0.0 |
| lidar_point_cloud_filter | 0.1.0 |
| ms_airsim_ros_bridge | 0.1.0 |
| sim | 0.0.0 |
| hello_module | 0.1.0 |
README
AirStack
**Build the autonomy, not the scaffolding.**
AirStack is an open ROS 2 stack for aerial robots — simulator, ground control,
and layered onboard autonomy that launch as one system. Developed by the
[AirLab](https://theairlab.org) at Carnegie Mellon University's Robotics Institute.
[](LICENSE)
[](https://docs.theairlab.org)
*Three drones flying the real stack in Isaac Sim, the Foxglove GCS, and MS AirSim —
recorded from this repo, unstaged. Watch the live demos on the
[documentation home page](https://docs.theairlab.org).*
Zero → drones flying in sim
git clone --recursive -j8 git@github.com:castacks/AirStack.git && cd AirStack
./airstack.sh install && ./airstack.sh setup
airstack up --play --wait
Then follow the Getting Started guide and the Modular AirStack Walkthrough. No Linux box or GPU? Run AirStack on OSMO from any laptop.
One command brings up sim, robots, and ground control
airstack up starts the simulator, one container per robot, and a
Foxglove-based ground control station, wired together over ROS 2. Flags select
the simulator, scene, and fleet size — no launch-file surgery:
airstack up --sim airsim --scene neighborhood
airstack up --sim isaac --robots 3 --scene full-warehouse
airstack up --fleet sim_three_mixed
airstack ready blocks until the stack is flight-ready — containers running,
sim publishing /clock, autonomy nodes up, PX4 EKF armable — so scripts and CI
know exactly when takeoff is available.
Same code in sim and on the vehicle
The desktop dev container and the Jetson (L4T) onboard container extend one
base service and launch the same stack entry point
(stacks/full_default/launch/stack.launch.xml). What you test in simulation is
what the vehicle runs.
CI flies the whole stack, not just unit tests
Pull requests run pytest campaigns against the live simulators on ephemeral GPU
runners: image builds, colcon builds in every container, bring-up liveliness,
sensor topic rates, takeoff–hover–land, fixed trajectories with cross-track
error, and waypoint navigation judged on the odometry track. Run them yourself,
or comment /pytest on a PR:
airstack test -m takeoff_hover_land --sim isaacsim --num-robots 1 -v
Marks are defined in tests/; metrics regressions fail the report.
AI agents can drive this repo
Module boundaries, an AGENTS.md contract, and 23 step-by-step
skills under .agents/skills/ give coding agents the same
on-ramp as humans: scaffold a package, wire it into a stack, fly it in sim,
document it. Every demo video on the documentation home page was captured by an
AI agent — it brought the stack up, scripted the flights, implemented the
follow-camera it filmed with, and edited the clips.
Modular architecture
AirStack follows a layered autonomy architecture:
``` Robot ├── Interface Layer: Communication with robot controllers ├── Sensors Layer: Data acquisition from various sensors ├── Perception Layer: State estimation and environment understanding ├── Local Layer: │ ├── World Models: Local environment representation │ ├── Planners: Trajectory generation and obstacle avoidance │ └── Controls: Trajectory following ├── Global Layer: │ ├── World Models: Global environment mapping │ └── Planners: Mission-level path planning └── Behavior Layer: High-level decision making
File truncated at 100 lines see the full file
CONTRIBUTING
Repository Summary
| Description | |
| Checkout URI | https://github.com/castacks/airstack.git |
| VCS Type | git |
| VCS Version | develop |
| Last Updated | 2026-09-11 |
| Dev Status | UNKNOWN |
| Released | UNRELEASED |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Packages
| Name | Version |
|---|---|
| airstack_common | 0.0.0 |
| coordination_bringup | 0.0.0 |
| coordination_msgs | 0.0.0 |
| desktop_bringup | 0.0.0 |
| rqt_py_template | 1.0.2 |
| waypoint_rviz2_plugin | 1.0.0 |
| rviz_tasks_panel | 0.0.0 |
| bag_record_pid | 0.0.0 |
| logging_bringup | 0.0.0 |
| airstack_msgs | 1.0.0 |
| behavior_tree_msgs | 0.0.0 |
| task_msgs | 0.0.0 |
| robot_descriptions | 0.0.0 |
| action_relay | 0.0.1 |
| gcs_visualizer | 0.0.1 |
| zed_wrapper | 4.1.0 |
| autonomy_bringup | 0.0.0 |
| drone_safety_monitor | 0.0.0 |
| global_bringup | 0.0.0 |
| global_plan_navigate_bridge | 0.1.0 |
| random_walk_planner | 0.0.0 |
| interface_bringup | 0.0.0 |
| mavros_interface | 0.0.0 |
| robot_interface | 0.0.0 |
| mav_comm | 3.3.3 |
| mav_msgs | 3.3.3 |
| mav_planning_msgs | 3.3.3 |
| mav_state_machine_msgs | 0.0.0 |
| mav_system_msgs | 0.0.0 |
| pid_controller | 0.0.0 |
| pid_controller_msgs | 0.0.0 |
| trajectory_controller | 0.0.0 |
| takeoff_landing_planner | 0.0.0 |
| trajectory_library | 0.0.0 |
| perception_bringup | 0.0.0 |
| lidar_point_cloud_filter | 0.1.0 |
| ms_airsim_ros_bridge | 0.1.0 |
| sim | 0.0.0 |
| hello_module | 0.1.0 |
README
AirStack
**Build the autonomy, not the scaffolding.**
AirStack is an open ROS 2 stack for aerial robots — simulator, ground control,
and layered onboard autonomy that launch as one system. Developed by the
[AirLab](https://theairlab.org) at Carnegie Mellon University's Robotics Institute.
[](LICENSE)
[](https://docs.theairlab.org)
*Three drones flying the real stack in Isaac Sim, the Foxglove GCS, and MS AirSim —
recorded from this repo, unstaged. Watch the live demos on the
[documentation home page](https://docs.theairlab.org).*
Zero → drones flying in sim
git clone --recursive -j8 git@github.com:castacks/AirStack.git && cd AirStack
./airstack.sh install && ./airstack.sh setup
airstack up --play --wait
Then follow the Getting Started guide and the Modular AirStack Walkthrough. No Linux box or GPU? Run AirStack on OSMO from any laptop.
One command brings up sim, robots, and ground control
airstack up starts the simulator, one container per robot, and a
Foxglove-based ground control station, wired together over ROS 2. Flags select
the simulator, scene, and fleet size — no launch-file surgery:
airstack up --sim airsim --scene neighborhood
airstack up --sim isaac --robots 3 --scene full-warehouse
airstack up --fleet sim_three_mixed
airstack ready blocks until the stack is flight-ready — containers running,
sim publishing /clock, autonomy nodes up, PX4 EKF armable — so scripts and CI
know exactly when takeoff is available.
Same code in sim and on the vehicle
The desktop dev container and the Jetson (L4T) onboard container extend one
base service and launch the same stack entry point
(stacks/full_default/launch/stack.launch.xml). What you test in simulation is
what the vehicle runs.
CI flies the whole stack, not just unit tests
Pull requests run pytest campaigns against the live simulators on ephemeral GPU
runners: image builds, colcon builds in every container, bring-up liveliness,
sensor topic rates, takeoff–hover–land, fixed trajectories with cross-track
error, and waypoint navigation judged on the odometry track. Run them yourself,
or comment /pytest on a PR:
airstack test -m takeoff_hover_land --sim isaacsim --num-robots 1 -v
Marks are defined in tests/; metrics regressions fail the report.
AI agents can drive this repo
Module boundaries, an AGENTS.md contract, and 23 step-by-step
skills under .agents/skills/ give coding agents the same
on-ramp as humans: scaffold a package, wire it into a stack, fly it in sim,
document it. Every demo video on the documentation home page was captured by an
AI agent — it brought the stack up, scripted the flights, implemented the
follow-camera it filmed with, and edited the clips.
Modular architecture
AirStack follows a layered autonomy architecture:
``` Robot ├── Interface Layer: Communication with robot controllers ├── Sensors Layer: Data acquisition from various sensors ├── Perception Layer: State estimation and environment understanding ├── Local Layer: │ ├── World Models: Local environment representation │ ├── Planners: Trajectory generation and obstacle avoidance │ └── Controls: Trajectory following ├── Global Layer: │ ├── World Models: Global environment mapping │ └── Planners: Mission-level path planning └── Behavior Layer: High-level decision making
File truncated at 100 lines see the full file
CONTRIBUTING
Repository Summary
| Description | |
| Checkout URI | https://github.com/castacks/airstack.git |
| VCS Type | git |
| VCS Version | develop |
| Last Updated | 2026-09-11 |
| Dev Status | UNKNOWN |
| Released | UNRELEASED |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Packages
| Name | Version |
|---|---|
| airstack_common | 0.0.0 |
| coordination_bringup | 0.0.0 |
| coordination_msgs | 0.0.0 |
| desktop_bringup | 0.0.0 |
| rqt_py_template | 1.0.2 |
| waypoint_rviz2_plugin | 1.0.0 |
| rviz_tasks_panel | 0.0.0 |
| bag_record_pid | 0.0.0 |
| logging_bringup | 0.0.0 |
| airstack_msgs | 1.0.0 |
| behavior_tree_msgs | 0.0.0 |
| task_msgs | 0.0.0 |
| robot_descriptions | 0.0.0 |
| action_relay | 0.0.1 |
| gcs_visualizer | 0.0.1 |
| zed_wrapper | 4.1.0 |
| autonomy_bringup | 0.0.0 |
| drone_safety_monitor | 0.0.0 |
| global_bringup | 0.0.0 |
| global_plan_navigate_bridge | 0.1.0 |
| random_walk_planner | 0.0.0 |
| interface_bringup | 0.0.0 |
| mavros_interface | 0.0.0 |
| robot_interface | 0.0.0 |
| mav_comm | 3.3.3 |
| mav_msgs | 3.3.3 |
| mav_planning_msgs | 3.3.3 |
| mav_state_machine_msgs | 0.0.0 |
| mav_system_msgs | 0.0.0 |
| pid_controller | 0.0.0 |
| pid_controller_msgs | 0.0.0 |
| trajectory_controller | 0.0.0 |
| takeoff_landing_planner | 0.0.0 |
| trajectory_library | 0.0.0 |
| perception_bringup | 0.0.0 |
| lidar_point_cloud_filter | 0.1.0 |
| ms_airsim_ros_bridge | 0.1.0 |
| sim | 0.0.0 |
| hello_module | 0.1.0 |
README
AirStack
**Build the autonomy, not the scaffolding.**
AirStack is an open ROS 2 stack for aerial robots — simulator, ground control,
and layered onboard autonomy that launch as one system. Developed by the
[AirLab](https://theairlab.org) at Carnegie Mellon University's Robotics Institute.
[](LICENSE)
[](https://docs.theairlab.org)
*Three drones flying the real stack in Isaac Sim, the Foxglove GCS, and MS AirSim —
recorded from this repo, unstaged. Watch the live demos on the
[documentation home page](https://docs.theairlab.org).*
Zero → drones flying in sim
git clone --recursive -j8 git@github.com:castacks/AirStack.git && cd AirStack
./airstack.sh install && ./airstack.sh setup
airstack up --play --wait
Then follow the Getting Started guide and the Modular AirStack Walkthrough. No Linux box or GPU? Run AirStack on OSMO from any laptop.
One command brings up sim, robots, and ground control
airstack up starts the simulator, one container per robot, and a
Foxglove-based ground control station, wired together over ROS 2. Flags select
the simulator, scene, and fleet size — no launch-file surgery:
airstack up --sim airsim --scene neighborhood
airstack up --sim isaac --robots 3 --scene full-warehouse
airstack up --fleet sim_three_mixed
airstack ready blocks until the stack is flight-ready — containers running,
sim publishing /clock, autonomy nodes up, PX4 EKF armable — so scripts and CI
know exactly when takeoff is available.
Same code in sim and on the vehicle
The desktop dev container and the Jetson (L4T) onboard container extend one
base service and launch the same stack entry point
(stacks/full_default/launch/stack.launch.xml). What you test in simulation is
what the vehicle runs.
CI flies the whole stack, not just unit tests
Pull requests run pytest campaigns against the live simulators on ephemeral GPU
runners: image builds, colcon builds in every container, bring-up liveliness,
sensor topic rates, takeoff–hover–land, fixed trajectories with cross-track
error, and waypoint navigation judged on the odometry track. Run them yourself,
or comment /pytest on a PR:
airstack test -m takeoff_hover_land --sim isaacsim --num-robots 1 -v
Marks are defined in tests/; metrics regressions fail the report.
AI agents can drive this repo
Module boundaries, an AGENTS.md contract, and 23 step-by-step
skills under .agents/skills/ give coding agents the same
on-ramp as humans: scaffold a package, wire it into a stack, fly it in sim,
document it. Every demo video on the documentation home page was captured by an
AI agent — it brought the stack up, scripted the flights, implemented the
follow-camera it filmed with, and edited the clips.
Modular architecture
AirStack follows a layered autonomy architecture:
``` Robot ├── Interface Layer: Communication with robot controllers ├── Sensors Layer: Data acquisition from various sensors ├── Perception Layer: State estimation and environment understanding ├── Local Layer: │ ├── World Models: Local environment representation │ ├── Planners: Trajectory generation and obstacle avoidance │ └── Controls: Trajectory following ├── Global Layer: │ ├── World Models: Global environment mapping │ └── Planners: Mission-level path planning └── Behavior Layer: High-level decision making
File truncated at 100 lines see the full file