Overview

The Global Path Planner computes the optimal racing line for the entire track after the first lap is complete. It uses the complete track map from SLAM to generate a single, time-optimal trajectory that the vehicle follows for all subsequent laps.

Purpose

After completing the exploration lap, the vehicle has a complete map of the track. The global path planner uses this full information to:

Compute optimal racing line: Find the fastest path around the entire track
Consider full track topology: Account for upcoming corners and straights
Generate repeatable trajectory: Same path used for all remaining laps
Maximize performance: Achieve minimum lap times with full track knowledge

The global planner runs once when the global map is available, then the vehicle tracks this path for the remainder of the race.

Comparison with Local Planner

Aspect	Local Planner	Global Planner
When Active	First lap (exploration)	After first lap (racing)
Horizon	10 waypoints (~10-20m)	100 waypoints (full track)
Update Frequency	1-5 Hz (every SLAM update)	Once (when global map received)
Solve Time	60-180ms	1-5 seconds
Input	Local cone observations	Complete track map
Objective	Minimize time over short horizon	Minimize full lap time
Path Quality	~10-15% slower than optimal	Optimal racing line

System Architecture

SLAM Global Map (after lap 1)
       ↓
Cone Ordering ────→ Full Track Boundaries
       ↓
Time-Optimal ────→ Complete Lap Trajectory
Optimization       (100 waypoints)
       ↓
Path Message ────→ MPC Controller
       ↓
Node Shutdown (job complete)

The global planner operates once:

Input: Receives complete track map from SLAM
Cone Ordering: Sorts all cones into closed-loop left/right boundaries
Trajectory Optimization: Solves for time-optimal lap
Output: Publishes full-lap trajectory and signals completion
Shutdown: Node destroys itself (no longer needed)

Key Characteristics

Long Horizon

Optimizes over N = 100 waypoints (configurable)
Covers entire track (~100-200 meters depending on track size)
Computation time: 1-5 seconds (acceptable since it runs once)

Time-Optimal Objective

Same as local planner:

\[\min \sum_{i=1}^N \Delta t_i\]

But now considers the entire lap, allowing for better planning of corner entry/exit speeds.

Closed-Loop Path

Unlike the local planner, the global path forms a closed loop:

First and last waypoints connect seamlessly
Path repeats indefinitely
Vehicle can track the same path for multiple laps

Cone Collision Constraints

The global planner includes explicit cone avoidance constraints (unlike the local planner):

Keeps vehicle bounding box away from all cones
Uses approximate rectangular safety region around vehicle
Considers N_CONES_PER_POINT nearest cones at each waypoint

Note: These constraints may be disabled depending on computational performance.

See: global_path/global_path/global_opt_compiled.py

Track Representation

Similar to the local planner, the track is represented as N pairs of left/right boundary points:

\[\text{position}_i = (1 - t_i) \cdot \text{left}_i + t_i \cdot \text{right}_i\]

Where t ∈ [0, 1] determines the racing line. However, for the global planner:

N = 100 (covers full track)
Path forms a closed loop (waypoint 101 = waypoint 1)
Optimization can choose aggressive racing lines with full track knowledge

Integration with SLAM

The global planner subscribes to /slam/map/global, which SLAM publishes after:

Vehicle completes first lap (lap counter ≥ 1)
Loop closure is detected
Full track map is optimized

The global map contains:

All observed cones (typically 50-200 cones depending on track size)
Cone colors (blue/yellow for left/right boundaries)
Optimized positions after loop closure

When the global map is received:

Global planner activates and starts optimization
Local planner receives the same message and shuts down
After optimization completes, global planner publishes path and shuts down

Optimization Time

The global planner solves a much larger optimization problem than the local planner:

Variables: 7 × 100 = 700 decision variables
Constraints: ~1000-2000 constraints (dynamics, bounds, cone avoidance)
Solve time: 1-5 seconds depending on track complexity

This is acceptable because:

It only runs once per race
Vehicle continues tracking local path until global path is ready
1-5 seconds is negligible compared to lap times (~20-40 seconds)

Output Format

The planner publishes a FebPath message containing the complete lap trajectory:

States (100 waypoints):

x, y: Position (meters)
psi: Heading angle (radians)
v: Velocity (m/s)
th: Steering angle (radians)

Controls (between waypoints):

a: Acceleration (m/s²)
thdot: Steering rate (rad/s)

The path is interpolated to a constant time grid (10ms intervals) to match the MPC control frequency, similar to the local planner.

Additionally, the global planner publishes:

/path/finished (Bool): Signals that global path is available
/path/global/viz (PointCloud): Path visualization

Typical Performance

Computation Time

Cone ordering: 10-50ms (more cones than local)
Optimization solve: 1-5 seconds
Path interpolation: 10-20ms
Total: 1-5 seconds (acceptable for one-time computation)

Path Quality

True optimal racing line (within solver tolerance)
Maximum corner speeds (friction-limited)
Optimal corner entry/exit trajectories
Lap times typically 10-15% faster than local planner paths

Lap Time Improvement

Example improvements over local planner:

Straight-heavy tracks: 5-10% faster
Technical tracks: 10-15% faster
Very tight tracks: 15-20% faster

The improvement comes from better anticipation of upcoming corners and optimized speed profiles.

Robustness

Solver Convergence

The larger problem is more challenging to solve:

May require more iterations (50-200 vs 10-50 for local)
Occasionally fails to converge on very complex tracks
Warm-starting not available (no previous solution)

If the solver fails:

Vehicle continues using local path planner
Manual intervention may be required to adjust constraints
Alternative: Pre-compute path offline and load from file

Cone Ordering

Cone ordering for the full track is more challenging:

Must form a closed loop (first and last points connect)
Longer boundaries increase risk of ordering errors
Same distance-based algorithm as local planner (prone to same failure modes)

If cone ordering fails:

Global planner won’t produce a valid path
Vehicle continues with local planner
SLAM map quality should be verified

Node Lifecycle

The global planner node has a unique lifecycle:

Startup: Node initializes and waits for global map
Activation: Receives /slam/map/global and begins optimization
Publishing: Outputs global path and completion signal
Shutdown: Destroys itself (self.destroy_node())

This design saves computational resources since the global planner is only needed once.

See: global_path/global_path/main.py:88

Transition from Local to Global

The handoff between local and global planners is designed to be seamless:

SLAM publishes global map
Local planner receives global map, publishes /path/finished, shuts down
Global planner receives global map, starts optimization
Vehicle continues tracking previous local path during optimization
Global planner publishes new path
MPC seamlessly switches to tracking global path

From the MPC perspective, it simply tracks whatever path is published on /path/global or /path/local, whichever is most recent.

Limitations

Single Computation

The global path is computed once and never updated:

Cannot adapt to changing track conditions
If cones are moved, path may become invalid
No dynamic obstacle avoidance

Cone Ordering Challenges

Same limitations as local planner, but amplified by full track:

Complex tracks may fail to order correctly
No error recovery once optimization starts
Requires high-quality SLAM map

Computational Cost

While 1-5 seconds is acceptable for one-time computation:

Very large tracks (>200 cones) may take >10 seconds
Embedded systems may struggle with memory requirements
Alternative: Pre-compute offline and load at runtime