DOI：10.16652/j.issn.1004-373x.2025.16.005

中圖分類(lèi)號(hào)：TN929.5-34 文獻(xiàn)標(biāo)識(shí)碼：A 文章編號(hào)：1004-373X（2025）16-0025-06

Design of device control scheme based on smart home gateway

XUEYalu’，ZHAOZuoxi1，LIAOZhifeng2，ZHENGLi

Abstract：With thedevelopmentof smarthomes，thecentralcontrol screenhasgradually becomeamust-have device for whole housesmarthomesduetoitsexcellnt interactiveexperiene，playingacentralroleincontrolandinteraction.Inodeto solvethe problemsofcomplex protocoldockingbetweethecentralcontrolscreeandhomedevices，aswellasloweffciencyin UI interactiondevelopment，adynamicloadingoptimizationschemebasedonthecontrolprotocolandinteractiveUIof the centralcontrolscreenisproposed.Inthisscheme，theobjectmodelisusedasthecentertodigitalldescribethefunction propertiesofthecontrolleddevice.Theatributecontrolinstructionofthedeviceobjectmodelandtheconversionof Zigbee wireless protocolarerealizedbymeansofLUAanalyticalscript.UIcontrolandpagelayoutdescriptionfilearedefined，the AndroidNativeandReactNativeframeworkareusedtorealizethedynamicrenderingofuserinteractioninterface.Theatribute mapingrelationship between UIcontrolandobject modelisestablished torealizetheatributechangethattheuser's click actionbehavioristransformedintotheobjectmodel，andtheZigBeecontrolinstructionisexecutedbymeansofLUAsriptto realize thepurposeofdevicecontrol.The testing resultsshowthattheproposedschemecanachievemoreeficientaccessto smart home devices and better interactive experience.

Keywords：whole house intelligence;central control screen;dynamic UI;object model device; LUAscripting language; ReactNativeframework

0 引言

