Formula Student AI is what it sounds like: the same cone-lined circuits as Formula Student, run in the IMechE's FS-AI class, with nobody in the car. Acceleration, Skid Pad, Sprint, Trackdrive. The car drives all of them itself. This year's competition was at Silverstone, 15–19 July.
No driver. No remote control. No human in the loop. The car has to find the cones, work out where the track goes, choose a line through it and drive that line, in real time, from what it can sense at that moment. Get one cone wrong and you clip it. Get the loop wrong and the car doesn't move at all.
I spent the season with UH Racing Autonomous, working on the software behind it.
The car
Underneath the shell it is one chain: perception → localization and mapping → planning → control. Cameras and LiDAR find the cones, SLAM builds a map and places the car on it, the planner draws a line through the cones, and the controller turns that line into steering and speed.
- Compute: NVIDIA Jetson AGX Orin, bolted to the car
- Vision: ZED 2i stereo camera
- Range: Velodyne LiDAR
- Motion: SBG IMU + GNSS
- Stack: ROS 2 Humble, C++ and Python, cone detector in PyTorch
With no driver in the seat, the sensor mount is the car's head. Everything it knows about the world arrives through that rig.
What I worked on
Two things, both underneath the part people actually watch: the environment the software was built in, and the sensor data it runs on.
The environment
A driverless car is, before anything else, a software project, and a student team is the worst possible conditions for one. People come and go between terms. Everyone is on a different laptop, a different distro, a different CUDA version. And all of it has to end up running on one specific arm64 Jetson bolted into a car, where the only thing that counts is whether it works on that machine, on the day, in the paddock.
"Works on my machine" is a joke right up until track time is finite. Then it is the whole problem.
So the environment became a thing you check out rather than a thing you rebuild: Docker, the same image for everyone, the same image on the car. It is the least glamorous work on the team and I would defend it as some of the most valuable, because it is what converts a person's afternoon from fighting their own setup into fixing the actual bug. Multiply that across a season and a team, and it is the difference between a car that runs and a car that nearly ran.
The sensor data
The other half of my season went into the camera and the LiDAR. Or, as our lead developer put it on his own write-up of the season, "spent way too many nights twisting camera and LiDAR data into submission."
That phrasing is about right. Perception gets described as "a neural network finds the cones", and that part is real, but it sits on top of a much less photogenic problem: two very different instruments have to agree about the same world. A stereo camera gives you colour and a guess at depth. A LiDAR gives you range you can trust and no idea what colour anything is. They sit in different places on the rig, run at different rates, and timestamp things their own way. Before any of it becomes "a list of coloured cones with positions", somebody has to make those two streams describe the same instant of the same track.
That is the work that doesn't appear in the highlight reel, and the stack simply does not function without it.
What the season taught me
That the demo is the last five per cent. Everything upstream of it is what decides whether the five per cent ever happens: reproducible builds, sensor data you can trust, logs you can replay.
Also that failures out here are wonderfully unambiguous. A robot that mislocalises in a lab prints a slightly wrong number. A car that mislocalises drives calmly and confidently through the cones, in front of everyone. Artiom has written the proper technical account of that side of it: the EKF-SLAM, the sensors that lie, the lap where the map froze. It is worth reading in full.
There is a lot left: wheel-speed odometry into the filter, faster perception on the Jetson, a real racing line once the drift is bounded. Every event teaches the team something the simulator never did.
But there is nothing quite like watching something you wrote steer a real car around a circuit with nobody in it.
The team
Thanks to Benjamin Joel, our team lead, who kept the whole thing pointed in the right direction. To Artiom Cebotari, our lead developer and one of the best engineers I have had the chance to work alongside. He set a standard the rest of us worked up to, and I learned a great deal just from being on the same team. To Sanchit Acharya, who took on the Acceleration event and a good share of the debugging. And to Fred Jordan bland, our ASR, who kept everyone safe and the operation running on track, which matters more than people outside the team realise.
Huge thanks to everyone at UH Racing Autonomous. Getting a car to drive itself around a circuit as a student team takes every single person.
