Source-linked AI summary
RoboRacer Arena: Scaling High-Fidelity Autonomous Racing in Isaac Sim
Mihaela-Larisa Clement, Agnes Poks, Ezio Bartocci
TL;DR
RoboRacer Arena addresses the limited scalability of physically rich racing simulation by generating three-dimensional Isaac Sim environments directly from occupancy maps. Its common interface combines recorded, circuit-derived, and natural-language inputs with deterministic screening, construction, and validation. The system contains 130 tracks, builds valid maps in 21/30 lattice trials, and reaches 8707 vehicle-steps per second with 256 rigid-body vehicles.
Problem
Existing occupancy-grid simulators add maps efficiently but omit physical contact, while 3D simulators require separate hand-modelled assets for each track.
Method
RoboRacer Arena converts recorded, circuit-derived, and language-specified occupancy maps into collision-ready USD environments using deterministic geometry construction and raster validation.
Results
130 tracks are included; the lattice constructor produced 21 valid maps in 30 matched trials, and throughput reached 8707 vehicle-steps per second with 256 rigid-body vehicles.
Takeaways & Limitations
The platform provides a shared, inspectable route from varied track inputs to reproducible physics-ready environments for RoboRacer simulation.
Takeaways & Limitations
The planar constant-width map representation does not yet model elevation, surface transitions, continuously varying width, or grade-separated crossings.
Abstract
from arXiv · showhide
RoboRacer 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, 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 raster-level 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 vehicle-steps per second when using 256 parallel rigid-body vehicles, excluding the time taken for rendering and policy execution.
I. INTRODUCTION
RoboRacer Arena addresses the trade-off between scalable map variation and physically rich simulation by generating Isaac Sim racing environments directly from occupancy maps. It unifies recorded, circuit-derived, and language-specified tracks while making the generation pipeline reproducible and testable.
- RoboRacer combines standardized 1:10 vehicles with dynamics exposing tyre interaction, steering limits, sensing, and control latency for repeatable experiments.
- Existing simulators either load occupancy maps efficiently without three-dimensional contact or require hand-modelled, simulator-specific 3D assets.
- RoboRacer Arena converts vehicle-recorded SLAM maps, 1:10 Formula 1 circuits, and natural-language requirements into a common occupancy-grid representation.
- A programmatic builder turns supported grids into textured, collision-ready USD geometry, while language generation separates extraction, screening, construction, and validation.
- 1.18 s to 2.48 s: the automated builder converts ROS occupancy grids into collision-ready, textured USD environments across an 82-fold raster-size range.
- The release integrates a parameterised 1:10 vehicle and 130 simulation-ready tracks, including SLAM, redistributed, OpenStreetMap-derived, and requirements-generated tracks.
II. RELATED WORK
Related work supplies scalable occupancy-map simulation, richer 3D environments, procedural generation, and language-conditioned robotics, but RoboRacer Arena combines these directions through a common racing-specific map interface and deterministic validation.
- RoboRacer research uses diverse tracks because learning-based control results depend on generalisation beyond a single training configuration.
- Occupancy grids are standard mobile-robotics representations, and prior systems convert them into Gazebo or urban simulation environments.
- RoboRacer Arena extends map-based construction with racing-specific floor and barrier meshes, collision properties, and material bindings.
- Procedural track generation supports domain randomisation and reinforcement-learning benchmarks, while language-conditioned systems generate tasks or scenes from semantic requests.
- A natural-language request is represented by a typed 12-field specification, and recorded, constructed, and Formula 1 maps enter simulation through the same ROS occupancy representation.
- Acceptance means the finished map passes every raster-level test; rejection indicates a violated necessary geometric bound, whereas generation failure does not prove infeasibility.
B. Vehicle Model and ROS 2 Interface
The platform programmatically instantiates a configurable Traxxas-based RoboRacer vehicle, sensors, and ROS 2 interfaces in Isaac Sim, with measurements characterising its physical operating envelope.
- Vehicle–track instances are created through physics configuration, environment loading, vehicle and sensor instantiation, and ROS 2 bridge startup.
- The standard Traxxas-based 1:10 chassis separates static hardware parameters from deployment settings and observed driving statistics.
- 62.4 min of competition recordings provide 149 362 lidar scans and 187 043 odometry messages for the operating-envelope observations.
- 6.66 m s−1: the recorded vehicle reaches this speed, while its predominant speed range is 1.5 m s−1 to 5 m s−1.
- µ ≈0.83: deployment tyre–surface friction is configurable and estimated from a lateral pull test.
- GPU ray casting models the physical lidar, and the ROS 2 bridge preserves odometry, transforms, simulation time, and Ackermann commands across simulation and hardware.
C. From Occupancy Grid to USD
RoboRacer Arena converts occupancy grids into collision-ready USD stages by separating visual geometry from distance-field collision geometry. Requirements follow parsing, geometric screening, deterministic construction, and raster-level validation before acceptance.
- Flood filling isolates the drivable corridor and removes exterior and infield regions from thin-line maps before boundary extraction.
- Smoothed borders generate visual barrier tubes, while a free-space distance field defines collision boundaries extruded into invisible wall meshes.
- The resulting metre-scale USD stage binds configurable floor and barrier materials, compliance, texture, colour, and geometry.
- Recorded layouts, controlled requirements, and scaled Formula 1 geometry provide alternative environment sources through four requirements stages.
- Gemma 4 31B extracts a fixed 12-field TrackSpec, supplying semantics while leaving coordinates, topology, and the centreline to deterministic stages.
- The admissibility screen uses requested radius, wall thickness, clearance, hall margin, constructor radius, pitch, and lap capacity before raster validation.
- For a 200 m lap in a 20×15 m hall, the default p = 2.15 m gives Lmax ≈123.7 m, causing immediate rejection; passing the screen does not ensure construction.
B. Lattice Construction and Raster Validation
The lattice constructor grows connected track geometry, rasterises it using ROS occupancy values, and accepts only maps that pass external raster-level checks.
- Construction: The lattice constructor grows a connected square-lattice cell set while forbidding holes and diagonal contacts, then derives a closed centreline.It resamples, scales, rotates, and tests candidates for hall fit, self-clearance, and curvature-based feature counts.
- Rasterisation: Rasterisation assigns free, occupied, and unknown cells using distance to the centreline, corridor width, wall thickness, and a half-cell correction.The resulting values follow the ROS map-server grayscale convention: 254 free, 0 occupied, and 205 unknown.
- Validation: The pipeline accepts a candidate only when its raster map satisfies connectivity, infield, geometric tolerances, feature counts, clearance, hall fit, order, and longest-straight checks.The validator measures the raster map M rather than the analytic curve C.
- Pipeline: The bounded algorithm parses q, screens the specification, constructs up to 800 candidates, rasterises each candidate, validates it, and returns either a valid map, rejection, or generation failure.A candidate is returned immediately after validation succeeds; otherwise the bounded search ends in generation failure.
C. Formula 1 Circuits at 1:10 Vehicle Scale
The Formula 1 library converts scaled circuit geometries into 1:10 RoboRacer tracks while preserving their proportions and smoothing closed-loop centreline paths.
- Source geometry: 44 OpenStreetMap-derived circuits are converted, using measured TUM centreline widths for 25 tracks and constant-width Formula 1 centreline metadata for 19.All geometries are uniformly reduced to one tenth of full-scale dimensions for the 1:10 RoboRacer vehicles.
- Geometry processing: A periodic cubic spline smooths and resamples each closed circuit loop before environment construction.
A. Map Building and Circuit-Library Accuracy
The system builds a broad circuit library and evaluates both map-conversion fidelity and natural-language requirements processing, with raster validation separating valid outputs from raw construction attempts.
- Map building: 1.18 s to 2.48 s is the build-time range for physics-ready USD stages across an 82-fold raster-size range.Single-threaded build time changes only 2.1-fold over that range.
- Library properties: All 44 maps contain one connected free corridor, while 1:10 lap lengths span 229.36 m to 699.84 m and mean corridor widths span 0.919 m to 1.588 m.The library generation time is 43.72 s.
- Accuracy: Width correction affects four circuits and at most 8 % of any loop, with centreline-length error averaging 0.253 % and peaking at 0.924 % relative to scaled input geometry.Suzuka is distributed with its centreline because planar mapping loses its grade separation.
- Parser evaluation: Four of six local models parse all 12 requirements exactly, while three avoid invented constraints across all 51 audit calls.The parser evaluation uses exact 12-request parsing followed by a 51-call invention audit.
- Parser selection: Gemma 4 31B is selected because it ties the best accuracy and restraint among evaluated parser models.
- Constructor comparison: 21 lattice maps are built and all are valid, compared with 27 DE maps of which 15 are valid and 30 random-sampling maps of which 11 are valid.The comparison concerns raw constructor outputs before the final validator; the complete pipeline never returns an invalid output.
- End-to-end evaluation: Six of eight end-to-end natural-language requests are accepted; one is rejected by the screen and one reaches bounded-search generation failure.The two unsuccessful requests terminate before map return, distinguishing proven rejection from failed candidate search.
C. Track Supply and Simulation Throughput
RoboRacer Arena separates track supply from simulation throughput, combining scalable map-based track creation with contact-physics benchmarking under explicitly defined workloads.
- Measurement scope: Track-supply comparisons are direct, whereas throughput comparisons retain each simulator’s documented workload.The table distinguishes environment availability from simulation performance.
- Simulation throughput: 4942 steps per second are measured for one planar F1TENTH Gym vehicle without rendering or three-dimensional contact.This workload differs from RoboRacer Arena’s contact-physics benchmark.
- Simulation throughput: 62.5 agent-steps per second is the reported AutoDRIVE throughput from a training run that includes rendering and policy updates.The documented workload is not directly matched to the other throughput measurements.
- Simulation throughput: 8707 vehicle-steps per second are achieved with 256 parallel rigid-body vehicles when rendering and policy execution are excluded.Aggregate throughput is 8368 at 1024 vehicles and 6818 at 2048.
- Track supply: 130 simulation-ready tracks are supplied through workflows that accept recorded maps, rasterised Formula 1 geometry, or requirements-based construction.RoboRacer Arena avoids per-track 3D modelling and asset import, unlike AutoDRIVE.
VI. SCOPE AND LIMITATIONS
RoboRacer Arena’s current representation is planar and supports collision geometry without reconstructing complete venue appearance, while its evaluations cover bounded workloads.
- Representation scope: The occupancy grid supplies track shape and collision geometry but not a complete visual reconstruction of the venue.Generic materials support lidar and contact-based experiments; Gaussian splatting is ongoing work for camera appearance.
- Geometric scope: Elevation, surface transitions, continuously varying width, and grade-separated crossings remain outside the current planar, constant-surface-and-width representation.Grade-separated crossings collapse to planar overlaps.
- Evaluation scope: Throughput values are not a matched learning benchmark because rendering, policy, vehicle, and parallelism workloads differ.The reported language results are also bounded to 12 parser requests, 51 invention-audit calls per advanced model, and eight end-to-end requests.
VII. CONCLUSION
RoboRacer Arena provides a common occupancy-grid route from diverse inputs to collision-ready USD stages, with inspectable validation and scalable rigid-body simulation. The release includes 130 tracks and reports bounded generation, geometric, and throughput results while identifying vision and matched-control evaluation as ongoing work.
- Contribution and results: 1.18 s to 2.48 s is the initialization range for collision-ready USD stages generated from recorded maps, circuit geometry, and track specifications.The common occupancy-grid interface supports all three input sources.
- Contribution and results: 130 tracks are released with a configurable vehicle model, including 44 Formula 1 circuits at 1:10 scale averaging 0.253 % centreline-length error.The lattice constructor produced valid maps in 21/30 trials, and all 21 built maps passed validation.
- Contribution and results: Independent language extraction, screening, construction, and raster validation make generation success and refusal inspectable.The conclusion presents these stages as independently testable parts of the requirements-to-track pipeline.
- Future work: Ongoing work extends the platform with Gaussian-splat reconstructions for vision experiments and matched reinforcement-learning and MPC comparisons across simulators and the physical vehicle.These extensions are intended to compare learning and closed-loop behaviour across the supported settings.