真的把 iPhone 用在机器人视觉上了：第一组数据比预想更有意思，但 60 FPS 也救不了运动模糊
上一篇文章里，我讨论了一个最初看起来有点“反常规”的想法：
机器人视觉一定要让 RealSense 这样的 RGB-D 相机同时负责 RGB 和 Depth 吗？
这个问题来自一个非常实际的使用体验。RealSense D435i 的深度能力对于机器人来说很好用，但 RGB 在复杂光照环境下并不总是让人满意。尤其当机器人从室内走向室外、经过玻璃门、树荫、强光或者高反射地面时，自动曝光的变化很容易直接影响后面的视觉识别。
于是我开始考虑另外一种分工：
D435i 做它最擅长的几何和深度，iPhone 做它最擅长的 RGB 成像。
真正吸引我的并不是“iPhone 摄像头参数更高”，而是 Apple 从 Sensor、ISP、自动曝光、HDR、IMU 到 ARKit 做了大量软硬件协同。
但上一篇更多还是假设。
这一次，我决定先不继续往系统架构上堆东西。
不接机器人，不接 D435i，也先不考虑 Livox。
先真正拿 iPhone 录一次，然后看看它到底能吐出什么。
1. 先做一个最小实验
为了快速拿到 RGB、Depth、Camera Pose 和 IMU，我这次直接使用了 Stray Scanner。
这不是一个严格的机器人测试。
整个采集时间只有大约 9.4 秒，主要是手持手机在桌面附近移动和旋转，场景中有电脑显示器、桌面、键盘等物体。
它没有楼梯，没有鹅卵石，没有室内走向室外，也没有机器人落脚产生的冲击。
换句话说：
这次实验不是为了证明整个方案成立，而是先回答一个更基础的问题：iPhone 作为机器人视觉前端，能不能稳定地产生一套可用的数据？
把 Stray Scanner 导出的数据拆开之后，我拿到了：
RGB
- Resolution: 1920 × 1440
- Codec: HEVC
- Frame rate: 60 FPS
Depth
- Resolution: 256 × 192
Camera Pose
- ≈ 60 Hz
IMU
- ≈ 100 Hz
Other
- Depth Confidence Map
- Camera Intrinsics
整段采集中，RGB 和 Pose 都有 564 帧，IMU 大约有 940 个采样。
这一点其实比我最开始预期的更有意思。
因为这意味着，从数据结构上看，iPhone 并不只是：
Camera → Image
而已经非常接近：
RGB + Depth + Pose + IMU + Intrinsics + Confidence
也就是说，如果以后自己写一个 iOS App，这套数据完全可以重新组织成机器人更加熟悉的形式，例如：
/image
/depth
/pose
/imu
/camera_info
然后通过网络送进 RK3588S、Jetson 或 ROS。
所以第一件被验证的事情其实非常简单：
这条 Sensor Frontend 的数据链是成立的。
2. ARKit 的位姿输出比我预期稳定
接下来我首先看的不是 RGB，而是 Camera Pose。
这段数据里，ARKit Pose 的实际输出频率基本稳定在：
≈ 60 Hz
最大帧间隔也基本保持在：
≈ 16.7 ms
IMU 则大约是：
≈ 100 Hz
更有意思的是，我把 Camera Pose 相邻两帧的旋转变化换算成角速度，再和陀螺仪数据进行比较。
两者的变化趋势高度一致。
而在这段手持采集中，手机最快的旋转速度已经达到大约：
74°/s
但没有看到特别明显的 Pose 跳变或者 Tracking 突然崩掉。前面的数据分析同样显示，Pose 流约 60 Hz、IMU 约 100 Hz，而且快速手持旋转期间 VIO 与陀螺仪保持了很高的一致性。
这当然不能得出：
“ARKit 可以直接替代机器人的主定位系统。”
这离现在的数据还非常远。
手持转动和真正的双足机器人完全不是一回事。
机器人上会有：
- 周期性的身体摆动；
- 落脚冲击；
- 高频 Pitch / Roll；
- 机械结构振动；
- 室外长距离运动；
- 视觉遮挡；
- 长时间累计漂移。
但至少从第一轮结果看，ARKit 的状态输出没有表现出明显的脆弱性。
因此我现在更愿意把它理解为：
一个非常有价值的辅助状态源，或者独立于机器人本体传感器之外的视觉看门狗。
即使未来真正的定位交给 LiDAR + LIO，ARKit 仍然可以作为一套完全独立的视觉参考。
3. 第一眼看 RGB：确实很“iPhone”
接下来才是我真正关心的 RGB。
这段室内录像里其实存在比较大的局部亮度差异。
例如电脑显示器明显比桌面和周围环境亮很多。
从关键帧上看，iPhone 的输出整体比较稳定。
没有出现一种非常典型的情况：
显示器太亮 → 整个环境突然变暗
也没有出现：
为了提亮暗部 → 高亮区域整片炸白
当然，高亮区域仍然会有像素达到饱和。
这是很正常的。
我也不想因为一段室内录像就直接得出：
“iPhone 的 HDR 已经解决机器人复杂光照问题。”
实际上，这次测试根本没有真正覆盖上一篇文章里我最想测试的东西。
真正需要测试的应该是一条明确的光照变化路线，例如：
- 室内较暗区域
- 正常室内环境
- 接近玻璃门或出口
- 进入室外强光
- 进入树荫
- 再次进入阳光直射
- 返回室内
所以这一次只能说：
iPhone RGB 的初步表现符合预期，但还没有验证核心假设。
这个区别很重要。
现在的数据最多只能说明：
值得继续做。
而不是：
已经证明了。
4. 然后出现了这次测试里最有意思的东西
原本我对 60 FPS 有一个很自然的预期：
帧率这么高，机器人运动时图像应该会比较稳定。
结果把图像清晰度和手机旋转速度放到一起之后，事情并没有这么简单。
大致可以看到这样一个趋势：
| 手机角速度 | 图像清晰度趋势 |
|---|---|
| < 10°/s | 很清晰 |
| 10–20°/s | 开始下降 |
| 20–40°/s | 明显下降 |
| > 40°/s | Motion Blur 很明显 |
这段测试里，低速运动时的清晰度指标可以达到大约：
580–670
但当手机快速旋转到：
67–74°/s
附近时，有些帧已经下降到：
90–100
上一轮数据分析也观察到了同样的问题：室内环境下，转速低于约 10°/s 时画面明显更清晰，而超过 40°/s 后清晰度显著下降；ARKit VIO 仍然稳定，但 RGB 已经明显受到影响。
这给了我这次实验里最重要的一个认识：
60 FPS 不等于短曝光。
60 FPS 只意味着：
1 / 60 ≈ 16.7 ms
也就是相机每隔大约 16.7 ms 输出一帧。
但它并不意味着：
每一帧的 Exposure Duration 都足够短。
如果当前环境较暗，自动曝光仍然可能使用相对较长的曝光时间。
这时即使最终输出 60 FPS，单帧内部仍然可能产生明显的运动拖影。
5. 对机器人来说，这可能比 FPS 本身更加重要
这一点让我重新考虑了之前纠结的一个问题：
到底应该使用 30 FPS 还是 60 FPS？
一开始很容易认为：
60 FPS 一定比 30 FPS 更适合运动中的机器人。
但真正装上机器人以后，我们面对的过程可能是：
- 机器人落脚；
- 身体产生瞬时 Pitch / Roll；
- 相机产生快速角运动；
- RGB 出现 Motion Blur；
- Object Detection Confidence 下降；
- 最严重时甚至直接漏检。
这种时候，真正决定 RGB 能不能用于识别的，可能不是 30 和 60 这个数字，而是：
Exposure Duration。
例如下面两个方案：
方案 A
30 FPS
+
Maximum Exposure ≈ 1/120 s
方案 B
60 FPS
+
完全自动曝光
到底哪一个更适合机器人？
我现在反而不会直接选方案 B。
因为对视觉检测模型来说：
有一点 ISO 噪声，很多时候比一整帧 Motion Blur 更容易处理。
这也意味着以后真正的机器人 iOS App 不能只是：
打开 Camera → 开始录像
而需要主动控制：
- HDR；
- Auto Exposure；
- Maximum Exposure Duration；
- Focus；
- Exposure Bias。
这里也暴露出 Stray Scanner 的一个限制：
它非常适合快速做传感器数据验证，但最终机器人 App 还是需要自己写。
6. 一个容易忽略的问题：相机内参也在变化
这次数据里还有另外一个比较容易忽略的现象。
Camera Intrinsics 里的焦距参数 fx 并不是完全固定的。
在这段短短 9 秒左右的测试中，它出现了大约 1.9% 的变化。之前的数据分析也记录到了这一点，并认为自动对焦是需要重点考虑的因素。
如果只是：
RGB → YOLO → Bounding Box
这个影响并不大。
但如果未来要做：
iPhone RGB + D435i Depth → 3D Object Position
事情就不一样了。
因为从图像像素恢复三维射线时，会使用类似：
X = (u - cx) × Z / fx
这样的关系。
如果内参一直变化，而机器人系统还把它当成固定相机，最后得到的 XYZ 一定会出现误差。
因此正式机器人版本至少要做两件事情之一：
方案 A：锁定 Focus
尽量让相机工作状态稳定。
方案 B：每帧发送 Camera Intrinsics
让机器人端永远使用当前真实参数。
我现在更倾向于：
锁焦，同时仍然随帧发送 Intrinsics。
机器人视觉里，“我认为它不会变”通常没有“我把它记录下来”可靠。
7. Depth 数据也给了我一个提醒
这次 Stray Scanner 还输出了：
256 × 192
的 Depth。
如果只看 Depth Map，会发现几乎所有像素都有数值。
第一眼很容易产生一种感觉：
很不错，Depth 很完整。
但是再看 Confidence Map，情况马上变了。
高置信度区域的比例并不是始终很高，平均大约只有一半左右，最差的时刻甚至非常低。已有分析显示，conf=2 高置信像素平均约 50.7%，最低约 8.6%。
这让我觉得之前提出的一个想法反而更加重要：
有 Depth，不等于这份 Depth 值得相信。
机器人真正需要的不应该只是：
depth = 0.83 m
而应该同时知道：
depth = 0.83 m
confidence = ?
不过这一轮也不能过度解读。
因为手机离桌面非常近，场景深度中位数大概只有：
0.3–0.6 m
这和真正机器人使用时：
1 m
2 m
3 m
看楼梯和路面完全不是同一个工况。
因此现阶段我不会用这组数据评价 iPhone LiDAR 到底适不适合机器人地形感知。
它只告诉我：
下一次必须认真看 Confidence，而不能只看 Depth 是否有值。
8. 所以这次实验到底证明了什么？
如果现在直接问：
“iPhone 机器人视觉方案成功了吗？”
我的答案会是：
还没有。
但如果问题是：
“这条路值得继续吗？”
我的答案已经非常明确：
值得。
因为这轮最小实验已经证明了几件很基础、但很关键的事情：
| 项目 | 当前结果 |
|---|---|
| RGB 60 FPS | ✓ |
| Camera Pose ≈ 60 Hz | ✓ |
| IMU ≈ 100 Hz | ✓ |
| Depth + Confidence | ✓ |
| Camera Intrinsics | ✓ |
| 数据链连续性 | ✓ |
而且 ARKit VIO 在快速手持运动中表现出了不错的稳定性。
与此同时，它也非常及时地暴露出了问题：
- Motion Blur；
- Exposure Strategy；
- Intrinsics Variation；
- Depth Confidence。
这其实比一切都“看起来很好”更有价值。
因为我们现在终于知道下一轮实验应该测什么了。
9. 下一步：不再测试“手机能不能录”，而是测试“视觉还能不能认”
下一阶段我准备把实验推进到：
iPhone → RGB → RK3588S → RKNN → YOLO
也就是说，RK3588S 不负责 SLAM，不负责 Nav2，也暂时不负责复杂机器人逻辑。
第一阶段只做三件事情：
- 接收 iPhone RGB；
- 运行视觉模型；
- 记录识别结果。
真正需要看的不再是：
“画面好不好看？”
而是：
- Detection Confidence；
- Miss Rate；
- Inference Latency。
更具体一点，我希望下一次测试路线变成：
- 室内暗处；
- 正常室内环境；
- 接近玻璃门；
- 走到室外强光；
- 进入树荫；
- 再次进入直射阳光；
- 重新进入室内。
画面中放置几个固定识别目标，例如：
- bottle；
- box；
- bag。
然后同时记录：
- Saturated Pixel Ratio；
- Dark Pixel Ratio；
- Blur Score；
- Angular Velocity；
- Detection Confidence；
- Miss Rate；
- AE Recovery Time。
这样我们就能第一次真正回答上一篇文章提出的问题：
当光照突然发生变化时，Apple 的成像链能不能让机器人视觉识别保持稳定？
而不是仅仅：
“iPhone 拍出来看起来比较好。”
10. 30 FPS 和 60 FPS 也应该在下一轮一起测
这次实验让我觉得这一组对照非常有必要。
Test A
1080p
30 FPS
HDR
限制最长 Exposure
Test B
1080p
60 FPS
HDR
限制最长 Exposure
然后在完全相同的运动和光照条件下比较：
- Blur；
- Noise；
- Detection Confidence；
- Miss Rate；
- Thermal；
- Latency。
我现在的猜测是：
对一个不追求高速、而追求稳定完成任务的机器人，30 FPS + 更合理的曝光控制，很可能已经足够。
而 60 FPS 真正有价值的场景，可能不是普通行走，而是：
- 落脚冲击；
- 身体快速转向；
- Camera 快速 Pitch / Roll。
但这是下一轮数据应该回答的问题，而不是现在凭直觉决定。
11. 从“能不能用”到“什么时候值得相信”
做完这次实验以后，我对这个方案最大的认识变化其实不是：
iPhone 果然很好。
而是：
机器人感知最难的问题可能不是获得数据，而是知道当前这份数据到底有多可信。
RGB 会因为 Motion Blur 退化。
Depth 会有 Confidence。
ARKit 会有 Tracking State。
光照会改变曝光。
机器人运动又会不断改变相机状态。
所以未来真正有意思的部分可能不是简单地：
RGB + Depth + IMU
而是进一步构建：
Perception + Perception Quality
机器人除了知道：
“前面有一个瓶子。”
还应该知道：
“现在图像没有过曝、运动模糊较低，这个瓶子的识别结果值得相信。”
或者：
“当前 RGB 因为快速转动已经明显模糊，先不要根据这一帧做高层决策。”
这和上一篇里我提到的 Perception Quality Manager，开始慢慢从一个架构上的想法变成了真实数据里能看到的问题。
写在最后
上一篇文章更多是在问：
iPhone 能不能成为机器人视觉系统的一部分？
这一轮实验至少让我把问题推进了一步。
现在我已经不太担心：
“iPhone 能不能把这些数据拿出来？”
因为 RGB、Depth、Pose、IMU、Intrinsics 和 Confidence 都已经真实拿到了。
新的问题变成了：
这些数据在什么条件下值得相信？
而第一次实测里最有意思的结果，恰恰不是 60 FPS 有多流畅。
而是：
60 FPS 也救不了不合适的曝光策略。
对于机器人视觉来说，这可能比单纯追求更高帧率重要得多。
下一步，就是把 iPhone 接到 RK3588S 上。
然后不再只看视频。
直接看机器人视觉模型，在真实光照变化和运动模糊下，到底还能不能稳定识别。