聶 冬，宋 陽(yáng)，周海波，嚴(yán)佳歡，趙一嬌，*

（1.天津理工大學(xué)a.天津市先進(jìn)機(jī)電系統(tǒng)設(shè)計(jì)與智能控制重點(diǎn)實(shí)驗(yàn)室，b.機(jī)電工程國(guó)家級(jí)實(shí)驗(yàn)教學(xué)示范中心，天津 300384）

為實(shí)現(xiàn)機(jī)器人和云平臺(tái)服務(wù)器之間數(shù)據(jù)的傳輸功能，在實(shí)驗(yàn)過(guò)程中機(jī)器人會(huì)在不同環(huán)境中采集實(shí)驗(yàn)所需要的溫度、濕度和位置等系列數(shù)據(jù)，并將采集到的實(shí)驗(yàn)數(shù)據(jù)通過(guò)第四代移動(dòng)通信技術(shù)（the 4th generation mobile communication technology，4G）無(wú)線傳輸?shù)姆绞絺鬏斨猎破脚_(tái)服務(wù)器。此時(shí)機(jī)器人采集到的各類數(shù)據(jù)信息就可以進(jìn)行分類存儲(chǔ)，同時(shí)應(yīng)用4G網(wǎng)絡(luò)通信技術(shù)，不僅能實(shí)現(xiàn)數(shù)據(jù)的無(wú)線傳輸，而且為云端數(shù)據(jù)分析、多機(jī)器人數(shù)據(jù)共享以及人機(jī)信息交互等奠定了技術(shù)基礎(chǔ)。

近年來(lái)隨著移動(dòng)通信技術(shù)的快速發(fā)展，利用4G網(wǎng)絡(luò)技術(shù)作為多機(jī)器人的無(wú)線傳輸方式成為一種趨勢(shì)[1-5]。與4G網(wǎng)絡(luò)無(wú)線數(shù)據(jù)傳輸技術(shù)相比，同領(lǐng)域的紫蜂（ZigBee）無(wú)線數(shù)據(jù)傳輸技術(shù)、藍(lán)牙（Bluetooth）無(wú)線數(shù)據(jù)傳輸技術(shù)和無(wú)線網(wǎng)絡(luò)通信技術(shù)（Wi-Fi）等雖然成本較低，但存在著傳輸范圍有限的缺點(diǎn)，在遠(yuǎn)距離數(shù)據(jù)傳輸場(chǎng)景中受到限制。4G網(wǎng)絡(luò)技術(shù)近年來(lái)得到充分地發(fā)展，雖然仍存在信號(hào)強(qiáng)度易受建筑物影響以及傳輸延遲較大等缺點(diǎn)，但是因其覆蓋面廣、分散性強(qiáng)和靈活性高，能擺脫空間的限制，實(shí)現(xiàn)大面積和遠(yuǎn)距離傳輸?shù)葍?yōu)點(diǎn)仍具有更好的發(fā)展前景[6-10]。

1 總體設(shè)計(jì)

1.1 硬件設(shè)計(jì)

在實(shí)驗(yàn)中，移動(dòng)機(jī)器人在不同環(huán)境中采集相應(yīng)的數(shù)據(jù)信息，當(dāng)機(jī)器人采集到數(shù)據(jù)信息后會(huì)根據(jù)具體要求上傳到云平臺(tái)服務(wù)器。當(dāng)某一臺(tái)機(jī)器人需要其他機(jī)器人的數(shù)據(jù)信息時(shí)，就可以直接向云平臺(tái)服務(wù)器發(fā)送請(qǐng)求，來(lái)獲取到相關(guān)的數(shù)據(jù)信息；實(shí)驗(yàn)研究人員也可以根據(jù)多臺(tái)機(jī)器人采集到的不同數(shù)據(jù)信息進(jìn)行對(duì)比研究、分析處理等工作，對(duì)于發(fā)現(xiàn)其內(nèi)在的深層規(guī)律有很大的幫助。硬件結(jié)構(gòu)圖如圖1所示。

圖1 硬件結(jié)構(gòu)圖Fig.1 Hardware design structural diagram

