开源仓库（DEMO）：https://gitee.com/littlehornet/sp_-vpie/tree/rdk-x5/

由于我是初次尝试调自瞄，下面的内容不专业并可能存在错误。

一、　选型背景

2026年下半年，由于内存等一系列电子元器件涨价，NUC，NVIDIA Jetson开发板等RM惯用的自瞄运算平台通通涨价，2000元以内鲜有性能合适的自瞄运算平台。在我得知 EEPW 电子产品世界论坛与 DigKey 得捷共同举办了RDK X5开发板的试用活动后，立即报名，希望为我队的自瞄提出一个新的低成本解决方案。

RDK X5 4GB版本售价低廉，在主流供货平台上仅700-800元的售价，显然价格低于市面上几乎所有的自瞄计算单元。

二、　上手体验

尝试桌面环境与本地编译

之前我们的自瞄开发都是在Intel NUC上进行的。它的内存充裕，x86 CPU算力强，功耗高。能充分适配执行端就是开发机的开发场景。我们一般就是给小电脑插个调试屏和键鼠就开始干活了。这个小电脑上又跑桌面环境，还跑编译，同时再跑自瞄程序，没什么压力，开发起来也很顺畅。但其实这个习惯本身并不好。后来到了神经网络自瞄时代，由于老款x86 CPU的推理速度很慢，我们就打算转向有神经网络加速推理功能的低功耗国产板卡。

由于我队缺少无头环境下的开发经验，我在初次烧录镜像时选择了带XFCE的Ubuntu 22.04系统（官方Desktop镜像），但启动后发现仅有2GB的内存冗余（htop上显示本机物理内存仅有2.99GB，系统进程和桌面环境占用不到1GB）。然后我又尝试安装了一些带GUI的网络代理，发现这些软件的GUI要不无法正常显示，要不就无法打开。

我们也没有交叉编译开发的经验，因此我在板端跑了一个Codex CLI，并采用本地编译的办法。显然，这让本就不富裕的内存变得雪上加霜，只要敢用两个线程编译，板子立马OOM卡死，后来我在AGENTS.md里写道：“严禁多线程编译”。但这又使得编译速度变得极其慢，开发体验很差。

这里我们犯了三个错误：跑桌面环境、跑板端Agent、跑板端编译，这都不是这块板子该干的事情。这是我们之前用小电脑进行开发的惯性思维。

改进内存使用

在意识到这些问题后，我选择了最彻底的解决办法：让AI配置x86的交叉编译环境，换用远端Agent，并配置SSH免密，告知Agent SSH连接办法，使用无头的系统镜像。内存占用成功达到了仅不到600MB的健康状态（仅必要的系统进程）。事实证明，这才是一个较为健康的开发过程：板端和开发机仅凭借网线或者WLAN局域网通信，可以不非得坐在地上，给机器人插各种调试线。开发起来不仅对板子好，也不会导致长期盘腿坐在地上导致腰酸背痛。

尝试移植自瞄

参考开源一：wunuo1/rm_armor_detection

我们先看了看有没有类似的开源方案，答案是有，就是RoboMaster-装甲板检测案例（https://forum.d-robotics.cc/t/topic/28335），这个开源办法里，作者和我们一样采用大恒相机，场景契合度非常高。这里有几个很关键的技术点，非常值得学习：

1. 大恒相机Bayer转NV12，相对于转RGB不需要去马赛克，理论性能开销会低（但实测延迟差别不大）

2. NV12支持在本板子上的VPU（视频处理单元）进行硬件resize，大幅降低性能开销

3. 在量化时手动去除了一些反量化节点，防止回落CPU

Bayer、RGB、NV12 到底是什么

这三个词后面会反复出现，解释一下——它们其实是计算机描述图像的三种方式。

① Bayer：每个像素只认一种颜色

CMOS 感光元件本身只能测亮度，所以厂商在像素上盖一层红绿蓝交替的滤色片，最常见的是 RGGB 排布：绿占一半，红蓝各四分之一（因为人眼对绿最敏感）。这样拍出来是一张"马赛克"图——每个像素只有一个通道的数值，想还原成彩色就必须做插值，也就是常说的去马赛克（demosaic）。

Bayer 滤色阵列（RGGB）示意｜图源 Wikimedia Commons，CC BY-SA 3.0

