Pith. sign in

REVIEW 4 major objections 7 minor 1 cited by

Open-Source Autonomous Driving Software Platforms: Comparison of Autoware and Apollo

T0 review · 4 major / 7 minor · reviewed 2026-08-09 · deepseek-v4-flash

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

Pith's one-line read Apollo's shared-memory middleware outperforms Autoware's DDS on latency but uses more memory.

desk verdict The architecture comparison and subcomponent counts are genuinely useful; the middleware benchmark, however, compares TCP against shared memory rather than DDS against CyberRT, so the headline latency gap should not be trusted as reported. read the letter →

arxiv 2501.18942 v1 pith:CWMIOQZ4 submitted 2025-01-31 cs.RO

Hee-Yang Jung , Dong-Hee Paek , Seung-Hyun Kong This is my paper · ORCID
classification cs.RO
keywords AutowareApolloautonomousdrivingsoftwareplatformmiddlewareCyberRTFastDDSsharedmemorylatency
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

This paper provides a head-to-head, quantitative basis for choosing between the two leading open-source autonomous-driving stacks, Autoware and Apollo. It compares how each platform implements the core modules—localization, perception, planning, and control—by counting subcomponents from source code, then runs a controlled middleware benchmark pitting FastDDS (Autoware's DDS) against CyberRT (Apollo's shared-memory middleware). The headline result is that CyberRT is far faster at transferring large sensor messages (0.11 vs 153 µs in the functional-module test, 1.72 vs 38075 µs for high-end sensor data) while using more memory, with no message loss on either side. The claim matters because middleware latency is a real-time bottleneck for autonomous driving, and platform selection has long-term integration consequences.

What carries the argument

The central object is the middleware layer: FastDDS, the Data Distribution Service implementation used in Autoware, versus CyberRT, the proprietary communication middleware used in Apollo. CyberRT's shared-memory transport with zero-copy reads, which eliminates serialization, is the mechanism that produces low latency; FastDDS's socket-based serialization and fragmentation is the mechanism that produces higher latency at large data sizes and lower memory use.

What would settle it

Run the same message-size, frequency, and subscriber sweeps with FastDDS configured exactly as Autoware's default launch files configure it (including any shared-memory transport), and measure end-to-end latency of a complete perception-to-planning pipeline on identical hardware; if the CyberRT-versus-FastDDS latency gap shrinks by orders of magnitude or reverses, the paper's central trade-off does not generalize.

Watch

Extended reading notes

Core claim

Autoware and Apollo take structurally different middleware approaches: Autoware runs on ROS2 with DDS, which serializes and fragments messages before transmission, while Apollo uses CyberRT, which writes sensor data directly into shared memory and reads it from there without serialization. In the paper's measurements, CyberRT's latency stays below about 2 µs even for high-end sensor data, while FastDDS rises to tens of milliseconds; memory usage is correspondingly higher for CyberRT, and neither middleware loses messages. The paper also claims the two platforms differ meaningfully in how they implement localization, perception, planning, and control, so the choice of platform is not just a benchmark score but a set of architectural trade-offs.

Load-bearing premise

The comparison assumes that a standalone microbenchmark of FastDDS versus CyberRT on synthetic messages faithfully represents how each platform performs inside a full autonomous-driving stack, even though real pipelines use different communication settings, message sizes, and shared-memory access patterns.

Editorial extensions

If this is right

  • Platform selectors can expect Apollo and CyberRT to pass large sensor messages far faster than Autoware and FastDDS in similar configurations, at the cost of higher memory use.
  • Autoware's DDS serialization is the main source of latency growth with message size, so latency-sensitive Autoware deployments should target the middleware layer rather than the algorithms when optimizing.
  • Neither middleware loses messages in the tested conditions, so message integrity is not a differentiator at these scales.
  • The module-level comparison shows the two platforms are not interchangeable: Autoware has more localization subcomponents, Apollo has more camera-perception and planning scenario coverage, and their controller designs differ.
  • Apollo's sequential-stage planning architecture can avoid computing trajectories for inactive scenarios, which the paper contrasts with Autoware's parallel scenario execution.

