简介这是一份基于CARLA的分布式自动驾驶仿真平台毕业设计源码采用Python实现面向计算机、AI、自动化、电子信息等专业学生与科研人员可用于毕业设计、课程设计、作业提交或自动驾驶仿真项目初期的快速演示与二次开发。压缩包共17个文件包含13个Python脚本、2个Markdown说明、1个YAML配置及1份Word设计报告分别对应仿真主控、分布式同步、传感器数据定义、参数配置、日志模块、环境配置与设计文档结构清晰适合按模块逐步阅读。包体仅96KB轻量完整便于部署。目前已有64人学习下载。资源附带设计报告与介绍文档可帮助快速理解平台架构、同步机制与数据流走向源码经过测试功能稳定支持多客户端协同仿真与多模式手动控制覆盖从环境配置到运行调试的关键环节也可在现有框架上扩展更多自动驾驶场景适合作为高年级本科生或研究生的实践参考。1. 基于CARLA的高性能分布式自动驾驶仿真平台把“单机跑不动”变成“集群跑得动”基于CARLA的高性能分布式自动驾驶仿真平台核心要解决的只有一个问题单机跑不动。一辆车在 CARLA 里打开感知仿真GPU 占用率轻松过半一旦场景铺到几十辆带传感器的车辆渲染线程立刻成为瓶颈帧率往下掉回传的数据大量集中在同一时刻场景训练价值大打折扣。分布式平台的做法不是去优化单机而是把一个 CARLA 实例拆成多台机器上的多个实例靠一层统一的帧同步和场景编排逻辑把散落的节点组织成一台“更大的仿真机”。作为毕业设计这个方向工程量集中、可验证、有研究深度而且拿到的 zip 工程包通常已经帮你把平台骨架搭好剩下的就是理解它、跑通它、在它之上加自己的东西。下面我从架构模型讲起一直落到双节点集群搭建、数据回传和踩坑记录最后给出性能验证的方法。适合正要定课题、或者已经拿到工程包但不知道怎么启动的人。2. 先理解 CARLA 的分布式基因服务器-客户端模型与帧同步机制2.1 每个 CARLA 实例都是独立世界服务器-客户端模型的边界一个常见的误解是把 CARLA 当成一个单一程序启动后按时弹出渲染窗口然后跑 Python 脚本。真实架构里CARLA 拆成了两个可独立部署的部分——服务器和客户端。服务器是一个基于虚幻引擎的进程负责场景渲染、物理计算和传感器模拟客户端是用户侧的程序通过 PythonAPI 或者 C API 发指令、读状态。两者走 TCP 协议默认端口是 2000。这个拆分意味着分布式多实例不是硬改出来的而是架构自带的能力在一台机器上可以启动多个 CarlaUE4 进程只要端口不冲突每个进程就是完整独立的虚拟世界。分布式平台里的“节点”本质上是把这些进程分散到多台物理机器上。我第一次做多实例测试的时候直接开两个实例分别指定 2000 和 2001 端口# 节点 A启动第一个实例渲染质量设为 Low无头模式 ./CarlaUE4.sh -quality-levelLow -carla-port2000 -RenderOffScreen # 节点 A启动第二个实例换端口避免冲突 ./CarlaUE4.sh -quality-levelLow -carla-port2001 -RenderOffScreen这里有两个容易忽略的点。-RenderOffScreen是无头模式渲染照常进行但不显示窗口服务器裸奔时是必须项-quality-levelLow不只是省显存它还会影响物理仿真线程的调度方式这我在后面的避坑章节会专门讲。同一张 GPU 上跑两个实例时如果不手动指定显卡虚幻引擎会把显存随意瓜分表现就是两个实例都卡。上面没有给绑定 GPU 的写法是因为不同版本的 CARLA 对-ini参数支持度不一样我更习惯用环境变量CUDA_VISIBLE_DEVICES配合启动脚本管理这样每个进程启动前就知道自己该用哪块卡。在代码层面客户端连接实例只需要 IP 加端口。下面是一个可靠的连接探测写法不用get_world()直接拿世界而是先探测版本号等服务器真正就绪import carla import time def connect_server(host, port, timeout60): client carla.Client(host, port) client.set_timeout(5) deadline time.time() timeout while time.time() deadline: try: version client.get_server_version() print(f[OK] {host}:{port} 返回 {version}) return client except Exception as exc: print(f等待 {host}:{port} 就绪{exc}) time.sleep(3) raise RuntimeError(f{host}:{port} 在 {timeout}s 内未就绪)set_timeout(5)设置的是单次请求的超时上限循环里的timeout60是总等待时间。第一次连接时 CARLA 可能还在加载地图get_server_version()会抛异常循环重试是最稳的校验方式。很多同学拿到 zip 工程后直接跑主脚本报错九成情况是服务器还没加载完成就去连代码就崩了。2.2 同步模式下的帧协调为什么分布式平台必须统一帧率如果多实例各跑各的时间线分布式就没有意义节点 A 采集的数据和节点 B 采集的数据对不上帧号训练时拼不成一组完整场景。CARLA 默认是异步模式服务器按自己的节奏推进客户端只负责发指令、收数据。要想让多个实例步调一致必须开启同步模式。同步模式的含义是服务器每推进一帧都会等所有参与方处理完这一帧的数据再继续往下走。核心设置是synchronous_mode与fixed_delta_secondsworld client.get_world() settings world.get_settings() settings.synchronous_mode True settings.fixed_delta_seconds 0.05 # 每帧 50ms等效 20 FPS world.apply_settings(settings) # 由客户端主动推进一帧 world.tick()fixed_delta_seconds决定仿真步长。0.05 秒对应 20 FPS是我在多实例平台上的默认值渲染压力可控传感器数据帧率足够训练使用。改成 0.03 甚至 0.025 能跑到 33~40 FPS但每个实例的 CPU 占用会明显抬升多实例场景下容易拖垮物理线程。实际项目里自动驾驶车本身的传感器跑 20 Hz 就够交通流车辆用 10 Hz 也没问题差异在客户端过滤即可没必要让服务器空转更高帧率。分布式平台里最忌讳的是多个客户端同时推动同一个实例的 tick。CARLA 允许一个实例被多个客户端连接如果两个客户端各自开着同步模式、各自调用world.tick()服务器会收到重复推进指令帧率直接翻倍所有传感器的帧号全部跳变。正确的分工是每个实例只由一个工作线程负责 tick其余客户端全部设为synchronous_modeFalse只读数据不推帧。这个设计原则会在第四章的编排代码里反复用到。2.3 单机仿真的三个天花板以及分布式为什么能突破把单机瓶颈拆成三个维度方便后面做性能对比。瓶颈维度单机上的表现分布式处理手段GPU 渲染场景车辆超过 30 辆帧率跌破 15 FPS多实例分摊渲染负载每个实例只渲染自己的场景CPU 物理Traffic Manager 在单实例中串行调度车辆越多越卡多实例分担车辆和行人交通流互相独立数据 I/O相机、LiDAR 每帧回传几十 MB 数据TCP 回传挤占带宽本地先落盘、后聚合跨节点只传结果摘要渲染是第一个触到顶的瓶颈。CARLA 的传感器模拟依赖虚幻引擎渲染管线8 颗相机加一颗雷达单帧数据量可以到几十 MB。如果平台要做多智能体协同仿真上千帧连续跑下来回传会变成一个巨大的 I/O 事件。分布式架构把请求分摊到每台机器的本地资源本质上是一种分治思路把一个大世界切分成多个 CARLA 实例用编排层统一派发任务。到这一层你就会理解这种 zip 工程包的核心目录应该包含什么平台代码、启动脚本、场景配置和数据处理模块。平台代码负责多实例状态管理启动脚本负责拉起 CarlaUE4 进程场景配置定义每个实例的车辆数和任务数据处理模块解决数据回收。先看懂这一层后面动手才不会乱。3. 从零搭建双节点 CARLA 集群环境、启动脚本与最小编排3.1 Ubuntu 24.04 下 CARLA 环境准备与 Docker 化部署平台的第一块地基是环境。CARLA 当前主线版本对 Ubuntu 24.04 已有较好的支持但初次安装有两个高频坑一是显卡驱动与系统内核不匹配二是 Python 版本不对导致 PythonAPI 导入失败。原生安装的检查顺序我一般照着三步走# 第一步确认显卡驱动可用 nvidia-smi # 第二步确认 Python 版本CARLA 0.9.15 之后要求 Python 3.8 python3 --version # 第三步解压 CARLA 包并查看核心目录 mkdir -p ~/carla tar -xzf CARLA_0.9.15.tar.gz -C ~/carla ls ~/carla/CARLA_0.9.15/如果你的机器上跑的是常见发行版解压后能看到CarlaUE4.sh、PythonAPI、Tools等目录。PythonAPI 目录下是carla的 Python 包需要把它加进PYTHONPATH才能import carla。这一步我吃过亏脚本直接import carla报 ModuleNotFoundError折腾半天发现是环境变量没配。容器化部署时先验证 GPU 容器运行时是否可用docker run --rm --gpus all nvidia/cuda:12.2.0-base-ubuntu22.04 nvidia-smi能正常输出显卡信息说明 Docker 侧没问题。之后拉取 CARLA 官方镜像并映射端口。容器方式的好处是每个计算节点的环境完全一致不用逐台机器装依赖缺点是渲染性能有约 5%~10% 的损耗显存分配也不够直观。毕业设计阶段我建议双轨并行开发时用 Docker 保证环境一致压测时切回原生安装拿真实性能数字。3.2 多节点 CARLA 实例启动命令行参数与 GPU 分配双节点集群的启动逻辑是把一批 CarlaUE4 进程分散到两台机器上。下面这个脚本是典型的批量拉起方式#!/bin/bash # 两个节点的 IP 与端口列表 NODES(192.168.1.10:2000 192.168.1.10:2001 192.168.1.11:2000 192.168.1.11:2001) for entry in ${NODES[]}; do ip${entry%%:*} port${entry##*:} # 通过 ssh 远程启动nohup 保证 ssh 断开后进程继续运行 ssh carla$ip cd /opt/carla nohup ./CarlaUE4.sh \ -quality-levelLow -carla-port$port -RenderOffScreen \ /tmp/carla_$port.log 21 sleep 3 done这里有两个关键点。第一nohup必不可少如果不加ssh 连接一断开远程进程会被 SIGHUP 信号杀掉这是新手最容易碰到的“过一会儿节点就没了”的翻车现场。第二sleep 3只是粗略的间隔控制真正可靠的等待方式是在编排脚本里轮询连接状态而不是靠固定睡眠。多节点部署时ssh 免密登录要先配好否则脚本会在输入密码处卡住。启动之后需要确认进程真的活着而且用的是预期那块 GPU# 在任意节点执行查看 CarlaUE4 进程 ssh carla192.168.1.10 ps aux | grep CarlaUE4 | grep -v grep # 确认显存占用 nvidia-smi --query-gpuindex,memory.used,utilization.gpu --formatcsv如果发现两个实例挤在同一张 GPU 上老老实实处理。常见做法是给每个实例配CUDA_VISIBLE_DEVICES因为多个 CarlaUE4 进程默认会自选显卡不手动约束的话负载分配完全随机。3.3 客户端连接与场景分发第一份可运行的编排脚本实例起来了下一步是让编排层把场景分发到各个实例。先做一个能遍历所有服务器并确认连接正常的最小脚本import carla import time SERVER_POOL [ (192.168.1.10, 2000), (192.168.1.10, 2001), (192.168.1.11, 2000), (192.168.1.11, 2001), ] def wait_for_server(host, port, timeout60): client carla.Client(host, port) client.set_timeout(5) deadline time.time() timeout while time.time() deadline: try: version client.get_server_version() print(f[OK] {host}:{port} - {version}) return client except Exception: print(f等待 {host}:{port} 就绪...) time.sleep(3) raise RuntimeError(f{host}:{port} 在 {timeout}s 内未就绪) clients [wait_for_server(host, port) for host, port in SERVER_POOL] print(f成功连接 {len(clients)} 个 CARLA 实例)每个carla.Client对象对应一个独立实例后续的分发逻辑就是给每个实例下发不同的场景文件和数据采集任务。注意这里的SERVER_POOL是静态配置实际平台里应该做成动态注册——节点上线后通过心跳上报自己的负载再由调度器决定把任务分给谁。4. 分布式场景编排与数据回传把集群能力变成实际可用的仿真服务4.1 基于 PythonAPI 的分布式场景编排从串行到并行的任务分发编排层是分布式平台的大脑。它要做的事很简单一批场景多个实例怎么分配、怎么回收。最原始的做法是写一个 for 循环一个场景跑完再跑下一个但这样实例空闲时间太多。正确做法是任务队列加工作线程每个线程连接一个实例不断从队列里取任务import threading from collections import deque task_queue deque() for scenario_id in range(20): task_queue.append({ scenario_id: scenario_id, map: Town01 if scenario_id % 2 0 else Town02, weather: ClearNoon if scenario_id % 3 0 else CloudyNoon, num_vehicles: 30, }) def worker(client, worker_id): while True: try: task task_queue.popleft() except IndexError: break try: run_scenario(client, task, worker_id) except Exception as exc: print(fworker {worker_id} 执行 task {task[scenario_id]} 失败{exc}) # 每个线程绑定一个独立的 CARLA 客户端 threads [] for i in range(4): client carla.Client(192.168.1.10, 2000 i) # 注意每个 worker 单独连接 client.set_timeout(30) t threading.Thread(targetworker, args(client, i)) t.start() threads.append(t) for t in threads: t.join()这个方案里的关键约束是一个 worker 只用一个客户端一个客户端只连一个实例。千万不要在多个线程里共享同一个carla.ClientPythonAPI 内部对客户端对象的并发访问没有加锁共享会引发随机崩溃。线程数等于实例数这是最简单也最不容易出错的映射关系。如果你要做的平台更像服务而不是一次性脚本全局调度器会维护一个实例状态表记录每个实例当前在跑哪个场景、剩余帧数、负载情况。任务级别可以做到“场景粒度”一个场景在一个实例上完整跑完而不是一个场景被切成多段分给多台机器。CARLA 目前不支持跨实例的世界状态同步所以场景切分不是这个平台的正确玩法。4.2 传感器数据回传本地缓存、结果聚合与存储格式数据回收是分布式平台的第二个核心问题。每个 CARLA 实例上一旦挂载相机和 LiDAR单帧数据量就是几十 MB如果所有节点把原始数据实时回传给中心服务器千兆网也会被打满。我采用的方案是“分两段走”采集端本地落盘聚合端定时扫描回收。import numpy as np import os def sensor_callback(data, sensor_id, save_dir): # data.raw_data 是传感器原始字节流转成 numpy 数组 array np.frombuffer(data.raw_data, dtypenp.uint8) # 帧号 传感器 ID 作为文件名帧号用于跨节点对齐 os.makedirs(save_dir, exist_okTrue) np.save(f{save_dir}/{sensor_id}_{data.frame:06d}.npy, array)这段代码里最关键的是data.frame。同步模式下所有实例的帧号起点一致因此帧号可以作为跨节点数据对齐的依据。归档目录建议按“节点 IP 端口 传感器类型”分层避免多个传感器写同一个目录产生文件名冲突。不同传感器的存储格式很有讲究。我的习惯是传感器类型推荐存储格式原因相机RGBPNG 压缩或 JPEG单帧数据小文件可预览LiDARASCII PLY 或 npy点云处理方便npy 读取更快毫米波雷达CSV 或 npy数据量小直接落表CAN 总线数据CSV结构化强便于后期分析聚合端不需要逐帧分析文件而是扫描目录里已经写满的帧序列按帧号拼接成完整样本。这样原始数据永远留在节点本地中心服务器拿到的只是压缩后的样本网络开销降到最低。4.3 调度参数设置实例数量、batch 大小与队列深度这一节列出的参数我在多个平台上反复调过可以直接抄作业参数推荐值说明fixed_delta_seconds0.05仿真帧间隔等效 20 FPS每实例最大车辆数30超过 30 辆物理线程瓶颈明显每张 GPU 实例数1~2渲染质量 Low 时取 2质量设为 Epic 时只能 1客户端超时30s首次加载地图时非常容易超时任务队列深度实例数 x 10队列太长会导致场景等待时间过久第一个要调的是每 GPU 实例数。显存 24 GB 的显卡跑 Low 质量两个实例各占约 8 GB留出余量给数据缓冲如果开到三个虚幻引擎的内存碎片会导致半小时后某个实例崩掉这是环境稳定性的大坑。第二个要调的是车辆数。Traffic Manager 在同步模式下每个 tick 都要重新规划所有车辆的动作车辆数从 30 涨到 50单帧耗时可能从 50ms 涨到 90ms直接击穿帧间隔。所以在spawn_vehicles()的时候就要控制数量而不是跑起来之后再调。第三个是队列深度。任务队列太长前面的场景还在跑后面的场景已经加载好等着实例并不会因此空转但队列太长会导致整个平台的端到端延迟变高。实例数乘以 10 是经验值保证任意时刻至少有几个任务在排队又不会积压太久。5. 分布式 CARLA 避坑指南四个高频故障的现象、原因与对策5.1 现象客户端连不上服务器报错 Timeout / Could not connectcarla.Client创建时没问题第一次调用get_server_version()就超时错误信息只给一个笼统的 timeout。原因有三类按概率排序服务器还没加载完、端口被防火墙挡住、set_timeout设得太短。尤其是首次启动时虚幻引擎要加载地图和材质慢的机器可能需要两分钟默认的 10 秒超时完全不够。对策是分步排查。先看端口通不通# 在客户端节点上探测端口 nc -zv 192.168.1.10 2000如果端口通但 Python 里仍然超时把连接的总体超时设为 30 秒以上并加上第 3 章里的轮询等待逻辑。如果nc都不通检查服务器节点防火墙sudo ufw allow 2000/tcp5.2 现象两个实例的帧号对不上传感器数据时间戳错乱配置了同步模式但收集回来的数据里实例 A 的帧号是 1000 时实例 B 已经到了 1003而且差异随时间增大。原因基本是某个实例被多个客户端连接或者某个客户端里开启了 Traffic Manager 的自动 tick。Traffic Manager 默认会在自己的线程里推进仿真和主动调用world.tick()形成竞争导致帧号漂移。对策是全局统一推进入口。所有实例只允许编排线程调用world.tick()Traffic Manager 必须显式关闭自动同步traffic_manager client.get_trafficmanager(port) traffic_manager.set_synchronous_mode(True)注意这里的端口参数要对应实例端口否则 Traffic Manager 会连到错误实例上。同步模式下set_synchronous_mode(True)和编排线程的world.tick()必须配合使用少了任何一个都会乱。5.3 现象多实例运行半小时后某个节点显存占满CARLA 进程直接崩溃三个实例跑在两张 GPU 上前 15 分钟一切正常之后某个实例的显存占用持续爬升最后 OOM 崩溃。重启后又复现但每次崩的实例不一定是同一个。原因是虚幻引擎的内存回收机制和长周期任务不匹配。场景循环中不断 spawn 和 destroy 车辆引擎内的 Mesh、贴图资源不会立刻释放加上传感器回调里如果持有数据引用内存会只增不减。对策分三层。第一层降低渲染质量到 Low关闭阴影和反射第二层在脚本里定期调用world.reset_all_actors()清理遗留下来的 actor第三层给每个实例配置最大内存上限监控接近阈值时自动重启实例。由于 CARLA 实例重启后世界状态会清空这个操作必须在任务边界执行不能在场景中途做。5.4 现象同一套代码节点 A 正常节点 B 的数据乱序且丢帧双节点平台节点 B 的传感器数据经常跳帧严重点的情况是 LiDAR 和相机的时间戳对不上差了几个帧周期。原因大概率是节点 B 的物理机 CPU 核数不够。CARLA 的虚幻引擎主线程和物理线程需要多个物理核并行如果节点 B 只有 4 核而节点 A 有 16 核在同步模式下服务器会因为物理计算来不及完成而跳帧。同步模式不丢帧但会用更长的 tick 间隔来表达“没算完”表现就是客户端看到的数据帧号稀疏。对策是先做资源配置检查lscpu看核数free -h看内存nvidia-smi看显卡。至少 8 核 16 GB 内存、8 GB 显存才适合跑一个 Low 质量实例。异构节点做平台测试时把实例数和车辆数按节点算力分开配不要用全局参数一把梭。6. 验证分布式平台的性能收益基准测试方法与共享内存优化6.1 用帧号与时间戳做最小基准测试平台搭完需要拿出性能数字。最简单的基准是测单实例的 tick 耗时在同步模式下连续 tick 200 帧统计平均耗时import time start time.time() for _ in range(200): world.tick() elapsed time.time() - start print(f平均帧耗时: {elapsed / 200 * 1000:.1f} ms) print(f等效帧率: {200 / elapsed:.1f} FPS)分别在单机单实例、双机双实例、双机四实例三种配置下各跑五分钟记录平均帧耗时和传感器数据完整性。如果分布式平台的表现是四实例总吞吐是单实例的三倍以上说明编排层没有成为瓶颈。如果不到两倍建议先检查各实例的车辆数是否平均分配再看节点间的网络延迟是否拖慢了全局 tick 同步。6.2 共享内存回传的进阶优化方向分布式平台的数据回收最耗时的路径是传感器数据从 CARLA 进程到 Python 回调、再到磁盘。如果未来要把数据实时送入训练流程可以考虑把聚合节点的传感器数据写入/dev/shmtmpfs 内存文件系统避免落盘后再读的两次 I/O# 写入 /dev/shm数据直接进内存供同节点的训练进程零拷贝读取 np.save(f/dev/shm/sensor_{data.frame:06d}.npy, array)/dev/shm的读写速度比普通磁盘高一个数量级代价是断电即失、内存占用上升。跨节点传输时更好的做法是先在节点上聚合成一段序列压缩后再用 TCP 或对象存储转发避免每帧都走网络。我自己的习惯是每次调整调度参数前都先跑一遍上面的基准脚本拿到数字再改改完再跑绝不靠感觉调参。分布式平台的复杂性决定了它一定会在某个节点上以某种诡异方式出错你要做的是把错误变成可复现的、可度量的东西然后逐个排除。这套方法陪我撑过了好几个仿真平台项目希望帮到你。本文还有配套的精品资源点击获取 基于CARLA的分布式自动驾驶仿真平台：从单机瓶颈到集群架构解析
简介这是一份基于CARLA的分布式自动驾驶仿真平台毕业设计源码采用Python实现面向计算机、AI、自动化、电子信息等专业学生与科研人员可用于毕业设计、课程设计、作业提交或自动驾驶仿真项目初期的快速演示与二次开发。压缩包共17个文件包含13个Python脚本、2个Markdown说明、1个YAML配置及1份Word设计报告分别对应仿真主控、分布式同步、传感器数据定义、参数配置、日志模块、环境配置与设计文档结构清晰适合按模块逐步阅读。包体仅96KB轻量完整便于部署。目前已有64人学习下载。资源附带设计报告与介绍文档可帮助快速理解平台架构、同步机制与数据流走向源码经过测试功能稳定支持多客户端协同仿真与多模式手动控制覆盖从环境配置到运行调试的关键环节也可在现有框架上扩展更多自动驾驶场景适合作为高年级本科生或研究生的实践参考。1. 基于CARLA的高性能分布式自动驾驶仿真平台把“单机跑不动”变成“集群跑得动”基于CARLA的高性能分布式自动驾驶仿真平台核心要解决的只有一个问题单机跑不动。一辆车在 CARLA 里打开感知仿真GPU 占用率轻松过半一旦场景铺到几十辆带传感器的车辆渲染线程立刻成为瓶颈帧率往下掉回传的数据大量集中在同一时刻场景训练价值大打折扣。分布式平台的做法不是去优化单机而是把一个 CARLA 实例拆成多台机器上的多个实例靠一层统一的帧同步和场景编排逻辑把散落的节点组织成一台“更大的仿真机”。作为毕业设计这个方向工程量集中、可验证、有研究深度而且拿到的 zip 工程包通常已经帮你把平台骨架搭好剩下的就是理解它、跑通它、在它之上加自己的东西。下面我从架构模型讲起一直落到双节点集群搭建、数据回传和踩坑记录最后给出性能验证的方法。适合正要定课题、或者已经拿到工程包但不知道怎么启动的人。2. 先理解 CARLA 的分布式基因服务器-客户端模型与帧同步机制2.1 每个 CARLA 实例都是独立世界服务器-客户端模型的边界一个常见的误解是把 CARLA 当成一个单一程序启动后按时弹出渲染窗口然后跑 Python 脚本。真实架构里CARLA 拆成了两个可独立部署的部分——服务器和客户端。服务器是一个基于虚幻引擎的进程负责场景渲染、物理计算和传感器模拟客户端是用户侧的程序通过 PythonAPI 或者 C API 发指令、读状态。两者走 TCP 协议默认端口是 2000。这个拆分意味着分布式多实例不是硬改出来的而是架构自带的能力在一台机器上可以启动多个 CarlaUE4 进程只要端口不冲突每个进程就是完整独立的虚拟世界。分布式平台里的“节点”本质上是把这些进程分散到多台物理机器上。我第一次做多实例测试的时候直接开两个实例分别指定 2000 和 2001 端口# 节点 A启动第一个实例渲染质量设为 Low无头模式 ./CarlaUE4.sh -quality-levelLow -carla-port2000 -RenderOffScreen # 节点 A启动第二个实例换端口避免冲突 ./CarlaUE4.sh -quality-levelLow -carla-port2001 -RenderOffScreen这里有两个容易忽略的点。-RenderOffScreen是无头模式渲染照常进行但不显示窗口服务器裸奔时是必须项-quality-levelLow不只是省显存它还会影响物理仿真线程的调度方式这我在后面的避坑章节会专门讲。同一张 GPU 上跑两个实例时如果不手动指定显卡虚幻引擎会把显存随意瓜分表现就是两个实例都卡。上面没有给绑定 GPU 的写法是因为不同版本的 CARLA 对-ini参数支持度不一样我更习惯用环境变量CUDA_VISIBLE_DEVICES配合启动脚本管理这样每个进程启动前就知道自己该用哪块卡。在代码层面客户端连接实例只需要 IP 加端口。下面是一个可靠的连接探测写法不用get_world()直接拿世界而是先探测版本号等服务器真正就绪import carla import time def connect_server(host, port, timeout60): client carla.Client(host, port) client.set_timeout(5) deadline time.time() timeout while time.time() deadline: try: version client.get_server_version() print(f[OK] {host}:{port} 返回 {version}) return client except Exception as exc: print(f等待 {host}:{port} 就绪{exc}) time.sleep(3) raise RuntimeError(f{host}:{port} 在 {timeout}s 内未就绪)set_timeout(5)设置的是单次请求的超时上限循环里的timeout60是总等待时间。第一次连接时 CARLA 可能还在加载地图get_server_version()会抛异常循环重试是最稳的校验方式。很多同学拿到 zip 工程后直接跑主脚本报错九成情况是服务器还没加载完成就去连代码就崩了。2.2 同步模式下的帧协调为什么分布式平台必须统一帧率如果多实例各跑各的时间线分布式就没有意义节点 A 采集的数据和节点 B 采集的数据对不上帧号训练时拼不成一组完整场景。CARLA 默认是异步模式服务器按自己的节奏推进客户端只负责发指令、收数据。要想让多个实例步调一致必须开启同步模式。同步模式的含义是服务器每推进一帧都会等所有参与方处理完这一帧的数据再继续往下走。核心设置是synchronous_mode与fixed_delta_secondsworld client.get_world() settings world.get_settings() settings.synchronous_mode True settings.fixed_delta_seconds 0.05 # 每帧 50ms等效 20 FPS world.apply_settings(settings) # 由客户端主动推进一帧 world.tick()fixed_delta_seconds决定仿真步长。0.05 秒对应 20 FPS是我在多实例平台上的默认值渲染压力可控传感器数据帧率足够训练使用。改成 0.03 甚至 0.025 能跑到 33~40 FPS但每个实例的 CPU 占用会明显抬升多实例场景下容易拖垮物理线程。实际项目里自动驾驶车本身的传感器跑 20 Hz 就够交通流车辆用 10 Hz 也没问题差异在客户端过滤即可没必要让服务器空转更高帧率。分布式平台里最忌讳的是多个客户端同时推动同一个实例的 tick。CARLA 允许一个实例被多个客户端连接如果两个客户端各自开着同步模式、各自调用world.tick()服务器会收到重复推进指令帧率直接翻倍所有传感器的帧号全部跳变。正确的分工是每个实例只由一个工作线程负责 tick其余客户端全部设为synchronous_modeFalse只读数据不推帧。这个设计原则会在第四章的编排代码里反复用到。2.3 单机仿真的三个天花板以及分布式为什么能突破把单机瓶颈拆成三个维度方便后面做性能对比。瓶颈维度单机上的表现分布式处理手段GPU 渲染场景车辆超过 30 辆帧率跌破 15 FPS多实例分摊渲染负载每个实例只渲染自己的场景CPU 物理Traffic Manager 在单实例中串行调度车辆越多越卡多实例分担车辆和行人交通流互相独立数据 I/O相机、LiDAR 每帧回传几十 MB 数据TCP 回传挤占带宽本地先落盘、后聚合跨节点只传结果摘要渲染是第一个触到顶的瓶颈。CARLA 的传感器模拟依赖虚幻引擎渲染管线8 颗相机加一颗雷达单帧数据量可以到几十 MB。如果平台要做多智能体协同仿真上千帧连续跑下来回传会变成一个巨大的 I/O 事件。分布式架构把请求分摊到每台机器的本地资源本质上是一种分治思路把一个大世界切分成多个 CARLA 实例用编排层统一派发任务。到这一层你就会理解这种 zip 工程包的核心目录应该包含什么平台代码、启动脚本、场景配置和数据处理模块。平台代码负责多实例状态管理启动脚本负责拉起 CarlaUE4 进程场景配置定义每个实例的车辆数和任务数据处理模块解决数据回收。先看懂这一层后面动手才不会乱。3. 从零搭建双节点 CARLA 集群环境、启动脚本与最小编排3.1 Ubuntu 24.04 下 CARLA 环境准备与 Docker 化部署平台的第一块地基是环境。CARLA 当前主线版本对 Ubuntu 24.04 已有较好的支持但初次安装有两个高频坑一是显卡驱动与系统内核不匹配二是 Python 版本不对导致 PythonAPI 导入失败。原生安装的检查顺序我一般照着三步走# 第一步确认显卡驱动可用 nvidia-smi # 第二步确认 Python 版本CARLA 0.9.15 之后要求 Python 3.8 python3 --version # 第三步解压 CARLA 包并查看核心目录 mkdir -p ~/carla tar -xzf CARLA_0.9.15.tar.gz -C ~/carla ls ~/carla/CARLA_0.9.15/如果你的机器上跑的是常见发行版解压后能看到CarlaUE4.sh、PythonAPI、Tools等目录。PythonAPI 目录下是carla的 Python 包需要把它加进PYTHONPATH才能import carla。这一步我吃过亏脚本直接import carla报 ModuleNotFoundError折腾半天发现是环境变量没配。容器化部署时先验证 GPU 容器运行时是否可用docker run --rm --gpus all nvidia/cuda:12.2.0-base-ubuntu22.04 nvidia-smi能正常输出显卡信息说明 Docker 侧没问题。之后拉取 CARLA 官方镜像并映射端口。容器方式的好处是每个计算节点的环境完全一致不用逐台机器装依赖缺点是渲染性能有约 5%~10% 的损耗显存分配也不够直观。毕业设计阶段我建议双轨并行开发时用 Docker 保证环境一致压测时切回原生安装拿真实性能数字。3.2 多节点 CARLA 实例启动命令行参数与 GPU 分配双节点集群的启动逻辑是把一批 CarlaUE4 进程分散到两台机器上。下面这个脚本是典型的批量拉起方式#!/bin/bash # 两个节点的 IP 与端口列表 NODES(192.168.1.10:2000 192.168.1.10:2001 192.168.1.11:2000 192.168.1.11:2001) for entry in ${NODES[]}; do ip${entry%%:*} port${entry##*:} # 通过 ssh 远程启动nohup 保证 ssh 断开后进程继续运行 ssh carla$ip cd /opt/carla nohup ./CarlaUE4.sh \ -quality-levelLow -carla-port$port -RenderOffScreen \ /tmp/carla_$port.log 21 sleep 3 done这里有两个关键点。第一nohup必不可少如果不加ssh 连接一断开远程进程会被 SIGHUP 信号杀掉这是新手最容易碰到的“过一会儿节点就没了”的翻车现场。第二sleep 3只是粗略的间隔控制真正可靠的等待方式是在编排脚本里轮询连接状态而不是靠固定睡眠。多节点部署时ssh 免密登录要先配好否则脚本会在输入密码处卡住。启动之后需要确认进程真的活着而且用的是预期那块 GPU# 在任意节点执行查看 CarlaUE4 进程 ssh carla192.168.1.10 ps aux | grep CarlaUE4 | grep -v grep # 确认显存占用 nvidia-smi --query-gpuindex,memory.used,utilization.gpu --formatcsv如果发现两个实例挤在同一张 GPU 上老老实实处理。常见做法是给每个实例配CUDA_VISIBLE_DEVICES因为多个 CarlaUE4 进程默认会自选显卡不手动约束的话负载分配完全随机。3.3 客户端连接与场景分发第一份可运行的编排脚本实例起来了下一步是让编排层把场景分发到各个实例。先做一个能遍历所有服务器并确认连接正常的最小脚本import carla import time SERVER_POOL [ (192.168.1.10, 2000), (192.168.1.10, 2001), (192.168.1.11, 2000), (192.168.1.11, 2001), ] def wait_for_server(host, port, timeout60): client carla.Client(host, port) client.set_timeout(5) deadline time.time() timeout while time.time() deadline: try: version client.get_server_version() print(f[OK] {host}:{port} - {version}) return client except Exception: print(f等待 {host}:{port} 就绪...) time.sleep(3) raise RuntimeError(f{host}:{port} 在 {timeout}s 内未就绪) clients [wait_for_server(host, port) for host, port in SERVER_POOL] print(f成功连接 {len(clients)} 个 CARLA 实例)每个carla.Client对象对应一个独立实例后续的分发逻辑就是给每个实例下发不同的场景文件和数据采集任务。注意这里的SERVER_POOL是静态配置实际平台里应该做成动态注册——节点上线后通过心跳上报自己的负载再由调度器决定把任务分给谁。4. 分布式场景编排与数据回传把集群能力变成实际可用的仿真服务4.1 基于 PythonAPI 的分布式场景编排从串行到并行的任务分发编排层是分布式平台的大脑。它要做的事很简单一批场景多个实例怎么分配、怎么回收。最原始的做法是写一个 for 循环一个场景跑完再跑下一个但这样实例空闲时间太多。正确做法是任务队列加工作线程每个线程连接一个实例不断从队列里取任务import threading from collections import deque task_queue deque() for scenario_id in range(20): task_queue.append({ scenario_id: scenario_id, map: Town01 if scenario_id % 2 0 else Town02, weather: ClearNoon if scenario_id % 3 0 else CloudyNoon, num_vehicles: 30, }) def worker(client, worker_id): while True: try: task task_queue.popleft() except IndexError: break try: run_scenario(client, task, worker_id) except Exception as exc: print(fworker {worker_id} 执行 task {task[scenario_id]} 失败{exc}) # 每个线程绑定一个独立的 CARLA 客户端 threads [] for i in range(4): client carla.Client(192.168.1.10, 2000 i) # 注意每个 worker 单独连接 client.set_timeout(30) t threading.Thread(targetworker, args(client, i)) t.start() threads.append(t) for t in threads: t.join()这个方案里的关键约束是一个 worker 只用一个客户端一个客户端只连一个实例。千万不要在多个线程里共享同一个carla.ClientPythonAPI 内部对客户端对象的并发访问没有加锁共享会引发随机崩溃。线程数等于实例数这是最简单也最不容易出错的映射关系。如果你要做的平台更像服务而不是一次性脚本全局调度器会维护一个实例状态表记录每个实例当前在跑哪个场景、剩余帧数、负载情况。任务级别可以做到“场景粒度”一个场景在一个实例上完整跑完而不是一个场景被切成多段分给多台机器。CARLA 目前不支持跨实例的世界状态同步所以场景切分不是这个平台的正确玩法。4.2 传感器数据回传本地缓存、结果聚合与存储格式数据回收是分布式平台的第二个核心问题。每个 CARLA 实例上一旦挂载相机和 LiDAR单帧数据量就是几十 MB如果所有节点把原始数据实时回传给中心服务器千兆网也会被打满。我采用的方案是“分两段走”采集端本地落盘聚合端定时扫描回收。import numpy as np import os def sensor_callback(data, sensor_id, save_dir): # data.raw_data 是传感器原始字节流转成 numpy 数组 array np.frombuffer(data.raw_data, dtypenp.uint8) # 帧号 传感器 ID 作为文件名帧号用于跨节点对齐 os.makedirs(save_dir, exist_okTrue) np.save(f{save_dir}/{sensor_id}_{data.frame:06d}.npy, array)这段代码里最关键的是data.frame。同步模式下所有实例的帧号起点一致因此帧号可以作为跨节点数据对齐的依据。归档目录建议按“节点 IP 端口 传感器类型”分层避免多个传感器写同一个目录产生文件名冲突。不同传感器的存储格式很有讲究。我的习惯是传感器类型推荐存储格式原因相机RGBPNG 压缩或 JPEG单帧数据小文件可预览LiDARASCII PLY 或 npy点云处理方便npy 读取更快毫米波雷达CSV 或 npy数据量小直接落表CAN 总线数据CSV结构化强便于后期分析聚合端不需要逐帧分析文件而是扫描目录里已经写满的帧序列按帧号拼接成完整样本。这样原始数据永远留在节点本地中心服务器拿到的只是压缩后的样本网络开销降到最低。4.3 调度参数设置实例数量、batch 大小与队列深度这一节列出的参数我在多个平台上反复调过可以直接抄作业参数推荐值说明fixed_delta_seconds0.05仿真帧间隔等效 20 FPS每实例最大车辆数30超过 30 辆物理线程瓶颈明显每张 GPU 实例数1~2渲染质量 Low 时取 2质量设为 Epic 时只能 1客户端超时30s首次加载地图时非常容易超时任务队列深度实例数 x 10队列太长会导致场景等待时间过久第一个要调的是每 GPU 实例数。显存 24 GB 的显卡跑 Low 质量两个实例各占约 8 GB留出余量给数据缓冲如果开到三个虚幻引擎的内存碎片会导致半小时后某个实例崩掉这是环境稳定性的大坑。第二个要调的是车辆数。Traffic Manager 在同步模式下每个 tick 都要重新规划所有车辆的动作车辆数从 30 涨到 50单帧耗时可能从 50ms 涨到 90ms直接击穿帧间隔。所以在spawn_vehicles()的时候就要控制数量而不是跑起来之后再调。第三个是队列深度。任务队列太长前面的场景还在跑后面的场景已经加载好等着实例并不会因此空转但队列太长会导致整个平台的端到端延迟变高。实例数乘以 10 是经验值保证任意时刻至少有几个任务在排队又不会积压太久。5. 分布式 CARLA 避坑指南四个高频故障的现象、原因与对策5.1 现象客户端连不上服务器报错 Timeout / Could not connectcarla.Client创建时没问题第一次调用get_server_version()就超时错误信息只给一个笼统的 timeout。原因有三类按概率排序服务器还没加载完、端口被防火墙挡住、set_timeout设得太短。尤其是首次启动时虚幻引擎要加载地图和材质慢的机器可能需要两分钟默认的 10 秒超时完全不够。对策是分步排查。先看端口通不通# 在客户端节点上探测端口 nc -zv 192.168.1.10 2000如果端口通但 Python 里仍然超时把连接的总体超时设为 30 秒以上并加上第 3 章里的轮询等待逻辑。如果nc都不通检查服务器节点防火墙sudo ufw allow 2000/tcp5.2 现象两个实例的帧号对不上传感器数据时间戳错乱配置了同步模式但收集回来的数据里实例 A 的帧号是 1000 时实例 B 已经到了 1003而且差异随时间增大。原因基本是某个实例被多个客户端连接或者某个客户端里开启了 Traffic Manager 的自动 tick。Traffic Manager 默认会在自己的线程里推进仿真和主动调用world.tick()形成竞争导致帧号漂移。对策是全局统一推进入口。所有实例只允许编排线程调用world.tick()Traffic Manager 必须显式关闭自动同步traffic_manager client.get_trafficmanager(port) traffic_manager.set_synchronous_mode(True)注意这里的端口参数要对应实例端口否则 Traffic Manager 会连到错误实例上。同步模式下set_synchronous_mode(True)和编排线程的world.tick()必须配合使用少了任何一个都会乱。5.3 现象多实例运行半小时后某个节点显存占满CARLA 进程直接崩溃三个实例跑在两张 GPU 上前 15 分钟一切正常之后某个实例的显存占用持续爬升最后 OOM 崩溃。重启后又复现但每次崩的实例不一定是同一个。原因是虚幻引擎的内存回收机制和长周期任务不匹配。场景循环中不断 spawn 和 destroy 车辆引擎内的 Mesh、贴图资源不会立刻释放加上传感器回调里如果持有数据引用内存会只增不减。对策分三层。第一层降低渲染质量到 Low关闭阴影和反射第二层在脚本里定期调用world.reset_all_actors()清理遗留下来的 actor第三层给每个实例配置最大内存上限监控接近阈值时自动重启实例。由于 CARLA 实例重启后世界状态会清空这个操作必须在任务边界执行不能在场景中途做。5.4 现象同一套代码节点 A 正常节点 B 的数据乱序且丢帧双节点平台节点 B 的传感器数据经常跳帧严重点的情况是 LiDAR 和相机的时间戳对不上差了几个帧周期。原因大概率是节点 B 的物理机 CPU 核数不够。CARLA 的虚幻引擎主线程和物理线程需要多个物理核并行如果节点 B 只有 4 核而节点 A 有 16 核在同步模式下服务器会因为物理计算来不及完成而跳帧。同步模式不丢帧但会用更长的 tick 间隔来表达“没算完”表现就是客户端看到的数据帧号稀疏。对策是先做资源配置检查lscpu看核数free -h看内存nvidia-smi看显卡。至少 8 核 16 GB 内存、8 GB 显存才适合跑一个 Low 质量实例。异构节点做平台测试时把实例数和车辆数按节点算力分开配不要用全局参数一把梭。6. 验证分布式平台的性能收益基准测试方法与共享内存优化6.1 用帧号与时间戳做最小基准测试平台搭完需要拿出性能数字。最简单的基准是测单实例的 tick 耗时在同步模式下连续 tick 200 帧统计平均耗时import time start time.time() for _ in range(200): world.tick() elapsed time.time() - start print(f平均帧耗时: {elapsed / 200 * 1000:.1f} ms) print(f等效帧率: {200 / elapsed:.1f} FPS)分别在单机单实例、双机双实例、双机四实例三种配置下各跑五分钟记录平均帧耗时和传感器数据完整性。如果分布式平台的表现是四实例总吞吐是单实例的三倍以上说明编排层没有成为瓶颈。如果不到两倍建议先检查各实例的车辆数是否平均分配再看节点间的网络延迟是否拖慢了全局 tick 同步。6.2 共享内存回传的进阶优化方向分布式平台的数据回收最耗时的路径是传感器数据从 CARLA 进程到 Python 回调、再到磁盘。如果未来要把数据实时送入训练流程可以考虑把聚合节点的传感器数据写入/dev/shmtmpfs 内存文件系统避免落盘后再读的两次 I/O# 写入 /dev/shm数据直接进内存供同节点的训练进程零拷贝读取 np.save(f/dev/shm/sensor_{data.frame:06d}.npy, array)/dev/shm的读写速度比普通磁盘高一个数量级代价是断电即失、内存占用上升。跨节点传输时更好的做法是先在节点上聚合成一段序列压缩后再用 TCP 或对象存储转发避免每帧都走网络。我自己的习惯是每次调整调度参数前都先跑一遍上面的基准脚本拿到数字再改改完再跑绝不靠感觉调参。分布式平台的复杂性决定了它一定会在某个节点上以某种诡异方式出错你要做的是把错误变成可复现的、可度量的东西然后逐个排除。这套方法陪我撑过了好几个仿真平台项目希望帮到你。本文还有配套的精品资源点击获取