Carla自动驾驶仿真平台从零上手：安装、配置与常见运行错误详解

1. Carla到底是什么：它在自动驾驶仿真里处于什么位置

有朋友问我，Carla到底怎么跑起来？我的第一反应总是反问一句：你跑Carla是想解决什么问题？因为同样一个Carla，有人拿它做感知算法验证，有人拿它做规划控制测试，还有人纯粹是想搭一个数字孪生场景拍演示视频。这三个方向对硬件、软件配置、运行模式的要求完全不一样，你抱着“随便跑跑看看效果”的心态去装，大概率会在第一步就被一堆环境问题卡住。

Carla（Car Learning to Act）本质上是一个开源的自动驾驶仿真平台，基于Unreal Engine 4开发，提供了车辆动力学模型、传感器仿真、交通流模拟、地图场景编辑等一整条链路。它和Gazebo、SUMO这些仿真器的区别在于：Gazebo偏机器人领域，物理引擎强但画质弱，SUMO是纯交通流级宏观仿真，不涉及车辆底盘的精细动力学和传感器信号。Carla则正好卡在中间偏下的位置，它既要还原真实的传感器数据（相机图像、激光雷达点云、毫米波雷达反射），又要提供可编程的交通环境，还能通过Python API和ROS接口跟外部算法闭环联动。

从我实际使用的感受来说，Carla最值钱的地方不是画面渲染，而是“传感器仿真真实度”和“环境可编程性”。它的相机输出带畸变和曝光参数，激光雷达点云有反射强度通道，这些都是拿来训练感知模型的硬指标。而且Carla内置了多种天气系统（晴天、雨天、大雾、夜晚）、多种地图（城中村、高速公路、乡村道路），可以用Python脚本动态切换，这对做强化学习里的环境泛化特别关键。

如果你是刚入门，我建议先把Carla当成“带物理引擎的自动驾驶沙盒”来理解。它分服务器端和客户端两端：服务器端负责渲染场景、跑车辆动力学、输出传感器数据，客户端负责决策算法输入控制指令，两端通过本地或跨机的网络端口通信。你第一次跑通Carla，实际上就是把服务器端启动起来，再用一个客户端脚本去连接它。

2. 动手之前：硬件评估与软件环境准备

2.1 硬件门槛：显卡、显存、内存到底要多高

Carla的硬件需求是我见过最容易被低估的。官方写的最低配置是8GB内存、6GB显存，但我实测下来这只是一个“能进主菜单”的配置，离顺畅跑起来差很远。我自己用过三代不同的机器跑Carla，这里直接说结论。

第一档是入门型（勉强能跑老版本）：GTX 1660 Super 6GB显存、16GB内存、i5-10400F。这个配置跑Carla 0.9.14的Town01地图，1080p分辨率低画质，能得到大概20到30帧，能用，但转视角会明显卡顿。第二档是推荐型（日常开发够用）：RTX 3060 Ti 8GB显存、32GB内存、i7-12700。这个配置能稳定跑30到40帧，开中高画质不爆显存，正常做算法验证没问题。第三档是舒适型（带复杂场景和多个传感器）：RTX 4080或以上，显存至少12GB。

核心考量在显存。Carla的传感器数据大部分要从GPU显存里走一道，比如你同时挂了4个鱼眼相机、1个128线激光雷达、2个毫米波雷达，每帧的数据量会迅速吃满显存。显存一旦不够，系统会退到共享内存，帧率直接断崖式下跌，甚至DirectX崩溃。

内存方面同样不能省。Carla加载地图的时候，会把地图纹理和网格一次性载入内存，Town01这种中小型地图大概吃8到10GB，Town06这种带高速路的长地图直接奔着15GB去了。你如果后台还开着Chrome、PyCharm、ROS，16GB内存基本见底。

2.2 系统与驱动：Windows和Ubuntu我都试过

Carla官方支持Windows和Ubuntu两个平台，两个平台我都长期用过，说下各自适合的人群。

