Pith. sign in

REVIEW 3 major objections 5 minor 1 cited by

FixDrive: Automatically Repairing Autonomous Vehicle Driving Behaviour for $0.08 per Violation

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

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

Pith's one-line read Two driving-failure snapshots yield fix rules at $0.08 each

desk verdict A genuinely new offline AV repair pipeline with honest per-run success rates, but the headline cost-per-violation claim needs to account for drawing multiple candidates before finding a working fix. read the letter →

arxiv 2502.08260 v1 pith:QU5K2T4E submitted 2025-02-12 cs.SE

Yang Sun , Christopher M. Poskitt , Kun Wang , Jun Sun This is my paper · ORCID
classification cs.SE
keywords autonomousdrivingstrategyrepairmultimodallargelanguagemodeldomain-specificsignaltemporallogicrobustnessdegreezero-shotlearningnear-missdetection
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

FixDrive tries to turn a single bad driving record into a permanent, readable repair. From an incident log it automatically picks the near-miss moment and the violation moment, renders those two instants as images, and asks a multimodal large language model to write a small µDrive program: event-triggered rules such as "when a vehicle is within 10 metres ahead, increase following distance." In benchmark scenarios where the base autonomous driving system violated traffic laws, collided, or got stuck, the generated repairs let the vehicle pass every tested run, and the repair scripts also transferred to a broader set of simulator scenarios without causing new accidents. The intended payoff is practical: the repair is produced offline, is human-readable, and costs about $0.08 and under 15 minutes per violation, so repeated sampling to handle the model's randomness is affordable.

What carries the argument

The load-bearing mechanism is the pairing of robustness-guided critical-moment selection with structured multimodal generation. FixDrive computes the robustness degree $\rho(\varphi,\pi,t)$ of the driving trace against a Signal Temporal Logic property, then scans prefixes to find the first time the robustness drops below zero (violation moment) and the first time it drops below a threshold $\delta$ (near-miss moment). Rendering those two instants as annotated top-down scenes lets the multimodal language model reason from the same spatial information a human driver would use; a text prompt adds weather, the violated rule, and the time gap between frames. Finally, function calling with a JSON schema derived from the µDrive grammar forces the model's reply into syntactically valid rule programs, making the repair directly executable by the planning module.

What would settle it

Take a violation whose cause is invisible in both selected frames, for example a wrong lane choice made several seconds earlier or a misprediction of another vehicle's intent, and run the pipeline 20 times. If no generated µDrive program passes the specification in simulation, or if the fix rate stays low even after tuning the near-miss threshold $\delta$, the two-frame assumption is not sufficient and the central claim fails.

Watch

Extended reading notes

Core claim

The paper's central claim is that a multimodal large language model, prompted with exactly two automatically chosen frames from a driving record and a short text description of the violated rule, can write correct and generalisable high-level driving repairs without any task-specific training. The two frames are found by quantitative robustness evaluation of a Signal Temporal Logic specification: the violation moment is the earliest prefix whose robustness becomes non-positive, and the near-miss moment is the earliest prefix whose robustness falls below a tunable threshold. The model's free-text output is constrained by a JSON schema for the µDrive grammar, so every generated program is syntactically valid and can be loaded directly into the autonomous driving stack's planning module. In the paper's evaluation, the repaired vehicle satisfied every tested property, including yielding, speed-limit, and red-light rules, where the original system often failed, and the same repair scripts improved completion and accident counts across 269 supplied scenarios. The authors therefore conclude that offline, interpretable strategy repair is possible at negligible direct cost.

Load-bearing premise

The load-bearing premise is that a single large language model, looking at only two still images of an incident plus a short text prompt, can infer the correct generalisable driving rule without ever seeing the full trajectory or the planner's internal state.

Editorial extensions

If this is right

  • Repairs generalise beyond the incident that produced them: the programs written for eight benchmark violations also improved journey completion and reduced accidents across 269 official simulator scenarios.
  • The repair output is inspectable: each fix is a small set of trigger-condition-action rules in µDrive, so a user can see exactly what driving behaviour changed and why.
  • Vision is essential to the method: swapping the two images for textual descriptions of the same moments cut the fix rate sharply, in some scenarios from 30% to 5% or from 50% to 0%.
  • Repeated sampling is affordable enough to be the mitigation for generative randomness: at roughly $0.08 per query, generating 20 repair candidates per scenario costs a small amount in total, which the paper uses to report stable effectiveness.
  • Because the repair runs offline and only adjusts planning parameters, it avoids the online latency of language-model-driven driving while still improving law compliance and collision avoidance.

