Generalizing End-To-End Autonomous Driving In Real-World Environments Using Zero-Shot LLMs

In plain words

Most end-to-end driving models learn by copying a human driver, so they need many examples of every situation they might meet. This paper trains a small model on a very simple case: one traffic cone in a hallway, with the car steering left or right around it. On a harder hallway with several cones and bins, that small model alone drives badly.

The fix is to let a large multimodal language model look at the same camera image and answer one word: LEFT, MIDDLE or RIGHT. The language model is not retrained. It is only asked to reason step by step about where the free space is. The small model takes that word as a hint and still produces the steering and throttle itself. Because the language model is slow, the car keeps using the last word it received until a new one arrives.

In the authors' real-car tests, adding the hint raised the success rate on the harder course from 40% to between 63% and 83%, depending on the language model. These are the authors' own numbers from a small set of runs.

TL;DR

• A ViT-B/16 imitation model outputs steering and throttle per route class; a pretrained multimodal LLM, used zero-shot with chain-of-thought prompts, sends it a LEFT, MIDDLE or RIGHT instruction §2.1 app. B.1.
• The LLM runs slower than the car's sensor loop, so the policy reuses the cached instruction between answers §2.2.
• Trained only on a single-cone hallway, the policy alone succeeds 40% of the time on a harder course; with an LLM, 63% to 83% tab. 3 (author-reported).
• No fine-tuning of the LLM and no simulation; the evidence is 30 real runs per configuration on one course, with no code released.

Problem

Imitation-learning driving models need a large, varied dataset to generalise. With only the simple training data, the authors report that the policy fails when obstacles appear in new positions: it succeeds on the training layout but only 40% on the harder test course §3.3 tab. 3. Their small-scale study shows the same effect: a model trained with one obstacle in the middle lane succeeds 100% there, 44% with an extra obstacle in the left lane and 78% with one in the right lane app. A tab. 4. Collecting data for every such case is the cost they want to avoid §1.

Fine-tuning a large model on driving data, or running it at every control step, is impractical for them: the LLM answers in roughly 6 to 8 seconds on their hardware §3.2 tab. 2. The paper therefore assumes that the policy must act at sensor rate while the LLM answers only occasionally §1 §2.2. The paper assumes a real vehicle with a single front camera and no LiDAR or other sensor §3. Simulated closed-loop studies that rely on fine-tuned LLMs are discussed as the alternative they avoid §1.

Method

The system has two parts. An end-to-end policy takes the camera image and an instruction and outputs steering and throttle for every frame. A multimodal LLM takes the same image with a chain-of-thought prompt and outputs one of three instructions every few seconds, at its own pace §2.1 fig. 2 fig. 3.

Policy. The image is cropped and resized to 320 × 160 app. B.1. A pretrained ViT-B/16 encodes it app. B.1. Two heads read the features: one gives, for each of the three classes LEFT, MIDDLE and RIGHT, a steering and a throttle value (a 3 × 2 matrix); the other gives a probability for each class. The class is the route type: STRAIGHT is mapped to MIDDLE app. B.1. The classes replace the learned k-means clustering of the cited imitation design, because the action space here only has steering and throttle §2.1.

Training data. A person drives the car by hand around one cone, in both directions, and also straight when no obstacle is present. Images are stored at 60 frames per second with the expert steering and throttle as labels §3.1. The dataset has 60 routes; each route is labelled with its type, and the paper gives an average length of 100 without a unit app. B.2.

Training objective. For each sample the loss is the squared error on the steering and throttle of the labelled class plus a weighted cross-entropy term on the class probability app. B.3:

L(w; D) = (V_{y_c, 0} - y_s)^2 + (V_{y_c, 1} - y_t)^2 - k \log p_{y_c} app. B.3

Here y_s \in [-1, 1] is the steering label, y_t \in [0, 1] the throttle label and y_c \in \{1, 2, 3\} the route label app. B.3. The equation names the weight k, while the text names it w app. B.3. No value is stated.

