F1TENTH Racing Architecture Design

[HaoruXue]

Overview

This design targets Autoware.Auto with packages being gradually ported to Autoware Universe.

Adapting Autoware to racing requires a different planning design compared to previous ODDs. The vehicle is presented with a free space and dynamic obstacles, through which the vehicle must safely and quickly maneuver. This design aims to reuse Autoware package where possible and create a planning pipeline for Autoware in racing ODD.

Components

The following Autoware nodes are involved in this process:

• record_replay_planner: serves as a global planner for an optimal racing line, created at ease by recording human driving, or by offline optimization.
• freespace_planner: serves as a local planner that takes into account dynamic obstacles and localization imperfections. Although originally intended for AVP, this is the only current node in Autoware.Auto that could plan in free space with dynamic obstacles.
• racing_planner (proposed): manages planning pipeline for racing and implements planning API such as PlannerCostmap and PlanTrajectoy.
• pure_pursuit_controller: the low-level vehicle controller.

Architecture

Baseline Architecture

This is the baseline Autoware stack on F1TENTH platform, with no obstacle avoidance ability. The record replay planner directly provides the trajectory to be followed by pure pursuit node.

This architecture is currently implemented in f1tenth-release.

Proposed Architecture

The proposed design has three major improvements

• Perception: adding NAV2 cost map generator,
• Planning: adding freespace_planner as the local planner based on cost map and race_planner to implement planning API and manage planning pipeline,
• Localization: adding IMU source and EKF to fuse VESC odometry and IMU.

The only source code change to Autoware.Auto is the additional racing planner, which may be given a more generic name based on its global-local planning characteristics.

Flow

1. A LiDAR scan is generated. AMCL updates global pose. Costmap updates based on the new scan.
2. IMU and odometry from VESC are generated and fused in EKF to complete the transform tree and output filtered odometry message, which is converted to VehicleKinematicState for record replay planner and pure pursuit controller.
3. Record replay planner gives the new raw trajectory based on the pose update.
4. Racing planner converts the raw trajectory into a route, and requests a feasible trajectory from freespace planner.
5. Freespace planner updates its costmap from racing planner, and produces a feasible trajectory.
6. Racing planner sends the local trajectory to pure pursuit controller, who outputs control signal to the VESC interface and eventually the VESC driver.

Alternatives to freespace_planner

If freespace planner does not produce sufficiently high localization rate (>= 1Hz), alternatives can be considered from external packages such as eband_local_planner and teb_local_planner. The difficulty is to port them from ROS1 from ROS2, and adapt to Autoware messaging. It also defeats the purpose of reusing Autoware as much as possible on the F1TENTH platform.