Reading between the lines

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

  • Beyond the paper: giving the model more than two frames, such as a short video clip or a small set of frames bracketing the near-miss, would test whether the low fix rates in some scenarios (15–30%) come from missing context rather than from the model's reasoning.
  • Beyond the paper: the $0.08 figure is tied to the commercial model's current API pricing, so the cost claim should be read as a point estimate for the tested model and pricing era, not a permanent property of the approach.
  • Beyond the paper: the same localize-then-ask recipe could apply to other embodied systems with a rule DSL and a robustness monitor, such as robots or drones, provided they can render interpretable snapshots and constrain the model output by schema.
  • Beyond the paper: the generalisation evidence comes from a finite set of simulated scenarios; a stronger test would involve unseen maps, adversarial traffic behaviour, and real-world logs, which the paper does not provide.
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

3 major / 5 minor

Summary. FixDrive is an offline repair pipeline for autonomous-vehicle (AV) driving behaviour. Given a record of an Apollo scenario that violates an STL property (a traffic law, no-collision, or journey completion), FixDrive computes robustness values, identifies the violation moment and a near-miss moment, visualises those two moments as screenshots, and asks GPT-4 Turbo to return a µDrive rule via a JSON-Schema-constrained function call. The rule is then applied to Apollo and tested in the simulator. Across eight violation scenarios the paper reports Fix rates of 15--100%, a Pass column of 100%, improved completion and accident counts on Apollo's official scenario suites, and an analysis cost of under 15 minutes and $0.08 per violation. The reported numbers, however, depend on a post hoc selection of the most frequently successful generated suggestion, and the $0.08 figure is the cost of a single LLM query rather than of obtaining a verified repair.

Significance. If the pipeline works at the reported per-success cost, FixDrive would be a valuable contribution to offline, interpretable AV repair: it couples an MLLM with a structured-output DSL, builds on the authors' LawBreaker and µDrive components, and provides an artifact repository. The two-critical-moment visualisation idea is sensible, and RQ4 gives initial evidence that images outperform text. The reviewer agrees with the stress-test assessment: the central evaluation weaknesses are load-bearing. The Pass metric is circular, the Fix rates are the true per-generation success rates, the δ threshold is chosen in-sample, and the cost headline understates the expected cost of a verified repair under the paper's own 20-query protocol. These issues can be addressed in a revision, and the corrected claims may still be useful, but as written the abstract and RQ1 overstate what the experiments demonstrate.

major comments (3)
  1. [§IV-B, Tables I and V] The headline success and cost figures are not supported by the stated protocol. The 'Pass' column is 100% by construction because it is defined as the success rate of 'effective' suggestions, and the 'Robustness' values are computed after selecting the most frequently successful suggestion from 20 generated scripts. The actual per-generation success rates are the 'Fix' rates (30%, 50%, 45%, 100%, 20%, 100%, 50%, 15%). Table V's $0.079 is the API cost of one query, not the cost of obtaining a verified repair. Under the paper's own protocol of always generating 20 suggestions, the direct API cost per scenario is about $1.58 (20 × $0.079), plus simulator verification; if one instead samples until the first success, the expected cost for S8 is about $0.53. The abstract's '$0.08 per violation' is therefore misleading and should be restated as '$0.08 per generated candidate' or amortised per verified repair.
  2. [§IV-B, Table II] The near-miss threshold δ is a free parameter that is selected in-sample. Table II sweeps δ from 1 to 30 over the eight evaluation scenarios and chooses δ=15 because it yields a tick for every scenario. No held-out scenarios or validation set are used, and the paper reports no sensitivity analysis beyond this selection. As a result, the Fix and Robustness values in Table I are optimistically biased, and the claimed generality of the repairs cannot be assessed. The authors should either run the evaluation on a separate set of scenarios with δ fixed, or present the results as a sensitivity analysis without selecting the threshold on the test data.
  3. [§IV-B, RQ2 and Table III] The claim that repairs generalise beyond the tested incidents rests on weak evidence. The paper applies all 22 generated repair programs to Apollo's official scenarios and reports aggregate Finish/Accident counts (Table III), but there is no non-trivial baseline, no per-scenario breakdown, and no statistical analysis. The observed differences are small (San Mateo: +1 finish, same accident count; Sunnyvale: +4 finishes, −1 accident). Without a control condition (e.g., simply increasing following/overtaking distances in Apollo), the improvements cannot be attributed to the MLLM-generated rules. The authors should provide per-scenario results and a baseline comparison.
