Pith. sign in

REVIEW 4 major objections 5 minor 38 references

AI-CDA4All: Democratizing Cooperative Autonomous Driving for All Drivers via Affordable Dash-cam Hardware and Open-source AI Software

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

Pith's one-line read The paper argues that cooperative driving automation can be assembled from a dash-cam, a $480 edge computer, a CAN adapter, and open-source software, and that a local AI assistant can answer driving queries in about five seconds without…

desk verdict A useful open-source CDA integration report that overreaches on validation: the stack is real, the 'democratizing' claim is not yet backed by closed-loop driving data. read the letter →

arxiv 2505.06749 v1 pith:CYFELAYP submitted 2025-05-10 eess.SY cs.SY

classification eess.SYcs.SY
keywords cooperativedrivingautomationV2XcommunicationedgeLLMopen-sourceautonomousdash-camhardwareMetaActionAPIvehicle-to-infrastructureSAEJ2735
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 claims that cooperative driving automation—the ability of vehicles to share data and coordinate with infrastructure—does not require expensive autonomy sensors or dedicated V2X hardware. It proposes a complete retrofit assembled from a standard webcam, a Jetson Orin Nano edge computer, a CAN/OBD-II adapter, and WiFi/LTE links, with a total bill of materials under $1,000, built on an open-source Level-2 driving stack. The authors report that the platform runs on over ten vehicle makes and models, and that a locally deployed language model answers driving-related queries with a mean response time of about 5 seconds on an AGX Orin, which they argue makes privacy-preserving AI assistance feasible without a cloud connection. The contribution is a feasibility demonstration: the piece-parts are affordable, the standards are public, and the remaining challenge is integration and safety validation.

What carries the argument

The load-bearing mechanism is the MetaAction API, a prompt-level interface that restricts a local large language model to emitting a small set of structured code segments, which the driving stack then parses and executes as low-level control actions. This converts abstract reasoning into executable commands while keeping the model away from raw CAN signals. A second load-bearing piece is the OpenDBC CAN message database, which maps steering, throttle, and brake messages across many car models; the paper's multi-vehicle interoperability claim rests on it. The final piece is the edge computer's capacity to run the perception model and the language model at the same time, which the paper supports only with the reported end-to-end response times.

What would settle it

Run a closed-loop test on a test track or public road with the repackaged stack and compare measured lane-centering error and detection latency against the original certified hardware; alternatively, bench-test the Orin Nano to see whether the perception model sustains real-time frame rates while the language model is also loaded. If the Nano cannot hold inference rate, or the CAN commands fail on any of the claimed vehicle models, the democratization claim collapses.

Watch

Extended reading notes

Core claim

The central claim is that a standards-compliant cooperative driving stack can be assembled from off-the-shelf parts: a webcam as the perception sensor, a Jetson Orin Nano as the edge computer, a CAN adapter on the OBD-II port for vehicle access, and LTE or WiFi links carrying SAE J2735 messages over MQTT. On this architecture the authors report a mean request-to-response time of 5.07 seconds for LLaMA 3.2 on an AGX Orin and 14.10 seconds on an Orin Nano, and they introduce a MetaAction API through which the language model emits structured code that the driving stack parses into executable commands such as changing following distance or applying an advisory speed. The paper's own framing is that these measurements show local edge LLMs can support driving assistance without the latency and privacy exposure of cloud-based models.

Load-bearing premise

The load-bearing premise is that the stock open-source perception and control stack, moved onto the cheaper Orin Nano with a standard webcam and accessed through the CAN/OBD-II interface, delivers the same real-time lane centering and control performance on over ten vehicles as it does on the original vendor-certified hardware; the paper gives no perception accuracy, control quality, or closed-loop safety measurements for the repackaged system.

Editorial extensions

