Generating Critical Scenarios for Testing Automated Driving Systems

In plain words

Testing a self-driving car in a simulator means deciding what happens around it: the weather, the time of day, other cars, pedestrians. This paper asks whether a learning agent can find the setups that make the car crash, instead of relying on people or on random tries.

The agent works like the director of a scene. At each step it makes one change, such as adding rain, switching the time of day, or placing a car in front of the test vehicle. The simulator then runs for a short, fixed time. The agent gets a score: a large reward if the car crashed, a partial reward if the car came close to a crash, and a small penalty if the situation was safe. Over many runs it learns which changes tend to lead to crashes.

Two choices set the approach apart. The agent looks at the car's own internal status, such as how far its position estimate is off or how fast it is going, as well as at the outside world. It also follows rules meant to keep the scenes plausible: obstacles are not dropped too abruptly or too close, so the car gets a fair chance to react. On two maps with four road layouts, the authors report more crashes found than the earlier learning approach, and far more than random search. Those numbers are the authors' own.

TL;DR

AVASTRA is a Double DQN agent with prioritized experience replay. It sets LGSVL scene parameters (weather, time of day, 30 NPC-vehicle actions, 2 pedestrian actions) to make Apollo 7.0 collide §3.2 §5.2.1. Its state holds 7 external and 12 internal variables §3.1. Author-reported, the agent finds 11.6 to 18.9 collisions per road, against 5.4 to 12.6 for DeepCollision and 3.2 to 7.0 for random search tab. 5. Its time to collision is longer than DeepCollision's on three of four roads tab. 5. The released code (MIT) differs from the paper in many details, including the state size (23 values in code, 19 in the paper). Read "Paper vs code" before implementing.

Problem

Real-road testing of an autonomous driving system is expensive and risky, so simulation-based testing is preferred §1. Search-based methods such as MOSAT and AV-Fuzzer search over the maneuvers of other vehicles. The authors argue they scale poorly and ignore wider environment factors §1. DeepCollision uses reinforcement learning to configure the environment, but its state does not fully capture the status of the vehicle under test, and it does not consider how realistic the scenes are §1.

Formally, a scenario is a sequence of environment configurations over a horizon T, on a map with an origin and a destination. The goal is to find the sequence that maximizes the likelihood of collisions. A critical scenario is one that puts the AV at risk of colliding with surrounding obstacles §2.

Method

Overview

The paper casts the search as a reinforcement learning task with tuple ⟨S, A, T, R, γ, π⟩ §3. The state s_t combines transformed external and internal values. The transformation is named but its numeric encoding is not given §3. An action sets one or more environment parameters, for example weather or NPC vehicles §3.

After each action the ADS runs for a fixed observation period (OTP), and the environment moves to a new state §4. The reward is computed from a collision probability (ProC) §3.3 §4.2. Transitions go into a replay buffer with prioritized sampling §4 §4.1. The Q-network is a Double DQN §4.1. Exploration is ε-greedy, with ε starting at 1.0 and decreasing to 0.1 §4.1.

An episode ends when the ego vehicle reaches its destination, or when it cannot move forward for 3 to 5 consecutive steps §4.

Steps

1. Read the current state s_t: 19 values in the paper's count (see Tables 1 and 2 below) §3.1.
2. Choose an action a_t with ε-greedy over the Q-values §4.1.
3. Apply a_t in the simulator, then let the ADS drive for one observation period of 6 s §4 §5.2.2.
4. Compute ProC and the reward r_t from the collision state §3.3 §4.2 eq. 8.
5. Check the stop rules, then store (s_t, a_t, r_t, s_{t+1}) with its priority §4 §4.1.
6. Sample a batch by priority, compute the Double DQN target, update the evaluation network, and refresh the priorities §4.1.
7. Copy the evaluation network into the target network periodically. The period is not stated in the paper §4.1.

State §3.1

The state is a tuple of 19 values: the first seven are external, the remaining twelve internal §3.1. The paper describes them in tab. 1 and tab. 2; the list below paraphrases them.

The paper does not model prediction or planning as separate state values. It argues their effect shows up through localization, perception and control §3.1.2.

Localization and perception use these error definitions §3.1.2:

distDeviation = \sqrt{(x_{local} - x_{real})^2 + (y_{local} - y_{real})^2} eq. 1

angleDeviation = \arctan \frac{y_{local} - y_{real}}{x_{local} - x_{real}} eq. 2

