徐文
摘 要:MCU端软件结构设计质量是影响循迹机器人工作效率、适应突发任务变更和异常状态能力的重要因素,但目前普适性的改进手段不多。本文通过遥控竞赛机器人任务特征分析,设计基于位置关联的控制设备与机器人间通讯协议,使用链表进行任务节点的封装和序列构造,最终基于位置信息实施控制流程。结果表明,任意给定任务序列能够准确实现。相对顺序式控制流程,该软件结构和关联流程设计在路径优化的同时还能适应任务序列的重整定。
关键词:循迹机器人;任务序列;软件结构
中图分类号:TP249 文献标识码:A
文章编号:2096-1472(2018)-11-31-03
1 引言(Introduction)
目前循迹机器人的应用研究侧重于本体组成设计[1]、路径优化设计[2]、稳定驱动设计[3,4]、传感器选型设计[5]等领域,机器人本体MCU(Microcontroller Unit)控制软件的结构设计关注偏低。本文以一款遥控智能赛车(以下称“循迹机器人”)、安卓遥控手机(以下称“移动控制端”)为实验对象,以赛道地图、任务集合为需求输入,通过任务节点的特征分析,给出有效的循迹机器人控制软件结构设计方案。
2 任务分析(Task analysis)
2.1 任务概述
利用移动控制端软件,控制循迹机器人完成赛道上的各项任务,如图1所示。赛道地图背景色为灰色无光;赛道为白色,宽30cm;寻迹线为黑色,宽3cm;循迹机器人以循迹线为赛道在行驶的同时完成移动控制端下发的各工作点任务,以入车库为任务终点。图中A、B、C三个位置为工作点停车线,A、B、两处可按指令前进到工作线位置,C点则通过测距或固定位移方式前进,停车后执行任务。1#车库为起点,2~4#为候选入库停车位。
2.2 任务特征细分
通过对循迹机器人(含移动控制端)任务特征的类属、执行设备、通讯方式、赛道位置和参数等维度项的分析,归结为表1所示的任务特征细分。类属的候选值有:A循迹路径驱动、B信号检测、C摄像及视频nfc信息处理、D赛道指令,其中A、B、D类任务由循迹机器人执行,C类由移动控制端执行。执行设备包括:A下位机(循迹机器人)、B上位机(移动控制端)。通讯方式的候选值有:A由上位机向下位机单向发送、B由下位机向上位机单向发送、C双向传输(存在握手需求:即机器人接受命令并执行后需向安卓移动端返回执行结果)、D无需通讯。赛道位置由命令帧或者数据报帧决定,表1不作定义。
2.3 硬件结构
循迹机器人的硬件系统构成包括:核心板、循迹驱动板、任务板和云台摄像头等部件。核心板采用宏晶STC15系列IAP15F2K61S2为MCU,通过电缆分别与其他部件连接,Keil C51为开发平台。循迹采用8组红外对管(TCR T5000),驱动采用L298N器件,用PWM信号驱动两侧车轮电机。任务板包括超声波测距、光强度检测、光敏检测、红外收发等器件。
3 MCU软件结构(MCU software structure)
文献[6,7]在机器人本体MCU上采用顺序式控制,缺少对于任务序列的结构性变更、随机性调整的灵活性,软件的冗余度偏高。本文根据任务特征细分和循迹机器人硬件结构设计,MCU软件结构设计包括:与移动控制端的通讯协议、任务节点数据结构、主控流程。
3.1 通讯协议
移动控制端通过WIFI转串口方式向循迹机器人发ASCⅡ格式命令帧,包括下列字段:命令帧起始字符、命令协议字符(必要时附带2位十进制参数数)、通讯方式字符(同表1)、机器人位置(同表2)字符、命令帧结尾字符。
循迹机器人向移动控制端发送数据报帧包括下列字段:数据帧起始字符、传感器数据(4位十进制数)、信号协议字符(命令帧中的信号采集命令协议字符)、机器人位置(同表2)、数据帧结尾字符。
循迹机器人的运行状态及位置如表2所示。图1中的三个工作位置中A、B点均有停车线和工作线,C点停车线即工作线。
3.2 任务节点数据结构
循迹机器人通常在起点处获得移动控制端下发的任务序列,在赛道上亦可随机收取新任务并插入到任务序列中。异常状态(如,出界)下,循迹机器人可主动插入数据报来重构任务序列。根据循迹机器人任务节点的离散、有序、与位置关联的特点,选择链表表征任务节点数据结构,并实现任务序列的构造与管理。按照循迹机器人任务特征细分(表1),以及命令帧格式、数据报帧格式的设计,且便于反向追溯,循迹任务链表设计为双链表:
#define uchar unsigned char //类型定义
uchar Robot_Status ; //机器人赛道状态、位置
typedef struct { //循迹任务链表數据结构
char Type; //类属(缺省值:A)
char Executor; //执行设备(缺省值:A)
char CommunicationMode; //通讯方式
char Command; //命令字符
uchar Location; //机器人位置:与执行命令关联的Robot_Status位置值,点动命令为空
uchar Status; //机器人状态:当前循迹任务结束时的Robot_Status状态值
struct Task_Tracking *link_next; //直接后继循迹任务的指针
struct Task_Tracking *link_before; //直接前驱循迹任务的指针
} Task_Tracking;
Task_Tracking * TrackingNow; //循迹任务链表当前节点指针
根据赛道路径上位置、状态的有限可枚举特征,全局变量Robot_Status的侯选值选取自表2。循迹除外的任务(以下称多任务)与机器人位置关联。参照循迹任务链表和命令协议字符设计,多任务链表设计为单链表:
typedef struct {//多任务链表数据结构
……
} Task_Multiple;
Task_Multiple* MultipleHead; //多任务链表表头指针
Task_Multiple中包括:类属(非A值)、执行设备、通讯方式、命令字符、命令字符附带2位十进制数、传感器数据4位十进制数、传感器信号协议字符、机器人位置、直接后继节点指针等。
移动控制端下发任务序列后循迹机器人构建循迹任务链表和多任务链表,并对循迹任务鏈表基于位置属性排序,此时TrackingNow和MultipleHead均为表头指针。而后进入主控流程,通过串口中断随机收新任务时则插入到任务链表中。
3.3 主控流程
在完成系统时钟、各端口、外设、定时器、链表(初始时节点为空)及指针等全局变量初始化后,循迹机器人主控流程如图2所示,阐述如下:
0.查询收到的任务字符。如有且为A类任务则插入到循迹任务链表,如有且为其他任务则插入到多任务链表。
1.从MultipleHead开始,向链表尾部方向移动指针方式查找Location值为空的节点。未找到则跳转至步骤5。
2.找到则执行节点任务,完毕后校验CommunicationMode值。其值不为C跳至步骤4。
3.值为C,按照表4的结构构造一个数据报,并通过串口转WiFi发送至移动控制端。
4.删除该节点,返回步骤1。
5.校验TrackingNow,值为空则返回步骤1。
6.执行节点任务,完毕后用当前状态位置更新Status并修正Robot_Status。
7.从MultipleHead开始,向链表尾部方向移动指针方式查找Location值与Robot_Status相匹配的节点,未找到则跳转至步骤11。
8.找到则执行节点任务,完毕后校验CommunicationMode值。其值不为C跳至步骤10。
9.值为C,按照表4的结构构造一个数据报,并通过串口转WiFi发送至移动控制端。
10.删除该节点,返回步骤7。
11.校验Robot_Status,为异常状态或者结束状态值(表5中的1、2、3、13)则按照表4的结构构造一个数据报,并通过串口转WiFi发送至移动控制端。
12.将TrackingNow更新为后继节点指针,返回步骤0。
4 结论(Conclusion)
以上MCU端软件结构设计经试验证明,能够有效保障循迹机器人完成其总体任务目标,并在随机接收临时任务和工作状态异常时实时调整任务序列,实现任务序列可整定功能。目前循迹机器人得到较广泛用[8],本设计试图为结构化生产环境中提高移动机器人控制软件的执行效率、降低设计成本提供案例和建设思路。
参考文献(References)
[1] 刘强,王超然,汪神岳,等.基于嵌入式系统的智能取书机器人设计[J].测控技术,2018,37(3):36-40.
[2] 李元,王石荣,于宁波.基于RGB-D信息的移动机器人SLAM和路径规划方法研究与实现[J].智能系统学报,2018,13(3):445-451.
[3] 黄刚.实时修正偏移量的循迹机器人控制系统研究与实现[J].仪器仪表学报,2015,36(11):2538-2546.
[4] 张志美,程立英,赵以恒,等.基于模糊PID控制算法的导盲机器人研究[J].沈阳师范大学学报(自然科学版),2015,33(1):81-85.
[5] 牛国臣,许开鲁.基于线性CCD的类人机器人循迹系统的设计[J].现代电子技术,2018,41(5):133-136;140.
[6] 刘家春,刘利,刘鑫,等.基于竞赛的医疗服务机器人控制系统设计[J].山东理工大学学报(自然科学版),2018,32(2):6-111.
[7] 张少华,刘富,刘利,等.面向竞赛的果园喷药机器人设计[J].机械工程与自动化,2018(2):153-156.
[8] 刘立军.基于单片机智能循迹机器人控制系统的设计与实现[J].仪器仪表用户,2017,24(5):42-45;68.
作者简介:
徐 文(1967-),男,硕士,高级工程师.研究领域:嵌入式应用,自动控制.