企业官网建设流程全解析

刚在同事那台N卡机器上从头把 Ubuntu 18.04 + Autoware 1.14 GPU版 环境重新过了一遍，差不多折腾了一个下午才把感知Demo跑起来。网上写安装教程的人不少，但大部分都断在最关键的一步，前面说“依赖全装好了”，后面直接“等编译完就能开跑”，中间的驱动、CUDA、ROS版本匹配没人讲透。这篇就把这个组合的环境配置流程完整梳理一遍，覆盖版本怎么选、NVIDIA驱动和CUDA怎么装、ROS Melodic怎么搭、Autoware源码怎么编译、Demo怎么验证，再把我踩过的报错和排查思路放出来。适合刚接触Autoware但不想在环境上浪费太多时间的开发者直接参考。

1. 安装前的整体设计与版本选型

1.1 为什么整套环境要锁定在老版本

Autoware 1.14 是很多算法包还停留在早期形态时的那一代版本，官方说明和绝大多数公开资料都默认它在 Ubuntu 18.04 上配合 ROS Melodic 使用。这个锁定关系不是随便拍的。ROS的发行版和Ubuntu的版本严格对应，Melodic对应18.04，换成20.04就得用ROS Noetic，而Autoware 1.14源码里的很多构建脚本和消息定义都是从Melodic时代遗留下来的，直接放到新版本环境里编译，通常会在一些不起眼的依赖上出问题。

有人会问，为什么不干脆装新版Autoware？Autoware后续版本架构改动很大，要重新学新的模块组织方式，而且GPU相关节点的编译方式也变了。如果目标是跑一个老项目，或者复现早期自动驾驶感知流程，1.14这套组合反而是最快速、最不容易出错的选择。我这里所说的“不容易出错”，指的是在已有版本匹配的前提下，遇到问题更容易搜到同款解决方案，而不是说它完全不会踩坑。

1.2 版本对应关系与硬件确认

先列一份我实测可用的版本对应表，避免后面每一步都在试错：

NVIDIA驱动版本不需要刻意追新，我的原则是跟着CUDA要求走。CUDA 10.2 对驱动的最低要求是440版本左右，实际装470或者450这类驱动都能用。装好之后一定要先确认nvidia-smi能正常输出GPU信息，这一步不做，后面CUDA和Autoware编译都无从谈起。

硬件方面，内存至少16GB，因为Autoware编译时并行度上来了很容易吃满内存，我见过8GB机器在编译阶段直接卡死，最后加了8GB交换空间才勉强跑完。显存建议至少4GB，跑点云匹配和感知节点的时候，显存不够会频繁触发显示驱动重置。磁盘剩余空间要预留40GB以上，源码、中间产物加上数据集，增长比你预想得快。

1.3 系统安装方式的建议

如果机器上已经是干净的Ubuntu 18.04，这一步跳过。如果是双系统，建议提前确认引导方式，Autoware涉及大量内核模块操作，双系统下驱动冲突的排查成本很高。我的建议是单独找一块硬盘装，或者在原有系统上处理好分区以后再来。

装好系统之后，先执行sudo apt update && sudo apt upgrade，然后立刻确认内核版本。Autoware编译对内核没有苛刻要求，但NVIDIA驱动安装时如果内核和驱动版本差太多，dkms会编译失败，所以尽量保持系统刚装完的状态，不要急着升级到完全不熟悉的内核。

2. 基础环境搭建：驱动、CUDA与ROS Melodic

2.1 NVIDIA驱动安装与nouveau处理

这块是GPU版环境最容易翻车的起点。默认Ubuntu的桌面环境会使用开源的nouveau驱动，NVIDIA官方驱动和它不能共存，不处理掉，后面装驱动就会碰到各种黑屏和登录循环。

先把内核模块列入黑名单。编辑/etc/modprobe.d/blacklist-nouveau.conf：

sudo vim /etc/modprobe.d/blacklist-nouveau.conf

写入两行：

blacklist nouveau options nouveau modeset=0

然后更新initramfs并重启：

sudo update-initramfs -u sudo reboot

重启之后先用lsmod | grep nouveau确认模块已经不再加载。如果还有输出，说明黑名单没生效，仔细核对文件路径和拼写。这个环节很多人漏掉，后面驱动装上以后一编译CUDA就花屏，其实就是nouveau在捣乱。

确认没问题后，可以用系统自带的工具查看推荐的驱动包名：

ubuntu-drivers devices

也可以直接指定版本安装：

sudo apt update sudo apt install nvidia-driver-470

