课程导入：无人车项目交付的整体流程、交付物清单、验收标准与学习目标

无人车项目从研发到落地，真正的“终点”并非算法跑通或样车路测通过，而是完成一次规范、完整、可复现的项目交付。交付环节是连接研发团队与客户/运营方的关键桥梁，也是衡量项目成熟度的核心标尺。在实际工程中，许多无人车项目在实验室表现优异，却在交付现场因文档缺失、接线混乱、模型权重版本不匹配或演示场景设计不合理而陷入被动。本章作为整个课程的开篇，将系统梳理无人车项目交付的整体流程、交付物清单、验收标准与学习目标，帮助学员建立“交付思维”——即从客户可接收、运维可接手、系统可复现的角度审视整个项目。

一、无人车项目交付的整体流程

无人车项目交付并非一个简单的“交钥匙”动作，而是一条包含多个阶段、多个角色协同的完整链路。从工程实践角度，交付流程可划分为五个核心阶段：交付准备、现场部署与集成、联调与测试、交付与验收、运维与支持。每个阶段都有明确的输入、输出和关键检查点。

1. 交付准备阶段

交付准备是决定项目成败的“隐形阶段”。此阶段的核心任务包括：需求确认与范围界定（明确客户期望的自动驾驶级别、运行场景、性能指标）、环境勘察（测量场地尺寸、光照条件、GPS信号强度、网络覆盖、电源容量）、交付计划制定（时间表、人员分工、备件清单）以及风险预案（如备用传感器、回滚方案、应急通信手段）。一个常见的误区是跳过环境勘察直接进场，导致现场出现GPS信号遮挡、Wi-Fi干扰或电源功率不足等问题，轻则延误工期，重则导致交付失败。

2. 现场部署与集成阶段

此阶段是将“实验室系统”转化为“现场可用系统”的过程。具体操作流程如下：

1. 硬件安装与接线检查：按照接线图逐一连接传感器（激光雷达、摄像头、IMU）、计算单元（工控机/嵌入式平台）、执行机构（电机/舵机）和电源模块。每完成一条接线，应立即用万用表进行通断测试和电压确认。
2. 系统镜像烧录与配置：为计算单元烧录操作系统（通常为Ubuntu或定制Linux），配置网络（静态IP、ROS/ROS2环境变量）、安装显卡驱动和CUDA环境。
3. 源码编译与依赖安装：从版本控制仓库（如Git）拉取指定tag的源码，按照依赖清单（requirements.txt、package.xml）安装所有第三方库。编译过程需记录日志，确保无警告和错误。
4. 模型权重部署与校验：将训练好的模型权重文件（如.pt、.onnx、.engine）拷贝至指定目录，并计算其MD5/SHA256哈希值与交付清单比对，防止文件损坏或版本错误。

3. 联调与测试阶段

联调测试是验证系统整体功能与性能的关键环节。测试应遵循“由底向上、由局部到整体”的原则：

• 单元测试：单独验证每个传感器（如激光雷达点云是否正常发布、摄像头图像帧率是否达标）和执行器（如电机转速响应、舵机转角精度）。
• 系统集成测试：验证传感器数据融合、定位模块输出、规划控制模块的闭环响应。重点检查通信链路（ROS Topic/Service）的延迟和丢包率。
• 场景演示预演：按照《演示场景说明》中的脚本，完整走一遍演示流程，记录每个步骤的实际表现与预期差异。
• 性能指标验证：使用专业工具（如bag包录制、性能分析器）测量系统延迟、CPU/GPU占用率、帧率等关键指标，确保满足设计规格。

4. 交付与验收阶段

此阶段的核心是“签字确认”。交付团队需准备完整的交付物清单，逐项向客户展示并解释。验收测试通常包括：功能验收（演示场景是否全部通过）、性能验收（指标是否达标）、文档验收（资料是否齐全）。验收过程中，客户可能会提出修改意见，需建立变更管理流程，明确修改范围、工期和成本影响。

5. 运维与支持阶段

交付不是终点，而是运维的起点。交付团队应提供：远程监控通道（如SSH隧道、VPN）、日志采集方案（自动上传运行日志）、故障响应机制（明确响应时间和升级路径）、定期巡检报告。对于模型迭代，需建立OTA（Over-The-Air）升级流程，确保现场设备可以安全、可回滚地更新软件和模型。

二、交付物清单详解