If this is right

  • Any car with an OBD-II port and a supported CAN database can be retrofitted with Level-2 cooperative driving for under $1,000, which would make fleet adoption by cities and small operators financially plausible.
  • A language model running on the vehicle can answer driving queries and adjust vehicle settings without sending CAN data, driver behavior, or telemetry to the cloud, because the measured 5-14 second response times come from on-board inference.
  • Because the system encodes SAE J2735 messages and sends them over MQTT on WiFi or LTE, infrastructure agencies can push advisory speed messages to cooperative vehicles through ordinary networks, enabling congestion and merging applications without dedicated RSU hardware.
  • The MetaAction API gives third-party developers a stable, low-code interface for adding new driving features, so the same hardware platform can serve as a testbed for traffic-flow research and data collection.

Reading between the lines

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

  • The 5-second latency was measured on the more expensive AGX Orin; the paper's own Nano numbers (14 seconds for LLaMA 3.2, far more for others) suggest that a privacy-preserving, fully on-Nano assistant would need a smaller distilled model than the ones tested.
  • The multi-vehicle claim borrows its reach from the OpenDBC database; the genuinely new contribution is the webcam-based perception port onto the open-source stack, and that part has no published accuracy numbers, so a direct benchmark against the original sensor would settle the port's quality.
  • The same plumbing could support a field experiment on advisory speed effects—one that measures real traffic-flow changes when a cohort of retrofitted vehicles follows infrastructure-issued speeds, which the paper does not attempt.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

4 major / 5 minor

Summary. The paper describes AI-CDA4All, an open-source cooperative driving automation (CDA) stack assembled from a Jetson Orin Nano, a Logitech C920 webcam, a CAN/OBD-II adapter, and the OpenPilot software platform, augmented with MQTT/QUIC-based V2X connectivity over LTE/Wi-Fi and locally deployed LLMs for driver assistance. The central claim is that a complete, affordable CDA platform can be built from off-the-shelf parts (BOM under $1000) and that edge-deployed LLMs provide privacy-preserving advisory functions. Quantitative support consists mainly of LLM request-to-response latency measurements (Table IV), a WiFi/LTE specification comparison (Table III), and a demonstration of crawling and displaying FDOT traffic data. The paper positions itself as a prototype/system-integration contribution rather than a derivation or controlled evaluation.

Significance. If the feasibility claims were substantiated, the paper would offer a useful low-cost reference architecture for infrastructure-oriented CDA research and retrofits of legacy vehicles, and its focus on local LLMs addresses a genuine privacy/latency concern. Strengths include a concrete bill of materials, alignment with SAE J2735 and MQTT/QUIC, a real edge-device latency comparison, and reuse of openly documented vehicle CAN databases (OpenDBC). However, as submitted, the evidence is not sufficient to support the stated feasibility: the only quantitative results concern LLM text generation, and the perception, control, and closed-loop aspects of the platform are unmeasured. The significance is therefore conditional on the addition of hardware validation and correction of the control-semantics issue.

major comments (4)
  1. [Section V-B] The only described actuation path for V2X advisory data is the statement that AI-CDA4ALL 'apply the advisory speed value to the control loop of the lateral control algorithm.' Advisory speed is a longitudinal quantity and should affect longitudinal control (throttle/brake), not lateral control. As written, this is a control-loop error that undermines the claimed advisory-speed use case; please correct the implementation/description and show evidence that the advisory speed actually changes vehicle speed.
  2. [Sections I (Contribution 1) and III-B] Contribution 1 claims the platform was 'tested extensively on over 10 different car make and model,' and Section III-B asserts that the Orin Nano plus webcam and CAN adapter handles Level-2 tasks including lane detection and obstacle avoidance. No perception accuracy, control-quality, closed-loop safety, or even sustained inference-rate data are reported; Table IV measures only LLM text-generation latency. Without such measurements, the central feasibility claim is unvalidated. Please add quantitative evidence (e.g., lane-detection metrics, lateral deviation, steering-command statistics, closed-loop driving logs) or explicitly downgrade the claim to a bench/prototype demonstration.
  3. [Section IV-B] The WiFi/LTE connectivity claims rely on specification values (Table III) and prior product datasheets rather than on measurements from the proposed system. There is no reported end-to-end latency, throughput, reliability, or a demonstration that SAE J2735 messages are actually encoded, transmitted, and decoded over the MQTT/QUIC links. Since lightweight connectivity is a primary contribution (Contribution 2), please provide measurement data or qualify these as architectural specifications.
  4. [Section III-B] The paper substitutes a Jetson Orin Nano and a Logitech C920 for comma.ai's certified Comma 3X hardware without any validation that OpenPilot's perception and control stack performs equivalently. OpenPilot's behavior is hardware- and calibration-sensitive, so porting it to non-certified components is not automatic. Please report the modifications made, calibration procedure, and at least one closed-loop or hardware-in-the-loop test showing that the stock pipeline runs at the required rate and maintains safe control.