minor comments (5)
  1. [§II-B, Definition 2] The satisfaction notation 'π ⊨ φ' is written with a free time variable t; it should be ρ(φ, π, 0) > 0 (and similarly for the violation condition), since ρ(φ, π) is already defined for t=0.
  2. [§IV-B, Table II] The tick criterion ('within 10 queries') is inconsistent with the 20-query protocol used to compute the Fix column in Table I; the denominator and stopping rule should be stated and kept uniform.
  3. [§IV-B, Table V] The row labelled 'localisation' for S7 is missing the 's' unit, and the 'overall time' excludes simulator verification; the caption should state what is and is not included.
  4. [§III-B] The prompt-generation description does not explain how the '4 seconds later' gap in the sequence prompt is chosen; it should be derived from the located violation and near-miss time steps.
  5. [§IV-B, RQ1] The sentence 'the threshold for FixDrive is set to 15, determined by an empirical experiment discussed later in this section' previews the result of Table II before the experiment is described; move the threshold-selection discussion before the main results.

Circularity Check

3 steps flagged · score 6.0 of 10

Reported '100% Pass' and '$0.08 per violation' are constructed by metric definition and post-hoc selection, while the δ threshold is fitted to the same scenarios used for evaluation; independent evidence remains in the Fix rates and RQ2 generalization.

  1. self definitional [Section IV-B (RQ1), Table I explanation]
    "The 'Pass' column indicates the proportion of runs that comply with traffic rules. It signifies the success rate of each effective suggestion, which is always 100% for FIXDRIVE . ... Therefore, we select the most frequently successful suggestion to determine the final values in the 'Pass' and 'Robustness' column."

    An 'effective suggestion' is defined as one that already passed the simulation, so Pass is the pass rate of pre-selected successful suggestions: 100% by construction. The additional selection of the most frequently successful suggestion (best-of-20 post hoc) means the Pass and Robustness columns do not measure the per-generation success rate of the repair pipeline. The paper's claim that 'the repairs by FIXDRIVE enable the AV to completely avoid accidents and violations' is thus not supported by Pass as an independent number; the honest per-suggestion rates are the Fix column (30%, 50%, 45%, 100%, 20%, 100%, 50%, 15%).

  2. fitted input called prediction [Section III-A (near-miss threshold) and Section IV-B (RQ1, Table II)]
    "Note that the threshold for F IXDRIVE is set to 15, determined by an empirical experiment discussed later in this section. ... If F IXDRIVE can provide driving strategy repairs that help the A V resolve the encountered problem, i.e. satisfy the corresponding specification within 10 queries, we mark it with a ✓."

    The near-miss threshold δ is a free parameter of problem localisation; Section III-A says it 'is determined empirically in our evaluation'. Table II sweeps δ from 1 to 30 over the same eight scenarios, and δ=15 is the only tested value yielding ✓ for all of them. RQ1 then reports Fix/Pass/Robustness on those same eight scenarios with δ=15. The effectiveness numbers are therefore not predictions from a fixed pipeline on unseen cases; they are conditioned on a parameter selected by looking at the test outcomes, i.e. the input is fitted to the data whose success it is used to report.

1 more flagged steps
  1. self definitional [Abstract; Section IV-B (RQ3, Table V); Section IV-B ('Fix' column definition)]
    "Furthermore, the direct costs of repairing an AV—15 minutes of offline analysis and $0.08 per violation—are reasonable in practice. ... A driving strategy repair is deemed successful only if it ensures that the A V causes no violations. ... This indicates that each driving suggestion costs less than $0.08, making it affordable, as shown in the last row of the table."

    The abstract's 'cost per violation' is the API cost of a single driving suggestion (Table V), while a 'repair' is defined as a suggestion that successfully removes violations. Because the Fix rate is below 100% in most scenarios (e.g. 30% in S1, 20% in S5, 15% in S8), the expected API cost per successful repair is $0.08/p (roughly $0.27–$0.53 for those scenarios) plus simulator verification, or about $1.6 if the full 20-query protocol is always run. The headline metric relabels a per-suggestion cost as a per-repair cost by definition, understating the cost of actually repairing a violation.

full rationale