② RGB：还原之后的"完整彩色"

去马赛克之后得到 RGB——每个像素三个字节，红绿蓝各一份。信息最全，代价也最大：1280×1024 的一帧就是 3.93 MB，而且后面每一步处理都要把三份数据搬一遍。

一张 RGB 图拆成 R / G / B 三个通道｜图源 Wikimedia Commons，Public Domain

③ NV12：丢掉一半色度，换一半带宽

NV12 属于 YUV 4:2:0 的一种 semi-planar 排布：人眼对亮度敏感、对色度迟钝，所以亮度 Y 按全分辨率存，色度 U/V 在水平和垂直方向都减半。同一帧 1280×1024，Y 平面 1.31 MB、UV 平面 0.66 MB，合计 1.97 MB——正好是 RGB 的一半。图中下半部分就是它在内存里的真实顺序：先一整块 Y，再是一串交错的 U1 V1 U2 V2…，这就是名字里 NV 的由来。

YUV 4:2:0 的帧内布局与字节流顺序（Y 平面 + 交错 UV）｜图源 Wikimedia Commons，CC BY-SA 4.0

把这三步串起来，就明白我们为什么选Bayer → NV12 直出：跳过重建完整 RGB，也就跳过了最贵的那一次去马赛克插值；而 NV12 的 Y 平面本身就是一张灰度图——后面角点精修只需要亮度，直接拿来用，一次多余拷贝都不用。

我们直接照抄了这个相机的处理方式，但此开源方案的模型比较老旧（作者演示时在识别基地大装甲板，但基地大装甲板已经在26赛季退出历史舞台了），我们从网络上找了一系列的开源模型，让Agent尝试了量化（队里没有量化经验）：

最终，我们选定了深圳大学的模型作为量化基座，因为其量化相对简单且精度不错。

但是，深圳大学2026模型在我们板端推理11ms（我们这版量化的实测值），这其实不太健康，只不过在我们的流水线下，它不是瓶颈，因此没有换参数量更小的模型。现在回顾，其实上科大的道路才是正确的，用参数量较小的模型，换来快速的推理，之后再用强精修兜底。换言之，神经网络的角点质量，其实应该没那么重要，重要的是检出率和推理延迟。

参考开源二：同济大学2025视觉框架

这是近几年RM视觉开源最高的山，是众多战队复刻开源的首选，其开创性的MPC路径规划和易于上手的特性受无数视觉青睐。但是本项目依赖于Intel x86运算平台，我们针对此进行了一系列改造。

同济这套框架的算法部分（MPC 轨迹规划器、EKF 整车估计、坐标链路与解算）我们基本原样保留，改的主要是ARM上跑不了的：

1. 推理后端换血：原项目的检测走 OpenVINO，我们改成 RDK X5 的 BPU；OpenVINO 变成可选依赖，非 x86_64 主机自动不参加编译。

2. 相机链路改成 NV12 直出：大恒相机直接给 Bayer，不转 RGB（省掉去马赛克），转 NV12 后交给 VPU 硬件 resize。

3. 检测模型换成 BPU 上的 int8 四点模型（深大 2026），解码链路按新模型的输出头重写。

4. 推理改成异步流水（submit/fetch 错峰，结果晚一轮取出），整帧吞吐从 46 提到 77 fps。

5. 延迟补偿不为 0：x86 配置里 delay_time 是 0，我们改成 15ms。

6. 调试方式换掉：原来靠 NoMachine 远程桌面 + PlotJuggler 曲线，我们改成板端画面JPEG硬编码，发送给PlotJuggler，可以同时看自瞄调试画面和参数曲线。

三、　延迟和帧率瓶颈

起点：纯识别的 20fps

我们之前参考wunuo1/rm_armor_detection，跑的是纯识别版本——只做检测、不接规划，模型的量化也做得比较粗糙，板端只有 20fps 左右。这里有很多原因，包括量化粗糙许多算子回落CPU，以及相机链路还存在拷贝。但是验证了RDK X5跑自瞄的可行性。

第一轮：letterbox 吃掉了整循环的 66%

先做分阶段延迟测试，把主循环拆成 read（相机读取帧） / bayer（Bayer转NV12） / submit(letterbox) （变换分辨率，准备喂给BPU）/ fetch（解码） / cls（传统数字复核） / track （跟踪解算）六段。结果很意外：

