这份记录测了什么
这是我在 RDK X3 双目套件上留下的测量记录，主要看近距离场景，这次整理没有重跑，先作为实验记录来看。
Hardware / 板子和摄像头
这套设备用了两只 USB 摄像头，左边通过 ROS 发布图像，右边用 OpenCV 采集。请求的帧率和实际看到的帧率有差别，我把它们分开记在表里。
| Item | Value |
|---|---|
| Platform | Horizon RDK X3 |
| Architecture | aarch64 |
| OS | Ubuntu 22.04 |
| Cameras | 2 × USB 摄像头 |
| LEFT | Camera ID 9，/dev/video9，由 hobot_usb_cam 发布 |
| RIGHT | Camera ID 8，/dev/video8，通过 OpenCV V4L2 采集 |
| Capture | 640 × 480 MJPG，请求 25 FPS |
| Observed camera/topic rates | RIGHT 报告 30 FPS；多次运行中 LEFT ROS 图像约 19–29 FPS |
Calibration / 先把双目标定好
我用棋盘格做双目标定，读入的 51 组图像都有效。后面的图像校正、视差、距离计算和检测框测距，用的就是这组标定参数。
| Metric | Result |
|---|---|
| Chessboard | 11 × 8 内角点 |
| Square size | 3 mm |
| Loaded stereo pairs | 51 |
| Valid stereo pairs | 51 / 51 |
| Stereo RMS | 1.505858 px |
| Reprojection error | 1.405942 px |
| Epipolar error | 0.769252 px |
| Estimated baseline | 0.016843 m |
| Physical baseline | 约 16 mm |
| Rectified focal length | 约 576.703 px |
Depth / 距离读数先从近处看
我先拿近处的目标看测距是不是在合理的量级，留下了这些读数：
- 目标在约 30 cm 处时，读到过
0.299 m、0.302 m和0.304 m。 - 另一次验证中，目标在约 26 cm 处，读数稳定在
0.25–0.26 m左右。 - 纹理太少或者匹配不可靠时，界面显示
NO_DEPTH或N/A，这一帧就没有距离。
多个距离的系统测量
要比较不同距离下的误差，还得把目标形状、纹理、光照、样本数量、预热时间、取样位置和无效帧的处理方法统一好。下面这张表当时还没填，TBD 就是待测。
| Ground Truth | Measured | Abs Error | Relative Error | Valid Rate |
|---|---|---|---|---|
| TBD | TBD | TBD | TBD | TBD |
YOLO / 检测放到 BPU 上
目标检测用的是板上运行的 YOLOv8n，输出通常在 20 FPS 左右，不同次运行会有波动。表里的类别是当时实跑时见到的几个例子。
| Item | Observation |
|---|---|
| Model | YOLOv8n |
| Model path | /opt/hobot/model/x3/basic/yolov8n_640x640_nv12.bin |
| Runtime | Horizon BPU |
| Topics | 从 /image 到 /hobot_dnn_detection |
| Message types | sensor_msgs/msg/CompressedImage 和 ai_msgs/msg/PerceptionTargets |
| Observed output rate | 约 20 FPS，多次运行间有波动 |
| Example observed classes | person、laptop、keyboard、sports ball、bottle、vase |
StereoBM / 最花时间的是双目匹配
我把双目匹配放在 CPU 上，最后选了 StereoBM。它是整套流程里主要的速度瓶颈，下面记录了一般运行时间和最终融合时的数值。
| Measurement | Observation |
|---|---|
| General StereoBM runtime | 约 170–300 ms/frame |
Final fusion bm_avg30 | 约 210–230 ms |
| Compute placement | CPU |
| Current status | 最终采用的匹配器，也是主要速度瓶颈 |
当时也对照试了 StereoSGBM，约 0.5–0.6 s/frame，看到的速度约 1.5 FPS，所以最终融合还是用了 StereoBM。
Fusion / 检测框和距离合起来看
有了检测框和深度图以后，我取框中央区域里有效深度的中位数，再按目标保存几帧历史结果做平滑。旧结果过了有效时间就丢掉。
| Measurement | Observation |
|---|---|
| Object-depth fusion | 通常在几十毫秒内，随目标数量变化 |
| Final HDMI display | 约 3–5 FPS |
| Depth estimator | 检测框中央 ROI 内，过滤无效像素后取中位数 |
| Temporal behavior | 每个目标分别记录中位数历史，并设置有效时间 TTL |
遇到无效深度或左右图不同步时，这一帧会跳过历史更新，框上可以显示 N/A。所以看检测话题的 20 FPS，和最后在屏幕上看到的 3–5 FPS，是两回事。
Synchronization / 没有硬件触发，先用时间差筛帧
这两只摄像头没有硬件同步。我记录左图到达 ROS 回调的时间，以及右图完成 OpenCV 采集的时间，把两者的差记成 stereo_delta_ms。
默认门槛是 --max-stereo-delta-ms 50。超过门槛就标成 DESYNC，跳过这一对图的双目匹配和深度更新。这样能先筛掉差得太远的帧，但记录的是软件收到图像的时刻，距离真正的曝光同步还有差距。
接下来还得处理的地方
回看这次实验，后续要继续做，主要还得盯着这些问题：
- 现在输入是 640 × 480，约 16.8 mm 的基线也更适合近距离。
- CPU 上的双目匹配比较慢，最后显示每秒只有几帧。
- 纹理太少时容易测不到；重复纹理、反光、遮挡和曝光差异也会干扰匹配。
- 运动场景需要更可靠的同步办法。
- 多距离误差、重复测量和有效率统计还需要补上。