项目开源地址：SimpleAstronaut/2026RM_Dart_Cli

0x01 前言

笔者是DreamTeam2025年和2026年飞镖系统的电控负责人，由于队伍先前有将近五年没有打过超对，因此在实际上队伍的飞镖组在队内没有太多可用经验和技术积累，本赛季飞镖系统的改进和研发主要针对了2025赛季飞镖研发和调试过程中的痛点和问题。

首当其冲的就是飞镖参数观测和调试过程繁琐。上赛季由于笔者经验不足，没能广泛参考其他学校优秀开源方案，上一赛季飞镖系统的参数观测和调整大量依赖连接调试器后调试模式观测变量的类似于调整PID参数的方式。一方面参数调整过程繁琐复杂，并且必须电控在场烧录代码，另一方面在赛场上面对3分钟准备时间需要临场调整参数的时候时间极其紧张，容错程度低。因此，在本赛季飞镖系统立项之初可视化操作和调试便成为电控部分关键研发目标。同时，飞镖系统控制依赖遥控器空控制，模式多且复杂，交由机械或者其他电控控制的时候无法短时间熟练遥控器操作，影响测试效率的同时也增加镖架损坏或安全风险。

因此，针对上述问题，我决定使用电脑作为飞镖镖架的上位机，采用usb连接镖架的C板，包含功能控制、模式切换，参数观测和调整等几项关键功能

0x02 技术栈

对于技术栈的选择我和队内的老学长经过了大量讨论。其中一种方案是直接使用镖架小电脑作为上位机，外接屏幕或者键鼠作为操作方式。但是由于队内经费紧张，留给镖架使用的小电脑性能很难满足流畅地使用图形界面作为上位机，固舍弃。另一种方案也就是最终选择的方案就是使用usb串口通信，node.js作为上位机底层，图形界面使用轻量化的electron。

采用此技术栈实际上有很多考量。一方面笔者在打RM之前就已经有Node.js以及web开发经验，短时间内可以上手并上线关键功能。实际上最初我的想法是采用node.js express框架，在本地运行网站服务器的方式前后端分离实现上位机图形化界面。但是笔者在vibecoding过程中发现用electron似乎能更加快速的产出图形化软件（雾。另一方面，由于我设计软件之初希望队内随便一个队员的电脑都能运行和使用上位机，并且为日后镖架可能的小电脑升级，上位机可以运行在小电脑上做准备，node.js的跨平台特性似乎可以满足上述要求。

因此综合各种考虑，飞镖上位机最终确定的技术栈为node.js electron，可以使用脚本打包为可执行文件。

0x03 功能设计

对于功能设计实际上笔者实际上在上赛季国赛结束后就有了大致需求清单，包括但不限于

•可视化参数观测和调整

•镖架状态观测

•模式切换和调试功能

•电机和其他外设状态的观测

对于上述功能，本赛季飞镖系统电控代码在开发的过程中我就已经为上位机控制预留了接口和控制逻辑。因此我可以大胆的设计通信协议和相关功能。最终实现的功能模块有

•usb串口连接控制

•连接与在线状态显示

•发射机构状态显示

•瞄准机构状态显示

•控制命令，启动停止，自动手动模式切换，开发模式关闭与开启，发射指令发送，以及开发模式下调试yaw和蓄力电机的运动

如下图所示

经过了几次迭代与调整，这些功能可以大大加快飞镖系统调试以及参数调整，甚至可以做到电控不在场的情况下仅由一名机械带领新生测试飞镖系统。

0x04 通信协议

由于设计通信协议的时候需要为可能的运行在小电脑上做准备，因此需要避开镖架视觉通信协议的帧头。最终确定的通信协议包含上下位机双向通信的各项关键功能。最终在形成了如下协议约定

项目	约定
物理层	UART
数据方向	双向
字节序	小端
帧类型	二进制定长头 + 可变载荷
校验	CRC16
同步方式	帧头同步
最大载荷	64 字节，建议预留到 128 字节
版本管理	通过协议版本号控制兼容性

帧格式如下

字段	长度	说明
SOF1	1	帧头，固定 `0xAA`
SOF2	1	帧头，固定 `0x55`
Ver	1	协议版本
Type	1	帧类型
Seq	1	序号
Len	1	载荷长度
Payload	N	数据区
CRC16	2	从 `Ver` 到 `Payload` 的校验