原来的 letterbox 是手写双线性插值，每个采样点都走一遍 double 运算加 std::lround，432k 个采样点在 Cortex-A55 上耗时 16.5 ms，占整个循环的 66%（submit 16.9 ms 里 16.5 ms 全是它）。而 BPU 的纯推理经 hb_perf 实测只要 3.17 ms（315 fps），早就被单飞双缓冲流水完全掩盖了，根本不是瓶颈。

改法是把 Y 平面与 UV 平面（CV_8UC2 交错）分别用 cv::resize(INTER_LINEAR) 直接写进 staging 带 pad 偏移的子矩阵（笔者肯定不知道这么厉害的解决办法，其实都是AI发力了）。几何上两者同为「中心对齐」，所以是等价的。letterbox 16.5 → 4.43 ms，端到端 40 → 78~85 fps（无目标）／45~54 fps（有目标）。

优化后的分阶段拆解（150 帧 EMA）：

第二轮：一个全局单线程留下的 4ms「重叠税」

这一轮最大的收获，是发现 letterbox 里那 4 ms 的重叠税其实是全局 cv::setNumThreads(1)：cv::resize 本身是多线程的，早年为了 tiny_resnet、ROI 这类小张量加的全局单线程，把这条大张量也一起压成了单线程（板端实测 4.45 ms vs 8.35 ms）。

改法是只在 letterbox 期间临时把 OpenCV 放开到 4 线程（小张量仍保持单线程，否则角点修正会从 0.5 ms 变成 14 ms）。这一条很关键——全局开关是懒办法，作用域开关才是正解。落地后 letterbox 8.84 → 5.45 ms、端到端延迟 30.5 → 23.0 ms、fps 58 → 76（峰值 81）。

第三轮：角点修正与 tracker

有目标之后帧率会明显掉下来（46.8~50.7 fps、延迟 36~39 ms），链路里多出两块大头：角点修正和tracker。

我们先把角点修正的成本拆开，发现八成花在取图上——把 NV12 整块转 BGR 再转灰度做二值化，而精修只需要亮度，NV12 的 Y 平面正好就是亮度。改成零拷贝喂 Y 平面后，角点修正 3.3 → 0.81 ms，有目标 fps 回到54.9~56.0、延迟降到33.9~34.3 ms。

同一轮还剖了 tracker：跟踪一帧 3.4 ms 里 96% 是解算，其中 optimize_yaw 的 140 轮暴力搜索占 2.87 ms，而且几乎全花在 Rodrigues + projectPoints 的矩阵 → rvec → 再转回矩阵往返上；手写投影的原型获得 41.5 倍加速（且与原算法等价）。

瓶颈到底在哪：BPU 其实一直很闲

四轮之后，无目标是 23 ms / 75 fps，有目标是 31~35 ms / 50~56 fps。这时候必须回答一个问题：是不是 BPU 算力不够了？

答案是否定的，而且证据明确：

• 满载上限 85.9 fps（submit gap P50 = 11.72 ms）。无目标时占空比 11.72/13.33 ≈ 88%，有目标时（周期 20 ms）反而降到 ~59%。

• 整机占用：无目标时主线程 101% 死死钉在单核上、其余 7 核只有 14~23%、全机 28.5%；有目标时出现第二个满核（cpu0+cpu7 双 102%）、plan_thread 从 0.3% 涨到 61.3%、全机也才 40.7%。

结论是：缺的不是算力，是并行结构。真正闲置的是 CPU 侧那 ~4.7 个等效核，而且没有任何 OS 级问题（无迁移、无抢占、无降频），全是我们自己的主循环单线程造成的。

下一步（TODO）：把 bayer + letterbox 搬出主线程、用 staging 双缓冲，按实测常数推演可以把有目标延迟压到 ~18-20 ms、fps 到 80+（撞 BPU 85.9 的上限）。

四、　调试与踩坑

段错误：多线程与调试台的竞态 （本错误由AI发现，此处是AI自述）

现象很规律：有目标 + Web 调试台开启 → 30~50 秒内必现 SIGSEGV，两次复现都拿到了 core。反证也很干净：把 web_debug.enabled 关掉，90 秒内目标多次进出，零崩溃。

