Trajectory Optimization & Planning at DiDi Research America
Project Summary
Overview
During my internship on the Motion Planning team at DiDi Research America, I worked across two systems: a data-driven end-to-end planning model trained on large-scale human-driving data, and a large legacy C++ production trajectory-optimization planner. Both problems reduced to the same core question — how to make constrained trajectory optimization fast, robust, and safe enough to run at scale, whether offline over billions of driving frames or online in a production vehicle stack. I approached both with differential dynamic programming (DDP) formulated as augmented-Lagrangian constrained optimization.
The Problem with “Ground Truth” Driving Data
The end-to-end planning model is trained on 1.3B human-driving frames. It’s tempting to treat logged human trajectories as ground truth and imitate them directly. But the logged trajectory is not the ground truth — it’s a noisy observation of it. Position and heading come from GPS+IMU, steering from a steering-angle sensor, acceleration from IMU — each with its own sensor noise (on the order of centimeters in position, hundredths of a radian in heading and steering). Comfort-relevant quantities like jerk and steering rate aren’t measured directly at all; they’re recovered by finite-differencing the logged signal, which is a high-pass operation that amplifies exactly the noise you’re trying to avoid.
Learning from the raw modular pipeline’s outputs is no better: a traditional perception → prediction → planning pipeline is already an engineered approximation of good driving, with many hand-tuned objectives and thresholds, and coupled modules that create unpredictable system-level effects. Imitating it just inherits its biases.
Reformulating Trajectory Cleanup as MAP Inference
My approach: separate what the sensors tell us actually happened from what behavior we’d prefer the model to imitate, and combine both into a single inference problem. Factor the trajectory posterior over states $x_k$, measurements $y_k$, and controls $u_k$ into three terms:
$$ \mathbb{P}(z_{0:T-1} \mid y_{0:T-1}) \propto \mathbb{P}(x_0) \prod_{k=0}^{T-1} \underbrace{\mathbb{P}(y_k \mid x_k)}_{\text{observation}} \prod_{k=0}^{T-2} \underbrace{\mathbb{P}(x_{k+1} \mid x_k, u_k)}_{\text{dynamics}} \underbrace{\mathbb{P}(u_k \mid x_k)}_{\text{preference}} $$The observation and dynamics terms are defined by the physical world — sensor noise and the vehicle model — so I measured them from sensor specs instead of hand-tuning them. The preference term is where we get to say what behavior we actually want (bounded jerk, small tracking error, smooth control), and I modeled it as a Boltzmann distribution over a cost $J(u)$, so that undesirable actions become exponentially less likely rather than simply forbidden.
Taking the negative log and finding the maximum a posteriori (MAP) trajectory turns this into a constrained optimization problem: find the dynamically feasible trajectory that stays statistically close to the recorded measurements, obeys comfort limits, and favors simple, slowly varying controls. I solved this with an augmented-Lagrangian DDP denoiser. In practice, the denoised trajectories cut jerk and lateral-jerk discomfort rates to 0–4% from a baseline of 8–39%, while keeping ADE/FDE tracking metrics essentially unchanged from the raw data.
Diagnosing Constraint Conflicts with Shadow Prices
Hard comfort limits and hard geometric constraints don’t always agree with the data — a sharp evasive maneuver in the logs might genuinely require jerk beyond the “comfortable” bound. Rather than hand-picking which constraints to soften for which scenarios, I used the constraints’ own shadow prices (the Lagrange multipliers from solving the MAP problem with everything as hard constraints) to diagnose conflict automatically: a shadow price tells you how much the optimizer would improve if that constraint were relaxed by one unit, so it directly measures which limits are actively fighting the data and by how much.
Clustering trajectories by their shadow-price signature recovered exactly the structure I’d expect from real driving data — a large cluster where no comfort constraint binds at all, a cluster of comfort-abiding but non-smooth trajectories where jerk limits dominate, a cluster where lane geometry dominates, and a mixed cluster where both interact — without needing to hand-label scenario types.
Elastic Constraint Relaxation
Shadow prices tell you which constraints conflict with the data; elastic relaxation is what turns that diagnosis into an action. I added a slack variable to each constraint with an $L_1$ penalty on its magnitude, so the solver only pays to violate a constraint when the shadow price of not violating it is high enough to be worth the penalty — i.e., the slack is priced like a resource, and the optimizer only draws on it when the benefit outweighs the cost. I shipped this as a relaxable augmented-Lagrangian constraint type that is no-op-safe: it falls back cleanly to standard hard-constraint behavior when relaxation isn’t needed, and degrades gracefully (rather than failing outright) on the sharp turns and emergency-braking scenarios where hard comfort limits are simply incompatible with what the maneuver requires.
Related Exploration: Constraint Relaxation for Narrow U-Turns
As a smaller side investigation of the same idea, I looked at why our geometry-based path planner struggled with U-turns at narrow intersections, which typically require a multi-point (“K-turn”) maneuver. The planner’s hard geometric constraints (curvature, pinch, juke) were often infeasible as stated — but what we actually care about is lateral comfort, which is jointly determined by path curvature and speed. A path that’s too tight at highway speed can be perfectly comfortable if the vehicle slows down first.
I reformulated this as an MPC problem that jointly plans a speed profile alongside the path, replacing the hard geometric constraints with a comfort-driven acceleration/jerk formulation over two phases: a tracking phase where progress is rewarded, and a braking tail that drives the vehicle to a full stop as a control-invariant terminal condition — so the planner always has a safe fallback if the maneuver can’t be completed. Testing across intersection widths showed the same qualitative shadow-price-style behavior: at 4m the turn is geometrically infeasible and the planner brakes to a safe stop instead of forcing a comfort violation, while at 10m there’s enough room to complete the turn smoothly.
Re-architecting the Production Solver
On the production side, I re-architected the trajectory-optimization core of a large legacy C++ planner — previously built on an IPOPT-based NLP formulation — as an efficient augmented-Lagrangian DDP solver, and built a reusable solver abstraction that let IPOPT, Acados/HPIPM SQP, and my Python/C++ AL-DDP implementation be benchmarked and swapped side-by-side. The new solver improved solve speed by ~6x over the IPOPT baseline, a critical margin for a component that has to run within a real-time onboard planning stack.
Cross-Team Collaboration
I coordinated design and code reviews across the ML-planner and path-planner teams, evaluated changes on real driving scenarios across safety, compliance, comfort, and efficiency metrics, and participated in weekly road-test triage.
Motion Planning Engineer, Intern (May 2026 — Aug 2026)
- Integrated a DDP smoother into the training and preprocessing pipeline of an end-to-end planning model trained on 1.3B human-driving frames, improving comfort and efficiency in data-based simulation.
- Reformulated trajectory cleanup as Bayesian MAP estimation and shipped an augmented-Lagrangian DDP denoiser, reducing jerk and lateral-jerk discomfort rates to 0-4% from 8-39% while keeping ADE/FDE competitive.
- Re-architected the trajectory-optimization core of a large legacy C++ production planner as an efficient augmented-Lagrangian DDP solver, improving solve speed by ~6x over an IPOPT baseline.
- Designed an elastic constraint-relaxation scheme with L1-penalized slacks, diagnosed via constraint shadow prices, and shipped it onboard as a no-op-safe relaxable augmented-Lagrangian constraint type.
- Coordinated design and code reviews across ML-planner and path-planner teams; evaluated changes on real driving scenarios across safety, compliance, comfort, and efficiency metrics; and participated in weekly road-test triage.
Tech: C++17, Python, CasADi, Acados/HPIPM/BLASFEO, IPOPT, Eigen, pybind11, ROS 1, Bazel.
