手上没什么可以做的事情呢，纸上谈兵一下吧。
我们将无刷电调称为 智能电机
智能电机能够执行CAN上的命令，并通过CAN向上位机报告自己的状态。
分层
CPU + 各个传感器 + 智能电机报告的状态，构成了决策感知层。
六个智能电机 + 其他外设构成了执行层。
在决策感知层，跑在 Linux ROS 上的程序应当能够完全知道车辆姿态、周围状态以及任务计划。
在运动方面划分为这些层面：
物理分层 | 逻辑分层 | 说明 | 示例 |
|---|---|---|---|
决策感知层 | 业务层 | 一个由用户或服务器下发产生的一个复杂的任务。视类型采用不同任务描述方法。 | 自动边界探索任务 按指定路线行驶任务 |
导航层 | 一个具体的，可被Nav2直接执行的命令。 | 移动到点 轨迹跟踪 | |
几何层 | 高频的数学抽象的车辆需要进行的运动，一般包括三个线速度和一个角速度。车辆物理应当尽量贴近这个。 | 2.4m/s直行 10deg/s右转 | |
接口层 | 高频的每个智能电机的转速，可以被智能电机直接理解和执行。 | 10圈/s转速 0转速 | |
执行层 | 各种作业硬件所在的层，具备一定的信息处理能力，为决策感知层提供高级抽象的接口和信息源。 | ||
设备网关 --业务层数据--> 执行器 --导航层数据--> Nav2 --几何层数据--> 解算器 --接口层数据--> 硬件
理论实现和技术选项
在决策感知层上，有 设备网关 执行器 Nav2 解算器 这些软件。
设备网关
内部在实现时需要进一步划分结构，这将是设备端本项目的核心，出于安全考虑，应当使用 C++ 或 Go 这类语言。
但 C++ 写网络通信这件事情总感觉坑很多，所以采用Go实现。Go底层操作也是足够友好的。
这部分除了需要连接服务器收命令，还应该具备 OTA、自检等功能。
执行器
这部分代码量很少，起一个调度作用。暂时不做过多考虑。
解算器
这是一个需要考虑的地方。
根据几何数据算电机转速，这一步没什么问题。
但是需要确保多个电机同步收到命令，这一步不简单。首先Linux就是一个最大的不确定因素。它不是实时操作系统。但Linux本身对CAN总线的支持非常好，就像就是想让你这么写一样。
我们可以通过缓存+广播的机制解决多个电机同步问题：
先逐个发送转速，智能电机缓存这个值，然后广播一个缓存使能，智能电机再使用这个值。
Linux虽说不是实时系统，但几毫秒的不确定性还是可以接受的。
此处也是使用 Go 来写。
传感器
雷达、摄像头、编码器这类传感器数据就算出现抖动也是无所谓的。
但 IMU 的数据需要积分，它的采样是不能够有抖动的，IMU的采样是绝对不可以在Linux上的。
但是我还不想多加一个MCU，怎么办呢？
AMP，非对称多处理！既然我们都可以编译Linux了，从理论上来讲，可以让Linux少用一个核，那那个核去跑一个RTOS或者裸机程序。
此处我们之后再研究，但确定使用AMP去解决，如果有其他需要裸机参与的东西也直接丢到这个单核裸机上。