RoboRacer Arena: Specification-Driven Track Construction for Autonomous Racing

arXiv:2608.23040 · cs.RO · Submitted 2026-08-24 · Read on arXiv

Listen

Radio episode about this paper

Transcript

Introduction to the show: ident: Robotics Radio. Generated commentary on the latest robotics and control papers.

Rosa: I'm Rosa, and with me are Dev and Taro, guest researcher.

Dev: Today's paper: "RoboRacer Arena: Specification-Driven Track Construction for Autonomous Racing".

Rosa: The gist The RoboRacer Arena system creates 3D racing environments directly from occupancy maps by using an automated map-to-environment builder that converts ROS occupancy grids into collision-ready,

Dev: First, who's behind it and why it matters.

Title and authors: Rosa: The title itself really sets the stage here because it highlights how they are using a specification-driven approach to build these tracks automatically. It’s about defining what you want, not just dumping a raw map in and hoping for the best.

Dev: Right. They’re focusing on this pipeline where you feed in a natural language description or some other specification, and the system figures out how to construct that specific track geometry from scratch, rather than relying on pre-made assets.

Taro: I think what's interesting is that the goal isn't just creating a pretty picture; it’s about making sure those environments are actually collision-ready and physically plausible for training autonomous agents.

Rosa: That’s right. It’s not just geometry; it involves extracting drivable corridors using a flood fill algorithm to define track boundaries, then calculating a distance field to set the actual collision boundaries, which is how they get that textured USD stage ready for Isaac Sim.

Dev: And the speed at which they do this is something I wanted to focus on—they claim it takes between one point one eight and two point four eight seconds to build these environments, depending on how detailed the raster size is <ref:2608.23040#pg2>.

Taro: That speed matters a lot if you're doing policy training, because you can iterate through thousands of different track layouts much faster than manually modeling them out for every test run.

The paper's summary: Rosa: So, the core of what the paper does is this automated map-to-environment builder. It takes a ROS occupancy grid—which is just a grid showing occupied and free space—and it systematically converts it into something collision-ready with textures and materials for Isaac Sim.

Dev: It’s a whole sequence: they start with flood filling to find the drivable areas, then use a distance field to define those hard collision edges, and finally assemble all that into a USD stage that the simulator can actually read.

Taro: What I find compelling is how they handle the inputs. They aren't limited to just recorded SLAM maps; you can even describe a track in natural language, and they use an AI model to turn that description into a structured TrackSpec without needing exact coordinates or geometry beforehand.

Rosa: That’s right, and then there’s this whole pipeline they have for requirements. It has a parser using Gemma four 31B to pull out the TrackSpec, then a necessary-condition screen that checks if the request is even geometrically possible before any heavy construction starts.

Dev: And then you have the constructive part where they use something called a lattice constructor to grow cells, making sure there are no holes or diagonal contacts, which results in one closed centerline.

Taro: The validation step is key too; they rasterize the grid into an occupancy map M using a ROS map-server grayscale convention—where two hundred fifty-four marks free track cells—and then they have to pass every test on that map M, including lap length and width tests within three percent and five percent of the original specification <ref:2608.23040#pg3>.

The paper's improvements: Rosa: The authors point out a few areas where they’ve improved things, mainly focusing on making the pipeline more robust. They talk about separating the responsibilities into distinct stages—the parser, the screen, the constructor, and the validator—so each part can be tested independently.

Dev: That separation is crucial for engineering; if one piece breaks or gives bad output, you know exactly which stage caused it, rather than having a monolithic builder where everything happens at once.

Taro: They also highlight that they’ve used the lattice constructor because it's more robust than just random sampling when it comes to producing valid outputs. They found that the lattice constructor built fewer maps in twenty-one out of thirty trials, but all those built maps passed validation <ref:2608.23040#pg3>.

Rosa: And they also mention how they integrated the vehicle model configuration from Table I, which includes deployment-specific parameters like the tyre–surface friction of approximately zero point eight three, making sure the simulation results match real-world driving characteristics from recorded data <ref:2608.23040#pg3>.

Dev: That level of detail on the chassis setup is important because it grounds the simulation in reality; you don't just build a generic car, you build *their* car with its specific mass and inertia properties.

Taro: I also noticed they are working toward integrating three-dimensional Gaussian-splat reconstructions for vision-based experiments, which suggests future work on how this environment generation can feed into more complex perception tasks.