positionDiff = \max_{i \in [1, N]} \sqrt{(x_{per}^i - x_{real}^i)^2 + (y_{per}^i - y_{real}^i)^2} eq. 3

directionDiff = \max_{i \in [1, N]} |dir_{per}^i - dir_{real}^i| eq. 4

sizeDiff = \max_{i \in [1, N]} \sqrt{(h_{per}^i - h_{real}^i)^2 + (w_{per}^i - w_{real}^i)^2 + (l_{per}^i - l_{real}^i)^2} eq. 5

velocityDiff = \max_{i \in [1, N]} \sqrt{(vx_{per}^i - vx_{real}^i)^2 + (vy_{per}^i - vy_{real}^i)^2} eq. 6

Actions §3.2

The action space has 45 actions §3.2 tab. 3:

• 13 actions for weather and time of day §3.2.
• 30 actions that add NPC vehicles with five behaviours: drive ahead, overtake, drive opposite, cross the road, and change lane §3.2 tab. 3.
• 2 actions that add a road-crossing pedestrian §3.2.

tab. 4 lists the parameter values. Vehicle types are Jeep, BoxTruck, Sedan, SUV, SchoolBus and Hatchback. Colours are six named colours. The lane is current, left or right. Distance and speed are positive integers, and the paper does not list their values.

The paper enforces these constraints §3.2:

• Chronological time. Morning can change to morning or noon. Noon can change to noon or night. Night can change to night or morning.
• Obstacle distance. The start distance of an added obstacle is the sum of three terms: a base distance for the mode (near or far), an extra distance for vehicle size (small or large), and an extra distance for speed. The weights are all 1 eq. 7. The paper's example values are 50 m for far, 12 m for near, and 3 m extra for large vehicles. It says the speed term is set empirically and gives no values.
• NPC speed. Drawn at random from [10, 20] m/s, and below the road's speed limit. Pedestrian speed is at most 1.4 m/s.
• Random attributes. Vehicle type and colour are picked at random for each action.
• Weather patterns. Not constrained. The authors leave this to future work.

distance = \alpha \cdot f_{d}(dist\_mode) + \beta \cdot f_{v}(size) + \gamma \cdot f_{s}(speed) eq. 7

Reward §3.3

r_t = \begin{cases} R_{col}, & ProC = 1.0 \\ ProC, & 0.2 < ProC < 1.0 \\ -1, & \text{otherwise} \end{cases} eq. 8

An action that causes a real collision gets R_col, which is much larger than the other rewards §3.3. Its value is not given in the paper; the sweep in §6.3.2 reports 7.5 as best. A dangerous action gets its ProC. A safe action gets −1 eq. 8 §3.3.

Collision probability §4.2

ProC is built from longitudinal and lateral scores, each computed per obstacle and then maximized over obstacles.

Safety distance §4.2.1. The paper uses the Berkeley default model. It assigns deceleration −6 m/s² to all vehicles and sets R_min to 5 m. Reaction time is ignored §4.2.1.

LoSD(v_f, v_l) = \frac{1}{2} \left( \frac{v_f^2}{\alpha_f} - \frac{v_l^2}{\alpha_l} \right) + R_{min} eq. 9

LaSD(v_{ego}) = \frac{(v_{ego} \sin \beta)^2}{\alpha_{ego} \sin \beta} eq. 10

Here β is the angle between the ego direction and the lane of the obstacle §4.2.1. Current distance is the 3-D Euclidean distance between the ego and the obstacle §4.2.2 eq. 11.

CD = \sqrt{(x_{ego} - x_{ob})^2 + (y_{ego} - y_{ob})^2 + (z_{ego} - z_{ob})^2} eq. 11

Per-obstacle scores §4.2.3:

loProC = \max_{i \in [1, N]} loProC_i \qquad laProC = \max_{i \in [1, N]} laProC_i eq. 12 eq. 13

loProC_i = \begin{cases} \frac{LoSD - CD}{LoSD}, & \text{same lane} \\ 0, & \text{different lane} \end{cases} eq. 14

laProC_i = \begin{cases} \frac{LaSD - CD}{LaSD}, & \text{different lane} \\ 0, & \text{same lane} \end{cases} eq. 15

The paper says each per-obstacle score ranges from 0 to 1, with 1 meaning a collision §4.2.3. The overall probability combines the two directions §4.2.3 eq. 16:

ProC = ProC_{max} + (1 - ProC_{max}) \times ProC_{min} eq. 16

