基于STM32 的机器人软件平台设计与实现

2021-08-20王岩褚泽帆符伟杰唐跃平

电子设计工程 2021年16期

王岩，褚泽帆，符伟杰，唐跃平

（水利部南京水利水文自动化研究所水利部水文水资源监控工程技术研究中心，江苏南京 210012）

移动机器人的控制软件作为系统的管理主体，承担机器运动的精准控制、数据的实时采集和传输、用户指令的有效执行等任务，软件平台的优劣直接关系到整个机器人系统能否正常工作[1]。市面上现有的RTOS 虽然在实时性要求上有所突破，但是由于其任务调度、内存管理等模块本身需要占用一定的内存、定时器等资源，且线程通信复杂不好掌控，使得在设计任务、分配资源时要充分小心，尤其在硬件资源紧张的平台上如何把握实时性和效率平衡的问题更加突出[2]。

针对以上所提出的设计问题，文中设计完成了一套通用的软件控制平台[3]URSP(Universal Robort Software Platform)。URSP 以STM32 小型化移动机器人为载体，充分利用软件分层设计思想，各层将所管理的软硬件内容以模块化方式并列，各模块之间互不交叉，只由最上层应用调配各层模块协同工作。此外，文中提出一套简化、高效的协议方案，最终由用户下达的用户帧指令调度完成各项工作，达到运动的可靠、数据传输的有序以及系统管理的便捷。

1 URSP总体设计

URSP 采用分层化管理，从上到下依次划分为协议解析层、功能控制层和硬件驱动层，如图1 所示。每层的主要功能明确，层与层之间通过特定的数据协议进行通信，减少了应用和硬件驱动间的交互冗余。各层的模块采用通用的数据结构进行设计，即使内部的模块有所变化，也不会对其他层造成影响，极大地保证了软件的可扩展性。用户端以无线方式下达用户帧命令，系统调配根据用户端下达的用户协议帧逐层解析执行，实现机器的各项功能控制。

图1 URSP总体结构

1.1 协议解析层

协议解析层位于URSP 的最上层，是URSP 系统的调度和控制中心，向上连接用户，向下控制机器人各功能硬件[4]。协议解析层的主要功能包括：

1）系统初始化及各种软件资源的创建；

2）接收用户发送的协议数据包并存储，检测功能控制层的各模块是否已准备好，如果是则开始解析协议数据包；

3）将用户协议数据包解析并转换为协议层和功能控制层的接口数据，按照接口数据的类型向功能控制层的各模块分发命令；

4）收集传感器、GPS 等数据并打包，上传给用户程序。

协议解析层从结构上主要由接收/发送循环缓冲区、接收/发送fifo、命令流分发器和传感数据收集器构成[5]，如图2 所示。

图2 协议解析层功能模块图

协议解析层包含了接收环形缓冲区和发送环形缓冲区，原始的用户协议数据包被缓存在接收环形缓冲区，协议解析器根据数据包的头部信息分析用户命令的类型，数据包长度、校验码等，提取相关数据并转换为所需的内部协议数据[6]，并添加内部控制域的字段，然后通知分发器提取内部接口。用户协议解析示意图如图3 所示。

图3 用户协议解析示意图

分发器在得到已解析转换过的同部接口数据后，直接通过几个控制字段向功能控制层的对应模块分发；接收队列则存储由功能控制层上传的内部协议帧，收集器检测并解析内部帧，将数据重新打包成用户帧后推送入发送环形缓冲区。

1.2 功能控制层

功能控制层由机器人的各功能硬件组成，功能硬件采用模块化方式管理，以本URSP 的物理载体轮式救援机器人为例，功能硬件包括电机模块、机械臂舵机模块、云台舵机模块、各类传感器模块、GPS 模块、探照灯模块、报警器模块等，每个模块以统一的结构CFuncModule表示，模块对象定义示意图如图4所示。

图4 模块对象定义示意图

所有的功能模块都使用统一的形式定义[7]，不仅使功能控制层与协议解析层或硬件驱动有了统一的交流接口，而且有利于模块的增减，一定程度上提高了软件的复用性。除上面所述的通用的数据和接口外，功能模块可根据自身的需要创建控制算法数据和接口，采用PrivateData 访问这一区域。功能算法控制是各功能模块的核心任务，对各功能硬件进行调配和管理，URSP实现的功能算法控制示意图如图5所示。

图5 功能控制示意图

1.3 硬件驱动层

硬件驱动层直接和MCU 交互，具有硬件平台依赖性，文中实验平台选用STM32F103 单片机，以官方固件库为基础[8]，将硬件驱动层组织起来。为简化硬件配置，屏蔽底层硬件驱动细节，将各片内外设的驱动参数以宏定义形式集中在一个文件中，可快速有效地完成MCU 硬件配置。主要的硬件驱动配置参数如表1 所示。