Windows上手简单，双击运行程序就能跑，不用折腾显卡驱动和编译环境。但对后续做联合仿真不太友好，因为Carla和ROS的生态基本绑定在Linux上，你在Windows上跑完Carla，后面想接Autoware、Apollo这些平台，还得换系统重来一遍。Ubuntu则是官方推荐的开发环境，稳定性更好，显存分配、网络通信效率都更优。缺点是驱动安装和依赖配置对新手不太友好，很容易卡在显卡驱动装不上导致黑屏这一步。

如果你目标是做自动驾驶算法开发而不是单纯看效果，我建议直接上Ubuntu 20.04 + ROS Noetic，这是Carla社区兼容性最稳的组合。如果只是初识体验，Windows 10或11都能跑，别在Windows 11上跑太旧的版本。

驱动方面有一个关键点：NVIDIA显卡必须装对应版本的Studio或Game Ready驱动，然后用nvidia-smi确认驱动识别正常再装CUDA。注意，Carla本身不需要你手动装CUDA工具包，它是自带预编译运行时和Unreal引擎依赖的。很多人看到报错里有CUDA字样就跑去装CUDA，其实绝大多数情况是显卡驱动太旧或者没识别到，而不是CUDA缺失。

2.3 必须提前备好的依赖和工具

除了系统本身，还有几个常见依赖，提前装好能省不少事。

• Visual Studio C++ Redistributable（仅Windows），装完显卡驱动后用dxdiag检查DirectX 12是否可用。
• Python 3.8或3.9，Carla官方对Python版本兼容性很挑剔，建议用conda或venv建一个独立环境，避免跟系统Python打架。
• 网络代理或稳定镜像源，Carla后期要下载大量素材和扩展包，网络不稳定会中断下载。
• 如果跑ROS联动，提前装好ROS Noetic、rqt_graph、rviz等工具。

还有一点容易被忽略：磁盘空间。Carla安装包本体接近20GB，解压后膨胀到近30GB，外加你下载的地图扩展包、素材包，建议预留至少80GB可用空间。曾经我把Carla装在固态硬盘的剩余空间里，结果解压中途报磁盘满，整个安装包损坏，又得重新下载20GB，那种体验实在难受。

3. 下载安装与目录结构解析

3.1 从官网拿到正确版本

Carla的下载页面在carla.org的Get Started入口，里面会列出多个版本，大多数人是分不清版本之间差异的。我建议直接下载最新稳定版本（写这篇文章时是0.9.15），不要碰Nightly builds，那是不稳定开发版，经常出现场景加载失败、API不兼容的问题。

下载时你会看到两个链接：一个是原始安装包，一个是你所在地区的高速镜像（通常在中国大陆可以通过镜像下载）。有些人会在网上论坛找别人压缩的绿色版，我强烈不建议这么干。Carla的安装包带文件校验和，不是官方源的版本，有小概率缺文件或被人添加额外内容，跑起来报错你是排查不出来的。

版本选择上还有一个隐性问题：Carla 0.9.x系列和0.8.x系列的API完全不同。如果你学习时看的是老教程，照着0.8.4版本的代码连0.9.15，所有API调用都会报错。下载前先确认自己网上找到的教程对应版本，最好是去官方文档查对应版本的API变更记录。

3.2 解压后就别乱动：目录里这些东西是干嘛的

安装包里主要的文件/文件夹有：

• CarlaUE4.exe（Windows）或CarlaUE4.sh（Ubuntu）—— 服务器端入口，必须从这里启动模拟器。
• CarlaServer/Carla目录 —— 存放服务端配置、日志和相关动态库，一般不用管。
• PythonAPI目录 —— 这是你Python客户端要用的核心库，里面嵌套了carla文件夹，包含编译好的Python库。
• Unreal/CarlaUE4/Content—— 存放地图、车辆模型、建筑模型等资源。
• Engine—— Unreal引擎自身依赖，千万别乱改，改错一个配置文件就可能起不来了。