minor comments (5)
  1. [Throughout] There are numerous typographical and grammar errors (e.g., 'muiltimodal,' 'camer's microphone,' 'adapoted,' 'seemless,' 'equpied,' 'suits'); a thorough proofread is needed.
  2. [Table IV] Table IV column headers are ambiguous: 'Tnet M ed' and 'Tnet Ltoken' are not defined; please use explicit names such as mean latency, median latency, and token length, and define them in the caption.
  3. [Figures] Figure numbering jumps from Figure 4 to Figure 6; there is no Figure 5. Please renumber or add the missing figure.
  4. [Section IV-B] Section IV-B states WiFi 6 coverage is 'up to 300 meters' while Table III lists 'Up to 465 meters' for the AI-CDA4ALL RSU; please reconcile these numbers.
  5. [Section III-C] OpenPilot is cited as [1] in Section III-C but as [2] in the Introduction; the OpenPilot reference should be [2].

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity found: the paper reports direct measurements and an integration prototype; no claim reduces by construction to its own inputs or to a fitted parameter relabeled as a prediction.

full rationale

This paper is a systems-integration and demonstration report rather than a derivation paper. The quantitative core is Table IV, which reports measured request-to-response latencies for local LLMs on two Jetson devices; these are direct benchmark measurements, not quantities derived from fitted inputs or from the model's own assumptions. The claimed architecture builds on OpenPilot and OpenDBC as reused open-source components, which is an engineering dependency rather than a circular justification: the paper does not claim to predict OpenPilot's performance from its own framework. The advisory-speed use case is described as sending values over MQTT and applying them to the control loop; even if the described lateral-control application is technically questionable, that is a correctness issue, not circularity. The only self-citation is to the authors' prior OpenLKA dataset [34], which is an independently collected external artifact and is not load-bearing for any of the paper's central feasibility claims. No fitted parameter is called a prediction, no uniqueness theorem is imported from the authors' prior work, and no known result is renamed. The unvalidated assumption that stock OpenPilot perception and control perform equivalently on non-certified hardware is an evidentiary gap and a correctness risk, but it does not make any derivation circular. Accordingly, the appropriate finding is no significant circularity.

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

The paper is an integration engineering report. It introduces no fitted parameters. Its central feasibility claim relies on several unproven domain assumptions: OpenPilot/OpenDBC provides a safe and reliable Level-2 base; the Jetson Orin Nano with a webcam can run OpenPilot's perception in real time; WiFi 6 and LTE provide the latencies cited from product specifications; and LLM-generated commands passed through the MetaAction API are safe to execute. None of these are validated with measurements in the paper.

assumptions (4)
  • domain assumption OpenPilot and OpenDBC provide a safe, reliable Level-2 driving base when repackaged on non-comma hardware.
    The paper builds the entire autonomy stack on OpenPilot and OpenDBC (Section III-C) but reports no validation that the perception/control chain performs adequately with the Jetson Orin Nano plus webcam setup. This is load-bearing for the feasibility claim.
  • domain assumption The WiFi 6 and LTE connectivity performance figures (latency <10 ms, speed, coverage) are applicable to the V2X use cases in real deployments.
    Section IV-B cites product specifications and surveys for WiFi 6 performance and presents them as the system's connectivity characteristics; no end-to-end V2X latency or packet-loss measurements are reported.
  • domain assumption LLM outputs translated by MetaAction into executable code will be semantically valid and safe on the road.
    Section IV-C describes the MetaAction code-generation mechanism and notes LLM hallucination as a known risk (citing [16]), but the paper offers no safety validation, sandboxing, or failure-mode analysis before allowing LLM-generated commands to modify control settings.
  • domain assumption The OBD-II CAN interface allows safe and reliable longitudinal and lateral actuation on all claimed vehicle models.
    Section III-B asserts the interface 'enables sending control commands for steering, acceleration, and braking' and claims broad compatibility via OpenDBC, but provides no vehicle-specific test results or safety analysis.

how reviews work

0 comments
Cite this review

Pith. "Pith review of AI-CDA4All: Democratizing Cooperative Autonomous Driving for All Drivers via Affordable Dash-cam Hardware and Open-source AI Software." pith.science (2026). https://pith.science/paper/CYFELAYP

@misc{pith2026250506749,
  author       = {Pith},
  title        = {Pith review of: AI-CDA4All: Democratizing Cooperative Autonomous Driving for All Drivers via Affordable Dash-cam Hardware and Open-source AI Software},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/CYFELAYP}},
  note         = {Machine review of arXiv:2505.06749}
}
read the original abstract