根因是主循环每帧在 letterbox 作用域里切 cv::setNumThreads(1↔4)，这会重建全局 TBB 线程池；而 Web 线程同时在跑 cvtColor(NV12→BGR) 的 TBB parallel_for。一边在销毁重建、另一边正在执行 → use-after-free。当时默认配置是开着 web_debug 的，实机部署等于一颗定时炸弹。

修法不是加锁，而是让 Web 侧彻底不进并行路径：新增一套显式串行的阈值/灰度/最近邻缩放，并逐像素对齐 OpenCV 的定点舍入语义（BGR 转灰度用 3735/19235/9798、>>15）。同时补了逐像素对拍加三线程并发压力测试。

有个细节值得记：注释里原本写着「小图天然线程安全」——这是错的，竞态跟图大小无关。另外测试里的参考图必须预生成在并发开始之前，我们曾经把 GRAY2BGR 放进 worker 里，结果在板端复刻出了生产环境同款的竞态。

角点顺序：一个不报错的 90° 错位

现象是整车预测模型相对检测框整体转了约 90°。这种错误最难受的地方在于：PnP 照样收敛、也不抛异常。

根因是上游点序表不统一（各学校的模型输出不太一样），角点精修继承了一个不一致的四点顺序。修法是在精修前加一步 normalizeCornerOrder，按图像几何统一成 [左上, 右上, 右下, 左下]，与上游点序无关且幂等——不管上游怎么给，出来都是同一个顺序。

串口掉线与 IMU 单位（本错误由AI修复，此处是AI自述）

串口这边踩的是一个很致命的坑：下位机复位或 USB 被拔时，libserial 的读写会抛异常，而读线程没有 catch，异常逃出线程触发 std::terminate，整个视觉进程直接死——不是掉线，是进程没了。

修法是全部捕获并降级：关端口、标记离线、绝不退出进程，由读线程按节流在后台重连。掉线期间 mode() 返回 IDLE、send() 直接丢弃、latest_q() 返回 nullopt，队列查询不再死等；收到合法帧就自动恢复。另外加了候选端口轮换（配置名 → 同前缀 ttyACM* 兄弟节点），解决重插后编号变化导致连不上的问题。Serial::Close() 也改成绝不抛异常，避免析构时二次抛出。

IMU 侧是另一种典型的「不报错但全错」：下位机把角度按度上报、不做弧度换算，而角速度字段是 rad/s。我们踩过 gimbal_yaw/pitch 多乘 57.3、以及 pitch/roll 槽位交换。现在的做法是随帧携带 IMU 四元数，优先用于 set_R_gimbal2world，非法时才回退欧拉角并告警——欧拉角降级为调试兜底，不再进主链路。

五、　实测

相机分辨率不一致

我们犯了一个经验主义的错误，由于我们队里有两种大恒工业相机，分别为 MER-139-210U3C 和 MER2-301-125U3C，我们一直在用前者，而我拿到手的这辆步兵是 MER2-301-125U3C 相机。MER-139-210U3C 相机的分辨率是 1280*1024，我们就按照这个参数取画面。结果是我们画面只取了相机左上角的一块 ROI，标定后发现光轴偏离严重，经过复核后发现相机型号不同，但此相机在满分辨率（2048*1536）下输出只有 95 fps，可能会成为瓶颈，于是我们采用了四个像素合并（Binning）的办法。

在 1024*768 分辨率下，帧率来到了125 fps，虽然也不是很高，但是不再成为瓶颈，但代价是分辨率大幅下降，对后面的角点精度不是很友好。

相机旧帧积压、图像与姿态时序错位，导致自瞄摆头

现象是：静止的装甲板上，整车预测模型的框幅度远大于真实该有的预测误差，一旦发散，云台立刻跟着动，看起来就是摇头。

根因有两条，都在时间上：一是相机 SDK 默认按 FIFO（OldestFirst） 交付图像，我们消费不过来时队列会积压旧帧，读到的画面越来越旧；二是代码用帧到达本机的时刻当帧时间戳，再配当时最新的云台姿态——图像内容和姿态对不上，静止目标被解算成了运动目标，EKF 的速度、半径跟着乱，预测参考一起摆。实测相对时差 x86 上 -154 ms、板端 -118 ms。