我第一次拿到的Carla是一个名为Carla_0.9.15的压缩包，解压后没有可执行文件，只有一堆文件夹，当时我到处找安装脚本。后来才搞明白，Carla就是纯绿色免安装版，解压后直接用CarlaUE4.exe启动就算“安装完成”。没有注册表、没有系统级依赖，这点比很多工业软件方便得多。

3.3 添加环境变量：把PythonAPI指给解释器

这一步非常关键，也是热词里出现的“运行错误”重灾区。默认情况下，你解压Carla后，在终端里import carla是会报错的，因为Python根本找不到carla模块定义。原因很简单：Carla的Python库不在Python默认搜索路径里，需要你手动把路径加进去。

Windows下操作如下：

1. 打开“系统属性” -> “高级” -> “环境变量”。
2. 在“系统变量”里新建一个名为CARLA_ROOT的变量，值填解压根目录，例如D:\Carla_0.9.15。
3. 再找Path变量，编辑，追加%CARLA_ROOT%\PythonAPI\carla\dist和%CARLA_ROOT%\PythonAPI两个路径。

Ubuntu下则在~/.bashrc结尾追加：

export CARLA_ROOT=/opt/Carla_0.9.15 export PYTHONPATH=$PYTHONPATH:$CARLA_ROOT/PythonAPI/carla/dist

保存后执行source ~/.bashrc生效。检查是否配置成功，在Python环境里跑：

import carla print(carla.__version__)

如果输出类似0.9.15的版本号，说明环境变量配置成功。

有一个细节：PythonAPI/carla/dist目录里通常会有一个.egg文件名的库文件，不同Python版本编译出的egg名后缀不同。如果你用的Python版本和Carla编译时的版本不一致，import carla依然会报错。这时可以到该目录看下egg文件名，比如carla-0.9.15-py3.5-linux-x86_64.egg，说明它针对Python 3.5编译，你得换一个与Python 3.8对应的Carla版本，或者用Carla提供的setuptools方式安装到当前Python环境。

4. 第一次运行：启动模拟器与常见运行错误

4.1 服务器端怎么启动

在Windows下双击CarlaUE4.exe或在Ubuntu下执行./CarlaUE4.sh，会弹出一个类似游戏引擎的画面窗口。这个时候，Carla就进入了服务器模式，默认监听本地端口2000。给两个常用配置项：

• 低画质模式：在启动命令后加-quality-level=Low，能显著降低显存占用，在显存不足的机器上保命。
• 无窗口模式（离线渲染）：加-RenderOffScreen，不显示画面但依然输出传感器数据，如果你想在服务器上跑Carla不占图形界面，用这个。

首次启动时Carla会加载初始地图，通常是Town01。加载过程可能持续几十秒到几分钟，取决于硬盘速度和CPU性能。你会在窗口右上角看到一个小方框显示帧率（FPS），帧率稳定后说明服务器端正常。

我实操中遇到的一个问题：启动后窗口能弹出来，但整个画面是黑的，等了10分钟也没反应。排查后才发现是显卡驱动太旧，Unreal引擎初始化DirectX 12失败。后来更新到最新NVIDIA驱动，问题解决。所以第一步启动后，优先确认画面有没有渲染出蓝天白云的场景，而不是只在任务管理器里看到进程存在。

4.2 常见运行错误速查

把热词榜上常见的Carla/仿真相关运行问题整理成一张表，都是我实际遇到过或帮朋友排查过的。

这些错误里，最坑的是“端口被占用”。我遇到过一款进程监控软件自动占用了2000端口，Carla服务器其实已经启动成功了，但客户端就是连不上。排查方法是在启动客户端脚本前先确认Carla服务器窗口上有帧率显示，再用telnet 127.0.0.1 2000测试端口连通性。

4.3 客户端连接失败：一个排查实例

