Skip to content

full_default — trunk reference stack

The full-autonomy topology, as a self-contained stack folder. This is the stack most users start from, the default when no stack is selected, and the baseline other stacks are copied from.

What it launches

The entry point launch/stack.launch.xml composes every layer as a flat set of module-launch includes: LiDAR near-range filter, stereo disparity/point-cloud pair, topic keepalive, takeoff/land task server, fixed-trajectory task server, the MIGHTY local planner (planner + acl-mapping voxel world model fed by the filtered Ouster cloud + NavigateTask bridge, from the asm_mighty module), trajectory controller, PID controller, VDB mapping, random-walk global planner, and the drone safety monitor — each module launch file declares its topic endpoints as args with canonical defaults, so bare includes mean canonical wiring. Two cross-domain extras run alongside: the DDS-router domain bridge to the GCS and the gossip coordination layer. Two blocks stay wrapped by design: interface.launch.py (the safety boundary) and logging.launch.xml (already a single self-contained module).

The local planner

MIGHTY (MIT ACL, RA-L 2026) is a map-based planner: a sliding voxel map with explicit unknown-space handling, convex safe corridors with a tunable clearance margin, and a Hermite-spline trajectory optimiser, CPU-only. It serves the same seam every AirStack local planner does — the tasks/navigate NavigateTask action in, trajectory_controller/* trajectories out — so the trajectory controller, PID, safety monitor, takeoff/landing and GCS are planner-agnostic. Planner and world-model tuning lives in the module (mighty_bridge/config/*_airstack.yaml); the launch args it exposes (lidar and odometry inputs, the mapper→planner grid seam, the altitude band) are listed in the module README.

The DROAN reactive planner is the alternative, one include line away: full_droan (GPU) and full_droan_cpu (CPU) pin the asm_droan module. Pick DROAN for depth-camera-only vehicles or minimal compute; pick MIGHTY (this stack) where clutter is dense and clearance margins matter — the judged comparison is in the asm_mighty README.

Baseline

This stack is the default: with no stack selected, robot.launch.xml launches it. Its committed wiring.md is the observed-graph baseline other full stacks are compared against; it is generated by the wiring snapshot test, never hand-edited:

airstack test -m wiring --stack full_default --sim isaacsim --num-robots 1

How to run

airstack up --stack full_default --sim isaac --robots 1
airstack ready

airstack up adds the asm_mighty pin from this stack's modules.repos to the checkout and syncs it when it is missing (airstack module list shows it). The module declares no image-level dependencies — its nlohmann-json header dep ships in the trunk robot image — so no module layer is composed and containers run the trunk images as-is.

The shared per-robot preamble (ROBOT_NAME namespace, use_sim_time, robot_state_publisher, world→map static TF) runs in autonomy_bringup/launch/robot.launch.xml, which dispatches to this stack when AIRSTACK_STACK_DIR is set.

Known limits

  • The interface layer is a wrapped include (interface.launch.py) — its MAVROS wiring is not visible in stack.launch.xml; read wiring.md for the observed graph.
  • MIGHTY needs a 3D lidar cloud (sensors/ouster/point_cloud by default); depth-camera-only vehicles use full_droan / full_droan_cpu.
  • docker-compose.yaml is a stub: the pinned module has no dependency layer, so trunk compose profiles provide all services.

wiring.md

This stack's observed wiring diagram is committed at wiring.md; CI drift-checks the running graph against it. Regenerate via airstack test -m wiring --stack full_default. The previous default topology's baseline is full_droan/wiring.md — the two differ only in the local-planner nodes (mighty/* vs droan/disparity_expander_node).