Language model. No fine-tuning. The model receives the image and a chain-of-thought prompt that asks five sub-questions in order: identify the obstacles, locate them in the hallway, locate the free space between them and the wall, say which free space is larger, and output LEFT, MIDDLE or RIGHT tab. 1 app. D. The paper compares this with a naive prompt that asks only for the direction app. D. The prompt is written in the appendix as a context of two sentences plus the five questions app. D, prompt table.

Closed loop. The policy runs on every frame and uses the most recent LLM instruction. The LLM is run on a frame and its answer replaces the instruction when it arrives; while it is pending, the previous instruction is kept §2.2 fig. 3. The paper says the instruction rate depends on the LLM's speed §2.2 but does not give a schedule.

# Closed-loop driving with a cached LLM instruction  [§2.2] [fig. 3]
# Input: camera stream, LLM, policy
# Output: steering and throttle per camera frame

def drive(camera, llm, policy):
    # Initial instruction before the first LLM answer: not stated
    instruction = None
    # Ask the slow LLM about the newest frame with CoT  [tab. 1]
    pending = llm.ask(camera.latest(), cot_prompt)
    while driving:
        # Run the fast policy on every frame with the cached instruction
        # [§2.2]
        frame = crop_and_resize(camera.latest())    # (160, 320, 3)
        steering, throttle = policy(frame, instruction)
        send(steering, throttle)
        # Use a finished answer; keep the old instruction until then  [§2.2]
        if pending.is_ready():
            instruction = parse_direction(pending.answer())
            pending = llm.ask(camera.latest(), cot_prompt)

# Policy forward pass  [app. B.1] [app. B.4]
# Input: image (160, 320, 3); instruction in {LEFT, MIDDLE, RIGHT} or None
# Output: steering in [-1, 1]; throttle in [0, 1]

def policy(image, instruction):
    # Pretrained ViT-B/16 backbone  [app. B.1]
    features = vit_b16(image)
    # One (steering, throttle) row per class  [app. B.1]
    values = action_head(features)              # (3, 2)
    # Class probabilities; used only when no instruction is given  [app. B.1]
    probs = class_head(features)                # (3,)
    if instruction is None:
        # Images only: sample the class from the probability head  [app. B.4]
        instruction = sample_class(probs)
    # Row lookup for the instructed class; how the instruction enters the
    # network is not stated, so this reading is an inference  [app. B.1]
    steering, throttle = values[instruction]
    return steering, throttle

# Training loss for one labelled sample  [app. B.3]
# Input: image, steering in [-1, 1], throttle in [0, 1], route in {1, 2, 3}
# Output: scalar loss

def training_loss(image, steering, throttle, route):
    # Forward pass: values (3, 2), probs (3,)  [app. B.1] [app. B.3]
    values, probs = policy_network(image)
    # Index base of the route label is not stated; see Pitfalls  [app. B.3]
    steering_error = (values[route, 0] - steering) ** 2
    throttle_error = (values[route, 1] - throttle) ** 2
    # k in the equation, w in the text; value not stated  [app. B.3]
    class_error = -class_weight * log(probs[route])
    return steering_error + throttle_error + class_error

Hyperparameters

Results

Author-reported. Setup: real hallway on an RC car with an iPhone; training on the single-cone environment; test on the zigzag course with cones and trash bins and a wider road after the first cones; baseline is the policy alone (ViT only) §3.1 §3.3.

Main comparison tab. 3. Success rate in percent, 30 real runs, as reported:

LLM inference time tab. 2, seconds, as reported:

Moving-obstacle extension, 10 runs per scenario, with the car as obstacle, pedestrians, or both app. C tab. 5:

Single-obstacle generalisation study, training layout S010 app. A tab. 4:

Paper vs code

No official code.

Search, in order: the paper names no code repository and has no project page. The abstract and the arXiv record carry no code link. The GitHub search for the title words, for "LLM OpenBot driving" and for "end-to-end driving LLM instructions iphone" returned no repositories. A user search for the first and last author returned nothing, and a repository search limited to the Sunrise organisation's account name failed. Nothing clearly belongs to the authors.

Pitfalls