21世紀(jì)初國(guó)內(nèi)興起智能家居概念[，發(fā)展至今主要分為三個(gè)階段：1.0單品智能時(shí)代—一單臺(tái)設(shè)備的智能控制；2.0場(chǎng)景聯(lián)動(dòng)時(shí)代——可以實(shí)現(xiàn)有限的聯(lián)動(dòng)智能；2022年華為正式發(fā)布全屋智能3.0，提出全屋智能解決方案概念，進(jìn)入3.0全屋智能時(shí)代2，市場(chǎng)逐漸擴(kuò)大，其中智能中控屏的市場(chǎng)增長(zhǎng)尤為迅速。

智能中控屏是全屋智能系統(tǒng)的核心部件[3，屬于“云邊端\"結(jié)構(gòu)中的邊緣智能，在靠近子設(shè)備的邊緣側(cè)對(duì)海量數(shù)據(jù)進(jìn)行本地處理4，負(fù)責(zé)設(shè)備的集中控制管理。在操作系統(tǒng)方面，鑒于Android系統(tǒng)自身的優(yōu)越性，大多智能家居系統(tǒng)的研究設(shè)計(jì)首選基于Android系統(tǒng)開(kāi)發(fā)APP來(lái)完成交互控制[5。Android系統(tǒng)本質(zhì)上也是一個(gè)不錯(cuò)的嵌入式軟件開(kāi)發(fā)平臺(tái)，中控屏逐漸選用其作為基礎(chǔ)底層系統(tǒng)，但需要根據(jù)全屋智能應(yīng)用場(chǎng)景進(jìn)行改造。在設(shè)備通信上，通常采用智能家居行業(yè)公認(rèn)較成熟的ZigBee作為中控屏與子設(shè)備之間的通信協(xié)議。但是現(xiàn)階段行業(yè)內(nèi)仍缺乏智能設(shè)備統(tǒng)一的標(biāo)準(zhǔn)體系和網(wǎng)絡(luò)協(xié)議，需要對(duì)于屏端底層系統(tǒng)進(jìn)行代碼開(kāi)發(fā)來(lái)解析協(xié)議處理數(shù)據(jù)8，同時(shí)不同的設(shè)備也需要實(shí)現(xiàn)不同功能的UI交互界面。所以，對(duì)于提供全屋智能解決方案的廠商來(lái)說(shuō)存在以下問(wèn)題：

1）需要針對(duì)不同控制協(xié)議的設(shè)備進(jìn)行開(kāi)發(fā)，開(kāi)發(fā)工作量與所需接入的子設(shè)備數(shù)量呈線性增長(zhǎng)關(guān)系；

2）基于Android原生XML布局開(kāi)發(fā)全部UI界面，結(jié)構(gòu)樣式實(shí)現(xiàn)不夠靈活且代碼冗余、不易調(diào)整；

3）產(chǎn)品上線后需要發(fā)布整體固件包進(jìn)行全網(wǎng)推送升級(jí)，增加了開(kāi)發(fā)和測(cè)試成本，系統(tǒng)版本難以管理；

4）更新包體積龐大，升級(jí)過(guò)程依賴用戶的主動(dòng)觸發(fā)，并需要重啟生效，用戶升級(jí)成本較高且易導(dǎo)致用戶版本滯后。

本文提出一種基于中控屏的控制協(xié)議和交互UI的動(dòng)態(tài)加載優(yōu)化方案。該方案的設(shè)計(jì)亮點(diǎn)在于優(yōu)化中控屏對(duì)不同產(chǎn)品協(xié)議的快速適配和UI交互的動(dòng)態(tài)加載，提升開(kāi)發(fā)效率和用戶體驗(yàn)。

1整體架構(gòu)設(shè)計(jì)

本文優(yōu)化方案整體架構(gòu)圖如圖1所示。

圖1本文優(yōu)化方案整體架構(gòu)圖

本文優(yōu)化方案的結(jié)構(gòu)設(shè)計(jì)包括用戶面和技術(shù)面兩個(gè)方面。

1）用戶面：提供兩層UI交互呈現(xiàn)——設(shè)備快捷控制頁(yè)和設(shè)備詳情控制頁(yè)。少量高頻、必需的操作（如開(kāi)關(guān)狀態(tài)）集合在前者表現(xiàn)，后者則提供更豐富完整的功能模塊。

2）技術(shù)面：主要分為IoT管理平臺(tái)、控制協(xié)議模塊、快捷控制模塊、詳情控制模塊等4個(gè)部分。其中：IoT管理平臺(tái)負(fù)責(zé)定義設(shè)備物模型信息、設(shè)備控制LUA腳本等；控制協(xié)議模塊通過(guò)LUA腳本解析轉(zhuǎn)換物模型指令與設(shè)備可識(shí)別控制指令，實(shí)現(xiàn)設(shè)備控制；快捷控制模塊通過(guò)對(duì)自定義的卡片描述文件進(jìn)行解析渲染，生成設(shè)備快捷控制界面；詳情控制模塊采用組件化開(kāi)發(fā)模式，定義了包含布局和控制邏輯的JS文檔，通過(guò)RN框架的橋接功能與原生代碼進(jìn)行雙向通信，完成設(shè)備詳情頁(yè)渲染。

2技術(shù)面設(shè)計(jì)與實(shí)現(xiàn)

2.1控制協(xié)議模塊

2.1.1 設(shè)備物模型定義

首先在IoT平臺(tái)對(duì)具體接人設(shè)備進(jìn)行物模型屬性（property）、事件（action）定義。屬性描述家居智能設(shè)備的基本信息、狀態(tài)屬性，例如開(kāi)關(guān)狀態(tài)、溫度值參數(shù)、空調(diào)工作模式等，通過(guò)設(shè)置讀寫(xiě)操作來(lái)實(shí)現(xiàn)對(duì)設(shè)備功能參數(shù)的修改和查詢；事件則表示設(shè)備可以進(jìn)行的操作或行為，例如智能門(mén)鎖下發(fā)動(dòng)態(tài)密碼、故障報(bào)警等。完成功能定義后，平臺(tái)將自動(dòng)生成該產(chǎn)品JSON格式的物模型文件。

例如新風(fēng)設(shè)備的風(fēng)速檔位物模型定義如下：

在proprties對(duì)象中定義各功能屬性，其中windSpeed屬性定義了風(fēng)速的低、中、高、關(guān)閉4個(gè)檔位以及其對(duì)應(yīng)值，并在defaultValue對(duì)象中存儲(chǔ)當(dāng)前設(shè)備狀態(tài)值。

2.1.2 解析腳本開(kāi)發(fā)

中控屏硬件中封裝有ZigBee模塊，可以與子設(shè)備實(shí)現(xiàn)穩(wěn)定且低功耗的無(wú)線通信[10-1]。在此基礎(chǔ)上通過(guò)開(kāi)發(fā)LUA腳本實(shí)現(xiàn)統(tǒng)一標(biāo)準(zhǔn)的物模型協(xié)議轉(zhuǎn)換接口（如writerProperty、readProperty），從而實(shí)現(xiàn)物模型控制指令和具有差異化的設(shè)備ZigBee協(xié)議之間的轉(zhuǎn)換。

當(dāng)用戶在交互界面進(jìn)行操作時(shí)，觸發(fā)物模型值的更改，屏端調(diào)用LUA腳本將該物模型指令解析成ZigBee協(xié)議數(shù)據(jù)并發(fā)送設(shè)備可識(shí)別信號(hào)，實(shí)現(xiàn)功能控制；當(dāng)設(shè)備端在改變狀態(tài)時(shí)，觸發(fā)ZigBee信息發(fā)送至屏端的ZigBee協(xié)調(diào)器，屏端調(diào)用LUA腳本對(duì)ZigBee信息進(jìn)行解析，轉(zhuǎn)換成物模型結(jié)構(gòu)數(shù)據(jù)，應(yīng)用層收到數(shù)據(jù)更新會(huì)驅(qū)動(dòng)UI刷新，實(shí)現(xiàn)中控屏同步真實(shí)設(shè)備狀態(tài)。

接人新設(shè)備時(shí)，除了原有對(duì)設(shè)備自身功能以及ZigBee通信協(xié)議的開(kāi)發(fā)以外，不需要對(duì)于中控屏底層進(jìn)行代碼改動(dòng)并發(fā)布新版本，直接更新LUA腳本并發(fā)布至IoT平臺(tái)，通過(guò)云端推送到各中控屏端進(jìn)行設(shè)備接入支持。

2.2快捷控制模塊

根據(jù)Android底層操作系統(tǒng)，采用Android原生技術(shù)實(shí)現(xiàn)設(shè)備基礎(chǔ)控制功能。由于設(shè)備類(lèi)型多、業(yè)務(wù)操作邏輯繁雜且UI類(lèi)型豐富，采用MVVM的GUI架構(gòu)模式[12]將數(shù)據(jù)管理、UI繪制和邏輯控制分開(kāi)。

2.2.1 定義配置文件

在ViewModel層管理界面相關(guān)數(shù)據(jù)和操作，Model層封裝可通用的設(shè)備卡片模板，繪制模板的同時(shí)，將各模板界面元素與相對(duì)應(yīng)的數(shù)據(jù)綁定。最終以View的形式實(shí)現(xiàn)快捷控制頁(yè)，在屏端應(yīng)用層與其父Fragment或父Activity保持關(guān)聯(lián)。

例如定義一個(gè)按鈕卡片模板時(shí)，先定義一個(gè)物模型文據(jù)類(lèi)：

dataclassEnumButtonCardModelconstructor（ override val modelld： String， override val category： String， overrideval properties：JSONObject，

valoperateTd： String，

valswitchTd： String，

val des： String，

再根據(jù)設(shè)備實(shí)際狀態(tài)對(duì)物模型的數(shù)據(jù)類(lèi)進(jìn)行實(shí)例化，用于在快捷控制頁(yè)上呈現(xiàn)真實(shí)的設(shè)備狀態(tài)：

\"enumButton\" -gt;1

val operateTd Σ=Σ cardDes.optString（\"operateTd\"，\"\"）

valinfoModel Σ=Σ EnumButtonCardModel（ gatewayDevice.modelID， gatewayDevice.category，

JSONObject（gatewayDevice.properties.toString）， operateTd， cardDes.optString（\"switchTd\"，\"\"）， cardDes.optString（\"des\"，\"\"）， ）

1

另外，針對(duì)不同品類(lèi)（category）的設(shè)備編寫(xiě)頁(yè)面Config文件，用于定義具體設(shè)備UI布局以及各控件與物模型的綁定關(guān)系：

一

\"type\"：2，

\"viewType\"： \"enumButton\"，

\"operateTd\"：\"windSpeed\"，

\"switchTd\"：\"power_1\"，

\"des\"：\"風(fēng)速\"

1

2.2.2設(shè)備交互UI動(dòng)態(tài)繪制

將Config文件和設(shè)備icon圖像資源打包成設(shè)備卡片資源文件夾，并上傳至云服務(wù)器。屏端應(yīng)用在啟動(dòng)時(shí)先獲取自身綁定的設(shè)備信息，根據(jù)modeIID值從云端獲取對(duì)應(yīng)型號(hào)設(shè)備的物模型描述文件。遇到\"category\"屬性時(shí)，讀出對(duì)應(yīng)值，依照該值從云端下載卡片資源文件夾，如圖2所示。

在屏端進(jìn)行資源文件夾解析，其中“type\"值為2表示生成 1×2 尺寸的模板頁(yè)面；再根據(jù)\"viewType\"屬性獲取并創(chuàng)建“enumButton\"空白模板，通過(guò)配置文件獲取該設(shè)備當(dāng)前物模型的值，在空白模板進(jìn)行具體渲染。

圖2快捷控制頁(yè)動(dòng)態(tài)渲染流程

2.3詳情控制模塊

設(shè)備詳情頁(yè)用來(lái)展示更完整的設(shè)備功能和狀態(tài)，所需物模型數(shù)據(jù)更多、UI交互元素更豐富，需要將這部分開(kāi)發(fā)與其他交互界面的開(kāi)發(fā)進(jìn)行解耦。同時(shí)，也需要在保證渲染效果一致的情況下，提高代碼復(fù)用率，實(shí)現(xiàn)彈性布局和熱更新。為了實(shí)現(xiàn)這些特性，采用ReactNative作為基礎(chǔ)框架。在此基礎(chǔ)上，通過(guò)自定義組件、數(shù)據(jù)驅(qū)動(dòng)UI顯示的方式實(shí)現(xiàn)一套模板，適用于不同型號(hào)的產(chǎn)品。

2.3.1 封裝自定義組件

ReactNative框架提供一系列內(nèi)置控件，可以直接調(diào)用，比如用于包裹其他組件進(jìn)行布局，顯示文本內(nèi)容，顯示圖像，顯示滾動(dòng)視圖，、等是用于交互的可觸摸控件。

將高復(fù)用的部分頁(yè)面功能模塊封裝在同一個(gè)中，并定義其業(yè)務(wù)邏輯，形成獨(dú)立、可調(diào)用的自定義組件。其中復(fù)用率較高的有標(biāo)題組件、開(kāi)關(guān)組件、風(fēng)速檔位組件等。以標(biāo)題組件為例，在View中定義布局邏輯（多層View嵌套關(guān)系）和動(dòng)作定義：

{this.props.devName}

{this.props.roomName}

2.3.2 編寫(xiě)詳情頁(yè)面

每一款設(shè)備詳情控制頁(yè)的開(kāi)發(fā)都可以直接調(diào)用已封裝好的自定義組件，提高代碼復(fù)用率，比如新風(fēng)詳情頁(yè)調(diào)用標(biāo)題組件和風(fēng)速檔位組件：

roomName={this.props.device.roomName）

devName={this.props.device.devName}

（20 1gt; （20

（this.modelTab=c）}

model={this.properties.windSpeed} onChange={this._operateDevice} /gt;

2.3.3詳情頁(yè)面動(dòng)態(tài)繪制

在整個(gè)屏端應(yīng)用程序啟動(dòng)時(shí)，會(huì)對(duì)RN模塊進(jìn)行信息初始化，獲取所支持打開(kāi)詳情頁(yè)的設(shè)備信息。進(jìn)入設(shè)備詳情頁(yè)時(shí)，首先進(jìn)行數(shù)據(jù)初始化，獲取最新設(shè)備狀態(tài)屬性；然后調(diào)用ViewModel中的flow，啟動(dòng)異步操作加載指定詳情頁(yè)面。

中控屏端進(jìn)行頁(yè)面渲染時(shí)，根據(jù)控件名稱(chēng)讀取其同名JS文件，并獲取所有需要用到的物模型數(shù)據(jù)properties，再利用props和state進(jìn)行層級(jí)組件之間的狀態(tài)信息傳遞、函數(shù)回調(diào)等，同樣的組件在不同的設(shè)備頁(yè)面可以展示不同行為、狀態(tài)，組件state更新時(shí)也可以觸發(fā)自動(dòng)渲染界面 UI^[13] 。

比如不同型號(hào)的新風(fēng)設(shè)備檔位分級(jí)不一定相同，只需將該款新風(fēng)的風(fēng)速物模型檔位數(shù)據(jù)windSpeed傳給控件中的model對(duì)象，渲染出符合該款設(shè)備的檔位分級(jí)，并獲得設(shè)備的真實(shí)狀態(tài)值，形成UI。

在設(shè)備控制時(shí)，組件的狀態(tài)發(fā)生變化，系統(tǒng)會(huì)主動(dòng)回調(diào)該組件注冊(cè)的自定義處理函數(shù)。例如上述示例中針對(duì)組件的onChange方法注冊(cè)了自定義處理函數(shù)\"onChange O= {this._operateDevice]”，當(dāng)新風(fēng)設(shè)備切換風(fēng)速時(shí)，組件狀態(tài)發(fā)生變化，_operateDevice方法會(huì)被調(diào)用，最終調(diào)用LUA腳本執(zhí)行設(shè)備控制動(dòng)作。

3 無(wú)感知更新

中控屏產(chǎn)品在出廠時(shí)內(nèi)置完整APK包，包含當(dāng)前版本數(shù)據(jù)的設(shè)備配置文件和bundle插件包。當(dāng)業(yè)務(wù)拓展、升級(jí)時(shí)，修改后的新版本卡片資源文件包發(fā)布至IoT平臺(tái)，需將詳情操作頁(yè)面的全部前端代碼（包括

JavaScript邏輯、引用的靜態(tài)資源及第三方依賴庫(kù)）通過(guò)構(gòu)建工具打包為標(biāo)準(zhǔn)化bundle文件[4]，并部署至IoT平臺(tái)。

如圖3所示，中控屏應(yīng)用在啟動(dòng)或定時(shí)輪詢時(shí)，會(huì)從IoT平臺(tái)獲取最新的配置文件版本，通過(guò)與本地文件的版本號(hào)進(jìn)行比較得知是否需要更新本地文件，如果有更新，在下載解析新配置文件后通知GUI進(jìn)行頁(yè)面刷新。用戶無(wú)需下載更新整個(gè)系統(tǒng)固件代碼，也不需要手動(dòng)觸發(fā)屏端重啟，直接無(wú)感知更新。

圖3用戶端更新流程

4功能測(cè)試及結(jié)果分析

注：本文通訊作者為趙祚喜。

將該優(yōu)化方案應(yīng)用到現(xiàn)有智能家居中控屏系統(tǒng)，主要對(duì)設(shè)備控制頁(yè)面動(dòng)態(tài)生成、設(shè)備有效控制及無(wú)感知更新等功能的實(shí)現(xiàn)進(jìn)行了驗(yàn)證。在新接入一款新風(fēng)設(shè)備時(shí)，只需要定義物模型、編寫(xiě)LUA控制腳本、頁(yè)面配置文件和編寫(xiě)詳情頁(yè)面，即可實(shí)現(xiàn)自動(dòng)生成快捷控制頁(yè)和設(shè)備詳情頁(yè)，無(wú)需發(fā)布中控屏固件就可以自動(dòng)渲染生成頁(yè)面，并成功控制設(shè)備。新風(fēng)設(shè)備屏端顯示狀態(tài)圖如圖4所示。

圖4新風(fēng)設(shè)備屏端顯示狀態(tài)圖

將該方案應(yīng)用到實(shí)際項(xiàng)目中，版本更新從需要手動(dòng)下載的 190MB 系統(tǒng)整包優(yōu)化成自動(dòng)觸發(fā)下載更新的2MB插件包，并且開(kāi)發(fā)、測(cè)試用時(shí)對(duì)比優(yōu)化前的方案而言具有如表1所示改進(jìn)。

表1網(wǎng)關(guān)開(kāi)發(fā)、測(cè)試用時(shí)對(duì)比 天

5結(jié)語(yǔ)

本文介紹了一種基于智能家居中控屏進(jìn)行設(shè)備接人和控制的優(yōu)化方案設(shè)計(jì)，接人一款家居設(shè)備時(shí)只需要對(duì)于設(shè)備本身進(jìn)行ZigBee協(xié)議開(kāi)發(fā)，不涉及中控屏底層代碼更改，不需要發(fā)布新屏端固件包。交互界面的解耦與動(dòng)態(tài)渲染可以極大地提高開(kāi)發(fā)效率，且用戶在使用中控屏?xí)r不需要頻繁下載新版本和重啟就可以獲得最新的系統(tǒng)功能和UI呈現(xiàn)。

將本文設(shè)計(jì)應(yīng)用在企業(yè)的實(shí)際上線項(xiàng)目中，極大地節(jié)省了開(kāi)發(fā)、測(cè)試、市場(chǎng)維護(hù)的成本，優(yōu)化了用戶體驗(yàn)，具有一定的市場(chǎng)應(yīng)用性，對(duì)全屋智能中控屏產(chǎn)品的發(fā)展具有現(xiàn)實(shí)意義。

參考文獻(xiàn)

[1]張俠丹.中國(guó)智能家居行業(yè)研究[J].未來(lái)與發(fā)展，2021，45（12）：14-19.

[2]蔣翰林.智能家居新浪潮：從智能單品到全屋智能[N].中國(guó)經(jīng)營(yíng)報(bào)，2022-11-14（B14）.

[3]佚名.智能家居新寵兒，中控屏有什么獨(dú)到之處？[J].世界電子元器件，2023（7）：3-7.

[4]張曉東，張朝昆，趙繼軍.邊緣智能研究進(jìn)展[J].計(jì)算機(jī)研究與發(fā)展，2023，60（12）：2749-2764.

[5]李昌奇，何志琴，周恒，等.基于Android和WiFi的智能家居監(jiān)控系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)[J].現(xiàn)代電子技術(shù)，2020，43（20）：67-70.

