📚 课程目录第1章课程导入

1. 课程导入

Autoware 作为开源自动驾驶软件栈，已经在原型验证阶段证明了其算法能力。但从“能跑”到“能量产”，中间隔着一整套工程化体系：传感器标定一致性、计算平台资源约束、功能安全与预期功能安全、诊断与故障降级、OTA 升级与版本追溯。本课程的目标，是把 Autoware 从一套算法框架，转化为可在真实车型上稳定交付的量产系统。

本课程的学习目标可以概括为三条主线：集成——把感知、定位、规划、控制与车辆平台正确装配；诊断——让系统在异常时能被观测、被定位、被降级；量产——满足车规环境下的可靠性、可维护性与合规性要求。

一、核心概念：从原型到量产的三层跃迁

理解本课程，需要先建立三个核心概念。第一是软件栈与硬件平台的耦合：Autoware 的节点并非孤立运行，它们依赖 LiDAR、相机、GNSS/IMU、底盘 CAN 等真实输入，任何一路信号的时序或标定偏差都会传导到下游。第二是运行时诊断：量产系统不能只依赖开发阶段的日志，而要在运行中持续采集健康状态、延迟、丢帧、置信度等指标。第三是可降级设计：当某个模块失效时，系统应进入安全状态，而不是直接崩溃。

这三层跃迁对应着不同的工程关注点：原型阶段关注“功能是否实现”，集成阶段关注“数据是否对齐”，量产阶段关注“异常是否可控”。很多团队在集成阶段就遇到瓶颈，原因往往不是算法不行，而是时间同步、坐标系变换、资源调度这些“非算法”问题没有被系统化处理。

二、方法流程：集成与诊断的闭环

量产集成不是一次性动作，而是一个持续闭环。典型流程如下：

接口对齐：确认传感器安装位置、坐标系定义、时间戳来源与频率，形成接口控制文档（ICD）。
标定与验证：完成内参、外参、时间偏移标定，并用回放数据验证标定残差。
资源评估：在目标计算平台上测量各节点 CPU、GPU、内存与通信带宽占用，识别瓶颈。
诊断埋点：为关键节点增加健康状态、延迟、丢帧、置信度等运行时指标。
降级策略：定义故障等级与对应动作，如限速、靠边停车、切换备用定位源。
回归与追溯：每次版本变更都通过回放与实车测试回归，并记录版本与配置。

建议把“诊断埋点”提前到集成初期，而不是等到量产前再补。因为诊断信息本身就是集成调试的重要输入，越早建立越能减少后期返工。

三、案例场景：一次典型的集成故障

某项目在实车测试中发现，车辆在高速路段偶尔出现规划轨迹抖动。算法团队检查规划模块未发现异常，最终定位到根因：LiDAR 与 IMU 的时间戳来源不同，导致点云去畸变时使用了错误的时间基准，定位输出出现周期性偏差。这个问题在开发阶段因为车速低、场景简单而未暴露。

解决过程体现了本课程的核心方法：先通过诊断指标发现定位协方差异常，再用回放数据复现，最后统一时间同步源并重新标定。整个过程依赖的是可观测性与可追溯性，而不是单纯调参。

# 查看关键话题频率与延迟（示例）
ros2 topic hz /sensing/lidar/points
ros2 topic delay /localization/kinematic_state
ros2 topic echo /diagnostics --once

四、误区与复盘

常见误区	后果	正确做法
只关注算法精度，忽略时间同步	定位与感知结果错位，规划抖动	统一时间源，验证时间偏移残差
诊断信息只在开发阶段使用	量产阶段无法快速定位故障	诊断埋点纳入量产版本，支持远程上报
降级策略缺失或过于简单	单点故障导致系统不可用	定义故障等级与对应安全动作
版本与配置无追溯	问题无法复现，责任边界模糊	建立版本、标定、参数一体化追溯

量产落地最大的挑战往往不是算法本身，而是“非算法”的系统工程：时间、坐标、资源、诊断、降级、追溯。这些环节任何一个缺失，都可能让整套系统在真实场景中失效。

本课程后续将围绕上述框架逐层展开：从传感器与接口集成，到计算平台与中间件调优，再到功能模块的诊断埋点与降级设计，最终落到量产验证与运维体系。掌握这套方法，才能让 Autoware 真正从演示走向交付。