船上的驾驶员轻推操纵杆。在 BlueROV2 动起来之前，这份操作意图已经依次穿过水面端应用、以太网系缆、伴随计算机、消息路由器、串行链路和自动驾驶仪。返回画面走的是另一条路线：相机帧经由视频服务沿系缆返回水面端，载具遥测则以结构化消息传输。

“开源水下机器人”这个说法初听直观，用来理解 BlueROV2 却过于笼统。BlueROV2 的实际形态是一组可替换的分层组件，各层的运行节拍、失效方式和职责各不相同，远比“蓝色机架里的一颗开源大脑”复杂。Cockpit 或 QGroundControl 面向操作员，MAVLink 为指令与遥测建立共享词汇，BlueOS 协调艇载服务，ArduSub 则贴近传感器、电机输出和载具状态。[1][4][7]

本文按这些职责分界绘制生态图谱，开放性标签本身退居其次。实际问题既包括团队能否修改这套软件栈，也包括改动该放在哪一层，以及改动失败时哪些层仍须正常工作。

跟随一条指令，再跟随一帧相机画面

指令路径可以收束成一行：

joystick → Cockpit or QGroundControl → tether/IP → BlueOS MAVLink endpoint → flight-controller link → ArduSub → motor mixer → ESCs and thrusters

图像走的是另一条路径：

camera → BlueOS camera manager → WebRTC, RTSP, or UDP stream → surface display or recorder

ArduPilot 自身的文档划出了核心分工。自动驾驶仪负责基本的载具控制与任务执行；伴随计算机管理相机和复杂外设，再通过 MAVLink 与自动驾驶仪通信，常见链路是 UART。[1] BlueOS 承担的正是这一伴随角色。其文档把它描述为一套运行在艇载计算机上的系统，位于飞行控制器、操作员和那些不直接测量控制状态的传感器之间。[4]

分别看待这些路径，故障诊断会更清楚。驾驶员可以收到正常遥测，视频流却已经中断；记录器可以停止工作，定深仍在继续；MAVLink 路由可以失效，相机依旧持续产生画面。“系缆已连通”只能说明一部分状态，指令、遥测和视频路径都要各有健康证据。

Cockpit 负责操作态势，稳定控制由艇载系统完成

Cockpit 把成堆信号整理成驾驶员的操作空间。其默认 ROV 配置包括视频或 HUD 视图、遥测、姿态与罗盘仪表、状态消息、飞行模式控制，以及供已定位载具使用的地图视图。发现 BlueOS 载具后，Cockpit 会连接 MAVLink2REST 服务获取载具数据，并连接 WebRTC 信令服务器接收视频。[7]

这些连接方式把 Cockpit 定位在操作界面这一层，水下控制回路仍留在载具端。移动一个小组件、重新映射操纵杆按钮或更改视图，会改变意图的表达方式与证据的呈现方式。姿态估计和推进器控制继续由艇载系统承担。

QGroundControl 仍负责相邻的一部分工作。Cockpit 文档说明，现阶段的载具配置与校准由 BlueOS 和/或另一套控制站完成，QGroundControl 就是推荐选项之一。[7] 这种互操作方式很有启发：两个开放客户端共享一套协议，每个客户端覆盖的工作流程仍有差别。团队在两者之间切换时，必须重新检查操纵杆轴、经 Shift 切换的按钮功能、飞行模式选择、视频流发现、告警和校准入口。协议兼容与操作员配置可移植是两项独立条件。

水面层还提出一个清楚的故障问题：显示应用关闭后，载具下一步会做什么？答案应写在自动驾驶仪已配置的模式和故障保护里；浏览器是否迅速重连，只是随后发生的事。

MAVLink 负责地址与语义，任务另有归属

MAVLink 将整套系统连在一起，不过“总线”这个称呼容易遮住关键细节。一个 MAVLink 网络包含系统，也就是载具与地面站，还包含自动驾驶仪、相机等组件。系统 ID 和组件 ID 的范围都是 1 到 255。消息可以指定一个组件、一个系统或所有接收方；目标值为零或省略时表示广播。路由器会学习各系统和组件曾从哪里出现，再根据这些观察结果转发已寻址的流量。[6]

