异步 vs 同步模式

两种模式的本质

模式	Server 行为	时间步	Client 等待	用途
异步 (Asynchronous)	全速渲染，按渲染帧率自走	delta_seconds 跟随渲染	否（随时读最新帧）	快速数据采集、调试可视化
同步 (Synchronous)	停在当前帧，等 tick() 才走	fixed_delta_seconds 固定	是（每帧等 Server）	闭环评测、可复现实验

异步模式为什么”不可复现”

异步模式下，Server 的推进由渲染帧率决定（受 GPU 负载、垂直同步、场景复杂度影响）。Client 调 get_world().snapshot 拿到的是”此刻最新的世界状态”，但这个状态对应哪个仿真时刻是模糊的——两次运行时 GPU 负载不同，相同时间点查到的世界状态可能完全不同。

更糟的是采样不均匀：如果 Client 推理慢，它会错过几帧；如果快，会重复采同一帧。对一个 20 Hz 训练的数据集来说，采样时刻漂移会导致轨迹标注错位。

同步模式：tick 是心跳

同步模式把仿真和算法绑成一个严格串行的循环：

Client 发 tick()  →  Server 推进 fixed_delta  →  传感器采一帧  →  返回 frame ID  →  Client 处理

• Server 在收到 tick() 之前完全冻结，物理不推进、传感器不采。
• tick() 是阻塞调用，等 Server 完成这一帧的物理和渲染后才返回。
• 同一帧里所有传感器的数据带同一 frame ID，可以精确对齐。

这保证了：只要输入序列相同，输出完全可复现——这是闭环评测的前提（Bench2Drive 要求可复现性）。

一个容易被忽略的细节：异步模式 + 等待

很多人以为”异步 = 不等”，其实 CARLA 提供一个折中：异步模式 + world.wait_for_tick()。Client 调 wait_for_tick() 阻塞到 Server 走完下一帧，但时间步仍由渲染决定（不固定）。这只解决了”我等下一帧”的问题，没解决”时间步固定”的问题，所以不能用于可复现评测，只能用于调试。

切换的代价

切换模式本身是免费的，但要注意：

• 从同步切回异步时必须显式还原：settings.synchronous_mode = False; world.apply_settings(settings)。否则 Server 还在等 tick，下次连接会卡死（详见 EP01 B08）。
• 多个 Client 同时连一个 Server：只能有一个把同步模式打开，否则互相打架。Bench2Drive 默认单 Client，避免这个冲突。

为什么 SparseDriveV2 必须用同步

闭环评测要求每一帧的”传感器输入 → 模型输出 → 物理执行”是原子单元：

1. 必须等模型出结果，才能 apply_control——异步模式下 control 可能跑到下一帧才生效，时序错乱。
2. 评测的违规检测要求”知道 Ego 在第几秒做了什么”，时间步必须确定。
3. 实验可复现是科研的基本要求。

所以整个 SparseDriveV2 系列都默认 synchronous_mode=True。

参考

• CARLA — Synchronous and asynchronous mode
• CARLA — #1. Client and world

固定时间步与 Sub-Stepping

四行设置

settings = world.get_settings()
settings.synchronous_mode = True
settings.fixed_delta_seconds = 0.05      # 20 Hz
world.apply_settings(settings)

fixed_delta_seconds 是仿真时间步（单位秒），不是渲染帧间隔。同步模式下 Server 收到 tick() 后固定推进这个时间。

频率换算

$f_{\text{sim}} = \frac{1}{\Delta t}$

$\Delta t$	频率	典型用途
0.05 s	20 Hz	Bench2Drive / SparseDriveV2 标准
0.02 s	50 Hz	高频控制研究
~0.033 s	30 Hz	部分密集采集

SparseDriveV2 用 20 Hz 是因为模型推理节奏、传感器 sensor_tick、控制响应时间都按这个频率标定。

为什么不直接用更大步长省时间

物理引擎（PhysX）用显式或半隐式积分推进刚体。步长 $\Delta t$ 越大，积分误差越大，碰撞穿透、车辆弹跳、抖动都会出现。典型表现：

• 步长 0.1 s（10 Hz）：高速过弯时车辆”漂”出车道，碰撞检测漏。
• 步长 0.05 s（20 Hz）：基本稳定。
• 步长 0.01 s（100 Hz）：稳定但 Server 算力吃不消，模型推理时间被挤压。

20 Hz 是物理稳定性和推理预算的平衡点。