Reading between the lines

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

  • If the microbenchmark transfers to real stacks, Autoware's DDS serialization becomes a scalability ceiling for sensor-heavy configurations, which would push adopters toward Apollo or toward a shared-memory transport inside ROS2.
  • A full-stack benchmark would need to include application-level compute times, because middleware latency gains can be swamped by perception and planning execution; the paper measures only the middleware layer.
  • The memory cost of CyberRT (tens of megabytes in these tests) is likely to grow with the number of concurrent subscribers and message sizes, so the trade-off may widen in multi-sensor fusion systems.
  • Autoware's ROS2 base gives it access to a broader ecosystem of tools and packages, and a developer might accept DDS overhead for that interoperability; the paper does not quantify ecosystem value.
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.

Referee Report

4 major / 7 minor

Summary. This paper presents a head-to-head comparison of two open-source autonomous driving software platforms, Autoware and Apollo. The authors qualitatively analyze the middleware, localization, perception, planning, and control modules of each platform, then quantitatively compare module subcomponents and benchmark the middleware layers (FastDDS in Autoware versus CyberRT in Apollo) in terms of latency, CPU usage, memory consumption, and message loss rate. The central quantitative claim, stated in Section V, is that CyberRT achieves lower latency for large-scale data transmission than FastDDS at the cost of higher memory usage, based on the Section IV-B benchmark. The paper also offers qualitative observations about architectural differences in planning and control design.

Significance. If the quantitative comparison were methodologically sound, the paper would provide a useful practical reference for researchers and engineers selecting between Autoware and Apollo. The qualitative module analysis and the enumeration of subcomponents in Table I are a convenient synthesis of the two platforms' architectures, and the paper does not rely on circular reasoning or fitted parameters. However, the central quantitative contribution rests on a thin benchmark that confounds transport choice with middleware design, and it lacks the statistical reporting needed to support the strong conclusions. The paper's value currently lies more in its qualitative survey aspect than in its performance measurements.

major comments (4)
  1. [Section IV-B, Table II] The latency comparison confounds transport choice with middleware architecture. FastDDS is configured with TCP explicitly to minimize message loss, while CyberRT uses shared memory. TCP on loopback adds serialization, copying, and acknowledgment overhead that shared memory avoids; FastDDS also supports shared-memory and UDP transports, and Autoware's ROS2 stack can be configured to use them. Therefore the reported latency gap (e.g., 38075 us versus 1.72 us for high-end sensor data) cannot be attributed to DDS versus CyberRT as architectural alternatives. The authors should either benchmark FastDDS with at least one non-TCP transport, or explicitly scope the conclusion to the specific TCP configuration tested.
  2. [Section IV-B, Fig. 9 and Table II] No trial counts, error bars, standard deviations, or definition of the measured latency endpoint are provided. The reported CyberRT latency of 0.11 us for the functional-module case is close to the cost of a single shared-memory read/write on the test hardware, which raises the question of whether the measurement captures only publisher-side enqueue rather than subscriber-side receipt. The authors should specify the measurement methodology, including which timestamps mark start and end, the number of warm-up and measured iterations, and the variability across runs, so that the comparison is reproducible and apples-to-apples.
  3. [Section IV-A, Table I] The subcomponent counts are presented as quantitative evidence of functional coverage, but no explicit counting criteria are given. It is unclear what qualifies as a subcomponent, how overlapping or deprecated components are handled, whether the counts reflect maintained code or documentation entries, and how the line is drawn between, for instance, Autoware's 17 LiDAR perception subcomponents and Apollo's 9. Without a defined and auditable rubric, Table I cannot be independently verified, which weakens the paper's claim of a 'systematic' quantitative comparison.
  4. [Section IV-B, Section V] The benchmark tests isolated middleware with synthetic messages, not the actual Autoware and Apollo pipelines. The conclusion in Section V extrapolates from this microbenchmark to 'large-scale data transmission' in the full-stack platforms, but the message sizes, frequencies, number of subscribers, and transport configurations in the benchmark are not tied to the real workloads of the two platforms. The authors should either include application-level or realistic sensor-data workloads, or temper the conclusion to a microbenchmark observation that does not generalize to full-stack performance.