機(jī)器人上安裝有32位微控制器（STMicroelectronics32，STM32）微控制器，4G模塊及相應(yīng)的傳感器，根據(jù)實(shí)驗(yàn)的具體需要，傳感器能夠收集相應(yīng)的數(shù)據(jù)信息，再通過(guò)4G網(wǎng)絡(luò)與Internet相連接，把采集到的數(shù)據(jù)信息傳輸?shù)皆破脚_(tái)服務(wù)器中，最終實(shí)現(xiàn)機(jī)器人與云平臺(tái)服務(wù)器之間的無(wú)線數(shù)據(jù)通信功能。無(wú)線傳輸系統(tǒng)主要包括STM32主控芯片、降壓電路、穩(wěn)壓電路、晶振電路、CH340程序下載電路、LCD顯示屏、DS18B20溫度傳感器和4G模塊等，硬件系統(tǒng)電路原理圖如圖2所示。

圖2 硬件系統(tǒng)電路原理圖Fig.2 Circuit schematic diagram of hardware system

1.2 數(shù)據(jù)傳輸原理

在實(shí)現(xiàn)機(jī)器人與云平臺(tái)服務(wù)器之間的無(wú)線數(shù)據(jù)傳輸過(guò)程中，其數(shù)據(jù)以JavaScript對(duì)象簡(jiǎn)譜（Javascript object notation，JSON）的形式傳送，利用超文本傳輸協(xié)議（hyper text transfer protocol，HTTP），HTTP協(xié)議屬于開放式系統(tǒng)互聯(lián)通信參考模型（open systen interconnection reference model OSI），模型7層結(jié)構(gòu)中的應(yīng)用層，其傳輸層是基于傳輸控制協(xié)議（transmission control protocol，TCP）實(shí)現(xiàn)的，TCP協(xié)議是可靠的、面向連接和需要三次“握手”才可以建立的字節(jié)流協(xié)議標(biāo)準(zhǔn)，進(jìn)而保證了數(shù)據(jù)安全地與高效地傳輸。

1.2.1 OSI模型概述

OSI模型是7層網(wǎng)絡(luò)物理模型，從下到上依次為物理層、數(shù)據(jù)鏈路層、網(wǎng)絡(luò)層、傳輸層、會(huì)話層、表示層和應(yīng)用層[11]。這些邏輯分層劃分代表了無(wú)線數(shù)據(jù)傳輸?shù)幕具^(guò)程，層與層之間相互獨(dú)立同時(shí)又相互依靠。原則上上層依賴于下層，而下層又為上層提供服務(wù)[12]。

在數(shù)據(jù)傳輸?shù)倪^(guò)程中，數(shù)據(jù)流遵循OSI網(wǎng)絡(luò)物理模型，數(shù)據(jù)發(fā)送端將需要發(fā)送的數(shù)據(jù)發(fā)出，數(shù)據(jù)就會(huì)從應(yīng)用層打包并封裝到物理層，并在物理層中轉(zhuǎn)化為比特流，通過(guò)Internet網(wǎng)傳送至數(shù)據(jù)接收端的物理層，然后數(shù)據(jù)層被解包并從物理層解封裝到應(yīng)用層，最終實(shí)現(xiàn)數(shù)據(jù)的傳輸功能。

1.2.2 HTTP協(xié)議概述

HTTP協(xié)議中定義了8種方法，或稱為“動(dòng)作”，分別為獲取資源（GET）、傳輸實(shí)體（POST）、傳輸文件（PUT）、獲取報(bào)文首部（HEAD）、刪除文件（DELETE）、詢問(wèn)支持（OPTIONS）、回顯診斷（TRACE）和連接代理（CONNECT）以指示操作請(qǐng)求地址（Request-URI）指定的資源的不同方式。

這8種方法都可以請(qǐng)求HTTP，但在實(shí)踐中常用get和post命令，其他請(qǐng)求方法也可以通過(guò)這2種方法間接實(shí)現(xiàn)。其請(qǐng)求過(guò)程由4個(gè)部分組成，分別為請(qǐng)求行（request line）、請(qǐng)求頭部（header）、空行和請(qǐng)求數(shù)據(jù)[13]。

1.2.3 數(shù)據(jù)傳輸方式JSON概述