Conclusion: Rosa: So to wrap up, the paper "RoboRacer Arena: Specification-Driven Track Construction for Autonomous Racing" shows a system that automates the creation of physics-ready USD environments from occupancy grids in just one point one eight to two point four eight seconds <ref:2608.23040#pg2>.

Dev: It’s a standardized platform that lets you move away from manual asset creation by using recorded SLAM maps, Formula one circuits, or even natural language descriptions to generate tracks on the fly <ref:2608.23040#pg1>.

Taro: What this means for us in autonomy research is that we can quickly test policies across a huge variety of track topologies without the massive overhead of per-track three dee modeling <ref:2608.23040#pg1>.

Rosa: It’s about making the environment generation part of the simulation loop, which should allow researchers to focus more on how agents drive rather than how they build the tracks.

Dev: The system also provides a vehicle model that includes deployment settings measured from physical driving, like a tyre friction value of zero point eight three, which adds necessary fidelity to the simulation results <ref:2608.23040#pg3>.

Taro: The limitation they state is that this current system handles fixed geometry and mass properties defined in Table I, but it’s still focused on those specific chassis configurations right now.

Rosa: Exactly. So "RoboRacer Arena: Specification-Driven Track Construction for Autonomous Racing" gives us a powerful tool for rapidly generating diverse, collision-ready racing environments directly from map data or simple descriptions.

TU Wien · AIT Austrian Institute of Technology

cs.RO

Submitted: 2026-08-24

Updated: 2026-10-08

Comments: Submitted to ICRA 2027

Code: https://github.com/f1tenth/f1tenth

Project page: https://ml4ad.github.io/files/papers2020/Real2sim%3A%

License: http://creativecommons.org/licenses/by/4.0/

Importance score: 83/100

The gist: The gist The RoboRacer Arena system creates 3D racing environments directly from occupancy maps by using an automated map-to-environment builder that converts ROS occupancy grids into

Key concepts

Occupancy Map
This is a grid map created by sensors that shows which areas in an environment are occupied and which are free space. The system uses this map as the starting point to build the 3D track geometry, identifying drivable corridors and boundaries.
Map-to-Environment Builder
This is the core automated tool that takes a raw occupancy grid and converts it into a fully textured, collision-ready 3D model (USD format) suitable for simulation in Isaac Sim. It performs complex steps like flood filling to define track edges and extruding distance fields to create walls.
Requirements Pipeline
This is a multi-stage process designed to reliably turn a natural language request into a valid track design. It involves parsing the text, checking if the requested geometry is physically possible (necessary-condition screen), constructing the track, and finally validating that it meets all specifications.
USD Stage
A USD (Universal Scene Description) stage is a standardized 3D file format used for representing scenes in simulation software like Isaac Sim. The system assembles all the generated track surfaces, textures, collision properties, and materials into this single stage for use in autonomous vehicle research.

Terminology

Summary

The gist The RoboRacer Arena system creates 3D racing environments directly from occupancy maps by using an automated map-to-environment builder that converts ROS occupancy grids into collision-ready, textured USD environments for Isaac Sim in 1.18 s to 2.48 s

System Overview

RoboRacer Arena offers a standardized platform for research using 1:10-scale autonomous vehicles by overcoming the limitations of existing simulators that either omit physical contact or require manual 3D asset implementation The system builds three-dimensional racing environments directly from occupancy maps, starting with a flood fill algorithm to extract drivable corridors and identify track boundaries for establishing barriers The process involves a distance field calculation to define collision boundaries and then assembling the track surfaces, textures, collision properties, and materials into a USD stage for automated generation in Isaac Sim Input maps can originate from SLAM sessions, rescaled Formula 1 circuits, or natural-language descriptions where Gemma 4 31B generates a track specification without specifying coordinates or geometry The system supports the generation of tracks from natural language, and currently contains 130 tracks available for use

Requirements Pipeline

The pipeline separates responsibilities into distinct stages to ensure consistency and reproducibility when generating environments from natural language requests The pipeline includes a requirements parser, a necessary-condition screen, a constructive track generator, and a raster-level validator The parser uses Gemma 4 31B to extract a typed TrackSpec from the natural language input while constraining the output to the fixed schema The necessary-condition screen rejects requests that violate geometric bounds, such as checking if minimum radius or lap length constraints are met before construction begins This screening stage ensures that only geometrically feasible requests proceed to the next deterministic construction phase