minor comments (7)
  1. [Section III-B] The heading 'Localizaiton' should be spelled 'Localization'.
  2. [Section IV-A] The phrase 'comparing the the subcomponents' contains a duplicated article and should be corrected.
  3. [Acknowledgment] The word 'funeded' should be 'funded'.
  4. [References] Reference [2] lists the first author as 'AndreiGavrilov' with a missing space; this appears to be a formatting error.
  5. [Section III-A] The statement that DDS 'creates TCP or UDP sockets' is an oversimplification, since DDS implementations also support shared-memory transports; this oversimplification is directly related to the confound identified in the benchmark.
  6. [Fig. 6 caption] The phrase 'Data is acquired' should be 'Data are acquired' for grammatical agreement, or rephrased.
  7. [General] The paper would benefit from a statement on code and data availability for the middleware benchmark, as none is currently provided.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity; the paper reports direct measurements and source-code observations rather than deriving conclusions from fitted inputs or self-citations.

full rationale

This paper does not contain a derivation chain that reduces to its own inputs. The central conclusions about Autoware and Apollo rest on two activities: (1) enumerating source-code subcomponents from the public repositories and official documentation, and (2) measuring middleware latency, CPU usage, memory usage, and message loss with an experiment reported in Section IV-B and Table II. No parameter is fitted to a target conclusion, no claimed prediction is definitionally equivalent to an input, and no load-bearing argument is justified by a self-citation. The comparison of FastDDS under a TCP configuration against CyberRT's shared-memory transport is a legitimate experimental design choice, and any concern about that choice is a methodological or external-validity issue, not circularity. The absence of error bars and the specific transport configuration could affect the interpretation of the latency gap, but they do not make the reported measurement an artifact of the paper's own assumptions. The manuscript is self-contained against the measured data and the cited public source code, so no circular step is present.

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

The central claims rest on domain assumptions about platform architecture and representativeness of the benchmark, not on mathematical axioms or fitted parameters. No new entities are invented.

assumptions (3)
  • domain assumption Autoware's middleware can be represented by FastDDS, and Apollo's by CyberRT.
    Section III-A states Autoware is based on ROS2 with DDS (FastDDS) and Apollo uses CyberRT; the benchmark in Section IV-B assumes these choices represent each platform in practice.
  • domain assumption Subcomponent counts obtained from source code and documentation review are an objective measure of platform functional capability.
    Section IV-A enumerates subcomponents to produce Table I, but the selection and grouping criteria are not specified in detail, so the counts are subjective.
  • domain assumption Middleware microbenchmark results transfer to full-stack autonomous driving workloads.
    Section IV-B tests middleware in isolation on synthetic conditions and treats the outcome as a platform-level performance indicator, which assumes the benchmark workload is representative.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Open-Source Autonomous Driving Software Platforms: Comparison of Autoware and Apollo." pith.science (2026). https://pith.science/paper/CWMIOQZ4

@misc{pith2026250118942,
  author       = {Pith},
  title        = {Pith review of: Open-Source Autonomous Driving Software Platforms: Comparison of Autoware and Apollo},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/CWMIOQZ4}},
  note         = {Machine review of arXiv:2501.18942}
}
read the original abstract

Full-stack autonomous driving system spans diverse technological domains-including perception, planning, and control-that each require in-depth research. Moreover, validating such technologies of the system necessitates extensive supporting infrastructure, from simulators and sensors to high-definition maps. These complexities with barrier to entry pose substantial limitations for individual developers and research groups. Recently, open-source autonomous driving software platforms have emerged to address this challenge by providing autonomous driving technologies and practical supporting infrastructure for implementing and evaluating autonomous driving functionalities. Among the prominent open-source platforms, Autoware and Apollo are frequently adopted in both academia and industry. While previous studies have assessed each platform independently, few have offered a quantitative and detailed head-to-head comparison of their capabilities. In this paper, we systematically examine the core modules of Autoware and Apollo and evaluate their middleware performance to highlight key differences. These insights serve as a practical reference for researchers and engineers, guiding them in selecting the most suitable platform for their specific development environments and advancing the field of full-stack autonomous driving system.

Figures

Figures reproduced from arXiv: 2501.18942 by the authors.

