Skip to content
Autonomy2026-06-10· 2026 Season

Standing Up the Driverless Program

UMSAE-Formula-Electric/cortex

Year one as Driverless System Officer: the team research, rules digest, vehicle and software architecture, team structure, design review and budget behind a driverless car for 2028.

#ROS 2#C++#Jetson Orin#architecture#rules#budget

The plan

  • Retrofit the existing FSAE Electric car. Every team that reached a driverless competition in under a year started from a running EV.
  • Target FSAE 2028, two years ahead of SAE’s 2030 mandate.
  • Build order: acceleration, autocross, trackdrive, skidpad. 150 of the 250 dynamic points are speed-independent, so reliability outranks pace.
  • Compute on the NVIDIA Jetson Orin, with one C++/ROS 2 monorepo: packages grouped by pipeline stage, one shared interface package, colcon and Docker. Closest references are AMZ’s fsd_skeleton and QUT’s QUTMS_Driverless.
  • **Budget of 28,234CAD∗∗across56lineitems,28,234 CAD** across 56 line items, 18,233 of it rules-critical. The Gross-Funk remote emergency system is the longest lead item, so it gets ordered first regardless of what else is settled.

Team research

How long it took other Formula Student programs to reach their first driverless competition, and what each of them started from. This set the 2028 target and the decision to retrofit rather than build a new platform.

TeamMonths to first driverless competition
KA-RaceIng (KIT)7 to 8
e-gnition Hamburg9
Chalmers10 to 11
TUfast (TUM)12
DUT Delft, MIT12 to 14
AMZ (ETH Zurich)12 to 18
KTH18 to 20
Carnegie Mellonabout 20
Toronto (UTFR)24 to 30
QUT29 to 31

Rules digest

Every driverless rule that constrains a design decision, mapped onto the subsystem that has to satisfy it, in columns for mechanical, electrical, software and inspection gating.

Rules digest by subsystem
FSAE Driverless supplement and FSG specification, read as design constraints.

Vehicle architecture

Where the sensors, compute and actuators sit on the car, and how the shutdown circuit, remote stop system and emergency brake supply are wired together.

Vehicle architecture and actuator power supply
Sensing and actuation over CAN, mission selection, and the shutdown circuit.

Software architecture

The ROS 2 workspace layout and topic graph: camera and LiDAR drivers into perception, then SLAM, then planning, with the MCU interface closing the loop back onto the car.

ROS 2 workspace and topic graph
Workspace boundaries and the topics that cross them.

Team structure

Who owns which stage of the pipeline, what each role is responsible for, and the development loop from simulation through hardware in the loop to track testing. The mechanical and electrical interface box is still unassigned.

Team structure and software process
Roles, responsibilities and open gaps. Names removed for publication.

Repository layout

The structure the planning repo recommends for the monorepo, synthesised from QUT (layout), AMZ (layering) and CMU (dev environment). Packages are grouped by pipeline stage, umsae_msgs is the one interface package everything else depends on, and the simulator adapter can be excluded from car builds.

umsae-driverless/                      # one repo = one colcon workspace
├── README.md                          # what/why, quickstart, links to docs/
├── LICENSE
├── .gitignore                         # build/ install/ log/ bags/ *.engine ...
├── .gitmodules                        # external ROS packages as submodules
├── .clang-format                      # C++ style (pick one, never argue again)
├── .pre-commit-config.yaml            # clang-format, black, isort, whitespace
├── pyproject.toml                     # black/isort/ruff config
├── dependencies.repos                 # optional: vcstool alternative to submodules
│
├── .github/
│   └── workflows/
│       ├── pre_commit.yaml            # lint on every PR
│       ├── build.yaml                 # colcon build + colcon test in the dev image
│       └── image.yaml                 # build+push dev image to GHCR on main
│
├── docker/
│   ├── Dockerfile.base                # FROM osrf/ros:jazzy-desktop, rosdep install
│   ├── Dockerfile.overlay             # user setup + workspace, dev tools
│   ├── docker-compose.yml             # dev, sim, (optional) ml profiles
│   ├── cyclonedds.xml                 # pinned DDS config
│   └── Makefile                       # make dev / make sim / make build
│
├── docs/
│   ├── onboarding.md                  # zero-to-running-sim guide (test on a fresh laptop)
│   ├── architecture.md                # pipeline diagram, topic map, frames/TF tree
│   └── conventions.md                 # naming, style, branch/PR rules
│
├── src/
│   ├── common/
│   │   ├── umsae_msgs/                # THE interface package: Cone, ConeArrayWithCovariance,
│   │   │                              #   CarState, ControlCommand, Mission, ...
│   │   │                              #   (start by copying eufs_msgs vocabulary)
│   │   └── umsae_common/              # shared utils, params, py/cpp helpers
│   │
│   ├── perception/
│   │   ├── lidar_pipeline/            # ground removal, clustering, cone candidates
│   │   ├── camera_pipeline/           # YOLO(TensorRT) cone detection + depth assoc
│   │   └── perception_bringup/        # launch + params only
│   │
│   ├── estimation/                    # (QUT folds this into "navigation")
│   │   ├── state_estimation/          # wheel odom + IMU + GNSS fusion (try robot_localization first)
│   │   ├── slam/                      # cone map + localization (try Nav2/existing SLAM first)
│   │   └── estimation_bringup/
│   │
│   ├── planning/
│   │   ├── path_planner/              # centerline from cones (Delaunay; see ft-fsd-path-planning)
│   │   └── planning_bringup/
│   │
│   ├── control/
│   │   ├── controllers/               # pure pursuit first, MPC later
│   │   └── control_bringup/
│   │
│   ├── hardware/
│   │   ├── canbus/                    # CAN <-> ROS bridge, generated from the team DBC
│   │   ├── sensors/                   # vendor driver configs/wrappers (drivers themselves = submodules)
│   │   └── actuation/                 # steering/brake/throttle interfaces, EBS state machine
│   │
│   ├── operations/
│   │   ├── vehicle_bringup/           # mission launches: acceleration, skidpad,
│   │   │                              #   autocross, trackdrive, inspection
│   │   ├── vehicle_urdf/              # robot description + TF
│   │   └── recording/                 # rosbag recorder + topics_to_record.yaml
│   │
│   └── sim/
│       └── sim_interface/             # adapter to eufs_sim/FSDS; excluded from car builds
│
└── tools/                             # non-ROS: CLI helpers, dataset scripts,
                                       #   Foxglove layouts, track generators
First batch of sensor units laid out for fitting: LiDARs, cameras, and the compute to run them

Targeted sponsorship outreach secured about $30k in sponsored hardware: LiDARs, cameras and auxiliary sensors.

Design review

The deck I presented to the team: dynamic events, system architecture across all three disciplines, the perception to estimation to controls pipeline and a simplified version to ship first, the DSO role and driverless systems form, the remote stop system, power supply schematic, monitoring and startup flowcharts, and the CAN signal set.

Driverless systems design review
46 slides · PDFOpenDownload

Driverless systems design review

Open the PDF →

Budgeting

56 line items in CAD, each tagged with priority, lead time and whether it is sponsorable. LiDAR, cameras and GNSS/INS sit at $0 because they are covered by the sponsorship asks rather than the cash budget.

PriorityCost (CAD)Line items
Critical$18,23330
High$9,11120
Medium$3424
Low$5482
Total$28,23456
Driverless budget
5 pages · PDFOpenDownload

Driverless budget

Open the PDF →

Next

Perception prototyping on the Orin, simulation infrastructure, and team documentation. These posts will follow the program to 2028.

← Back to all entries