7.0 KiB
EM Longitudinal Rolling Planning — Final Acceptance Handoff
Scope and commits
- Phase 4 start baseline:
6cfbaf6(feat: reuse prior trajectory in longitudinal planning) - Task 8:
eb050b1(test: cover rolling-to-stop EM planning flow) - Task 9:
302798b(docs: explain rolling longitudinal planning diagnostics) - Phase 4 code/documentation end:
302798b
Only original-plan Tasks 8, 9, and 10 were executed. No fifth phase is defined or created.
Delivered behavior
Task 8 — service-level rolling-to-stop regressions
- Added service coverage for
RollingContinuation -> ApproachStopBoundary -> ExactStopAtBoundary. - The rolling case uses
DistanceHorizonMeters=5m,TimeHorizonSeconds=2s,OutputTimeStepSeconds=0.1s, andMaximumForwardSpeedMetersPerSecond=0.2m/s; it publishes 21 points, stops short of 5m, and retains nonzero terminal speed. - Goal and
CreateGearPairReferencePath()exact-stop cases verify the true boundary anchor, following QP stationary point, zero speed, and the absence of points from the next direction segment. - The parameterized gear-pair fixture retains its existing 2m default and supports a short first segment for exact-stop service tests.
- The existing rolling integration regression now explicitly proves the 21-knot / 5m-LS / 2s-ST semantics.
Task 9 — observation diagnostics and documentation
- The one-time configuration diagnostic reports the worst forward/reverse jerk-limited stopping capability:
maximumJerkLimitedStopDistance,maximumJerkLimitedStopDuration, andrequiredDistanceHorizon. - Published trajectory summaries now report
longitudinalMode,terminalSpeed, andterminalAcceleration. - Failure summaries preserve every upstream value and explicitly mark any missing longitudinal context as
unavailable; the required fields arelongitudinalMode,remainingToBoundary,minimumStoppingDistance,minimumStoppingDuration, andmaximumStoppedReachableDistance. - EMPlanner and MovementTest documentation now distinguish the L-S distance window from the S-T duration and state that
rolling observation remains
OBSERVE_ONLY.
TDD and debugging record
Task 8 began with new service assertions and an em-core-all red run. The first failure was an undersized ±3m fixture
map for a 10m rolling path. Subsequent red runs established that a scripted solver warm start is not a validated exact
stop solution. The final fixture uses the pre-existing, discretely feasible exact-stop service scenario while the
separate 5m/2s case covers rolling semantics. No acceleration, jerk, solver residual, or publication-validation limit
was changed.
Task 9 began with new required-field assertions. trajectory-observation failed because the configuration diagnostic
did not report jerk-limited stopping capability; the minimal implementation then made that test pass.
Verification evidence
All commands below were run from the repository root.
| Command | Exit | Key output |
|---|---|---|
dotnet run --project ClumsyPilot/tests/EMPlannerVerificationHost/EMPlannerVerificationHost.csproj -- em-core-all (Task 8 red) |
1 | New fixture exposed map-boundary and unvalidated exact-stop warm-start failures. |
dotnet run --project ClumsyPilot/tests/EMPlannerVerificationHost/EMPlannerVerificationHost.csproj -- longitudinal-integration |
0 | PASS longitudinal-integration after reverting an unsuccessful seed experiment. |
dotnet run --project ClumsyPilot/tests/EMPlannerVerificationHost/EMPlannerVerificationHost.csproj -- em-core-all (Task 8 green) |
0 | PASS longitudinal-model, PASS longitudinal-integration, PASS trajectory, PASS em-planning-service. |
dotnet run --project ClumsyPilot/tests/EMPlannerVerificationHost/EMPlannerVerificationHost.csproj -- trajectory-observation (Task 9 red) |
1 | Missing maximumJerkLimitedStopDistance= assertion. |
dotnet run --project ClumsyPilot/tests/EMPlannerVerificationHost/EMPlannerVerificationHost.csproj -- trajectory-observation (Task 9 green) |
0 | PASS trajectory-observation. |
dotnet run --project ClumsyPilot/tests/EMPlannerVerificationHost/EMPlannerVerificationHost.csproj -- em-core-all |
0 | All four core PASS lines. |
dotnet run --project ClumsyPilot/tests/EMPlannerVerificationHost/EMPlannerVerificationHost.csproj -- coordinator |
0 | PASS coordinator. |
dotnet run --project ClumsyPilot/tests/EMPlannerVerificationHost/EMPlannerVerificationHost.csproj -- executor |
0 | PASS executor. |
dotnet run --project ClumsyPilot/tests/EMPlannerVerificationHost/EMPlannerVerificationHost.csproj -- trajectory-observation |
0 | PASS trajectory-observation. |
dotnet build ClumsyPilot/ClumsyPilot.csproj -p:ExcludeLegacyAutoAvoidance=true |
0 | Build succeeded with 0 warnings and 0 errors. |
dotnet run --project ClumsyPilot/tests/EMPlannerVerificationHost/EMPlannerVerificationHost.csproj -- longitudinal-real-osqp-probe |
0 | PASS longitudinal-real-osqp. |
git diff --check |
0 | No whitespace errors; only CRLF notices from unrelated user edits. |
git status --short / git log --oneline -12 |
0 | Task commits are present; unrelated user work remains unstaged. |
The automated C# runs emitted the pre-existing obsolete-API warnings in MovementTests.TireFollowing.cs and
TireFollowing.cs; the Task 10 build with ExcludeLegacyAutoAvoidance=true itself reported 0 warnings.
OSQP and observation-only target verification
The real OSQP probe succeeded on this Windows workspace host, so the native DLL was loadable for the probe. The manual
TrajectoryObservationMovementTest observation-only run remains pending on the deployed vehicle/MDCS host: it is a
vehicle-UI MovementTest that requires live localization and chassis-speed read interfaces and has no standalone
non-interactive launcher in this workspace. It must confirm the startup configuration prints once, the
RollingContinuation -> ApproachStopBoundary -> ExactStopAtBoundary progression, no point-21
JerkLimitExceeded, and continuing OBSERVE_ONLY: no chassis command is sent. output.
Preserved user worktree and safety constraints
The branch remains trajplanner. Unrelated modified, deleted, and untracked user work in PathSmoothing, CoarsePath,
Map, reports, configuration, MovementTest, and planning/spec documents remains untouched and unstaged. No reset,
checkout, clean, stash, broad git add, or worktree cleanup was used.
No chassis command, trajectory follower, or watchdog was added. OBSERVE_ONLY remains unchanged.
Retained invariants
DistanceHorizonMetersremains the L-S reference window;TimeHorizonSecondsremains one S-T output duration.- Only real Goal/GearSwitch boundaries use exact zero-speed terminals and an in-QP stationary S/U/A tail.
RollingContinuationandApproachStopBoundarymay publish nonzero terminal speed and do not gain a synthetic hold.ZeroSpeedHoldSecondsremains outside the QP horizon.- Previous-trajectory PathS/speed arrays remain objective soft references, never terminal hard constraints.
- No jerk, acceleration, solver, or publication-validation threshold was relaxed.