JSON是一種起源于JavaScript的輕量級(jí)的數(shù)據(jù)交換形式，以鍵值對(duì)的形式傳輸信息，有多種編程語(yǔ)言都支持JSON形式，適用性廣。一個(gè)JSON對(duì)象是若干個(gè)無(wú)序的鍵/值對(duì)的集合，一個(gè)對(duì)象以左括號(hào)“{”開始，右括號(hào)“}”結(jié)束，鍵/值對(duì)組合中的鍵名寫在前面并用雙引號(hào)包裹，鍵與值之間使用冒號(hào)分隔，不同鍵值對(duì)之間逗號(hào)分隔[14]。其格式示例如下所示：{"Key1"：Value1，"Key2"：Value2}。

1.3 模式設(shè)定

4G模塊主要包含3層功能區(qū)域，即基于TCP/UDP協(xié)議的透明傳輸模式和基于HTTP協(xié)議的超文字傳輸協(xié)定常駐程式客戶（hyper text transfer protocol daemon client，HTTPD Client）模式，這兩層共同組成4G模塊的傳輸模式；另一層是AT指令模式，它是4G模塊的設(shè)置模式。

在實(shí)際進(jìn)行無(wú)線數(shù)據(jù)傳輸?shù)倪^(guò)程中，首先，用戶需要進(jìn)入4G模塊的AT指令模式來(lái)設(shè)置AT指令，待設(shè)置好后需要重啟模塊；然后用戶可以根據(jù)自身通訊的基本情況來(lái)具體選擇是透明傳輸模式還是HTTPD Client模式。

1）AT指令模式。在無(wú)線數(shù)據(jù)傳輸?shù)膶?shí)驗(yàn)中，需要先進(jìn)入AT指令模式，對(duì)模塊進(jìn)行參數(shù)設(shè)置。

首先，串口設(shè)備連續(xù)向4G模塊發(fā)送“+++”。收到“+++”后，4G模塊將用‘a(chǎn)’回復(fù)串口設(shè)備；當(dāng)串口設(shè)備收到‘a(chǎn)’時(shí)，必須在3 s內(nèi)給4G模塊發(fā)送另一個(gè)‘a(chǎn)’，并且在收到‘a(chǎn)’后，4G模塊將用“+ok”回復(fù)串口設(shè)備。此時(shí)，4G模塊進(jìn)入“AT指令模式”。在此期間，串口設(shè)備可以向其發(fā)送AT指令。

在設(shè)置完AT指令時(shí)，串口設(shè)備給4G模塊發(fā)送指令“AT+ENTM”，當(dāng)4G模塊接收到指令之后，給串口設(shè)備回復(fù)一個(gè)“OK”，這時(shí)4G模塊就回到之前的工作模式[15]。

2）網(wǎng)絡(luò)透?jìng)髂Ｊ?。網(wǎng)絡(luò)透?jìng)髂Ｊ街恍鑼?shù)據(jù)包傳送到目的節(jié)點(diǎn)，在數(shù)據(jù)傳輸過(guò)程中不對(duì)數(shù)據(jù)進(jìn)行分組、編碼、加密和截?cái)嗟热魏翁幚?，只需保證傳輸質(zhì)量即可的一種傳輸模式。在實(shí)驗(yàn)過(guò)程中，4G模塊通過(guò)4G網(wǎng)絡(luò)基站將接收到的串口數(shù)據(jù)傳輸?shù)揭蛱鼐W(wǎng)中，最后將TCP/UDP數(shù)據(jù)傳輸?shù)皆破脚_(tái)服務(wù)器。同時(shí)，云平臺(tái)服務(wù)器還可以將相關(guān)的TCP/UDP數(shù)據(jù)返回到因特網(wǎng)，通過(guò)4G網(wǎng)絡(luò)基站反饋給4G模塊，實(shí)現(xiàn)雙向通訊過(guò)程。在此模式之下，一次發(fā)送數(shù)據(jù)的最大長(zhǎng)度由打包長(zhǎng)度決定，范圍是1～1 024字節(jié)。網(wǎng)絡(luò)透?jìng)髂Ｊ焦ぷ鬟^(guò)程如圖3所示。

圖3 網(wǎng)絡(luò)透?jìng)髂Ｊ焦ぷ鬟^(guò)程Fig.3 Working process of network transmission

