企业官网建设流程全解析

1. 项目概述：为什么要在 CARLA 里跑 RLlib，而不是直接用 PyTorch 或 Stable-Baselines3？

“RLlib 集成 - CARLA 模拟器 中文文档”这个标题乍看像一份翻译稿，但实际它指向一个极具实操门槛、又极富工程价值的交叉领域落地场景：将工业级强化学习训练框架 RLlib，与高保真自动驾驶仿真平台 CARLA 深度耦合，构建可扩展、可复现、可分布式调度的端到端决策训练流水线。我从2020年开始在多个高校实验室和初创团队中支持这类项目，亲手搭过17套不同配置的 RLlib+CARLA 环境，踩过的坑足够填满三本笔记本——不是环境装不上，而是装上了跑不稳；不是模型训不出，而是训出来一上真车就发飘；不是没奖励函数，而是奖励稀疏到 agent 学了三天还在原地打转。

这个集成的核心价值，不在“能跑起来”，而在“能规模化地、鲁棒地、可调试地跑起来”。CARLA 提供的是带语义分割、LiDAR 点云、多视角相机、物理引擎、交通流建模的完整城市驾驶沙盒；RLlib 提供的是基于 Ray 的 Actor-Critic 并行架构、内置 PPO/SAC/IMPALA 等十余种算法、支持跨节点 rollout worker 分布式采样、自动超参调优（Tune）、策略服务化（Serving）的一站式强化学习基础设施。二者结合，意味着你不再需要手写 rollout 循环、自己管理 replay buffer 内存、手动切分 batch、硬编码多智能体通信逻辑——这些在 PyTorch 原生实现中动辄上千行的胶水代码，在 RLlib 里被抽象为几行 config 配置。

适合谁参考？三类人最常深夜加我微信问这个问题：一是高校做自动驾驶决策研究的硕士/博士，论文需要对比 baseline、复现 SOTA、跑消融实验；二是车企智驾部门的算法工程师，要快速验证新奖励设计或新状态表征在闭环仿真中的泛化性；三是机器人方向的创业者，想用低成本仿真替代部分实车路测，把“让 car 学会左转”这件事，从两周缩短到两小时。他们共同的痛点不是“不会写神经网络”，而是“写完 network 后，整个训练 pipeline 像个漏水的水管——数据流断、梯度爆炸、reward 波动像心电图、worker 随机挂掉、log 查三天找不到原因”。

所以这份中文文档，不是对官方英文文档的逐字翻译，而是我把过去四年在 8 个真实项目中沉淀下来的配置模板、避坑清单、调试路径、性能调优参数表、多智能体协同范式、以及 CARLA 版本兼容性矩阵，全部揉进一个可即插即用的技术栈里。它不讲 RL 理论推导，不堆砌公式，只回答一个问题：当你在终端敲下rllib train --config carla_ppo.yaml时，背后到底发生了什么？哪些环节必须改？哪些参数改 0.01 就会让训练彻底失效？CARLA 的 tick rate 和 RLlib 的 rollout fragment length 怎么配才不丢帧？下面我们就一层层拆开这个“黑箱”。

2. 整体架构设计：为什么必须用 RLlib + CARLA，而不是 CARLA + Gym Wrapper？

2.1 核心矛盾：CARLA 的异步性 vs 强化学习训练的同步性

很多初学者第一反应是：“CARLA 不是有 gym wrapper 吗？套个gym.make('Carla-v0')，再接 Stable-Baselines3 不就完了？”——这思路没错，但会在第3个 epoch 就撞墙。根本原因在于CARLA 的底层通信机制与标准 gym 接口存在不可忽视的语义鸿沟。

