AutoDRIVE: Integrated Digital Twin Platform

• AutoDRIVE is a digital twin ecosystem that integrates a devkit, simulator, and testbed for sim2real validation in autonomous driving and smart city management.
• The platform supports hardware-software co-development with ROS, Python/C++, and distributed computing to enable both single and multi-agent research.
• It enables practical use cases such as autonomous parking, behavioral cloning, and cooperative intersection traversal through a unified engineering workflow.

AutoDRIVE is an openly accessible, comprehensive research and education platform for implementing and validating intelligent transportation algorithms pertaining to vehicular autonomy as well as smart city management. In its mature form, it is presented as a tightly integrated digital twin ecosystem comprising the AutoDRIVE Devkit, AutoDRIVE Simulator, and AutoDRIVE Testbed, intended for synergistically prototyping, simulating, and deploying cyber-physical solutions for autonomous driving as well as smart city management. Across the relevant literature, AutoDRIVE is characterized by hardware-software co-development, support for single and multi-agent paradigms through local as well as distributed computing, and explicit support for simulation-to-reality and real-to-simulation workflows (Samak et al., 2022, Samak et al., 2022).

1. Historical emergence and conceptual scope

AutoDRIVE first appears as a platform “envisioned to be an integrated research and education platform for scaled autonomous vehicles and related applications,” with the AutoDRIVE Simulator introduced as a high-fidelity simulator for scaled autonomous vehicles developed atop the Unity game engine (Samak et al., 2021). Subsequent technical reports and ecosystem papers broaden this initial scope from a simulator-centered effort into a full digital twin ecosystem with physical hardware, modular infrastructure, and software-development interfaces (Samak et al., 2022, Samak et al., 2022).

A central feature of this evolution is the shift from a platform primarily targeted at 1:14 scale research vehicles toward a framework explicitly designed to support development, simulation, deployment, and validation across different scales and operational design domains. Later work describes AutoDRIVE as an “integrated digital twin framework” and as a “unified real2sim2real toolchain,” including digital twin representations of Nigel, F1TENTH, Hunter SE, and OpenCAV across 1:14, 1:10, 1:5, and 1:1 scales (Samak et al., 2024, Samak et al., 2024). This suggests a progression from a scaled-vehicle research environment into a broader autonomy-oriented validation framework.

The ecosystem is also framed as a mechatronics platform. In that formulation, autonomous vehicles are treated as multidisciplinary systems composed of mechanical, electrical, electronic, computing, and information sub-systems, and AutoDRIVE is used to support concurrent engineering, multidisciplinary co-design, and virtual, hybrid, and physical verification and validation (Samak et al., 2023). That interpretation situates AutoDRIVE not merely as a simulator or testbed, but as an engineering workflow for system design and validation.

2. Core architecture and software-hardware organization

The canonical AutoDRIVE architecture consists of three tightly coupled components: the Devkit, the Simulator, and the Testbed. The literature repeatedly describes these as a “harmonious trio” or as a “tightly integrated trio” for design, simulation, and deployment (Samak et al., 2022, Samak et al., 2023).

Component	Primary role	Notable capabilities
AutoDRIVE Devkit	Software development	ROS-compatible AD software stack, Python/C++ APIs, Smart City Software Stack, distributed computing
AutoDRIVE Simulator	High-fidelity digital twin	Unity + NVIDIA PhysX, sensor/actuator simulation, modular environments, WebSocket bridge
AutoDRIVE Testbed	Physical validation	1:14 scale vehicle, modular infrastructure, real-world deployment and validation

The Devkit provides the software interfaces needed to connect user algorithms to both simulation and hardware. It supports ROS, Python, and C++ APIs, and in some descriptions includes both an Autonomous Driving Software Stack and a Smart City Software Stack with a Smart City Manager server and web app (Samak et al., 2022, Samak et al., 2022). It is also described as compatible with PyTorch, TensorFlow, and Unity ML-Agents, which is significant because the demonstrated workloads span classical probabilistic robotics, imitation learning, deep reinforcement learning, and centralized smart-city control (Samak et al., 2022).

