karl. -- A Research Vehicle for Automated and Connected Driving

Bastian Lampe; Guido Linden; Jean-Pierre Busch; Lennart Reiher; Lukas Ostendorf; Lutz Eckstein; Till Beemelmanns; Timo Woopen

REVIEW 4 major objections 5 minor 23 references

karl. -- A Research Vehicle for Automated and Connected Driving

T0 review · 4 major / 5 minor · reviewed 2026-08-03 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read The paper argues that a single retrofitted plug-in hybrid van, named karl., can serve as a complete L4-capable research platform for automated and connected driving, and provides a detailed hardware blueprint so other labs can build one.

desk verdict A detailed, honest engineering blueprint for an academic L4 research vehicle—though the L4 capability claim outruns the static, component-level evidence. read the letter →

arxiv 2602.08842 v3 pith:ISWIBHG2 submitted 2026-02-09 cs.AR cs.ROcs.SYeess.SY

Jean-Pierre Busch , Lukas Ostendorf , Guido Linden , Lennart Reiher , Till Beemelmanns , Bastian Lampe , Timo Woopen , Lutz Eckstein This is my paper · ORCID

classification cs.ARcs.ROcs.SYeess.SY

keywords automateddrivingresearchvehiclesensorfusionPTPclocksynchronizationdrive-by-wire360-degreeperceptionC-ITSL4

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The authors set out to show that a capable Level 4 automated-driving research vehicle does not require a purpose-built platform or corporate budget: a production plug-in hybrid van, fitted with a roof-mounted sensor rack, a cabin compute rack, and a drive-by-wire interface, can cover the full sensing, compute, communication, and actuation needs of autonomous driving research. They document every design choice so that other institutions can replicate or adapt the vehicle. Measured results back the claim: sub-200 nanosecond clock synchronization across compute nodes, redundant 360° sensor coverage, about 4.5 hours of full-load operation on the auxiliary battery, and longitudinal control that respects ISO 15622 acceleration limits. If the platform works as described, it closes a gap that currently limits independent academic research in automated driving.

What carries the argument

The central object is the vehicle's integrated hardware architecture: a two-tier Ethernet network that aggregates all rooftop sensors at an edge switch and connects them to a cabin core switch, with a GNSS-disciplined INS serving as the IEEE 1588 PTP grandmaster. This single time-synchronization backbone is what makes the redundant 360° multi-modal sensor suite fuseable into one consistent world model; the drive-by-wire interface, built from the stock parking assist and ACC, is the second load-bearing piece, turning sensor and planning outputs into physical vehicle motion.

What would settle it

Drive karl. over a rough road or through temperature changes while continuously logging PTP offset between the HPC, embedded computers, and lidars, and recompute camera-lidar reprojection error during the drive; if mean PTP offset exceeds the sub-200 ns range or reprojection error grows beyond the at-rest values, the core claim of a ready L4 sensor platform fails.

Watch

Extended reading notes

Core claim

On its own terms, the paper's core claim is that karl. fulfills 'many required core capabilities' of an L4 research vehicle while remaining modular, extensible, and reproducible. The vehicle combines eight stereo cameras, four corner-mounted rotating lidars, one forward FMCW lidar, and seven radars to achieve redundant 360° coverage; a GNSS-disciplined INS acts as PTP grandmaster to synchronize all compute and PTP-capable sensors below 200 ns mean offset; and a drive-by-wire system built on the stock parking assist and adaptive cruise control provides lateral curvature control and longitudinal acceleration control within ISO 15622 limits. The evaluation also reports 72 ms mean latency for ro

Load-bearing premise

The paper assumes that calibration and clock synchronization measured at rest remain valid during dynamic driving; if vibration, temperature, or motion degrade them, the redundant 360° perception that the L4 claim depends on would be compromised.

Editorial extensions

If this is right