[6]蔣志偉，王偉，劉姍，等.基于ARM的智能家居系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)[J].現(xiàn)代電子技術(shù)，2023，46（4）：177-181.

[7]姚健，劉郵政，季曦冉，等.包容性導(dǎo)向下的智能家居設(shè)計(jì)研究現(xiàn)狀與展望[J].包裝工程，2024，45（6）：1-13.

[8]劉基成，田祎然，李國(guó)鋒.基于ZigBee的嵌人式智能家居網(wǎng)關(guān)設(shè)計(jì)[J].電子制作，2023，31（22）：100-103.

[9]張靜，薛茹.基于JSBridge技術(shù)的跨平臺(tái)移動(dòng)應(yīng)用開(kāi)發(fā)研究[J].信息與電腦（理論版），2021，33（6）：100-102.

[10]劉超，徐志方，王方前，等.面向智能家居的物聯(lián)網(wǎng)操作系統(tǒng)應(yīng)用框架設(shè)計(jì)[J].現(xiàn)代電子技術(shù)，2020，43（23）：143-145.

[11]梁海潔，陳嬌英，陳延明.基于嵌入式ARM構(gòu)架的智能家居控制系統(tǒng)設(shè)計(jì)[J].廣西大學(xué)學(xué)報(bào)（自然科學(xué)版），2021，46（1）：144-149.