• Conflict on what the LLM outputs. The method and conclusion say the LLM only gives high-level instructions and the policy outputs the actions §1 §2.1 §4. The appendix says that with images and instructions "the LLM provides the steering and throttle values" and the probability head is dropped app. B.4. These are different systems. This card follows the main text. Check which one the authors ran before implementing either.
• Index base of the route label. The loss uses y_c \in \{1, 2, 3\} as the row index of the 3 × 2 matrix V, whose rows are indexed from 0 in the same equation app. B.3. Map labels to rows explicitly, and say which mapping you use.
• Loss weight is ambiguous. The equation uses k, the text uses w, and w also names the network weights app. B.3. Neither value is stated, and the optimizer, learning rate, batch size and number of epochs are not stated either.
• Instruction encoding. How the instruction enters the network is not stated. The card's reading (selecting the instructed row of the action matrix) is an inference from app. B.1.
• No instruction at start-up and no timeout. The paper does not say which instruction is used before the first LLM answer, how an unparseable LLM answer is handled, or how old a cached instruction may get §2.2.
• LLM query schedule. The paper says instructions arrive "at intervals determined by the LLM's inference speed" §2.2. Whether the LLM is queried again immediately after each answer, or on a timer, is not stated.
• Sampling when no instruction is given. The paper says the class is sampled from the probability head app. B.4. The sampling method (for example, a temperature or argmax) is not stated.
• Output ranges. Steering and throttle are said to range over [-1, 1] and [0, 1] fig. 3 app. B.3. Whether the network output is clipped is not stated.
• Camera description. The main text says "back camera" of the phone §3; the appendix names the ultra-wide lens of an iPhone 15 Pro with a 101° field of view app. B.1. Use the appendix values for the lens.
• Dataset details. The average route length of 100 has no unit app. B.2. The proportion of the three route types in the dataset is not stated.
• Failure mode. Strong backlight and reflections on the floor cause the LLM to give wrong instructions, and the paper says the training data for the LLM had few such images §3.4 app. D.1. The paper does not measure how often this happens in the test runs.
• Trial counts do not all fit 30 runs. 83%, 63% and 40% match 25, 19 and 12 of 30 runs. 75% does not match a whole number of 30 runs (22.5), yet two rows report 75% tab. 3 §3.3. The footnote says values are rounded, but the underlying counts are not given. Treat the ranking as indicative.
• Model naming. tab. 3 names "LLaVA-LLaMA3-7B"; the text and tab. 2 name LLaVA-LLaMA3-8B §3.2 tab. 2.
• Statistics. The "±" values in tab. 2 are not explained. No confidence intervals are given for the success rates, and the test course is one site.
• Success criterion is narrow. A run succeeds when the car passes all cones without touching a cone or the wall §3.3. Time, comfort and speed are not measured.
• Moving obstacles. In the moving-obstacle extension the local LLaVA-LLaMA2 does better than ChatGPT-4o in every scenario tab. 5. The paper does not explain this gap, and the run counts are 9 to 11 per cell.
• Reproducibility of the hosted model. ChatGPT-4o runs on OpenAI's servers and its version is not stated §3.2, so the reported numbers may not be repeatable.
• Latency budget. The policy is said to run in milliseconds on the phone, but no policy latency is reported. Only the LLM times are given §1 tab. 2. The pipeline figure defines the two delays as d and l without values fig. 3.
• Local LLM hardware. The local models ran on two RTX A6000 GPUs §3.2. The paper does not say where those GPUs were; the on-car compute is the phone §3.
• Speed limit. The car was limited to under 10 mph for safety §3. Results at higher speed are unknown.

Lineage

• Builds on: the behaviour-cloning design with a per-class action head, adapted from the cited behaviour-transformer and urban-driving work app. B.1 §2.1; ViT-B/16 as the image backbone app. B.1; chain-of-thought prompting Chain-of-thought tab. 1.
• Compared against: closed-loop LLM driving methods that fine-tune the LLM to output actions and were tested in simulation (LMDrive, LeGo-Drive, Hybrid approach) §1. The paper does not run experiments against them.
• Superseded by: not stated in this card's sources.