CARLA 使用 ZeroMQ（默认）或 TCP 协议与 Python client 通信，每次world.tick()是一个阻塞式同步调用：client 发送 tick 请求 → server 执行物理更新 → server 返回 tick 结果 → client 解析并继续。而标准 gym 的step()接口隐含“单步即时响应”假设。当 RL 训练进入高速 rollout 阶段（比如每秒采样 500 步），CARLA server 若因渲染负载高、传感器数据量大（尤其开启 4 个 1080p 相机+LiDAR）导致 tick 延迟超过 100ms，gym wrapper 就会卡死或抛出 timeout 异常。我在清华某课题组部署时就遇到过：同一份代码，在 A100 上训练稳定，在 RTX 3090 上每 200 步必 crash——根源就是 3090 的 PCIe 带宽瓶颈导致 sensor 数据回传延迟抖动加剧，而 gym wrapper 完全没有重试、降频、心跳检测等容错机制。

RLlib 则天然适配这种“非理想延迟”场景。它的 rollout worker 架构是异步-并行-弹性的：每个 worker 独立连接 CARLA server，独立执行env.reset()→ 多步env.step()→env.close()生命周期；worker 之间不共享状态，失败后可自动重启；更重要的是，RLlib 的SampleCollector支持fragment_length参数——你可以明确告诉它：“每个 rollout 片段只采集 50 步，哪怕 CARLA 还没返回第51步，也先打包发回 driver”。这相当于在 RL 训练流和 CARLA 仿真流之间插入了一个“缓冲漏斗”，把不可控的仿真延迟，转化为可控的 batch size 波动。这是 gym wrapper 永远无法提供的底层弹性。

2.2 架构选型对比：三种集成方式的实测吞吐量与稳定性

我们实测了三种主流集成方案在相同硬件（1×A100, 2×CARLA server 实例, Ubuntu 20.04）下的平均 rollout 吞吐量（steps/sec）与 1 小时内 worker crash 次数：

提示：表格中 RLlib 方案的吞吐量优势并非来自算法加速，而是其RolloutWorker 自动负载均衡机制——当某个 worker 因 CARLA 延迟变慢，RLlib 会动态减少其分配的 rollout 数量，将更多任务分给响应快的 worker，整体 pipeline 吞吐量波动小于 ±5%。而 SB3 的VecEnv是静态分片，一旦某个子进程卡住，整个 batch 就得等。

2.3 最终选定架构：RLlib Native Env + CARLA Server Pool

我们放弃所有 wrapper 层，采用 RLlib 官方推荐的Custom Environment模式，即直接继承ray.rllib.env.MultiAgentEnv，在reset()和step()方法内部原生调用carla.Client和carla.WorldAPI。这样做的好处是：

• 完全掌控连接生命周期：可设置client.set_timeout(10.0)、world.wait_for_tick(timeout=5.0)，避免无限等待；
• 精确控制传感器数据流：例如只在step()返回时才触发camera.listen()回调，避免 sensor 数据堆积内存；
• 原生支持多智能体：一个MultiAgentEnv实例可同时 spawn 3 辆 ego vehicle，各自拥有独立观测空间（ego camera + neighbor bounding box + traffic light state），reward 可按 vehicle ID 分别计算；
• 无缝对接 RLlib 的 checkpointing：训练中断后，可精确恢复到某个 episode 的某个 step，包括 CARLA world 的 snapshot（需启用world.freeze()+world.get_snapshot()）。

这套架构的代价是：你需要手写约 400 行环境封装代码。但相比后续节省的 200 小时 debug 时间，这笔投入绝对值得。下面我们就进入最核心的实操环节。

3. 核心细节解析：CARLA 环境封装的 7 个生死关卡

3.1 关卡一：CARLA Server 启动与资源隔离（90% 的崩溃源于此）

很多人以为./CarlaUE4.sh -opengl启动就完事了，其实这是最大误区。CARLA UE4 编辑器默认以“窗口模式”启动，会抢占 GPU 资源、触发桌面 compositor、产生不可预测的帧率抖动。生产环境必须使用无头模式（headless）+ 显式 GPU 绑定。

正确启动命令（Ubuntu）：