Other research groups can build a comparable L4 testbed from a production hybrid van plus commercially available sensors, computers, and networking gear, following the paper's parts list and layout.
The sub-200 ns PTP offsets across the HPC and embedded computers mean that sensor streams from different modalities can be fused and replayed with timestamps accurate enough for object-level fusion.
The 4.5-hour full-load power budget enables full-day test campaigns with periodic charging from the vehicle's hybrid system, not just short demonstrations.
Drive-by-wire behavior within ISO 15622 limits gives a safety argument that a safety driver can override and that emergency braking demands are met.
With the AD stack containerized and deployable, the same vehicle can switch between stock, shadow, and automated modes, making it usable for data collection and public-road testing once approval is granted.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

If the blueprint is as replicable as claimed, the main bottleneck for new labs shifts from vehicle acquisition to software stack maturity; the paper leaves the AD stack itself for a future publication.
The choice of end-to-end PTP without transparent clocks may become a scaling limit as more PTP-capable sensors are added; a transparent-clock topology would be a natural next step.
The static-only calibration and 3-minute clock measurement suggest the next decisive experiment is dynamic validation: measuring PTP offset and lidar-camera reprojection error during real driving, vibration, and temperature swings.
A testable extension would be to publish calibration and timing data from a public-road drive, letting others verify whether the at-rest accuracies persist under motion.

Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

Short version: this is one of the better “here is our research vehicle” papers I’ve read. It’s a detailed, honest engineering report that gives a lab considering an L4 platform a genuinely useful blueprint. The hardware choices are well reasoned, the two-tier Ethernet architecture is clearly described, and the measurements that are included—PTP offset, sensor latency, power budget, drive-by-wire tracking—are direct and credible. The authors also deserve credit for being explicit that the AD software stack is out of scope and that public-road approval is pending. That framing keeps the overreach modest.

What’s actually new: the specific combination of a VW T7 Multivan, four Ouster OS1s, an Aeva Aeries II, eight ZED X cameras, a radar array, and the dual-tier network with PTP is not documented elsewhere. EDGAR uses the same base vehicle, so this is an incremental extension of an established genre, but it is a concrete new instance with enough detail to reproduce.

Where the soft spots are, in proportion: the main gap is the step from static, component-level validation to the claim that the vehicle “fulfills many required core capabilities” for L4. PTP offsets were measured over three minutes at standstill; calibration is shown only at rest; and the front FMCW lidar, a key velocity sensor, is synchronized via NTP from the HPC, yet no NTP accuracy measurement appears anywhere in Section V. During driving, vibration, thermal drift, and network load can change both clock offsets and extrinsics. Without dynamic validation or a closed-loop test of the perception-to-control chain, the L4-capability claim is not established. That said, this is an engineering report, not a scientific derivation. The hardware claims mostly hold up; the authors are careful in most places. The conclusion does extrapolate, so the appropriate fix is either to soften “fulfills many required core capabilities” to something like “provides the hardware basis for” or to add a dynamic calibration/timing evaluation.

The citation pattern is fine. Related work covers the comparable platforms, and self-citations are to relevant prior work.

Who this is for: labs that want to build their own research vehicle, or groups that need a reference point for sensor fusion hardware. It’s not a paper that changes scientific understanding.

Recommendation: send it to peer review. It’s a legitimate systems contribution that will be useful to a specific community. The reviewers should ask for a more careful statement of what is validated, and ideally some dynamic timing/calibration data, but the paper is solid enough to warrant the round trip.

Referee Report

4 major / 5 minor

Summary. The paper presents karl., a research vehicle for automated and connected driving built on a Volkswagen T7 Multivan hybrid. It documents the hardware design in detail: auxiliary power, roof-mounted sensor rack with cameras, four rotating lidars, one FMCW lidar, five radars, GNSS/INS, 5G and V2X communication, a centralized HPC with two Jetson embedded computers, a two-tier Ethernet network with PTP synchronization, and a drive-by-wire interface based on fka/DSPACE hardware. The software stack is described only at a high level, with evaluation explicitly deferred. Section V reports component-level measurements: PTP offsets below 200 ns over 3 minutes at standstill, qualitative camera-lidar calibration at rest, sensor data latencies, power consumption and battery endurance, compute headroom, and acceleration/curvature limits of the drive-by-wire system. The conclusion states that karl. fulfills many required core capabilities and is positioned as an L4 research platform.