修法也分两步：先把采集策略换成相机 SDK 的 NewestOnly（只取最新帧），再把帧时间戳改成相机给出的曝光时刻、姿态按这个时间戳插值取。修改之后，摆头现象立即消失。

六、　回顾我们的开发

从 20fps 到 80fps，真正花时间的不是「换一个更快的框架」，而是把整条链路上的浪费一层层剥出来。回头看，有三点体会值得留给后面的同学：

• 先量，再改。这条链路上最耗时的两个地方——手写 letterbox 的 16.5 ms、全局单线程留下的 4 ms——都不是看代码能看出来的，全是分阶段插桩之后由数据指出来的。反过来，一开始最怀疑的BPU 算力和相机帧率，最后都被证明不是瓶颈：BPU 纯推理只要 3.17 ms，一直很闲。

• 惯性思维不可取。跑桌面环境、在板端编译、在板端跑 Agent，这三件事在 NUC 上全是理所当然，放到这块板子上却是灾难。把整套习惯原样搬过来，代价是半个月的折腾。

• 不报错的错误最危险。90° 的角点错位、IMU 的度与弧度、相机旧帧造成的摆头——它们都不抛异常，程序照常输出，只是答案是错的。这类问题只能靠可观测性提前暴露：分阶段计时、时间戳对齐、调试画面叠加，一个都不能省。

回到最开始那个问题：这块七百多块的板子，到底能不能当自瞄运算平台？我们的答案是能。它现在是 23 ms / 75 fps，虽然帧率上还并不是很极致，但我们现在只投入了不到一个月的时间优化。而在同等性能下，它的价格只有 NUC 和 Jetson 路线的 1/2 甚至 1/3。

当然它还没被榨干。预处理并行化那一步做掉之后，按实测常数推演还能把有目标延迟压到 18~20 ms、帧率做到 100+甚至200+——那才是这块板子真正的上限，也是我们接下来要继续做的事。

为什么我们有胆量说RDK X5的自瞄帧率能更高，就是因为上海科技大学的自瞄开源：

七、　对照上科大 AX650：RDK X5 的上限在哪

他们公开发表的成绩是 300fps 吞吐、12ms 端到端延迟。这个数字之所以有参考价值，是因为两边的硬件其实是同一档的。

两边硬件其实是同一档

换句话说：CPU 差 12%，INT8 算力只差 7%——这两项几乎可以认为平手。它们都是国产边缘视觉 SoC，都是「八核 A55 + 一颗独立 NPU」的架构，连短板都相似。

相似到什么程度

不只是纸面参数像，整条技术路线几乎是一个模子刻出来的：

• 相机路线相同：都是 USB3 工业相机直接走厂商 SDK 取流（我们用大恒，他们用海康），都不经过 SoC 的 ISP。这意味着两边的图像链路起点完全一致。

• 算法链路相同：采集 → 预处理 → 检测 → 传统视觉角点精修 → PnP → 跟踪 → 规划 → 串口，一级不差。甚至「神经网络只负责出候选、精度靠传统方法兜底」这个取舍也是同一个思路。

• 模型同源：他们仓库里就放着深圳大学 2026 的 onnx（512×640 输入），而我们正是选了深大模型当量化基座。也就是说，我们两家的模型是同一族，甚至有可能就是同一个。

• 目标场景相同：都是 RM 步兵自瞄、都要在几十毫秒内闭环。

所以「他们在 AX650 上能做到什么」这件事，对我们有很强的可迁移性——不是类比，是近似同构。

但不能直接对标：差在三处

• 模型规模差了一档。他们主线的 SKD 模型是 640×512 输入、6720 个候选 × 21 个值的单输出轻量网络；我们用的深大 v8n 是三个输出头、每头 6720×22。这不是芯片差异，但它直接决定了单帧成本——再加上我们这版量化本身成色未验，两个因素叠在一起，才拉开现在的差距。

• 内存带宽只有一半。官方硬件手册写得很清楚：RDK X5 是 32-bit LPDDR4，AX650N 是 64-bit LPDDR4x。而我们在排查里发现，每帧 BPU 的固定开销本身就占了大头——带宽减半会直接压在这上面。

• 工具链对动态算子的容忍度不同。我们踩过：模型图里内嵌 NMS 或 TopK，hb_mapper 直接编译失败，或者整块回落 CPU。上科大用 AXCL/Pulsar2，对这类结构的支持要好得多。

