Autoware.universe 实车调试全流程：从环境搭建到控制调优

1. 为什么选择 Autoware.universe 做实车调试1.1 从仿真到实车中间隔了什么很多做自动驾驶的朋友都有类似的经历在仿真环境里跑得好好的算法一上车就各种问题。仿真里感知完美、规划平滑、控制精准到了实车上要么定位漂移要么感知误检要么控制延迟大到没法看。这中间的鸿沟很大程度上不是算法本身的问题而是整个软件栈在真实硬件上的集成和调试没有做到位。Autoware.universe 是目前开源自动驾驶领域功能最完整的软件栈之一它覆盖了感知、定位、规划、控制、车辆接口等全链路模块。相比早期的 Autoware.AIuniverse 版本全面转向了 ROS2 架构在实时性、分布式通信、生命周期管理等方面有了质的提升。但功能完整也意味着系统复杂依赖众多对环境的搭建和配置要求比较高。我这次要分享的就是如何从零开始在一台真实的调试车上把 Autoware.universe 跑起来。整个过程涉及 Ubuntu 系统准备、ROS2 环境配置、Autoware 编译、传感器驱动接入、车辆接口对接、标定与调试等环节。适合已经有一定 ROS2 基础、准备把自动驾驶算法往实车上落地的开发者参考。1.2 实车调试环境的核心需求在动手之前先理清楚实车调试环境到底需要满足哪些需求。这决定了后面每一个技术选型的理由。第一是实时性。实车调试和仿真最大的区别在于传感器数据是实时流入的控制指令必须按时发出。ROS2 默认的通信机制在某些场景下延迟不够稳定需要针对性地调整 QoS 配置和 DDS 实现。第二是可靠性。实车调试过程中任何一个节点的崩溃都可能导致整个系统失效。ROS2 的生命周期节点管理机制可以帮我们做到节点的有序启动、监控和恢复。第三是可观测性。实车调试不像仿真可以随时暂停回放必须有一套完整的日志记录和可视化工具方便事后分析问题。rosbag2 录制、rviz2 可视化、rqt 工具链都是必备的。第四是硬件兼容性。实车上的传感器种类繁多激光雷达、摄像头、组合导航、CAN 总线等每一种都需要对应的 ROS2 驱动而且驱动的时间同步、坐标系定义都要统一。理解了这些需求后面的每一步操作就都有了明确的指向。1.3 整体方案概览我采用的方案大致是这样的底层用 Ubuntu 22.04 作为操作系统ROS2 选择 Humble 版本这是 Autoware.universe 官方推荐的长期支持版本DDS 中间件用 CycloneDDS在实车多节点场景下表现比默认的 FastDDS 更稳定Autoware.universe 从源码编译以获得最大的可定制性。传感器方面激光雷达用常见的机械式或固态激光雷达摄像头用 USB 或 GMSL 接口的工业相机组合导航用支持 RTK 的 GNSS/INS 模块车辆底盘通过 CAN 总线对接。所有传感器的时间同步统一用 PTP 或 GPS 秒脉冲。这个方案的好处是每个环节都是可控的出了问题容易定位。坏处是搭建工作量确实不小需要耐心一步步来。2. 系统环境准备与 ROS2 配置2.1 Ubuntu 22.04 安装与基础配置Autoware.universe 对操作系统版本有明确要求Humble 版本的 ROS2 官方支持 Ubuntu 22.04。我建议直接用 Ubuntu 22.04 的桌面版做开发调试服务器版做车载计算单元。安装过程这里不展开重点说几个容易踩坑的地方。分区的时候如果车载计算单元是 NVMe 固态硬盘建议给根目录至少留 200GB因为 Autoware 源码编译加上 rosbag 数据很容易就吃掉上百 GB。另外单独分一个 /data 分区用来存 rosbag 和地图数据方便管理和迁移。安装完成后第一件事是换国内源并更新系统。这一步看似简单但源没换好后面装依赖会各种超时。我用的是清华的镜像源具体操作是编辑/etc/apt/sources.list把默认的 archive.ubuntu.com 替换成 mirrors.tuna.tsinghua.edu.cn。更新完执行sudo apt update sudo apt upgrade确保系统是最新的。接下来安装一些基础工具这些在后面编译和调试中都会用到sudo apt install -y build-essential cmake git wget curl \ python3-pip python3-colcon-common-extensions \ python3-rosdep python3-vcstool这里特别说一下python3-colcon-common-extensions这是 ROS2 的编译工具 colcon 的扩展包Autoware 的编译依赖它。python3-vcstool是用来管理多个 git 仓库的工具Autoware 的源码由几十个仓库组成靠它来统一拉取。注意不要用 pip 安装 colcon一定要用 apt 安装 python3-colcon-common-extensions否则可能出现编译时找不到某些扩展的问题。2.2 ROS2 Humble 安装与验证ROS2 Humble 的安装按照官方文档来就行但有几个细节值得强调。首先是设置 localeROS2 对 UTF-8 编码有要求sudo apt update sudo apt install locales sudo locale-gen en_US en_US.UTF-8 sudo update-locale LC_ALLen_US.UTF-8 LANGen_US.UTF-8 export LANGen_US.UTF-8然后是添加 ROS2 的 apt 源。这里要注意ROS2 的源和 Ubuntu 的源是分开的需要先添加 GPG key再添加源地址。具体命令官方文档写得很清楚照着做就行。安装的时候我建议装ros-humble-desktop而不是ros-humble-ros-base因为实车调试过程中经常需要用到 rviz2、rqt 这些可视化工具desktop 版本都包含了。安装完成后source 一下环境source /opt/ros/humble/setup.bash echo source /opt/ros/humble/setup.bash ~/.bashrc验证安装是否成功最经典的方法就是跑小乌龟ros2 run turtlesim turtlesim_node另开一个终端跑ros2 run turtlesim turtle_teleop_key如果能看到小乌龟并且能用键盘控制它移动说明 ROS2 基础环境没问题。2.3 DDS 中间件选型与配置ROS2 默认使用 FastDDS 作为 DDS 中间件但在实车多节点、大数据量的场景下FastDDS 的表现有时候不够稳定尤其是在网络抖动或者节点数量较多的时候。我实测下来CycloneDDS 在实车环境下的延迟抖动更小内存占用也更低。安装 CycloneDDSsudo apt install ros-humble-rmw-cyclonedds-cpp然后设置环境变量切换默认的 RMW 实现export RMW_IMPLEMENTATIONrmw_cyclonedds_cpp echo export RMW_IMPLEMENTATIONrmw_cyclonedds_cpp ~/.bashrcCycloneDDS 的配置文件也很重要默认配置在某些场景下可能不够用。我一般会在~/.ros/cyclonedds.xml里写一份自定义配置重点调整接收缓冲区大小和网络接口绑定?xml version1.0 encodingUTF-8? CycloneDDS xmlnshttps://cdds.io/config Domain idany General NetworkInterfaceAddressauto/NetworkInterfaceAddress AllowMulticasttrue/AllowMulticast /General Internal SocketReceiveBufferSize min10MB/ /Internal /Domain /CycloneDDS然后通过CYCLONEDDS_URI环境变量指定配置文件路径。这个配置的作用是增大 socket 接收缓冲区避免在高频率激光雷达数据涌入时丢包。实操心得DDS 的配置对实车调试影响非常大但很多人会忽略。我踩过的坑是激光雷达点云频率高的时候默认缓冲区不够导致点云丢帧感知模块拿到的数据不完整表现为检测结果时断时续。调大缓冲区后问题消失。2.4 系统性能调优实车调试对系统实时性有要求Ubuntu 默认的一些配置需要调整。首先是 CPU 频率调节策略默认的 powersave 模式会导致 CPU 降频影响实时性。改成 performance 模式sudo apt install linux-tools-common linux-tools-generic sudo cpupower frequency-set -g performance其次是禁用一些不必要的后台服务比如 unattended-upgrades避免它在调试过程中突然占用 CPU 和网络。还有就是把 swappiness 调低减少内存交换sudo sysctl vm.swappiness10 echo vm.swappiness10 | sudo tee -a /etc/sysctl.conf如果车载计算单元有独立显卡还需要安装对应的驱动。NVIDIA 显卡的话建议用 apt 安装官方驱动不要用.run 文件方便后续升级。安装完驱动后CUDA 和 cuDNN 也要装好因为 Autoware 的感知模块很多依赖 GPU 加速。3. Autoware.universe 源码编译与部署3.1 源码获取与依赖安装Autoware.universe 的源码托管在 GitHub 上由多个仓库组成。官方推荐用 vcstool 来管理。首先创建工作空间mkdir -p ~/autoware_ws/src cd ~/autoware_ws然后下载 Autoware 的 .repos 文件这个文件定义了所有需要的仓库和对应的版本wget https://raw.githubusercontent.com/autowarefoundation/autoware/main/autoware.repos vcs import src autoware.repos这个过程会拉取几十个仓库网络不好的话可能要很久。建议配置好 git 的代理或者用国内镜像。拉取完成后用 rosdep 安装系统依赖sudo rosdep init rosdep update rosdep install -y --from-paths src --ignore-src --rosdistro humblerosdep 安装依赖这一步是最容易出问题的因为依赖包很多任何一个下载失败都会导致后续编译报错。我的经验是如果中途失败不要慌重新执行一次 rosdep install它会跳过已经装好的继续装剩下的。反复几次直到全部成功。注意rosdep 有时候会因为网络问题卡住可以设置ROS_DISTROhumble环境变量并且确保 apt 源是通的。如果某个包一直装不上可以手动 apt install 对应的包名。3.2 编译参数选择与优化Autoware.universe 的编译是个大工程全量编译在普通配置的机器上可能要一两个小时。编译前有几个参数需要根据实际情况调整。首先是编译类型调试阶段建议用RelWithDebInfo既有优化又保留调试信息colcon build --symlink-install \ --cmake-args -DCMAKE_BUILD_TYPERelWithDebInfo \ -DCMAKE_CXX_FLAGS-w--symlink-install的作用是用符号链接代替拷贝这样修改 Python 脚本或者 launch 文件后不需要重新编译直接生效调试效率高很多。-DCMAKE_CXX_FLAGS-w是屏蔽编译警告Autoware 代码量大警告信息会刷屏屏蔽掉能让真正的错误更容易被发现。如果机器内存不够比如只有 16GB编译时可能会因为内存不足被 kill。这时候可以用--parallel-workers限制并行编译的包数量colcon build --symlink-install --parallel-workers 2 \ --cmake-args -DCMAKE_BUILD_TYPERelWithDebInfo编译过程中可以用--packages-select只编译特定的包比如只改了感知模块就只编译感知相关的包节省时间。编译完成后source 一下工作空间的 setup 文件source ~/autoware_ws/install/setup.bash echo source ~/autoware_ws/install/setup.bash ~/.bashrc3.3 地图与车辆参数配置Autoware 跑起来需要地图和车辆参数。地图方面Autoware 使用 Lanelet2 格式的高精地图包含道路拓扑、车道线、交通标志等信息。如果没有现成的高精地图可以用 Autoware 自带的地图工具或者开源的工具链生成。车辆参数方面Autoware 在vehicle目录下有各种车型的配置模板。需要根据实际车辆修改的参数包括轴距、轮距、最大转向角、最大加速度、最大减速度、车辆尺寸等。这些参数直接影响控制模块的计算填错了轻则控制效果差重则车辆行为异常。我一般会新建一个自己的车辆参数包而不是直接改官方的这样升级 Autoware 的时候不会冲突。具体做法是复制一份官方模板重命名后修改参数然后在 launch 文件里指定使用自己的参数包。3.4 传感器驱动接入传感器驱动是实车调试环境搭建中最繁琐的部分因为每种传感器的驱动都不一样而且驱动的时间戳、坐标系、数据格式都要和 Autoware 对齐。激光雷达方面常见的 Velodyne、RoboSense、Livox 等都有 ROS2 驱动。安装驱动后需要配置 IP 地址、端口、数据格式等参数。关键是确保点云的时间戳是准确的并且坐标系定义符合 Autoware 的要求一般激光雷达坐标系是lidar需要和base_link有正确的 TF 变换。摄像头方面USB 相机可以用usb_cam或v4l2_camera驱动GMSL 相机一般用厂商提供的驱动。摄像头的内参和畸变系数需要提前标定好写成 YAML 文件供 Autoware 使用。组合导航方面支持 RTK 的 GNSS/INS 模块一般通过串口或网口输出数据需要对应的 ROS2 驱动解析。关键是确保输出的定位数据包含协方差信息Autoware 的定位模块需要这个来做融合。CAN 总线方面车辆底盘的控制指令和状态反馈都通过 CAN 传输。需要用ros2_socketcan或者厂商提供的 CAN 驱动把 CAN 报文转换成 ROS2 话题。发送控制指令的话题一般是vehicle/command接收车辆状态的话题一般是vehicle/status。实操心得传感器驱动接入的时候最容易忽略的是时间同步。如果各个传感器的时间戳不一致感知融合和定位都会出问题。我的做法是统一用 PTP 做时间同步或者用 GPS 的秒脉冲加 PPS 信号。如果硬件不支持至少要在软件层面做时间戳对齐。4. 实车调试流程与关键环节4.1 静态调试传感器数据检查车不动的时候先把所有传感器的数据检查一遍。这一步的目的是确认每个传感器都能正常出数据数据格式正确时间戳合理。启动 Autoware 的传感器 launch 文件后用ros2 topic list查看所有话题确认每个传感器对应的话题都存在。然后用ros2 topic hz检查数据频率激光雷达一般是 10Hz 或 20Hz摄像头是 30Hz组合导航是 100Hz 或更高。用 rviz2 可视化点云和图像确认数据内容正常。点云应该能清晰看到周围环境图像应该没有明显畸变。如果点云有拖影或者图像有撕裂可能是时间戳或者同步的问题。还要检查 TF 树是否完整。用ros2 run tf2_tools view_frames生成 TF 树图确认从base_link到各个传感器的坐标系变换都存在且合理。TF 缺失或者错误是实车调试中最常见的问题之一。4.2 动态调试定位与感知验证车动起来之后重点验证定位和感知。定位方面Autoware 支持多种定位方式包括 GNSS、NDT 匹配、EKF 融合等。实车调试一般先用 GNSS 定位跑通再逐步加入激光雷达匹配。检查定位是否正常可以在 rviz2 里看车辆位置是否和实际位置一致轨迹是否平滑。如果定位跳变或者漂移可能是 GNSS 信号不好或者 NDT 匹配的参数需要调整。感知方面重点看检测结果是否稳定。激光雷达检测应该能稳定识别出周围的车辆、行人、障碍物。如果检测结果时有时无可能是点云质量不好或者检测参数需要调优。摄像头检测应该能识别车道线和交通标志如果识别率低可能是标定参数不准或者光照条件影响。4.3 控制调试从低速到高速控制调试是最需要谨慎的环节因为直接关系到车辆安全。我的做法是从最低速开始逐步提高。先在封闭场地里把车辆限制在极低速度比如 5km/h测试基本的加减速和转向控制。确认车辆能按照预期响应控制指令后再逐步提高速度。控制参数方面Autoware 的 MPC 控制器和纯跟踪控制器都有不少参数需要调。关键是横向控制的预瞄距离和纵向控制的 PID 参数。预瞄距离太短会导致转向震荡太长会导致转向滞后。PID 参数需要根据车辆的实际响应来调没有万能值。调试过程中一定要有安全员随时准备接管并且设置好紧急停止按钮。任何异常情况第一时间停车。4.4 数据记录与回放分析实车调试过程中一定要全程录制 rosbag。rosbag2 可以录制所有话题的数据事后可以回放分析。录制的时候注意磁盘空间高频率的激光雷达和摄像头数据很占空间建议用外置 SSD。回放分析的时候可以用ros2 bag play回放数据同时启动 rviz2 和 rqt 观察各个模块的表现。如果发现问题可以反复回放同一段数据慢慢排查。我一般会针对每次调试写一个简单的记录包括调试时间、天气、场地、测试内容、发现的问题、可能的原因。这些记录在后续排查问题时非常有用。5. 常见问题与排查技巧5.1 编译与依赖问题编译 Autoware 最常见的问题是依赖缺失。表现是 colcon build 的时候某个包报错提示找不到某个头文件或者库。这时候先看错误信息确定缺的是什么然后用 apt 安装对应的包。如果 apt 里没有可能需要从源码编译。另一个常见问题是内存不足。编译大包的时候如果内存不够编译器会被 OOM killer 杀掉表现为编译突然中断没有任何错误信息。这时候用dmesg看内核日志如果有 OOM 相关的记录就是内存不够。解决办法是减少并行编译的包数量或者增加 swap 空间。5.2 通信与 QoS 问题ROS2 的 QoS 配置不匹配是实车调试中的高频问题。表现是话题存在ros2 topic list能看到但ros2 topic echo收不到数据。这通常是因为发布者和订阅者的 QoS 不兼容比如一个用 reliable一个用 best_effort。解决办法是检查发布者和订阅者的 QoS 配置确保兼容。可以用ros2 topic info --verbose查看话题的 QoS 信息。Autoware 里很多话题的 QoS 是预设好的如果自己写的节点要订阅这些话题必须匹配对应的 QoS。5.3 时间同步与 TF 问题时间同步问题表现多样可能是点云和图像对不齐可能是定位跳变可能是控制延迟。排查的时候先检查各个传感器的时间戳看是否在同一个时间基准上。TF 问题表现是 rviz2 里某些数据显示不出来或者显示位置不对。用ros2 run tf2_tools view_frames检查 TF 树看是否有断链或者循环。常见的 TF 问题包括静态 TF 没有发布、TF 的时间戳过期、坐标系名称拼写错误。5.4 常见问题速查表问题现象可能原因排查方法解决办法话题存在但收不到数据QoS 不匹配ros2 topic info --verbose调整 QoS 配置点云丢帧DDS 缓冲区不足检查 CycloneDDS 配置增大 SocketReceiveBufferSize定位跳变GNSS 信号差或 NDT 参数不当查看 GNSS 状态和 NDT 匹配分数调整参数或切换定位模式控制震荡预瞄距离或 PID 参数不当录制控制指令和车辆响应调整控制参数编译中断无报错内存不足dmesg查看 OOM 记录减少并行编译或增加 swapTF 断链静态 TF 未发布view_frames检查补发静态 TF传感器数据时间戳不一致未做时间同步对比各传感器时间戳配置 PTP 或软件对齐5.5 独家避坑技巧第一个技巧是分阶段启动。不要一上来就启动整个 Autoware而是先启动传感器驱动确认数据正常再启动感知再启动定位最后启动规划控制。这样出问题容易定位是哪个环节。第二个技巧是用 ros2 doctor 做体检。ros2 doctor可以检查 ROS2 环境的各种配置包括网络、DDS、环境变量等能发现一些隐藏的问题。第三个技巧是保留一份最小可运行配置。调试过程中会不断改参数很容易改乱。我一般会保留一份确认能跑通的最小配置改乱了就回退到这份配置重新来。第四个技巧是日志分级。Autoware 的日志信息很多调试的时候把日志级别调到 debug能看到更多细节。但正式跑的时候要调回 info 或 warn避免日志刷屏影响性能。6. 写在最后的一些个人体会实车调试这件事急不得。我见过太多人想着一两天就把车跑起来结果各种问题堆在一起越调越乱。我的经验是把整个流程拆成小步骤每一步都确认没问题再往下走。传感器数据检查、定位验证、感知验证、控制调试每个环节都稳了整车才能稳。另外就是一定要重视数据记录。实车调试的机会往往有限每次上车都要尽量多录数据。很多问题在车上的时候看不出来回来回放数据才发现端倪。rosbag 录制的习惯越早养成越好。还有就是安全。实车调试和仿真最大的区别就是仿真里撞了可以重来实车撞了就是真金白银甚至人身安全。安全员、紧急停止、低速测试这些规矩一个都不能少。我自己的习惯是任何新的控制参数先在仿真里跑一遍再到实车上低速验证确认没问题再逐步提速。Autoware.universe 这个软件栈确实复杂但它的模块化设计也意味着你可以按需使用。不一定非要把所有模块都跑起来可以先跑通定位加控制感知用简单的障碍物检测等基础链路稳了再逐步加模块。这种渐进式的思路比一上来就追求全功能要靠谱得多。