3）HTTPD Client模式。HTTPD Client模式是一種傳輸模式，其中接收的數(shù)據(jù)包被處理成某個(gè)組數(shù)據(jù)包，然后發(fā)送到HTTP服務(wù)器。在實(shí)驗(yàn)過(guò)程中，4G模塊通過(guò)4G網(wǎng)絡(luò)基站將接收到的串口數(shù)據(jù)信息發(fā)送到因特網(wǎng)，并在傳輸過(guò)程中對(duì)4G數(shù)據(jù)進(jìn)行分組處理，最后形成HTTP數(shù)據(jù)包并傳輸?shù)紿TTP服務(wù)器。同時(shí)HTTP服務(wù)器還將相關(guān)的HTTP數(shù)據(jù)包返回到因特網(wǎng)，并通過(guò)4G網(wǎng)絡(luò)基站反饋給4G模塊，以實(shí)現(xiàn)雙向通信過(guò)程。在此模式之下，由于串口接收緩存為1 000字節(jié)，所以7S4組包后的包大小最多為1 000字節(jié)。其工作過(guò)程與網(wǎng)絡(luò)透?jìng)髂Ｊ降膮^(qū)別在于基站、因特網(wǎng)與云平臺(tái)之間傳輸?shù)臄?shù)據(jù)由TCP/UDP數(shù)據(jù)改變?yōu)镠TTP數(shù)據(jù)包。

1.4 軟件實(shí)現(xiàn)流程

軟件部分主要根據(jù)硬件中通訊的原理圖和模型圖，通過(guò)C語(yǔ)言來(lái)實(shí)現(xiàn)對(duì)STM32微控制器的程序編譯過(guò)程。主要從以下幾個(gè)方面進(jìn)行操作設(shè)置，包括數(shù)據(jù)采集端的程序編譯、控制端的程序編譯、數(shù)據(jù)傳輸端的程序編譯和數(shù)據(jù)接收端的程序編譯幾個(gè)部分。軟件設(shè)計(jì)流程如圖4所示。

圖4 軟件設(shè)計(jì)流程Fig.4 Flow chart of software design

從圖4可以看出，實(shí)驗(yàn)中溫度傳感器采集到溫度數(shù)據(jù)后，會(huì)將其傳輸?shù)皆破脚_(tái)服務(wù)器，當(dāng)云平臺(tái)服務(wù)器成功接收數(shù)據(jù)時(shí)，將會(huì)根據(jù)收到的數(shù)據(jù)信息下載回傳指令，給STM32微控制器返回發(fā)送的溫度值，并在回復(fù)“SUCCESS”時(shí)做出“LED ON”的指令操作。這時(shí)紅色發(fā)光二極管（light emitting diode，LED）燈就會(huì)亮，以這種方式，可以通過(guò)液晶顯示器（liquid crystal disply，LCD）顯示屏和LED的亮滅來(lái)判斷是否完成雙向通訊過(guò)程。

在實(shí)驗(yàn)中采集溫度數(shù)據(jù)時(shí)，采用實(shí)時(shí)采集與傳輸?shù)姆桨?，?shù)據(jù)會(huì)持續(xù)上傳服務(wù)器，且服務(wù)器始終接收新的數(shù)據(jù)以實(shí)現(xiàn)實(shí)時(shí)更新的效果。

2 實(shí)驗(yàn)與調(diào)試

2.1 硬件搭建

在完成4G無(wú)線數(shù)據(jù)傳輸?shù)膶?shí)驗(yàn)中，將4G模塊（濟(jì)南有人物聯(lián)網(wǎng)技術(shù)有限公司生產(chǎn)的USR-LTE-7S4模塊）連接上天線、接入電源、插入4G網(wǎng)卡和通過(guò)九針串口線與STM32微控制器相連接。STM32控制芯片通過(guò)P11接口連接到DS18B20溫度傳感器，用于采集溫度數(shù)據(jù)。然后將連接好的設(shè)備安裝在機(jī)器人上，完成機(jī)器人的4G無(wú)線數(shù)據(jù)傳輸?shù)挠布罱ā＿@樣，可以在STM32微控制器程序的驅(qū)動(dòng)下完成數(shù)據(jù)的采集與傳輸，實(shí)現(xiàn)機(jī)器人與云平臺(tái)服務(wù)器之間的無(wú)線通信功能。4G模塊與其他各個(gè)部件連接，硬件系統(tǒng)如圖5所示。

圖5 硬件系統(tǒng)Fig.5 Hardware system

2.2 實(shí)驗(yàn)結(jié)果

2.2.1 數(shù)據(jù)發(fā)送與回傳