[12]馬利軍.Web前端架構(gòu)模式的演化及MVVM模式在 Web 前端框架中的研究[J].軟件，2023，44（7）：61-65.

[13]陳磊.一種跨平臺(tái)移動(dòng)APP開(kāi)發(fā)ReactNative方法的實(shí)現(xiàn)[J].電子技術(shù)與軟件工程，2020（10）：40-41.

[14]蘇家嘯，武永成.ReactNative技術(shù)淺析[J].中國(guó)管理信息化，2021，24（11）：192-194.

[15]雷賽楠，章文俊，李昊.基于STM32和ZigBee網(wǎng)絡(luò)的智能家居系統(tǒng)[J].電子設(shè)計(jì)工程，2023，31（7：109-112.

[16]劉正業(yè)，李震，常新峰.基于Arduino的智能家居系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)[J].電子設(shè)計(jì)工程，2021，29（6）：29-33.

作者簡(jiǎn)介：薛雅璐（2001—），女，湖南益陽(yáng)人，碩士研究生，研究方向?yàn)橹悄芗揖涌刂葡到y(tǒng)。趙祚喜（1968—），男，湖南張家界人，博士研究生，教授，博士生導(dǎo)師，研究方向?yàn)檐?chē)輛導(dǎo)航控制系統(tǒng)、計(jì)算機(jī)視覺(jué)及農(nóng)業(yè)電氣化與自動(dòng)化。廖志峰（1985—），男，廣東梅州人，廣東睿住智能科技有限公司軟件研發(fā)總監(jiān)，研究方向?yàn)橹悄芗揖涌刂葡到y(tǒng)。鄭麗（2000—），女，四川自貢人，碩士研究生，研究方向?yàn)闄C(jī)器人、機(jī)械臂強(qiáng)化學(xué)習(xí)。