我第一次跑通Carla时，走的弯路值得分享。当时我按教程先双击启动CarlaUE4.exe，画面加载正常，然后运行官方示例脚本manual_control.py，结果终端直接报RuntimeError: failed to connect to server。一开始我以为服务器没起来，反复重启，后来才发现是防火墙在作祟。Carla默认监听TCP 2000端口，Windows防火墙弹窗询问是否允许访问，我没注意到点了阻止，导致所有本地回环之外的程序访问不了这个端口。

解决方式有两种：一是在防火墙出站规则里放行CarlaUE4.exe的公网/专用网络访问；二是用管理员权限启动客户端脚本。这个问题在Ubuntu下很少出现，因为Linux默认对本地回环端口访问比较宽松。

运行客户端脚本的通用姿势是：

cd /path/to/Carla/PythonAPI/examples python manual_control.py

运行起来后，你能用WASD键控制一辆车在地图里开动，这就是一个最简单的“运行成功”判断标准。

5. 跑第一个Python脚本：理解Carla的核心API

5.1 安装Python依赖

Carla客户端脚本依赖两个基础库：numpy和PIL，官方示例还经常用到pygame。在conda环境里一条命令装齐：

pip install numpy pygame Pillow

另外要根据你Python环境安装egg库对应包，Carla在0.9.14之后提供了.whl文件，可以直接pip安装：

pip install PythonAPI/carla/dist/carla-0.9.15-py3.8-linux-x86_64.whl

装完后import carla能正常通过，说明客户端环境准备完成。注意，如果你之前在别的Python工程里安装了旧版本的carla，务必先卸载干净再装新版本，否则会出现API属性缺失的小问题。

5.2 生成车辆、控制车辆、拍照——第一个脚本

一个最简化的Carla脚本包含四个核心步骤：连接服务器、加载地图、生成车辆、控制或读取数据。下面是我用来验证环境是否可用的最小脚本，你也可以直接抄：

import carla import math import time import random # 1. 连接服务器 client = carla.Client('127.0.0.1', 2000) client.set_timeout(10.0) # 2. 加载指定地图（首次会重建场景） world = client.load_world('Town01') # 3. 通过蓝图库取一辆车和路人模型 blueprint_library = world.get_blueprint_library() vehicle_bp = blueprint_library.filter('vehicle.tesla.model3')[0] # 4. 在某个出生点生成车辆 spawn_points = world.get_map().get_spawn_points() spawn_point = random.choice(spawn_points) vehicle = world.spawn_actor(vehicle_bp, spawn_point) # 5. 打印车辆信息 print("Vehicle spawned: ", vehicle.id) print("Location: ", spawn_point.location) # 6. 让车自己动起来 vehicle.apply_control(carla.VehicleControl(throttle=0.5, steer=0.0)) time.sleep(5) # 7. 添加一个RGB相机传感器 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_transform = carla.Transform(carla.Location(x=-6.0, z=2.5)) camera = world.spawn_actor(camera_bp, camera_transform, attach_to=vehicle) # 8. 注册回调，把相机数据保存到本地 camera.listen(lambda image: image.save_to_disk('output/%06d.png' % image.frame)) time.sleep(5) # 9. 清理actor，避免重复生成导致资源泄漏 camera.destroy() vehicle.destroy() print("Done.")

这个脚本能做的事情其实已经很多。vehicle.apply_control里两个核心参数是throttle（油门）和steer（转向），取值范围是0到1和-1到1。你还可以设置brake（刹车）和hand_brake（手刹）。Carla的车辆动力学模型会结合油门、刹车、转向和地面摩擦来实时解算，所以这个“让车跑起来”的过程和真实驾驶有很强的对应关系。

5.3 模型是红的、车不动？渲染物理与同步模式

航到第一次跑这个脚本，你会遇到三种典型现象。

第一种：车辆模型显示为红色半透明。这说明车辆模型还没有加载完整或深度缓冲区有问题，通常发生在低显存环境或长时间运行后。解决办法是重启Carla服务器，或降低纹理质量。