As transportation technology advances, the demand for connected vehicle infrastructure has greatly increased to improve their efficiency and safety. One area of advancement, Cooperative Driving Automation (CDA) still relies on expensive autonomy sensors or connectivity units and are not interoperable across existing market car makes/models, limiting its scalability on public roads. To fill these gaps, this paper presents a novel approach to democratizing CDA technology, it leverages low-cost, commercially available edge devices such as vehicle dash-cams and open-source software to make the technology accessible and scalable to be used in transportation infrastructure and broader public domains. This study also investigates the feasibility of utilizing cost-effective communication protocols based on LTE and WiFi. These technologies enable lightweight Vehicle-to-Everything (V2X) communications, facilitating real-time data exchange between vehicles and infrastructure. Our research and development efforts are aligned with industrial standards to ensure compatibility and future integration into existing transportation ecosystems. By prioritizing infrastructure-oriented applications, such as improved traffic flow management, this approach seeks to deliver tangible societal benefits without directly competing with vehicle OEMs. As recent advancement of Generative AI (GenAI), there is no standardized integration of GenAI technologies into open-source CDAs, as the current trends of muiltimodal large language models gain popularity, we demonstrated a feasible locally deployed edge LLM models can enhance driving experience while preserving privacy and security compared to cloud-connected solutions. The proposed system underscores the potential of low-cost, scalable solutions in advancing CDA functionality, paving the way for smarter, safer, and more inclusive transportation networks.

Figures

Figures reproduced from arXiv: 2505.06749 by the authors.