一份规范的交付物清单是验收的基础。根据行业实践和课程经验，无人车项目交付物可分为四大类：代码与模型、硬件与接线文档、部署与运维文档、演示与测试材料。下表列出了核心交付物及其关键要求：

三、验收标准与判定方法

验收标准是交付团队与客户之间的“契约”。标准必须可量化、可复现、可判定。以下是一套经过多个项目验证的验收标准框架：

1. 功能验收标准

• 场景覆盖率：所有约定的演示场景（如“绕障行驶”、“定点停车”、“循迹导航”）必须100%通过，且连续运行3次无失败。
• 安全机制：急停按钮响应时间≤200ms；障碍物检测距离误差≤10%；自动紧急制动（AEB）功能在测试中必须成功触发。
• 人机交互：遥控器切换模式（自动/手动）响应时间≤500ms；状态指示灯显示与系统实际状态一致。

2. 性能验收标准

• 系统延迟：从传感器数据采集到控制指令输出的端到端延迟≤100ms（典型值50ms）。
• 定位精度：在RTK有效区域内，横向定位误差≤10cm，纵向误差≤20cm。
• 资源占用：在典型场景下，CPU平均占用率≤70%，GPU显存占用≤80%，内存占用≤85%。

3. 稳定性验收标准

• 连续运行：系统在无人值守状态下连续运行8小时，无死机、无核心进程崩溃、无内存泄漏。
• 异常恢复：模拟网络中断、传感器断连等故障，系统应能自动恢复或安全停车，且恢复时间≤30秒。

四、案例拆解：某园区无人配送车交付实录

为帮助学员理解上述流程，下面拆解一个真实案例：某科技园区无人配送车项目交付。

背景与约束：客户为一家物流公司，需要在占地2平方公里的园区内实现无人车配送。场地特点：道路较窄（最窄处2.5米）、有大量行人、部分区域GPS信号被高楼遮挡。交付工期为10个工作日，客户要求提供完整的源码和模型，以便后续自行迭代。

初始现象与目标：实验室样车在园区测试时，频繁出现定位漂移（误差超过50cm），导致车辆压线行驶。目标是将定位误差控制在15cm以内，并完成三个演示场景：场景A（沿固定路线配送）、场景B（动态避障）、场景C（定点停车取货）。

关键输入数据与参数：

• 传感器配置：1×16线激光雷达、1×前视摄像头（1080p@30fps）、1×RTK-GPS（理论精度2cm）、1×IMU（200Hz）。
• 定位算法：LOAM（激光里程计）+ RTK-GPS融合，采用EKF（扩展卡尔曼滤波）。
• 现场实测：在GPS信号遮挡区域（高楼旁），RTK固定解丢失率高达40%。

分析判断过程：通过录制bag包回放分析，发现定位漂移主要发生在RTK信号丢失的瞬间。EKF融合算法在GPS更新中断后，过度依赖IMU积分，导致误差快速累积。进一步检查发现，IMU的安装位置靠近车辆振动源（电机驱动器），导致高频噪声过大。

实际操作步骤：

1. 硬件调整：将IMU重新安装至车辆后轴中心位置，并使用橡胶减震垫隔离振动；同时调整RTK天线安装位置，减少遮挡。
2. 算法优化：修改EKF参数，降低GPS信号丢失时的IMU权重；增加激光雷达点云与高精地图的匹配约束（NDT配准）。
3. 参数调优：将IMU的加速度计噪声密度从0.01 m/s²/√Hz调整为0.005，陀螺仪噪声密度从0.001 rad/s/√Hz调整为0.0005。
4. 验证测试：在GPS遮挡区域连续测试10次，记录定位误差。

结果对比：

风险与代价：算法优化增加了约15%的CPU计算量，导致系统整体延迟从85ms上升至95ms，仍在100ms指标内。但为了安全余量，最终将激光雷达的扫描频率从10Hz降至8Hz，延迟回落至88ms。这一调整需要重新验证避障性能，额外花费了1天时间。

复盘经验：① 交付前的环境勘察必须包含GPS信号质量测试，不能只看卫星数量；② IMU安装位置对定位精度影响巨大，应作为标准检查项；③ 任何算法参数调整后，必须回归测试所有演示场景，不能只测单一场景。

五、常见误区与总结复盘

在无人车项目交付中，以下误区最为常见，需要特别警惕：