# 先查可用 GPU ID（假设为 0） nvidia-smi -L # 启动 CARLA server，绑定 GPU 0，禁用渲染器（仅用于 sensor 数据生成） DISPLAY= ./CarlaUE4.sh -opengl -carla-server -carla-no-hud -quality-level=Epic -fps=20 -world-port=2000 -gpu=0 & # 验证是否成功（返回非空即成功） curl -s http://localhost:2000/health | jq '.status'

注意：-fps=20不是限制 CARLA 内部 tick rate，而是限制其渲染帧率。CARLA 的物理仿真 tick rate 由world.set_weather()和world.tick()控制，与渲染无关。我们实测发现，当-fps设为 0（即关闭渲染）时，CARLA server 的 CPU 占用率下降 40%，但world.tick()延迟反而升高——因为 UE4 渲染管线被完全 bypass 后，某些 sensor 初始化逻辑会异常。因此-fps=20 是经过 12 次压测得出的黄金值：既保证 sensor 初始化正常，又将 GPU 占用压到最低。

更关键的是server pool 管理。单个 CARLA server 无法支撑 10+ 并行 rollout worker（每个 worker 需独占一个 world instance）。我们采用“server pool + connection pooling”双层隔离：

• 启动 4 个独立 CARLA server 实例，端口分别为 2000/2001/2002/2003；
• 在 RLlib env 的__init__中，通过 round-robin 算法从 pool 中分配一个空闲 port；
• 每个 env 实例持有唯一 port，避免 worker 间端口冲突；
• 添加atexit.register(self._cleanup)确保 env 销毁时自动 kill 对应 server 进程。

这套机制让我们在 32 worker 规模下，server crash 率从 12% 降至 0.1%。

3.2 关卡二：Observation Space 设计——别让 CNN 输入变成噪声发生器

CARLA 默认输出的 RGB 图像（1920×1080）直接喂给 ResNet？那是自找麻烦。我们做过对比实验：同样 PPO 训练 100 万步，输入原始 1080p 图像的 agent，碰撞率比输入预处理后 224×224 图像高 3.2 倍。原因有三：

• 分辨率冗余：驾驶决策所需的关键信息（车道线、红绿灯、前车距离）在 224×224 下已足够分辨，更高分辨率只增加噪声和计算负担；
• 色彩失真：CARLA 的 sRGB 输出在不同光照条件下（正午 vs 黄昏）色偏严重，CNN 会学到与光照强相关的伪特征；
• 传感器噪声未建模：真实摄像头有 motion blur、lens distortion、ISO noise，CARLA 原生图像过于“干净”，导致 sim-to-real gap。

我们的解决方案是三级预处理 pipeline：

1. 几何校正：用 OpenCV 的cv2.undistort()消除镜头畸变（CARLA 提供 camera intrinsic matrix）；
2. 色彩归一化：将 RGB 转为 HSV 空间，对 V（亮度）通道做 CLAHE（对比度受限自适应直方图均衡化），再转回 RGB；
3. 语义增强：叠加 CARLA 的SemanticSegmentationsensor 输出（13 类语义标签），将语义图 resize 到 224×224 后，与 RGB 图 concat 成 4-channel 输入（R,G,B,semantic）。

实测表明，加入 semantic channel 后，agent 对“施工区域锥桶”的识别准确率从 68% 提升至 92%，且训练收敛速度加快 1.7 倍。这不是玄学，因为 semantic map 提供了像素级 ground truth，相当于给 CNN 加了一层监督信号。

3.3 关卡三：Reward Function 工程化——如何让 reward 不是“玄学调参”

新手常犯的错误是写一个“if collision: reward = -1000”的硬规则。结果 agent 学会了永远停在路边——因为“不动”比“动了可能撞”更安全。真正的 reward engineering 是分层设计 + 量纲归一 + 动态缩放。

我们采用四层 reward 结构：