Figure 1
Figure 1. AI-CDA4ALL Ecosystem limiting scalability. Cellular and WiFi-based alternatives have historically been dismissed due to performance limitations, but the landscape has changed: modern protocols like LTE￾Advanced, 5G, and WiFi 6 offer significantly improved reliability and throughput [5]. These advances make them promising candidates for non-safety-critical V2I and V2X communications, such as traffic advisory messages… view at source ↗
Figure 2
Figure 2. Communication links between hardware components [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 4
Figure 4. Example of Intersection WiFi Install Map [PITH_FULL_IMAGE:figures/full_fig_p005_4.png] view at source ↗
Figures from the paper (6 more)
Figure 3
Figure 3. Figure 3: Data flow of MQTT communication using RabbitMQ [PITH_FULL_IMAGE:figures/full_fig_p005_3.png]
Figure 6
Figure 6. Figure 6: MetaAction Based LLM Command Workflow Since AI-CDA4ALL has access to low level vehicle data and controls, a driving assistant can be created to send control command to the low level motion controller using API specified by the prompt. As vision language model gains in …
Figure 7
Figure 7. Figure 7: Example of Vision Language Model (GPT4o-mini) advisory [PITH_FULL_IMAGE:figures/full_fig_p006_7.png]
Figure 9
Figure 9. Figure 9: Advisory Speed Application In a Toyota RAV4 [PITH_FULL_IMAGE:figures/full_fig_p007_9.png]
Figure 8
Figure 8. Figure 8: Screenshot of FDOT Traffic Report As described before in section IV-A, DOT and other transportation agencies may push a advisory speed and using methods we proposed to command the control flow to the vehicles along a specific route to reduce congestion or enhance safet…
Figure 10
Figure 10. Figure 10: Example of Toll Road Use case REFERENCES [1] Comma.ai, “Opendbc,” https://github.com/commaai/opendbc, 2016. [2] ——, “Openpilot,” https://github.com/commaai/openpilot, 2016. [3] S. Kato, S. Tokunaga, Y. Maruyama, S. Maeda, M. Hirabayashi, Y. Kitsukawa, A. Monrroy, T. A…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

38 extracted references · 29 canonical work pages

  1. [1]

    Opendbc,

    Comma.ai, “Opendbc,” https://github.com/commaai/opendbc, 2016

  2. [2]

    Openpilot,

    ——, “Openpilot,” https://github.com/commaai/openpilot, 2016

  3. [3]

    Autoware on board: Enabling autonomous vehicles with embedded systems,

    S. Kato, S. Tokunaga, Y . Maruyama, S. Maeda, M. Hirabayashi, Y . Kitsukawa, A. Monrroy, T. Ando, Y . Fujii, and T. Azumi, “Autoware on board: Enabling autonomous vehicles with embedded systems,” in Proceedings of the 9th ACM/IEEE International Conference on Cyber- Physical Systems (ICCPS), 2018, pp. 287–296

  4. [4]

    Pc5-based cellular-v2x evolution and deployment,

    L. Miao, J. J. Virtusio, and K.-L. Hua, “Pc5-based cellular-v2x evolution and deployment,”Sensors, vol. 21, no. 3, 2021. [Online]. Available: https://www.mdpi.com/1424-8220/21/3/843

  5. [5]

    A survey of wi-fi 6: Technologies, advances, and challenges,

    E. Mozaffariahrar, F. Theoleyre, and M. Menth, “A survey of wi-fi 6: Technologies, advances, and challenges,”Future Internet, vol. 14, no. 10, 2022. [Online]. Available: https://www.mdpi.com/1999-5903/ 14/10/293

  6. [6]

    Autoagent: A fully-automated and zero-code framework for llm agents,

    J. Tang, T. Fan, and C. Huang, “Autoagent: A fully-automated and zero-code framework for llm agents,” 2025. [Online]. Available: https://arxiv.org/abs/2502.05957

  7. [7]

    J2735: V2x communications message set dictionary,

    S. International, “J2735: V2x communications message set dictionary,”

  8. [8]

    X-car: An experimental vehicle platform for connected autonomy research,

    G. Mehr, P. Ghorai, C. Zhang, A. Nayak, D. Patel, S. Sivashangaran, and A. Eskandarian, “X-car: An experimental vehicle platform for connected autonomy research,”IEEE Intelligent Transportation Systems Magazine, vol. 15, no. 2, p. 41–57, Mar. 2023. [Online]. Available: http://dx.doi.org/10.1109/MITS.2022.3168801

Show all 38 references
  1. [9]

    A survey of open-source autonomous driving systems and their impact on research,

    N. Aliane, “A survey of open-source autonomous driving systems and their impact on research,”Information, vol. 16, no. 4, 2025. [Online]. Available: https://www.mdpi.com/2078-2489/16/4/317

  2. [10]

    Othman, G

    B. Othman, G. De Nunzio, A. Sciarretta, D. Di Domenico, and C. Canudas-de Wit,Connectivity and Automation as Enablers for Energy-Efficient Driving and Road Traffic Management. Cham: Springer International Publishing, 2022, pp. 2337–2376. [Online]. Available: https://doi.org/10...

  3. [11]

    Cvip: A protocol for complex interactions among connected vehicles,

    B. H ¨afner, J. Jiru, K. Roscher, J. Ott, G. A. Schmitt, and Y . Sevilmis, “Cvip: A protocol for complex interactions among connected vehicles,” in2020 IEEE Intelligent Vehicles Symposium (IV), 2020, pp. 510–515

  4. [12]

    Real-time motion planning methods for autonomous on-road driving: State- of-the-art and future research directions,

    C. Katrakazas, M. Quddus, W.-H. Chen, and L. Deka, “Real-time motion planning methods for autonomous on-road driving: State- of-the-art and future research directions,”Transportation Research Part C: Emerging Technologies, vol. 60, pp. 416–442, 2015. [Online]. Available: https...

  5. [13]

    Cellular-v2x communications for platooning: Design and evaluation,

    G. Nardini, A. Virdis, C. Campolo, A. Molinaro, and G. Stea, “Cellular-v2x communications for platooning: Design and evaluation,” Sensors, vol. 18, no. 5, 2018. [Online]. Available: https://www.mdpi. com/1424-8220/18/5/1527

  6. [14]

    Gpt- driver: Learning to drive with gpt,

    J. Mao, Y . Qian, J. Ye, H. Zhao, and Y . Wang, “Gpt- driver: Learning to drive with gpt,” 2023. [Online]. Available: https://arxiv.org/abs/2310.01415

  7. [15]

    On the road with gpt-4v(ision): Early explorations of visual-language model on autonomous driving,

    L. Wen, X. Yang, D. Fu, X. Wang, P. Cai, X. Li, T. Ma, Y . Li, L. Xu, D. Shang, Z. Zhu, S. Sun, Y . Bai, X. Cai, M. Dou, S. Hu, B. Shi, and Y . Qiao, “On the road with gpt-4v(ision): Early explorations of visual-language model on autonomous driving,” 2023. [Online]. Available:...

  8. [16]

    Llm4drive: A survey of large language models for autonomous driving,

    Z. Yang, X. Jia, H. Li, and J. Yan, “Llm4drive: A survey of large language models for autonomous driving,” 2024. [Online]. Available: https://arxiv.org/abs/2311.01043

  9. [17]

    Langprop: A code optimization framework using large language models applied to driving,

    S. Ishida, G. Corrado, G. Fedoseev, H. Yeo, L. Russell, J. Shotton, J. F. Henriques, and A. Hu, “Langprop: A code optimization framework using large language models applied to driving,” 2024. [Online]. Available: https://arxiv.org/abs/2401.10314

  10. [18]

    Nexar one dashcam,

    N. USA, “Nexar one dashcam,” 2021. [Online]. Available: https: //www.getnexar.com/the-dash-cams/nexar-one/

  11. [19]

    Gomotive dashcam,

    gomotive.com, “Gomotive dashcam,” 2022. [Online]. Available: https://gomotive.com/products/dashcam/

  12. [20]

    Video-based safety — ai dash cams — samsara,

    S. Inc., “Video-based safety — ai dash cams — samsara,”

  13. [21]

    Cw - visionconnect,

    C. LLC., “Cw - visionconnect,” Jun 2024. [Online]. Available: https://vision2x.com/

  14. [22]

    Available: https://www.samsara.com/products/safety/ dash-cam

    [Online]. Available: https://www.samsara.com/products/safety/ dash-cam

  15. [23]

    The opencda open-source ecosystem for cooperative driving automation research,

    R. Xu, H. Xiang, X. Han, X. Xia, Z. Meng, C.-J. Chen, and J. Ma, “The opencda open-source ecosystem for cooperative driving automation research,” 2023. [Online]. Available: https://arxiv.org/abs/2301.07325

  16. [24]

    Opencda: An open cooperative driving automation framework integrated with co-simulation,

    R. Xu, Y . Guo, X. Han, X. Xia, H. Xiang, and J. Ma, “Opencda: An open cooperative driving automation framework integrated with co-simulation,” in2021 IEEE International Intelligent Transportation Systems Conference (ITSC), 2021, pp. 1155–1162

  17. [25]

    Logitech,

    Logitech, “Logitech,” 2025. [Online]. Available: https://www.logitech. com/en-ch/shop/p/c920-pro-hd-webcam.960-001055

  18. [26]

    Nvidia jetson orin

    NVIDIA, “Nvidia jetson orin.” [Online]. Available: https: //www.nvidia.com/en-us/autonomous-machines/embedded-systems/ jetson-orin/

  19. [27]

    A survey on mqtt: a protocol of internet of things (iot),

    D. Soni and A. Makwana, “A survey on mqtt: a protocol of internet of things (iot),” inInternational conference on telecommunication, power analysis and computing techniques (ICTPACT-2017), vol. 20, 2017, pp. 173–177

  20. [28]

    Openwakeword,

    dscripka, “Openwakeword,” https://github.com/dscripka/ openWakeWord, 2022

  21. [29]

    Rabbitmq

    Broadcom, “Rabbitmq.” [Online]. Available: https://www.rabbitmq. com/

  22. [30]

    Vulnerabilities and limitations of mqtt protocol used between iot devices,

    D. Dinculean ˘a and X. Cheng, “Vulnerabilities and limitations of mqtt protocol used between iot devices,”Applied Sciences, vol. 9, no. 5,

  23. [31]

    Design and implementation of a real-time crowd monitoring system based on public wi-fi infrastructure: A case study on the sri chiang mai smart city,

    T. Wiangwiset, C. Surawanitkun, W. Wongsinlatam, T. Remsungnen, A. Siritaratiwat, C. Srichan, P. Thepparat, W. Bunsuk, A. Kaewchan, and A. Namvong, “Design and implementation of a real-time crowd monitoring system based on public wi-fi infrastructure: A case study on the sri c...

  24. [32]

    Rfc 9000: Quic: A udp-based multiplexed and secure transport

    J. Iyengar and M. Thomson, “Rfc 9000: Quic: A udp-based multiplexed and secure transport.” [Online]. Available: https: //datatracker.ietf.org/doc/rfc9000/

  25. [33]

    An experimental comparative perfor- mance study of different wifi standards for smart cities outdoor envi- ronments,

    I. ElKassabi and A. Abdrabou, “An experimental comparative perfor- mance study of different wifi standards for smart cities outdoor envi- ronments,” in2022 IEEE 13th Annual Ubiquitous Computing, Elec- tronics and Mobile Communication Conference (UEMCON), 2022, pp. 0450–0455

  26. [34]

    Openlka: an open dataset of lane keeping assist from market autonomous vehicles,

    Y . Wang, A. Alhuraish, S. Yuan, S. Wang, and H. Zhou, “Openlka: an open dataset of lane keeping assist from market autonomous vehicles,” 2025. [Online]. Available: https://arxiv.org/abs/2501.03287

  27. [37]

    Unifi u7 outdoor - tech specs,

    U. Network, “Unifi u7 outdoor - tech specs,” 2025. [Online]. Available: https://techspecs.ui.com/unifi/wifi/u7-outdoor?subcategory= wifi-outdoor

  28. [2019]

    Available: https://www.mdpi.com/2076-3417/9/5/848

    [Online]. Available: https://www.mdpi.com/2076-3417/9/5/848

  29. [2023]

    Available: https://www.mdpi.com/2624-6511/6/2/48

    [Online]. Available: https://www.mdpi.com/2624-6511/6/2/48

  30. [2024]

    Available: https://www.sae.org/standards/content/ j2735 202409/

    [Online]. Available: https://www.sae.org/standards/content/ j2735 202409/

Pith tools

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