Track Construction and Validation

The core of the track construction involves a programmatic builder that converts any supported grid into textured, collision-ready USD geometry The process begins by isolating the drivable corridor from the occupancy grid using flood filling, which removes exterior and infield areas for thin-line maps Collision boundaries are defined by a level set of the free-space distance field, which are then extruded into invisible wall meshes The lattice constructor grows a connected square-lattice cell set while forbidding holes and diagonal contacts, with its outer boundary yielding one closed centreline C Rasterisation converts this grid into an occupancy map M using ROS map-server grayscale convention where 254 marks free track cells Acceptance requires the resulting map M to satisfy every raster-level test, including lap length and width within 3 % and 5 % of the specification S

Evaluation and Performance

The evaluation demonstrates the system's efficiency across various inputs, showing that every evaluated map becomes a physics-ready USD stage in a time range of 1.18 s to 2.48 s The platform supports the generation of tracks from recorded SLAM maps, Formula 1 circuits at 1:10 vehicle scale, and natural-language requirements In benchmark tests, the system attains 8,707 vehicle-steps per second when using 256 parallel rigid-body vehicles The track supply capability allows users to avoid per-track 3D modelling and asset import by accepting recorded maps or rasterising circuit geometry at 1:10 scale The constructor comparison shows that the lattice method builds fewer maps than baselines but produces the most valid trials, with all built maps passing validation

Conclusion

RoboRacer Arena successfully builds three-dimensional racing environments from recorded maps, circuit geometry, and track specifications through a common occupancy-grid interface that produces collision-ready USD stages in 1.18 s to 2.48 s The system provides an automated map-to-environment builder and a requirements-to-track pipeline whose components are independently testable The platform enables the generation of tracks from natural language, and the lattice constructor produces a valid map in 21/30 trials and all 21 built maps pass validation Ongoing work extends the platform with three-dimensional Gaussian-splat reconstructions for vision-based experiments The intended release includes the builder and 130 simulation-ready tracks with source and licence provenance

--- Page 1 ---

RoboRacer Arena offers a standardized platform for research using 1:10-scale autonomous vehicles, but the variety of available tracks hinders the process of acquiring policies Although existing occupancy-grid simulators allow for the quick addition of new maps, they fail to include physical contact, while 3D simulators require each circuit to be implemented as a separate asset, thus limiting their scalability In order to overcome this issue, we have developed RoboRacer Arena, a system that creates 3D racing environments directly from occupancy maps Our method starts by using a flood fill algorithm to extract the drivable corridors and to identify the track boundaries, which are then used to establish the barriers A distance field is calculated to define the collision boundaries The track surfaces, textures, collision properties, and materials are assembled into a USD stage, which allows for the automated and reproducible generation of the environment in Isaac Sim The input maps can be obtained from SLAM sessions, from rescaled Formula 1 circuits, or from natural-language descriptions When the input is based on natural language, we use Gemma 4 31B to generate a track specification without specifying any coordinates or geometry To guarantee consistency and reproducibility, we apply geometric screening, procedural generation, and rasterlevel validation The simulation environments are initialized in a time range of 1.18 to 2.48 seconds, with the initialization time increasing linearly as the raster size increases In 30 matched trials involving 10 tracks and 3 seeds, 21 maps were generated and all passed validation RoboRacer Arena currently contains 130 tracks and supports the generation of tracks from natural language In benchmark tests, the system attains 8,707 vehiclesteps per second when using 256 parallel rigid-body vehicles, excluding the time taken for rendering and policy execution

--- Page 2 ---

vehicle-recorded SLAM maps, Formula 1 circuits at 1:10 vehicle scale