依靠这一模型，控制站、BlueOS 服务、传感器桥接程序和实验性自主进程可以共享载具状态，同时继续作为独立程序运行。配置风险也由此出现。错误的 ID 会让指令无处可达，意外广播会触及超出预期的接收方，组件重启则会让既有路由知识失效。开放的传输格式提高了故障可检查性，故障本身依旧存在。

在 BlueOS 中，这处衔接直接可见。它的 MAVLink Endpoints 管理器可以连接串行、UDP 和 TCP 端点，MAVLink Inspector 则显示发往水面端的消息。内部服务可以走本机回环路由，外部端点也可以指向水面端地址。BlueOS 还提供不同的路由器实现，各自有不同的转发和日志行为。[5] 这部分直接关系到运行现场：路由器的选择决定事故期间谁能看到哪些证据。

视频进一步显出了这条分界。BlueOS 可以检测 H.264 视频流、开放多个流端点、把兼容视频流重新封装为供 Cockpit 使用的 WebRTC，还能发布视频流信息，供 QGroundControl 选择。MAVLink 可以协助描述相机服务，像素数据依旧走自己的视频通道，与普通 MAVLink 遥测分开。[5] 因此，容量测试要让视频负载和指令流量同时运行：画面清晰只证明视频一侧的状态，遥测响应迅速也只覆盖消息一侧，操作员能否继续看见画面仍需单独验证。

BlueOS 负责衔接与扩展

伴随计算机是整套系统的集成工作台。BlueOS 管理固件与参数、MAVLink 端点、日志、网络测试、相机、串行桥接和受支持的声呐服务。它可以把 Ping 声呐的距离估计转换成供自动驾驶仪使用的 MAVLink DISTANCE_SENSOR 消息，同时把更丰富的传感器处理留给艇载或水面端应用。[5]

凡是需要 Linux 库、存储空间、网络服务或快速迭代的任务逻辑，都适合放在这一层，例如标记视频、协调任务载荷、转换传感器数据流，或提供自定义操作页面。BlueOS 扩展可以加入这些功能，同时让它们与飞行控制器固件分开。[4][5] 这种分工兼顾开发速度与责任归属。摄影测量服务可以决定何时拍摄；保持载具水平的能力仍须由既定控制回路独立保有。

伴随层的资源预算是有限的。占用大量 CPU 的视觉扩展、写入过量数据的日志记录器，或多台高码率相机，都会与路由和视频服务争夺资源。严谨的集成测试因此要限定实验条件：在最苛刻的并发工作负载下观察处理器负载、系缆延迟、数据包流向和视频状态，随后重启扩展，确认基础控制路径始终可用。只有资源预算和重启行为经过测试，模块化才能把故障限制在局部。

ArduSub 负责载具状态与运动

ArduSub 运行在传感器读数转化为状态估计、期望运动转化为电机输出的位置。它的模式表清楚标出了职责归属。MANUAL 由驾驶员全权控制，稳定功能关闭。ALT_HOLD 增加自动深度控制，并要求深度传感器。POSHOLD、GUIDED 和 AUTO 需要位置与深度信息；SURFTRAK 则需要测距仪，以保持载具与海床的距离。[2]

这些简短的模式名就是一份份契约。在精致的 UI 中选择 POSHOLD，仍需可信的水下位置估计作为基础。发送 GUIDED 指令时，深度依赖同样存在。在 BlueOS 中添加声呐只是接入工作的前半程；测量的坐标系、时序、有效性和数据丢失后的行为，还要以估计器与模式真正理解的形式抵达自动驾驶仪。

