Applications

RoboRacer Core Kit Use Cases

A 1:10-scale autonomous racing vehicle is one of the few platforms where teaching, competition and publishable research all sit on identical hardware. Here is what each of those looks like in practice.

Use case 01

Universities: teaching autonomy at cohort scale

Autonomous systems teaching has a structural problem. The concepts — state estimation, SLAM, motion planning, control — are best learned on real hardware, but real hardware absorbs the semester. A course that begins with twelve teams assembling twelve vehicles ends with twelve different vehicles, several of which do not work, and a lecturer who has become a hardware technician.

A pre-integrated platform inverts that. Every group starts from a vehicle that already localises and drives, so week one is an algorithms week rather than a wiring week, and a demonstrator's time goes to teaching rather than to fault-finding.

A representative twelve-week structure

  • Weeks 1–2 — ROS 2 fundamentals. Nodes, topics, transforms and ros2 bag on hardware that is already publishing. Students read a live sensor_msgs/LaserScan in their first session.
  • Weeks 3–4 — reactive control. Wall following and follow-the-gap from the raw scan. The first time a student's own code drives a physical vehicle is the moment the course earns its enrolment.
  • Weeks 5–7 — mapping and localisation. Occupancy grids with slam_toolbox or Cartographer, then particle-filter localisation against a saved map.
  • Weeks 8–10 — planning and tracking. Raceline generation, pure pursuit, Frenet-frame local planning, and the practical business of tuning look-ahead against speed.
  • Weeks 11–12 — assessed head-to-head races. A competitive assessment students actually prepare for, on a track the whole cohort has been developing against.

What matters to the department, not just the lecturer

  • Procurement is one line item. A purchase order for an assembled kit clears a finance process that a bill of materials spanning eight international suppliers does not.
  • Results are comparable. Identical builds mean a marking scheme can rest on measured lap times, because the vehicles are not a confounding variable.
  • The skills are transferable. ROS 2, Ubuntu, NVIDIA Jetson, CUDA and SLAM are the tools graduates meet again in autonomous vehicle, drone and warehouse robotics roles.
  • The platform outlives the course. The same vehicles carry final-year projects and master's dissertations without a second procurement round.

Use case 02

Competition teams: RoboRacer and F1TENTH racing

The RoboRacer community — the international autonomous racing programme widely known by its earlier name, F1TENTH — runs head-to-head Autonomous Grand Prix events alongside robotics conferences such as IEEE ICRA and IROS. Entries are 1:10-scale vehicles built to a common specification, racing on a closed circuit with no human in the loop.

A competition season is short, and it is decided by algorithms. Teams that spend the first two months sourcing a VESC and debugging a power tree arrive at the event having tested a controller on the track twice. Starting from a vehicle that already drives moves that budget to where it decides results.

Where a season actually goes

  • Raceline optimisation. Computing a minimum-curvature or minimum-time line for the circuit, then discovering how much of it the vehicle can actually hold.
  • Control at the limit. Pure pursuit is where teams start and rarely where they finish; model-predictive control with an identified tyre model is where the last tenths live.
  • Opponent handling. Detecting and tracking another vehicle in the LiDAR scan, then planning an overtake in the Frenet frame without a collision penalty.
  • Sim-to-real transfer. Training and regression-testing in the f1tenth_gym simulator, then closing the gap between simulated and measured behaviour — the discipline that separates a fast simulator result from a fast lap.
  • Reliability. Races are lost to a loose connector or a brown-out far more often than to a suboptimal planner.
A key hardware feature that competition teams notice is the open-source AE170 power board design, because a team that wants to add a depth camera or a custom board can see exactly what the power tree is doing — the files are published.

Use case 03

Research laboratories: reproducible experiments

Reviewers of robotics and control papers increasingly want a hardware demonstration next to the simulation results, and they want it on a platform other groups can reproduce. A standard 1:10-scale autonomous racing vehicle answers both: it is small enough to run indoors, fast enough to reach the dynamic regimes that make control research interesting, and common enough that a described experiment can actually be repeated elsewhere.

Research directions the platform supports

  • Learning-based control. Reinforcement and imitation learning policies trained in simulation and deployed onboard, with GPU inference on the Jetson's Ampere cores through PyTorch or TensorRT.
  • Model-predictive and adaptive control. Real-time optimisation against an identified vehicle model, at the tyre-friction limit where linearisations stop being honest.
  • State estimation and SLAM. Scan matching, particle filters and sensor fusion between the LiDAR, wheel odometry and the VESC's integrated IMU, evaluated under genuine wheel slip.
  • Multi-agent interaction. Two or more vehicles on one circuit — game-theoretic planning, intent prediction and cooperative or adversarial behaviour.
  • Safety and verification. Runtime monitors, control barrier functions and safe reinforcement learning, demonstrated where a violation is a scuffed bumper rather than a casualty.
  • Sim-to-real methodology. Domain randomisation and system identification studies, with the simulator and the vehicle exposing the same ROS 2 interfaces.

Why the electronics matter to a laboratory

Research vehicles accumulate hardware. The AE170 power distribution unit is designed for that: it takes battery or wall-adapter input and provides regulated 19 V, 12 V and 5 V rails with spare outputs, and its schematic, Gerber, DXF and bill-of-materials files are published as open source. A laboratory adding a depth camera, an external IMU or its own sensor board can design against the real power tree instead of measuring it with a multimeter.

Use case 04

Industry: skills training and applied R&D

Companies building autonomous vehicles, warehouse robots, agricultural machinery or delivery platforms face a hiring and onboarding problem: engineers need to be fluent in ROS 2, sensor integration and real-time control, and a production vehicle is an expensive and slow place to become fluent.

  • Onboarding new engineers. A two-week programme on a 1:10 vehicle teaches the ROS 2 graph, transform trees, sensor timing and the difference between a controller that works in simulation and one that works — at a fraction of the cost of a full-size test vehicle.
  • Algorithm de-risking. Trying a planner or estimator on a small platform before it is scheduled onto a full-size test programme, where a bad week costs a great deal more.
  • Demonstrations and recruitment. A vehicle that races autonomously is a considerably better trade-show exhibit, open-day demonstration or investor demonstration than a slide.
  • Hardware prototyping. With the power board design published, a company can prototype its own sensor or compute module against a known, documented power tree.

Ambimat Electronics has 44 years of electronics design and manufacturing behind it, across wearables, medical devices, home and building automation, contactless payment and robotics. Requirements that go beyond the standard kit are worth a conversation with the team.

The common thread

Different goals, the same bottleneck

A lecturer, a competition captain and a principal investigator want very different outcomes. They lose time to exactly the same three things.

Bottleneck 01

Procurement

Eight or more suppliers, several countries, independent lead times and customs. One late component stalls everything downstream of it, and nothing on the critical path is intellectually interesting.

Bottleneck 02

Integration

Power tree design, connector choice, driver and kernel version conflicts, VESC calibration, LiDAR networking. This work is real engineering — it is simply not the engineering most teams are being funded or assessed to do.

Bottleneck 03

Inconsistency

Vehicles that differ subtly between builds make results incomparable, defeat a marking scheme and turn every regression into an argument about which car it was on.

Order the Core Kit Read the full platform guide