FixDrive is an empirical MLLM-based repair pipeline rather than a mathematical derivation, so most of its chain is not circular. Reusing LawBreaker and µDrive from the same research group is implementation reuse with independent evaluation in Apollo, not a load-bearing self-citation of an unverified theorem. However, three reported quantities do reduce by construction or by post-hoc selection. The 100% Pass column is the success rate of 'effective' suggestions, i.e. suggestions that already passed, and then the most frequent successful suggestion is chosen, making the headline 'completely avoid accidents' tautological relative to the metric. The $0.08-per-violation figure is the cost of a single query, not of a successful repair, so it relabels a per-suggestion cost as a per-violation cost without dividing by the Fix rate. Finally, the near-miss threshold δ is selected by scanning Table II for the value that makes all eight benchmark scenarios pass, and the same scenarios are used to report the main results, so the reported effectiveness is a fitted-input success rather than an independent prediction. These issues are partial: the per-suggestion Fix rates are honestly reported, and RQ2's generalization across official Apollo scenarios (Sunnyvale, San Mateo, Apollo Virtual) provides external evidence that selected repairs can help. The central idea is not circular by construction, but the headline effectiveness and cost claims are partly manufactured by metric definition and test-set tuning.

Assumptions & free parameters 1 free parameters · 5 assumptions · 0 invented entities

The central pipeline rests on a small number of free parameters and several domain assumptions. The main free parameter is the near-miss threshold δ, which is tuned on the evaluation data. The framework also assumes that the Apollo simulator, the µDrive DSL, the LawBreaker specifications, and GPT-4's zero-shot synthesis all behave as expected. No new physical entities are introduced.

free parameters (1)
  • Near-miss threshold δ = 15
    Defines how far below the STL robustness bound a trace must fall to mark the near-miss moment. Set to 15 based on an empirical experiment over the eight benchmark scenarios; Table II shows the result is sensitive to this value.
assumptions (5)
  • standard math The quantitative semantics of STL (from Maler and Nickovic, Deshmukh et al.) correctly measures the closeness of a trace to violation.
    Invoked in Definition 2 and used for moment localization in Section III-A.
  • domain assumption Apollo 9.0 and its Dreamview Plus simulator faithfully reproduce the ego vehicle's dynamics, perception, and traffic environment.
    All evaluations are performed in this simulator; the framework's effectiveness is measured only there (Section IV-A, IV-B).
  • domain assumption The µDrive DSL and its Apollo backend correctly apply the generated rules to the planner's parameters at runtime.
    FixDrive inherits µDrive from prior work [34] by the same authors; the paper does not re-validate the backend.
  • domain assumption GPT-4 Turbo can generate syntactically valid and semantically useful µDrive programs from two static images plus text in a zero-shot setting.
    This is the core empirical assumption of the approach; the low Fix rates suggest it holds only partially (Section IV-B).
  • domain assumption The traffic-law formalizations adopted from LawBreaker [8] are faithful to the Chinese regulations they encode.
    Used to define the legal properties evaluated in RQ1 (Section II-B, IV-B).

how reviews work

0 comments
Cite this review

Pith. "Pith review of FixDrive: Automatically Repairing Autonomous Vehicle Driving Behaviour for $0.08 per Violation." pith.science (2026). https://pith.science/paper/QU5K2T4E

@misc{pith2026250208260,
  author       = {Pith},
  title        = {Pith review of: FixDrive: Automatically Repairing Autonomous Vehicle Driving Behaviour for $0.08 per Violation},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/QU5K2T4E}},
  note         = {Machine review of arXiv:2502.08260}
}
abstract

Autonomous Vehicles (AVs) are advancing rapidly, with Level-4 AVs already operating in real-world conditions. Current AVs, however, still lag behind human drivers in adaptability and performance, often exhibiting overly conservative behaviours and occasionally violating traffic laws. Existing solutions, such as runtime enforcement, mitigate this by automatically repairing the AV's planned trajectory at runtime, but such approaches lack transparency and should be a measure of last resort. It would be preferable for AV repairs to generalise beyond specific incidents and to be interpretable for users. In this work, we propose FixDrive, a framework that analyses driving records from near-misses or law violations to generate AV driving strategy repairs that reduce the chance of such incidents occurring again. These repairs are captured in {\mu}Drive, a high-level domain-specific language for specifying driving behaviours in response to event-based triggers. Implemented for the state-of-the-art autonomous driving system Apollo, FixDrive identifies and visualises critical moments from driving records, then uses a Multimodal Large Language Model (MLLM) with zero-shot learning to generate {\mu}Drive programs. We tested FixDrive on various benchmark scenarios, and found that the generated repairs improved the AV's performance with respect to following traffic laws, avoiding collisions, and successfully reaching destinations. Furthermore, the direct costs of repairing an AV -- 15 minutes of offline analysis and $0.08 per violation -- are reasonable in practice.