The Simulator is the digital twin component. It is built atop the Unity engine and relies on NVIDIA PhysX for multi-threaded real-time physics and on post-processing or HDRP for photorealistic rendering (Samak et al., 2022, Samak et al., 2022). It includes a communication bridge that supports bidirectional, real-time data exchange with externally developed autonomy software, including ROS integration through an autodrive_ros_bridge node and direct Python/C++ scripting without middleware (Samak et al., 2022).

The Testbed is the physical counterpart, centered initially on the native 1:14 scale vehicle Nigel and on a modular infrastructure kit. It is presented as a real-world deployment environment rather than a demonstration rig: the same platform is used for autonomous parking, sim2real behavioural cloning, and infrastructure-aware experiments (Samak et al., 2022, Samak et al., 2023).

3. Vehicle, sensor, actuator, and environment models

At the hardware level, the native AutoDRIVE vehicle Nigel is a 1:14 scale Ackermann-steered, rear-wheel-drive modular platform. The hardware descriptions specify two rear DC geared motors, one front steering servo with $\pm 30^\circ$ saturated Ackermann steering, a standard vehicular lighting system, wheel encoders, AprilTag-based indoor positioning, a 9-axis IMU, RPLIDAR A1, and front and rear PiCamera V2.1 units, with computation split between an NVIDIA Jetson Nano and an Arduino Nano (Samak et al., 2022, Samak et al., 2022).

The Simulator reproduces this physical stack in software. The technical report describes simulated throttle and steering sensors, motor encoders, IPS, IMU, 2D LIDAR, and front/rear RGB cameras, together with delayed and saturated drive and steering actuators, lighting logic, and reconfigurable scene modules such as roads, intersections, parking lots, terrain, and obstacles (Samak et al., 2022). The platform is explicitly cross-platform, supporting Windows, Linux, and Mac OS X via Unity (Samak et al., 2022).

Vehicle dynamics are modeled beyond simple kinematics. The sim2real and cross-scale papers describe a combined rigid-body and multiple sprung-mass model, suspension as second-order damped springs,

$${}^iM \cdot {}^i\ddot{Z} + {}^iB \cdot ({}^i\dot{Z}-{}^i\dot{z}) + {}^iK \cdot ({}^iZ-{}^iz),$$

and tire friction curves using cubic splines for slip, with longitudinal and lateral slip defined by

$$S_x = \frac{{}^ir \cdot {}^i\omega - v_x}{v_x}, \qquad S_y = \frac{v_y}{|v_x|}.$$

Ackermann steering angles are computed as

$$\delta_l = \arctan\left(\frac{2l \tan\delta}{2l + w \tan\delta}\right), \qquad \delta_r = \arctan\left(\frac{2l \tan\delta}{2l - w \tan\delta}\right)$$

(Samak et al., 2023, Samak et al., 2024).

The early simulator work also gives the scaled-vehicle turning-radius relation

$R = \frac{L}{\tan(\delta)},$

with a minimum turning radius of $600\,\text{mm}$ for the chassis used in environment design and trajectory planning (Samak et al., 2021). These formulations show that AutoDRIVE was constructed to preserve kinodynamic and actuator constraints that matter for closed-loop autonomy software, rather than treating the simulated vehicle as a purely geometric proxy.

The environment side is similarly modular. The Infrastructure Development Kit includes terrain modules, road kits, parking modules, obstacles, traffic signs, and IoT-enabled traffic lights, while the simulator includes pre-configured maps such as “Parking School,” “Driving School,” “Intersection School,” and “Tiny Town” (Samak et al., 2022, Samak et al., 2022). Later work extends this to synthetic and photorealistic replicas of proving grounds, racetracks, cities, forests, and parking lots across scales (Samak et al., 2024).