表1 硬件驱动配置参数

硬件驱动各功能模块以统一接口与功能控制层交互，如1.2 节描述，功能控制层通过将read/write 绑定到硬件驱动的外部接口实现控制硬件的目的[9]。

2 协议设计

2.1 用户协议

用户协议分为上行协议和下行协议[10]，用户协议的设计原则是在满足控制功能的基础上尽可能简化以达到节省内存、优化控制的目的，上、下行协议各字段的定义如表2 所示。

表2 用户上、下行协议

协议各字段定义如下：

1）帧头：用于用户和机器人的同步，以3 字节的0xFF 表示；

2）目的地址：当协议下行时，目的地址即为机器人地址；当协议上行时，为用户端地址；

3）数据域长度低字节和高字节：用于表示数据域的字节长度，以此数据长度可直接从数据域中取出所需数据；

4）命令位/数据类型：在下行协议中，命令位表示机器所要进行的运行控制（例如前进、后退、云台左转等）；在上行协议中，数据类型表示机器人所上传的数据类型，包括温度、距离、GPS 位置等；

5）数据域：在下行协议中，数据域中的数据表示运动控制的具体参数，如前进的速度、机械臂上抬的角度等；在上行协议中，数据类型表示机器人上传的具体有效数据；

6）Crc 高低字节：是通过Crc 校验算法从帧头开始到数据域最后一个字节结束所计算出的Crc 码，分两个字节存放，用于机器人或用户校验。

2.2 内部协议

内部协议主要为协议解析层数据封装以及协议解析层和功能控制层的信息交互[11]，如表3 所示。

表3 内部协议

内部协议同样分为上下行数据，上行数据为各传感器模块、GPS 模块等的采集信息，下行数据则为用户协议的命令解析[12]，内部协议各字段定义如下：

1）BlockId:用于标识功能控制层的各模块，每个功能模块有唯一的BlockId 标识；

2）方向：0 表示从协议解析层到功能控制层；1 表示从功能控制层到协议解析层；

3）命令：解析用户协议的命令位，配合内部协议的硬件索引下达正确的命令；

4）硬件索引：用于表示硬件模块的标识，例如电机模块有4 个，则索引为0～3；

5）控制参数：解析用户协议的数据域，将其转换为硬件索引所标识的硬件参数，例如电机转速、云台转动角度等；

6）数据域：是一个8 bits 的指针，指向要上传数据Buffer 的首地址，只在数据上传时会用到。

考虑到MCU 硬件平台的差异性，在功能控制层并未定义协议，只定义了对应的接口指针去访问各硬件驱动，以便快速移植驱动库[13]。

3 数据流处理

一个完整的数据流处理周期包括下行数据流处理和上行数据流处理。下行数据流处理由用户根据控制需求发送，无线数据经过WIFI 模块转发，通过UART送入到STM32单片机[14]。单片机以中断方式接收数据，根据用户协议的帧头和Crc 校验码断定协议帧的开始和结束，然后将数据帧推入到协议解析层的环形缓冲区，并更新环形缓冲区的相关标志信息。一旦协议解析层检测到环形缓冲区中有新的协议帧数据，就立即从中取出，根据各字段解析用户协议帧所表示的意义[15]。之后将解析出的数据转换为内部协议数据，添加入BlockId、硬件索引等字段后，将内部帧数据推入到内部帧接收队列中，并通知分发器工作，然后解析器可立即投入到下一次的解析。分发器接收到解析器的通知后，从队列头取出一个数据帧，只需要根据其BlockId 就可以将内部数据帧分发到相应的功能模块进行处理。功能模块得到已经解析完的内部协议帧，直接调用自身的算法处理接口进行底层控制参数计算，完成后即可将相关参数write到对应的片内外设，由此完成一次协议帧的下发处理，工作流程如图6所示。

图6 下行数据流处理

上行数据流处理针对传感器数据和GPS 信息，上行数据流的开启仍由用户启动，相关的硬件模块在用户请求获取数据后才开始工作，在用户通知数据获取完成后结束工作，最大程度地降低系统功耗。硬件驱动在获取传感器数据后会将数据信息地址和数据长度打包成一个DataEntry，并将其加入到一个全局链表中，由于GPS 数据长度达数百字节，系统设定全局链表的长度在一定范围内[16]。而各类数据的生成速度可能快于功能控制层的读取速度，当DataEntry 的数量超过链表规定的长度时，需要将最旧的DataEntry 释放，这样保证用户端拿到的数据相对是比较新的。功能控制模块read 读取DataEntry，然后打包成内部协议，推送到发送队列[17]。收集器在检测到发送队列中有协议帧后，从中取一帧解析并再封装成用户帧，推送到发送环形缓冲区，然后启动UART向用户端发送，用户随时可以下达命令，中止传感器数据的上传，上行数据流处理流程如图7所示[18-19]。