Cooperative driving automation

Overview

In cooperative driving automation (CDA), automated vehicles exchange status and intent over a vehicle-to-everything link and agree on a joint plan, such as joining a platoon 2107.06260 §III.B. Each vehicle runs a layered stack of sensing, perception, planning and actuation, and a separate application layer carries the shared plan 2107.06260 §III.B. Testing this needs more than one simulator. Vehicle sensing and control come from one tool, and the surrounding traffic comes from another 2107.06260 §III.A.

The main contribution of the card's paper is a software framework rather than a new algorithm 2107.06260 §III. Its platooning example is therefore one setup among several that a team could build, not a field consensus.

This page currently rests on one paper, OpenCDA. It is the only card that lists this slug, so the variants below describe that paper's setup and not the field as a whole.

Variants

Test bench: single simulator or co-simulation

Co-simulation runs CARLA for the vehicles and SUMO for the background traffic. SUMO's driver models control the human-driven vehicles, and their states are passed into the CARLA server, where the connected automated vehicles react 2107.06260 §III.A. The authors advise against co-simulating every test and say a single-simulator setup is enough for some questions 2107.06260 §III.A. Card: OpenCDA: An Open Cooperative Driving Automation Framework Integrated with Co-Simulation.

Join rule: nearest member or fuzzy rule

When a single vehicle asks to join a platoon, the platoon has to pick the member behind which the newcomer will drive 2107.06260 §IV.A. The paper compares two rules. The baseline takes the nearest member by Euclidean distance. The Genetic Fuzzy System (GFS) also uses the members' speeds and nearby human-driven vehicles 2107.06260 §IV.B.2. The paper cites a prior work for the GFS method, and the card's Paper vs code section finds no fuzzy-logic code in the repository 2107.06260 §IV.B.2 (card).

In the merge scenario, the authors report that the GFS rule keeps the new car's gap above 0.6 s and completes the join in 9.9 s. The baseline takes 13.1 s in the text and 13.5 s in the table 2107.06260 §V.B 2107.06260 tab. 1.

Following law: fixed time gap on the predecessor's track

A follower tracks its predecessor's trajectory at a desired time gap. Its next position blends the predecessor's position, shifted back by the predecessor's length, with its own previous position, and its speed comes from the displacement over one step 2107.06260 §IV.A 2107.06260 eq. 5 2107.06260 eq. 6. In the single-lane run, followers held an average time gap of 0.602 to 0.603 s with zero hazard events 2107.06260 tab. 1 (a) 2107.06260 §V.A. The paper describes only this one following law.

When to use which

All results come from simulation, and the paper reports no real-vehicle tests 2107.06260 §V. The paper does not state hardware, CARLA or SUMO versions, or run counts 2107.06260 §V, so latency and compute needs cannot be compared from it.

Implementation sketch

The core of the platoon, as the paper describes it, is the following law. The join decision sits on top of it. The sketch below follows the paper's equations 2107.06260 eq. 5 2107.06260 eq. 6. It is written from those equations, not from the code.

# Follower tracks its predecessor at a fixed time gap  [§IV.A] [eq. 5-6]
# Input:  pred_pos[t] (position along the path, m), pred_len (m),
#         gap (desired time gap, s), dt (step, s), ego_pos0 (m)
# Output: ego_pos[t] (m), ego_speed[t] (m/s)

def follow(pred_pos, pred_len, ego_pos0, gap, dt):
    # Weight on the ego's previous position: gap / dt  [eq. 5]
    w = gap / dt
    ego = [ego_pos0]
    for t in range(1, len(pred_pos)):
        # Predecessor's rear position, blended with own previous position
        target = pred_pos[t] - pred_len
        ego.append((target + w * ego[t - 1]) / (1 + w))
    # Speed from the displacement over one step  [eq. 6]
    speed = [abs(ego[t] - ego[t - 1]) / dt for t in range(1, len(ego))]
    return ego, speed

Notes for implementers:

• The weight is set by the step size. At a 0.6 s gap, it is 12 for a 0.05 s step and 3 for a 0.2 s step. The repository uses a different step for its trajectories than the paper's Δt 2107.06260 eq. 5 (card).
• The repository is licensed for academic and nonprofit research only. Do not copy its code into a commercial product on the strength of this page (card).

Contradictions

• Heuristic join time. The text gives 13.1 s for the nearest-member merge, and the table gives 13.5 s 2107.06260 §V.B 2107.06260 tab. 1 (c).
• Minimum gap in the merge. The text says one vehicle's gap falls below 0.2 s during the cut-in with the baseline rule. The table does not report a minimum gap 2107.06260 §V.B 2107.06260 tab. 1 (c).
• Paper vs repository. The paper's leader speeds (25 and 30 m/s, held 20 s) differ from the repository's defaults. The hazard count and ATTC from the paper are not computed in the repository 2107.06260 §IV.B.1 2107.06260 §IV.C (card).

Papers

• OpenCDA: An Open Cooperative Driving Automation Framework Integrated with Co-Simulation: an open Python framework that couples CARLA with SUMO, ships a full CDA stack and a platooning benchmark, and reports simulation-only results.