最近在做移动机器人视觉方案时，我遇到了一个看似普通、实际上很工程的问题：

光照。

具体一点，是 Intel RealSense D435i 在机器人从室内走向室外、经过树荫、阳光、反光地面时出现的曝光变化问题。

一开始很自然地会把问题理解成：

Auto Exposure 参数没有调好。

但继续查资料以后，会发现问题没有这么简单。

RealSense 官方明确指出，D400 系列的深度质量高度依赖左右双目图像本身的曝光质量，过曝和欠曝都会直接影响 stereo matching。其自动曝光默认根据 ROI 内像素平均强度工作，如果太阳或者太阳反射进入画面，AE 可能为了压制高亮区域而把整个场景曝光降低。官方甚至专门建议自动驾驶机器人把 AE ROI 放到图像下半部分。

更极端的情况下，曝光甚至已经没有继续下降的空间。RealSense 的光学滤镜技术文档提到，在约 100,000 lux 的强烈光照条件下，D435 即使处于最低曝光附近也可能发生传感器饱和；此时左右 IR 图像中的区域会失去纹理，最终表现为深度图上的空洞。

社区里也能找到更加直观的案例：D435 在阳光下自动把 exposure 和 gain 降到最低之后，重新回到较暗环境时，曾出现 AE 无法正常恢复的现象。

那么这时候，有没有一个软硬件协同性巨无敌，然后在视频领域流畅度非常猛，然后其产品非常常见乃至于随便都可以取得的呢？

---

一个有点“不机器人”的想法：为什么不用手机？

这里就引出了我之前一直在考虑的一个方案：

把一台支持 LiDAR 的 iPhone 直接作为机器人视觉前端。

这里的关键不是：

用 iPhone 替代 D435i。

而是：

让 iPhone 做它擅长的事情，让 D435i 做它擅长的事情。

这个区别很重要。

在消费电子领域，手机摄像头每天面对的恰恰就是机器人现在遇到的这些场景：

• 室内走向室外；
• 窗口逆光；
• 强烈阳光；
• 阴影；
• 夜间；
• 反光；
• 高频亮度变化。

Apple 在 AVFoundation 中提供连续自动曝光、曝光补偿、曝光兴趣区域以及手动 exposure duration / ISO 控制；其 Camera API 还提供 HDR/EDR 和 tone mapping 等能力。

ARKit 又在更高一层直接提供了 lightEstimate。其中的 ambientIntensity 会根据摄像头内部曝光补偿估算场景光照变化。

也就是说，对于机器人来说，iPhone 不仅可以输出一张 RGB 图像。

它实际上可以变成一个：

Visual Perception Front-end。

你好兄弟，有的，有这样硬件不算猛，但是其软硬件协同这一块无人能及的公司口牙！

我原来设计的 iPhone 数据，并不是“1 FPS 摄像头”

之前考虑这个方案的时候，有一个很容易产生误解的数字：

1 FPS。

我的设想并不是让机器人每秒只看一次。

真正的数据链大致是：

数据	计划频率
机器人自身控制	100–500+ Hz
iPhone Pose / VIO	30–60 Hz
Depth / Local Terrain	15–30 Hz
Terrain Classification	10–20 Hz
Trash Detection	5–15 Hz
发给 Ubuntu 的完整 RGB Keyframe	约 1 FPS + Event Trigger

也就是说：

1 FPS 只是完整 RGB 图像传输频率。

iPhone 自己仍然在持续感知。

我们真正希望发给 Ubuntu 的其实是：

Pose / Odometry

Depth / Local Terrain

Terrain Type

Slope

Roughness

Traversability

Preferred Foothold

Obstacle XYZ

Trash XYZ

Confidence

RGB Keyframe

而不是：

30 FPS RGB
+
30 FPS Depth
+
全部原始 IMU
+
全部中间结果

这种设计的出发点很简单：

尽量在传感器端把“像素”转换成“信息”。

---

为什么 iPhone 在这里突然变得有意思？

ARKit 本身就已经把 Camera + IMU 组合成了 Visual-Inertial Odometry。

Apple 对 World Tracking 的定义非常明确：它通过视觉惯性里程计，将运动传感器数据和摄像头视觉信息结合起来，对设备的 6DoF 位姿进行跟踪。

对于支持 LiDAR 的设备，ARKit 还可以直接提供：

sceneDepth

以及：

smoothedSceneDepth

后者会在时间维度上对深度数据进行平滑，同时携带深度置信度信息。

因此，一个 iPhone 实际上可以同时提供：

RGB
│
├── Camera ISP / Exposure
│
├── HDR / Tone Mapping
│
└── Semantic Perception
     
LiDAR
│
└── Depth + Confidence

IMU
│
└── VIO / Pose

Camera
│
└── Light Estimate

这和一颗传统机器人深度相机的设计哲学并不一样。

---

那是不是意味着 iPhone 比 D435i 强？

不是。

实际上我认为这恰恰是一个很容易走向错误结论的地方。

