Feat(planner): add optional Bézier trajectory head as swappable planner

[gcordova10]

Description

This PR introduces an optional, swappable Bézier trajectory planner head into the AutoE2E architecture, aligning with the WG's requirements for trajectory smoothing and jerk reduction.

Key Changes

• Implemented BezierPlanner under Model/model_components/trajectory_planning/ using a precomputed Bernstein basis (zero scipy dependency).
• Integrated PLANNER_REGISTRY to support modular, swappable planners.
• Maintained full backward compatibility with the existing AutoE2E contract (trajectory, ego_hidden, future_visual_features).
• Follows unicycle dynamics (acceleration, curvature) as per the project's contract.
• Verified with 15+ unit/integration tests ensuring gradient flow and output integrity.

Testing

• Verified numerical stability of Bernstein expansion against analytical reference.
• CI passed successfully (lint + unit tests).

Closes #45 (Relates to #51)

WG Alignment Note: This implementation aligns with the "fast/reactive" planning layer discussed in the WG meeting. It serves as one of the metric trajectory planner heads identified as a
requirement for the current reactive block, ensuring compatibility with the broader architectural goal of separating reactive trajectory planning from future "slow-thinking" reasoning modules.

[m-zain-khawaja]

Hi @gcordova10 - this looks good to me. I noticed that you added a compute_planner_loss function. We already have a losses folder with a trajectory loss - could you please therefore remove the planner loss from your bezier_planner.py and if you need to add further losses, could you please add them under the losses folder.

Also, have you tried a forward pass test with your planner, do the layers work correctly?

[gcordova10]

Hi @zainkhawaja!
I have force-pushed to update this branch. The Bezier Planner is now fully refactored to comply with the new BasePlanner interface (separating forward for inference and compute_planner_loss for training), and I've integrated it cleanly via the Planner Registry.
Note on the CI: The make typecheck (mypy) step might fail on this branch due to the pre-existing typing issue in map.py I kept my branch strictly focused on the Bezier planner and didn't include a fix here.
The PR is ready for review!

[m-zain-khawaja]

Approved, thanks @gcordova10

[gcordova10]

@ryotayamada @m-zain-khawaja — as suggested in #56, I put together a small planner benchmark harness that runs gru, flow_matching and bezier through the PLANNER_REGISTRY under identical conditions (same embed_dim/horizon/inputs/device).

What it measures now (no checkpoint/dataset/sim needed): inference latency, parameter count, and architectural smoothness on the (accel, curvature) output — jerk = Var(Δaccel), curvature = Var(Δcurvature).

Results (GPU, batch=1, random weights — see caveat):

planner	params	latency p50 (ms)	jerk Var(Δaccel)	curv Var(Δcurv)
gru (autoregressive)	829K	43.3	1.4e-04	3.8e-04
flow_matching (ODE)	988K	11.3	4.2e+00	2.0e+00
bezier (one-shot)	495K	0.39	5.0e-06	1.2e-06

So Bézier is ~28× faster than flow-matching and ~110× faster than GRU, the lightest, and the smoothest by construction (Bernstein basis) — relevant for the real-time R-Car target.

Honest caveat: these are untrained weights, so the smoothness/latency numbers are architectural; ADE/FDE, off-road rate, collision and closed-loop stability are NOT comparable yet — they need a trained checkpoint + dataset (KITScenes/L2D) + a simulator (NAVSIM/Bench2Drive). The harness has hooks for those.

@m-zain-khawaja — since you're leading this comparison, happy to fold the harness into this PR or move it to a separate one, whatever you prefer. I can also help wire the trained ADE/FDE + closed-loop metrics once the training loop (#78/#67) is in place.

[zainkhawaja]

Stop Sent from my iPhoneOn Jun 22, 2026, at 3:48 PM, Gabriela Cordova ***@***.***> wrote:gcordova10 left a comment (autowarefoundation/auto_e2e#69) @ryotayamada @m-zain-khawaja — as suggested in #56, I put together a small planner benchmark harness that runs gru, flow_matching and bezier through the PLANNER_REGISTRY under identical conditions (same embed_dim/horizon/inputs/device). What it measures now (no checkpoint/dataset/sim needed): inference latency, parameter count, and architectural smoothness on the (accel, curvature) output — jerk = Var(Δaccel), curvature = Var(Δcurvature). Results (GPU, batch=1, random weights — see caveat): planner params latency p50 (ms) jerk Var(Δaccel) curv Var(Δcurv) gru (autoregressive) 829K 43.3 1.4e-04 3.8e-04 flow_matching (ODE) 988K 11.3 4.2e+00 2.0e+00 bezier (one-shot) 495K 0.39 5.0e-06 1.2e-06 So Bézier is ~28× faster than flow-matching and ~110× faster than GRU, the lightest, and the smoothest by construction (Bernstein basis) — relevant for the real-time R-Car target. Honest caveat: these are untrained weights, so the smoothness/latency numbers are architectural; ADE/FDE, off-road rate, collision and closed-loop stability are NOT comparable yet — they need a trained checkpoint + dataset (KITScenes/L2D) + a simulator (NAVSIM/Bench2Drive). The harness has hooks for those. @m-zain-khawaja — since you're leading this comparison, happy to fold the harness into this PR or move it to a separate one, whatever you prefer. I can also help wire the trained ADE/FDE + closed-loop metrics once the training loop (#78/#67) is in place. —Reply to this email directly, view it on GitHub, or unsubscribe.Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today! You are receiving this because you were mentioned.Message ID: ***@***.***>

[m-zain-khawaja]

Thank you @gcordova10 - these results are encouraging. Could you please add this in a separate PR 👍