装完重启，依次执行nvidia-smi和nvidia-settings。只要能看到显卡型号和显存信息，驱动部分就算过了。此时不要急着继续，我建议让机器静置一会，让驱动真正初始化一遍，再做下面的步骤。

2.2 CUDA Toolkit与cuDNN安装

驱动装好以后，CUDA Toolkit就好办多了。我选的是CUDA 10.2，因为Autoware 1.14编译时大量节点是通过CMake的find_package(CUDA)去探测的，10.2在很多老项目里兼容性做得好。

下载的时候选择runfile方式，不要用deb方式，runfile可以自定义安装路径，后续切换版本也方便。安装命令大致是：

sudo sh cuda_10.2*.run --toolkit --silent --override

这里--toolkit只安装工具包，不覆盖驱动，避免把刚装好的驱动又改掉。安装完成后，在/usr/local下会出现cuda-10.2目录，同时可能保留cuda这个软链接。如果软链接不是指向10.2，就手动改一下：

sudo ln -sf /usr/local/cuda-10.2 /usr/local/cuda

环境变量是后续所有编译的关键，写入~/.bashrc：

export PATH=/usr/local/cuda/bin:$PATH export LD_LIBRARY_PATH=/usr/local/cuda/lib64:$LD_LIBRARY_PATH

然后执行source ~/.bashrc，用nvcc -V验证版本。

cuDNN这里有个常见误区：直接去下载最新版。Autoware 1.14编译和运行时的库依赖是CUDA 10.x时代的，用太新的cuDNN反而会在运行时报符号找不到。我用的是7.6.5，解压后把include、lib64下的内容拷贝到CUDA目录，或者用deb包装上都可以。装完以后可以在/usr/local/cuda/lib64下看到libcudnn.so.7这类文件。

2.3 TensorRT的安装与定位

TensorRT 7.x 对Autoware里的vision_ssd_detect、vision_yolo3_detect等推理节点很重要，这些节点编译时会尝试寻找TensorRT的头文件和库文件。如果找不到，部分节点会被跳过，虽然整体能编译过，但GPU推理能力就废了一半。

安装TensorRT 7.x可以直接用官方提供的deb包，装完以后路径一般在/usr/lib/x86_64-linux-gnu/下。为了让CMake顺利找到，可以把路径加进LD_LIBRARY_PATH，也可以设置TensorRT_ROOT环境变量。我的做法是把这几个库路径全部写进~/.bashrc，一劳永逸。

如果只是想先跑通不带深度学习检测的感知Demo，TensorRT可以后装，但后面一旦需要启用检测节点，还是得回来补这一步。到那时再重编Autoware，编译时间又得重来一遍，倒不如一开始就装上。

2.4 ROS Melodic安装与依赖初始化

ROS的部分反而是整个环境里最不容易出问题的。先添加ROS软件源：

sudo sh -c 'echo "deb http://packages.ros.org/ros/ubuntu $(lsb_release -sc) main" > /etc/apt/sources.list.d/ros-latest.list'

然后配置密钥，更新索引，安装桌面完整版：

sudo apt update sudo apt install ros-melodic-desktop-full

这里我给的是通常意义上的安装步骤，具体源地址以你所在网络能正常访问的为准。装完之后初始化rosdep：

sudo rosdep init rosdep update

这个命令偶尔会提示超时或者拉取失败，我的处理方式是等一会儿再执行一次，或者检查网络连接是否正常，不要反复强制重试，容易把缓存弄乱。rosdep的作用是解析源码包的依赖关系，这一步不跑，后面Autoware编译时会遇到大量Missing依赖。

2.5 基础依赖库补齐

ROS桌面完整版会带上OpenCV、PCL、Eigen这些常用库，但Autoware还需要一些额外的系统库，直接一次性装好：

sudo apt install nlohmann-json3-dev libyaml-cpp-dev libboost-all-dev libpcl-dev python3-catkin-tools python3-osrf-pycommon ros-melodic-velodyne

nlohmann-json3-dev在Autoware的几个感知节点中是硬依赖，Ubuntu 18.04默认源里的版本够用。如果源里没有这个包名，可以试试nlohmann-json-dev。libyaml-cpp-dev处理参数文件解析，libpcl-dev是点云库。用catkin build作为编译工具，所以要装python3-catkin-tools。ros-melodic-velodyne后面跑雷达Demo时会用到。

装完后可以顺手检查一下dpkg -L ros-melodic-desktop-full | grep pcl，确认核心库已经就位。基础环境到这里就算封闭了，下一步进入Autoware本体。

3. Autoware 1.14源码编译

3.1 源码拉取与分支选择

