在河道机器人这种资源极度受限的场景下，光靠地理航点根本解决不了避障问题，你得让机器人真能“看懂”水面边界和障碍物。

最近看到 arXiv 上刚出的这篇关于 PAANI 的论文（arXiv:2609.22353v1），这套架构解决的是一个很硬核的问题：如何在像 Arduino UNO Q 这种计算能力几乎可以忽略不计的边缘设备上，既能跑视觉感知，又能给出一套“说得清理由”的引导逻辑。

这种低功耗设备是怎么跑视觉感知的

很多时候我们聊边缘 AI，默认都是在跑 Jetson Nano 或者更强的模块，但 PAANI 走的是极端的低功耗路线。它把感知任务拆成了两个部分，然后强行塞进了 Arduino UNO Q 里：

• 目标检测： 用的是经过项目训练的 YOLO11n 检测器。
• 语义分割： 配了一个定制的 MobileNetV3 Small 分割器，专门用来识别水面边界。

为了能让这两个模型在如此简陋的硬件上跑起来，开发者把它们都转成了 FP32 的 ONNX 格式。这两套模型加起来占用的空间也就 14.817 MB。虽然看起来不大，但在这种级别的单片机上跑视觉模型，每一兆字节都是在跟硬件极限博弈。

实际测试的表现到底怎么样

我仔细看了下论文里的实测数据，这套架构在精度和延迟之间做了一个挺有意思的权衡。

模型精度方面：

• 检测器： 在 0.5 IoU 下，检测器的测试 mAP 是 0.7388；如果看那个导出的矩形 ONNX 版本，验证集的 mAP 是 0.7367。
• 分割器： 语义分割的表现非常惊人，验证集的 mIoU 达到了 0.9750。

运行效率（这是最关键的）：
在配置为 0.5 Hz 的频率下，通过对 Arduino UNO Q 进行 5 分钟的录制测试，得到的流水线延迟中位数是 467.8 ms，而 95% 分位数的延迟是 580.3 ms。

你要知道，在河道这种动态环境下，接近 600 毫秒的延迟意味着机器人看到的画面和实际物理世界之间存在巨大的“时间差”。虽然作者通过时间戳对齐的证据融合（timestamp aligned evidence fusion）来缓解这个问题，但在高速运动场景下，这种延迟依然是个巨大的坑。

为什么它强调“可解释性”

PAANI 最有意思的点不在于它跑得有多快，而在于它的“决策逻辑”不是一个黑盒。

传统的机器人如果识别到一个障碍物，它只会吐出一个“左转”或者“停止”的指令。但在 PAANI 的架构里，它会输出一个“显式走廊策略”（explicit corridor policy）。这个策略会结合表面标签、检测到的物体、紧急程度以及掩码的不确定性（mask uncertainty）来做决定。

最硬核的是，它给出的每一个最终建议都会暴露它的“证据”和“政策理由”。比如它告诉你“建议左转”，它会告诉你是因为看到了某个特定的物体，并且当前的分割掩码置信度很高。这种设计对于调试非常有帮助，你一眼就能看出是模型看错了，还是逻辑判断错了。

避不开的坑和局限性

论文里也没吹牛，实测中也暴露了几个非常具体的工程问题，这对于我们做机器人开发的人来说很有参考价值：

1. 黑场误判： 当输入图像变成全黑时，模型会出现误分类的情况。这在光照剧烈变化或者传感器失效时是致命的。
2. 采样率不匹配： 这是一个很典型的系统集成问题。由于采样率不匹配，导致诊断用的“表观运动估计器”（apparent motion estimator）无法收集到足够的证据。
3. 场景局限： 作者明确强调了，这些结果证明的是模型精度和板载执行的能力，并不代表它已经在真实水域验证了碰撞规避的安全性。

这套方案通过 ROS 2 接口连接到 Gazebo 仿真环境进行测试，使用了 10,000 张 WaterScenes 图像进行四分类检测训练，以及 1,127 张 MaSTr1325 图像进行分割训练。

如果你也想在极其低端的 MCU 上折腾视觉避障，PAANI 提供的这种“检测+分割+可解释策略”的组合思路，确实比单纯堆模型要靠谱得多。