Getting Started with the RoboRacer Core Kit

Unpack and inspect the vehicle

Lift the vehicle out by the chassis, not by the equipment deck. Check that the LiDAR, the Jetson Orin Nano, the VESC 6 MkIV and the AE170 power board are all seated, that connectors are latched, and that nothing has worked loose in transit.

Charge the 3S battery

Charge the 3S lithium-polymer pack on the supplied balance charger, on a non-flammable surface, and never unattended. For desk work, power the vehicle from a wall adapter through the AE170 board's DC jack instead, so the traction pack is reserved for driving.

Power the vehicle

The AE170 power board has two switches. SW1 selects the source — VJACK for the wall adapter, VBAT for the battery. SW2 is power on and off. Set SW1, then switch SW2 on; the board brings up 19 V for the Jetson, 12 V for the LiDAR and 5 V for accessories. With SW2 off, SW1's position is immaterial to the circuit.

Wheels off the ground for this first power-up. A motor configuration that is still being checked should not be able to launch the vehicle across the room.

Connect to the Jetson

Put the vehicle and your laptop on the same network and open a shell on the Jetson over SSH. Where Software Setup / Technical Support was included, Ubuntu 22.04 LTS with NVIDIA JetPack is already installed and the ROS 2 environment is already configured, so there is no flashing step. Otherwise, flash JetPack and install ROS 2 first.

The credentials and hostname supplied with your vehicle are the ones to use here. Change the password before the vehicle goes onto a shared network.

Verify the ROS 2 graph

Start the vehicle launch file supplied with the kit, then confirm the graph is healthy before trusting anything above it:

You are looking for the LiDAR publishing sensor_msgs/LaserScan at roughly 40 Hz, odometry arriving from the VESC, and a complete transform tree. On the laptop, open rviz2, add a LaserScan display and watch the room appear as a 270° arc of points. If the scan looks right and odometry moves when you push the vehicle, the hardware layer is sound.

Drive under teleoperation first

Before any autonomy, drive manually in an open space. Confirm that steering goes the way you expect, that throttle response is sane, and — most importantly — that the emergency stop works from wherever the operator will be standing.

Agree who holds the stop control before the first autonomous run, and keep that person's only job the stop control.

Build a map with SLAM

Drive slowly around the closed circuit while a SLAM package builds an occupancy grid from the LiDAR scans — slam_toolbox and Cartographer are both well travelled on this platform. Save the map once the loop closes cleanly.

On subsequent runs, localise against the saved map with a particle filter rather than re-mapping. That is what makes lap times comparable between sessions, and it is the foundation every path-tracking controller builds on.

Run a first autonomous lap

Start with a reactive controller that needs only the raw scan — wall following or follow-the-gap — with a conservative speed limit. These are the traditional first algorithms on a RoboRacer / F1TENTH vehicle precisely because they need neither a map nor a localiser, so a failure has only one place to hide.

Record everything:

A recorded run can be replayed against a modified controller offline, which turns a scarce resource — track time — into a repeatable test.

Move to planning, control and learning

With mapping and localisation working, the platform stops being the constraint. The usual progression is pure pursuit path tracking on a recorded raceline, then Frenet-frame local planning for overtaking, then model-predictive control once a vehicle model has been identified from the logs.

Learned policies are trained in the f1tenth_gym simulator and transferred to the vehicle, with inference running on the Jetson's Ampere GPU through PyTorch or TensorRT. Because simulator and vehicle expose the same ROS 2 interfaces, the transfer is a change of machine rather than a rewrite.