Sub-Stepping：物理内部的更细划分

fixed_delta_seconds 是仿真层的步长，物理引擎内部还会进一步细分成子步——这就是 Sub-Stepping。原因：

• 碰撞检测要求”一个子步内物体移动距离 < 最薄物体的厚度”，否则会穿透。
• 车辆悬挂、轮胎力是高频动力学，需要更细步长才稳定。

CARLA 通过 UE 的 MaxSubstepDeltaTime 和 MaxSubsteps 控制：

max_substep_delta_time = 0.01   # 单子步最大 0.01 s → 100 Hz
max_substeps = 10               # 一个 tick 最多 10 个子步

设 fixed_delta=0.05 时，物理引擎会把它拆成 5 个 0.01 s 子步。子步频率不低于 60 Hz 是经验下限——低于这个阈值，高速碰撞会有可见穿透。

一个反直觉的坑：fixed_delta 与 substep 的耦合

fixed_delta_seconds 必须能被子步上限整除，否则物理会跳步：

$\text{子步数} = \lceil \Delta t_{\text{fixed}} / \Delta t_{\text{substep,max}} \rceil$

如果 $\Delta t_{\text{fixed}} = 0.05$，$\Delta t_{\text{substep,max}} = 0.01$，正好 5 步。但如果 $\Delta t_{\text{substep,max}} = 0.008$，会算出 7 步、最后一步只用 0.004 s，导致最后一步物理略快——长期累积会让仿真时间和墙钟时间不同步（同步模式下两者本来应该一致）。

no_rendering_mode 的影响

调试时可以开 settings.no_rendering_mode = True：跳过所有渲染，只跑物理。这能让 Server 每帧快 5–10 倍，适合大批量轨迹回放评测。代价是 RGB / Depth 相机返回空图像——只对不需要视觉的评测有用。

参考

• CARLA — Fixed time-step
• Unreal Engine — Sub-stepping

Traffic Manager 与 ScenarioRunner

两层 NPC 行为体系

CARLA 里”NPC 怎么动”分两个层次，对应两套不同的工具：

层	工具	运行位置	目的	控制粒度
背景层	Traffic Manager (TM)	Client 端（C++ 后端）	撑起常态背景车流	全局统计行为（跟车/超车概率）
考题层	ScenarioRunner (SR)	Client 端 + py_trees 行为树	精确编排考试场景	单车单步精确控制

Bench2Drive 的 44 种交互场景由 SR 驱动，背景车流由 TM 填充。两者协作：TM 提供有车流的”路面”，SR 在其中插入精确的”考题”。

Traffic Manager 的五阶段流水线

TM 是个运行在 Client 端 C++ 后端的批处理流水线。每个 tick，TM 对所有”挂给它”的车批量算下一步动作，分五个阶段：

1. Localization Stage：把每辆车投到 OpenDRIVE 路网，存储前方一串 waypoint（路径预测的基础）。
2. Path Planning / Motion Planner Stage：决定每辆车的目标行为——保持车道还是变道、目标速度多少。
3. Collision Stage：把每辆车沿预测路径的 bbox 延伸出去，检查与其他车/障碍物的潜在碰撞，必要时减速。
4. Traffic Light Stage：检查红绿灯和 stop sign，做路权推理（谁先走）。
5. PID Control Stage：把”目标速度 + 目标横向”转成 apply_control 的油门/刹车/转向。

注意 CARLA 官方文档把 Stage 2 和 5 之间的边界写法略有出入，但核心是”预测 → 规划 → 碰撞 → 路权 → 控制”五步。

关键点：碰撞检测用的是预测路径上的 bbox，不是当前 bbox。TM 看的是”如果继续这样走会不会撞”，这是前瞻性的避撞，不是被动反应。

ScenarioRunner 与 py_trees 行为树

ScenarioRunner 的核心是 py_trees（Python 行为树库）。行为树是一种分层的状态机：

• Composite 节点：Sequence（顺序）、Selector（选择）、Parallel（并行）。
• Behavior 节点：原子动作，如 DriveTo、ChangeLane、WaitUntil。
• 每个 tick 行为树从根开始遍历，根据子节点的 SUCCESS/FAILURE/RUNNING 返回值决定下一步。

例如 Cut-In 场景的行为树大致是：

Sequence
├── Selector
│   ├── WaitUntil(distance_to_ego < threshold)   # NPC 追上 Ego
├── ChangeLane(target_lane=ego_lane)              # 切入
├── MaintainSpeed(slow_factor=...)                # 切完后稳速