Figure 1
Figure 1. Classification of autonomous driving software platforms. [PITH_FULL_IMAGE:figures/full_fig_p001_1.png] view at source ↗
Figure 2
Figure 2. Architecture of autonomous driving software platforms. Core functionality includes middleware for data communication between modules. The core [PITH_FULL_IMAGE:figures/full_fig_p002_2.png] view at source ↗
Figure 3
Figure 3. Architecture of software platforms. overview of Autoware’s software stack and its functionalities, and [7] validates the feasibility of applying Autoware to real vehicles. Meanwhile, [11] delves into Apollo’s opti￾mal path planning techniques, and [12] proposes a novel control approach based on Apollo. Although other works mention both platforms, few provide an in-depth, direct comparison. For example, [29] qualitat… view at source ↗
Figures from the paper (3 more)
Figure 6
Figure 6. Figure 6: Internal structure of the core perception module used in Autoware [PITH_FULL_IMAGE:figures/full_fig_p003_6.png]
Figure 8
Figure 8. Figure 8: Internal structure of the core control module used in Autoware [PITH_FULL_IMAGE:figures/full_fig_p004_8.png]
Figure 9
Figure 9. Figure 9: Middleware communication performance results based on data size, frequency, and number of subscribers. The first row represents data size, the [PITH_FULL_IMAGE:figures/full_fig_p005_9.png]

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 1 Pith paper

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

  1. LLM-Assisted Dynamic Threat Analysis for Attacker-Reachable Software Weaknesses in Autonomous Vehicles

    cs.SE 2026-08 conditional novelty 7.0 of 10

    LLM-generated dynamic analysis harnesses for Autoware rarely compile or link against the real build, no weakness was confirmed, and build integration, not fuzzing, is the binding constraint.

Reference graph

Works this paper leans on

41 extracted references · 38 canonical work pages · cited by 1 Pith paper

  1. [1]

    Reliability and security analysis of artifi- cial intelligence-based self-driving technologies in saudi arabia: A case study of openpilot

    Faisal S Alsubaei. Reliability and security analysis of artifi- cial intelligence-based self-driving technologies in saudi arabia: A case study of openpilot. Journal of advanced transportation , 2022(1):2085225, 2022

    work page 2022

  2. [2]

    Analysis of robotic platforms: Data transfer performance evaluation

    Marlen Bergaliyev AndreiGavrilov, Sergey Tinyakov, and Kirill Krinkin. Analysis of robotic platforms: Data transfer performance evaluation. architecture, 17:18, 2021

    work page 2021

  3. [3]

    Apollo 10.0 autonomous driving open platform

    Baidu. Apollo 10.0 autonomous driving open platform. Available: https://apollo.baidu.com/docs/apollo/latest/ index.html. Accessed: Jan. 23, 2025 [Online]

    work page 2025

  4. [4]

    Apollo github

    Baidu. Apollo github. Available: https://github.com/ ApolloAuto/apollo. Accessed: Jan. 23, 2025 [Online]

    work page 2025

  5. [5]

    Biber and W

    P. Biber and W. Strasser. The normal distributions transform: a new approach to laser scan matching. In Proceedings 2003 IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS

    work page 2003

  6. [6]

    Systematic analysis of dds implementations

    Vincent Bode, David Buettner, Tobias Preclik, Carsten Trinitis, and Martin Schulz. Systematic analysis of dds implementations. In Proceedings of the 24th International Middleware Conference , pages 234–246, 2023

    work page 2023

  7. [7]

    Research on an open-source software platform for autonomous driving systems

    Lukas Bulwahn, Tilmann Ochs, and Daniel Wagner. Research on an open-source software platform for autonomous driving systems. BMW Car IT GmbH, Munich, Germany , 2013

    work page 2013

  8. [8]

    Openpilot

    CommaAI. Openpilot. Available: https://github.com/ commaai/openpilot. Accessed: Jan. 23, 2025 [Online]

    work page 2025

