Frenet-Frame Trajectory Planning for Urban Driving

The problem

Urban driving needs trajectories that follow curved lanes, keep distance to other road users, stop when needed and stay comfortable. The Frenet-frame approach generates many candidate trajectories cheaply and picks the best one, but its behaviour depends on sampling density, cost weights and replanning rate, all of which must be tuned and measured.

Objectives

• Implement Frenet conversion along a curved reference path.
• Generate quintic lateral and quartic longitudinal candidates for following, stopping and velocity keeping.
• Check candidates for kinematic feasibility and collisions with predicted obstacles.
• Evaluate safety, comfort and progress across urban scenarios and compare with a simpler baseline.

What you need

Key concepts

Frenet coordinates

Position along the reference path (s) and lateral offset from it (d). Planning in s and d separates lane keeping from speed control on curved roads.

Jerk-optimal polynomials

Quintic polynomials minimise jerk for given start and end conditions; quartic polynomials are used for velocity-keeping where final position is free.

Receding horizon replanning

Planning a trajectory several seconds long but executing only the first part before replanning from the new state, which handles changing traffic.

Step-by-step guide

1. 1

   Set the ODD and requirements

   Define the scenario scope: urban two-lane roads with curves, speed limits up to 50 km/h, stopped vehicles, slower leaders, cut-ins and a pedestrian crossing. Set requirements: no collisions, a minimum time headway to leaders, longitudinal and lateral acceleration and jerk limits, and a planning cycle under 100 ms. Choose a baseline: an IDM car-following model with lane keeping only. Note the planning horizon too.

   Checkpoint: A requirements table and a baseline definition.

2. 2

   Build the reference path and Frenet conversion

   Create curved reference paths from waypoints fitted with a cubic spline parameterised by arc length. Implement Cartesian to Frenet conversion by finding the closest point on the spline and Frenet to Cartesian conversion using the path heading and curvature. Test round trips at many points, including on tight curves where the conversion can become ill-conditioned for large offsets. Also check the curvature profile for spikes from badly placed waypoints.

   Checkpoint: Round-trip error below a centimetre for offsets within the lane width.

3. 3

   Generate candidates

   For each cycle, sample terminal lateral offsets (lane centre, small offsets and the adjacent lane centre) and durations of 2 to 5 s for quintic lateral polynomials. Sample target speeds for quartic velocity-keeping profiles and target stop positions for quintic stopping profiles. Combine lateral and longitudinal profiles into full candidates and convert them to Cartesian paths with heading, curvature, speed and acceleration.

   Checkpoint: A plot of all candidates for one cycle, coloured by type.

4. 4

   Check feasibility

   Reject candidates that exceed maximum speed, longitudinal acceleration, curvature or lateral acceleration limits, or that leave the drivable area. Record how many candidates each check removes to understand the sampling efficiency. If too many are rejected in curves, adjust sampling ranges rather than loosening limits. Apply the cheapest checks first, such as speed and acceleration, so expensive curvature and drivable-area checks run on fewer candidates. Measure time spent in each check.

   Checkpoint: Feasibility statistics per scenario showing sensible rejection rates.

5. 5

   Predict obstacles and check collisions

   Predict other vehicles and pedestrians with constant velocity along their lanes or paths over the horizon. Represent each as a rectangle or set of circles inflated by a time-growing margin, and check each candidate at every time step. Add a separate time headway check against leaders in the same lane. Visualise rejected and accepted candidates against predicted obstacles. Time the collision check per candidate to keep within the cycle budget.

   Checkpoint: Candidates crossing a predicted obstacle are consistently rejected.

6. 6

   Design the cost function

   Cost each candidate on lateral and longitudinal jerk, deviation from the lane centre, deviation from desired speed, time to complete and proximity to obstacles. Normalise each term so weights are interpretable. Tune weights on a subset of scenarios, then freeze them. Add hysteresis on lane choice so the planner does not alternate between lanes every cycle. Record the weights in a configuration file so every evaluation run uses the same values.

   Checkpoint: Tuned weights that give smooth, sensible behaviour in tuning scenarios.

7. 7

   Run closed-loop scenarios

   Simulate the ego vehicle following the chosen trajectory, replanning every 100 ms from the current state. Run scenarios: stopped car in lane with a clear adjacent lane, stopped car with oncoming traffic, cut-in, slow leader, pedestrian crossing and a sharp curve. Randomise actor speeds and start times across 20 or more runs per scenario. Log trajectories and metrics. Store the chosen candidate for each cycle so failures can be replayed.

   Checkpoint: Closed-loop logs for every scenario and run.

8. 8

   Evaluate and compare

   Compute collision rate, minimum time headway and TTC, peak acceleration and jerk, average speed and planning time per cycle. Compare with the IDM baseline, which cannot change lanes, to show where the planner helps and where its added complexity adds little. Present per-scenario tables and distributions over runs. Use identical seeds and actor behaviours for both planners, and check whether any collisions are caused by the planner or by unavoidable scripted actor behaviour.

   Checkpoint: Comparison tables with spread across randomised runs.

9. 9

   Analyse sensitivity and report

   Vary sampling density, horizon length and replanning rate and show their effect on planning time and quality. Discuss failure modes, such as constant-velocity prediction failing for turning vehicles. Write up method, scenarios, results and limitations, noting that tests were in simulation only. Include the scenario definitions, random seeds and configuration files as an appendix, and plot planning time percentiles rather than only the mean, since worst-case cycles matter most.

   Checkpoint: A thesis chapter with sensitivity plots and conclusions.

Testing & validation

• Collision rate and minimum TTC and time headway per scenario.
• Peak acceleration and jerk against comfort limits.
• Planning time per cycle against the 100 ms budget.
• Comparison with the IDM lane-keeping baseline.

Expected results

A Frenet-frame urban trajectory planner with feasibility and collision checks, evaluated on randomised scenarios against a car-following baseline, with sensitivity results on sampling and horizon.

Take it further

• Add interaction-aware prediction of other vehicles.
• Use an optimisation-based refinement of the selected candidate.
• Run the planner in CARLA with its traffic manager.

Viva and review questions

Learn it at DIYguru

These DIYguru courses and programmes teach what this project needs.