行为树的好处是可组合：把”追上”和”切入”拆成原子行为，组合出 44 种不同场景。Bench2Drive 的 cut_in_right、object_crossing、junction_left_turn 都是这种组合。

为什么不用 TM 编排考试场景

TM 的设计目标是统计意义上的真实车流——它追求”看起来像真交通”，不保证”NPC 一定在某帧做某个动作”。但考试场景要求精确：cut_in_right 必须在 Ego 进入指定路段、达到指定速度时让 NPC 切入。这种确定性的事件序列必须靠行为树，不能交给 TM 的概率模型。

这也是 EP07 T1 故障的根源：Bench2Drive 的 cut_in_right 用 SR 编排，但底层切道动作依赖 CARLA 在该路段生成 LaneChange waypoint——弯道处这个拓扑不存在，行为树里 ChangeLane 节点永远 FAILURE，NPC 只能平行前进（详见 EP07）。

参考

• CARLA — Traffic Manager
• ScenarioRunner GitHub
• py_trees 文档

Traffic Manager 配置

创建 TM 与接管车辆

tm = client.get_trafficmanager(port)             # port 默认 8000
tm.set_synchronous_mode(True)                    # 跟 Server 同步模式对齐
tm.set_hybrid_physics_mode(True)                 # 远处的车用简化物理
tm.set_hybrid_physics_radius(50.0)               # 半径 50m 内用完整物理

for npc in npc_vehicles:
    npc.set_autopilot(True)                      # 把车交给 TM
    tm.port()                                     # 确认接管

set_autopilot(True) 是把车的控制权交给 TM——TM 的 PID Control 阶段会替它发 apply_control。set_synchronous_mode(True) 让 TM 的流水线和 Server 的 tick() 同步，否则 TM 自己按另一个节奏跑会和 Server 错位。

全局参数 vs 单车参数

TM 的参数分两个粒度：

全局参数（影响所有 TM 管的车）

tm.set_global_distance_to_leading_vehicle(5.0)    # 跟车距离 5 米
tm.set_global_speed_limit(40)                      # 全局速度上限 40 km/h
tm.set_respawn_dormant_vehicles(True)              # 死掉的车自动重生
tm.set_boundaries_respawn_dormant_vehicles(25, 700) # 重生的距离边界

单车参数（精确调参一辆 NPC）

tm.distance_to_leading_vehicle(npc, 5.0)          # 这辆车的跟车距离
tm.set_desired_speed(npc, 0.9)                     # 目标速度 = 限速 × 0.9
tm.set_vehicle_lane_offset(npc, 0.0)               # 横向偏移（米）
tm.set_lane_change_policy(npc,
    collision_detection=True, lane_change=True)    # 允许变道
tm.set_collision_detection(npc, ego, False)        # 让这辆 NPC 忽略和 Ego 的碰撞检测

几个核心参数的含义

参数	含义	典型用途
desired_speed	相对限速的倍率（0–1）	0.5 = 温和，1.2 = 激进超速
distance_to_leading_vehicle	跟车距离（米）	模拟拥堵 vs 高速
global_percentage_speed_difference	与限速的差值百分比	负值 = 超速
set_collision_detection(npc, target, False)	关闭 NPC 与 target 的碰撞预测	编排场景时让 NPC 故意逼近 Ego

最后一个参数很重要：默认 TM 会主动避撞。要编排”NPC 切入 Ego 前方”这类场景，必须关掉 NPC 与 Ego 的碰撞检测，否则 TM 检测到接近就提前减速，永远切不进来。

混合物理模式（Hybrid Physics）

tm.set_hybrid_physics_mode(True)
tm.set_hybrid_physics_radius(50.0)

远处（半径 50m 外）的 NPC 用运动学模型（简化、快），近处（半径内）用完整车辆物理（PhysX、慢但真实）。这是性能优化：

• 远处车只是背景，简化模型够用。
• 近处车可能和 Ego 交互，必须物理精确。

代价是”远车变近车”那一帧物理切换可能不平滑——极端场景下会有可见跳变。

构造鲁棒性测试

通过组合参数可以构造从温和到激进的车流：

# 温和车流
tm.set_global_distance_to_leading_vehicle(8.0)
for npc in npc_vehicles:
    tm.set_desired_speed(npc, 0.7)
    tm.set_lane_change_policy(npc, lane_change=False)