以傳輸溫度數(shù)據(jù)為例，STM32微控制器在程序的驅(qū)動(dòng)下，首先控制4G模塊進(jìn)入AT指令設(shè)置模式，待設(shè)置完成后，通過(guò)網(wǎng)絡(luò)透?jìng)髂Ｊ较蛟破脚_(tái)服務(wù)器發(fā)送溫度數(shù)據(jù)，LCD數(shù)據(jù)輸出顯示當(dāng)前采集溫度為29。當(dāng)云平臺(tái)服務(wù)器從STM32微控制器收到數(shù)據(jù)信息時(shí)，它將根據(jù)具體結(jié)果給出反饋指示，表明服務(wù)器已經(jīng)收到其發(fā)來(lái)的數(shù)據(jù)包。在此次實(shí)驗(yàn)中，服務(wù)器在接收到數(shù)據(jù)信息后會(huì)根據(jù)要求在顯示屏上顯示數(shù)據(jù)回傳是否成功，如果成功回傳就做出使LED紅燈亮的指示，回傳當(dāng)前溫度為29，LCD數(shù)據(jù)發(fā)送與回傳顯示如圖6所示。

圖6 LCD數(shù)據(jù)發(fā)送與回傳顯示Fig.6 LCD data output display

2.2.2 云平臺(tái)數(shù)據(jù)接收

云平臺(tái)服務(wù)器搭載了一個(gè)網(wǎng)頁(yè)服務(wù)器，在接收到DS18B20溫度傳感器采集到的溫度數(shù)據(jù)信息后，可以在相應(yīng)的網(wǎng)頁(yè)中顯示出來(lái)，上傳的溫度數(shù)據(jù)為29，云平臺(tái)服務(wù)器顯示結(jié)果如圖7所示。

圖7 云平臺(tái)服務(wù)器顯示結(jié)果Fig.7 Cloud platform server display results

2.2.3 網(wǎng)絡(luò)延時(shí)實(shí)驗(yàn)

機(jī)器人應(yīng)用中有2種數(shù)據(jù)傳輸，一種是機(jī)器人向服務(wù)器上傳自身采集的數(shù)據(jù)，另一種是服務(wù)器向機(jī)器人下達(dá)的控制命令。機(jī)器人自身數(shù)據(jù)采樣與上傳周期為1 s，在此情況下需要考慮4G網(wǎng)絡(luò)的網(wǎng)絡(luò)延時(shí)，期望的網(wǎng)絡(luò)延時(shí)在1 s以內(nèi)，這樣不會(huì)影響下一次上傳。服務(wù)器對(duì)機(jī)器人下發(fā)的控制指令一般是下達(dá)任務(wù)，而非實(shí)施控制，所以不需要考慮網(wǎng)絡(luò)延時(shí)，只需要考慮命令是否能準(zhǔn)確到達(dá)。

實(shí)驗(yàn)過(guò)程首先由機(jī)器人上報(bào)自身信息，而后接收服務(wù)器返回的控制指令，統(tǒng)計(jì)上傳與下達(dá)的總用時(shí)與丟包率。

經(jīng)100次收發(fā)實(shí)驗(yàn)統(tǒng)計(jì)，網(wǎng)絡(luò)延時(shí)最小值為：60.0 ms，最大值為：179.0 ms，平均值為：114.7 ms，丟包率為：0%，滿足實(shí)際使用需求。

3 結(jié)論

在機(jī)器人與云平臺(tái)服務(wù)器之間，采用STM32嵌入式系統(tǒng)和4G無(wú)線傳輸技術(shù)相結(jié)合，設(shè)計(jì)了無(wú)線數(shù)據(jù)傳輸?shù)挠布蛙浖到y(tǒng)，實(shí)現(xiàn)了數(shù)據(jù)由采集端到4G網(wǎng)絡(luò)，再通過(guò)Internet網(wǎng)絡(luò)運(yùn)營(yíng)商將數(shù)據(jù)信息最終傳輸?shù)皆破脚_(tái)服務(wù)器。最終實(shí)驗(yàn)實(shí)現(xiàn)了機(jī)器人與云平臺(tái)服務(wù)器之間的雙向無(wú)線通信功能，研究成果對(duì)無(wú)線數(shù)據(jù)傳輸技術(shù)在機(jī)器人通信的發(fā)展和應(yīng)用中具有推動(dòng)作用。