系统架构

最终版本R2的系统架构可以概括如下：

驱动层 动作层 决策层

• 最终架构中：驱动层和动作层位于下位机执行，决策层由上位机负责。
• R2车组认为，在当前ROBOTIC的环境下。驱动层必须由下位机执行，决策层必须有上位机执行。中间的动作（应用）层可以放上位机或下位机，但不允许被拆分到双边。

随版本流转的系统架构说明

为什么这么划分？

说来心酸，我们尝试了很久，才找到这个更适合萝卜IC宝宝体质的架构。

• 首先，由上位机向下位机发送动作码下位机执行动作，这一点始终不变。
• 随后，在发送什么样的动作码执行什么样的动作上，我们更改了很多版。
• V1.0-1.2，我们尝试使用碎片动作码，何谓碎片动作码？以台阶动作举例，在那个时期，算法需要发送多个碎片动作码才能合成一个完整的上下台阶动作。当时的流程是：1.走定点 2.上台阶 3.走定点
• V1.3 我们更激进地尝试了碎片动作码，以期实现错误动作的恢复和上位机对于机构的完全控制。

碎片化动作码基本失败。原因如下：1.动作码越多 = 交流越多 = 交流成本高 = 修改成本高。在车体动作需要修改时，需要上下机两端同时修改，交流。2.RC基本无法做到动态的错误恢复。碎片化动作码无优势

• V1.4 使用整体动作码。动作完全抽象为：（动作）-（概念）。举例而言，在一区获取端头动作只有一组动作码，对应含义为：夹取并对接 - 对应编号端头；在二区，上下台阶动作改为：前往 - 对应编号梅林。

• V2.0 进一步调整动作码结构，将所有动作的底盘点位下放下位机

• V2.1 - 2.2 电控架构变更

• V2.3 系统架构无变更

从碎片动作码到整体动作码到场地对应点位数据放至下位机，是基本正确的决定，在很大程度上加速了调试进程，稳定了系统架构。从此上下机双方均以更统一的接口处理所有的动作，对双方代码的一致性很有帮助。

尝试与改进方向：

1. 尝试将某些独立机构的动作层上拉至上位机，但仍然保持整体动作码这个思路不变。如果说之前的碎片动作码是横向切开，平等地破碎所有动作的话；那么未来的改进方向就是竖向切开，将一些独立性特别强，上位机工作又特别方便的机构纯由上位机控制（比如这赛季的通用机械臂）；而其余联动性强的动作仍然保留在下位机中。
2. 尝试完全将动作曾上拉上位机，底盘暴露线速度接口，机构暴露电机位置和对应速度接口，下位机写好驱动，限位及保护即可。

后者比较泛用，在复杂的动作时变系统中这样的作法很常见，比如狗子。我觉得2尝试作用大于1，如果读者有对应尝试欢迎交流

技术说明

• 笔者只是相当于打了一年全职RC的软件半吊子，在R1已经用上了freertos的时候，还在使用中断+while1处理任务，这并不优雅，能跑就行啦。只提供一些索引，您能看懂就好

串口接收方式与中断回调与错误处理

1. 从逐字节到DMA idle
2. 中断回调与while处理
3. 必需的错误处理

超多电机处理方案

这块可以着重说下，这也是这赛季探索的比较重要的技术与性能边界。

1. 通讯层：对dm电机，控制端自can切换至canfd，将波特率自1M提升至4M，从而降低总线负载和丢帧率，解决单can口在1khz交互频率下只能最多挂载4个dm电机的问题。具体操作可以看这篇博客：

https://www.cnblogs.com/dtclk/articles/21894624

2. MCU端：在解决了这个问题之后，我们使用的H723zet6核心引出3can口，最终总共挂载了20+电机在同一块H723上，此时H7出现中断超载和fifo超载现象，通过极力优化软件架构，降低部分驱动闭环的dm电机控制频率，勉强实现了控制，但此时稳定性极差，绝非长久之计。

3. 分控tv：太好了是分控，我们有救了。在赛季中，我们更新了硬件架构，从单h7变更为一主多从的mcu控制架构，主从之间通过can协议交互，这正是can协议的舒适区。使用分控有很多好处，减少mcu挂载电机数量，减轻mcu负担只是其中的一点。

一些运动优化d

谷谷谷谷