结论：MARV 无人车的 CAN 集成层只有一份 marv.dbc，规模是 35 条 BO_ 报文、115 行 SG_ 信号，平均每条报文 3.29 条信号。它落在 marv_driver 包的 resource/ 目录里，与自定义消息包、场景包、惯导驱动并列。真正限制复用的是三处未核验：平台硬件、DBC 信号校验、以及它并非量产车型定义。
集成层的落点：一份 DBC 与四个 ROS 包
归档只保留了一个文件：colcon_ws/src/marv_driver/resource/marv.dbc。把它放在 driver 包的 resource/ 下，说明这个项目把报文定义当作驱动的一部分来管理，而不是外部配置文件。这个位置决定了 DBC 的更新节奏与驱动代码同步，改信号定义等于改驱动包。
同一工作空间里并列着四个包。理解它们的分工，才能判断一条 CAN 信号从总线到控制回路之间要穿过几层。
| 包 | 上游说明 | 在集成链中的位置 |
|---|---|---|
marv_driver |
Basic system functions | 归档的 marv.dbc 位于该包 resource/ 目录，是报文定义的落点 |
marv_msgs |
Custom messages package | 自定义消息类型定义，说明文档未给出消息清单 |
marv_scenarios |
用户实现的场景，例如 waypoint_navigation | 场景层，说明文档仅举了航点导航一例 |
sbg_ros2 |
The SBG INS driver | 惯性导航数据源，与总线信号并行 |
规模与统计口径
35 条报文与 115 行信号是归档方统计 BO_ 与 SG_ 行数得出的。这个口径只说明文件里定义了多少条报文、多少行信号，不代表每一条都已被实车验证。作为对照，同为车队级归档的水冷式方程式项目通常在 50 到 115 条报文的量级，MARV 属于偏小的一侧。
| 指标 | 数值 | 口径说明 |
|---|---|---|
报文定义（BO_） |
35 | 按 BO_ 行数统计 |
信号定义（SG_） |
115 | 按 SG_ 行数统计 |
| 平均信号 / 报文 | 3.29 | 由上述两项相除得出 |
| 归档文件数 | 1 | marv_driver/resource/marv.dbc |
归档说明还给出了该文件的完整性校验值：Git blob 182c2fb5f6c02d8ef26c26b2adaa564174f1c2f1，SHA-256 4aab0907c9c43435b11c8729c725c092f98667deb868cc7c6356ed5eb8f3dddc，快照修订为 5b7ed5f6a5547a63407562572b31243f9c5a35a7，采集日期 2026-10-04。
构建、运行与开机自启
构建链路相当固定：先在 REACH 车载计算机上按「reach setup」文档装齐依赖，再 source ROS 2 galactic，最后在 colcon_ws 目录内执行 colcon build --symlink-install。这里没有给出依赖清单，意味着环境不可复现——换一台机器时，第一步的「装齐依赖」只能靠文档之外的信息完成。
运行方式有三套，分别对应调试、常规与部署。测试用途下 ./marv_start.sh 会启动一个 screen 终端会话，适合现场看输出；常规使用则依赖服务在开机时自动拉起，需要人工干预时另有 ./marv_restart、./marv_stop、./marv_start 三个脚本。
| 场景 | 命令 | 说明 |
|---|---|---|
| 测试用途 | ./marv_start.sh |
启动一个 screen 终端会话，便于直接观察节点输出 |
| 常规使用 | 开机自动启动；./marv_restart、./marv_stop、./marv_start |
需先在 reach setup 文档中完成服务配置 |
| 服务管理 | sudo systemctl enable marv_package、start、stop、systemctl status marv_package |
enable 用于开机自启，start 与 stop 用于手动控制，status 查状态 |
| 会话清理 | screen -r 重新接入；killall screen |
接入后用 ctrl + C、ctrl + D 逐个关闭终端 |
读这份文档时有一处需要自己纠正：上游把「禁用服务」的命令也写成了 sudo systemctl enable marv_package，与启用命令完全相同。按字面执行达不到禁用效果，正确做法应是对应的 disable。这类笔误在自维护文档里很常见，抄命令之前先确认语义，不要照单全收。
日志与仿真这两套机制合起来，覆盖了从录制到回放再到脚本自检的完整链路，但它们的边界都写在文档里而没有含糊处理。使用时最容易犯的错误是把「跑通了」当成「跑对了」。
两套 rosbag 与 scenario_starter 的仿真边界
日志侧提供两套 rosbag：一套记录全部 topic，另一套只记录指定 topic（如导航数据），具体 topic 可在 start_specific_ros_bah.sh 脚本中修改。这种「全量 + 定向」的双轨设计很实用——全量用于事后回溯，定向用于长时间跑车时控制数据量。
仿真侧则由 scenario_starter 这个额外的 ROS 节点承担，用来模拟 MARV 系统其余部分的行为。它模拟 12V Auto 状态，以及 OCU 发出的 start scenario 命令。文档对它的边界写得很克制：它不模拟任何传感器数据，作用只是在正式路试前先在「陆地」上验证场景脚本能否正常启动。
| 手段 | 覆盖 | 明确不覆盖 |
|---|---|---|
| rosbag（全量） | 每一个 topic | 说明文档未涉及落盘策略与容量限制 |
| specific rosbag | 指定 topic，例如导航数据 | 其余 topic 不记录；需手工维护脚本内的 topic 列表 |
scenario_starter 节点 |
12V Auto 状态、OCU 的 start scenario 命令 | 任何传感器数据；只能给出脚本是否启动正确的指示 |
把这三行放在一起看，结论很直接：这套工具链能验证「脚本会不会崩」，但不能验证「车会不会开对」。传感器数据必须来自真实车辆或另行搭建的仿真。
归档快照与权利状态
归档只保留了一个文件，因此完整性校验相对简单：路径 colcon_ws/src/marv_driver/resource/marv.dbc，Git blob 182c2fb5f6c02d8ef26c26b2adaa564174f1c2f1，SHA-256 4aab0907c9c43435b11c8729c725c092f98667deb868cc7c6356ed5eb8f3dddc，快照修订 5b7ed5f6a5547a63407562572b31243f9c5a35a7，采集日期 2026-10-04。归档方确认保留字节与所钉住的 Git blob 一致，且在本地存档中没有字节相同或经 CRLF 归一化后相同的重复项。
权利侧的表述需要读仔细：归档保留了仓库的 MIT 许可证与上游 README，同时写明各组件数据的独立来源并未确立。这两句话不矛盾，但含义差别很大——MIT 覆盖的是仓库自身携带的内容，不等于覆盖项目所引用的第三方组件数据。把它并入闭源产品或对外再分发之前，组件部分仍需单独确认。
常见问题
marv.dbc 的 35 条报文分别对应哪些硬件？
归档说明没有给出逐条映射。文件位于 colcon_ws/src/marv_driver/resource/marv.dbc，规模为 35 条 BO_ 报文与 115 行 SG_ 信号；归档方同时写明具体平台硬件与 DBC 信号校验均未独立检查，且这不是量产车型定义。要确定报文与硬件的对应关系，需要结合 marv_driver 的源码自行核对。
为什么构建步骤要固定 ROS 2 galactic？
因为构建与运行步骤是按这个发行版写的：构建前需 source ROS2 galactic，相关脚本按 /opt/ros/galactic/setup.bash 的路径组织。换成其他发行版时这些路径与包名需同步调整，而说明文档没有提供其他发行版下的验证记录。
两套 rosbag 应该怎么选？
按用途分：一套记录全部 topic，适合事后完整回溯；另一套只记录指定 topic（例如导航数据），适合长时间跑车时压住数据量。定向那套的 topic 列表写在 start_specific_ros_bah.sh 脚本里，改场景时要记得同步维护，否则关键信息不会被记录。
scenario_starter 能不能代替实车路试？
不能。它只模拟 12V Auto 状态与 OCU 发出的 start scenario 命令，用于在正式路试前验证场景脚本能否正常启动。上游说明明确指出它不模拟任何传感器数据，因此只能给出「脚本是否启动正确」的指示，无法验证控制行为是否正确。
这份归档的权利状态如何？
归档方保留了仓库的 MIT 许可证与上游 README，同时说明各组件数据的独立来源并未确立。MIT 覆盖的是仓库本身携带的内容，不等于覆盖随项目引用的第三方组件数据；再分发前需要单独确认各组件部分的权利。
延伸阅读
- PACMod 线控 v3 平台档案：4.0.0 到 14.1.0 演进 —— 同类地面无人车线控总线的报文契约
- Kia Soul OSCC 档案：归一化命令与 200 ms 保活接口 —— 另一套无人车命令归一化与保活设计
- 车载信号为什么会说谎：TTL、源时间与 500 ms 新鲜度阈值 —— 场景层消费解码信号时的新鲜度约束
- Waterloo 2024CAR DBC 档案：115 个报文与 890 条信号 —— 车队级归档在量级上的横向对照
参考资料
- 项目 01 ——
public-can-dbc-datasets/additional/case-lab-marv-ros/SOURCE.md（marv.dbc的路径、35 条 BO_ 报文与 115 行 SG_ 信号、Git blob 与 SHA-256、快照修订与采集日期、平台硬件与信号校验未核验的声明、保留 MIT 许可证与上游 README 的权利说明） - 项目 01 ——
public-can-dbc-datasets/additional/case-lab-marv-ros/UPSTREAM_README.md（colcon_ws 内四个包的分工、依赖与 galactic 环境下的 colcon build –symlink-install 构建、两套 rosbag 与 start_specific_ros_bah.sh 的 topic 配置、marv_start.sh 与 screen 会话、systemd 服务命令、scenario_starter 节点的仿真覆盖范围与不模拟传感器数据的边界）
免责声明
本文所述报文与信号数量、包结构、命令与运行方式均来自公开开源仓库的说明文档，属第三方工程产物，未经独立实车核验。归档方已明确声明平台硬件与 DBC 信号校验未独立检查，且该定义并非量产车型模型。不同平台版本与组件固件可能存在差异。涉及安全相关用途时请仅作参考，并以实际测量与官方资料为准。
更新记录
- 2026-10-14 初稿
发表回复