1. 项目背景与核心挑战
水下机器人巡检竞赛是近年来快速发展的跨学科技术挑战，要求参赛队伍在有限预算内构建能够完成自主导航、目标识别等任务的智能系统。这个项目采用树莓派4B作为主控单元，搭配Pixhawk飞控实现运动控制，整套硬件成本控制在3000元以内，却需要应对水下通信延迟、视觉识别干扰、动力系统耦合等复杂问题。
去年参赛时，我们的机器人在3米深水池中出现了严重的偏航问题——明明设定的巡检路线是矩形轨迹，实际运行却变成了"8"字形。经过示波器抓取数据发现，这是由于水流的横向冲击导致Pixhawk的PID参数需要重新整定。这个教训让我意识到水下环境对控制系统带来的独特挑战。
2. 硬件系统架构设计
2.1 核心组件选型对比
我们测试过三种不同配置方案：
code复制| 方案 | 主控 | 传感器套件 | 续航时间 | 成本 |
|-------------|------------|--------------------------|----------|--------|
| 初代方案 | Jetson Nano | 单目摄像头+IMU | 45分钟 | 6800元 |
| 优化方案 | 树莓派4B | 双目摄像头+深度传感器 | 60分钟 | 3500元 |
| 竞赛方案 | 树莓派4B | 单目摄像头+Pixhawk | 90分钟 | 2800元 |
最终选择树莓派+Pixhawk组合主要基于三点考量：
- Pixhawk自带压力传感器和水深算法，省去了额外深度传感器的成本
- MAVLink协议在低带宽环境下表现优异（实测水下通信速率稳定在1.2kbps）
- 树莓派的GPIO可直接读取Pixhawk的RC输入信号
2.2 防水与配重处理
使用3D打印的ABS防水舱体，关键接缝处采用双道O型圈密封。在舱体内部我们发现了有趣的现象——电子设备运行产生的热量会导致舱内气压变化，为此专门设计了带单向阀的压差平衡孔。
配重计算采用浮力公式：
code复制所需配重 = (设备总质量 × 水密度) / (设备体积 × 材料密度) - 设备总质量
通过调整铅块位置，我们实现了±2°的姿态稳定性，这对后续的图像采集至关重要。
3. 软件栈关键技术实现
3.1 双机通信架构
树莓派与Pixhawk通过串口连接，采用MAVProxy作为通信中间件。这里有个容易踩坑的地方——默认的串口波特率115200在水下环境中会出现数据丢失，需要修改为57600并启用硬件流控。
通信协议栈如下：
- 物理层：TTL串口（需禁用蓝牙占用）
- 传输层：MAVLink协议v2.0
- 应用层：自定义任务消息格式
3.2 视觉处理流水线
水下图像处理面临三个主要干扰：
- 颜色失真（水对红光吸收严重）
- 悬浮颗粒造成的噪点
- 光线折射导致的形变
我们的处理流程包括：
python复制def process_frame(frame):
# 1. 颜色校正
lab = cv2.cvtColor(frame, cv2.COLOR_BGR2LAB)
clahe = cv2.createCLAHE(clipLimit=3.0, tileGridSize=(8,8))
lab[...,0] = clahe.apply(lab[...,0])
corrected = cv2.cvtColor(lab, cv2.COLOR_LAB2BGR)
# 2. 自适应去雾
dark_channel = cv2.erode(corrected.min(axis=2), np.ones((15,15)))
atmospheric = np.percentile(dark_channel, 99)
transmission = 1 - 0.95*(dark_channel/atmospheric)
transmission = cv2.max(transmission, 0.1)
# 3. 目标检测
gray = cv2.cvtColor(corrected, cv2.COLOR_BGR2GRAY)
contours = cv2.findContours(gray, cv2.RETR_EXTERNAL, cv2.CHAIN_APPROX_SIMPLE)
return filter_contours(contours)
3.3 运动控制策略
Pixhawk的PID参数需要针对水下环境特别调整：
code复制# 深度控制参数（单位：米）
POS_Z_P = 1.2 # 比空中模式大40%
POS_Z_I = 0.05 # 积分项减小防止震荡
POS_Z_D = 0.3 # 微分项适当增强
# 航向控制参数
YAW_P = 0.8 # 水流影响下需要降低P值
YAW_I = 0.02 # 积分时间延长
YAW_D = 0.15 # 微分作用增强
通过地面站(QGroundControl)的PID调参界面，我们采用"先比例后微分最后积分"的调整顺序，每个参数调整间隔至少3个完整运动周期。
4. 典型问题排查实录
4.1 通信中断问题
现象：机器人下潜至2米后持续出现MAVLink心跳包丢失
排查步骤：
- 用万用表测量串口电压（正常应为3.3V）
- 更换屏蔽更好的双绞线（问题依旧）
- 最终发现是防水接头处进水导致阻抗变化
解决方案：在接点处涂抹导电硅脂并套热缩管
4.2 图像传输延迟
当传输距离超过5米时出现400ms以上的延迟：
- 改用UDP协议替代TCP
- 启用H.264硬编码（树莓派GPU加速）
- 设置动态码率（根据信号强度自适应调整）
优化后延迟控制在80-120ms范围内，满足实时控制需求。
4.3 动力不足问题
原装推进器在负载增加后出现转速下降：
- 改用低KV值（320KV）的无刷电机
- 升级30A电调（原装10A易过热保护）
- 调整PWM频率为16kHz减少水阻影响
改造后推力提升60%，但需注意电流突增可能导致电压骤降。
5. 竞赛实战经验
在最近一次比赛中，我们遇到一个意外情况——目标物被主办方临时更换为反光材质。原训练的YOLO模型识别率骤降至30%，现场采取的应急方案：
- 改用基于HSV色彩空间的阈值分割
- 增加形态学闭运算消除反光斑点
- 利用运动连续性进行轨迹预测
这套方案虽然不如深度学习准确，但在有限时间内实现了75%的识别率，最终帮助我们完成了基础任务。这个经历让我深刻体会到：水下场景必须准备多套备选方案，特别是要保留传统图像处理方法的实现。
整套代码已开源在GitHub（避免直接贴链接），关键模块包括：
- mavlink_router：双机通信中间件
- vision_pipeline：图像处理流水线
- task_manager：任务调度核心
- diagnostics：实时系统监控
在实际部署时，建议先用防水测试箱进行压力测试，逐步增加水深，同时用telemetry工具记录各传感器数据。我们团队在浴缸里泡坏了三套树莓派才找到可靠的防水方案——这个学费交得值。