Significance. If the described design is accurate and reproducible, the paper is a valuable engineering reference for academic and small research groups seeking to build an automated vehicle platform with off-the-shelf components. Its strengths are the unusually complete hardware bill of materials, the modular two-tier network and power architecture, the use of an open-source calibration tool, and the direct measurements of power, latency, and drive-by-wire behavior. The paper does not claim algorithmic novelty, but that is not required for a platform paper. The main limitation is that the evaluation is component-level and static: it does not demonstrate integrated, dynamic operation of the perception, timing, and control chain. The paper would be stronger if its claims were scoped to 'hardware platform with component-level validation' rather than implying validated L4 capability.

major comments (4)

[Sec. V.1 and Sec. III-G.4] The PTP evaluation measures offsets only on the HPC and embedded computers, 30 times over 3 minutes while the vehicle is at standstill, and then asserts that 'the same sub-microsecond accuracy is expected to hold for the PTP-synchronized sensors.' This is an extrapolation, not a measurement. Moreover, the front-facing FMCW lidar is synchronized via NTP from the HPC (Sec. III-G.4), but no NTP offset or stability measurement is reported anywhere in Sec. V. During driving, vibration, temperature changes, and variable network load can affect clock offsets and switch residence times. To support the claim that synchronized multi-sensor fusion is a core capability, the authors should measure PTP offsets on the actual PTP-capable sensors and measure NTP offset/error for the FMCW lidar, ideally under dynamic or at least thermally varying conditions.
[Sec. V.2 and Sec. III-D.4] Sensor calibration is evaluated only 'at rest' and with a qualitative visual reprojection (Fig. 7). No numerical reprojection error, calibration target uncertainty, or repeatability is reported. The paper's positioning relies on 360° redundant multi-modal coverage for perception; if extrinsics drift under vibration or thermal expansion during driving, the claimed fusion capability is not established. The authors should provide quantitative calibration residuals and, if possible, a dynamic validation (e.g., calibration consistency before/after a test drive, or reprojection on a moving sequence).
[Sec. V introductory footnote vs. Sec. III-G.1] The evaluation was conducted with an earlier HPC setup (Threadripper PRO 5995WX and one RTX 4090), while the described current vehicle uses a Threadripper PRO 9985WX and two RTX PRO 6000 GPUs. This means the reported power consumption, battery endurance, and compute-headroom numbers in Secs. V.4 and V.5 do not directly characterize the system presented in Sec. III. At minimum, the paper should state that these numbers are historical and re-measure power and load on the current hardware, or clearly mark the evaluation as applying to a previous configuration.
[Secs. IV.B, V intro, and VI] The paper repeatedly positions karl. as an 'L4-capable' research platform, and the conclusion says the evaluation demonstrates that it 'fulfills many required core capabilities.' However, the software stack evaluation is explicitly out of scope, and no closed-loop automated driving experiment, shadow-mode run, or even a test-track demonstration is reported. As presented, the evidence supports a well-integrated hardware platform for developing and testing ADS components, not a validated L4-capable system. The claims in the abstract, introduction, and conclusion should be scoped accordingly, or the authors should add at least a minimal closed-loop or shadow-mode validation on the current hardware.

minor comments (5)