4. Development workflow, verification, and sim2real methodology

A defining characteristic of AutoDRIVE is that it is used not only to run autonomy algorithms, but also to structure the engineering lifecycle around them. The mechatronics-oriented paper frames this around an Extended V-model and concurrent engineering, beginning with requirement-driven decomposition into mechanical, electronic, firmware, and software specifications, then proceeding through virtual, hybrid, and physical prototyping and testing (Samak et al., 2023).

Virtual prototyping includes CAD, EDA, model-in-the-loop, software-in-the-loop, and full-system simulation in the AutoDRIVE Simulator. Hybrid prototyping includes processor-, hardware-, and vehicle-in-the-loop configurations, replay of real-world sensor data, and onboard-computer execution against virtual environments. Physical prototyping culminates in full deployment on the Testbed, with unit and integration testing of localization, mapping, planning, and control modules (Samak et al., 2023).

The sim2real formulation is explicit in later work. AutoDRIVE is described as a digital twin ecosystem designed for seamless sim2real and real2sim transfer, with a unified workflow in which the same codebase and modularity are preserved across simulation and reality (Samak et al., 2023). Several mechanisms are emphasized repeatedly: high-fidelity digital twins; deliberate modeling of actuator saturation, delays, and sensor characteristics; domain randomization through observation noise, actuation uncertainty, and environment perturbations; and API consistency between simulated and physical platforms (Samak et al., 2023, Samak et al., 2024).

The real2sim2real Autoware integration work extends this methodology from scaled experimentation to autonomy-stack portability. It describes AutoDRIVE’s ROS 2 APIs, human-machine interfaces, and meta-packages for vehicle-specific configuration, enabling the same Autoware stack to be exercised in simulation and on physical vehicles (Samak et al., 2024). A notable claim in the cross-scale validation paper is that “the exact same controller gains from simulation worked for the real-world deployments” in the demonstrated map-based navigation workflow (Samak et al., 2024).

5. Canonical applications and experimental use-cases

Four use-cases function as the canonical demonstration set for the ecosystem: autonomous parking using a probabilistic robotics approach; behavioural cloning using computer vision and deep imitation learning; intersection traversal using vehicle-to-vehicle communication and deep reinforcement learning; and smart city management using vehicle-to-infrastructure communication and internet-of-things (Samak et al., 2022, Samak et al., 2022).

In autonomous parking, the representative pipeline consists of Hector SLAM for mapping, range-flow odometry plus AMCL for localization, A* for global planning, Timed-Elastic-Band for local trajectory replanning, and proportional controllers for steering and drive commands (Samak et al., 2023). In the mechatronics-oriented study, this same application is used to quantify system-level validation: navigation precision of $\leq 2.5 \times 10^{-2}\,\text{m}$ and parking pose tolerance of $\leq 5 \times 10^{-2}\,\text{m}$ in position and $\leq 8.73 \times 10^{-2}\,\text{rad}$ in orientation, with repeatability assessed through 5-trial mean and standard deviation plots (Samak et al., 2023).

In behavioural cloning, AutoDRIVE is used to collect simulator data, perform augmentation and class balancing, train a 6-layer CNN, and then deploy the learned model on the physical vehicle without changing the core policy (Samak et al., 2023, Samak et al., 2022). The 2023 sim2real paper specifies that 5 laps of human driving were recorded in simulation, the network was trained for 4 epochs with learning rate $1e^{-3}$ using Adam, and the trained model completed multiple successful laps in the physical “Driving School” “without major deviation or collision” (Samak et al., 2023).

In reinforcement learning, AutoDRIVE supports both single-agent and multi-agent settings. The ecosystem paper demonstrates intersection traversal using Unity ML-Agents and PPO (Samak et al., 2022). A later multi-agent reinforcement learning study extends this to cooperative intersection traversal with Nigel and competitive head-to-head racing with F1TENTH, describing the ecosystem as an enabler for physically accurate and graphically realistic digital twins of both platforms (Samak et al., 2023). The same paper emphasizes a decentralized learning architecture, sparse observation spaces, and kinodynamic as well as safety constraints in both cooperative and competitive settings (Samak et al., 2023).