• 基础层（Base）：+0.1per step（鼓励探索），-0.05per meter of deviation from center lane（车道保持）；
• 安全层（Safety）：-1.0if distance to front vehicle < 2m（防追尾），-0.5if red light violation（闯红灯惩罚）；
• 效率层（Efficiency）：+0.3if speed > 30km/h in highway（高速通行奖励），+0.2if successfully change lane（变道成功）；
• 平滑层（Smoothness）：-0.02 × |a_t - a_{t-1}|（加速度变化率惩罚，防止 jerky driving）。

关键技巧在于动态 reward scaling：初始训练阶段，base layer 权重设为 1.0，safety layer 权重为 0.3；当 collision rate 低于 5% 后，自动将 safety layer 权重提升至 1.0，base layer 降至 0.5。这个逻辑写在 RLlib 的on_episode_step()callback 里，无需修改 reward 函数本身。

注意：所有 reward 值都经过 min-max 归一化到 [-1, +1] 区间。我们曾因未归一化，导致+1000的 lane change reward 盖过了-1的 collision penalty，agent 疯狂变道求死——这是血泪教训。

3.4 关卡五：Action Space 映射——方向盘不是角度，是扭矩

CARLA 的VehicleControl接口接受steer ∈ [-1, +1]（归一化方向盘转角），但直接让 agent 输出 steer 值会出大问题：人类司机打方向是“渐进式”的，而 RL agent 初始策略是随机的，第一步就输出steer = -0.9，车辆瞬间横甩。我们必须引入动作平滑约束。

标准做法是用action = α × action_prev + (1-α) × action_pred（指数加权），但 α 需随训练动态调整。我们的方案更激进：将 action space 定义为 torque（扭矩）而非 angle（角度）。

具体实现：

• 在 env 中维护一个self._steer_history = deque(maxlen=5)；
• step()时，agent 输出torque ∈ [-1, +1]；
• 真实 steer 值计算为：steer_real = np.clip(self._steer_history[-1] + torque * 0.1, -1, 1)；
• 同时将steer_real加入 history。

这样，agent 学习的是“施加多少扭矩来改变当前转向”，而非“应该转到哪个绝对角度”。实测显示，该设计使车辆失控率下降 87%，且 agent 更快学会“预见性转向”（提前 200ms 开始微调方向）。

3.5 关卡六：MultiAgentEnv 的协同逻辑——如何让 3 辆车不互相“幽灵穿模”

CARLA 原生支持多 vehicle，但MultiAgentEnv的难点在于state synchronization。如果 3 辆车分别调用world.tick()，它们看到的 world state 可能是不同时间戳的——A 车看到红灯，B 车看到绿灯，C 车看到黄灯，这会导致 reward 计算混乱。

我们的解法是全局 tick controller：

• 在 env pool 层面，启动一个独立的TickController进程，负责统一调用world.tick()；
• 所有 vehicle 的step()不直接调用 tick，而是向 controller 发送 “ready” 信号；
• controller 收到全部 ready 信号后，执行一次world.tick()，然后广播当前 snapshot 给所有 vehicle；
• 每个 vehicle 基于同一 snapshot 计算自己的 observation 和 reward。

这相当于给多智能体系统加了一个“全局时钟”，确保所有 agent 的决策基于完全一致的世界观。我们在测试中发现，未加此机制时，3 车交互场景的 collision rate 高达 43%；加入后降至 6.8%，且 lane change 协作成功率从 22% 提升至 79%。

3.6 关卡七：Checkpoint 与 Resume——如何让训练中断后不从头开始

RLlib 的trainable.save()默认只保存模型权重和 optimizer state，但 CARLA env 的状态（vehicle pose、traffic light phase、weather）全丢了。resume 后 agent 面对的是一个“重置的世界”，之前学的策略完全失效。

我们的方案是双 checkpoint 机制：

• RLlib checkpoint：保存 policy、replay buffer（若启用）、tune config；
• CARLA snapshot checkpoint：在on_episode_end()callback 中，调用world.get_snapshot()获取当前世界状态，并序列化为 JSON（包含所有 actor 的 transform、light state、weather preset）；
• resume 时，先加载 RLlib checkpoint，再用 snapshot JSON 调用world.apply_snapshot()恢复世界。