出于同一原因，故障保护也归这一层。ArduSub 分别记录了驾驶控制丢失、地面站联系中断、电池状态、漏水、内部压力与温度、估计器故障、碰撞检测和看门狗事件的响应方式。[3] 这些响应无法保证载具恢复，在位置未知时，水下载具也没有通用的“返航”行为。它们的作用是让每类损失对应一次载具级状态转换。水面 UI 的职责是报告这种转换，转换本身必须存在于载具端。

研究控制器需要更精确的控制权时，也要守住这条分界。Patrick Ng 和 Michael Krieg 在 BlueROV2 Heavy 上的工作，直接面对原有软件栈的工程细节。他们用实际测试改进软件在环模型，替换了适用于手动操控的控制分配方法，以支持定量自动控制，并把高层控制器放在 ROS 中。[8] 开放接缝促成了这种混合方案，也让验证责任更加清楚：新控制器仍然需要流体动力学测量、更完善的仿真，以及与特定载具对应的实验。

软件栈保持开放，责任才能明确到层

导语照片里的 MURAKUMO 框架是一个直观的实体类比。它由 5 到 8 台相机和频闪灯组成，是一套安装在 BlueROV2 上、用于阿图岛周边考察的独立摄影测量载荷。研究需求改变时，载荷可以随之更换，载具继续担任运载平台。[9] 软件扩展也应保持同样清楚的分工。

对于操作标准载具的小型野外团队，安全做法有意采取保守配置：让 ArduSub 负责稳定控制和各类失效响应，用 BlueOS 衔接各系统并运行任务载荷服务，再由 Cockpit 或 QGroundControl 在下水前验证完整的操作员工作流程。实验室若要加入自主能力，可以把规划或感知放在伴随计算机上，同时承担延迟、资源隔离、仿真器保真度，以及该进程消失时降级模式的设计责任。改动推力分配的团队则已经进入载具控制工程，需要按这一层级开展测试。

四个问题可以检验这些分界是否真实存在。Cockpit 退出时，ArduSub 会进入预期状态吗？扩展挂起时，路由和基本遥测仍然可用吗？操作员能区分视频丢失和控制丢失吗？更换水面端应用后，每一条轴、每一个按钮、每一项告警和每一次模式转换，都经过水中测试了吗？若这些“是”的依据只有台架演示，现有证据尚不足以回答实际作业问题。

这套开放体系的价值源于清晰归位：开放代码给实验留下接入点，界面、消息路由器、伴随计算机和电机控制回路则分处不同的安全域。沿着一条指令向下，再跟着一帧相机画面返回。路线会告诉你在哪里着手开发，也会标出哪些分界必须保持完整。

来源

1. ArduPilot，《Companion Computers for Sub》——官方说明载具控制、伴随计算机外设与 MAVLink 链路之间的分工。
2. ArduPilot，《Sub Modes》——官方列出的模式能力、传感器要求与模式选择参数。
3. ArduPilot，《Failsafes》——官方汇总驾驶员、GCS、电池、漏水、环境、估计器、碰撞与看门狗事件的响应。
4. BlueOS 文档，《Overview》——官方说明艇载计算机的角色、架构与扩展目标。
5. BlueOS 文档，《Advanced Usage》——介绍 MAVLink 端点与检查工具、网络测试、声呐桥接、串行服务和视频流行为。
6. MAVLink 指南，《Routing》——官方说明系统与组件寻址、广播语义、路由学习和重启处理。
7. Cockpit 文档，《Getting Started》——介绍载具发现、MAVLink2REST 与 WebRTC 连接、ROV 视图、操纵杆设置，以及与 QGroundControl 之间的校准职责分界。
8. Patrick Ng 与 Michael Krieg，《Modifications to ArduSub That Improve BlueROV SITL Accuracy and Design of Hybrid Autopilot》，Applied Sciences 14(17)，2024——出版方托管的论文，讨论控制分配、仿真保真度与 ROS/ArduSub 混合方案。
9. NOAA Ocean Exploration，《MURAKUMO on BlueROV》——介绍考察背景、载荷说明、图片署名与导语照片的源文件下载。