那 RDK X5 的上限到底在哪

把上面这些摆在一起，可以分三档看，结论比「能不能到 300」更有用：

第一档：85.9 fps 不是 BPU 的天花板，是「我们这版量化产物 + 当前链路」的天花板。我们量到深大 v8n 单帧 BPU 成本 11~12.8 ms（四法互证），85.9 fps 正好是这个成本倒过来的数。这一段是算术，不是估计。

但这里得补一句公道话：11~12.8 ms 是我们自己那版量化产物跑出来的，不能直接算到深大模型头上。队里没有量化经验，这份 bin 是让 Agent 一点点试出来的——哪些算子被逼回了 CPU、图里还留着多少多余的反量化节点、输入格式有没有做到零拷贝，我们都没有系统地 A/B 过。同一个网络，量化做得好不好，单帧成本完全可以差出一大截。所以更准确的说法是：我们离这个模型应有的成本还有距离，而不是这个模型只能跑 11 ms。这一点我们自己心里有数，也是接下来要补的课。

第二档：能不能摸到这个上限，取决于三件事，没有一件是「换个更快的芯片」。一是把这版量化重做一遍——先搞清楚哪些算子掉到了 CPU、图里还剩多少冗余节点；二是换轻量模型 + 传统强精修——这正是上科大走过的路，也是我们在量化那一节里承认过的正确方向；三是把每帧的固定开销压下去——预处理搬出主线程、减少拷贝、加深流水。前两件属于「我们做得不够好」，第三件属于「我们还没动手」，都不是硬件挡路。

所以：RDK X5 现在跑 50~75 fps，不是这块板子只能跑这么多，是我们还没把它榨干。同一档的硬件，别人已经跑到 300 fps 了；我们按同样的模型和通路折算，落到 150~200 fps 是完全够得着的——而这块板子只卖七百多块。

八、　为什么明知能做得更好，却先停在这里

写到这儿，大概会有人问：既然量化可以重做、数据通路可以再压，为什么不去做？

不是不做，是现在做等于白做。

2026 年 10 月 15 日，RoboMaster 2027 赛季的《机器人制作规范手册》V1.0.0 发布。里面有一条改动，把这件事的靶子换掉了。原文在 S30「不得使用任何手段改变机器人视觉特征」下面：

「在 2027 赛季，裁判系统装甲模块受击面为点阵屏幕，受击面可以显示对应机器人编号或图案（具体样式后续更新）。」

两侧灯条在安装规范里还在，但受击面中间那块印着数字的哑光贴纸没有了——变成了一块会发光的点阵屏。它显示什么、什么颜色、怎么刷新，规则里只写了"后续更新"。

对视觉来说这意味着什么，做过自瞄的人都清楚：

• 数据集基本作废。我们攒的、开源社区共享的、各队自己标的那批装甲板图，拍的全是"灯条 + 贴纸"。新目标是点阵屏，图案未知，旧标注一条都用不上。

• 模型要重训。检测目标从"灯条围出的矩形 + 中间的数字"变成一块整面发光的屏，外形特征、边缘、亮度分布全变了；分类头更是直接失去意义——编号不再是印上去的字，而是屏上画出来的东西。

• 量化要重来。输入分布一变，标定集就得重做，之前调好的量化参数、阈值、置信度门限全部失效。

我们之前做的近一个月的量化，重训练，标数据集，已经可以全部丢垃圾桶了。这不是偷懒，是止损。

但已经做出来的东西一点没浪费：

• 链路是稳的。交叉编译、一键部署、相机 NV12 直出、BPU 单飞流水、曝光时刻时间戳、串口降级重连——这些跟"检测什么"完全无关，换个模型照样跑。

• 性能认识是可迁移的。瓶颈在哪、单帧成本怎么拆、哪一层并行有收益、哪个数字是理论口径不能信，这套方法论换个目标依然成立。

• 工具是现成的。调参台、SN 管理、标定闸门、部署脚本，都还能接着用。

所以这块板子的故事没写完。现在的 50~75 fps 是在旧靶子上打出来的成绩；等点阵屏到底长什么样定下来，把数据集重建、模型重训、量化重做，再把这套已经被验证过的链路接上去——150~200 fps 那一档，才是它真正的起点。