特别注意：apply_snapshot()不能在reset()中调用，必须在env.__init__()之后、第一次step()之前完成。我们为此专门写了CARLASnapshotManager类，管理 snapshot 的版本兼容性（CARLA 0.9.13 和 0.9.14 的 snapshot JSON schema 有细微差异）。

4. 实操过程详解：从零搭建可运行的 RLlib+CARLA 流水线

4.1 环境准备：精准匹配的版本矩阵（抄作业版）

CARLA 和 RLlib 的版本兼容性是“雷区中的雷区”。我们实测验证过的稳定组合只有以下三组（其他组合均出现过 silent failure）：

提示：不要迷信“最新版最好”。CARLA 0.9.15 的 LiDAR 点云精度提升 15%，但其get_world().get_actors()API 在高并发下返回空列表的概率是 0.9.13 的 3 倍。我们最终选择CARLA 0.9.14 + RLlib 2.9.3作为主力开发版本，平衡了稳定性与功能。

安装命令（Ubuntu 20.04）：

# 创建纯净 conda 环境 conda create -n carla-rllib python=3.9 conda activate carla-rllib # 安装 CARLA Python API（注意：必须与 server 版本严格一致） pip install carla==0.9.14 # 安装 RLlib（指定 CUDA 版本，避免 wheel 不匹配） pip install "ray[rllib]"==2.9.3 -f https://docs.ray.io/en/releases.html # 验证安装 python -c "import carla; print(carla.__version__)" python -c "import ray; ray.init(); from ray import rllib; print(rllib.__version__)"

4.2 核心代码：CARLAEnv 类的完整实现（含注释）

以下是经过 8 个项目验证的CARLAEnv核心骨架，删除了业务相关逻辑，保留所有关键工程细节：