where ProC_max = max(loProC, laProC) and ProC_min = min(loProC, laProC). ProC lies in [ProC_max, 1], and ProC = 1 means a collision §4.2.3.

Q-network and learning §4.1

• The Q-network has four layers: an input layer that takes the state, two hidden layers with ReLU, and a linear output with one value per action. The two networks share this architecture. Hidden sizes are not stated §4.1 fig. 2.
• Double DQN: the evaluation network selects the next action and the target network scores it §4.1.
• Replay buffer with prioritized experience replay (PER). The paper says priorities come from how well the selection network evaluated an action §4.1. The paper gives no α, β or ε for PER.
• Exploration: ε starts at 1.0 and is lowered to 0.1, "following the decay schedule from previous studies" §4.1. The schedule itself is not given.

The overall loop is shown in fig. 1 §4.

# One training episode  [§4] [§5.2.2]
# agent: Q-network, replay buffer and epsilon schedule  [§4.1]

def run_episode(agent, simulator, origin, destination):
    # Start from the origin, with the destination set  [§4]
    simulator.load(origin, destination)
    state = observe(simulator)
    while True:
        # Choose one environment action, epsilon-greedy  [§4.1]
        action = agent.choose(state)
        # Apply it, then let the ADS drive one observation period  [§4]
        apply(simulator, action)
        simulator.run(seconds=6)  # OTP = 6 s  [§5.2.2]
        next_state = observe(simulator)
        # Read ProC for this step from the simulator  [§4.2]
        proc = read_collision_probability(simulator)
        # Reward from the collision probability  [§3.3] [eq. 8]
        reward = reward_for(proc)
        # Stop when the ego cannot move forward for 3 to 5 steps  [§4]
        done = ego_stuck(simulator) or reached(simulator, destination)
        agent.store(state, action, reward, next_state, done)
        agent.learn()
        if done:
            return
        state = next_state

# Reward from ProC  [§3.3] [eq. 8]

def reward_for(proc):
    # A real collision gets the largest reward  [eq. 8]
    if proc == 1.0:
        return R_COL  # R_col = 7.5 in code  [§6.3.2]
    # Dangerous, but no collision: the reward is ProC itself  [eq. 8]
    if 0.2 < proc < 1.0:
        return proc
    # Safe: penalty  [eq. 8]
    return -1.0

# Collision probability for one time step  [§4.2] [eq. 16]
# Inputs: ego (position, speed); obstacles (position, speed, same_lane)
# Output: ProC in [0, 1]; 1.0 means a collision

def collision_probability(ego, obstacles):
    # Per-direction scores, each starting at 0  [eq. 12] [eq. 13]
    lo_scores = [0.0]
    la_scores = [0.0]
    for obstacle in obstacles:
        # Current distance, 3-D  [eq. 11]
        current = euclidean(ego.position, obstacle.position)
        if obstacle.same_lane:
            # Longitudinal safety distance  [eq. 9]
            safe = los_distance(ego.speed, obstacle.speed)
            # Score is 1 at zero distance and 0 at LoSD  [eq. 14]
            score = (safe - current) / safe
            lo_scores.append(clamp(score, 0.0, 1.0))  # [§4.2.3]
        else:
            # Lateral safety distance, beta = angle to the lane  [eq. 10]
            safe = las_distance(ego.speed, obstacle.beta)
            # Score is 1 at zero distance and 0 at LaSD  [eq. 15]
            score = (safe - current) / safe
            la_scores.append(clamp(score, 0.0, 1.0))  # [§4.2.3]
    # Worst obstacle in each direction  [eq. 12] [eq. 13]
    lo_proc = max(lo_scores)
    la_proc = max(la_scores)
    # Combine the two directions  [eq. 16]
    proc_max = max(lo_proc, la_proc)
    proc_min = min(lo_proc, la_proc)
    return proc_max + (1 - proc_max) * proc_min

# Safety distances  [§4.2.1] [eq. 9] [eq. 10]
# Deceleration and R_min are paper values; sign: see Pitfalls

DECEL = -6.0  # m/s^2, all vehicles  [§4.2.1]
R_MIN = 5.0   # m  [§4.2.1]

def los_distance(v_follow, v_lead):
    # 1/2 (v_f^2 / a_f - v_l^2 / a_l) + R_min  [eq. 9]
    term = v_follow ** 2 / DECEL - v_lead ** 2 / DECEL
    return 0.5 * term + R_MIN