Figures

Figures reproduced from arXiv: 2502.08260 by the authors.

Figure 2
Figure 2. Specification language syntax, where ϕ, ϕ1 and ϕ2 are STL formulas, I is an interval, and f is a multivariate linear continuous function over language variables xi journey completion. FIXDRIVE provided effective general driving strategy repairs that helped the ADS successfully nav￾igate these problematic scenarios without adversely affecting performance in normal scenarios. Additionally, FIXDRIVE consistently genera… view at source ↗
Figure 3
Figure 3. Abstract syntax of µDrive programs B. Specifying Safety Properties In the context of AVs, safety should not simply mean the absence of collisions, but also adherence to the rules of the road that drivers are supposed to abide by. To that end, we adopt the property specification language used by LawBreaker [8], as well as the project’s existing specifications of the traffic laws of China and Singapore. The specificat… view at source ↗
Figure 5
Figure 5. Visualisation of a scenario, which is provided to the MLLM along with an ‘overall prompt’ [PITH_FULL_IMAGE:figures/full_fig_p006_5.png] view at source ↗
Figures from the paper (1 more)
Figure 6
Figure 6. Figure 6: µDRIVE driving strategy repair scripts for S1 likelihood of imminent violation. A value less than or equal to 0 indicates a violation of the corresponding traffic rule. Furthermore, if a regulation comprises multiple sub-rules, the robustness for each sub-rule is seque…

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. ADReFT: Adaptive Decision Repair for Safe Autonomous Driving via Reinforcement Fine-Tuning

    cs.LG 2025-06 conditional novelty 6.0 of 10

    A two-stage trained transformer module, ADReFT, repairs unsafe autonomous driving decisions at runtime, fixing more collisions with smaller interventions than rule-based and anomaly baselines.

Reference graph

Works this paper leans on

49 extracted references · 43 canonical work pages · cited by 1 Pith paper

  1. [1]

    Taxonomy and definitions for terms related to driving automation systems for on- road motor vehicles,

    SAE On-Road Automated Vehicle Standards Committee, “Taxonomy and definitions for terms related to driving automation systems for on- road motor vehicles,” SAE International: Warrendale, PA, USA , 2021

    work page 2021

  2. [2]

    (2025) Waymo Driver

    Waymo. (2025) Waymo Driver. https://waymo.com/waymo-driver/. On- line; accessed Feb 2025

    work page 2025

  3. [3]

    (2025) Apollo

    Baidu. (2025) Apollo. https://www.apollo.auto/. Online; accessed Feb 2025

    work page 2025

  4. [4]

    (2024) Autonomous driving technology designed for trucks

    TuSimple. (2024) Autonomous driving technology designed for trucks. https://www.tusimple.com/technology/. Online; accessed Nov 2024

    work page 2024

  5. [5]

    Too afraid to drive: Systematic discovery of semantic DoS vulnerability in autonomous driving planning under physical-world attacks,

    Z. Wan, J. Shen, J. Chuang, X. Xia, J. Garcia, J. Ma, and Q. A. Chen, “Too afraid to drive: Systematic discovery of semantic DoS vulnerability in autonomous driving planning under physical-world attacks,” in NDSS. The Internet Society, 2022

    work page 2022

  6. [6]

    DeepCrashTest: Turning dashcam videos into virtual crash tests for automated driving systems,

    S. K. Bashetty, H. B. Amor, and G. Fainekos, “DeepCrashTest: Turning dashcam videos into virtual crash tests for automated driving systems,” in ICRA. IEEE, 2020, pp. 11 353–11 360

    work page 2020

  7. [7]

    A V-FUZZER: Finding safety violations in autonomous driving systems,

    G. Li, Y . Li, S. Jha, T. Tsai, M. B. Sullivan, S. K. S. Hari, Z. Kalbarczyk, and R. K. Iyer, “A V-FUZZER: Finding safety violations in autonomous driving systems,” in ISSRE. IEEE, 2020, pp. 25–36

    work page 2020

  8. [8]

    LawBreaker: An approach for specifying traffic laws and fuzzing autonomous vehicles,

    Y . Sun, C. M. Poskitt, J. Sun, Y . Chen, and Z. Yang, “LawBreaker: An approach for specifying traffic laws and fuzzing autonomous vehicles,” in ASE. ACM, 2022, pp. 62:1–62:12

    work page 2022

