简介这套基于Python与CARLA的分布式自动驾驶仿真平台面向高校人工智能、车辆工程、自动化等专业学生及相关科研人员适用于课程设计、毕业设计或自动驾驶方向进阶学习。平台重点解决多传感器同步、车流并行仿真、分布式客户端控制等常见问题并提供清晰的分层模块设计便于快速上手与二次开发。压缩包共17个文件以13个Python源码文件为主体覆盖同步、配置、日志、手动控制等功能另含2个Markdown说明文档、1个YAML服务配置和1份设计报告帮助理解整体架构与运行流程。整包仅96KB轻量但功能完整目前已有94人学习下载。借助内置的传感器控制、数据定义和同步测试脚本读者可快速搭建仿真场景也可基于现有代码扩展自定义功能适合作为项目初稿或毕业设计的基础框架。1. 为什么 Autoware、Apollo 之外还要自己搭一套 CARLA 仿真平台接触到“PythonCARLA高性能分布式自动驾驶仿真平台”这个标题的开发者多半已经过了“装个 CARLA 跑通 autopilot 示例就算入门”的阶段。常见的问题是单机单场景下传感器数据处理不过来多车联调时地图资源互相挤占训练数据的生成速度远跟不上模型迭代而 Carla 作为开源仿真器本身却提供了分布式扩展的可能性——只是官方教程只讲了单个客户端连本地服务器多机多场景的编排完全留给开发者自己去探索。这个标题指向的正是把 CARLA 当作自动驾驶仿真领域的“实验基座”用 Python 作为控制面语言把渲染、物理仿真、传感器数据采集分发到多台机器上并行执行最终搭出一个可供感知、规划、控制算法反复迭代的高吞吐仿真环境。这套方案适合三类人做决策规划算法验证的研究者、需要批量生成传感器数据的算法团队以及做仿真基础设施的自动驾驶工程师。它解决的问题不是“能不能跑”而是“能不能大规模、高效率地跑”。2. 分布式架构的核心设计把 CARLA 的客户端-服务器模型拆开看2.1 理解 CARLA 的核心模型服务器、客户端、Actor 三者关系CARLA 的架构本质上是一个客户端-服务器Client-Server模型。服务器端运行仿真主循环负责物理计算、渲染和世界状态的维护客户端是 Python 库carla通过 RPC 协议与服务器通信获取世界状态并下发控制指令。所有传感器摄像头、LIDAR、GNSS在 CARLA 中都是Actor它们由服务器端创建数据通过数据流Data Stream回传给客户端。这个模型的优点是把仿真核心和业务逻辑解耦了。服务器只管世界的运行客户端可以随时启停、独立开发。这也是分布式系统的天然基础因为服务器本身通过端口开放 RPC 接口通过共享内存Shared Memory机制传输传感器数据天然适合拆分到不同的计算节点。但单机部署时这个模型会有明显瓶颈服务器既要跑物理仿真又要渲染多个摄像头的画面还要为 LIDAR 做点云计算CPU 和 GPU 都会被吃满。分布式的核心思路就是让计算有效地拆分出去。2.2 分布式要解决的三个核心问题同步、数据分发、资源隔离做分布式仿真平台时最先面对的问题是和仿真的步调保持一致。CARLA 的服务器端以固定时间步长fixed time-step推进仿真客户端通过client.tick()或client.wait_for_tick()来同步。多客户端同时连接时服务器为每个客户端提供世界状态快照但不同客户端之间的仿真实时性其实是同一份即所有人都看到同一个世界在推进。第二个问题是数据分发。传感器数据产生在服务器端消费在客户端。单机时带宽够用但当你把客户端和服务器分开部署在两台机器上传感器数据就要经过网络传输就要考虑带宽和延迟对数据获取的影响。第三个问题是资源隔离。如果多个实验场景同时跑合理的做法是起多个 CARLA 服务器实例每个实例占用一组 GPU 和 CPU 核心互不干扰。但 CARLA 服务器默认吃满本机所有资源如何给进程绑定资源需要额外的精力来处理。提示CARLA 的共享内存机制只在单机模式下有效。一旦客户端与服务器分离部署传感器数据将自动切换为 TCP/UDP 传输延迟和带宽占用会明显上升设计时要注意这一点。2.3 Python 在分布式方案中的角色指挥调度而非仿真主体选择 Python 做这个平台的控制层语言几乎是必然的。CARLA 官方的 Python API 已经覆盖了场景配置、Actor 生成、传感器设置、世界状态读取等全部功能不需要你再去做底层封装。大多数自动驾驶算法验证工作流也建立在 Python 生态里从 NumPy 数组处理到 PyTorch 模型推理用 Python 做数据接口层能减少序列化和类型转换的损耗。但注意Python 在分布式系统里应当做指挥者Orchestrator而非执行者。你不能用 Python 去实现高吞吐的数据转发逻辑——多线程、GIL 限制会让它显得力不从心。合理的分层是Python 负责场景编排、状态同步、任务调度把计算密集型的仿真任务交给 CARLA 服务器C 实现把数据预处理下推到客户端本地的 NumPy 向量化操作。这样各取所长整个系统才能承载高并发实验。3. 从零搭建分布式 CARLA 仿真平台安装、多机多实例编排3.1 环境准备硬件要求与版本选择思路在搭建分布式环境前先明确硬件选型和版本策略。CARLA 对硬件的需求跨度很大0.9.x 系列的版本在 GTX 1080 上就能跑通基础场景但如果要并行渲染多个相机加上 LIDAR显存需求会指数级上升。如果是 8GB 显存以下的老卡建议只跑单相机加 LIDAR 的配置用多实例并行来换取吞吐量而不是用高配置传感器消耗显存。版本选择方面对分布式开发最重要的是 CUDA 版本和 CARLA 版本的匹配关系。官方 Release 版本中较早的 0.9.11 及之前版本对低版本 CUDA 兼容性更好新版本如 0.9.14只支持更新的 CUDA 和 PyTorch 生态。选型思路不是追新而是看你后面要挂什么算法栈——如果你的感知模型要跑 PyTorch 2.x就选可以支持对应 CUDA 的 CARLA 版本避免重装驱动。安装过程多为常规操作这里给出一份最小化验证清单# 安装 CARLA Python API以 0.9.x 为例 pip install carla0.9.14 # 下载 CARLA 服务器端如 Linux 版本 # 解压后进入目录 cd CARLA_0.9.14 # 启动服务器无渲染模式适合分布式计算 ./CarlaUE4.sh -carla-rpc-port2000 -quality-levelLow -RenderOff参数说明-carla-rpc-port指定 RPC 端口默认是 2000多个实例时要区分开-RenderOff关闭渲染显著降低系统负载-quality-level设置画面质量等级分布式场景下建议使用 Low 或 Epic 级以下的设定把 GPU 算力留给传感器数据生成而不是画面呈现。注意-RenderOff模式下如果没有 GPU 也可以运行但 LIDAR 和摄像头数据依然会生成只是服务器不渲染画面。这是服务器集群模式的常用方案。3.2 多线程多进程利用 Python 并发概念协调多 CARLA 实例当你在一台拥有 8 核 CPU、双 GPU 的机器上搭建平台时核心思路是让每个 GPU 跑一个 CARLA 服务器实例然后利用 Python 的multiprocessing去并发管理多个实例的生命周期。这里选用multiprocessing而不是threading是因为 CARLA Python API 的客户端连接是阻塞式的线程切换并不能绕开 GIL 的限制进程级隔离才能真正利用多核。下面是一个用 multiprocessing 管理双 CARLA 实例的最小代码框架import multiprocessing import subprocess import time import carla # 定义实例启动函数每个子进程启动一个 CARLA 服务器 def launch_carla_server(port, gpu_id): cmd [ ./CarlaUE4.sh, f-carla-rpc-port{port}, -RenderOff, -quality-levelLow, f-ini:[/Script/Engine.RendererSettings]:r.GPUMask{gpu_id} # 指定GPU ] proc subprocess.Popen(cmd) proc.wait() def run_scenario_on_port(port, scenario_name): # 等待服务器启动 time.sleep(30) # CARLA 启动需要时间实际代码中建议轮询连接 client carla.Client(localhost, port) client.set_timeout(10.0) world client.get_world() # 按照 scenario_name 加载对应地图 world.load_map(scenario_name) time.sleep(5) # 在这里执行具体的场景逻辑比如生成车辆、配置传感器 # ... return True if __name__ __main__: # 进程1端口2000GPU 0 p1 multiprocessing.Process(targetlaunch_carla_server, args(2000, 0)) # 进程2端口2001GPU 1 p2 multiprocessing.Process(targetlaunch_carla_server, args(2001, 1)) p1.start() p2.start() # 主进程里为每个端口启动一个场景管理子进程 s1 multiprocessing.Process(targetrun_scenario_on_port, args(2000, /Game/Carla/Maps/Town01)) s2 multiprocessing.Process(targetrun_scenario_on_port, args(2001, /Game/Carla/Maps/Town02)) s1.start() s2.start() p1.join() p2.join()这段代码实现了“双实例、双场景并行”的最小框架。需要特别说明的是-ini:[/Script/Engine.RendererSettings]:r.GPUMask{gpu_id}这个参数它是 Unreal EngineCARLA 的底层引擎的 GPU 选择参数在双卡环境下你不希望两个实例都默认落在 GPU 0 上否则负载依然会倾斜。CUDA 层面也可以通过设置环境变量CUDA_VISIBLE_DEVICES达到同样效果export CUDA_VISIBLE_DEVICES0 ./CarlaUE4.sh -carla-rpc-port2000 -RenderOff提示实际项目中我一般不会让一个multiprocessing.Process即拉服务器又跑场景逻辑因为服务器进程会阻塞场景进程崩溃时会导致服务器无人回收。更好的方式是服务器进程独立管理场景进程作为它的“消费者”。3.3 多机扩展用 Docker 容器化 CARLA 服务器当单机的资源被占满或者你需要一个真正的服务器集群来跑大规模仿真容器化就变成了一个很有价值的方案。Docker 可以为每个 CARLA 实例提供独立的文件系统、网络端口和 GPU 资源。CARLA 官方提供了 Docker 镜像的构建方式但这里给出的是使用 NVIDIA Container Toolkit 运行已有 CARLA 包的更直接路径。Docker 化的核心价值在于一是环境一致性不同机器上的 CUDA、驱动、依赖库版本不再成为问题镜像打包了全套运行环境二是资源隔离通过--gpus参数和 CPU 绑定参数不同容器天然拥有独立资源视图互不干扰三是弹性伸缩新增一台机器时只需要拉取镜像不需要手动装驱动和依赖。以下是启动一个 CARLA 容器的命令模板# 构建 CARLA 镜像假设已有 Dockerfile基础镜像为 nvidia/cuda:11.8-devel-ubuntu20.04 docker build -t carla-distributed:0.9.14 . # 启动容器只暴露 RPC 端口挂载 CARLA 数据目录 docker run -d --name carla-instance-01 \ --gpus device1 \ -p 2000:2000 \ -e CARLA_RPC_PORT2000 \ -v /data/carla/Datasets:/workspace/datasets \ carla-distributed:0.9.14涉及多机的分布式调度需要一个编排层常见的做法是写一个简单的 Python 控制脚本用 SSH 或 HTTP 接口远程触发各机器上的 Docker 容器操作。这部分如果用 Docker Compose 管理单机多实例还是很方便的多机环境下 Kubernetes 会引入不必要的复杂度对自动驾驶仿真场景来说可以先尝试轻量级的调度方案。# docker-compose.yml: 双实例单机编排示例 version: 3.8 services: carla-a: image: carla-distributed:0.9.14 ports: - 2000:2000 environment: - CARLA_RPC_PORT2000 deploy: resources: reservations: devices: - driver: nvidia device_ids: [0] capabilities: [gpu] carla-b: image: carla-distributed:0.9.14 ports: - 2001:2001 environment: - CARLA_RPC_PORT2001 deploy: resources: reservations: devices: - driver: nvidia device_ids: [1] capabilities: [gpu]注意device_ids指定 GPU 的物理序号在多机环境下各机器的 GPU 序号可能不同需要让配置文件对每台机器具备可解释性。这里是把分布式机器的差异通过环境变量来抹平。4. 高性能数据链路传感器流、共享内存与数据落地4.1 传感器配置与数据回调机制带宽与精度权衡传感器是数据链路的源头。CARLA 的传感器以 Actor 形式存在服务器创建传感器后数据按帧推送到客户端。以相机和 LIDAR 为例# 相机传感器配置 camera_bp world.get_blueprint_library().find(sensor.camera.rgb) camera_bp.set_attribute(image_size_x, 1280) camera_bp.set_attribute(image_size_y, 720) camera_bp.set_attribute(fov, 90) camera_bp.set_attribute(sensor_tick, 0.05) # 20 FPS # LIDAR 传感器配置 lidar_bp world.get_blueprint_library().find(sensor.lidar.ray_cast) lidar_bp.set_attribute(channels, 64) lidar_bp.set_attribute(points_per_second, 500000) lidar_bp.set_attribute(range, 50) lidar_bp.set_attribute(rotation_frequency, 20) # 20Hz参数说明中sensor_tick是传感器的采样间隔它与服务器的tick是独立的。降低采样频率可以显著减小带宽压力但不一定能被感知算法接受需要根据实际模型输入频率来设定。points_per_second直接影响点云的密度这个参数的设定应该取决于算法所需的点云分辨率不再产生大量用不到的数据。传感器回调在 Python 端是阻塞式的数据量大时回调函数如果做太多操作会影响帧率。标准做法是回调函数只做拷贝和入队不做预处理import queue import numpy as np import cv2 sensor_queue queue.Queue(maxsize20) def process_camera_data(image): # 转成 numpy 数组后入队回调中不做任何计算 array np.frombuffer(image.raw_data, dtypenp.uint8) array array.reshape((image.height, image.width, 4)) sensor_queue.put(array[:, :, :3]) # 丢弃 alpha 通道为什么这样设计传感器回调是 CARLA 客户端收到网络数据的入口如果在这里直接跑图像增强或模型推理会阻塞后续数据帧的接收。用一个有界队列做缓冲消费者用独立线程从队列里取数据做预处理这是分布式数据链路中最基本的背压Backpressure模型。4.2 数据落地方案从 Redis 到 MinIO 的分层存储策略分布式平台一旦进入量产数据的阶段数据就不会直接流向内存中的队列而是需要一套持久化方案。这里涉及两个不同的存储目标一是消息级别的缓冲存储二是数据集级别的对象存储。消息级别的缓冲是整个数据链路中的关键缓冲层。常见做法是引入 Redis 作消息缓冲import redis # Redis 连接池用于多客户端共享数据 pool redis.ConnectionPool(hostredis-master, port6379, db0) r redis.Redis(connection_poolpool) # 将传感器数据序列化为 bytes 并写入 Stream for frame_data in sensor_queue_consumer(): # frame_data 包含图像 numpy 数组、时间戳、角色名等信息 payload frame_data.tobytes() # 数据序列化 r.xadd(sensor-stream, { timestamp: frame_data[timestamp], actor_id: frame_data[actor_id], data: payload }, maxlen10000) # 只保留最近 1 万条防止内存膨胀用 Redis Stream 而非简单的 List 的原因是 Stream 自带消费组功能多个算法模块可以独立游标消费同一条数据流不会相互干扰。maxlen参数是必要的——仿真平台跑几小时数据量就会非常惊人不限制长度会导致 Redis 内存溢出。数据集级别的存储采用 MinIO 这类 S3 兼容的对象存储来保存历史场景。当一组场景跑完后你可以把回放包上传到 MinIO# 使用 mc 客户端将本地数据目录同步到 MinIO mc cp --recursive ./output/dataset-20250215/ myminio/autonomous-driving/scenarios/落地策略按数据热冷分层热数据最近一轮迭代的传感器数据用 Redis 做缓冲温数据完整场景记录落本地高速磁盘冷数据历史训练集进 MinIO。这样既能保证实验的高速迭代又不至于把所有数据都塞进内存把机器拖垮。4.3 分布式时序对齐用最少的时间成本完成时钟同步分布式仿真要考虑“时序对齐”问题。比如 3 台机器各跑一个场景每个场景里车辆在 10:00:00 各自出发数据的记录时间戳是对各自机器时钟而言的。合并数据集时时间戳不统一给训练过程引入不必要的复杂度。解决思路有两种。一种简单可行的做法是在数据里显式记录仿真时间simulation timestampPRG 时间戳从 CARLA 服务器的world.get_snapshot()获取它是从仿真开始到当前的帧序换算而来与机器时钟无关snapshot world.get_snapshot() sim_time snapshot.timestamp.elapsed_seconds # 仿真开始至今的秒数 # 把 sim_time 写入每帧数据的前 8 字节作为对齐依据 frame_header struct.pack(d, sim_time)另一种是 NTP 对时加时间戳补偿。如果在多机环境部署让所有机器先做 NTP 时钟同步然后在数据落地的入口记录本机时间作为批次号再用仿真时间作为帧内序号联合排序。两套机制共同作用可以保证分布式的数据在合并时是严格有序的。5. 场景编排与控制从单场景剧本到多智能体协同5.1 用 Python 控制 NPC 车辆Traffic Manager 的分布式配置CARLA 内置的 Traffic ManagerTM用来控制 NPC 车辆的自动驾驶行为。在分布式场景中TM 可以部署在独立的端口默认端口是 8000。多客户端环境中TM 也可以跨服务器动态切换流量。TM 影响仿真性能的关键参数是set_simulation_duration和每秒更新的车辆数# 连接 TM指定端口 traffic_manager client.get_trafficmanager(8000) traffic_manager.set_synchronous_mode(True) # 同步模式开启 # 为指定的自动驾驶车辆设置忽略交通规则的概率 traffic_manager.ignore_lights_percentage(ego_vehicle, 10) traffic_manager.ignore_walkers_percentage(ego_vehicle, 0) # 设置全局速度限制因子相对于路段限速 traffic_manager.global_percentage_speed_difference(10.0)在分布式多场景的语境下每台机器上的实例通常有自己独立的 TM这意味着每个实验组可以自定义自己的 NPC 密度。但要注意总 NPC 数量受到服务器物理引擎上限的限制0.9.x 版本单服务器可承载的车辆数量大约在 100200 量级受 CPU 影响超出后物理仿真会开始出现抖动。5.2 批量场景生成用 Python 脚本快速铺开场景矩阵做算法训练数据集时核心诉求是用尽可能少的时间覆盖尽可能多的场景变体。手动在编辑器里拖场景不可取正确做法是用 Python 脚本参数化生成场景矩阵。import itertools # 场景参数组合地图、天气、车辆数、行人密度 scenario_params list(itertools.product( [Town01, Town02, Town03, Town04, Town05], [ClearNoon, CloudyNoon, WetNoon, HardRainNoon], [10, 30, 50], [0, 20, 50] )) # 每个参数组合对应一个 CARLA 服务器的配置 def configure_scenario(client, scenario): world client.load_world(scenario[map]) weather carla.WeatherParameters() if scenario[weather] ClearNoon: weather.sun_altitude_angle 60 elif scenario[weather] HardRainNoon: weather.precipitation 80.0 world.set_weather(weather) # 生成车辆和行人...这种参数化的场景矩阵能很好地配合分布式平台每个 worker 领取一个参数组合执行任务做完后从消息队列领取下一个组合这是更贴近实际业务的分发方式。控制端配合 Redis 做一个简单的任务分发机制# 任务池把所有场景配置 push 到 Redis List for idx, combo in enumerate(scenario_params): r.rpush(scenario-task, json.dumps({id: idx, params: combo})) # 每个工作进程从 List 中阻塞取任务 while True: task r.blpop(scenario-task, timeout10) if task: run_one_scenario(client_map, json.loads(task[1])) else: break这个模型的优点是天然负载均衡。性能强的机器跑得快做得任务多性能弱的机器少跑几个不需要中心调度器去预分配。5.3 多 ego 车辆联调让一辆车控制另一辆车被控制在分布式平台上更复杂的场景是 V2X车路协同联调。你需要同时控制两辆 ego 车辆让一辆车的行为依赖于另一辆车的状态。# 服务端创建两辆车 ego_bp world.get_blueprint_library().filter(vehicle.audi.a2)[0] ego_1 world.spawn_actor(ego_bp, transform_1) ego_2 world.spawn_actor(ego_bp, transform_2) # client A 控制 ego_1 vehicle_control_1 carla.VehicleControl(throttle0.5, steer0.0, brake0.0) ego_1.apply_control(vehicle_control_1) # client B 获取 ego_2 的状态做跟随控制 elif ego_2.get_velocity().x 5.0: vehicle_control_2 carla.VehicleControl(throttle0.3, steer0.0, brake0.0) ego_2.apply_control(vehicle_control_2)这种多 ego 配置要求所有客户端都以同步模式连接服务器。CARLA 的同步模式下每个客户端都要发送tick指令当有多个同步客户端时服务器会等待所有客户端就绪后再推进一帧这会明显降低仿真速度。这里更合理的做法是只让主控制端发送 tick从属客户端以wait_for_tick方式被动接收把推进权交给单一角色。6. 性能评测与调优验证平台能力的关键技巧6.1 度量指标吞吐量、帧率与资源利用率搭建完成后面临的第一个问题是这套分布式平台比单机快多少确定评估指标也有讲究。要关注的核心指标有三个指标含义测量方法FPS仿真帧率CARLA 服务器每秒钟推进的仿真步数world.get_snapshot().timestamp.delta_seconds的倒数统计数据吞吐量单位时间内产生的传感器帧数含所有传感器统计 sensor_queue 中消费的帧数 / 时间资源利用率GPU、CPU 的使用率nvidia-smi和top定期采样对 FPS 监控可以挂在异步线程里定期打印import threading import time fps_counter {frames: 0, last_time: time.time(), fps: 0.0} def fps_monitor(): while True: time.sleep(5) end time.time() fps_counter[fps] fps_counter[frames] / (end - fps_counter[last_time]) fps_counter[frames] 0 fps_counter[last_time] end print(fServer FPS: {fps_counter[fps]:.2f}) t threading.Thread(targetfps_monitor, daemonTrue) t.start() # 在主循环中每帧调用 world.tick()并递增计数器 while running: world.tick() fps_counter[frames] 1这套指标不只用于验收也是确定整个平台瓶颈定位的依据。如果 FPS 正常但吞吐量上不去瓶颈在网络传输路径或数据消费端如果 FPS 偏低且 GPU 利用率高瓶颈在仿真计算本身需要减少传感器数量或降低分辨率。6.2 常见性能瓶颈与针对性解法分布式 CARLA 平台跑起来之后常见的性能问题有这几类对应解法如下。一是服务器端 FPS 过低但 GPU 利用率不高——这表示 CPU 成为瓶颈。CARLA 的物理运算和多 NPC 管理是 CPU 密集任务解法是减少 NPC 数量、关闭渲染-RenderOff、降低物理子步长-carla-server-delta-seconds。二是传感器数据延迟增大帧间隔不稳定。这个多发生在多机部署时。解决办法是检查sensor_tick设置、调整数据队列长度、用共享内存模式替代网络传数据。三是某个客户端连不上服务器提示 “timeout”。这是典型的端口或防火墙问题。用telnet server_ip 2000检查端口连通性同时确认client.set_timeout()设置合理。6.3 验证平台分布式能力的一个实用技巧四场景并行压力测试最后给出一个可执行的验证方法这个压力测试设计初衷就是验证平台的并发承载能力。在 4 台机器上各启动一个 CARLA 实例端口分别为 20002003。然后在主控机器上用 Python 脚本并发连接 4 个客户端每个客户端加载不同地图和不同的 NPC 密度配置。运行 10 分钟后检查每个客户端的平均输出帧率波动不超过 10%。所有客户端的传感器数据时间戳错位在 2 帧以内。没有出现客户端连接超时断开的情况。满足这三点基本可以认为平台的分布式能力是合格的。这套验证思路不依赖任何额外工具用 CARLA Python API 就能完成适合作为落地验收的标准动作。本文还有配套的精品资源点击获取