def las_distance(v_ego, beta):
    # (v sin(beta))^2 / (a sin(beta))  [eq. 10]
    return (v_ego * sin(beta)) ** 2 / (DECEL * sin(beta))

# One learning step: Double DQN with prioritized replay  [§4.1]
# Shapes: states (B, N), actions (B,), rewards (B,), weights (B,)

def learn_step(eval_net, target_net, buffer, gamma, batch_size):
    # Draw a batch in proportion to stored priorities  [§4.1]
    batch, weights, tree_ids = buffer.sample(batch_size)
    states, actions, rewards, next_states = batch
    # Q-values of the actions that were taken  [§4.1]
    q_taken = eval_net(states)[actions]
    # Selection: the evaluation network picks the next action  [§4.1]
    best_next = argmax(eval_net(next_states))
    # Evaluation: the target network scores that action  [§4.1]
    q_next = target_net(next_states)[best_next]
    target = rewards + gamma * q_next  # no gradient through target
    # Error per transition, used for the loss and the priority  [§4.1]
    td_error = abs(q_taken - target)
    loss = mean(weights * td_error ** 2)  # loss not stated in paper
    update(eval_net, loss)
    buffer.update_priorities(tree_ids, td_error)

Hyperparameters

Values marked "code" come from the released repository and are not stated in the paper. Code citations are relative to the repository root at code_commit.

Results

Author-reported. Setup: LGSVL simulator with Apollo 7.0; four roads on the San Francisco and Tartu maps §5.2.1 fig. 3. Baselines: DeepCollision and Random Search §5.2.2. Metrics: number of collisions (higher is better) and time to collision, TTC (lower is better) §5.2.3. Hardware is not stated.

The paper's headline comparisons §6.1:

• Against DeepCollision, AVASTRA has 58% more collisions on Road 1, 50% more on Road 2, 115% more on Road 3, and 30% more on Road 4 §6.1.
• Against Random Search, AVASTRA has about four times as many collisions on Road 1 and 3.5 times as many on Road 2 §6.1. The abstract's "up to 275%" matches Road 1 tab. 5.
• The paper names Road 2 as the road with the most collisions for all approaches, and Road 3 as the one with the fewest §6.1.

RQ2, component analysis §6.2:

• Full state beats internal-only and external-only states by 15% to 65%, on Road 1 and Road 3 §6.2.1 fig. 6. The per-variant numbers are shown only in the figure.
• On Road 1, external-only beats internal-only by 41%. On Road 3, internal-only beats external-only by 23% §6.2.1.
• Action spaces tab. 6 (#Collisions, TTC): NPC vehicles and weather/time 14.4 and 24.4; weather/time and pedestrians 21.0 and 14.4; pedestrians and NPC vehicles 19.0 and 24.6; all three groups 20.2 and 29.0 tab. 6.
• Constraints tab. 7: with the distance constraints, 18.9 collisions, 2.2 subjective collisions, TTC 15.78. Without them, 9.0, 4.4 and 17.45 tab. 7.

RQ3, parameters §6.3:

• OTP: 6 s gives 11.8 collisions. That is 64% more than 8 s (7.2) and about ten times 4 s (1.2). Its TTC is 11% to 36% lower than the other settings §6.3.1 fig. 7. The OTP values are also quoted in the figure.
• R_col: 1.0 gives 2.7 collisions, 7.5 gives 13.4, 10.0 gives 11.6. The text reports 12% to 400% more collisions at 7.5 than at the other values §6.3.2 fig. 8.
• θ_ε (ε floor): 14.4 collisions at 0.0, 7.6 at 0.8, and a peak of about 16 at 0.2 §6.3.3 fig. 9.

RQ4, sensitivity §6.4: Road 4 is tested with three training sets. Cross-road training (Roads 1 to 3) is the weakest. Same-road training gives 13.4 collisions. Training on all four roads gives 14.7. The cross-road count is not stated as a number. The text says it is about one third of the same-road count and 68% below the all-roads count §6.4 fig. 10.

Paper vs code

Repository: https://github.com/iSE-UET-VNU/AVASTRA, at commit 31d66fa42e26c8bf365cc32d8b26f55526829c06. The paper links it in its introduction and threats section §1 §6.5. Its root LICENSE is MIT. This card uses only the avastra_model_pipeline/ and configuration_api_server/ folders. The PythonAPI/ folder carries a separate LG simulator licence and was not used.

Differences that matter for an implementation:

1. State size. The paper has 19 values §3.1. The code builds a vector of 23, adding lane encoding, junction encoding and three rotation values utils.py crisis_api_server.py. Table 1 has no rotation variable, and its road-condition entry gives only the road type and quality, not how lane or junction data are encoded tab. 1.
2. Time of day. The paper uses three categories tab. 1. The code reports a continuous hour crisis_api_server.py. The three actions set base hours 10, 14 and 20 plus an offset, and the last is named "evening" crisis_api_server.py api_service_list.json "10"-"12".
3. Weather encoding. The paper gives no numeric encoding. The code uses rain × 100 + fog × 10 + wetness crisis_api_server.py.
4. Localization angle. The paper uses arctan of the coordinate-difference ratio eq. 2. The code uses atan2 of the offset, adding π when the x offset is negative crisis_api_server.py. The code also computes the localization offset in GPS easting and northing crisis_api_server.py crisis_api_server.py.
5. Weather and time actions. The paper says 13 §3.2. Table 4 would give 12 combinations of level and phenomenon, but the code has 10 weather actions: a single "nice" action plus nine rain, fog and wetness levels. It adds three time actions api_service_list.json "0"-"12".
6. Chronological time constraint. Not found. The training loop has no time mask avastra_training_model.py, and the API has no transition check. The only time handling is the setter crisis_api_server.py.
7. NPC speed. The paper draws it at random from [10, 20] m/s §3.2. The code fixes it per action: 10 m/s for drive-ahead crisis_api_server.py, and 20 m/s for overtake and drive-opposite crisis_api_server.py crisis_api_server.py.
8. Start distances. The paper's examples are 12 m near, 50 m far, and +3 m for large vehicles §3.2. The code's values depend on the action. Drive-ahead uses 12 m near, 15 m near for large vehicles, and 50 m far crisis_api_server.py. Cross-road uses 12 m near and 25 m far, with 17 m and 30 m for large vehicles crisis_api_server.py. No speed term appears in either function.
9. Vehicle type and colour. Random per action, as the paper says crisis_api_server.py.
10. Safety-distance deceleration and sign. The paper uses −6 m/s² in the formula §4.2.1 eq. 9 eq. 10. The code uses +6 for NPC vehicles and 1.5 for pedestrians, and takes an absolute value in LoSD utils.py. The 1.5 for pedestrians is not in the paper.
11. LoSD. The code's absolute-value form differs from eq. 9. The code adds R_min as +5 m utils.py.
12. LaSD. The paper's eq. 10 has no R_min. The code adds +5 m utils.py. The code's angle is between the ego trajectory and the obstacle trajectory, not between the ego and the lane as the paper's β suggests utils.py.
13. Current distance. The paper uses 3-D eq. 11. The code uses horizontal x and z only utils.py utils.py.
14. Clamping. The paper says each score is in [0, 1] §4.2.3 but its formulas do not clamp. The code clamps scores to 0 when the distance is at or above the safety distance utils.py, and starts both maxima at 0 utils.py.
15. Same-lane test. The paper does not define it. The code uses a slope-based heuristic with thresholds of 0.6 utils.py.
16. Reward at exactly 0.2. The paper's eq. 8 gives −1 when ProC = 0.2. The code treats ProC ≥ 0.2 as dangerous and returns ProC, so it gives 0.2 avastra_training_model.py.
17. Collision probability location. The code computes ProC in the API server and returns it on a GET endpoint, rounded to six decimals in training crisis_api_server.py avastra_training_model.py.
18. Delayed reward. The compiled paper has no such rule. The LaTeX source has one only in commented-out text. The code gives the earlier action that created the obstacle the full reward, and multiplies the current reward by 1/3 avastra_training_model.py avastra_training_model.py.
19. Repeated collisions. A repeated contact with the same object counts as new only if the ego has moved at least 3 m since the last collision point. Otherwise the reward is zeroed avastra_training_model.py.
20. Episode end rules. Besides the stop rule above, the code ends an episode when the ego moves 2 m or less after touching a static obstacle avastra_training_model.py. It also ends the episode when the ego is within 5 m of the goal and moved 2 m or less avastra_training_model.py. The paper mentions neither.
21. Action choice. The code re-selects weather and time actions. If fewer than 5 steps have passed since the last weather or time change, it picks only vehicle and pedestrian actions. After 5 or more steps, it avoids repeating the same weather or time action avastra_training_model.py avastra_training_model.py. Random actions are drawn from action probabilities that are adjusted each time an action is picked: the chosen action loses 5% of its current probability, which is shared among the others avastra_training_model.py pipeline_constants.py. The paper describes neither.
22. ε sweep. RQ3 varies a threshold θ_ε §6.3.3. The code has no such parameter. The floor is fixed at 0.1 after the decay avastra_training_model.py.
23. Priorities and loss. The paper's priority rule is vague §4.1. The code uses the absolute TD error avastra_training_model.py avastra_training_model.py, and a weighted squared TD error as loss avastra_training_model.py.
24. Learning schedule. The code takes one gradient step per environment step after more than 3000 transitions avastra_training_model.py. The paper does not say how often it learns.
25. Episodes and testing. The paper trains for 750 episodes and picks the best or most stable checkpoint §5.2.2. The code defaults to 300 training episodes avastra_training_model.py. The test loads a fixed checkpoint, episode 5 pipeline_constants.py avastra_experiment.py. The code defines set_seed but I found no call to it utils.py.
26. Road for ablations. The paper does not say which road the ablations use §6.2 §6.3. The code default is road "2" pipeline_constants.py, while the model names say "road3" pipeline_constants.py.

The repository includes random_search_experiment.py. I found no DeepCollision code in it. The paper does not say whether the baseline numbers were rerun or copied from DeepCollision's paper.

Pitfalls

• Sign and absolute value in the safety distances. §4.2.1 gives deceleration −6 m/s², but eq. 9 and eq. 10 divide by it. Implemented literally, the sign flips the distances. The code uses magnitude 6 with an absolute value in LoSD utils.py. Use magnitude 6 and check the sign of the results.
• Division by zero in LaSD. eq. 10 divides by sin β. The paper does not handle β = 0. The code nudges a slope by 0.0001 to avoid an exact zero utils.py.
• Negative scores. The paper's formulas can give negative per-obstacle scores, but §4.2.3 says they lie in [0, 1]. Clamp them, as the code does.
• Exactly ProC = 0.2. The paper and the code disagree on this boundary (see Paper vs code, item 16). The effect is small but affects training reward.
• Time to collision. AVASTRA's TTC is longer than DeepCollision's on Roads 1, 3 and 4 tab. 5. The text says "sometimes" §6.1. Use the table when comparing.
• Subjective collisions. The paper excludes collisions that are unavoidable for the ADS §5.2.3. The table reports them separately tab. 7. It does not say whether the headline #Collisions excludes them.
• Realism claim. The realism gain is measured only as a count of subjective collisions (4.4 without constraints, 2.2 with) tab. 7. The paper has no other realism metric in its main text.
• Figure-only numbers. Many results (state variants, OTP, R_col, ε, the RQ4 training sets) exist only as figures fig. 6–fig. 10. The card gives only the values stated in the text.
• Non-monotone ε result. The text says a higher θ_ε gives fewer collisions §6.3.3, but also reports a peak of about 16 at 0.2. The trend is not monotone.
• Road names are inconsistent. §6.2.1 calls Road 3 "Complex Corner Intersection" in Tartu. The figure caption gives that name to Road 2, and calls Road 3 "Multi-Lane Urban Crossroad" fig. 3 §6.1.
• Draft content in the LaTeX source. Commented-out text describes 24 states, 512 hidden neurons and a softmax output. None of that is in the published text, and the released code does not do it: 23 values, 1024 and 512 hidden units, and a linear output. Do not use the commented text.
• Hard-coded settings. The pipeline constants hard-code an Apollo host address, ports and map identifiers pipeline_constants.py. Replace them for your own setup.
• Simulator licence. Running the code needs LGSVL and Apollo 7.0. The repository's PythonAPI/ folder carries the LG simulator licence, which is separate from the MIT root licence.
• Compute and budget. The paper gives no runtime, hardware, or cost per episode. Each action takes a 6 s simulated run, so a 750-episode run is long even before the simulator's own cost.

Lineage

• Builds on DeepCollision (Lu et al.), an RL approach to configuring the environment. AVASTRA reuses its safety-distance collision probability and decay schedule, and changes the state, the action space and the Q-network §1 §4.1 §4.2.
• Compared against DeepCollision and Random Search in the experiments §5.2.2. MOSAT and AV-Fuzzer are discussed as related search-based work §1.
• Superseded by: not known.