Autoware 1.14的源码建议从官方Git仓库拉取，拉取时指定tag或者分支。我用的命令长这样：

mkdir -p ~/autoware cd ~/autoware git clone <官方仓库地址> autoware cd autoware git checkout 1.14

之所以强调分支，是因为master上的代码可能已经混入了新版本架构的部分，直接编译大概率会碰到版本不一致。用tag拉下来，至少源码是官方标记过的版本，和网上教程对得上。我的建议是，把<官方仓库地址>替换为实际能访问到的官方仓库地址，北方地区有的网络访问比较慢，可以换个时间段拉取。

拉取完成后，先看目录结构。ros子目录才是ROS工作区，后面所有依赖安装和编译都在这个目录里进行。如果发现源码拉取不完整，比如某些子模块是空的，可以先执行git submodule update --init --recursive。

3.2 rosdep自动安装依赖

进入ros目录后，用rosdep一次性解析并安装全部ROS依赖：

cd ~/autoware/autoware/ros rosdep install -y --from-paths src --ignore-src --rosdistro melodic

这一步会输出一大堆apt-get install的包名，过程中如果出现unable to locate package的报错，说明前面基础依赖没补全。最稳妥的方式是安装完了再跑一遍rosdep，因为不同节点的依赖可能有交叉。

rosdep跑完后，我习惯再加一轮手动的依赖检查。常见的漏网之鱼包括一些只出现在编译期的头文件包，比如libqt4-dev或qtbase5-dev，Rviz和Runtime Manager界面都依赖Qt，装全了能避免运行时弹窗报段错误。

3.3 编译配置与GPU检测

Autoware的编译我直接用catkin工具，编译前建议设置Release模式，不然Debug模式会带来非常大的二进制体积和意外的运行时开销。命令如下：

cd ~/autoware/autoware/ros catkin build --cmake-args -DCMAKE_BUILD_TYPE=Release

如果想要限制同时编译的包数量，避免内存不够：

catkin build -j2 --cmake-args -DCMAKE_BUILD_TYPE=Release

这里的-j2是限制并行的编译进程数量，可以按机器和内存情况调整。如果磁盘写入慢，比如机械硬盘，降低并行数也能减少IO压力。

GPU相关节点在编译时会自动检测CUDA，不需要额外打开某个开关。CMake会寻找/usr/local/cuda、nvcc以及libcudnn，只要前面的环境变量没问题，编译日志里会出现Found CUDA的提示，这就说明GPU支持被正确启用了。如果日志里出现CUDA NOT FOUND，说明环境变量或者软链接不对，回到上一章检查，不要强行继续往下。

编译整个Autoware是个体力活，第一次编译通常要一个小时以上。在等待时把终端日志用tee保存下来，后面排查会方便很多。

3.4 编译产物与环境初始化

编译结束以后，工作区会生成devel目录，里面是编译产物和setup脚本。运行前需要显式加载环境：

source ~/autoware/autoware/ros/devel/setup.bash

之后就可以在终端里执行autoware_start或者runtime_manager。注意每次新开终端都要重新source，否则ROS找不到包，会直接报package not found。

到这里，如果不做验证直接跑Demo，大概率会在运行时才暴露问题。所以下一步还是要老老实实用官方Demo数据走一遍。

4. 运行验证与GPU效果测试

4.1 准备Demo数据与点云地图

Autoware官方提供了一个经典的演示流程：加载点云地图、回放rosbag、启动ndt_matching和感知节点，在Rviz里看车辆定位和障碍物检测结果。点云地图和rosbag数据可以自己录制，也可以用社区流传的样本数据。

准备工作就是把.pcd地图文件和.bag文件放到一个好记的路径。我的习惯是放在~/autoware_demo/下面，不要用中文路径，也不要把文件放在桌面挂载目录，运行时权限问题会很烦。另外rosbag里的话题名要和Autoware节点默认监听的雷达话题一致，不一致的话，后面点云根本不会显示。

4.2 启动Runtime Manager

Runtime Manager是整个Autoware图形化的控制入口。启动命令：

cd ~/autoware/autoware/ros source devel/setup.bash ./run

界面起来之后，左侧会有一排Tab，分别是Map、Sensing、Localization、Perception、Planning等。加载点时，在Map页选择Point Cloud，指定刚才的.pcd文件。Simulation页加载rosbag文件，点击Play开始回放。

实际跑通感知Demo时，我的选择顺序一般是这样：Sensing页打开velodyne_node，Localization页打开ndt_matching，Perception页打开lidar_kf_contour_track或points_downsampler。不用一次全开，逐步验证每个节点是否正常输出。