Show all 49 references
  1. [9]

    Specification-based autonomous driving system testing,

    Y . Zhou, Y . Sun, Y . Tang, Y . Chen, J. Sun, C. M. Poskitt, Y . Liu, and Z. Yang, “Specification-based autonomous driving system testing,”IEEE Trans. Software Eng., vol. 49, no. 6, pp. 3391–3410, 2023

    2023

  2. [10]

    REDriver: Runtime enforcement for autonomous vehicles,

    Y . Sun, C. M. Poskitt, X. Zhang, and J. Sun, “REDriver: Runtime enforcement for autonomous vehicles,” in ICSE. ACM, 2024, pp. 176:1–176:12

    2024

  3. [11]

    Assuring the safety of end-to-end learning-based autonomous driving through runtime monitoring,

    J. Grieser, M. Zhang, T. Warnecke, and A. Rausch, “Assuring the safety of end-to-end learning-based autonomous driving through runtime monitoring,” in DSD. IEEE, 2020, pp. 476–483

    2020

  4. [12]

    A VGuardian: Detecting and mitigating publish- subscribe overprivilege for autonomous vehicle systems,

    D. K. Hong, J. Kloosterman, Y . Jin, Y . Cao, Q. A. Chen, S. A. Mahlke, and Z. M. Mao, “A VGuardian: Detecting and mitigating publish- subscribe overprivilege for autonomous vehicle systems,” in EuroS&P. IEEE, 2020, pp. 445–459

    2020

  5. [13]

    Guardauto: A decentralized runtime protection system for autonomous driving,

    K. Cheng, Y . Zhou, B. Chen, R. Wang, Y . Bai, and Y . Liu, “Guardauto: A decentralized runtime protection system for autonomous driving,” IEEE Trans. Computers, vol. 70, no. 10, pp. 1569–1581, 2021

    2021

  6. [14]

    Formal runtime monitoring approaches for autonomous vehicles,

    S. Shankar, U. V . R, S. Pinisetty, and P. S. Roop, “Formal runtime monitoring approaches for autonomous vehicles,” in OVERLAY’20, ser. CEUR Workshop Proceedings, vol. 2785. CEUR-WS.org, 2020, pp. 89–94

    2020

  7. [15]

    Assuring the safety of advanced driver assistance systems through a combination of simulation and runtime monitoring,

    M. Mauritz, F. Howar, and A. Rausch, “Assuring the safety of advanced driver assistance systems through a combination of simulation and runtime monitoring,” in ISoLA (2) , ser. LNCS, vol. 9953, 2016, pp. 672–687

    2016

  8. [16]

    LOLA: Run- time monitoring of synchronous systems,

    B. D’Angelo, S. Sankaranarayanan, C. S ´anchez, W. Robinson, B. Finkbeiner, H. B. Sipma, S. Mehrotra, and Z. Manna, “LOLA: Run- time monitoring of synchronous systems,” in TIME. IEEE Computer Society, 2005, pp. 166–174

    2005

  9. [17]

    Runtime monitoring for safety of intelligent vehicles,

    K. Watanabe, E. Kang, C. Lin, and S. Shiraishi, “Runtime monitoring for safety of intelligent vehicles,” in DAC. ACM, 2018, pp. 31:1–31:6

    2018

  10. [18]

    End-to- end autonomous driving: Challenges and frontiers,

    L. Chen, P. Wu, K. Chitta, B. Jaeger, A. Geiger, and H. Li, “End-to- end autonomous driving: Challenges and frontiers,” IEEE Trans. Pattern Anal. Mach. Intell. , vol. 46, no. 12, pp. 10 164–10 183, 2024

    2024

  11. [19]

    Multi-modal fusion transformer for end-to-end autonomous driving,

    A. Prakash, K. Chitta, and A. Geiger, “Multi-modal fusion transformer for end-to-end autonomous driving,” in CVPR. Computer Vision Foundation / IEEE, 2021, pp. 7077–7087

    2021

  12. [20]

    Extracting human-like driving behaviors from expert driver data using deep learning,

    K. Sama, Y . Morales, H. Liu, N. Akai, A. Carballo, E. Takeuchi, and K. Takeda, “Extracting human-like driving behaviors from expert driver data using deep learning,” IEEE Trans. Veh. Technol., vol. 69, no. 9, pp. 9315–9329, 2020

    2020

  13. [21]

    A learning-based autonomous driver: Emulate human driver’s intelligence in low-speed car following,

    J. Wei, J. M. Dolan, and B. Litkouhi, “A learning-based autonomous driver: Emulate human driver’s intelligence in low-speed car following,” in Unattended Ground, Sea, and Air Sensor Technologies and Applica- tions XII, vol. 7693. SPIE, 2010, pp. 93–104

    2010

  14. [22]

    Establishing style-oriented driver models by imitating human driving behaviors,

    L. Xu, J. Hu, H. Jiang, and W. Meng, “Establishing style-oriented driver models by imitating human driving behaviors,”IEEE Trans. Intell. Transp. Syst., vol. 16, no. 5, pp. 2522–2530, 2015

    2015

  15. [23]

    Learning from naturalistic driving data for human-like autonomous highway driving,

    D. Xu, Z. Ding, X. He, H. Zhao, M. Moze, F. Aioun, and F. Guillemard, “Learning from naturalistic driving data for human-like autonomous highway driving,” IEEE Trans. Intell. Transp. Syst. , vol. 22, no. 12, pp. 7341–7354, 2021

    2021

  16. [24]

    A survey on imitation learning techniques for end-to-end autonomous vehicles,

    L. Le Mero, D. Yi, M. Dianati, and A. Mouzakitis, “A survey on imitation learning techniques for end-to-end autonomous vehicles,” IEEE Trans. Intell. Transp. Syst. , vol. 23, no. 9, pp. 14 128–14 147, 2022

    2022

  17. [25]

    Language models are few-shot learners,

    T. B. Brown, B. Mann, N. Ryder, M. Subbiah, J. Kaplan, P. Dhariwal, A. Neelakantan, P. Shyam, G. Sastry, A. Askell, S. Agarwal, A. Herbert- V oss, G. Krueger, T. Henighan, R. Child, A. Ramesh, D. M. Ziegler, J. Wu, C. Winter, C. Hesse, M. Chen, E. Sigler, M. Litwin, S. Gray, B...

    2020

  18. [26]

    GPT-4 technical report,

    OpenAI, “GPT-4 technical report,” CoRR, vol. abs/2303.08774, 2023

    2023 arXiv

  19. [27]

    A survey on multimodal large language models,

    S. Yin, C. Fu, S. Zhao, K. Li, X. Sun, T. Xu, and E. Chen, “A survey on multimodal large language models,” CoRR, vol. abs/2306.13549, 2023

    2023 arXiv

  20. [28]

    A survey on multimodal large language models for autonomous driving,

    C. Cui, Y . Ma, X. Cao, W. Ye, Y . Zhou, K. Liang, J. Chen, J. Lu, Z. Yang, K. Liao, T. Gao, E. Li, K. Tang, Z. Cao, T. Zhou, A. Liu, X. Yan, S. Mei, J. Cao, Z. Wang, and C. Zheng, “A survey on multimodal large language models for autonomous driving,” in WACV (Workshops). IEEE...

    2024

  21. [29]

    Driving with LLMs: Fusing object- level vector modality for explainable autonomous driving,

    L. Chen, O. Sinavski, J. H ¨unermann, A. Karnsund, A. J. Willmott, D. Birch, D. Maund, and J. Shotton, “Driving with LLMs: Fusing object- level vector modality for explainable autonomous driving,” in ICRA. IEEE, 2024, pp. 14 093–14 100

    2024

  22. [30]

    GPT-Driver: Learning to drive with GPT,

    J. Mao, Y . Qian, H. Zhao, and Y . Wang, “GPT-Driver: Learning to drive with GPT,” CoRR, vol. abs/2310.01415, 2023

    2023 arXiv

  23. [31]

    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,” CoRR, vol. abs/2311.05332, 2023

    2023 arXiv

  24. [32]

    Autoware.AI,

    Autoware.AI, “Autoware.AI,” www.autoware.ai/, 2025, online; accessed Feb 2025

    2025

  25. [33]

    A systematic study of automated program repair: Fixing 55 out of 105 bugs for $8 each,

    C. Le Goues, M. Dewey-V ogt, S. Forrest, and W. Weimer, “A systematic study of automated program repair: Fixing 55 out of 105 bugs for $8 each,” in ICSE. IEEE Computer Society, 2012, pp. 3–13

    2012

  26. [34]

    µDrive: User-controlled autonomous driving,

    K. Wang, C. M. Poskitt, Y . Sun, J. Sun, J. Wang, P. Cheng, and J. Chen, “ µDrive: User-controlled autonomous driving,” CoRR, vol. abs/2407.13201, 2024

    2024 arXiv

  27. [35]

    (2025) ChatGPT

    OpenAI. (2025) ChatGPT. https://openai.com. Online; accessed Feb 2025

    2025

  28. [36]

    Function calling,

    OpenAI, “Function calling,” https://platform.openai.com/docs/guides/ function-calling, 2025, online; accessed Feb 2025

    2025

  29. [37]

    Apollo 9.0,

    Baidu, “Apollo 9.0,” https://github.com/ApolloAuto/apollo/releases/tag/ v9.0.0, 2023, online; accessed Feb 2025

    2023

  30. [38]

    Monitoring temporal properties of contin- uous signals,

    O. Maler and D. Nickovic, “Monitoring temporal properties of contin- uous signals,” in FORMATS/FTRTFT, ser. LNCS, vol. 3253. Springer, 2004, pp. 152–166

    2004

  31. [39]

    PaLM- E: An embodied multimodal language model,

    D. Driess, F. Xia, M. S. M. Sajjadi, C. Lynch, A. Chowdhery, B. Ichter, A. Wahid, J. Tompson, Q. Vuong, T. Yu, W. Huang, Y . Chebotar, P. Sermanet, D. Duckworth, S. Levine, V . Vanhoucke, K. Hausman, M. Toussaint, K. Greff, A. Zeng, I. Mordatch, and P. Florence, “PaLM- E: An e...

    2023

  32. [40]

    ACA V: A frame- work for automatic causality analysis in autonomous vehicle accident recordings,

    H. Sun, C. M. Poskitt, Y . Sun, J. Sun, and Y . Chen, “ACA V: A frame- work for automatic causality analysis in autonomous vehicle accident recordings,” in ICSE. ACM, 2024, pp. 102:1–102:13

    2024

  33. [41]

    Robust online monitoring of signal temporal logic,

    J. V . Deshmukh, A. Donz ´e, S. Ghosh, X. Jin, G. Juniwal, and S. A. Seshia, “Robust online monitoring of signal temporal logic,” Formal Methods Syst. Des. , vol. 51, no. 1, pp. 5–30, 2017

    2017

  34. [42]

    RTAMT: Online robustness monitors from STL,

    D. Nickovic and T. Yamaguchi, “RTAMT: Online robustness monitors from STL,” in ATVA, ser. LNCS, vol. 12302. Springer, 2020, pp. 564– 571

    2020

  35. [43]

    Regulations for the implementation of the road traffic safety law of the People’s Republic of China,

    Chinese Government, “Regulations for the implementation of the road traffic safety law of the People’s Republic of China,” http://www.gov.cn/ gongbao/content/2004/content 62772.htm, 2021, online; accessed Feb 2025

    2004

  36. [44]

    FixDrive source code & supplementary materials,

    “FixDrive source code & supplementary materials,” 2025. [Online]. Available: https://github.com/lawbreaker2022/FixDrive2025

    2025

  37. [45]

    Dreamview Plus,

    Baidu, “Dreamview Plus,” https://github.com/ApolloAuto/apollo/tree/ master/modules/dreamview plus, 2024, online; accessed Feb 2025

    2024

  38. [46]

    Apollo Studio,

    Baidu, “Apollo Studio,” https://apollo.baidu.com/workspace, 2025, on- line; accessed Feb 2025

    2025

  39. [47]

    Tokenizer,

    OpenAI, “Tokenizer,” https://platform.openai.com/tokenizer, 2025, on- line; accessed Feb 2025

    2025

  40. [48]

    Towards fully autonomous driving: Systems and algorithms,

    J. Levinson, J. Askeland, J. Becker, J. Dolson, D. Held, S. Kammel, J. Z. Kolter, D. Langer, O. Pink, V . R. Pratt, M. Sokolsky, G. Stanek, D. M. Stavens, A. Teichman, M. Werling, and S. Thrun, “Towards fully autonomous driving: Systems and algorithms,” in Intelligent Vehicles...

    2011

  41. [49]

    A survey of autonomous driving: Common practices and emerging technologies,

    E. Yurtsever, J. Lambert, A. Carballo, and K. Takeda, “A survey of autonomous driving: Common practices and emerging technologies,” IEEE Access, vol. 8, pp. 58 443–58 469, 2020

    2020

Pith tools

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