视频演示

地瓜派 RDK X5 让我们看见了 ARM 板卡在 RoboMaster 上的潜力。这次试用我们主要做出来三个成果：

1. RoboMaster 装甲板自瞄

2. 人脸识别追踪（含云台追踪）

3. 用 CAN FD 直接驱动 GM6020 电机

一、RoboMaster 装甲板自瞄

RoboMaster 自瞄的任务就是：从相机画面里找到敌方装甲板，解算它在三维空间中的位置与朝向，预测它接下来的运动，再换算成云台该转多少。整个闭环必须在几十毫秒内完成——慢一帧，弹丸就落在装甲板后面了。

我们在 RDK X5 上把这条链路完整跑通了，而且是在一块七百多块钱、没有独显、没有风扇的板子上：

这条链路上真正花功夫的地方

• 相机直出 Bayer → NV12，跳过重建 RGB，把最贵的一次去马赛克插值省掉；NV12 的 Y 平面本身就是灰度图，角点精修直接拿来用，零拷贝。

• letterbox 从手写换成 cv::resize(NEON)，单帧 16.5 ms → 4.43 ms，一次性把端到端帧率从 40 拉到 78~85 fps。

• 角点修正零拷贝喂 Y 平面，3.3 → 0.81 ms；tracker 里的 140 轮暴力搜索换成手写投影，拿到 41.5 倍加速。

• 取帧策略换成 NewestOnly，时间戳改用相机给出的曝光时刻、姿态按该时刻插值——这是把「静止目标被判成运动目标、云台自己摇头」这个怪现象根除的那一刀。

• 串口掉线不退出进程，读写异常全部降级捕获，后台重连 + 候选端口轮换，下位机复位或 USB 被拔都不会把视觉进程带崩。

完整的踩坑与调优过程，写在另一篇帖子里：《【过程】从 20fps 到 80fps：RDK X5 上的 RoboMaster 自瞄移植》。

二、人脸识别追踪

第二个成果看着和自瞄无关，其实验证的是同一件事：这块板子能不能实时「看见」，并且让云台跟着动。

检测这一层我们直接用了地平线 TROS 官方的人脸年龄检测节点 mono_face_age_detection——它本身订阅 mono2d_body_detection 给出的人脸框，再用 BPU 跑 faceAge 模型推理。官方给的账其实很宽裕：这个模型输入只有 1×3×128×128，在 RDK X5 上单模型推理能到 207 fps，整条流水线稳定在 30 fps——对云台追踪来说完全够用。

我们在这套基础上加了云台追踪闭环：从检测结果里取出人脸框中心，换算成云台目标角度，通过串口下发下去。效果就是人往哪走，云台跟到哪。

这一件值得提的原因是它几乎零成本：官方节点开箱即用，我们真正写的只有追踪那一层。它也侧面说明了 RDK 生态的好处——很多能力别人已经做完了，你只要能接上。

三、用 CAN FD 直接驱动 GM6020

前两个成果都停留在「算」，第三个是「动」。

RDK X5 板载一路 CAN FD。我们用它在板端直接对 GM6020 下发控制指令——CAN 标准帧，一帧 8 字节可以同时带 4 台电机的控制量，中间不需要任何下位机转接。

从电压到角度：三层控制都跑在板端

最底层是电压控制——GM6020 的 CAN 指令本质就是一个 −30000 ~ 30000 的量，对应施加在电机上的电压。这一层只解决「使多大劲」，不解决「转到哪」。

所以在这之上我们自己补了两层：速度环和角度环，都是 PID 闭环，反馈取自电机回传的角度与转速。三层串起来就是——电压是「力」，速度环把它变成「转多快」，角度环再把它变成「转到哪」。三层全部跑在 RDK X5 上，不依赖任何外部控制器。

顺手写了个 Web 上位机

调 PID 最烦的是改一次参数就要重编译、重部署一次。所以我们写了个 Web 上位机：在浏览器里直接设目标、改参数、看电机回传的实时反馈——不用改代码、不用重编译、也不用额外接调试线。

这块板子本来就有千兆网口和 Wi-Fi 6，在板上起一个 web 服务就行，队里谁都能上手调。

这件事其实在开箱那篇里埋过伏笔：当时看到这颗板子有 CAN FD，我们判断「用它控制 GM6020、4310 这类云台电机完全可行，一块板子就能顶掉下位机」。现在这一条不只是被验证了，还多了一层闭环和一套调参工具。

三个成果拼起来是什么

一个能自己看（自瞄）、能跟着人转（人脸追踪）、还能把电机稳稳控住（CAN FD + 双闭环 + Web 上位机）的平台，正好就是 RoboMaster 步兵所需要的那一套。而这三件事，现在跑在同一块七百多块钱的板子上。