FRENETIX: Modular Motion Planner

• The paper introduces FRENETIX as a modular, high-performance motion planner that integrates trajectory sampling, kinematic feasibility checks, and occlusion-aware safety mechanisms.
• It employs rigorous mathematical formulations and multi-objective cost optimization to achieve robust, collision-free maneuvers in diverse simulation scenarios.
• The framework offers open-source implementations in C++ and Python, enabling seamless integration, real-time planning, and customizable module replacements.

FRENETIX is a high-performance, strictly modular motion planning framework for autonomous driving, originally developed by the Technical University of Munich (TUM-2023). It combines a sampling-based trajectory planner with robust, extensible modules for kinematic feasibility, multi-objective optimization, and advanced safety assessment—including explicit handling of occlusions. FRENETIX is designed for efficient autonomous navigation in both simulated and real-world environments, with open-source reference implementations in C++ and Python targeting seamless integration and rigorous benchmarking in academic and industrial research (Trauth et al., 2024, Moller et al., 2024).

1. Modular Architecture and Motion Planning Workflow

FRENETIX employs a pipeline-structured, modular architecture in which each stage can be independently replaced or extended. The major components are:

• Preprocessing stage: Ingests scenarios (e.g., CommonRoad), builds a semantic lanelet network, and computes a global reference path $\Gamma$ using Dijkstra or A* graph search. The preprocessing stage also accommodates optional modules such as vehicle-motion prediction, risk assessment, occlusion handling, or behavior planning.
• Motion-Planning Cycle (executed at every planning timestep):

1. Vehicle-State Update: Pose, velocity, and acceleration are updated from the simulator or sensors.
2. Trajectory Sampling (Frenet frame): Longitudinal ($s$) and lateral ($d$) motions are planned with respect to $\Gamma$.
3. Kinematic Feasibility Check: Verifies compliance with bounds on acceleration, curvature, yaw-rate, and curvature rate.
4. Cost Evaluation: Computes trajectory-specific costs on comfort, safety, and path deviation.
5. Multi-Objective Optimization: Aggregates cost components by weighted sum for efficient ranking.
6. Collision and Road-Boundary Check: Uses oriented bounding box (OBB) checks to ensure continuous-time collision-freedom and compliance with road boundaries.
7. Trajectory Selection: Outputs the lowest-cost, collision-free trajectory; in the absence of feasible solutions, an emergency or minimum-risk maneuver is selected.

• Open, Swappable Modules: Architecture allows for exchange of trajectory samplers (e.g., quintic-polynomial, RRT*), cost functions, collision checkers, and prediction modules.

This modularity is reflected in both the C++ core (for real-time execution) and the Python wrapper (for rapid prototyping and researcher accessibility).

2. Mathematical Formulation of Trajectory Planning

FRENETIX parameterizes candidate trajectories in Frenet coordinates $(s(t), d(t))$ relative to the path $\Gamma$. The generation and evaluation process is defined as follows:

• Trajectory Sampling: Discretizes terminal conditions over time horizon $\tau$, lateral offsets $d_\tau$, and terminal velocities $v_\tau$ (or end positions $s_\tau$).
  • Lateral motion $s$0 is modeled as a quintic polynomial

  $s$1

  with boundary conditions $s$2, $s$3, $s$4, $s$5, $s$6, $s$7. Longitudinal motion can use quartic or quintic polynomials.

• Feasibility Constraints: Kinematic bounds must hold $s$8,

  • Acceleration: $s$9, where $d$0 scales with velocity as detailed in the framework.
  • Curvature: $d$1.
  • Curvature-rate and yaw-rate limits.
  • Continuous collision-free guarantee by OBB collision checking (DrivabilityChecker).
• Cost Functions and Optimization: Each feasible $d$2 receives a total cost

$d$3

with partial costs $d$4 (acceleration), $d$5 (jerk), $d$6 (lateral jerk), $d$7 (velocity offset), $d$8 (route precision), $d$9 (distance to obstacle), $\Gamma$0 (collision probability), and $\Gamma$1 (minimum distance to moving obstacles). Cost weights $\Gamma$2 can be adjusted online or via learning-based approaches for adaptation.

3. Explicit Occlusion Handling with FRENETIX-Occlusion

FRENETIX-Occlusion extends baseline planning with an occlusion-aware safety module. Its principal mechanisms are:

• Occlusion Detection: Computes visible ($\Gamma$3) and occluded ($\Gamma$4) areas in the ego-vehicle’s sensor footprint using map and obstacle geometry. Static, dynamic, and geometric (curvature-induced) blind spots are separately identified.
• Phantom Agent (PA) Generation: For each occlusion region, spawn points $\Gamma$5 are generated and assigned plausible agent types (pedestrian, bicycle, vehicle). For each combination, deterministic constant-velocity predictions are produced along feasible routes.
• Criticality Metrics: For any ego-candidate trajectory $\Gamma$6, computes:
  • Distance-to-Closest-Encounter (DCE)
  • Time-to-Collision (TTC)
  • Brake-Threat-Number (BTN)
  • Harm & Risk (HR)
  • Collision Probability (CP)

