feat(stacks): full_mighty reference stack + mighty module marketplace entry

[andrewjong]

Motivation

The DROAN GPU local planner (droan_gl) hit an architectural ceiling on judged obstacle-route evaluation: its 2018-era reactive design has no persistent map (accumulated collision votes make cluttered pockets absorbing hover states) and its ~86° forward stereo FOV + voxel quantization produce close-quarters near-contacts. This PR upstreams the replacement integration developed on the paper branch: MIGHTY (MIT ACL, RA-L 2026, arXiv:2511.10822) — a map-based Hermite-spline planner with its acl-mapping voxel world model — packaged as the external asm_mighty module and consumed by a new reference stack. The integration doubled as the requested stress test of the RFC #379 module workflow (module add/sync/lock --build all held up with zero manual bypasses).

What's in the PR

• stacks/full_mighty/ — full_default with exactly one wiring difference: the droan_gl include is replaced by the module's mighty_module.launch.xml include (planner + global_mapper_ros voxel mapper + mighty_bridge, which serves the same tasks/navigate action and publishes to the same trajectory_controller seam — controller/PID/safety-monitor/takeoff-landing untouched). modules.repos pins asm_mighty v0.1.1. This is the module-swap demonstration for the modular architecture: swap one include, pin one module. wiring.md follows the bootstrap rule (generated by the first validated wiring-snapshot run).
• Marketplace catalog — mighty module + full_mighty stack registered: fixture index entries, regenerated docs/modules/ pages (gen_docs_catalog.py), mkdocs nav, and the reference-stack enumerations in docs/development/stacks.md, docs/robot/autonomy_modes.md, adding_a_controller.md, adding_a_world_model_and_planner.md (full_mighty is now the worked example for a module-shipped planner swap). Registry PR with the live entries: Register mighty (asm_mighty v0.1.1) + full_mighty stack airstack-modules-index#1 — merge that first so docs deploys regenerate against a registry that has the entries.
• VERSION 0.20.0-alpha.16 → 0.20.0-alpha.17 + release-notes entry.

Validation (at the pinned module version, Isaac Sim)

Check	Result
Module workflow (module add → sync → lock --build → bws, fresh clone from the GitHub pin)	clean, zero manual bypasses
Vendored upstream gtests (colcon test --packages-select mighty)	44/44 (6 suites, incl. L-BFGS gradient check)
Synthetic smoke (no sim): cloud+odom in → TrajectoryXYZVYaw stream out	~10 Hz replan, no solver errors over the session
Empty-world Isaac flight: takeoff → 3-waypoint NavigateTask route → land	in-order, goal error 0.14 m, clean land, no controller mode fights
Pillar-field avoidance flights (both command paths: NavigateTask + global_plan follower)	7/7 clean traversals, zero collisions, min clearances ≥ 1.06 m
Judged obstacle-route evaluation (ground-truth scoring, 1.0 m clearance gate, fresh routes per flight)	5/5 passes + validation flight, goal errors 0.01–0.15 m, min clearances 1.59–1.65 m

The motivating DROAN-vs-MIGHTY comparison (quantitative table + same-field flown-track and clearance-profile figures) is in the asm_mighty README.

tests/meta contract suite passes locally (docs-catalog drift check, stack-anatomy, single-locus launch lint); mkdocs build --strict clean.

Notes

• asm_mighty is private until the AirStack agent study concludes, then flips public (noted in the stack README, modules.repos comment, registry entry, and release notes). Until the flip, syncing full_mighty needs castacks-member credentials; the docs deploy's per-clone failure isolation handles the unfetchable repo.
• full_default keeps droan_gl — flipping the trunk default planner is a separate decision.
• v0.1.1 is code-identical to the validated v0.1.0 (README-only delta).

🤖 Generated with Claude Code

[github-actions]

Test Metrics — e79be503ba8f53d304541df5686b1af45992a7b1

No metrics report generated.