主要帧类型

•0x01 心跳请求

•0x02 心跳应答

•0x10 模式控制命令

•0x11 开发者模式命令

•0x12 阶段控制命令

•0x13 动作控制命令

•0x14 四发飞镖参数命令 (v1.1)

•0x20 系统状态上报

•0x21 发射机构状态上报

•0x22 瞄准机构状态上报

•0x23 电机状态上报

•0x24 四发飞镖参数状态上报 (v1.1)

•0x7F 错误应答

具体细节在开源仓库中有相关api文档说明，笔者就不过多在此赘述。依托于下位机电控代码开发之初就精心设计的架构，使用这套通信协议的上位机可以非常完美的控制飞镖镖架的各项功能。

0x05 操作和使用

主要使用方法非常简单，几乎就是傻瓜式的点按操作，这里我主要想说一下在赛场上临场观测和调整参数功能。在比赛结束下电之前，连接上位机以后可以直接观测赛场上记录下的yaw轴和蓄力数据，方便场下还原赛场环境。可以不用其他例如写入flash的操作，减轻电控开发难度（bushi

下图为某一场比赛结束后记录的yaw轴偏移数据和蓄力数据

屏幕截图 2026-05-28 162550.png

此外，上位机还可以临场单独调整四发飞镖的yaw偏置和蓄力补偿参数，快速实现一镖一参

0x06 项目结构

•main.js：Electron 主进程，负责窗口创建、串口管理和 IPC 通信

•preload.js：安全的 IPC 桥接层

•renderer.js：界面逻辑、状态渲染和命令发送

•protocol.js：协议打包、解析与载荷解码

•index.html：用户界面

•build.js：本地离线打包脚本

环境要求

•Node.js 18 或更高版本

•npm

•Windows 系统建议直接运行和打包当前项目

0x06 一些想说的话

笔者在加入队伍之前就了解过RM这项赛事，最初令我印象深刻的就是南京航空航天大学的飞镖系统。远距离高爆发的精准打击成为了我加入RM的奋斗目标和理想。因此我参加我们学校的dreamteam的其中一个梦想就是想做飞镖。由于笔者水平有限，以及队伍战术布局和其他一些原因，2025赛季飞镖系统地研发经历了很多坎坷和弯路，最终呈的结果就是对于队伍的战术和场上局势毫无作用，这也成为了我一个解不开的心结。我还是想做飞镖。

经历了2025赛季，今年我对飞镖系统抱有巨大的期望，心高气傲想要一雪前耻。但是规则的改动缺给了当时的我致命一击。飞镖固定目标的削弱给了我当头一棒。一方面队伍经费和资源有限，不太有可能允许我们消耗大量资源研发制导镖，另一方面当时经过队伍内部讨论，觉得固定飞镖这赛季作用有限，可能还是需要击打前哨加快节奏用途大，现在看来这可能是当初我们的某种战术设计失误？或许吧。总之给当初梦想做出中国科学技术大学那样关键飞镖，心高气傲的我来说是致命打击，一度怀疑过自己是否还要继续做飞镖。

但是随着赛季研发的进行，飞镖的重要性逐渐凸显，尤其是南部赛区开打以后，飞镖似乎成为了影响局势走向的关键。这几乎让我们整个镖组重燃了信心。在后面的测试中整个镖组都是对飞镖满怀希望，认为我们的飞镖一定能够在场上展现出强大功能。在最终决定胜负的最后一场比赛的第一句中几近命中目标，命中了飞镖靶的上沿，场间三分钟调试中镖组所有人都认为下一局的飞镖一定能够命中，帮助队伍扭转战局。但是场上局势风云多变，队伍关键输出核心出现了问题，导致飞镖系统在最后一刻也没能让我们调整的参数写进战局。遗憾吧，也有些不甘心。最终还是棋差一招，没能等到第二次开镖

本来这些话应该写在飞镖系统开源中的，但是队伍这赛季的飞镖实在是平平无奇，我便挑出了其中最拿得出手的也是我最得意的上位机开源，也算是作为纪念吧。

文落笔处，感慨万千。

0x07 通讯信息

e-mail：escscience@163.com

wx：Simple_Astronaut

[1][1]