# 激进车流
tm.set_global_distance_to_leading_vehicle(3.0)
for npc in npc_vehicles:
    tm.set_desired_speed(npc, 1.1)
    tm.set_lane_change_policy(npc, lane_change=True)

测试算法在不同交通压力下的表现，是 SparseDriveV2 闭环评测的一部分。

易错点

• TM 端口要对应：多个 CARLA Server 各有自己的 TM 端口，连错会无声失败。
• set_autopilot 必须每辆 NPC 都调：不是全局开关，是单车属性。
• 同步模式漏开 TM 同步：Server 同步但 TM 不同步，NPC 会乱跑、撞 Ego。

参考

• CARLA — Traffic Manager configuration

天气与光照

天气是 carla.WeatherParameters 的参数集合

CARLA 的天气不是一个”晴/阴/雨”枚举，而是一组连续的物理参数。每个参数独立可调：

weather = carla.WeatherParameters(
    cloudiness=0.0,         # 云量 [0,100]
    precipitation=0.0,      # 降水强度 [0,100]
    precipitation_deposits=0.0,  # 路面水/雪沉积 [0,100]
    wind_intensity=0.0,     # 风强度（影响植被摆动）[0,100]
    fog_density=0.0,        # 雾密度 [0,100]
    fog_distance=0.0,       # 雾能见度距离（米）
    wetness=0.0,            # 湿度/路面湿润 [0,100]
    sun_azimuth_angle=0.0,  # 太阳方位角（度）
    sun_altitude_angle=70.0,# 太阳高度角（度，决定白天/黄昏/夜）
)
world.set_weather(weather)

关键参数的物理含义：

• sun_altitude_angle：太阳在地平线上方角度。70° 是正午，0° 是日出/日落（橙红光），负值是夜间。这是光照变化的主因。
• fog_density / fog_distance：雾由体积散射近似，fog_density 越高散射越强、fog_distance 越小能见度越近。两者共同决定雾的厚度。
• precipitation_deposits：和 precipitation（下不下雨）不同，这是路面已经被淋湿的程度——决定路面上有没有水渍反光。

内置天气预设

CARLA 提供一组预设组合：

presets = [
    carla.WeatherParameters.ClearNoon,
    carla.WeatherParameters.CloudyNoon,
    carla.WeatherParameters.WetNoon,
    carla.WeatherParameters.WetSunset,
    carla.WeatherParameters.MidRainSunset,
    carla.WeatherParameters.HardRainNoon,
    carla.WeatherParameters.SoftRainSunset,
]
world.set_weather(random.choice(presets))

这些预设是参数组合的快捷方式，本质就是上面那组参数的具体取值。

重要：天气只影响视觉，不改变物理

这是最容易踩坑的地方：

• 雨天不打滑：precipitation 增大只让画面更暗、相机噪声增加，车辆的轮胎摩擦系数不变。
• 雾天不减速：fog_density 高了能见度低，但 NPC 的 TM 不会因此减速（它用的是 OpenDRIVE 拓扑和 bbox 预测，不是视觉）。
• 风不影响行驶：wind_intensity 只让树叶和旗帜摆动，车不受风阻。

为什么这么设计？因为 CARLA 的天气是渲染层的概念，物理引擎（PhysX）独立运行。要把天气影响加到物理上，需要自己改车辆的 tire_friction_scale、drag_coefficient 等参数。

雾效的相机影响

雾对 RGB 相机的影响是真实的——大气散射让远处物体对比度下降。这给纯视觉算法带来挑战：

• 远处的车在雾里看不清，感知容易漏检。
• SparseDriveV2 训练数据（nuScenes / NAVSIM）的天气相对温和，对浓雾是域外（OOD）。

所以 Bench2Drive 在多种天气下评测，本质是在测算法的域鲁棒性——能不能在没见过的天气里还正常开车。

实时调整与插值

天气可以每帧调，做”日落动画”：

for alt in np.linspace(70, -10, 100):   # 太阳从 70° 落到 -10°
    weather = world.get_weather()
    weather.sun_altitude_angle = alt
    world.set_weather(weather)
    world.tick()

这模拟了一天内的光照变化。但要注意：天气变化是渲染时的，需要 tick 才生效——同步模式下 set 完要 tick 一次才能看到。

参考

• CARLA — Weather simulations
• CARLA — Weathers 预设列表

同步数据闭环：完整 tick 循环

一帧的生命周期