第二种：车辆模型看起来在半空悬空，没有落在地面上。这是因为Carla的车辆动力学仿真需要一个初始化时间，让车辆从空中位置下沉到路面并稳定。在world.tick()循环里多跑几步就好。如果你想要更快的落位，可以直接用vehcile.set_location()把z坐标降低到路面高度附近。

第三种：客户端程序里world.tick()一直不返回，卡死。这通常是同步/异步模式概念混淆导致的。Carla默认是异步模式，服务器端自己按固定时间步推进世界状态，客户端只是被动接收数据。但官方很多示例会调用world.apply_settings(carla.WorldSettings(synchronous_mode=True, fixed_delta_seconds=1.0/20.0))切换到同步模式，此时服务器不再自动推进，而是等客户端调用world.tick()才更新一帧。如果你在同步模式下忘记调用 tick，整个仿真就卡住了，表现为所有Actor都不动、传感器数据不更新。

同步模式的典型用途是与外部仿真器（如Carsim）做数据交互时需要保持时间步一致性，平时跑脚本建议用异步模式，不然容易卡住误以为死机。

6. 从“运行成功”到“能用来做项目”：扩展路径

6.1 和你已有的仿真工具做联动

Carla运行成功的下一步，很多人想的是和已有的仿真工具联动。最多见的是Carsim和Simulink联合仿真，这几乎成了自动驾驶算法验证的标准赛道玩法。

基本原理是：Carla负责渲染环境和传感器数据，Carsim负责车辆动力学精确解算，Simulink作为中间桥梁连接两者。流程是Carla把当前车辆的位姿信息发出去，Simulink/Matlab接收到后驱动Carsim解算出下一时刻的车辆状态（如速度、横摆角速度），再把结果回传给Carla做渲染和传感器更新。

配置过程中最常遇到的问题就是端口沟通和消息格式匹配。Carla这边通过ROS桥接包（carla-ros-bridge）或者自定义的Python socket接口把数据送出去；Carsim要通过VS Commands等外部通信接口定义好输入输出通道；Simulink里则要写一个S-Function或M文件定时拉取数据。整个过程涉及三套软件的版本匹配，很难一次成功，建议先在Carla侧跑通carla_ros_bridge的示例，确认ROS话题里有/carla/ego_vehicle/vehicle_status这类数据再去对接Carsim，不要上来就三端联调，会把你排查的耐心耗尽。

6.2 加入场景、传感器、地图资源

跑通基础场景只是一个起点，真正拿Carla做实验要往三个方向扩展。

第一个方向是场景丰富化。Carla内置了10多个官方地图（Town01到Town12等），不同Town对应不同道路结构，从城市网格、郊区、高速公路到港口物流场景都有。你可以用client.load_world('Town04')切换地图。同时天气系统可以用world.set_weather(carla.WeatherParameters(cloudiness=50.0, precipitation=80.0, fog_density=10.0))调整，这在感知算法鲁棒性测试里特别重要。

第二个方向是传感器扩展。除了camera.rgb，Carla还支持深度相机、语义分割相机、激光雷达、毫米波雷达、GPS、IMU等。每个传感器有自己的属性，比如激光雷达有channels（线数）、points_per_second（点云密度）、range（探测距离），毫米波雷达有horizontal_fov、vertical_fov。多传感器组合才能构成完整的感知输入，做传感器融合算法验证时我会在车顶挂一个64线激光雷达加6个摄像头，然后在Carla里实时观察每个传感器的输出。

第三个方向是多车协同和群体仿真。Carla支持在一张地图里同时生成上百个NPC车辆，它们会按交通规则自动行驶，可以给每辆车指定固定的路径点，也可以设置自动驾驶模式。我在做路口冲突决策算法测试时，同时生成40多辆有不同行驶策略的车，在一个红绿灯路口制造混行场景，这对模型压力测试效果很好。

6.3 多机分布式仿真与性能优化

