TIER IV Releases Open Autoware Racing-Kart Stack With Simulator and Real-Vehicle Workflow


TIER IV has released the Autoware-based reference design used for the 2026 Autonomous Driving AI Challenge, exposing the autonomous-driving software, simulator and vehicle-integration material in a public GitHub repository. The platform supported 240 teams and about 600 participants during qualifying and final rounds held from July through September 2026.

The release provides a reproducible development path from simulation to a physical racing kart. Its public repository combines Autoware Universe, AWSIM simulation, ROS 2 tooling, Docker-based development, evaluation scripts and interfaces for the real vehicle. TIER IV says the competition hardware combined a TOM'S EV racing kart, GNSS, an IMU and an onboard computer.

For robotics developers, the useful artifact is the complete integration environment: teams can build and evaluate autonomous-driving logic against a shared simulator, then move qualifying software toward the real-vehicle interfaces used in the competition finals.

What TIER IV released

TIER IV's September 24 announcement describes four parts of the reference design:

Component Published scope
Vehicle and hardware TOM'S EV racing kart, GNSS, IMU and onboard computer
Autonomous-driving software Open-source racing-kart software based on Autoware
Simulation Public racing-kart simulator plus the competition evaluation environment
Development and evaluation Tools for setup, execution and review of driving results

The public AutomotiveAIChallenge/aichallenge-racingkart repository provides the software and documentation. Its README describes the qualifying workflow as integrating Autoware Universe-based autonomous-driving software into an end-to-end simulated racing kart, with finalists moving their software to the physical kart.

The repository is licensed under Apache-2.0.

The development stack

The repository's current development layout is more substantial than a sample planning node or isolated ROS package. It separates simulation, vehicle, remote-access and submission workflows into dedicated top-level areas.

The documented Docker Compose environment includes:

  • an Autoware service and separate colcon build service;
  • AWSIM for the racing-kart simulation;
  • ROS 2 command tooling for service and topic operations;
  • Zenoh bridging;
  • a real-vehicle driver service;
  • RViz2 for visualization;
  • an optional NVIDIA GPU Compose overlay; and
  • an optional PulseAudio overlay for the simulator.

The setup tooling can detect whether a GPU is available and generate the corresponding Compose configuration. The documented bootstrap flow installs or prepares the environment, downloads AWSIM and pulls the Autoware base image before the workspace build and development loop.

A representative setup sequence from the project is:

./setup.bash bootstrap
./docker_build.sh dev
make autoware-build
make dev

Developers should use the repository's current setup documentation when deploying the stack because its scripts, images and competition interfaces can change independently of this article.

Simulation and physical-vehicle integration share one project

The repository organizes simulator and real-kart work in the same project. aichallenge/ contains simulator, Autoware and evaluation launch/operation scripts, while vehicle/ contains real-vehicle setup checks, Zenoh and rosbag-related material. A separate remote/ area covers SSH, Zenoh, RViz and joystick-assisted remote workflows.

That structure matters for autonomous-systems development because the transition from a simulated planner to a physical platform introduces interfaces, networking, sensor data, timing and operational checks that a simulator-only example cannot exercise.

TIER IV says the September 19–20 final rounds included both simulation-based and real-world racing-kart challenges. The same reference design had already been used as the common technical foundation across 240 teams, giving the public project evidence of use beyond a newly published demo repository.

Where AI development fits

The platform gives teams a common vehicle and software baseline while leaving room to develop autonomous-driving algorithms and AI models. In practice, that makes it relevant to researchers and engineering teams that want an Autoware-based environment without assembling the entire vehicle/simulation toolchain first.

The release is also useful for studying the interfaces around an autonomy model. Perception or planning code still has to coexist with localization, vehicle control, middleware, simulation, logging and evaluation. The repository exposes those surrounding systems in a form that can be inspected and modified.

The competition's real vehicles and hosted online evaluation environment were supplied as part of the event. Public availability therefore covers the repository's software, simulator and design information; reproducing the competition's complete physical test environment still requires compatible hardware and infrastructure.

Who should use it

The strongest fit is developers already working with ROS 2, Autoware or autonomous-robotics simulation, plus university and training teams that need a concrete autonomy stack with an eventual path to real hardware.

For newcomers, the Docker-based setup and published documentation reduce the amount of integration work required before experimenting with planning and autonomy logic. For experienced teams, the project is a reference implementation for connecting Autoware, AWSIM, evaluation tooling and a compact EV platform.

The project should be treated as a development and competition reference environment, with safety engineering and validation appropriate to any physical vehicle deployment. The public materials provide an unusually complete starting point for learning and experimentation because the stack was exercised by hundreds of competition participants before TIER IV's September release announcement.

Sources