这是整个 SparseDriveV2 系统的”心跳”。每一帧严格按这个环运转：

world.tick()                      # ① Server 推进 0.05s，渲染 6 相机
        │
        ▼
传感器回调采集 6 张图 ──┐
        │              │（同 frame ID 对齐入队）
        ▼              │
SparseDriveV2 推理 ◄───┘      # ② 感知 → 建图 → 规划
        │
        ▼
输出一条规划轨迹 τ = {(x_t, y_t)}
        │
        ▼
apply_control(throttle, steer, brake)   # ③ 转成控制指令
        │
        ▼
（下一帧 tick 时物理执行）             # ④

关键时序约束：50 毫秒硬截止

$\Delta t = 0.05$ s 意味着整个环必须在 50 ms 内跑完：

$T_{\text{inference}} + T_{\text{io}} + T_{\text{control}} < 50\text{ ms}$

如果超时，会出现两种问题：

• 欠实时：推理 80 ms 才完成，tick() 还没回来，仿真”卡”在原帧——不是真的卡，是 Client 在等模型。
• 被迫降频：要么把 fixed_delta_seconds 调大（牺牲物理精度），要么跳帧（牺牲时序一致性）。

这是 SparseDriveV2 追求效率的根本原因——26 万候选的 Scoring 必须用 Coarse-to-Fine 才能在预算内完成（详见 EP05）。

③ 从轨迹到控制：轨迹跟踪

模型输出的是轨迹 $\tau = \{(x_t, y_t, v_t)\}_{t=1}^{T}$——一系列未来时刻的目标位置和速度。但 CARLA 的 apply_control 只接受油门/转向/刹车。中间需要一个**轨迹跟踪控制器（trajectory tracker）**把轨迹转成控制指令。

最常见的是 Pure Pursuit（纯跟踪）：

1. 在轨迹上选一个前瞻点（lookahead point），距 Ego 当前位置 $L_d$ 米。
2. 计算这个前瞻点在 Ego 车体坐标系下的角度 $\alpha$。
3. 转向角：

$\delta = \arctan\left(\frac{2 L \sin\alpha}{L_d}\right)$

其中 $L$ 是车的前后轴距（wheelbase），$L_d$ 是前瞻距离。

油门/刹车用 PID 控制当前速度逼近轨迹上指定速度：

$u_t = K_p (v_{\text{target}} - v_{\text{current}})$

④ 控制指令的生效延迟

一个容易被忽略的细节：apply_control 在本帧 tick 后、下一帧 tick 时才物理生效。因为：

• 本帧 tick() 已经推进过物理，本帧的 apply_control 是设给”下一帧物理步”的输入。
• 模型推理用的是”当前状态”，但控制要到下一帧才执行——存在一帧（50 ms）的延迟。

这个延迟在 20 Hz 下意味着模型输出的轨迹其实是”为 50 ms 后的世界规划的”。好的轨迹规划器会做模型预测，把这一帧延迟考虑进去。Bench2Drive 评测时所有方案都面对同样的延迟，所以是公平的。

多线程化的工程实现

实际系统里，“推理”这步很慢，会让整个环阻塞。常见做法是把推理放到单独的 worker 线程：

import queue, threading

infer_q = queue.Queue()
result_q = queue.Queue()
threading.Thread(target=inference_worker, args=(infer_q, result_q), daemon=True).start()

while True:
    world.tick()
    images = collect_frame()           # 主线程：IO + 数据准备
    infer_q.put(images)                # 丢给 worker
    try:
        control = result_q.get(timeout=0.05)  # 试着拿上一次推理的结果
        ego.apply_control(control)
    except queue.Empty:
        pass                            # 推理没好，沿用上一帧控制

注意这种”用上一次推理结果”会引入额外一帧延迟，对控制稳定性有影响——所以推理必须够快，否则要降级。

易错点

• 遗忘 apply_control：模型出了轨迹但没转成控制，Ego 车不动。要确保 trajectory tracker 一定跑。
• 轨迹坐标系错误：模型输出通常是 Ego 车体坐标系，Pure Pursuit 也用车体坐标系——一致即可，但混用全局坐标会全乱。
• tick 在 apply_control 之前：顺序是 tick → 采数据 → 推理 → apply_control，不能 apply_control → tick，否则用的是上一帧推理结果去控制本帧物理。

参考

• Pure Pursuit 算法（维基百科）
• CARLA — Vehicle control 与 PID