A programmatic builder converts any supported grid into textured, collision-ready USD geometry The natural-language pipeline separates responsibilities: a local model extracts a typed TrackSpec, a necessary-condition screen rejects requests that cannot fit, a deterministic constructor proposes geometry, and a validator remeasures the raster before acceptance The platform also instantiates a configurable model of the standard Traxxas-based RoboRacer chassis We distinguish its fixed geometry and mass properties, configurable deployment settings, and measured operating envelope from 62.4 min of physical driving The contributions of this work are:

  1. An automated map-to-environment builder that converts ROS occupancy grids into collision-ready, textured USD environments for Isaac Sim in 1.18 s to 2.48 s across an 82-fold raster-size range (Sec. IIIC) 2) A requirements-to-track pipeline whose language extraction, necessary-condition screening, deterministic construction, and raster-level validation are independently testable (Sec. IV) 3) An integrated RoboRacer simulation and track library comprising a parameterised 1:10 vehicle, 130 simulation-ready tracks, and parallel-physics measurements up to 2048 vehicles (Secs. III-B and V-C) We recorded 51 distinct SLAM maps at several RoboRacer competitions and racing or testing sessions Another 23 are unmodified ROS maps redistributed with permission from the GPL-3.0 F1TENTH racetracks collection [9] Our rasterisation pipeline adds 44 OpenStreetMap-derived circuits at 1:10 scale, comprising 25 from the TUM racetrack database and 19 from a public Formula 1 GeoJSON collection [10], [11] The remaining 12 tracks are generated from requirements The Formula 1 circuit sources retain the Open Database Licence

--- Page 3 ---

(a) SLAM map from the 27th RoboRacer Autonomous Racing Competition.

(b) Automatic Isaac Sim reconstruction.

(c) Requirement-generated track. (d) Interlagos at 1:10 vehicle scale.

Fig. 2: Three inputs, one environment representation. (a) A recorded competition map.(b) Its collision-ready reconstruction, built in 1.18 s.(c) A map for “three hairpins and one chicane within a 20 × 15 m hall.” (d) A Formula 1 circuit at 1:10 vehicle scale.

Improvements for AI systems

  1. Adapt policy training to leverage diverse environments generated by RoboRacer Arena, as diversity materially affects generalisation to held-out environments [4], [5], allowing for robust learning across varied track topologies.

  2. Implement a requirements-to-track pipeline where the local LLM extracts requirements, while the necessary-condition screen, geometry construction, and maplevel validation remain deterministic, ensuring that generated tracks adhere strictly to specified geometric bounds like 2πrmin ≤ L ≤ Lmax.

  3. Utilize the automated map-to-environment builder to create physics-ready USD stages in 1.18 s to 2.48 s across an 82-fold raster-size range, enabling rapid generation of simulation assets from SLAM maps or natural language descriptions for policy testing.

  4. Integrate the Gemma 4 31B model into the pipeline to perform semantic extraction only of track specifications, ensuring it generates a TrackSpec that is schema-constrained and passes a rigorous necessary-condition screen.

  5. Employ the lattice constructor or DE constructor for track generation, as they are more robust than random sampling in producing valid outputs, with the Lattice constructor producing 21 maps, all valid in 30 trials.

  6. Incorporate the vehicle model configuration from Table I to account for deployment-specific parameters such as Tyre–surface friction µ ≈ 0.83, ensuring that simulation results accurately reflect real-world driving characteristics recorded in the data.

  7. Use GPU ray casting models for sensing and control, while retaining the sensor model, as this allows controllers to downsample its beams while preserving the necessary interface between simulation and hardware.

Abstract

Learning-based autonomous racing relies on diverse training environments, yet constructing a new track requires geometric design, validation, and simulation-asset generation. This coupling makes track geometry difficult to vary systematically during policy training and evaluation. To address this limitation, we present RoboRacer Arena, a specification-driven pipeline that exposes track geometry as an explicit experimental variable. Starting from natural-language requirements, a seeded coverage-guided constructor generates closed-loop layouts, validates the exported occupancy maps, and automatically builds the corresponding Isaac Sim environments. The same interface admits recorded maps and scaled circuits, yielding an initial reference collection of 130 tracks. Across our evaluation, RoboRacer Arena achieves the highest valid-map generation rate among the tested construction procedures under their respective computational budgets and converts eight benchmark maps into simulation assets in less than 2.5 seconds each. We further reconstruct the RoboRacer vehicle as a CAD and USD asset and use it for parallel residual-policy training and deployment on the physical platform. In physical experiments, policies trained with RoboRacer Arena complete ten consecutive laps at command settings up to four times the nominal training speed. These results demonstrate that explicit track requirements can be connected to validated simulation assets and physical evaluation within a reproducible autonomous-racing workflow.

Sources

Related papers