Autonomous F1Tenth Racer

The Run

Three laps, no collisions, no map. Annotations as it goes:

• ›0:03. Long straight, car at max speed.
• ›0:07. Approaches a turn; front-cone distance shrinks, speed drops.
• ›0:11. Hairpin; both the front distance and the track width close in, so the car slows further.

The Car (Hardware)

This is a standard F1Tenth car, the reference 1/10th-scale autonomy research platform out of Penn. Full hardware stack:

System Architecture

Three nodes run in parallel at race time:

1. Teleop. Handles joystick input and gates the motor enable.
2. LiDAR driver. Publishes /scan at the sensor's native rate.
3. Race controller. Subscribes to /scan, computes steering and speed, publishes an AckermannDriveStamped command.

The loop, per scan:

The whole loop closes on every LiDAR frame. No memory of past laps, no global state.

Approach

We started the semester planning to do this with SLAM: map the track on a formation lap, localize against the map on race laps, and run a fast trajectory. We got it working in simulation, but it didn't survive the jump to the physical car (more on that in Challenges). Once SLAM was off the table for race day, we pivoted to iterating on the staff-provided EOH wall-follower script and pushing it as far as it would go.

Speed Controller

The default EOH controller scales speed linearly with the minimum distance inside a ±10° cone in front of the car. Reasonable baseline, but that cone is wide enough that the LiDAR starts catching the sides of the track when you approach a turn, so the car thinks there's an obstacle before there actually is one in its driving line.

We narrowed the front cone to ±5°. That alone made the car much more willing to commit to corners.

The bigger change: we added a second input to the speed law, track width. The intuition is that front distance tells you how far ahead is clear, but track width tells you how forgiving the geometry around you is. A narrow chute deserves a slower speed even if nothing is directly ahead.

To estimate width: the LiDAR returns a sorted array indexed by angle. We find the index that separates "wall on my left" from "wall on my right" (effectively the front of the scan), then take the minimum range on each side. The sum of those two is our track-width estimate.

Speed then becomes a linear function of both the narrowed front distance and that left+right wall sum, with tuning constants we found empirically.

Evaluation

Without localization there's no ground-truth pose to evaluate against, so we instrumented the controller itself instead and looked at three things: how it reacts to the scan, how cleanly it tracks its own speed targets, and how much safety margin it actually maintains.

Sensor Responsiveness

Plotting target speed vs. front distance and track width over time shows the controller doing what it's supposed to: open up the track and the target climbs, tighten it down and the target drops. Transitions are sharp and they line up with where the corners actually are on the track.

Speed Tracking and Ramping

Target speed and commanded speed don't match exactly, and that's on purpose. We added accel/decel ramping so the car doesn't slam between speeds. Small jumps would otherwise translate into traction loss on the rear wheels.

Safety

Two main safety knobs:

• ›Steering clipped to ±0.4 rad no matter what the PID asks for.
• ›Minimum clearance of 0.3 m. We tuned the speed constants so that under normal track geometry the car never closes inside 0.3 m of the front wall.

Results

Speed and steering both adapt to what the LiDAR sees. Open tracks get fast laps, tight sections get cautious approaches, all without any reliance on a map or a localization pipeline. For a controller this simple, that's a result we're happy with.

What We Tried First: SLAM

Before we landed on the LiDAR-only controller, the plan was a formation-lap-then-race strategy. Map the track once with SLAM, localize against that map on every subsequent lap, run a faster, map-aware policy.

In simulation this worked.

We also got AMCL localization working in the sim. The green dot is the simulator's ground-truth pose, the red dot is what AMCL was predicting from LiDAR alone:

It just didn't survive the move to the real car. Details below.

Challenges

2. SLAM Sim-to-Real Gap

Our simulated SLAM and AMCL stack was working cleanly. On the physical car it wasn't. The sim doesn't capture the actual noise characteristics of the Hokuyo, the actual vibration of the chassis, or the actual latency between scan timestamp and the control loop. Once any of those drift, AMCL's confidence estimate drifts with them. We could not get localization accurate enough to trust on race day.

3. Scan Matching Without Odometry

With full SLAM not working, we fell back to scan-matching-only approaches (Cartographer, SLAM Toolbox). These worked on small tracks where the loop closes quickly, like the CSL studio room:

But on the larger competition track, with longer loops, the map drifted before it could close. That left us with artifacts and a localization estimate that wasn't usable:

This is the point at which we cut our losses and committed to the reactive controller.

Future Work

A few directions where this project could keep going:

• ›Visual odometry. A camera-based odometry source would give SLAM enough of a motion prior to actually close loops on bigger tracks. The D435i is already on the car, it's just unused right now.
• ›Wheel encoders. A real velocity signal from the wheels would close one of the biggest sim-to-real gaps in the stack. The VESC reports something, but it's not clean enough to trust for SLAM.
• ›Map-aware overlay. Once localization is reliable, the reactive controller could be augmented (not replaced) by a global racing line. Reactive for safety, planned for speed.