Add fuselage surface sweep Objectives (3-pass working + single-path raster)

[rlpratt12]

Motivation

Tutorial 4 is dropping the flat-rectangle GenerateCoveragePath examples (see PickNikRobotics/moveit_pro#19330). This PR adds the replacement: real point-cloud-driven coverage of the airplane fuselage, built up from the working Plan Path Along Surface Objective.

Brief description

Two Objectives in src/hangar_sim/objectives/:

• plan_path_along_surface_3_passes.xml — the working multi-pass sweep. Reuses the proven Plan Path Along Surface flow (crop a thin slab → centroid → GetContourFromPointCloudSlice → PlanCartesianPath → ValidateTrajectory → ExecuteTrajectory) at three stacked heights (z = 1.7, 1.55, 1.4, top-down to stay reachable). All three contour markers are shown up front, then each pass is planned, validated, and executed in turn — each pass chaining from the previous contour's endpoint (a pseudo-raster; no return to Look at Plane between passes). tip_offset holds the tool at a fixed standoff from the surface: 0.2 m on passes 1–2, and 0.3 m on pass 3 where the coarse fuselage collision mesh needs a little more clearance (see follow-up comment below). Verified: ran SUCCEEDED end-to-end on hangar_sim with all three ValidateTrajectory checks enabled.
• raster_path_along_fuselage.xml — single stitched-path raster (reference, not runnable). Stitches the three contours into one boustrophedon path and plans it with a single PlanCartesianPath. Kept as a documented reference and marked runnable="false" because the single plan can hang on hangar_sim (see header comment for tuning options).

How it was tested

Run live on a hangar_sim dev backend (agent_robot.app), driven via ros2 action send_goal /do_objective:

• Plan Path Along Surface (baseline): SUCCEEDED from a clean robot state.
• Plan Path Along Surface 3 Passes: SUCCEEDED end-to-end — all three contours planned and executed, each pass chaining from the previous endpoint, with every ValidateTrajectory passing.
• Raster Path Along Fuselage (single stitched path): perception + stitching produce the path, but the single PlanCartesianPath does not return in reasonable time (>8 min, vs ~2 s for one contour). Root cause: the whole-body manipulator group's base redundancy plus orientation discontinuities at the contour seams. Header comment lists tuning options (arm-only group, coarser path, larger blending radius, per-row execute).

Required Git LFS assets had to be pulled for hangar_sim to launch (the wrist cloud and ros2_control IMU interfaces depend on the MuJoCo meshes).

Alternatives considered

• Single monolithic PlanCartesianPath over all three stacked contours — does not return in reasonable time in this sim (see above). Kept as a documented, non-runnable reference rather than the primary path.
• Freespace Move to Pose resets between passes — an earlier version moved toward an approach pose between passes. Once the tool orientation and standoff were corrected, the plain per-pass Cartesian chain plans the short inter-pass move fine, so the resets were removed.
• FindSlicePlanesAlongEdge/AddOverageToPath raster (original approach) — generated paths fine but the wide whole-body Cartesian plan hit wrist-joint limits / did not converge; the centroid-slab contour approach is far more reliable on hangar_sim.

Release notes

New Behavior/Library: New Plan Path Along Surface 3 Passes Objective in hangar_sim that sweeps three stacked contour passes along the airplane fuselage.

[rlpratt12]

Follow-up (non-blocking): coarse fuselage collision mesh causes phantom collisions.

Pass 3 of Plan Path Along Surface 3 Passes uses a larger tool standoff (tip_offset z = 0.3 vs 0.2 on passes 1–2) purely to work around a sim-asset issue, not a path-planning one.

The fuselage's MoveIt collision mesh collision_Plane_009.obj is a coarse 20-vertex, roughly flat-wall hull that bulges outside the detailed visual skin (the high-poly tire_lndg_rear_l_in.* meshes the wrist point cloud is built from). So ValidateTrajectory reports collisions where the gripper is actually clear of the real surface — most visibly up high on pass 3, where the real fuselage curves back but the collision wall does not.

The standoff bump is fine for this tutorial Objective, but a finer / convex-decomposed fuselage collision mesh in hangar_sim would remove the phantom collisions and let all three passes share one standoff. Leaving this here as a tracked follow-up.

[Copilot]

Pull request overview

Adds fuselage surface coverage Objectives for hangar_sim, replacing flat rectangle coverage examples with point-cloud-driven contour sweeps based on the existing surface path planning flow.

Changes:

• Adds a favorite 3-pass fuselage sweep Objective that generates three point-cloud contours, plans, validates, and executes each pass.
• Adds a non-favorite single stitched raster Objective as a documented tuning/reference example.
• Reuses existing hangar_sim Objective discovery, waypoint, perception, and Cartesian planning behaviors.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 4 comments.

File	Description
src/hangar_sim/objectives/plan_path_along_surface_3_passes.xml	Adds the working multi-pass fuselage contour sweep Objective.
src/hangar_sim/objectives/raster_path_along_fuselage.xml	Adds a documented single-path raster reference Objective with known planning limitations.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[marioprats]

LGTM, but Dave may want to take a look

[davetcoleman]

Thanks!