96 lines
7.0 KiB
Markdown
96 lines
7.0 KiB
Markdown
# 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`, and
|
|
`MaximumForwardSpeedMetersPerSecond=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`, and `requiredDistanceHorizon`.
|
|
- Published trajectory summaries now report `longitudinalMode`, `terminalSpeed`, and `terminalAcceleration`.
|
|
- Failure summaries preserve every upstream value and explicitly mark any missing longitudinal context as `unavailable`;
|
|
the required fields are `longitudinalMode`, `remainingToBoundary`, `minimumStoppingDistance`,
|
|
`minimumStoppingDuration`, and `maximumStoppedReachableDistance`.
|
|
- 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
|
|
|
|
- `DistanceHorizonMeters` remains the L-S reference window; `TimeHorizonSeconds` remains one S-T output duration.
|
|
- Only real Goal/GearSwitch boundaries use exact zero-speed terminals and an in-QP stationary S/U/A tail.
|
|
- `RollingContinuation` and `ApproachStopBoundary` may publish nonzero terminal speed and do not gain a synthetic hold.
|
|
- `ZeroSpeedHoldSeconds` remains 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.
|