為NXP Hovergames3開發的AutoSQA項目文章

減震器彈簧

MR-Bugg3 的標準減震器彈簧，WLToys 124019，非常柔軟，特別是背面土壤傳感器致動器的重量增加，它們無法承受越野車的重量。好處是減震器中的彈簧可以用更硬的彈簧代替。我從全球速賣通 ( https://www.aliexpress.com/item/1005002511575059.html ) 訂購了一套長 40mm、直徑 16mm、厚 1.4mm 的線圈（庫存線圈為 1mm）。從測量來看，這些似乎是正確的尺寸，但由于彈簧尚未到貨，我無法對其進行測試。

第 2 部分：傳感器平臺

傳感器平臺負責從環境中收集信息，在本應用中是從田間土壤收集信息。它可以分為 4 個功能部分：

• 傳感器采集板：采集板由一塊STM32F103藍色藥丸板組成（我手頭有），負責從傳感器（土壤和空氣）采集數據并進行必要的轉換，以便傳遞給NavQPlus的數據是已經處理了。
• 土壤執行器：土壤執行器是為該項目開發的具有力傳感功能的線性執行器。它負責使土壤傳感器與土壤接觸。可以在其上安裝不同類型的土壤傳感器，但本項目中使用的是 3 合 1 土壤傳感器。
• 土壤傳感器：土壤傳感器種類繁多，有些需要直接接觸，有些則不需要。這里使用直接接觸式，特別是來自 3 合 1 土壤傳感器。
• 空氣傳感器：空氣傳感器為BOSCH為本次挑戰免費提供的BME688氣體傳感器。它是一款出色的緊湊型傳感器，可提供溫度、濕度和壓力值，并集成了一種新型氣體傳感器，在 AI 模型的幫助下，可以檢測并在某些情況下區分不同的 VOC 和 VSC。

這 4 個部分共同構成傳感器平臺并連接到 NavQPlus。NavQPlus 控制采集步驟，收集傳感器數據并發布它們。下面是一個框圖，顯示了這 4 個部分的概述以及它們如何連接在一起，以及與 NavQPlus 的連接：

采集系統概覽框圖。

?

下圖顯示了傳感器平臺的所有組件：

傳感器平臺部件概述。

?

傳感器采集板

如上所述，采集板負責采集土壤傳感器（模擬信號）和空氣傳感器（I2C）的信號。它僅包含一個 STM32F103 藍色藥丸板，土壤傳感器通過緩沖放大器 (LM358) 連接到其模擬輸入（PA0 和 PA1）。BOSCH BME688 傳感器通過 I2C（PB6 和 PB7）連接。然后，采集板本身通過串行接口（PA9 和 PA10 上的 UART）連接到 NavQPlus，后者請求并接收已處理的傳感器信息。

BME688 的控制在采集板上完成，使用 BOSCH 的 BME68x 庫。從土壤傳感器模擬信號到相關土壤參數的轉換也在采集板上完成。采集板上運行的軟件可在附件（.zip文件）中找到并下載。

土壤執行器

為了讓直接接觸式土壤傳感器與土壤接觸，將其插入土壤中，我必須設計一個執行器。我選擇設計一個可以輕松進行 3D 打印并且可以在未來用于其他應用的線性致動器。我添加到該致動器的一個特殊功能是能夠感應致動力，特別是用于將托架“向下”推的力。添加這一點是因為對于他的應用程序，它可用于測量土壤的硬度，以及在它碰到堅硬的表面（如巖石）時停止/中止驅動并防止其舉起整個 Buggy。

要構建此執行器，需要以下部件：

• 3D 打印部件（8 個部件）( https://www.thingiverse.com/thing:5936797 )
• 2x 光滑棒，150mm x 6mm
• 1x T8 絲杠和螺母，150mm
• 2x LM6UU 直線軸承
• 1 個耦合器，8 毫米至 6 毫米
• 1x 28BYJ-48 步進器
• 2x 離開開關（末端停止）
• 1x 膜壓力傳感器（稱重傳感器），4mm 50g-2kg + 放大器板（https://www.aliexpress.com/item/1005001324635941.html ）
• 各種 M2.5 螺絲和螺母

該組件的設計旨在簡化 3D 打印，有利于需要組裝的較小零件，而不是較大的單件。執行器的基礎由4個部分組成，底座，2個側面和電機安裝座。所有這些都與直接擰入塑料 M2.5 螺釘（電機安裝到頂側件）或 M2.5 螺母和螺釘（側件到底板）一起擰緊。完整的組裝說明可以在 Thingiverse 頁面上找到。完全組裝好的執行器，帶有步進器、限位器和力傳感器，如下圖所示：

完全組裝的線性平臺。

?

力感測是通過使用自由移動的托架和安裝在絲杠螺母上的推桿實現的。推桿通過兩個螺釘連接到托架，但有間隙，因此它可以在不移動托架的情況下輕微地上下移動。這個推動器推動托架，在接觸點增加了一個薄膜力傳感器。需要螺釘來防止推動器旋轉，并能夠將托架拉回原位。該組件如下圖所示：

線性執行器的力傳感組件。

?

該平臺由一個簡單的電路板控制，該電路板由 Arduino Pro Mini 和 DRV8825 步進驅動器構成（參見：https ://microdigisoft.com/drv8825-motor-driver-and-28byj-48-stepper-motor-with-arduino /).我在這里忽略的一個小細節是，此步進驅動器僅適用于 8V 以上的電源電壓，因此它僅適用于幾乎充滿電的電池（2S lipo 完全充電有 8.4V）。此外，步進電機是一個 5V 部件，因此步進驅動器會使電機稍微過載。從我的測試來看，這似乎不是問題，即使沒有電流限制，電機也不會在一次完全啟動所需的相對較短的時間內變熱。另外，當沒有運動發生時，我會禁用步進驅動器，以避免過度驅動電機。Arduino 還會對力傳感器進行采樣，并在力高于閾值（開始舉起 Buggy 的力值）時中止驅動。Arduino 的這塊板的控制是通過串行 (UART) 接口使用簡單的 ASCII 樣式命令完成的，

硬件、3D 打印部件可在我的 Thingiverse ( https://www.thingiverse.com/thing:5936797 ) 上獲得，而軟件、Arduino 代碼已添加到附件部分。

空氣傳感器

使用的空氣傳感器是 BME688，這是一款 4 合 1 緊湊型傳感器，在同一封裝內包含溫度、壓力、濕度和氣體傳感器。溫度、濕度和壓力可以直接（通過 I2C）讀出，而氣體傳感器可以使用 BME AI-Studio 進行訓練，以定制其對目標應用的靈敏度。遺憾的是，由于時間限制，我無法充分利用 BME688 傳感器，特別是針對我的應用的氣體傳感器培訓尚未完成，但軟件和工具已在采集板上就位。

土壤傳感器

如前所述，它們是各種不同的土壤傳感器。根據它們與土壤相互作用/采樣的方式，它們可以分為兩組：直接接觸傳感器和間接接觸傳感器。該項目使用第一類土壤傳感器，盡管最初我計劃使用 EM 傳感器原理在土壤中感應磁場然后讀取反射和衰減的二次場來開發低成本的間接接觸土壤傳感器。但是，再次，有限的時間讓我選擇了使用現成的直接接觸傳感器的更簡單的解決方案。

實際上，我購買了幾 (4) 個現成的傳感器，它們都很受歡迎，而且很容易在網上找到。其中兩個測量土壤的 EC（電導率），為此目的使用帶有兩個外露探針的 PCB。另一個測量土壤的介電特性（電容），同樣使用帶有兩個探針的 PCB，但這次它們與土壤隔離。最后是所謂的三合一土壤傳感器，它是為家庭使用而銷售的，它使用電流原理，因此是自供電的。下圖顯示了所有 4 個傳感器：

獲得的土壤傳感器，從左到右分別是兩個 EC 傳感器、電容傳感器和三合一傳感器。

?

我在我愛植物的女朋友的幫助下，在不同的測試條件下測試了所有這四個傳感器。在“實驗和結果”部分中有更多相關信息。最后，雖然最有前途的是電容式傳感器，但還是使用了三合一傳感器，因為它是最堅固的傳感器，可以插入土壤中，并且最容易與土壤驅動平臺集成（非常長探針?。?。

為了結束本節，以及硬件部分，土壤傳感器的圖片安裝到安裝到 MR-Buggy3 的執行器：

安裝在 MR-Buggy3 上的土壤傳感器和執行器。

?

因此，從上圖可以看出，相對較重的執行器安裝在 MR-Buggy3 的背面，可憐的 Buggy 觸底反彈。嬰兒車上的彈簧太軟了，特別是在增加重量的情況下。這就是減震器中的彈簧必須更換的原因，但由于我在項目后期才意識到這個問題，新彈簧尚未到貨（而且這些彈簧的運輸時間也很長......）。

第 3 部分：大腦 (NavQPlus)

安裝并與 MR-Buggy3 集成的 NXP NavQPlus 構成了自主采樣 Buggy 的中心。它負責管理 Buggy 上發生的所有動作，在環境中四處移動，收集傳感器數據，獲取任務并跟蹤它們，并報告回采樣數據（并非所有這些都已實現......）。負責或完成這些任務的代碼開發為 ROS 2 節點，在 NavQPlus 上運行。ROS 2 節點的全局概覽以及軟件系統架構的總體概覽如下方框圖所示：

控制系統概述。

?

由此我們可以看出，NavQPlus，即ROS 2個節點的任務，可以分為4組：

• 運動：這些節點負責將 Buggy 從 A 點帶到 B 點，同時跟蹤其位置 [大部分已實現，但并非全部測試，一些參數未調整]。
• 數據采集??：該節點負責將傳感器移動到土壤執行器的位置，從整個采集板上的傳感器收集數據，并將它們發布到采集服務器（集線器）[大部分已實現]。它的代碼可以在這里找到：https://github.com/NotBlackMagic/AutoSQA-Acquistion
• Mission Planning（和路徑跟隨）：這些節點負責向任務服務器（Hub）請求一個新的Mission，并使Buggy跟隨任務：在定義的點跟隨任務路徑和采樣點，以及避開障礙物和其他危險 [未實施]。
• 圖像處理：這些節點負責通過深度感應立體相機設置定位越野車路徑上的障礙物，并通過圖像識別在環境中找到有趣的特征。[只實施了立體相機的基本測試]。

其中一些部分，如運動和圖像處理，也可以獨立用于其他應用程序。所有 ROS 2 節點均使用 ROS 2 Humble 開發，并經過測試可在運行預裝 ROS 2 的 Ubuntu 22.04 映像的 NavQPlus 上運行（https://github.com/rudislabs/navqplus-create3-images/releases/tag/ v22.04.2 ）。

以下小節將更詳細地討論其中一些部分并給出說明。

運動

當前版本的 PX4 自動駕駛儀 Beta V1.14 僅支持流動站和船的兩種飛行（駕駛？）模式，框架類型：手動模式和任務模式，后者也僅支持 GPS。( https://docs.px4.io/main/en/getting_started/flight_modes.html#rover-boat )。由于這個原因，也因為我的項目需要對 Buggy 進行位置控制，我決定在 NavQPlus 上運行的 ROS 2 中為 MR-Buggy3 實施一個完整的、離板的、運動和測距系統。我將其稱為運動系統，并且我嘗試以一種方式設計它，以便將來可以將其基礎轉移到 PX4 自動駕駛儀上。也正是在這里，開發的車輪編碼器被集成到整個系統中。

Locomotion 系統作為一個 ROS 2 包，由 7 個節點組成，每個節點在整個系統中只做一小部分。這些節點之間的交互，使用的消息類型和接口，以及每個節點的 python 文件的名稱，如下方框圖所示：

運動子系統概述框圖。

?

在我更好地解釋這些節點中的每一個之前，我們將看看我們如何將運行在 FMUK66 上的 PX4 連接到 NavQPlus 并將其集成到 ROS 2 中。從 Beta V1.14 開始，PX4版本，將 PX4 連接到板外 PC 的兩種主要方式：使用 MAVLink 或使用 uROS 鏈接（使用 microDDS）。uROS 鏈接是 V1.14 版本的 PX4 的新鏈接，我只是用 SITL 模擬對其進行了簡短的測試，但它大大簡化了與 PX4 之前版本的 ROS 的集成。讓我們快速瀏覽一下如何設置它。

PX4 通過 uROS (microDDS) 到 ROS

在PX4端，啟動microDDS服務很簡單，在SD卡/etc/extras.txt中添加如下啟動命令即可，當microDDS服務要運行在以太網上時（受到推崇的）。另請參閱： https: //docs.px4.io/main/en/modules/modules_system.html#microdds-client和https://docs.px4.io/main/en/ros/ros2_comm.html。

set +e
microdds_client start -t udp -p 14551 -h 10.0.0.3
set -e

或者這個，如果它要在串行鏈路上運行（不推薦并且可能由于串行鏈路的低帶寬而導致問題）：

set +e
microdds_client start -t serial -d /dev/ttyS3 -b 921600
set -e

這些命令啟動 PX4 上的 microDDS 服務，它將在選定的接口上發布定義的 uORB 消息，然后可以通過機外計算機端的 uROS 訪問（此處為 NavQPlus）。通過此接口發送和接收的 uORB 消息在文件中定義：src/modules/microdds_client/dds_topics.yaml. 根據應用程序，應該添加一些額外的 uORB 消息，比如能夠直接控制 Buggy，/fmu/in/manual_control_setpoint必須啟用消息，這可以通過在訂閱下添加此行來完成：

- topic: /fmu/in/manual_control_setpoint
  type: px4_msgs::msg::ManualControlSetpoint

PX4、FMUK66 端的設置完成后，我們可以繼續進行外接計算機端的設置，這里是 NavQPlus。

在這里它就像遵循任何 uROS 教程一樣簡單，就像可以在這里找到的官方教程一樣：https: //micro.ros.org/docs/tutorials/core/first_application_linux/也可以在這里找到https://github.com/ Jaeyoung-Lim/px4-offboard/blob/2d784532fd323505ac8a6e53bb70145600d367c4/doc/ROS2_PX4_Offboard_Tutorial.md，有關 PX4 (SITL) 案例的更具體教程。本質上，uROS 工具必須被克隆、構建 (colcon)、創建代理、構建和獲取它并最終將代理作為 ROS 2 節點運行。有了這個，PX4 消息現在可以作為 ROS 2 主題使用。要使用它們，請不要忘記將 ROS 2 的 PX4 消息定義克隆到您的 ROS 2 工作區，可在此處找到： https: //github.com/PX4/px4_msgs 。

我只能用 SITL 模擬測試這個接口，因為在我能夠將我的 MAVLink 實現轉移到 ROS 2 之前，我通過錯誤地將 USB 連接到串行適配器燒毀了我的 FMUK66 MCU：

USB 轉 UART 適配器插入方向錯誤。

?

適配器 PCB 通常熱縮到 USB 到 UART 適配器，但我將其移除以便我可以恢復 RX-TX 引腳。添加此節點是為了在執行切換到 uROS（和 microDDS）連接時，它之后的所有節點都可以直接與 PX4 交互。

消息轉換

該節點采用 PX4 ROS 主題并將它們轉換為 ROS 2 標準消息等價物。在這種情況下，它獲取“Sensor GPS”、“Sensor Combined”和“Attitude”PX4 消息，并將它們轉換為“NatSatFix.msg”和“Imu.msg”消息，然后由 Pose Estimation 節點使用，由機器人本地化包。

里程計

該節點獲取“Wheel Encoder”PX4 消息并使用阿克曼里程計模型（靈感來自：https://medium.com/@waleedmansoor/how-i-built-ros-odometry-for-差動驅動車輛無編碼器 c9f73fe63d87）。Ackermann 是 MR-Buggy3 使用的轉向類型，它給出了 Buggy 在給定轉向角和前進速度下的位置變化。這也是使用開發的車輪編碼器的地方，在沒有 GPS 的情況下獲得 Buggy 的位置估計。

現在，里程計節點僅將車輪編碼器信息用于前進速度，并從發送到 Buggy 的轉向命令中獲取轉向角（根據“實驗和結果”部分所示的測試適當縮放）。未來，特別是當Buggy的4個輪子都有編碼器時，編碼器的數值也可以用來計算Buggy的實際轉向角度。根據差動齒輪引起的內輪和外輪的速度差計算得出。它們還可以用于預測輪胎打滑并在里程計節點中為此校正位置估計。

速度控制器

顧名思義，速度控制器節點控制越野車的速度。它采用 Twist 消息主題，設置 Buggy 的目標線速度和角速度，以及來自 Odometry 節點的 Odometry 消息主題作為反饋。對于前進速度，實現了一個 PID 控制器，它從 Twist 主題中獲取目標前進速度，并將其與當前前進速度進行比較，從 Odometry 主題中計算，并計算傳遞給 Buggy 所需的手動控制命令通過PX4到電機ESC。

該 PID 控制器是通過不接觸土壤的越野車、自由旋轉的輪子進行調整的，可能需要針對田間以外的實際應用進行調整。此外，由于速度控制器是在車輪不與土壤接觸的情況下開發的，因此實際上只使用了一個車輪編碼器值（提供更高 RPM 的那個），這是因為車輪自由旋轉并且由于差動齒輪, 一個輪子通常根本不旋轉或慢得多（這同樣適用于里程計節點）。

下圖顯示了當設置（并移除）3 m/s 的目標速度時，由 PID 回路控制的 Buggy（橙色）的前進速度：

速度控制器 PID 回路輸出

?

測量的 Buggy 速度中的大尖峰部分是由于編碼器分??辨率低，低速有問題，部分是因為這幾乎是 Buggy 速度的下限，因此當 PID 回路將輸出降低到很多時，ESC 停止完全旋轉電機而不是更慢。但總而言之，它奏效了，至少在替補席上是這樣。

轉向控制沒有 PID 回路，它只是采用所需的角速度，并通過使用阿克曼模型，將它們轉換為轉向角，然后將其轉換為手動控制命令。

位置控制器

顧名思義，位置控制器節點控制著越野車的位置。它采用 Stamped Pose 消息主題，設置 Buggy 的目標位置（姿勢被忽略），以及來自 Odometry 節點的 Odometry 消息主題作為反饋。然后計算必要的線速度和角速度，這些速度作為 Twist 消息發布給速度控制器。

實施的位置控制器始終通過弧線從當前位置移動到目標位置，其中 Buggy 的開始和結束姿勢都與該弧線相切。這意味著線速度和角速度在整個運動過程中都是恒定的，除了線速度在開始和結束時的斜坡上升和下降。參見下圖，作為位置控制器計算的軌跡示例，用于將 Buggy 從其起始姿勢移動到目標位置（僅使用目標位置，姿勢/旋轉由位置控制器強制執行）：

位置控制器沿著弧線計算軌跡。

?

為了進行測試，通過設置目標姿勢，通過 RVIZ 給出了目標位置。此外，在測試期間，使用的 Odometry 消息主題是由 Odometry 節點發布的消息，而不是由 Pose Estimation 節點發布的消息，因為后者不能很好地與 Buggy stationary 一起使用，本應如此。

可悲的是，由于燃燒了 FMUK66，并且沒有事先拍攝任何結果/照片，我沒有顯示位置控制器實際工作的結果......

姿勢估計（robot_localization 包）

為了更準確地估計越野車的位置，里程計信息應與 IMU 和 GPS 信息融合。這就是這個節點所做的。Pose Estimation 節點運行兩個 EKF 過濾器實例，一個用于將里程計數據與 IMU 數據融合并將它們發布為局部里程計主題，另一個將其與 GPS 數據融合并將它們發布為全局 Odomtry 主題。這些節點來自 robot_localization 包，我按照包文檔中提供的說明和設置進行操作：http://docs.ros.org/en/melodic/api/robot_localization/html/index.html

重要的是我還沒有調整任何參數，特別是必須修改協方差矩陣以反映 Buggy 的實驗結果，以便從這些節點獲得準確的位置估計。

鍵盤控制器

該節點用于測試，它發布速度控制器使用的 Twist 消息。獲取鍵盤輸入并將其轉換為 Twist 消息的線速度和角速度。

所有這些節點都可以在我的 GitHub 上找到，可以克隆并用作 ROS 2 包： https: //github.com/NotBlackMagic/MR-Buggy3-Offboard

數據采集

如本節開頭所述，該節點負責將傳感器移動到土壤執行器的位置，從傳感器收集數據，遍及采集板，并將它們發布到采集服務器（集線器）（大部分已實現）。數據采集??節點有兩個串行連接，一個連接到執行器控制器板，一個連接到采集板。這意味著我必須使用 NavQPlus 的兩個 UART 接口，總共有 4 個可用。現在實際上并沒有 4 個易于訪問的 UART 接口可用，有些是隱藏的，有些是已經使用的：

• UART1（“/dev/ttymxc0”）：這個位于用于藍牙模塊的特殊接頭上，不易訪問。
• UART2（“/dev/ttymxc1”）：這個在 JST-GH 接頭上很容易訪問，但用于串行終端。要使用它，必須先使用以下命令停止該服務systemctl stop serial-getty@ttymxc1 .service，然后我們必須允許自己使用命令實際使用它。sudo chmod 666 ttymxc1.這是用于連接執行器控制器板的那個。
• UART3（“/dev/ttymxc2”）：這個在 JST-GH 標頭上很容易訪問并且可以免費使用。不需要額外的配置或命令。這是用于連接采集板的那個。
• UART4（“/dev/ttymxc3”）：在 JST-GH 接頭上也很容易訪問，但默認情況下它連接到 Cortex-M7，并且不容易用于 Cortex-A53 內核以及 Linux。請參閱：https://community.nxp.com/t5/i-MX-Processors/IMX8-mini-UART4/td-p/935322

通過這些接口交換非常簡單的 ASCII 命令和數據。對于空氣傳感器采集，本節點簡單發送一個請求命令，“A;”，然后采集集線器對BME688進行采樣并返回一個數據字符串，例如“T: 25.65, H: 49.45, P: 1015.65, R: 80526.12 ”。要對土壤進行采樣，還需要執行幾個步驟，首先將歸位命令發送到執行器“H;”，然后該節點將等待直到通過輪詢執行器“I;”完成移動。之后，它發送向下移動命令“D50；”，將執行器向下移動 50 毫米，土壤傳感器隨之進入土壤。節點再次通過輪詢執行器等待完成。當到達該位置時，該節點向采集中心“S;”請求數據，然后對土壤傳感器進行采樣并返回采樣和處理后的數據。最后，該節點向執行器發送另一個歸位命令，將土壤傳感器移回其靜止位置。然后將所有收集到的數據與 Buggy 的當前位置打包在一起，來自 Odometry 消息主題，并通過 UDP 發送到服務器。

它的代碼可以在這里找到：https://github.com/NotBlackMagic/AutoSQA-Acquistion

圖像處理

如“第 1 部分：機器人平臺 (MR-Buggy3) ”部分所示，NavQPlus 的重大改進/補充之一是第二個 ISP，相機接口，允許實施立體相機設置，用于深度感知。在同一部分中，我還展示了基于兩個 Google Coral 相機創建的立體相機設置，它們之間的距離為 70 毫米。理想情況下，立體相機對應該是具有全局快門和固定焦距的低分辨率黑白相機（例如來自 ArduCam RPI 全局快門相機的 OV7251 或來自新的 RPI 全局快門相機模塊的 IMX296），但 Google Coral 相機在這個階段。

用于連接相機的軟件是 Python 中的 OpenCV。開發的第一個測試代碼是從立體相機創建 3D 立體紅青色圖片。為此遵循的代碼和教程是： https: //learnopencv.com/making-a-low-cost-stereo-camera-using-opencv/

看下面MR-Buggy3的3D Anaglyph圖片，3D效果不是最好的，需要相當多的調整才能將兩個幀彼此靠近以改善效果。

生成立體 3D 圖片的立體相機。

?

使用立體攝像頭設置的真正目的是在 Buggy 上獲得深度感知，并進行障礙物檢測和避開。由于時間限制，我只能開始這部分，啟動并運行基本軟件，并嘗試使用相機分辨率（參見“實驗和結果”部分）和視差參數校準。同樣，使用的教程和代碼來自此處：https://learnopencv.com/depth-perception-using-stereo-camera-python-c/

請參見下方視差校準 GUI 的示例屏幕截圖，底部顯示視差，右側顯示原始左右攝像頭圖像，右側控制臺顯示幀時序和幀速率（使用 320x240 分辨率） .

立體相機視差標定、深度感知標定。

?

我必須在這里補充一點，這是我第一次接觸 OpenCV，在 NavQPlus 和兩個 Coral 相機上使用 OpenCV 和 python 的幾乎完美的工作流程使它成為一個很棒的體驗，并將繼續探索這條道路！我還必須對https://learnopencv.com網站的作者大聲疾呼，指南和代碼示例非常棒！

雖然所有使用的代碼大部分只是來自https://learnopencv.com ( https://github.com/spmallick/learnopencv )的代碼，我還是把它添加到我的 GitHub 上，這樣它就可以即插即用了NavQPlus： https: //github.com/NotBlackMagic/NavQPlus-OpenCV

第 4 部分：圖形用戶界面

為了在更高層次上控制 Buggy、計劃任務和監控采樣傳感器數據，開發了一個 GUI 界面。開發的GUI界面使用Unity游戲引擎。這個 Unity 項目有兩個主要任務，即根據使用的輸入生成任務計劃、生成路徑和樣本位置以及以簡單的方式向用戶顯示樣本數據。現在只有部分實現了。

從顯示采樣傳感器數據開始，Unity 項目托管一個 UDP 服務器，Buggy 可以向其發布傳感器數據消息。傳感器數據消息包含采樣傳感器值以及采樣位置。然后在 Unity 項目中使用它來生成顯示傳感器值的彩色熱圖的紋理。傳感器值按可配置的半徑擴展。這可以在下圖中看到，其中顯示了采樣的氣溫數據（覆蓋有地形的自上而下圖像）：

傳感器數據表示示例。

?

該系統不僅限于從 Buggy 接收數據，事實上，許多不同的傳感器站，無論是移動的還是固定的，都可以發送帶有位置的傳感器數據，所有這些都可以在 Unity 中合并到一個簡單的熱圖表示中。

這個 Unity 項目的第二個任務是在高層控制 Buggy。我們的想法是，我們可以通過遙測 MAVLink 連接武裝 Buggy，然后 Buggy 將從 Unity 服務器請求執行任務。只實現了這一點，MAVLink 連接正常，可以從 Unity 項目武裝 Buggy（它還將 Buggy 設置為手動控制模式，這是運動部分所必需的）。

關于通過 MAVLink 設置飛行模式的旁注，我在官方文檔中找不到任何關于在“command_long”MAVLink 命令中使用哪些參數、值來切換到特定模式的信息……幸運的是有人在社區發現了這一點，從我的測試來看它們似乎是正確的：https://discuss.px4.io/t/mav-cmd-do-set-mode-all-possible-modes/8495

還實現了一個簡單的點擊和拖放路徑創建，以及路徑平滑：將尖角轉換為圓弧，可以由 Buggy 實際執行的運動，以及位置控制器的工作方式。如下圖所示（藍色為原始路徑，來自點擊和放置，紅色為帶圓弧的平滑路徑，完整的圓圈顯示為調試步驟）：

路徑平滑示例。

?

遺憾的是，這就是實現的功能停止的地方，沒有從繪制的路徑創建任務，也沒有將路徑傳輸到 Buggy（還），這也將通過 UDP 連接完成（存根代碼已經存在）。

Unity 項目可在我的 GitHub 上找到： https: //github.com/NotBlackMagic/AutoSQA-Hub

實驗和結果

本節包含一些、記錄的、為該項目所做的實驗以及獲得的結果。

越野車測試

為了正確實施運動軟件來控制 Buggy，我必須首先做一些實驗來收集 Buggy 的基本駕駛特性：PX4 手動控制命令值到真實世界的駕駛。為此進行了兩項測試，首先是為了獲得前向推力手動控制命令與實際越野車速度之間的關系。Buggy 速度是在輪子懸空的長凳上獲得的，并使用了開發的車輪編碼器。結果如下圖所示：

手動控制推力與 MR-Buggy3 的前進速度。

?

因為這個結果是在車輪自由旋轉時獲得的，所以現實世界的速度會更低，應該在未來通過現場測試進行修正。此外，通過減少電機傳動裝置獲得的結果，因此開箱即用的 MR-Buggy3 將具有更高的速度。最后，使用的PX4固件為V1.14 Beta，增加了倒車功能。

接下來的測試是獲取轉向手動控制指令與實際轉向角之間的關系。用于測量轉向角的設置如下圖所示：

轉向角校準設置。

?

可以看出，一根棍子綁在輪子上，測量了與靜止的距離。通過一些基本的三角函數，我們可以得到實際的轉向角，如下圖所示：

手動控制轉向與 MR-Buggy3 的轉向角。

?

此結果適用于開箱即用的 MR-Buggy3，因為未對轉向硬件或參數進行任何更改。然后將獲得的關系用于里程計和速度控制器 ROS 2 節點中的阿克曼計算。

采集和傳感器測試

如前所述，在“第 2 部分：傳感器平臺”一節中，我購買了幾個（4 個）不同的土壤傳感器。然后我和我的女朋友一起測試了它們，因為她喜歡植物和園藝，所以很高興能測試一些土壤傳感器。我們設置了兩種不同的測試，一種用于評估傳感器輸出與土壤濕度的關系，另一種用于查看傳感器對 pH 值的免疫力。

第一個測試，土壤濕度，我們使用便宜的盆栽土壤混合物，并用相同數量的土壤填充 5 個盆。然后將一個晾干以獲得干重，同時添加另外 4 種不同量的水（一種不加水）。然后，這給了我們 5 種不同且已知的水與土壤混合物。然后使用每個土壤傳感器對土壤進行采樣，并為每個盆使用每個傳感器采樣 5 個點，并對結果進行平均。下圖顯示了獲得的結果（請參閱“第 2 部分：傳感器平臺”部分以了解所使用的傳感器）：

土壤傳感器與土壤濕度水平。

?

我們可以看到使用電容式傳感器獲得的最佳結果，這也是預期的，因為通常認為它對土壤礦化等其他變量的依賴性較低，然后是其他測試傳感器。

使用土壤傳感器進行的第二項測試是評估與 pH 水平的依賴性，并測試三合一土壤傳感器的 pH 傳感器。這是使用 2 種不同的瓶裝水完成的，具有不同的 pH 值，一種堿性和一種酸性，以及中性樣品（蒸餾水）。本實驗的結果如下圖所示：

土壤傳感器與 pH 值。

?

我們可以看到只有三合一土壤傳感器對 pH 水平具有單調響應，但遺憾的是對于測量輸出、濕度和 pH 值。所有其他傳感器給出了非常不同的值，特別是蒸餾水。我的猜測是，這是由于不同的礦化作用而不是 pH 值，因為所使用的瓶裝水之間存在差異，并且礦化度高于蒸餾水（應該接近 0）。應進行另一項測試，其中只有礦化發生變化，同時保持 pH 值接近中性。

最后，對致動器力傳感器進行了測試/校準。這是通過放置在土壤傳感器探頭下方的秤來完成的，土壤傳感器探頭由土壤執行器固定，然后在頂部添加不同的重量并記錄秤輸出和力傳感器輸出。有關所使用的設置，請參見下圖：

土壤執行器力傳感器校準。

?

該測試的結果如下圖所示。假設土壤探針的圓形橫截面是扁平的，則計算壓力。

力傳感器輸出與施加的力。

?

OpenCV 深度測試

我用深度感測軟件、視差校準、不同的分辨率做了一些測試，并記錄了用它們實現的幀時間和幀速率：

深度映射分辨率與幀時間。

?

Bellow 也是其中 3 種分辨率生成的視差圖的比較。場景與“圖像處理”部分中所示的場景相同，帶有立體 3D 圖片。差異部分是由于使用的分辨率不同，但也由于每個使用的參數不同。

不同分辨率的視差圖。

?

未來的工作

從這個項目的整個過程中可以看出，有很多未完成的部分。對于未來的工作，我將主要集中在改進開發的 Wheel Encoder，添加 CAN 接口并支持 Buggy 的所有 4 輪。以及運動部分，并致力于將其部分移動到 PX4 自動駕駛儀固件中（已經在 Twitter 上就此進行了一些聯系和合作興趣）。我還將使用 OpenCV 在 NavQPlus 上繼續探索立體相機設置。我仍然想開發基于 EM 的土壤傳感器，但會看到。

貢獻和社區參與

我對 NXP GitBooks 做了兩個小貢獻。首先是 MR-Buggy3 構建指南。添加了有關使用帶有 T 型電源連接器的 ESC 時安裝沖突的部分（PR： https: //github.com/NXPHoverGames/GitBook-NXPCup/pull/2）。其次是 NavQPlus GitBook，添加了有關在 NavQ GitBook 中通過以太網使用 MAVLink 的章節，并進行了更改以反映使用的 Ubuntu 22.04 圖像（PR：https: //github.com/NXPHoverGames/GitBook-NavQPlus/pull/7）。

我也在努力將 Wheel Encoder 更好地集成到 PX4 固件中，目前我還沒有做任何 PR，因為驅動程序非常簡單和早期，我想先把它刷出來并更好地測試。

?