A trajectory is valid iff all metrics $\Gamma$7 are below user-defined thresholds $\Gamma$8, i.e., $\Gamma$9.

• Integration with Planning: The motion-planning funnel is extended by appending the occlusion-safety check after kinematic and collision filtering. The planner can discard invalid trajectories or re-rank based on combined cost and safety.
• API: The Python module can be invoked standalone to evaluate candidate trajectory sets, receiving map, state, and planned trajectories as inputs.

4. Performance Evaluation and Empirical Results

FRENETIX has been extensively evaluated using the CommonRoad benchmark, with 1,750 diverse scenarios encompassing urban, highway, and highly dynamic environments (Trauth et al., 2024).

• Quantitative Metrics:
  • Success Rate: 88.0% (1,539/1,750 scenarios reach the goal with no collision).
  • Collisions: 8.2% (143/1,750).
  • No feasible solution: 2.2% (39/1,750).
  • Time-limit exceeded: 1.6% (29/1,750).
• Computation Times for 800 trajectories (AMD 7950X, RTX 4090):
  • C++ (single-core): 29.37 ms
  • C++ (multi-core): 7.87 ms
  • Python (single-core): 457.87 ms
  • Python (multi-core): 214.72 ms

Real-time planning capability is preserved up to high trajectory counts (e.g., 13,000) with parallelized C++. This suggests suitability for deployment in latency-sensitive applications.

• FRENETIX-Occlusion Performance (Moller et al., 2024):
  • Metric evaluation per $(s(t), d(t))$0 and two PAs: TTC ≈ 0.08 ms, DCE ≈ 4.3 ms, BTN ≈ 15 ms.
  • Sensor model: ≈16 ms; PA prediction: ≈110 ms (vehicle), ≈0.4 ms (pedestrian).
• Scenario-based Assessment: Stricter occlusion-risk thresholds lead to lower velocities and improved collision avoidance. For example, enforcing $(s(t), d(t))$1 resulted in earlier braking and v_min decrease from 4.4 m/s to 3.05 m/s in a left-turn cyclist occlusion scenario.
• Real-World Tests: Current results are primarily simulation-based. Planned track experiments will evaluate controller deviation and robustness under sensor and actuator imperfections.

5. Adaptability, Extensions, and Open-Source Implementation

FRENETIX facilitates broad adaptability:

• Vehicle-Model Agnosticism: Vehicle kinematic constraints ($(s(t), d(t))$2, $(s(t), d(t))$3, $(s(t), d(t))$4) and trajectory boundary conditions are configurable for different platforms.
• Scenario Support: Modular preprocessing accommodates custom map loaders, lanelet extractors, and scenario generation.
• Cost Adaptation: Online and learned cost-weight tuning (e.g., via inverse reinforcement learning) is supported to match driving style preferences.
• Parallelizability: The computation pipeline is embarrassingly parallel—supporting multi-threading, GPU-based evaluation, or distributed computation.
• Open-Source Availability:
  • FRENETIX core: https://github.com/TUM-AVS/Frenetix-Motion-Planner
  • C++ src/ with CMake, Python py/, example scenarios, scripts for experiments.
  • FRENETIX-Occlusion: https://github.com/TUM-AVS/Frenetix-Occlusion
  • Modular Python codebase; includes sensor modeling, spawn-point detection, PA prediction, metric computation, and safety assessment.
• Reproducibility: Complete instructions are provided for experiment replication, including dependency installation, scenario downloads, and log extraction.

6. Experimental Limitations and Research Directions

Several limitations suggest future developments:

• Static Thresholds in Safety Metrics: Current occlusion and harm thresholds are user-defined and scenario-invariant. Adaptive or learning-based thresholding could reduce unnecessary conservatism.
• Computational Scaling: PA prediction cost grows with the number of spawn points and routes; optimized C++ implementations and GPU offloading are identified as promising.
• Prediction Model Fidelity: FRENETIX-Occlusion currently uses deterministic constant-velocity predictions for phantom agents, excluding interactions or responsive behaviors. Incorporating set-based reachable sets, POMDP-based probabilistic forecasts, or game-theoretic models could enhance realism.
• Temporal Tracking of Occluded Agents: Phantom agents have no temporal continuity. Integration of joint multitimestep reasoning or multi-hypothesis tracking could improve risk calibration.
• Experimental Validation: While simulation results are comprehensive, planned real-world testing will address controller-trajectory deviation and actuation/sensor uncertainties.

A plausible implication is that the FRENETIX architecture and codebase constitute not only a reference for high-throughput, modular motion planning research but also a baseline platform for next-generation occlusion-aware and risk-adaptive autonomous driving behaviors (Trauth et al., 2024, Moller et al., 2024).