[Sec. V.3] Latency is reported only as a mean. For real-time fusion and control, the distribution and worst-case (or 95th/99th percentile) matter. Please report min/max or percentiles, and describe the measurement methodology for the radar 'below 1 ms' latency, which currently has no detail.
[Sec. V.1] Please report the number of samples, whether the offsets are mean absolute offset or mean of absolute values, and the min/max values. The current statement '30 times over 3 minutes' does not convey the stability of the offset.
[Sec. III-G.4] The statement that end-to-end PTP mode 'still provides sufficient accuracy' is asserted without quantitative justification. Since the switches do not support transparent clocking, consider documenting switch residence time asymmetry or using boundary clocks.
[Fig. 4] The field-of-view figures are information-dense and hard to read in print. Consider enlarging labels and separating the sensor subsets into clearer subfigures.
[Sec. IV.C] The AD stack is described only at a block-diagram level. If a companion publication or repository exists, cite it; otherwise, state explicitly that no public details are yet available.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: karl. is a direct measurement/design report; stated capabilities are measured, not derived from fitted inputs.

full rationale

karl. does not claim a derivation, prediction, or uniqueness result. Section V evaluates core capabilities by direct measurement: PTP offsets read from pmc over 3 minutes, power draw measured at idle/full load, sensor latency measured in ROS 2, compute headroom measured over 2 minutes, and DbW response compared against ISO 15622 limits. None of these quantities is fitted to data and then re-reported as a prediction; each is an independent measurement. The only self-citations ([18] ros2_calib by a coauthor, [20] docker-ros by two coauthors) are used as tools and do not carry the argument; even if the calibration tool were imperfect, the calibration evaluation is qualitative and at rest rather than a derived claim. The static-only calibration and NTP-synced FMCW lidar timing are evidence limitations for the L4 operational claim, but they are not circularity: the paper does not define the vehicle's capability in terms of those measurements. No self-definitional step, fitted input, uniqueness import, ansatz smuggling, or renaming is present.

Assumptions & free parameters 0 free parameters · 4 assumptions · 0 invented entities

No fitted free parameters or newly postulated entities; the central claim rests on domain assumptions about off-the-shelf component performance and the untested software stack.

assumptions (4)

domain assumption Manufacturer-specified sensor performance (e.g., Aeva Aeries II 200 m range, SBG Ekinox 1 cm/0.05° accuracy, Altos V2 detection ranges) is accurate in real operating conditions.
Section III-D and III-E rely on vendor specifications as evidence that the sensor suite meets L4 perception and localization needs; no independent verification is provided.
domain assumption IEEE 1588 PTP end-to-end synchronization over the two-tier Ethernet network is accurate enough for multi-sensor fusion, even though the switches do not support transparent clocks.
Section III-G.4 asserts sufficiency; Section V.1 measures static offsets only, not synchronization under load or motion.
domain assumption The stock VW T7 ACC and active parking assist, accessed through the fka drive-by-wire interface, provide safe and sufficient longitudinal and lateral actuation for L4 operation.
Section III-H and V.6 show adherence to ISO 15622 acceleration limits and speed-dependent curvature limits, but do not cover all maneuvers, gradients, or fault cases.
domain assumption The single-track vehicle model with Ackermann steering is adequate for trajectory planning and control on the roads karl. will encounter.
Section IV.C introduces the motion model without experimental validation of its accuracy at the platform's operating envelope.

how reviews work

0 comments

Cite this review

Pith. "Pith review of karl. -- A Research Vehicle for Automated and Connected Driving." pith.science (2026). https://pith.science/paper/ISWIBHG2

@misc{pith2026260208842,
  author       = {Pith},
  title        = {Pith review of: karl. -- A Research Vehicle for Automated and Connected Driving},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/ISWIBHG2}},
  note         = {Machine review of arXiv:2602.08842}
}

read the original abstract