# carla_env.py import numpy as np import cv2 import carla from collections import deque from typing import Dict, Tuple, Any, Optional from ray.rllib.env.multi_agent_env import MultiAgentEnv class CARLAEnv(MultiAgentEnv): def __init__(self, config: Dict[str, Any]): super().__init__() self.config = config # 1. 连接 CARLA server（带重试） self.client = None for _ in range(3): try: self.client = carla.Client("localhost", config.get("port", 2000)) self.client.set_timeout(10.0) self.world = self.client.get_world() break except Exception as e: print(f"CARLA connection failed: {e}, retrying...") time.sleep(2) if not self.client: raise ConnectionError("Failed to connect to CARLA server after 3 retries") # 2. 初始化传感器（只创建一次，避免重复 allocate） self._setup_sensors() # 3. 动作平滑历史 self._steer_history = deque([0.0], maxlen=5) # 4. 定义 observation space（以 224x224 RGB+Semantic 为例） self.observation_space = gym.spaces.Box( low=0, high=255, shape=(224, 224, 4), dtype=np.uint8 ) # 5. 定义 action space（steer, throttle, brake，全部归一化到 [-1,1]） self.action_space = gym.spaces.Box( low=-1.0, high=1.0, shape=(3,), dtype=np.float32 ) def _setup_sensors(self): """一次性初始化所有传感器，避免 step() 中重复创建""" blueprint_library = self.world.get_blueprint_library() # RGB camera cam_bp = blueprint_library.find('sensor.camera.rgb') cam_bp.set_attribute('image_size_x', '224') cam_bp.set_attribute('image_size_y', '224') cam_bp.set_attribute('fov', '110') # Semantic camera（关键！） seg_bp = blueprint_library.find('sensor.camera.semantic_segmentation') seg_bp.set_attribute('image_size_x', '224') seg_bp.set_attribute('image_size_y', '224') seg_bp.set_attribute('fov', '110') # 挂载到 ego vehicle（需先 spawn vehicle） self.vehicle = self._spawn_ego_vehicle() self.rgb_cam = self.world.spawn_actor(cam_bp, carla.Transform( carla.Location(x=2.5, z=1.0), carla.Rotation(pitch=-15))) self.seg_cam = self.world.spawn_actor(seg_bp, carla.Transform( carla.Location(x=2.5, z=1.0), carla.Rotation(pitch=-15))) # 设置回调（注意：必须用 lambda 绑定 self，否则无法访问实例变量） self.rgb_image = None self.seg_image = None self.rgb_cam.listen(lambda image: self._process_rgb(image)) self.seg_cam.listen(lambda image: self._process_seg(image)) def _process_rgb(self, image): """RGB 图像预处理：去畸变 + CLAHE + resize""" # CARLA 图像是 BGRA，转 BGR 再转 RGB img = np.frombuffer(image.raw_data, dtype=np.uint8).reshape((image.height, image.width, 4))[:, :, :3] # 去畸变（使用 CARLA 提供的 intrinsic matrix） K = np.array([[image.fov / 2, 0, image.width / 2], [0, image.fov / 2, image.height / 2], [0, 0, 1]]) # 实际去畸变需 calibrate，此处简化为 resize + CLAHE img = cv2.resize(img, (224, 224)) hsv = cv2.cvtColor(img, cv2.COLOR_BGR2HSV) clahe = cv2.createCLAHE(clipLimit=2.0, tileGridSize=(8,8)) hsv[:,:,2] = clahe.apply(hsv[:,:,2]) self.rgb_image = cv2.cvtColor(hsv, cv2.COLOR_HSV2RGB) def _process_seg(self, image): """语义图预处理：转为 13 类索引图""" # CARLA 语义图是 uint8，每个像素值对应一个 label id seg = np.frombuffer(image.raw_data, dtype=np.uint8).reshape((image.height, image.width, 4))[:, :, 0] seg = cv2.resize(seg, (224, 224), interpolation=cv2.INTER_NEAREST) self.seg_image = seg def reset(self) -> Dict[str, Any]: """重置环境：清理旧 actor，spawn 新 vehicle，重置传感器""" # 清理 if hasattr(self, 'vehicle') and self.vehicle: self.vehicle.destroy() if hasattr(self, 'rgb_cam') and self.rgb_cam: self.rgb_cam.destroy() if hasattr(self, 'seg_cam') and self.seg_cam: self.seg_cam.destroy() # 重置历史 self._steer_history.clear() self._steer_history.append(0.0) # Spawn 新 vehicle self.vehicle = self._spawn_ego_vehicle() # 重新 setup sensors（复用 _setup_sensors 逻辑） self._setup_sensors() # 等待传感器数据就绪（最多等 5 tick） for _ in range(5): self.world.tick() if self.rgb_image is not None and self.seg_image is not None: break time.sleep(0.05) # 构建 observation（RGB + Semantic） obs = np.concatenate([ self.rgb_image, self.seg_image[..., np.newaxis] ], axis=-1) # shape: (224, 224, 4) return {"ego_vehicle": obs} # MultiAgentEnv 要求 dict def step(self, action_dict: Dict[str, np.ndarray]) -> Tuple[ Dict[str, Any], Dict[str, float], Dict[str, bool], Dict[str, Any] ]: # 1. 解析 action（只处理 ego_vehicle） action = action_dict["ego_vehicle"] steer_pred, throttle, brake = action # 2. 动作平滑（扭矩映射） steer_real = np.clip( self._steer_history[-1] + steer_pred * 0.1, -1.0, 1.0 ) self._steer_history.append(steer_real) # 3. 应用控制 control = carla.VehicleControl() control.steer = float(steer_real) control.throttle = float(np.clip(throttle, 0, 1)) control.brake = float(np.clip(brake, 0, 1)) self.vehicle.apply_control(control) # 4. 执行 world tick（关键：必须等 sensor 数据更新） self.world.tick() # 等待 sensor 回调完成（简单轮询，生产环境建议用 event loop） for _ in range(10): if self.rgb_image is not None and self.seg_image is not None: break time.sleep(0.01) # 5. 构建 observation obs = np.concatenate([ self.rgb_image, self.seg_image[..., np.newaxis] ], axis=-1) # 6. 计算 reward（简化版，实际应分层） reward = self._calculate_reward() # 7. 判断 done（例如碰撞、超时、到达目标） done = self._is_done() # 8. 构建 info（用于调试） info = { "speed": self.vehicle.get_velocity().length(), "distance_to_center": self._calc_lane_deviation(), } return ( {"ego_vehicle": obs}, {"ego_vehicle": reward}, {"ego_vehicle": done, "__all__": done}, {"ego_vehicle": info} ) def _spawn_ego_vehicle(self) -> carla.Vehicle: """Spawn vehicle at random spawn point""" spawn_points = self.world.get_map().get_spawn_points() transform = np.random.choice(spawn_points) blueprint = self.world.get_blueprint_library().filter("vehicle.*")[0] vehicle = self.world.spawn_actor(blueprint, transform) return vehicle def _calculate_reward(self) -> float: # 实际项目中这里会调用 3.3 节的分层 reward 函数 return 0.1 # placeholder def _is_done(self) -> bool: # 检查碰撞、红灯、超时等 return False def close(self): """清理所有资源""" if hasattr(self, 'vehicle') and self.vehicle: self.vehicle.destroy() if hasattr(self, 'rgb_cam') and self.rgb_cam: self.rgb_cam.destroy() if hasattr(self, 'seg_cam') and self.seg_cam: self.seg_cam.destroy() if self.client: self.client.disconnect()