D435i 的价值依然非常明显。

它是一颗为机器视觉设计的 stereo depth camera。

例如 D435 的深度双目使用 global shutter，官方推荐的深度工作分辨率是 848×480，并且 librealsense 对 exposure、gain、ROI、depth preset、filter、HDR 等参数开放了相当多的底层控制。

而 iPhone 的方向恰恰相反。

Apple 帮开发者做掉了大量底层工作，但是与此同时：

很多底层过程也被封装起来了。

于是二者形成了一种很有意思的对比：

	D435i	iPhone
设计目标	Robot / Machine Vision	Consumer Vision / AR
RGB ISP	相对基础	高度集成
强弱光处理	需要工程调参	系统高度参与
Depth	Stereo	LiDAR / ARKit Depth
Depth 底层控制	强	较弱
VIO	需要自己构建	ARKit 已提供
IMU 融合	自己完成	ARKit 内建
Light Estimate	无直接高级接口	ARKit 提供
Semantic	外部模型	可直接运行端侧模型
参数透明度	高	低
系统开放程度	高	相对封闭

所以，与其讨论：

iPhone VS D435i，谁更强？

我觉得可能更有价值的问题是：

管他这的那的，你就说能不能用吧

---

一个可能更合理的系统

我目前更倾向于下面这种结构：

              ┌───────────────┐
              │    iPhone     │
              │               │
              │ RGB + LiDAR   │
              │ IMU + ARKit   │
              └───────┬───────┘
                      │
        ┌─────────────┼─────────────┐
        ↓             ↓             ↓
      VIO          Semantic      Lighting
     Pose           Terrain        State
        │             │             │
        │        Trash / Stairs     │
        │             │             │
        └──────┬──────┴──────┬──────┘
               ↓             ↓
          Structured      RGB Keyframe
             Data            1 FPS
               │
               ↓
           Ubuntu / ROS2
               ↑
               │
        D435i Depth Stream
               ↑
               │
          ┌────┴─────┐
          │   D435i  │
          │  Stereo  │
          └──────────┘

这里 D435i 不再承担：

“整个机器人必须依靠我的 RGB 看懂世界。”

它更像一个：

专用几何传感器。

而 iPhone 则负责：

视觉理解 + 光照适应 + VIO + 较高层感知。

---

甚至可以再往前一步：让 iPhone 帮 D435i 判断“现在是什么光”

这是我觉得最值得做实验的部分。

ARKit 已经能给出 ambientIntensity。

AVFoundation 本身又可以读取和控制 exposure。

那么机器人完全可以建立一个：

Lighting State Estimator

例如：

NORMAL

INDOOR_DARK

OUTDOOR

STRONG_SUNLIGHT

BACKLIGHT

SUN_SHADE_TRANSITION

REFLECTIVE_SURFACE

然后根据状态动态改变 D435i。

例如：

iPhone
检测到亮度快速上升
      │
      ↓
SUNLIGHT TRANSITION
      │
      ↓
Ubuntu
      │
      ├─ D435i AE ROI → Ground
      │
      ├─ Exposure limit ↓
      │
      └─ Gain limit ↓

而当出现：

Bright + Dark

同时存在时：

D435i → HDR Depth

RealSense 本身已经支持 stereo HDR，也就是交替使用不同 exposure/gain 的帧来扩大可利用动态范围。

这样一来，iPhone 就不是单纯的另一个摄像头。

它实际上变成了：

D435i 的环境状态观察器。

---

为什么这个思路可能特别适合慢速机器人？

这里还有一个非常重要的任务背景。

我的目标并不是：

机器人 5 m/s 高速奔跑

而更接近：

沿预先规定的路线行走
        ↓
普通地面
        ↓
楼梯
        ↓
不平路面
        ↓
鹅卵石
        ↓
垃圾 / 障碍物

而且：

不追求完成时间，只要求稳定完成。

这会彻底改变视觉系统的设计逻辑。

高速机器人必须极端关注：

Latency
FPS
Synchronization

但是慢速任务可以接受：

发现复杂场景
      ↓
减速
      ↓
获取更多感知
      ↓
确认 terrain
      ↓
切换 locomotion policy
      ↓
通过

这实际上允许机器人主动改变自己的“时间预算”。

---

D435i 曝光问题反而揭示了一个更大的问题

RealSense 官方给出的 D435 典型曝光数据其实很有意思。

从 100,000 lux 的阳光，到只有约 1 lux 的极暗环境，最佳曝光时间跨度可以从极短曝光一路增长到约几十毫秒量级。

这说明：

Camera
不是一个恒定质量的数据源。

很多机器人算法默认：

Image_t
Image_t+1
Image_t+2

质量大致相同

现实却可能是：

Frame 1
Excellent

Frame 2
Excellent

机器人走过门口

Frame 3
Overexposed

Frame 4
Dark

Frame 5
AE adjusting

Frame 6
Normal

这时候再好的下游：

YOLO
Segmentation
VLM
SLAM
Terrain Network