Carla最初是单机软件，但它也支持分布式部署：一台机器跑Carla服务器，另一台或多台机器通过Python客户端连接同一台服务器，各自控制不同的车辆。这个模式下，计算和渲染集中在服务器，算法推理分布在客户端，很贴近真实车队的云端-车端架构。

实操时需要改两个地方。第一，在Carla服务器启动时加参数-carla-rpc-port=2000，并确保服务器机器的防火墙对客户端IP开放该端口。第二，客户端连接时把carla.Client('127.0.0.1', 2000)改成carla.Client('<服务器IP>', 2000)，同时设置正确的超时时间，防止网络延迟导致握手失败。

性能优化也有几个经验。尽量用fixed_delta_seconds固定步长，而不是直接跑物理实时模拟，因为固定步长能让多个客户端的时间戳一致。多个传感器同时工作时，用sensor.listen的回调频率设置减小CPU占用。渲染无关的场景可以关闭阴影和反射，用carla.WorldSettings调低配置。这些优化做下来，帧率提升和延迟降低肉眼可见。

7. 关键注意事项与长期维护心得

7.1 版本管理是最大的“隐藏坑”

Carla版本更新速度不算快，但每个版本的API变化都很大。0.9.11到0.9.12改了车辆控制API的一些字段，0.9.13到0.9.14改了地图命名方式和部分属性。我见过最严重的案例是，同事用0.9.12版本写的全套训练代码，放到0.9.14上几乎全部报TypeError和AttributeError，移植成本比重新写还要高。

我现在的做法是，在代码仓库里把Carla版本号固定写入requirements.txt，并在README里明确标注“请在Carla 0.9.15环境下运行”。机器学习训练时，我会分别创建不同conda环境，对应不同Carla版本，互不干扰。这个习惯在多人协作时尤其重要，省去了“跑不起来先互相猜疑”的时间。

7.2 资源清理与长时间运行的稳定性

Carla长时间运行会积累内存碎片和GPU资源占用，尤其是不停spawn_actor和destroy_actor的场景。如果你的代码在循环里反复生成车辆却不清理，内存会持续增长，最终卡到崩溃。规范做法是使用with上下文管理器或try/finally块，确保actor最终被销毁。

传感器同理，sensor.listen注册的回调会一直占用线程和缓冲区，不再使用时要调用sensor.stop()和sensor.destroy()。这个细节没做，跑12小时以上的数据采集任务基本注定中途挂掉。还有一个诡异的现象：Carla服务器连续运行几天后，画面会出现轻微纹理闪烁，这是Unreal引擎的纹理缓存问题，重启一次服务器就好，不用慌。

7.3 安全边界：别把仿真当现实

最后说一个容易被忽略但是很重要的事。Carla再怎么真实，车辆动力学模型和真实车辆依然有差距，传感器噪声和延时特征也偏理想化。比如Carla默认的激光雷达点云很“干净”，没有真实环境的雨滴噪点和灰尘反射。你做算法验证，可以通过结果判断算法合理性，但绝不能把仿真数据集当真实路测数据用。

我见过有些初学者拿Carla跑的视频和传感器数据做公司产品素材，结果被甲方专业人士一眼看出“仿真痕迹明显”。更好的做法是，在Carla里加入你们业务场景独有的物理噪声和对抗扰动，让仿真数据更接近真实环境。这样既保证了数据质量，也避免了“整个项目只有仿真效果能看”的尴尬。

我个人在实际操作中体会最深的是，Carla运行牵扯到的变量实在是太多了——从显卡驱动到端口占用，从Python版本到地图加载，任何一个环节出问题都会让你误以为是代码写错了。养成每次启动前检查服务器帧率的习惯，并且把不同版本的启动配置写成不同的命令脚本，能省下大量无意义的排查时间。先跑通最小示例，再逐步加传感器、换地图、做联调，这个顺序是最稳的。最后再分享一个小技巧：在Carla上做大量实验前，先花半小时给服务器和客户端分别写一个监控脚本，日志里带上时间戳和版本号，后续出问题你会感谢自己当初多写这几行。