1. 这不是一份“文档翻译”,而是一份我踩了三年坑后整理的 CARLA 中文实操手记
CARLA 不是玩具,它是一套工业级自动驾驶仿真平台,底层绑着 Unreal Engine 4.26、Python 绑定、C++ 模块、海量高清资产包,还有一整套跨平台构建流水线。你在网上搜到的所谓“中文文档”,90% 是机器翻译的 GitHub README 堆砌,连make launch报错时该看哪一行日志都懒得标红。我从 0.9.5 版本开始在 Ubuntu 18.04 上编译失败,在 Windows 10 上被libintl3.dll卡住三天,在 CI 服务器上因磁盘空间不足导致 UE4 编译中途崩溃——这些不是“报错”,是 CARLA 给你的入门考试卷。这份 FAQ 不是罗列问题,而是把每个高频故障背后的真实链路拆给你看:为什么CarlaUE4.sh在源码里根本不存在?为什么pip install carla在 0.9.12 后突然失效?为什么你export PYTHONPATH后脚本还是报ImportError: No module named 'carla'?答案不在官方文档里,而在你执行make PythonAPI时终端滚动的那几百行日志中——尤其是第 372 行那个被忽略的warning: failed to link libcarla.so。本文覆盖 Linux(Ubuntu 20.04/22.04)与 Windows(10/11)双平台,所有命令均经实测(含完整路径、权限要求、输出特征),不回避任何脏活累活。如果你刚下载完carla-0.9.15.tar.gz正准备解压,或者正盯着AttributeError: module 'carla' has no attribute 'Client'发呆,请先放下鼠标,读完这一段再动手——省下的 8 小时调试时间,够你跑完 5000 帧传感器数据采集。
2. 核心设计逻辑:CARLA 构建体系的本质是“三重耦合”
CARLA 的安装失败率远高于一般开源项目,根源在于其构建体系并非单一线性流程,而是由三个强依赖层嵌套耦合而成:UE4 引擎层 → CARLA 项目层 → Python 客户端层。任何一层的版本错位、路径污染或环境残留,都会在下游引发雪崩式故障。这不是设计缺陷,而是为保障仿真精度与物理引擎一致性所必须付出的代价。下面我用一个真实案例说明这三层如何互相绑架:
某用户在 Ubuntu 22.04 上执行
make launch失败,错误信息为ERROR: Could not find UE4Editor binary。他检查了UE4_ROOT,确认指向/home/user/UnrealEngine_4.26,且该目录下确有Engine/Binaries/Linux/UE4Editor文件。但make仍报错。真相是:他在同一台机器上曾用apt install unreal-engine安装过社区版 UE4,该版本将ue4-editor符号链接写入了/usr/bin/。当make脚本调用which ue4-editor时,返回的是/usr/bin/ue4-editor,而非他手动设置的UE4_ROOT路径。更隐蔽的是,这个社区版 UE4 实际指向的是 4.24 分支,与 CARLA 要求的 4.26 严重不兼容。最终解决方案不是改UE4_ROOT,而是sudo apt remove unreal-engine+rm /usr/bin/ue4-editor+hash -r清除 shell 命令缓存。
这个案例揭示了 CARLA 构建的底层逻辑:它不信任全局环境,只认绝对路径;它不接受“差不多”的版本,只认精确匹配的 commit hash;它不区分“已安装”和“已污染”,任何残留都视为潜在威胁。因此,所有官方文档中轻描淡写的“set your environment variable”背后,实际是一场对系统纯净度的严苛审查。下面我将按这三层耦合结构,逐层拆解关键细节与实操陷阱。
2.1 UE4 引擎层:CARLA 的地基,也是最易被忽视的雷区
CARLA 对 UE4 的依赖不是“调用 API”,而是“深度侵入式修改”。CARLA 的CarlaUE4项目直接修改了 UE4 的Source/Engine目录下的物理子系统、网络同步模块和渲染管线。这意味着:
- UE4 必须从源码编译,不能使用二进制安装包。Epic Games Launcher 下载的 UE4.26 安装包是预编译的,缺少
Source目录,CARLA 的Setup.sh脚本会直接报错ERROR: Unreal Engine source code not found。 - UE4 的 Git 仓库必须通过 Epic 官方账号克隆,且需严格验证邮箱。很多人卡在
git clone https://github.com/EpicGames/UnrealEngine.git报Permission denied (publickey),原因不是 SSH 密钥问题,而是未在 https://www.unrealengine.com/en-US/ue-on-github 注册并验证邮箱。注册后,需在 GitHub Settings → Applications → Authorized OAuth Apps 中,将 Epic Games 添加为授权应用。此步骤耗时约 5-10 分钟,但跳过则永远无法git clone。 - UE4 编译完成后的
Engine/Binaries目录大小约 12GB,且必须保留。很多用户为节省空间,在 CARLA 编译成功后删除UnrealEngine/Engine/Binaries,结果下次运行make launch时,CarlaUE4.sh因找不到UE4Editor而静默退出,无任何错误提示。
提示:UE4 编译是 CARLA 构建中最耗时的环节(Ubuntu 20.04 + i7-9700K + RTX 2080 Ti 约需 45 分钟)。建议在
UnrealEngine目录下执行./GenerateProjectFiles.sh -game -engine后,用make -j$(nproc) > build_ue4.log 2>&1将日志重定向。当编译卡在Building Target Program 'UnrealHeaderTool'超过 20 分钟时,大概率是内存不足(需 ≥32GB RAM),此时应killall -9 make并重启系统释放内存。
2.2 CARLA 项目层:从源码到可执行文件的“炼金术”
CARLA 项目层是连接 UE4 与 Python 的桥梁。它的核心产物是CarlaUE4可执行文件(Linux 下为CarlaUE4.sh,Windows 下为CarlaUE4.exe)和libcarla.so/.dll动态库。这里存在两个致命误区:
- 误区一:“下载源码包就能直接运行”。GitHub 上的
carla-0.9.15.tar.gz是仅包含 CARLA 项目代码的源码包,不含 UE4 引擎,也不含CarlaUE4.sh脚本。该脚本是在make过程中由Makefile动态生成的。若你解压后发现没有CarlaUE4.sh,不是下载错了,而是你还没执行make。 - 误区二:“make launch 就是启动模拟器”。
make launch实际执行的是三步操作:① 检查UE4_ROOT和CARLA_ROOT环境变量;② 运行UnrealEngine/Engine/Build/BatchFiles/RunUAT.sh BuildCookRun ...编译 CarlaUE4 项目;③ 启动编译好的CarlaUE4。其中第②步失败时,make launch会直接退出,且错误信息常被淹没在数百行 UE4 编译日志中。正确做法是先单独执行make CarlaUE4,观察其输出末尾是否有Packaging complete字样。
注意:
make CarlaUE4成功后,生成的可执行文件位于Unreal/CarlaUE4/Binaries/Linux/CarlaUE4(Linux)或Unreal/CarlaUE4/Binaries/Win64/CarlaUE4.exe(Windows)。CarlaUE4.sh脚本则位于项目根目录,内容仅为几行 shell 命令,用于设置环境变量并调用上述二进制文件。因此,CarlaUE4.sh的存在与否,完全取决于make CarlaUE4是否成功。
2.3 Python 客户端层:让脚本“看见”模拟器的神经接口
Python 客户端是用户与 CARLA 交互的唯一入口。它的核心是carla模块,该模块本质是一个 C++ 扩展(libcarla.so/.dll)的 Python 封装。其加载机制决定了 90% 的ImportError都源于路径混乱:
- CARLA 0.9.12 是分水岭版本。此前,客户端仅支持
.egg文件分发;此后,官方同时支持pip install carla(PyPI)、pip install carla-*.whl(本地 wheel 包)和传统.egg三种方式。但这三种方式互斥。若你用pip install carla安装了 0.9.15,再执行make PythonAPI生成的.egg文件将被 Python 优先忽略,因为pip安装的包在sys.path中排位更高。 .egg文件的命名是精确指纹。其格式为carla-0.9.15-py38-linux-x86_64.egg(Linux)或carla-0.9.15-py38-win-amd64.egg(Windows)。其中py38必须与你运行脚本的 Python 解释器版本完全一致(python3 --version输出3.8.10,则必须是py38,而非py3或py3810)。linux-x86_64则对应系统架构,ARM64 机器上若出现x86_64则必然报错%1 is not a valid Win32 app(Windows)或cannot open shared object file(Linux)。PYTHONPATH是双刃剑。官方教程推荐export PYTHONPATH=$PYTHONPATH:/path/to/carla/PythonAPI/carla/dist/carla-0.9.15-py38-linux-x86_64.egg,但这会导致所有 Python 进程全局加载该.egg。若你同时开发多个 CARLA 版本项目,极易因路径冲突导致AttributeError: module 'carla' has no attribute 'Client'。更安全的做法是在每个脚本开头动态插入路径:import sys import os # 替换为你的实际路径 carla_egg = "/home/user/carla/PythonAPI/carla/dist/carla-0.9.15-py38-linux-x86_64.egg" if carla_egg not in sys.path: sys.path.insert(0, carla_egg) import carla
3. 实操过程全记录:从零开始构建一个可运行的 CARLA 环境
以下流程基于 Ubuntu 20.04 LTS(Linux)与 Windows 10 21H2(Windows)双平台实测,所有命令与路径均为真实环境截图验证。请严格按顺序执行,跳步将导致不可逆的环境污染。
3.1 Linux 平台(Ubuntu 20.04)完整构建流程
3.1.1 系统准备与磁盘空间审计
CARLA 构建对磁盘空间的要求是硬性门槛,非建议值。170GB是官方给出的“最低要求”,实测中,一个干净的 Ubuntu 20.04 系统安装基础开发工具后,剩余空间约185GB。但构建过程会临时占用额外40GB(UE4 编译中间文件),若空间不足,make将在 UE4 编译阶段静默失败,错误日志中仅显示g++: internal compiler error: Killed (program cc1plus),这是 Linux OOM Killer 杀死进程的典型标志。
# 1. 检查可用空间(必须 ≥ 185GB) df -h / | awk '{print $4}' # 2. 更新系统并安装基础依赖(Ubuntu 20.04) sudo apt update && sudo apt upgrade -y sudo apt install -y build-essential python3-dev python3-pip python3-setuptools \ cmake libtbb-dev libboost-all-dev libeigen3-dev libglew-dev libglfw3-dev \ libxrandr-dev libxinerama-dev libxcursor-dev libxi-dev libxss-dev libxcomposite-dev \ libasound2-dev libpulse-dev libudev-dev libfreetype6-dev libfontconfig1-dev \ libgl1-mesa-dev libglu1-mesa-dev libvulkan-dev libvulkan1 libvulkan-dev # 3. 安装 Git LFS(必须!否则 UE4 克隆失败) curl -s https://packagecloud.io/install/repositories/github/git-lfs/script.deb.sh | sudo bash sudo apt install -y git-lfs git lfs install # 4. 创建专用工作目录(避免空格与中文路径) mkdir -p ~/carla_dev && cd ~/carla_dev3.1.2 克隆与编译 Unreal Engine 4.26
此步骤耗时最长,务必确保网络稳定。Epic Games 的 UE4 仓库体积超12GB,Git LFS 管理的大型资产包(如Engine/Content/Textures)需单独下载。
# 1. 克隆 UE4 仓库(注意:必须使用 HTTPS,SSH 不支持 LFS) git clone --depth=1 -b 4.26 https://github.com/EpicGames/UnrealEngine.git # 2. 进入 UE4 目录并生成项目文件 cd UnrealEngine ./GenerateProjectFiles.sh -game -engine # 3. 编译 UE4(使用全部 CPU 核心,重定向日志) make -j$(nproc) > build_ue4.log 2>&1 # 4. 验证编译结果(应输出 "UE4Editor" 路径) ls Engine/Binaries/Linux/UE4Editor # 正确输出示例:/home/user/carla_dev/UnrealEngine/Engine/Binaries/Linux/UE4Editor # 5. 设置 UE4_ROOT 环境变量(永久生效) echo 'export UE4_ROOT="/home/user/carla_dev/UnrealEngine"' >> ~/.bashrc echo 'export PATH="$UE4_ROOT/Engine/Binaries/Linux:$PATH"' >> ~/.bashrc source ~/.bashrc3.1.3 获取与构建 CARLA 项目
CARLA 官方 GitHub 仓库提供两种获取方式:git clone(推荐,可随时git pull更新)与tar.gz下载(适合离线环境)。此处以git clone为例。
# 1. 返回工作目录并克隆 CARLA cd ~/carla_dev git clone https://github.com/carla-simulator/carla.git # 2. 设置 CARLA_ROOT 环境变量 echo 'export CARLA_ROOT="/home/user/carla_dev/carla"' >> ~/.bashrc source ~/.bashrc # 3. 下载 CARLA 专用资产包(必需!否则启动黑屏) cd $CARLA_ROOT make sync # 4. 编译 CARLA 项目(生成 CarlaUE4 可执行文件) make CarlaUE4 # 5. 验证 CarlaUE4 是否生成 ls $CARLA_ROOT/Unreal/CarlaUE4/Binaries/Linux/CarlaUE4 # 正确输出示例:/home/user/carla_dev/carla/Unreal/CarlaUE4/Binaries/Linux/CarlaUE4 # 6. 构建 Python 客户端(生成 .egg 文件) make PythonAPI # 7. 验证 .egg 文件生成 ls $CARLA_ROOT/PythonAPI/carla/dist/ # 正确输出示例:carla-0.9.15-py38-linux-x86_64.egg3.1.4 启动与验证:从命令行到第一个 Python 脚本
make launch是启动 CARLA 服务端的快捷方式,但其内部逻辑复杂。为确保万无一失,我们分步验证。
# 1. 启动 CARLA 服务端(后台运行,便于后续调试) cd $CARLA_ROOT nohup ./CarlaUE4.sh -opengl -quality-level=Low > carla_server.log 2>&1 & # 2. 检查服务端是否监听 2000 端口(CARLA 默认端口) netstat -tuln | grep :2000 # 正确输出应包含:tcp6 0 0 :::2000 :::* LISTEN # 3. 运行第一个 Python 脚本(使用绝对路径加载 .egg) cd $CARLA_ROOT/PythonAPI/examples python3 -c " import sys sys.path.insert(0, '/home/user/carla_dev/carla/PythonAPI/carla/dist/carla-0.9.15-py38-linux-x86_64.egg') import carla client = carla.Client('localhost', 2000) client.set_timeout(10.0) world = client.get_world() print(f'Success! Connected to CARLA {world.get_map().name}') " # 正确输出示例:Success! Connected to CARLA Town01实操心得:
-opengl参数是 Linux 下的救命稻草。NVIDIA 驱动在某些 Ubuntu 20.04 系统上与 Vulkan 渲染器存在兼容性问题,导致CarlaUE4.sh启动后立即崩溃。添加-opengl强制使用 OpenGL 渲染器,可绕过此问题。若你使用 AMD GPU,则应替换为-vulkan。
3.2 Windows 平台(Windows 10)完整构建流程
Windows 构建的痛点在于 Visual Studio 版本冲突与 DLL 依赖地狱。CARLA 严格要求 Visual Studio 2019(16.11.x),任何其他版本(包括 VS2022)均会导致C2440、C2672等编译错误。
3.2.1 系统准备与 Visual Studio 清理
Windows 环境的脆弱性远超 Linux。一个残留的 VS2017 注册表项就足以让make调用错误的编译器。
# 1. 彻底卸载所有 Visual Studio 版本(管理员权限运行 PowerShell) # 进入 VS 安装器目录 cd "C:\Program Files (x86)\Microsoft Visual Studio\Installer\resources\app\layout" # 执行完全清理(此命令会删除所有 VS 相关文件与注册表) .\InstallCleanup.exe -full # 2. 重新安装 Visual Studio 2019 Community(必须勾选以下组件) # - "Desktop development with C++" # - "CMake tools for Visual Studio" # - "Windows 10/11 SDK" # - "CMake Tools" # 3. 安装 Python 3.8(x64 版本,必须!3.9+ 不兼容) # 从 https://www.python.org/downloads/release/python-3810/ 下载 Windows x86-64 executable installer # 安装时务必勾选 "Add Python to PATH" # 4. 安装 Git for Windows(含 Git Bash) # 从 https://git-scm.com/download/win 下载并安装 # 安装时选择 "Use Git and optional Unix tools from the Command Prompt"3.2.2 克隆与构建 UE4 与 CARLA
Windows 下的 Git 操作需特别注意换行符与 LFS 配置。
# 1. 在 Git Bash 中执行(非 CMD 或 PowerShell) # 设置 Git 全局配置(避免 CRLF 问题) git config --global core.autocrlf false git config --global core.filemode false # 2. 克隆 UE4(同 Linux,但需等待 LFS 下载完成) git clone --depth=1 -b 4.26 https://github.com/EpicGames/UnrealEngine.git # 3. 进入 UE4 目录并生成 VS 项目文件 cd UnrealEngine ./GenerateProjectFiles.bat -game -engine # 4. 使用 VS2019 打开并编译 UE4(GUI 操作) # 双击 UnrealEngine/Engine/Build/BatchFiles/RunUAT.bat # 在弹出窗口中选择 "Build Unreal Engine" -> "Win64" -> "Development Editor" # 编译完成后,关闭 VS2019 # 5. 克隆 CARLA 并设置环境变量 cd ~ git clone https://github.com/carla-simulator/carla.git # 在系统环境变量中添加: # UE4_ROOT = C:\Users\YourName\UnrealEngine # CARLA_ROOT = C:\Users\YourName\carla # 重启所有终端使变量生效3.2.3 解决 Windows 特有 DLL 依赖问题
libintl3.dll和libiconv2.dll缺失是 Windows 构建的标志性错误。它们是make工具链(MinGW)的依赖,而非 CARLA 自身。
# 1. 下载 MinGW 依赖包(官方提供) # 访问 https://carla-releases.s3.eu-west-3.amazonaws.com/Windows/dependencies.zip # 解压到 C:\carla_deps # 2. 将 DLL 复制到 make 工具所在目录 # 通常为 C:\Program Files\Git\usr\bin\ cp /c/carla_deps/libintl3.dll /c/Program\ Files/Git/usr/bin/ cp /c/carla_deps/libiconv2.dll /c/Program\ Files/Git/usr/bin/ # 3. 验证 make 是否能正常运行 make --version # 正确输出应为:GNU Make 4.33.2.4 启动与验证:Windows 下的稳健启动法
Windows 下make launch的稳定性较差,推荐使用CarlaUE4.exe直接启动。
# 1. 编译 CARLA 项目(在 Git Bash 中) cd $CARLA_ROOT make CarlaUE4 # 2. 手动启动 CarlaUE4.exe(GUI 方式,便于观察错误) # 打开文件资源管理器,导航至: # C:\Users\YourName\carla\Unreal\CarlaUE4\Binaries\Win64\ # 双击 CarlaUE4.exe # 若弹出 "Failed to load module" 对话框,点击 "Accept" 让 UE4 自动重建缺失模块 # 3. 运行 Python 脚本(使用绝对路径) cd $CARLA_ROOT\PythonAPI\examples python3 -c " import sys sys.path.insert(0, r'C:\\Users\\YourName\\carla\\PythonAPI\\carla\\dist\\carla-0.9.15-py38-win-amd64.egg') import carla client = carla.Client('localhost', 2000) client.set_timeout(10.0) world = client.get_world() print(f'Success! Connected to CARLA {world.get_map().name}') "4. 常见问题与排查技巧实录:一份来自生产环境的故障速查表
以下问题均来自我维护的 12 个 CARLA 生产集群的真实日志。每个问题都附带现象特征、根本原因、三步定位法与一键修复命令。这不是理论推测,是血泪经验。
| 问题现象 | 根本原因 | 三步定位法 | 一键修复 |
|---|---|---|---|
make launch报错ERROR: Could not find UE4Editor binary,但ls $UE4_ROOT/Engine/Binaries/Linux/UE4Editor存在 | make脚本调用which ue4-editor,而系统 PATH 中存在旧版 UE4 的符号链接 | 1.which ue4-editor2. readlink -f $(which ue4-editor)3. ls -la /usr/bin/ue4-editor | sudo rm /usr/bin/ue4-editor && hash -r |
AttributeError: module 'carla' has no attribute 'Client',且pip list | grep carla显示已安装 | Python 加载了 pip 安装的 carla(0.9.15),但脚本试图调用源码编译的.egg中的Client类,两者 ABI 不兼容 | 1.python3 -c "import carla; print(carla.__file__)"2. pip show carla | grep Version3. ls $CARLA_ROOT/PythonAPI/carla/dist/ | pip uninstall carla -y && make clean && make PythonAPI |
RuntimeError: rpc::rpc_error during call in function version | CARLA 服务端(CarlaUE4)与 Python 客户端(carla module)版本不匹配。常见于服务端为 0.9.14,客户端为 0.9.15 | 1../CarlaUE4.sh --version(Linux)或查看CarlaUE4.exe属性(Windows)2. python3 -c "import carla; print(carla.__version__)"3. cat $CARLA_ROOT/VERSION | cd $CARLA_ROOT && git checkout 0.9.14 && make clean && make CarlaUE4 && make PythonAPI |
ImportError: DLL load failed while importing libcarla: %1 is not a valid Win32 app | Python 解释器架构(32-bit)与libcarla.dll(64-bit)不匹配 | 1.python3 -c "import platform; print(platform.architecture())"2. file $CARLA_ROOT/PythonAPI/carla/dist/carla-*.egg(Linux)或查看 DLL 属性(Windows)3. where python | 卸载所有 32-bit Python,仅保留python-3.8.10-amd64.exe安装包 |
Fatal error: 'version.h' has been modified since the precompiled header(Linux) | Linux 内核更新后,/usr/include中的头文件时间戳变更,触发 UE4 PCH 重建失败 | 1.ls -la $UE4_ROOT/Engine/Intermediate/Build/Linux/B4D820EA/UnrealEditor/Inc/Engine/version.h2. stat /usr/include/stdio.h | grep Modify3. make help | grep hard-clean | make hard-clean && make CarlaUE4(耗时约 25 分钟) |
实操心得:
make hard-clean是 Linux 下的终极核武器。它会删除UnrealEngine/Engine/Intermediate和carla/Unreal/CarlaUE4/Intermediate下所有中间文件,强制 UE4 重新生成预编译头(PCH)。虽然耗时,但比花 3 小时排查version.h时间戳问题高效得多。我将其设为每日构建前的固定动作。
4.1 关于 “Update CARLA”:升级不是git pull那么简单
CARLA 的版本升级是系统工程,绝非git pull && make可以解决。0.9.14 升级到 0.9.15 涉及 UE4 引擎补丁、资产包哈希变更、Python API 接口调整三重变更。
升级前必做三件事:
- 备份
PythonAPI/carla/dist/下的所有.egg文件。新版本make PythonAPI会清空该目录。 - 检查
UnrealEngine仓库的4.26分支是否已同步最新 commit。CARLA 新版本常依赖 UE4 的特定 hotfix。 - 阅读
carla/Docs/CHANGELOG.md中的 Breaking Changes。例如 0.9.15 移除了carla.World.debug_draw_point()方法,改用carla.DebugHelper.draw_point()。
标准升级流程:
# 1. 进入 CARLA 目录并拉取最新代码 cd $CARLA_ROOT git fetch origin git checkout 0.9.15 # 2. 同步 UE4 引擎(关键!) cd $UE4_ROOT git fetch origin git checkout 4.26 # 若提示 "Your local changes would be overwritten",执行: git reset --hard origin/4.26 # 3. 重新下载资产包(哈希校验失败会自动触发) make sync # 4. 彻底清理并重建 make hard-clean make CarlaUE4 make PythonAPI # 5. 验证新版本 ./CarlaUE4.sh --version # 应输出 0.9.15 python3 -c "import carla; print(carla.__version__)" # 应输出 0.9.15注意:
make sync命令会校验Content/目录下所有资产文件的 SHA256 哈希值。若你手动修改过某个.fbx模型,make sync会将其恢复为官方版本,并输出Restoring file: Content/Static/Prop/prop_01.fbx。这是 CARLA 保证仿真一致性的设计,非 bug。
5. 关于快速启动包(Quick Start Package)的真相与适用场景
CARLA 官方提供的CARLA_0.9.15.tar.gz(Linux)与CARLA_0.9.15.zip(Windows)是“开箱即用”的二进制包,但它并非万能解药。理解其原理与局限,才能避免掉入“快速却不可靠”的陷阱。
5.1 快速启动包的构成与工作原理
快速启动包本质是一个预编译的 CARLA 服务端 + 预打包的 Python 客户端。其内部结构如下:
CARLA_0.9.15/ ├── CarlaUE4.sh # 启动脚本,内嵌 UE4Editor 路径 ├── PythonAPI/ │ └── carla/ │ └── dist/ │ └── carla-0.9.15-py38-linux-x86_64.egg # 预编译的 Python 模块 └── Unreal/ └── CarlaUE4/ # 已编译的 CarlaUE4 项目(不含源码)它绕过了 UE4 编译与 CARLA 项目编译,直接提供可执行文件。因此,其启动速度极快(./CarlaUE4.sh3 秒内响应),但代价是丧失了所有定制化能力。
5.2 快速启动包的三大适用场景与三大禁用场景
✅ 适用场景:
- 教学演示:向学生展示 CARLA 基础功能,无需解释构建流程。
- CI/CD 测试:在 Docker 容器中运行自动化测试,要求环境纯净且启动迅速。
- 硬件验证:在新购 GPU 服务器上快速验证 NVIDIA 驱动与 CARLA 兼容性。
❌ 禁用场景:
- 需要修改 CARLA 源码:如添加自定义传感器、修改交通规则逻辑。快速包不含
Source/目录,无法编译。 - 需要调试 UE4 引擎:如分析物理碰撞异常、优化渲染性能。快速包提供的是
CarlaUE4二进制,无调试符号。 - 生产环境部署:快速包中的
CarlaUE4.sh硬编码了绝对路径(如/opt/carla/Unreal/CarlaUE4/Binaries/Linux/CarlaUE4),一旦移动目录即失效,且无法通过make package生成自定义发行版。
实操心得:我在一个自动驾驶算法团队中推行“双轨制”:研究组使用快速启动包进行算法迭代(
pip install carla+./CarlaUE4.sh),工程组则坚持源码构建(make CarlaUE4+make PythonAPI)以支持车载域控制器的 ARM64 交叉编译。二者共存,互不干扰。
5.3 快速启动包的安装与安全加固
快速启动包虽便捷,但默认配置存在安全隐患,需手动加固。
# 1. 下载并解压(以 Linux 为例) wget https://carla-releases.s3.eu-west-3.amazonaws.com/CarlaSimulator/0.9.15/CARLA_0.9.15.tar.gz tar -xzf CARLA_0.9.15.tar.gz cd CARLA_0.9.15 # 2. 修改启动脚本,禁用默认端口暴露(安全第一) sed -i 's/2000/20001/g' CarlaUE4.sh # 此操作将服务端口从 2000 改为 20001,避免与本地其他服务冲突 # 3. 设置 PythonPATH(仅对当前会话) export PYTHONPATH=$PWD/PythonAPI/carla/dist/carla-0.9.15-py38-linux-x86_