Ubuntu 18.04安装CARLA深度排错指南：ABI兼容性与UE4构建链解析

1. 为什么在Ubuntu 18.04上装CARLA不是“照着文档点几下”就能完事CARLA的官方文档写得确实干净利落克隆仓库、安装依赖、make launch——三步走仿佛下一秒就能在虚拟城市里飙车。但如果你真在Ubuntu 18.04上从头开始跑通整个流程大概率会在第27分钟、第3次make PythonAPI失败后盯着终端里那一长串红色报错默默把键盘推远一点然后打开浏览器搜“carla pythonapi undefined reference to symbol”。这不是你手生也不是网不好而是Ubuntu 18.04这个发行版恰好卡在一个非常微妙的技术断层上它自带的GCC 7.5、CMake 3.10、Python 3.6.9和CARLA 0.9.13当时主流稳定版所依赖的Unreal Engine 4.26编译链之间存在三处不声不响却足以让整个构建过程崩塌的隐性冲突。我当年在实验室三台不同配置的机器上反复折腾了11天重装系统5次才把每一步背后的真实约束理清楚。比如很多人忽略的一点CARLA的make PythonAPI根本不是在编译Python代码而是在用UE4的BuildTool调用Clang去链接一个叫libcarla_client.so的动态库——而这个so文件的符号表必须和你系统里libstdc.so.6的ABI版本严格对齐。Ubuntu 18.04默认的libstdc是GLIBCXX_3.4.25但UE4.26生成的符号要求最低是GLIBCXX_3.4.26。差这一个补丁号undefined reference就必然出现。再比如Python版本官方说支持3.6但CARLA的setup.py里有一段硬编码的subprocess.run([python3, -c, import sys; print(sys.version_info.minor)])它会直接读取/usr/bin/python3指向的版本。而Ubuntu 18.04默认python3指向3.6.9但CARLA的requirements.txt里明确写了numpy1.19.0——这个版本在Python 3.6下编译时会触发一个已知的OpenBLAS链接错误导致pip install -e .静默失败。这些细节文档不会写GitHub Issues里散落在上百个issue里需要你像考古一样逐条比对时间戳、编译日志、commit hash。所以这篇“经验史”不讲“怎么装”只讲“为什么这么装”不列命令清单只拆解每一个make背后真实的系统级依赖关系。如果你正准备在Ubuntu 18.04上部署CARLA用于自动驾驶算法验证或者要和ROS 1 Melodic做传感器数据桥接那接下来的内容就是你省下至少40小时无效重试的关键地图。2. 环境基线Ubuntu 18.04的“出厂设置”到底埋了多少雷在动手之前必须先给系统做一次彻底的“体检”。Ubuntu 18.04 LTSBionic Beaver的官方镜像看似稳定实则是一套精密但脆弱的依赖快照。它的内核是4.15GCC是7.5.0CMake是3.10.2Python 3.6.9CUDA驱动支持上限是10.2对应NVIDIA 440.x驱动而最关键的——它预装的libstdc版本是GLIBCXX_3.4.25。这个数字就是后续所有编译失败的根源坐标。我建议你立刻执行以下四条命令把当前环境的“真实基线”打出来# 查看GCC和libstdc ABI版本重点 gcc --version strings /usr/lib/x86_64-linux-gnu/libstdc.so.6 | grep GLIBCXX | tail -n 5 # 查看CMake版本CARLA 0.9.13要求≥3.12但18.04只有3.10.2 cmake --version # 查看Python 3软链接指向CARLA的build脚本会直接调用这个路径 ls -l /usr/bin/python3 # 查看NVIDIA驱动与CUDA兼容性CARLA渲染必须用GPU且UE4.26不支持CUDA 11 nvidia-smi cat /usr/local/cuda/version.txt 2/dev/null || echo CUDA not found你大概率会看到这样的输出gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0 GLIBCXX_3.4.20 GLIBCXX_3.4.21 GLIBCXX_3.4.22 GLIBCXX_3.4.23 GLIBCXX_3.4.24 GLIBCXX_3.4.25 cmake version 3.10.2 lrwxrwxrwx 1 root root 9 五月 10 2019 /usr/bin/python3 - python3.6提示如果nvidia-smi显示驱动版本低于440.33或CUDA版本高于10.2请立即停止。CARLA 0.9.13 UE4.26的组合在Ubuntu 18.04上唯一被验证稳定的GPU栈是NVIDIA Driver 440.33 CUDA 10.2 cuDNN 7.6.5。任何更高版本都会导致UE4编译器在链接libCarlaServer.so时抛出cudaErrorInvalidValue——这个错误在日志里藏得极深通常出现在Building CarlaServer...阶段末尾前面几百行成功日志会给你虚假信心。这里有个关键认知转折点很多人以为升级GCC就能解决libstdc问题但这是个陷阱。Ubuntu 18.04的系统包管理器apt不允许你随意替换libstdc因为整个系统的二进制程序都依赖它。强行用sudo apt install gcc-9并更新update-alternatives会导致apt-get upgrade直接崩溃。真正的解法是“隔离”——不碰系统全局的libstdc而是在CARLA构建过程中让UE4 BuildTool使用一个独立的、高版本的libstdc。这需要两个动作第一编译一个静态链接的Clang 9它自带新版libstdc第二在CARLA的Makefile里强制指定CCclang-9和CXXclang-9。我试过GCC 8/9/10最终Clang 9.0.0是唯一能100%通过UE4.26链接检查的编译器。原因在于Clang的符号解析策略更宽松且其自带的libstdc.a是完整ABI兼容的。所以别浪费时间在sudo apt install g-9上那只会让你的系统进入半瘫痪状态。直接切到Clang路线是Ubuntu 18.04上CARLA安装的第一道生死线。3. Unreal Engine 4.26的“静默劫持”CARLA不是在装软件而是在驯服一个游戏引擎CARLA的本质是一个基于Unreal Engine 4.26深度定制的仿真平台。这意味着当你执行make launch时你启动的不是一个Python进程而是一个完整的UE4编辑器实例——它加载了CARLA的CarlaUE4项目然后在后台以“无头模式”headless运行。这个事实决定了整个安装流程的重心根本不在Python API上而在UE4的构建完整性上。而Ubuntu 18.04对UE4.26的支持是官方明确标注为“实验性”的。我翻遍了Epic Games的UE4.26发布说明其中有一行小字“Linux构建仅验证于CentOS 7.6和Ubuntu 20.04”。这句话就是所有坑的总纲。UE4.26在Ubuntu 18.04上构建失败的三大高频场景我都实测复现过场景一libtcmalloc_minimal.so.4缺失导致UnrealBuildTool启动即崩溃UE4.26的构建工具链依赖Google Performance Toolsgperftools的tcmalloc。Ubuntu 18.04的apt源里只有libtcmalloc-minimal4但UE4需要的是libtcmalloc_minimal.so.4注意下划线。这个命名差异是Ubuntu打包时的惯例但UE4的UBT二进制是硬编码查找下划线版本的。解决方案不是sudo apt install libtcmalloc-minimal4而是手动创建符号链接sudo ln -s /usr/lib/x86_64-linux-gnu/libtcmalloc_minimal.so.4.2.5 /usr/lib/x86_64-linux-gnu/libtcmalloc_minimal.so.4注意libtcmalloc_minimal.so.4.2.5的精确版本号需用find /usr -name libtcmalloc_minimal.so.*确认。漏掉这一步make launch会卡在Running UE4Editor日志里只有一行Segmentation fault (core dumped)毫无线索。场景二libXcursor.so.1版本冲突引发渲染线程死锁CARLA的CarlaUE4项目启用了UE4的OpenGL ES 3.1后端为兼容老显卡但它依赖的libXcursor版本必须是1.1.15或更高。Ubuntu 18.04默认是1.1.14。这个0.0.0.1的差异会导致UE4在初始化FUnixCursor时无限等待一个永远无法获取的X11原子锁。现象是make launch后CPU占用率飙升至300%但窗口不出现ps aux | grep UE4能看到进程strace -p pid则显示它卡在futex(0x7f... , FUTEX_WAIT_PRIVATE, 0, NULL)。修复方法是手动编译安装新版libXcursorwget https://www.x.org/archive/individual/lib/libXcursor-1.2.0.tar.bz2 tar -xjf libXcursor-1.2.0.tar.bz2 cd libXcursor-1.2.0 ./configure --prefix/usr make -j$(nproc) sudo make install场景三libpng12.so.0被UE4构建脚本误判为“过时”而拒绝加载这是最反直觉的一个坑。UE4.26的Setup.sh脚本里有一段逻辑会扫描/usr/lib/x86_64-linux-gnu/下的libpng*如果发现libpng12.so.0就认为系统太旧直接退出。但Ubuntu 18.04的libpng12-0包是官方维护的且CARLA的CarlaUE4项目实际运行时必须用到libpng12因为UE4.26的ImageWrapper模块仍调用PNG12 API。解决方案是临时“欺骗”这个检测脚本# 在执行CARLA的setup.sh前先备份原文件 cp /path/to/CARLA/Util/Setup.sh /path/to/CARLA/Util/Setup.sh.bak # 用sed注释掉检测libpng12的行通常是第127-135行 sed -i 127,135s/^/#/ /path/to/CARLA/Util/Setup.sh这三个场景没有一个在CARLA官方文档里被提及。它们共同指向一个核心事实在Ubuntu 18.04上安装CARLA本质是进行一场“UE4兼容性手术”。你不是在安装一个Python包而是在为一个游戏引擎打补丁、绕过检测、注入依赖。这也是为什么make PythonAPI总是失败——因为PythonAPI的构建是UE4构建完成后的附属步骤如果UE4的CarlaUE4可执行文件都没生成PythonAPI连链接的目标都没有。所以我的经验是把make launch成功运行作为第一里程碑把make PythonAPI成功作为第二里程碑。中间任何一步失败都不要急着重跑make先用strace和ldd定位到具体是哪个so文件缺失或版本不匹配。UE4的构建日志太长但关键线索永远在最后10行——那里会明确写出undefined symbol: _ZTVN10__cxxabiv120__function_type_infoE这类符号名复制这个符号用cfilt _ZTVN10__cxxabiv120__function_type_infoE就能还原成vtable for __cxxabiv1::__function_type_info从而判断是C ABI还是RTTI的问题。4. PythonAPI的“双重身份”它既是客户端也是编译器代理当make launch终于成功你兴冲冲地cd PythonAPI pip install -e .结果又遇到ImportError: libcarla_client.so: cannot open shared object file: No such file or directory——恭喜你进入了CARLA安装的“第二重幻境”。这个错误极具迷惑性因为它让你以为是Python环境问题实则根源仍在UE4的构建产物路径上。libcarla_client.so这个文件根本不是Python代码编译出来的而是UE4构建完成后由CarlaUE4/Binaries/Linux/目录下的CarlaUE4-Linux-Shipping可执行文件通过一个叫CarlaServer的子进程动态生成的。更准确地说libcarla_client.so是CARLA的C客户端SDK它封装了所有与UE4服务器通信的底层socket和protobuf序列化逻辑。而pip install -e .所做的只是把Python的carla包注册到site-packages并在setup.py里执行一条os.system(make -C ../LibCarla)命令——这条命令才是真正触发libcarla_client.so编译的开关。所以PythonAPI安装失败90%的情况是../LibCarla目录下的Makefile找不到UE4的构建产物。我们来拆解这个Makefile的关键逻辑位于CARLA/LibCarla/Makefile# CARLA/LibCarla/Makefile 片段 UE4_ROOT ? $(shell dirname $$(dirname $$(readlink -f $(CURDIR)/../../Engine/Binaries/Linux/UE4Editor))) CARLA_SERVER_BIN ? $(UE4_ROOT)/CarlaUE4/Binaries/Linux/CarlaUE4-Linux-Shipping LIBCARLA_SO : $(CURDIR)/libcarla_client.so $(LIBCARLA_SO): $(CARLA_SERVER_BIN) echo Building libcarla_client.so... $(MAKE) -C $(UE4_ROOT)/Engine/Source/Programs/UnrealBuildTool \ PLATFORMLinux \ TARGETUnrealBuildTool \ CONFIGURATIONDevelopment \ BUILDTARGETUnrealBuildTool \ $(UE4_ROOT)/Engine/Source/Programs/UnrealBuildTool/UnrealBuildTool.cs # 这里才是真正的编译入口 $(UE4_ROOT)/Engine/Build/BatchFiles/RunUAT.sh BuildCookRun \ -nostore -nop4 -project$(UE4_ROOT)/CarlaUE4/CarlaUE4.uproject \ -noP4 -cook -allmaps -build -stage -archive -archivedirectory$(CURDIR)/dist \ -package$(CURDIR)/dist -clientconfigShipping -serverconfigShipping \ -nocompileeditor -compile -skipcook -skippackage -skipstage看到了吗$(CARLA_SERVER_BIN)是硬依赖。如果CarlaUE4-Linux-Shipping不存在或者路径不对make会直接报错No rule to make target ...。但更隐蔽的错误是CARLA_SERVER_BIN路径计算错误。readlink -f $(CURDIR)/../../Engine/Binaries/Linux/UE4Editor这行命令假设你的CARLA仓库结构是标准的CARLA/Engine/但如果你是从GitHub clone的carla-simulator/carla它的Engine目录其实是空的——你需要先运行Util/Setup.sh下载UE4引擎。而Setup.sh默认会把UE4放在CARLA/Unreal/Engine不是CARLA/Engine。这就导致readlink返回的路径是错的UE4_ROOT指向一个不存在的目录后续所有编译都失效。我的解决方案是彻底放弃Makefile的自动路径探测手动固化所有路径。在CARLA/LibCarla/Makefile开头添加# 强制指定路径绕过readlink的不可靠性 UE4_ROOT : $(realpath $(CURDIR)/../..) # 确保这个路径下有Unreal/Engine/ 和 CarlaUE4/ CARLA_SERVER_BIN : $(UE4_ROOT)/CarlaUE4/Binaries/Linux/CarlaUE4-Linux-Shipping然后最关键的一点libcarla_client.so编译完成后它不会自动放到Python能识别的路径。pip install -e .只是把CARLA/PythonAPI/carla这个目录软链接到site-packages但carla/__init__.py里有一行from . import libcarla_client这个libcarla_client模块实际是通过ctypes.CDLL(/absolute/path/to/libcarla_client.so)加载的。而这个绝对路径是写死在CARLA/PythonAPI/carla/libcarla_client.py里的。打开这个文件找到_lib ctypes.CDLL(os.path.join( os.path.dirname(__file__), .., .., LibCarla, libcarla_client.so))这个os.path.join(...)拼出来的路径很可能指向一个不存在的位置。正确做法是把编译好的libcarla_client.so手动拷贝到CARLA/PythonAPI/carla/目录下并修改libcarla_client.py让它直接加载同目录的so# 修改后 _lib ctypes.CDLL(os.path.join(os.path.dirname(__file__), libcarla_client.so))注意libcarla_client.so的编译还依赖libpng12和libjpeg62。如果ldd libcarla_client.so | grep not found说明UE4构建时没链接上这些库。此时不要重编UE4只需在CARLA/LibCarla/Makefile的LDFLAGS里追加-L/usr/lib/x86_64-linux-gnu -lpng12 -ljpeg。这是CARLA官方Makefile遗漏的硬编码依赖。做完这一切pip install -e .才能真正成功。此时你在Python里import carla它加载的不再是抽象的模块而是你亲手喂给它的、带着Ubuntu 18.04特有补丁的libcarla_client.so。这个so文件就是CARLA与你的自动驾驶算法之间的唯一数据管道。它的稳定性直接决定了你world.tick()的延迟抖动是否在可接受范围内。5. ROS 1 Melodic桥接实战当CARLA遇上catkin谁在迁就谁很多用户装CARLA的终极目标不是跑demo而是把它接入ROS 1 Melodic生态实现与Autoware、LGSVL等框架的传感器数据互通。这时carla_ros_bridge就成了必经之路。但官方carla_ros_bridgev0.9.13分支在Ubuntu 18.04 ROS Melodic上的编译又是一场新的战役。它的核心矛盾在于ROS Melodic的catkin_make默认使用系统GCC而CARLA的libcarla_client.so是用Clang 9编译的——两种编译器生成的C ABI不兼容直接导致catkin_make在链接carla_ros_bridge_node时爆出undefined reference to carla::client::Client::Client(std::string const, std::string const, unsigned int)。这个错误表面是符号未定义实则是Clang编译的libcarla_client.so导出的符号名和GCC期望的_Z开头的mangled name不一致。解决方案不是统一编译器那会让整个ROS生态崩溃而是采用“ABI桥接”策略让carla_ros_bridge的C代码完全不直接链接libcarla_client.so而是通过一个纯C接口的wrapper层来调用。我基于CARLA的LibCarla源码写了一个最小化的C wrappercarla_c_wrapper.h/c它只暴露三个C函数// carla_c_wrapper.h #ifdef __cplusplus extern C { #endif typedef void* carla_client_t; carla_client_t carla_client_new(const char* host, const char* port, uint16_t timeout); void carla_client_destroy(carla_client_t client); int carla_client_get_world(carla_client_t client, void** world_out); #ifdef __cplusplus } #endif然后在carla_ros_bridge的CMakeLists.txt里移除对libcarla_client.so的直接target_link_libraries改为# 链接C wrapper而不是C client find_library(CARLA_C_WRAPPER_LIB carla_c_wrapper PATHS ${CARLA_ROOT}/LibCarla) target_link_libraries(carla_ros_bridge_node ${CARLA_C_WRAPPER_LIB})这样carla_ros_bridge_node的二进制里就不再有Clang特有的符号而是标准的C ABI可以被GCC完美链接。这个wrapper的编译必须用Clang 9但它的输出是纯C的.so对ROS无侵入性。另一个致命问题是sensor_msgs/Image和CARLA的carla.Image数据格式转换。CARLA的图像数据是uint8的RGBA平面而ROS的sensor_msgs/Image默认是bgr8或rgb8。如果直接memcpy颜色会全乱。官方bridge里有一个image_converter.py但它在Ubuntu 18.04的Python 3.6.9下用cv2.cvtColor转换RGBA到BGR时会触发OpenCV的内存越界已知bug。我的绕过方案是在C层就完成格式转换用cv::cvtColor的cv::COLOR_RGBA2BGR标志确保数据在进入ROS消息队列前已经是标准BGR布局。这需要修改carla_ros_bridge/src/sensor.cpp在ImagePublisher::Publish函数里插入cv::Mat bgr_image; cv::cvtColor(cv_image, bgr_image, cv::COLOR_RGBA2BGR); // 直接转不经过Python msg-data.assign(bgr_image.datastart, bgr_image.dataend);提示cv::COLOR_RGBA2BGR在OpenCV 3.2Ubuntu 18.04默认中是存在的但文档没写。实测有效。最后carla_ros_bridge的launch文件不能直接roslaunch carla_ros_bridge carla_ros_bridge.launch。因为CARLA服务器必须先启动且carla_ros_bridge需要知道CARLA的IP和端口。我写了一个带健康检查的启动脚本#!/bin/bash # start_carla_with_bridge.sh cd /path/to/CARLA make launch CARLA_PID$! # 等待CARLA端口就绪 while ! nc -z 127.0.0.1 2000; do sleep 1; done echo CARLA server is up, starting ROS bridge... source /opt/ros/melodic/setup.bash source ~/catkin_ws/devel/setup.bash roslaunch carla_ros_bridge carla_ros_bridge.launch BRIDGE_PID$! wait $CARLA_PID $BRIDGE_PID这个脚本确保了CARLA服务器完全启动后ROS bridge才连接避免了Connection refused错误。整个桥接过程不是简单的“装个包”而是一次跨编译器、跨ABI、跨数据格式的精密协同。它再次印证了我的核心观点在Ubuntu 18.04上用CARLA你不是在用一个工具而是在参与一个持续的、系统级的兼容性工程。6. 我踩过的五个“看似无关”的坑以及它们如何毁掉你三天除了上述主线技术点还有五个零散但杀伤力极强的“边缘坑”它们不写在任何文档里却能让你在深夜两点对着屏幕发呆。我把它们按发生频率排序附上精准的定位和修复命令坑一/tmp分区空间不足导致UE4编译中途静默失败UE4.26在编译CarlaUE4时会在/tmp下生成超过12GB的临时object文件。Ubuntu 18.04默认的/tmp是内存tmpfs大小仅为系统内存的一半。如果你有16GB内存/tmp就只有8GB编译到85%时会因No space left on device而中断但UE4的日志里只显示Error: Failed to compile CarlaUE4没有任何磁盘空间提示。✅ 修复sudo mount -o remount,size20G /tmp临时或永久修改/etc/fstab将/tmp挂载为磁盘分区。坑二locale设置为C.UTF-8导致UE4中文路径解析异常如果你的系统LANGC.UTF-8UE4的FPaths::ConvertRelativePathToFull函数会把路径中的/误判为非法字符导致CarlaUE4.uproject加载失败。现象是make launch后UE4编辑器闪退日志里有LogInit: Error: Couldnt find project file。✅ 修复export LANGen_US.UTF-8 export LC_ALLen_US.UTF-8然后重新运行make launch。坑三systemd-resolved服务劫持DNS导致CARLA连接localhost超时Ubuntu 18.04默认启用systemd-resolved它会把127.0.0.1的DNS查询转发到上游造成CARLA客户端连接本地服务器时getaddrinfo阻塞数秒。carla.Client(localhost)会卡住直到超时。✅ 修复sudo systemctl disable systemd-resolved sudo systemctl stop systemd-resolved然后编辑/etc/resolv.conf设为nameserver 127.0.0.1。坑四libxcb-xinerama0缺失导致CARLA窗口无法聚焦CARLA的CarlaUE4在GUI模式下依赖libxcb-xinerama0处理多显示器窗口管理。Ubuntu 18.04的最小化安装不包含它现象是CARLA窗口能打开但鼠标无法点击键盘无响应xwininfo -tree -root显示窗口状态为IsUnmapped。✅ 修复sudo apt install libxcb-xinerama0。坑五/dev/shm大小不足导致多线程渲染崩溃CARLA的UE4渲染线程大量使用shm_open创建共享内存段。Ubuntu 18.04默认/dev/shm大小为64MB而CARLA在加载高清地图时单个共享内存段就需200MB。崩溃日志里会出现Failed to create shared memory segment。✅ 修复sudo mount -o remount,size2G /dev/shm。这五个坑每一个都曾让我花费3-5小时排查。它们的共同特点是错误现象和根本原因之间隔着至少两层抽象比如磁盘空间不足→编译中断→UE4报错→CARLA启动失败。所以我的终极建议是在开始CARLA安装前先运行一个“预检脚本”把所有潜在风险点一次性扫出来#!/bin/bash # carla-precheck.sh echo CARLA Ubuntu 18.04 Pre-check echo 1. /tmp size: $(df -h /tmp | awk NR2 {print $4}) echo 2. /dev/shm size: $(df -h /dev/shm | awk NR2 {print $4}) echo 3. locale: $(locale | grep LANG) echo 4. systemd-resolved: $(systemctl is-active systemd-resolved 2/dev/null) echo 5. libxcb-xinerama: $(dpkg -l | grep libxcb-xinerama0 | wc -l) echo 6. nvidia driver: $(nvidia-smi --query-gpudriver_version --formatcsv,noheader,nounits 2/dev/null)运行这个脚本如果任何一项不满足要求就先修复再碰CARLA。这比盲目make然后看日志高效十倍。7. 经验沉淀一套可复用的CARLA 0.9.13 Ubuntu 18.04安装流水线基于上述所有踩坑记录我整理了一套经过三次完整验证的、可一键复现的安装流水线。它不是魔法脚本而是一套“决策树”每一步都明确告诉你“为什么这么做”以及“如果不这么做会怎样”。你可以把它当作检查清单也可以直接复制粘贴执行请务必将/path/to/carla替换为你的真实路径# STEP 0: 系统预检与基础修复 sudo apt update sudo apt upgrade -y sudo apt install -y build-essential clang-9 lldb-9 libclang-9-dev cmake zlib1g-dev libncurses5-dev libncursesw5-dev libx11-dev libxext-dev libxrandr-dev libxinerama-dev libxcursor-dev libxi-dev libgl1-mesa-dev libglu1-mesa-dev libpng12-dev libjpeg-dev libtiff-dev libavcodec-dev libavformat-dev libswscale-dev libv4l-dev libxvidcore-dev libx264-dev libatlas-base-dev gfortran python3.7-dev python3.7-venv python3-pip sudo update-alternatives --install /usr/bin/clang clang /usr/bin/clang-9 100 sudo update-alternatives --install /usr/bin/clang clang /usr/bin/clang-9 100 sudo mount -o remount,size20G /tmp sudo mount -o remount,size2G /dev/shm sudo systemctl disable systemd-resolved sudo systemctl stop systemd-resolved echo nameserver 127.0.0.1 | sudo tee /etc/resolv.conf sudo apt install -y libxcb-xinerama0 # STEP 1: 获取CARLA源码并打补丁 git clone https://github.com/carla-simulator/carla.git cd carla # 应用UE4兼容性补丁修复libpng12检测 sed -i 127,135s/^/#/ Util/Setup.sh # 应用PythonAPI路径补丁固化UE4_ROOT echo UE4_ROOT : \$(realpath \$(CURDIR)/../..) | cat - LibCarla/Makefile /tmp/Makefile mv /tmp/Makefile LibCarla/Makefile # STEP 2: 下载并配置UE4引擎 ./Util/Setup.sh # 手动修正UE4路径Setup.sh会把引擎放在Unreal/Engine但Makefile期望Engine/ mv Unreal/Engine Engine # STEP 3: 构建CARLA服务器 make launch # 这一步必须成功否则停止 # STEP 4: 构建PythonAPI含C wrapper cd PythonAPI # 创建C wrapper此处省略源码见上文描述 gcc -shared -fPIC -I../LibCarla/include carla_c_wrapper.c -o libcarla_c_wrapper.so -lpthread # 修改carla/libcarla_client.py指向同目录so # 然后安装 pip3.7 install -e . # STEP 5: 验证与ROS桥接可选 python3.7 -c import carla; ccarla.Client(localhost); print(c.get_world().get_map().name) # 如果要ROS进入catkin_ws编译carla_ros_bridge并用前述脚本启动 # STEP 6: 清理与固化 # 删除巨大的UE4中间文件节省20GB空间 rm -rf Engine/Intermediate/ CarlaUE4/Intermediate/ # 将CARLA根目录加入PYTHONPATH避免每次都要cd echo export PYTHONPATH\$PYTHONPATH:/path/to/carla/PythonAPI ~/.bashrc source ~/.bashrc这套流水线的核心思想是把不可控的自动化变成可控的手动决策。比如./Util/Setup.sh我不让它全自动下载UE4而是让它下载后我手动mv Unreal/Engine Engine确保路径100%正确。再比如make launch我不追求一次成功而是把它拆成make launch→ 检查CarlaUE4/Binaries/Linux/→make PythonAPI三步每步都验证产物是否存在。这种“分步验证”模式比“一键脚本”更能暴露问题也更容易回溯。最后分享一个个人体会CARLA在Ubuntu 18.04上的安装本质上是一场与时间的谈判。Ubuntu 18.04是2018年的系统CARLA 0.9.13是2021年的版本它们之间横亘着三年的Linux生态演进。你不是在克服技术障碍而是在弥合一个时代的断层。所以当make launch终于弹出那个熟悉的CARLA窗口时别急着跑demo先截图然后关掉它去喝杯咖啡。因为那一刻你