As highly automated driving is transitioning from single-vehicle closed-access testing to commercial deployments of public ride-hailing in selected areas (e.g., Waymo), automated driving and connected cooperative intelligent transport systems (C-ITS) remain active fields of research. Even though simulation is omnipresent in the development and validation life cycle of automated and connected driving technology, the complex nature of public road traffic and software that masters it still requires real-world integration and testing with actual vehicles. Dedicated vehicles for research and development allow testing and validation of software and hardware components under real-world conditions early on. They also enable collecting and publishing real-world datasets that let others conduct research without vehicle access, and support early demonstration of futuristic use cases. In this paper, we present karl., our new research vehicle for automated and connected driving. Apart from major corporations, few institutions worldwide have access to their own L4-capable research vehicles, restricting their ability to carry out independent research. This paper aims to help bridge that gap by sharing the reasoning, design choices, and technical details that went into making karl. a flexible and powerful platform for research, engineering, and validation in the context of automated and connected driving. More impressions of karl. are available at https://karl.ac.

Figures

Figures reproduced from arXiv: 2602.08842 by the authors.

**Figure 1.** Cabin rack carrying drawer, V2X unit, 5G router, AE switch, HPC, core switch, vehicle interface, power distribution panel, and power supply 1) Cabin Rack: Most of the hardware installed in the interior is located in a compact cabin rack in the rear compartment. The rack is constructed from 40 mm aluminum profiles and is divided into two separate 19” 12U columns. This provides a highly modular and expandable basis fo… view at source ↗

**Figure 2.** Sensor rack carrying stereo cameras, rotating lidars, FMCW lidar, rooftop box, 5G antenna, and GNSS antennas [PITH_FULL_IMAGE:figures/full_fig_p002_2.png] view at source ↗

**Figure 3.** Developer workplace and front row HMI devices [PITH_FULL_IMAGE:figures/full_fig_p003_3.png] view at source ↗

Figures from the paper (5 more)

**Figure 4.** Figure 4: Fields of view of environment sensors: stereo cameras, rotating lidars, FMCW lidar, and 4D radars. The top-down view shows all sensors, the other views only show those sensors whose vertical field of view lies in the view plane. space. With a 10 % reflectivity range of…

**Figure 5.** Figure 5: Overview of the two-tier Ethernet architecture connect [PITH_FULL_IMAGE:figures/full_fig_p005_5.png]

**Figure 6.** Figure 6: Fundamental components of our software stack for [PITH_FULL_IMAGE:figures/full_fig_p006_6.png]

**Figure 7.** Figure 7: Sample demonstrating sensor calibration quality at rest [PITH_FULL_IMAGE:figures/full_fig_p007_7.png]

**Figure 8.** Figure 8: Vehicle response to nominal braking step with vehicle speed back in ROS, and compare nominal vs. real values. We measure longitudinal acceleration with the INS at 50 Hz and compute a centered rolling average over 200 ms, and measure steering angle via the curvature int…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

23 extracted references · 1 canonical work pages

[1]

J3016: Taxonomy and Definitions for Terms Related to Driving Automation Systems for On-Road Motor Vehicles,

SAE International, “J3016: Taxonomy and Definitions for Terms Related to Driving Automation Systems for On-Road Motor Vehicles,” SAE International, Tech. Rep., 2021. [Online]. Available: https: //www.sae.org/standards/j3016 202104-taxonomy-definitions-terms-rel ated-driving-automation-systems-road-motor-vehicles

2021
[2]

[Online]

Waymo, 2025. [Online]. Available: https://x.com/Waymo/status/1915507 165378257100

arXiv 2025
[3]

Zoox is live in Las Vegas!

Zoox, “Zoox is live in Las Vegas!” 2025. [Online]. Available: https://zoox.com/journal/las-vegas/

2025
[4]

China’s Baidu says weekly robotaxi rides hit 250,000 – same as Alphabet’s Waymo this spring,

CNBC, “China’s Baidu says weekly robotaxi rides hit 250,000 – same as Alphabet’s Waymo this spring,” 2025. [Online]. Available: https://ww w.cnbc.com/2025/11/03/china-baidu-robotaxis-alphabet-waymo-.html

2025
[5]

CARLA: An open urban driving simulator,

A. Dosovitskiyet al., “CARLA: An open urban driving simulator,” in Proceedings of the 1st Annual Conference on Robot Learning, 2017