4.3 配置文件：RLlib Train Config（YAML 版）

carla_ppo.yaml是整个训练的灵魂，90% 的调优工作都在这里：

# carla_ppo.yaml env: carla_env.CARLAEnv env_config: port: 2000 # 其他 env 参数... # RLlib 核心配置 run: PPO stop: timesteps_total: 5000000 episode_reward_mean: 150.0 # 早停条件 checkpoint_freq: 10 checkpoint_at_end: true # 算法参数（PPO） config: # 1. Rollout 配置（最关键！） num_workers: 16 # 每个 worker 连一个 CARLA server num_envs_per_worker: 1 # 每个 worker 只跑 1 个 env（CARLA 是 heavy-weight） rollout_fragment_length: 200 # 每次 rollout 采集 200 步，避免 CARLA 延迟累积 train_batch_size: 4000 # 必须是 rollout_fragment_length 的整数倍 sgd_minibatch_size: 512 num_sgd_iter: 10 # 2. 模型配置 model: fcnet_hiddens: [256, 256] conv_filters: [ [16, [8, 8], 4], [32, [4, 4], 2], [512, [11, 11], 1], ] # 注意：CARLA 输入是 224x224x4，最后一层 conv 输出 1x1x512，正好接 fc # 3. 探索与稳定性 clip_param: 0.2 vf_clip_param: 100.0 entropy_coeff: 0.01 lr: 3e-4 # 4. 多智能体（如启用） multiagent: policies: ego_policy: (null, null, null) # 自动 infer policy_mapping_fn: "lambda agent_id, episode, **kwargs: 'ego_policy'" # 5. Callbacks（注入 reward scaling 等逻辑） callbacks: on_episode_start: "carla_env.on_episode_start" on_episode_step: "carla_env.on_episode_step" on_episode_end: "carla_env.on_episode_end" # Ray cluster 配置（本地开发可省略） ray: address: auto include_dashboard: false num_cpus: 32 num_gpus: 1

4.4 启动训练：一行命令背后的完整流程

执行训练命令：

rllib train --config carla_ppo.yaml --run PPO --env carla_env.CARLAEnv

这条命令背后，RLlib 启动了以下组件：

1. Driver Process：加载 config，初始化 trainer，启动 Tune experiment；
2. 16 RolloutWorker Processes：每个 worker 执行CARLAEnv.__init__()，连接到 CARLA server（port 2000~2015）；
3. CARLA Server Pool：16