The smart city management use-case highlights the infrastructure side of AutoDRIVE. In this mode, a Smart City Manager server tracks vehicles and infrastructure elements through a real-time database and web app, and the vehicle can accept direct actuation commands from centralized infrastructure logic, bypassing onboard perception and planning for V2I and IoT experiments (Samak et al., 2022, Samak et al., 2022).

6. Cross-scale expansion, Autoware integration, and terminological boundaries

Later work generalizes AutoDRIVE from a scaled-vehicle ecosystem into a validation framework spanning multiple spatial scales and distinct ODDs. The integrated digital twin framework paper describes four vehicle digital twins—Nigel, F1TENTH, Hunter SE, and OpenCAV—spanning 1:14, 1:10, 1:5, and 1:1, and targeting autonomous parking, autonomous racing, off-road navigation, and full-scale parking scenarios (Samak et al., 2024). The same literature states that the framework was demonstrated with Autoware Core/Universe, with vehicle-specific overlays and meta-packages, and includes what is described as the first-ever off-road deployment of the Autoware stack (Samak et al., 2024, Samak et al., 2024).

This cross-scale expansion is conceptually important because it shifts AutoDRIVE from a platform for “scaled autonomous vehicle research and education” to a system for validating autonomy software stacks “across scales and operational design domains” (Samak et al., 2021, Samak et al., 2024). A plausible implication is that AutoDRIVE’s most distinctive contribution lies less in any single simulator or vehicle and more in the preservation of interfaces, abstractions, and calibration practices across virtual and physical embodiments.

The name, however, requires careful disambiguation. “A-DRIVE,” as in “A-DRIVE: Autonomous Deadlock Detection and Recovery at Intersections for Automated Vehicles,” denotes a decentralized deadlock recovery protocol and is not the AutoDRIVE ecosystem (Aoki et al., 2022). Likewise, the SAE AutoDrive Challenge literature—such as the Zeus system descriptions, the object tracking system aUToTrack, and the traffic-light system aUToLights—concerns competition vehicles and perception stacks developed for the collegiate challenge rather than components of the AutoDRIVE ecosystem (Burnett et al., 2018, Burnett et al., 2019, Burnett et al., 2020, Wu et al., 2023).

A further source of ambiguity is that “AutoDrive” also appears in the titles of later autonomous-driving VLM and VLA papers, including “AutoDrive-QA” (Khalili et al., 20 Mar 2025), “AutoDrive-P$${}^iM \cdot {}^i\ddot{Z} + {}^iB \cdot ({}^i\dot{Z}-{}^i\dot{z}) + {}^iK \cdot ({}^iZ-{}^iz),$$0” (Ye et al., 30 Mar 2026), “VLM-AutoDrive” (Bhat et al., 18 Mar 2026), “AutoDriveRL” within “DriveRX” (Diao et al., 27 May 2025), and “AutoDrive-R$${}^iM \cdot {}^i\ddot{Z} + {}^iB \cdot ({}^i\dot{Z}-{}^i\dot{z}) + {}^iK \cdot ({}^iZ-{}^iz),$$1” (Yuan et al., 2 Sep 2025). These works address multiple-choice evaluation, structured perception-prediction-planning reasoning, post-training for safety-critical event detection, reinforcement learning for cross-task reasoning, and reasoning-plus-self-reflection for VLA models, respectively. They share nomenclature with AutoDRIVE, but the ecosystem literature identifies AutoDRIVE itself as the integrated Devkit-Simulator-Testbed platform centered on digital twinning, mechatronic development, and sim2real validation (Samak et al., 2022, Samak et al., 2024).