2017
[6]

CARLOS: An Open, Modular, and Scalable Simulation Framework for the Development and Testing of Software for C-ITS,

C. Gelleret al., “CARLOS: An Open, Modular, and Scalable Simulation Framework for the Development and Testing of Software for C-ITS,” in 2024 IEEE Intelligent Vehicles Symposium (IV), 2024, pp. 3100–3106

2024
[7]

Use of simulation for the homologation of automated driving functions,

H. Abdellatif and C. Gnandt, “Use of simulation for the homologation of automated driving functions,”ATZ Electron Worldw, vol. 14, no. 12, pp. 68–71, Dec. 2019

2019
[8]

A Multi-Modality Evaluation of the Reality Gap in Autonomous Driving Systems ,

S. C. Lambertenghi, M. F. Valdez, and A. Stocco, “A Multi-Modality Evaluation of the Reality Gap in Autonomous Driving Systems ,” in ACM International Conference on AI-powered Software (AIware), 2025

2025

Show all 23 references

[9]

UNICARagil - Disruptive Modular Architectures for Agile, Automated Vehicle Concepts,

T. Woopenet al., “UNICARagil - Disruptive Modular Architectures for Agile, Automated Vehicle Concepts,” in27. Aachen Colloquium Automobile and Engine Technology. Aachen: Institute for Automotive Engineering, RWTH Aachen, Oct 2018, pp. 663–694

2018
[10]

The OPA3L System and Testconcept for Urban Autonomous Driving,

A. Folkerset al., “The OPA3L System and Testconcept for Urban Autonomous Driving,” in2022 IEEE 25th International Conference on Intelligent Transportation Systems (ITSC), 2022, pp. 1949–1956

2022
[11]

EDGAR: An Autonomous Driving Research Platform – From Feature Development to Real-World Application,

P. Karleet al., “EDGAR: An Autonomous Driving Research Platform – From Feature Development to Real-World Application,” 2024. [Online]. Available: https://arxiv.org/abs/2309.15492

2024 arXiv
[12]

CoCar NextGen: A Multi-Purpose Platform for Con- nected Autonomous Driving Research,

M. Heinrichet al., “CoCar NextGen: A Multi-Purpose Platform for Con- nected Autonomous Driving Research,” in2024 IEEE 27th International Conference on Intelligent Transportation Systems (ITSC), 2024, pp. 482– 489

2024
[13]

RoboCar: A Rapidly Deploy- able Open Source Platform for Autonomous Driving Research,

M. Testouri, G. Elghazaly, and R. Frank, “RoboCar: A Rapidly Deploy- able Open Source Platform for Autonomous Driving Research,”IEEE Intelligent Transportation Systems Magazine, vol. 17, pp. 83–95, 2025

2025
[14]

Automated Vehicle Platform with Connected Driving Capabilities,

O. Teikmaniset al., “Automated Vehicle Platform with Connected Driving Capabilities,” 2023. [Online]. Available: https://arxiv.org/abs/23 08.02176

2023
[15]

[Online]

Technische Universit ¨at Ilmenau, 2024. [Online]. Available: https: //www.tu-ilmenau.de/unionline/forschung/details/vom-labor-auf-die-str asse-1496

2024
[16]

[Online]

TOPAS, 2025. [Online]. Available: https://topas.tech/news/detail/auton omer-vw-bus-erhaelt-bundesweite-testfreigabe/

2025
[17]

Robot Operating System 2: Design, architecture, and uses in the wild,

S. Macenskiet al., “Robot Operating System 2: Design, architecture, and uses in the wild,”Science Robotics, vol. 7, no. 66, p. eabm6074, 2022

2022
[18]

ika-rwth-aachen/ros2 calib: Release v0.1.1,

T. Beemelmanns, “ika-rwth-aachen/ros2 calib: Release v0.1.1,” Sep
[19]

Rethinking vehicle architecture through softwarization and servitization,

