【RM2020 圆桌】第二期 步兵代码的那些问题

目前参赛队伍的机器人主控采用的多为STM32,STM32的CAN收发器Fifo的深度仅有3，这就导致了如果CAN线上设备过多则容易试得在某些时刻丢失掉部分数据，或者是CAN线上有一个发送速率很快(比如远超1KHz)的设备持续发送信息也会导致有时无法解析到其他设备(电调等设备都是1KHz)的报文信息，请问官方在这一方面有什么方法解决吗？

官方开源的步兵代码中PID计算采用的是位置式PID，官方是否有对比过在不同控制情况下(比如功率控制)采用增量式PID和位置式PID达到稳态的控制过程中哪个控制效果更好吗？

官方开源的步兵代码中，对于Dbus的空闲中断接收采用了双缓冲区处理，这样做有什么好处吗？

陀螺仪姿态解算的时候会融合加速度计，但是这个融合解算过程需要一定的时间，具体就会表现为云台PID控制之后，加速度计融合到姿态解算中使得这一位置的姿态角发生改变，PID控制器又开始进行输出，导致云台又开始缓慢进行调节之后稳定。且在加速度大的情况下云台容易出现抬头点头现象，请问这个如何解决呢？

官方开源的步兵代码中OLED采用的是STM32的硬件IIC，然后网络上经常能看到对于STM32硬件IIC不好用的吐槽，在实际使用中也的确遇到过其硬件IIC总线宕机的情况，请问官方在测试过程中有没有遇到这个问题呢？又是如何解决的

官方开源的步兵代码中，support文件夹下有一个名为mem_manager4.c的文件，而CubeMX软件生成工程时在FreeRTOS的中间层文件中也有一个关于内存分配的heap4.c文件，这里support文件夹下的文件作用是什么呢？

官方开源的步兵中使用的IMU芯片和之前内测的RM陀螺仪配置很像，请问是同款吗？

在使用FreeRTOS时，任务数比较多的情况下就需要考虑优先级和任务间隔时间，在实际使用中就有发生过某个任务一直被抢占的情况，请问官方在分配任务时一般会采用什么原则呢