基于STM32 的機器人軟件平臺設計與實現

王巖，褚澤帆，符偉杰，唐躍平

（水利部南京水利水文自動化研究所水利部水文水資源監控工程技術研究中心，江蘇南京 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]。

圖7 上行數據流處理流程

4 結束語

文中以STM32為硬件平臺，介紹了通用軟件控制平臺（URSP）的設計主體，該軟件平臺規避了傳統RTOS 運行所需的資源耗費，以分層化模塊化構建了協議解析層、功能控制層和硬件驅動層，給出分層協議的方案，簡化數據流的處理細節，并成功應用在水利信息采集機器人平臺上，取得了良好的技術經濟效益。