A. Khamis and P. Goswami, “Rethinking vehicle architecture through softwarization and servitization,”IEEE Access, vol. 13, pp. 126 213– 126 226, 2025

2025
[20]

Enabling the Deployment of Any-Scale Robotic Applications in Microservice Architectures through Automated Containerization,

J.-P. Busch, L. Reiher, and L. Eckstein, “Enabling the Deployment of Any-Scale Robotic Applications in Microservice Architectures through Automated Containerization,” in2024 IEEE International Conference on Robotics and Automation (ICRA), 2024, pp. 17 650–17 656

2024
[21]

V2AIX: A Multi-Modal Real-World Dataset of ETSI ITS V2X Messages in Public Road Traffic,

G. Kuepperset al., “V2AIX: A Multi-Modal Real-World Dataset of ETSI ITS V2X Messages in Public Road Traffic,” in2024 IEEE 27th International Conference on Intelligent Transportation Systems (ITSC), 2024, pp. 392–398

2024
[22]

Intelligent transport systems - Adaptive cruise control systems - Perfor- mance requirements and test procedures,

“Intelligent transport systems - Adaptive cruise control systems - Perfor- mance requirements and test procedures,” International Organization for Standardization, Geneva, CH, Standard, 2018

2018
[2025]

Available: https://doi.org/10.5281/zenodo.17218809

[Online]. Available: https://doi.org/10.5281/zenodo.17218809

doi

Pith tools

Reviewed August 3, 2026 · model on record in the stance chip above.

[1] [1]

J3016: Taxonomy and Definitions for Terms Related to Driving Automation Systems for On-Road Motor Vehicles,

SAE International, “J3016: Taxonomy and Definitions for Terms Related to Driving Automation Systems for On-Road Motor Vehicles,” SAE International, Tech. Rep., 2021. [Online]. Available: https: //www.sae.org/standards/j3016 202104-taxonomy-definitions-terms-rel ated-driving-automation-systems-road-motor-vehicles

2021

[2] [2]

[Online]

Waymo, 2025. [Online]. Available: https://x.com/Waymo/status/1915507 165378257100

arXiv 2025

[3] [3]

Zoox is live in Las Vegas!

Zoox, “Zoox is live in Las Vegas!” 2025. [Online]. Available: https://zoox.com/journal/las-vegas/

2025

[4] [4]

China’s Baidu says weekly robotaxi rides hit 250,000 – same as Alphabet’s Waymo this spring,

CNBC, “China’s Baidu says weekly robotaxi rides hit 250,000 – same as Alphabet’s Waymo this spring,” 2025. [Online]. Available: https://ww w.cnbc.com/2025/11/03/china-baidu-robotaxis-alphabet-waymo-.html

2025

[5] [5]

CARLA: An open urban driving simulator,

A. Dosovitskiyet al., “CARLA: An open urban driving simulator,” in Proceedings of the 1st Annual Conference on Robot Learning, 2017

2017

[6] [6]

CARLOS: An Open, Modular, and Scalable Simulation Framework for the Development and Testing of Software for C-ITS,

C. Gelleret al., “CARLOS: An Open, Modular, and Scalable Simulation Framework for the Development and Testing of Software for C-ITS,” in 2024 IEEE Intelligent Vehicles Symposium (IV), 2024, pp. 3100–3106

2024

[7] [7]

Use of simulation for the homologation of automated driving functions,

H. Abdellatif and C. Gnandt, “Use of simulation for the homologation of automated driving functions,”ATZ Electron Worldw, vol. 14, no. 12, pp. 68–71, Dec. 2019

2019

[8] [8]

A Multi-Modality Evaluation of the Reality Gap in Autonomous Driving Systems ,

S. C. Lambertenghi, M. F. Valdez, and A. Stocco, “A Multi-Modality Evaluation of the Reality Gap in Autonomous Driving Systems ,” in ACM International Conference on AI-powered Software (AIware), 2025

2025