RAVEN semantic planner + geometric exploration planner as modules (full_raven, full_exploration stacks) - #426
Merged
Conversation
…bal_plan→NavigateTask bridge Two global planners now ship as external modules with pinned reference stacks: - stacks/full_exploration — asm_exploration_planner (frontier-based geometric exploration planner from the construction-site project). The trunk package robot/ros_ws/src/global/planners/exploration moves to that module repo with its history (git filter-repo) plus the bounded-exploration additions from junbin/planning_demo; removed here so the same colcon package never exists in trunk and the module overlay at once. - stacks/full_raven — asm_raven (RAVEN, ICRA 2026): the RayFronts semantic ray-frontier mapper + behavior manager run as a GPU sidecar container declared by the module's compose fragment; raven_bridge relays plans/prompts on the robot side. Trunk support these needed: - robot/ros_ws/src/global/global_plan_navigate_bridge: turns each new Path on global_plan into a NavigateTask goal (cancel-then-resend, identical re-publications deduped) so topic-publishing planners can drive the task-executor local planner droan_gl. Hermetic unit tests registered in tests/colcon_unit_test_packages.yaml. - tools/module_overlay.py: compose fragments may now declare sidecar services with build: sections — build.context / build.dockerfile / env_file relative paths are absolutized like bind sources (+ contract tests). - Isaac follow camera: ISAAC_SIM_FOLLOW_CAM_TOPIC / ISAAC_SIM_FOLLOW_CAM_RES publish the chase camera as a sensor_msgs/Image topic for headless video capture (scene_prep.add_camera_image_publisher). - Docs: stack tables, autonomy modes, global planning page, environment variables, modules.md (sidecars), docs/modules catalog regenerated from the fixture index (raven, exploration_planner, full_raven, full_exploration), mkdocs nav, release notes. VERSION 0.21.0-dev.8 -> 0.21.0-dev.9. Module repos: castacks/asm_raven, castacks/asm_exploration_planner (v0.1.0 pins are placeholders until tagged). Registry: airstack-modules-index PR #2. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
…ith build:) in modules.md and the create-module skill Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
example_one_px4_pegasus_launch_script.py hardcoded the spawn at the world origin; only the multi-drone script read ISAAC_SIM_SPAWN_XY. Several imported stages (construction-site, retro-neighborhood) are enclosed at the origin, so --scene runs with one robot could not move the drone off it. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Both new stacks now take their local layer from full_mighty (asm_mighty v0.1.1 pinned alongside the planner module): MIGHTY's bridge follows the published global_plan directly, so the Path->NavigateTask adapter is not needed there (global_plan_navigate_bridge stays in trunk for droan_gl-based stacks), and MIGHTY plans on the Ouster LiDAR, which keeps navigation working in unlit imported stages where the stereo disparity droan_gl consumes is unavailable. Docs tables, release notes, registry fixture entries and the generated catalog updated; both READMEs flag asm_mighty's known fixed-yaw-at-goal bug (fix being upstreamed separately). Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
…yaw fix upstreamed) Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
…in full_exploration/full_raven Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
…wer gate for 3 m takeoffs mighty_bridge engages its global_plan follower only after climbing follow_min_climb_m (module default 8 m); TakeoffTask climbs to ~3 m, so the published plans were adopted but never flown. A scoped set_parameter around the MIGHTY include lowers follow_min_climb_m / follow_airborne_above_m to 1.5 m without editing the module. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
…); rebase full_exploration/full_raven on full_default full_mighty was folded into full_default on develop, so both new stacks now derive from full_default (one global-planner include swap), pin asm_mighty v0.1.4 like trunk, and pin the planner modules at v0.1.1 (docs-only re-tag aligning their READMEs/test stacks with the MIGHTY-default trunk). Bridge package docs point at asm_droan for the DROAN task-executor case. Catalog regenerated; VERSION 0.21.0-dev.13. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Contributor
Test Metrics —
|
| Test | Pass | Fail | Skip | Rate |
|---|---|---|---|---|
| test_colcon_build_gcs | 0 | 1 | 0 | 0% |
| test_colcon_build_ms_airsim | 0 | 1 | 0 | 0% |
| test_colcon_build_robot | 0 | 1 | 0 | 0% |
| test_colcon_test_robot | 0 | 1 | 0 | 0% |
Metrics
| Test | Metric | Value |
|---|---|---|
| test_colcon_build_robot | duration_s | 0.75s |
| test_colcon_test_robot | duration_s | 0.565s |
| test_colcon_build_gcs | duration_s | 0.575s |
| test_colcon_build_ms_airsim | duration_s | 0.577s |
…lower-gate override asm_mighty v0.1.5 arms the global_plan follower off takeoff_landing_planner/is_airborne and clears its route memory on landing, so the scoped set_parameter workaround in full_exploration / full_raven is no longer needed; both stacks pin v0.1.5 like full_default. VERSION 0.21.0-dev.14. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
andrewjong
marked this pull request as ready for review
September 11, 2026 05:37
Contributor
Test Metrics —
|
| Test | Pass | Fail | Skip | Rate |
|---|---|---|---|---|
| test_colcon_build_gcs | 1 | 0 | 0 | 100% |
| test_colcon_build_ms_airsim | 1 | 0 | 0 | 100% |
| test_colcon_build_robot | 1 | 0 | 0 | 100% |
| test_colcon_test_robot | 1 | 0 | 0 | 100% |
Metrics
| Test | Metric | Value |
|---|---|---|
| test_colcon_build_robot | duration_s | 147.9s |
| test_colcon_test_robot | duration_s | 38.74s |
| test_colcon_build_gcs | duration_s | 63.81s |
| test_colcon_build_ms_airsim | duration_s | 13.77s |
andrewjong
added a commit
that referenced
this pull request
Sep 11, 2026
Follow-up to #426: the overlay absolutizes a fragment's build.context / build.dockerfile / env_file paths, so a module may declare a whole sidecar service (the raven module's RayFronts container is the first). The paragraph was written alongside #426 but did not land on its branch. Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Two global planners now ship as external AirStack modules with pinned reference stacks, supporting the paper's "planners plug in as modules" claim:
ravenstacks/full_ravenraven_bridgerelays plans/prompts on the robot side. Operator sets a natural-language target onraven/set_prompt.exploration_plannerstacks/full_explorationjunbin/planning_demo, then hardened for live Isaac flights (no empty-plan stops, start relaxation + escape mode, TF fallback, progress-based stall, altitude band).Both stacks are
full_default(MIGHTY, as of develop 0.21.0-dev.11) with one include swapped (random walk → the module); MIGHTY'smighty_bridgefollows the publishedglobal_plandirectly.robot/ros_ws/src/global/planners/explorationis removed from trunk (same package must never exist in trunk and a module at once).Trunk changes
global_plan_navigate_bridge(new package): Path-on-topic →NavigateTaskadapter (cancel-then-resend, dedupes re-publications) so topic-publishing global planners can drive the task-executordroan_gl. Not used by the two MIGHTY-based stacks; kept for DROAN-based stacks (asm_droan,full_droan*). Hermetic unit tests registered.build:—build.context/build.dockerfile/env_filerelative paths are absolutized (+ contract tests). Documented indocs/development/modules.mdand thecreate-moduleskill.ISAAC_SIM_FOLLOW_CAM_TOPIC/_RESpublish the follow camera as asensor_msgs/Imagetopic;example_one_px4_pegasus_launch_script.pynow honorsISAAC_SIM_SPAWN_XY(the imported Nucleus stages are enclosed at the origin).full_exploration,full_raven(asm_mighty v0.1.5 + the planner module at v0.1.1 pinned). Docs tables, autonomy modes page, global planning page, environment variables, release notes;docs/modulescatalog regenerated from the fixture index (registry PR: Register raven + exploration_planner modules and full_raven / full_exploration stacks airstack-modules-index#2).full_mightyno longer exists, so the new stacks derive fromfull_default).Validation (Isaac Sim 5.1, this host)
full_exploration, construction-site stage, spawn (24, 0), 7-minute autonomous exploration: 15 plans published, 7 plan ends reached, ~49 m flown inside the 1.5–6 m band, no empty-plan stops; RViz recording + rosbag captured (module README media).full_raven, retro-neighborhood stage, spawn (76, −20), prompt "red car": sidecar maps at ~2 frames/s wall, behavior manager runs, plans relayed and followed by MIGHTY. In the 7-minute flight with the frontier ceiling in place the vehicle flew 292 m through the neighborhood (371 plans relayed); in the earlier attempt it descended onto the driveway next to the prompted red car (follow-cam footage in the module README). RAVEN reported frontier-based mode throughout (no semantic cue fired at these settings). Two integration fixes came out of it: RAVEN's frontier search needs an altitude ceiling (patch 0003 in asm_raven, plus a relay clamp), and MIGHTY's follower needed to arm offis_airborneand clear its route memory on landing (fixed upstream in asm_mighty v0.1.5, which the stacks pin).mkdocs build --strictclean.Known gaps / follow-ups
livelinessis unaffected. Tracked in the modules' READMEs.module-system-tests.yml@develop) can only go green after this PR merges (duplicate-package rule forexploration_planner); the sidecar image is not built by the reusable workflow yet.wiring.mdfor both stacks is bootstrap-deferred to the first wiring-snapshot run.asm_raven/asm_exploration_plannerare private until the paper work concludes; module pins arev0.1.1(v0.1.0 + docs aligned with the MIGHTY-default trunk).🤖 Generated with Claude Code