4.3 用nvidia-smi确认GPU真正在干活

这一步是GPU版最有成就感的时刻。在感知节点运行起来之后，另开一个终端执行：

nvidia-smi

如果能看到一个带Autoware或CUDA关键字的进程占用了GPU显存和计算单元，说明GPU加速确实生效了。单看Rviz界面是分不清CPU和GPU的，必须用这个命令验证。

我遇到过一种情况是节点虽然在跑，但nvidia-smi里看不到进程，后来发现是编译时CMake没找到CUDA，所有GPU相关节点被静默编译成CPU版本。解决办法是检查编译日志，找到包含cuda的节点是否真的显示Found CUDA，然后重新编译对应包。

4.4 可视化与效果对比

在Rviz里加载Autoware提供的视图配置，加入PointCloud2、ndt_map、BoundingBox等显示项。如果点云地图和雷达数据时间戳对齐，ndt_matching输出轨迹会贴合地图，感知节点会画出障碍物框。

想要直观对比GPU和CPU的差异，可以在编译选项里去掉CUDA支持再编一次同一个节点，观察CPU占用和检测帧率。实测下来GPU加速的推理节点帧率提升非常明显，这也是为什么非要用GPU版的原因。在跑检测节点时，GPU版的每个检测框更新更流畅，CPU版则明显拖拽，尤其点云数量上来以后差距更大。

5. 常见问题与避坑整理

5.1 编译期报错实录

编译阶段最常见的几类错误，我分开列一下：

第一类，CMake Error: The following variables are used in this project, but they are set to NOTFOUND。多数情况是某个ROS包或系统库没装。解决办法是先跑一遍rosdep，再对照catkin build的报错信息，找到缺的package.xml依赖并手动安装。

第二类，Could NOT find CUDA。这个最让人头疼，因为Autoware不要求你显式指定GPU，但编译日志会告诉你CUDA路径找不到。我当时的处理办法是检查/usr/local/cuda软链接、nvcc -V和LD_LIBRARY_PATH，三个都对上以后重新编译。注意重新编译前最好清一下build目录里的缓存，否则CMake可能还是沿用旧的失败结果。

第三类，Segmentation fault或internal compiler error，极大概率是内存或者磁盘空间不够。用free -h和df -h确认，再适当减少并行度，或者增加swap。

5.2 运行时缺库与路径问题

运行阶段最容易碰到的是：

error while loading shared libraries: libcudnn.so.7: cannot open shared object file

这个几乎都是LD_LIBRARY_PATH没有包含cuDNN库路径。新版cuDNN默认装到CUDA的lib64下，只要环境变量正确，这种错误应该不会出现。如果还报找不到，可以直接在/etc/ld.so.conf.d下建一个文件，把路径写进去，执行sudo ldconfig。

还有一个比较隐蔽的问题是运行时提示qt.qpa.plugin: could not load ...，这是Qt平台插件缺失，安装qtbase5-dev和libqt5svg5-dev就能解决。这个问题常常出现在用精简桌面环境的机器上，完整桌面版一般不会触发。

5.3 Runtime Manager启动失败

./run脚本启动后界面不出来，先看终端有没有Python报错。Autoware 1.14里有一些脚本是Python2写的，如果系统默认python指向了Python3，脚本可能直接崩溃。我碰到的解决方案是给python做一个指向Python2的软链接，或者找到对应的启动脚本手动调整解释器路径。用ls -l /usr/bin/python可以快速确认当前指向。

还有一种可能是依赖的Qt库版本不对，可以试着用ldd查看相关二进制文件的依赖是否完整，缺哪个就装哪个。

5.4 常见问题速查表

这里每一行都是我实际遇到过或者周围同事遇到过的，不是从文档里抄出来的。速查表只能帮你定位方向，具体细节还是得看日志，建议养成编完一包就看一眼日志的习惯。

5.5 写在最后的体会

这套环境我前前后后装了三遍，第一遍卡在CUDA，第二遍卡在TensorRT，第三遍才完整跑通。个人最大的体会是，Autoware 1.14本身并不算难编，难的是把CUDA、cuDNN、TensorRT和ROS这几个组件的时间线对齐。少一个版本精确匹配，后面报错的样式千奇百怪。

最后再分享一个省钱省时间的小技巧：把编译时用到的命令整理成脚本，每执行完一步就把输出追加到日志文件。比如catkin build ... 2>&1 | tee build.log，这样哪一步出错、哪个节点没有正确识别CUDA，翻日志比猜快得多。如果你正准备在Ubuntu 18.04上装这一套GPU环境，希望这份流程能帮你少走几个来回。