Show all 41 references
  1. [9]

    Eb robinos

    Elecktrobit. Eb robinos. Available: https://www.elektrobit. com/products/automated-driving/eb-robinos/ . Ac- cessed: Jan. 23, 2025 [Online]

    2025

  2. [10]

    Fast dds documentation

    eProsima. Fast dds documentation. Available: https:// fast-dds.docs.eprosima.com/en/latest/. Accessed: Jan. 28, 2025 [Online]

    2025

  3. [11]

    Baidu apollo em motion planner

    Haoyang Fan, Fan Zhu, Changchun Liu, Liangliang Zhang, Li Zhuang, Dong Li, Weicheng Zhu, Jiangtao Hu, Hongye Li, and Qi Kong. Baidu apollo em motion planner. arXiv preprint arXiv:1807.08048 , 2018

    2018 arXiv

  4. [12]

    Application of baidu apollo open platform in a course of control simulation experiments

    Minjian Feng and Hui Zhang. Application of baidu apollo open platform in a course of control simulation experiments. Computer Applications in Engineering Education , 30(3):892–906, 2022

    2022

  5. [13]

    A comprehensive study of autonomous vehicle bugs

    Joshua Garcia, Yang Feng, Junjie Shen, Sumaya Almanee, Yuan Xia, Chen, and Qi Alfred. A comprehensive study of autonomous vehicle bugs. In Proceedings of the ACM/IEEE 42nd international conference on software engineering , pages 385–396, 2020

    2020

  6. [14]

    YOLOX: exceeding YOLO series in 2021

    Zheng Ge, Songtao Liu, Feng Wang, Zeming Li, and Jian Sun. YOLOX: exceeding YOLO series in 2021. CoRR, abs/2107.08430, 2021

    2021 arXiv

  7. [15]

    Autorally: An open platform for aggressive autonomous driving

    Brian Goldfain, Paul Drews, Changxi You, Matthew Barulic, Orlin Velev, Panagiotis Tsiotras, and James M Rehg. Autorally: An open platform for aggressive autonomous driving. IEEE Control Systems Magazine, 39(1):26–55, 2019

    2019

  8. [16]

    Autoware documentation

    Tier IV . Autoware documentation. Available: https://autowarefoundation.github.io/ autoware-documentation/main/. Accessed: Jan. 28. 2025 [Online]

    2025

  9. [17]

    Autoware github

    Tier IV . Autoware github. Available: https://github.com/ autowarefoundation/autoware. Accessed: Jan. 23, 2025 [Online]

    2025

  10. [18]

    Autoware universe documentation

    Tier IV . Autoware universe documentation. Available: https://autowarefoundation.github.io/autoware. universe/main/. Accessed: Jan. 28. 2025 [Online]

    2025

  11. [19]

    Autoware universe github

    Tier IV . Autoware universe github. Available: https://github. com/autowarefoundation/autoware.universe. Accessed: Jan. 28. 2025 [Online]

    2025

  12. [20]

    An open approach to au- tonomous vehicles

    Shinpei Kato, Eijiro Takeuchi, Yoshio Ishiguro, Yoshiki Ninomiya, Kazuya Takeda, and Tsuyoshi Hamada. An open approach to au- tonomous vehicles. IEEE Micro, 35(6):60–68, 2015

    2015

  13. [21]

    Autoware on board: Enabling autonomous vehicles with embedded systems

    Shinpei Kato, Shota Tokunaga, Yuya Maruyama, Seiya Maeda, Manato Hirabayashi, Yuki Kitsukawa, Abraham Monrroy, Tomohito Ando, Yusuke Fujii, and Takuya Azumi. Autoware on board: Enabling autonomous vehicles with embedded systems. In 2018 ACM/IEEE 9th International Conference on...

    2018

  14. [22]

    Pointpillars: Fast encoders for object detection from point clouds

    Alex H Lang, Sourabh V ora, Holger Caesar, Lubing Zhou, Jiong Yang, and Oscar Beijbom. Pointpillars: Fast encoders for object detection from point clouds. In Proceedings of the IEEE/CVF conference on computer vision and pattern recognition , pages 12697–12705, 2019

    2019

  15. [23]

    Memory-centric communication mechanism for real-time autonomous navigation applications

    Wei Liu, Yifan Gong, Hao Wu, Jidong Zhai, and Jiangming Jin. Memory-centric communication mechanism for real-time autonomous navigation applications. In Proceedings of the 49th International Conference on Parallel Processing, pages 1–11, 2020

    2020

  16. [24]

    A robotic communication middleware combining high performance and high reliability

    Wei Liu, Hao Wu, Ziyue Jiang, Yifan Gong, and Jiangming Jin. A robotic communication middleware combining high performance and high reliability. In 2020 IEEE 32nd International Symposium on Computer Architecture and High Performance Computing (SBAC- PAD), pages 217–224. IEEE, 2020

    2020

  17. [25]

    An iterative image registration technique with an application to stereo vision

    Bruce D Lucas and Takeo Kanade. An iterative image registration technique with an application to stereo vision. In IJCAI’81: 7th international joint conference on Artificial intelligence , volume 2, pages 674–679, 1981

    1981

  18. [26]

    Exploring the performance of ros2

    Yuya Maruyama, Shinpei Kato, and Takuya Azumi. Exploring the performance of ros2. In Proceedings of the 13th international conference on embedded software , pages 1–10, 2016

    2016

  19. [27]

    Driveworks sdk

    NVIDIA. Driveworks sdk. Available: https://developer. nvidia.com/driveworks. Accessed: Jan. 23, 2025 [Online]

    2025

  20. [28]

    Frustum pointnets for 3d object detection from rgb-d data

    Charles R Qi, Wei Liu, Chenxia Wu, Hao Su, and Leonidas J Guibas. Frustum pointnets for 3d object detection from rgb-d data. In Proceedings of the IEEE conference on computer vision and pattern recognition, pages 918–927, 2018

    2018

  21. [29]

    Performance of open autonomous vehicle platforms: Autoware and apollo

    Vysyaraju Manikanta Raju, Vrinda Gupta, and Shailesh Lomate. Performance of open autonomous vehicle platforms: Autoware and apollo. In 2019 IEEE 5th International Conference for Convergence in Technology (I2CT), pages 1–5. IEEE, 2019

    2019

  22. [30]

    Kalman and extended kalman filters: Con- cept, derivation and properties

    Maria Isabel Ribeiro. Kalman and extended kalman filters: Con- cept, derivation and properties. Institute for Systems and Robotics , 43(46):3736–3741, 2004

    2004

  23. [31]

    Quaternion kinematics for the error-state kalman filter

    Joan Sola. Quaternion kinematics for the error-state kalman filter. arXiv preprint arXiv:1711.02508 , 2017

    2017 arXiv

  24. [32]

    Robocar: A rapidly deployable open-source platform for autonomous driving research, 2024

    Mehdi Testouri, Gamal Elghazaly, and Raphael Frank. Robocar: A rapidly deployable open-source platform for autonomous driving research, 2024

    2024

  25. [33]

    Probabilistic robotics

    Sebastian Thrun. Probabilistic robotics. Communications of the ACM, 45(3):52–57, 2002

    2002

  26. [34]

    Platform ecosystems: Aligning architecture, gover- nance, and strategy

    Amrit Tiwana. Platform ecosystems: Aligning architecture, gover- nance, and strategy . Newnes, 2013

    2013

  27. [35]

    Research commentary—platform evolution: Coevolution of platform architec- ture, governance, and environmental dynamics

    Amrit Tiwana, Benn Konsynski, and Ashley A Bush. Research commentary—platform evolution: Coevolution of platform architec- ture, governance, and environmental dynamics. Information systems research, 21(4):675–687, 2010

    2010

  28. [36]

    Robust and precise vehicle localization based on multi-sensor fusion in diverse city scenes

    Guowei Wan, Xiaolong Yang, Renlan Cai, Hao Li, Yao Zhou, Hao Wang, and Shiyu Song. Robust and precise vehicle localization based on multi-sensor fusion in diverse city scenes. In 2018 IEEE international conference on robotics and automation (ICRA) , pages 4670–4677. IEEE, 2018

    2018

  29. [37]

    Moving forward: A review of autonomous driving software and hardware systems

    Xu Wang, Mohammad Ali Maleki, Muhammad Waqar Azhar, and Pedro Trancoso. Moving forward: A review of autonomous driving software and hardware systems. arXiv preprint arXiv:2411.10291 , 2024

    2024 arXiv

  30. [38]

    Open source and standards: The role of open source in the dialogue between research and standardization

    SA Wright and D Druta. Open source and standards: The role of open source in the dialogue between research and standardization. in 2014 ieee globecom workshops (gc wkshps), 650–655, 2014

    2014

  31. [39]

    Center-based 3d object detection and tracking

    Tianwei Yin, Xingyi Zhou, and Philipp Krahenbuhl. Center-based 3d object detection and tracking. In Proceedings of the IEEE/CVF conference on computer vision and pattern recognition , pages 11784– 11793, 2021

    2021

  32. [40]

    Efficient l-shape fitting for vehicle detection using laser scanners

    Xiao Zhang, Wenda Xu, Chiyu Dong, and John M Dolan. Efficient l-shape fitting for vehicle detection using laser scanners. In 2017 IEEE Intelligent Vehicles Symposium (IV) , pages 54–59. IEEE, 2017

    2017

  33. [2003]

    No.03CH37453), volume 3, pages 2743–2748 vol.3, 2003

    (Cat. No.03CH37453), volume 3, pages 2743–2748 vol.3, 2003

    2003

Pith tools

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