徐文
摘 要: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-),男,碩士,高級工程師.研究領域:嵌入式應用,自動控制.