都只能处理已经受到破坏的输入。

所以也许机器人视觉系统真正缺少的不是：

更强的 perception model。

而是一层：

Perception Quality Manager

它实时回答：

我现在看到的东西靠谱吗？

RGB 是否过曝？

Depth valid ratio 是多少？

IR 有没有 saturation？

当前 lighting state 是什么？

VIO confidence 是否下降？

不同传感器现在谁更可信？

---

最终可能不是 Sensor Fusion，而是 Confidence Fusion

这也是我目前最感兴趣的一点。

传统 Sensor Fusion 经常写成：

Camera + IMU + Depth
        ↓
      Fusion

但真正复杂环境中的系统也许应该是：

iPhone RGB
confidence = 0.95

iPhone Depth
confidence = 0.72

D435i Depth
confidence = 0.31

VIO
confidence = 0.93

Terrain Model
confidence = 0.88

然后：

             Perception Manager
                    │
      ┌─────────────┼──────────────┐
      ↓             ↓              ↓
    Geometry      Semantic        Pose
      │             │              │
      └─────────────┴──────────────┘
                    ↓
                 Planner

例如强烈阳光导致 D435i stereo saturation：

D435i confidence ↓

那就暂时提高：

iPhone LiDAR
+
Temporal Terrain Estimation

的权重。

进入室内之后：

D435i confidence ↑

再重新增加 D435i depth 权重。

这比永远相信某一个固定传感器，也许更接近真正鲁棒的 embodied perception。

---

但这个方案还有很多坑

这篇文章只能算抛砖引玉，因为真正实现以后很可能马上遇到几个问题。

第一是同步。

iPhone 和 D435i 是两个完全独立的时钟系统。

如果机器人运动明显：

iPhone(t)

D435i(t + Δt)

可能对应完全不同的空间状态。

因此必须认真处理：

timestamp

extrinsic calibration

time synchronization

pose interpolation

第二是 Apple 的封装。

ARKit 给我们的数据非常好用，但并不意味着我们能够访问所有底层参数。

例如 smoothedSceneDepth 本身就是经过时间平滑的数据。

对于 AR，这是优点。

对于高速机器人：

它可能意味着额外的 temporal behavior。

必须实际测试，而不能直接认为“更平滑 = 更好”。

第三是：

手机不是工业传感器。

散热、持续运行、供电、接口稳定性、系统调度、iOS 生命周期，全部需要验证。

所以这个方案目前绝对不能说：

iPhone 可以替代 D435i。

更准确的表达应该是：

iPhone 可能是一个被机器人领域低估的高集成视觉协处理器。

---

我下一步更想做的实验

与其继续理论讨论，我觉得最简单的方法就是做一条测试路线：

Indoor
  ↓
Dark Corridor
  ↓
Glass Door
  ↓
Outdoor Sunlight
  ↓
Shadow
  ↓
Direct Sun
  ↓
Reflective Floor
  ↓
Stairs
  ↓
Cobblestone

同时记录：

iPhone RGB

iPhone exposure / ISO

ARKit ambientIntensity

ARKit Pose

iPhone sceneDepth

iPhone Depth Confidence

D435i RGB

D435i Left IR

D435i Right IR

D435i Exposure

D435i Gain

D435i Depth

然后真正比较几个指标：

RGB overexposure ratio

RGB underexposure ratio

Depth valid pixel ratio

Depth temporal variance

Exposure convergence time

VIO tracking state

Terrain classification confidence

Obstacle detection confidence

尤其测试：

室内 → 阳光

和：

阳光 → 阴影

两个瞬间。

因为真正的问题可能根本不是：

静态状态谁的画质更好。

而是：

谁能更平稳地穿过状态变化。

---

最后

D435i 依然是一颗非常好的机器人深度相机。

iPhone 也绝对不是一颗工业机器人传感器。

但这两个设备恰好代表了两种完全不同的发展路线：

D435i

Sensor
 ↓
Raw Data
 ↓
Engineer
 ↓
Algorithm

以及：

iPhone

Sensor
 ↓
ISP
 ↓
Sensor Fusion
 ↓
OS Framework
 ↓
Structured Perception

机器人领域过去更习惯第一种。

但随着端侧算力、手机 ISP、LiDAR、VIO 和端侧 AI 越来越成熟，也许未来值得重新思考一个问题：

机器人究竟需要的是更多“原始传感器”，还是更好的“感知节点”？

至少对于一个并不追求高速、目标只是稳定走完复杂路线的机器人来说，我觉得：

iPhone + D435i 并不是一个特别荒唐的组合。

甚至反过来讲——

D435i 在强弱光切换中暴露出来的问题，也许恰好给了我们一个机会，去重新思考机器人视觉系统应该怎么分工。

这目前只是一个工程假设。

下一步最有价值的事情，不是继续争论：

“手机能不能做机器人视觉？”

而是把 iPhone 和 D435i 并排装在机器人上，

走一次。

把所有数据记录下来。

然后让数据回答这个问题。