描述

這是一篇關于我為 NXP Hovergames3 開發的 AutoSQA 項目的文章，包含說明、演示、實驗和經驗教訓。

第 1 部分：機器人平臺 (MR-Buggy3)

這個名為 AutoSQA 的項目使用 NXP 的 Mobile Robotics Buggy3 (MR-Buggy3) 套件作為機器人基礎。這個套件本身使用 WLToys 124019 RC Buggy 底盤作為基礎，除了這個 buggy 之外還包含一個飛行（在這種情況下是驅動器？）管理單元，帶 GPS 和調試器的 FMUK66 套件，一個更好的 RC 遙控器（FlySky FS-i6s） 、ESC 和伺服，以及機械部件（兩個帶支架的 PCB）來創建機器人基礎。下面的圖片顯示了我收到的完整套件及其零件：

MR-Buggy3 是按照 NXP Cup Car Gitbook 的構建說明構建的，可在此處找到：https ://nxp.gitbook.io/nxp-cup/mr-buggy3-developer-guide/mr-buggy3-build-指導。說明非常清楚，我沒有遇到任何問題，所以我不會在這里重復。相反，我只會展示和寫下我對 MR-Buggy3 平臺所做的更改，特別是對 WLToys 124019 底盤所做的更改，如下所示：

• 新電池座：為更大的電池設計了電池座（在本例中為 OVONIC 的 2S 5200 mAh ( https://www.amazon.es/-/pt/gp/product/B08NJKB456 )）。
• 新的驅動齒輪：改變了電機支架和小齒輪（庫存 27T 到 17T）以獲得更大的齒輪減速（從庫存 4.074:1 到 6.47:1），因此將最高速度（庫存 55 公里/小時）降低到更高合理的 35 公里/小時。
• RC 和遙測支架：設計了用于 RC 和遙測接收器的支架以及用于 RC 天線的 V 型支架。
• 背面安裝點：為后減震器的 PCB 中板設計了一個安裝支架，帶有用于附加部件的垂直安裝點，取代了擾流板作為支架，以及一個帶有垂直安裝點的互補“L-Holder”，用于頂板。
• 車輪編碼器：開發并添加了帶有簡單 PX4 集成的車輪編碼器。

在接下來的小節中，我將更詳細地介紹其中的每一個，并提供有關如何使用和/或復制它們的說明。

電池座

MR-Buggy3的電池座只能裝最大100x10x10mm的電池，我選電池的時候不知道（套件還沒到）。所以我最終買了一個對這個支架來說太大了的。具體來說，我購買了 5200 mAh（138x46x24 毫米）的 OVONIC 2S 50C Hardcase LiPo，它看起來非常適合具有充足容量和硬殼以提供額外保護的應用。因此，我有兩個選擇，要么用較小的電池更換電池，要么想出一種新的安裝解決方案。我采用了后一種方法，設計并測試了兩種不同的安裝選項。我想出的第一個選擇是水平安裝電池，用立管支架將其抬到越野車的塑料裙邊上：

第二個是垂直安裝電池的，有一個支架將電池固定在 MR-Buggy3 中板/驅動軸蓋上：

我最終使用了后一種，因為它可以更好地保護電池并降低電池，使越野車的重心 (CG) 保持較低并更靠近中心線，從而提高穩定性。支架是 3D 打印的，STL 文件可在附件部分下載。它通過 buggy 側板上的 3 個孔擰入到位，裙子上已經有一些未使用的孔，帶有 25mm 長的 M2 螺釘和螺母。

傳動裝置

WLToys 124019 底盤的 MR-Buggy3 的原裝驅動齒輪比非常高，專為高最高速度（55 公里/小時）而設計，并不真正適合經常使用低得多的驅動速度的機器人應用并且需要。這樣做的問題是它限制了可達到的最低行駛速度，即電機（和車輪）開始旋轉的極限，并降低了 Buggy 的速度控制分辨率。這就是我決定改變資產負債率的原因。

經過一些研究，我發現了一篇關于更換原裝電機支架和小齒輪的好文章：https ://www.quadifyrc.com/rccarreviews/the-ultimate-pinion-gear-guide-for-wl-toys-144001-144002- 144010-124016-124017-124018-124019。雖然這篇文章主要關注在用無刷電機替換原廠有刷電機時改變傳動裝置（這也是將來要進行的一次重大升級！），但它為我指明了正確的方向。然后我訂購了一個可調電機安裝套件 ( https://pt.aliexpress.com/item/1005004690257050.html )，它帶有幾個兩個不同的小齒輪，但我還訂購了一個額外的更小的小齒輪，一個 T17一個（https://pt.aliexpress.com/item/1005004692034775.html ）。

要更換電機支架，必須拆下 WLToys 中板。接下來，可以通過卸下這兩個螺釘（我看起來不同的螺釘）從底板上擰下備用電機支架：

這些螺絲看起來很牢固，鎖緊力很強，我無法用螺絲刀卸下我的螺絲，只能將它們鉆出來……后來我讀到一個更好的解決方案是用熱來軟化鎖-緊，總有東西要學！這樣就可以將電機支架連同電機一起拆下。下一步是從電機上拆下備用小齒輪，這也是通過拆下一個非常牢固的鎖緊螺釘（在小齒輪中）來完成的，它可能再次被熱軟化但我鉆了出來。將電機固定在電機支架上的兩個螺釘重復了這個故事，通過鉆出它們，我也損壞了電機，不得不購買一個替換的。長話短說，拆下原裝電機支架和電機是一個相當大的挑戰，并指望打破兩者！電機后，

現在因為電機將更靠近驅動齒輪和驅動軸，所以必須對驅動排水蓋（如下圖所示）和頂部中間板進行一些調整切割。很好，兩個部件都來自非常柔軟的塑料：

接下來我們可以將電機安裝到新的電機支架上。電機首先不應擰緊到電機支架上，以便調整其位置。在此階段，還要將新的小齒輪添加到電機中，并擰緊一點。然后可以將組件放置到位，并調整電機位置，使新小齒輪與驅動齒輪接觸良好。再次拆下組件，現在將電機緊緊地擰到電機支架上，對螺絲也加一些鎖緊，最后將電機支架固定到底板上。其結果如下圖所示：

T17 的配合非常緊密，電機和驅動軸之間幾乎沒有間隙，因此這是可以使用的最小小齒輪。之后，將中板擰回原位（不要忘記添加電機安裝支架的驅動軸軸承支架頂部），并進行必要的調整/切割以為現在更近的電機騰出空間。圖片顯示再次完全組裝，中間板有切口：

這次冒險給我們帶來了新的整體傳動比從 4.074:1 增加到 6.47:1，增加了 37%，將最高速度從超過 55 公里/小時降低到更合理的 35 公里/小時，額外的好處是增加扭矩！

我也有用一個帶編碼器的電機替換電機的想法，甚至訂購了一個（較小的 RS-385 電機：https://www.ebay.com/itm/191880076979 ）但結果證明它有一個短軸穿過電機支架并在其上安裝小齒輪。

背面安裝點

如前所述，該項目的目標是對田間土壤進行采樣，實現這一目標的方法之一是使用與土壤直接接觸并穿透土壤的傳感器。為了能夠在這個 Buggy 平臺上使用這種類型的傳感器，我們設計了一個線性執行器來將這種土壤傳感器推入（和提升）到地下。這將在“第 2 部分：傳感器平臺”部分進一步解釋。該執行器必須安裝到 MR-Buggy3 上，最佳位置是在 Buggy 的背面，必須設計定制的安裝硬件。

開發了兩個安裝支架，以創建兩個垂直安裝點，增加安裝穩定性。第一個支架安裝在后減震器上并取代后擾流板，因此必須將其作為中板的安裝支架移除。

要安裝此支架，在 3D 打印后，第一步是拆下擾流板支架并將新支架滑到后減震器上。然后用四個自攻螺釘將其固定到位，類似于前減震器上的支架。結果如下圖所示：

接下來將 4 個 M2 螺母添加到此支架，兩個從波紋管插入，兩個從后面插入槽中。這些螺母與 M2 螺釘結合使用，用于將中間板擰到支架上。最后，將 4 個 M2.5 螺母插入支架背面，形成垂直安裝點。組裝可以在下圖中看到：

第二個安裝支架用于頂板，通過 4 個 M2.5 螺釘和螺母固定在頂板上。該安裝支架背面有可容納 6 個 M2.5 螺母的空間，增加了額外的 6 個垂直安裝點。內4與下支架的安裝點對齊。帶有兩個支架的完整組件如下圖所示：

這些安裝點稍后用于將土壤傳感器致動器安裝到 Buggy，但它們也可用于其他硬件/傳感器，如后部安裝的距離傳感器，例如超聲波傳感器陣列。兩個支架的 CAD (.STL) 文件可在附件部分下載。

遙控/遙測支架

按照構建指南，MR-Buggy3 上的 RC 接收器和遙測單元的標準放置位于頂板的末端，彼此堆疊并用雙面膠帶固定到位。此放置選項會干擾將任何東西垂??直安裝到 Buggy 的背面，例如從上方添加的支架，因此必須更改 RC 接收器和遙測單元的放置。

為此，我為遙測單元和 RC 接收器設計了一個支架，將它們安裝在離頂板末端更遠的位置，更靠近 FMUK66。同時我為 RC 接收器天線設計了一個天線支架，將它們固定在 V 形（天線的推薦方向）。支架和天線支架通過 M2x7mm 螺釘從底部擰到頂板上。天線通過天線支架中的摩擦固定，而接收器和遙測單元則通過扎帶固定到位。下圖顯示了完整的裝配：

這些支架的 CAD 文件可在我的 Thingiverse 上找到，并且可以輕松進行 3D 打印：https://www.thingiverse.com/thing :5890392

RC接收器RSSI

隨附的 RC 接收器 FS-iA6B 的庫存固件不提供任何 RSSI 信號反饋，即使硬件能夠提供。可以通過刷新社區開發的新固件來啟用此功能： https: //github.com/povlhp/FlySkyRxFirmware

此 GitHub 包含有關如何訪問 RC 接收器的編程接口以及如何刷新新固件的所有必要說明。這里需要注意的重要一點是，庫存固件是讀保護的，在刷新此新固件之前無法備份...

刷入新固件后，我們現在在 SBUS 通道 14 上有接收器 RSSI 信號輸出，然后可以通過設置 PX4 固件中的 RC_RSSI_PWM_CHANNEL 參數（可以通過 QGroundControl 完成）由 FMUK66 讀取，如下圖所示：

然后 RSSI 值也顯示在 QGroundControl 中，如下圖所示：

車輪編碼器

正如“ DriveGear ”部分末尾所述，最初的想法是使用帶編碼器的電機為 MR-Buggy3 添加里程計。這沒有解決，所以必須找到替代方案，現在回想起來更好。替代方案是車輪編碼器，而不是電機編碼器。通過將里程計與 IMU 和 GPS 數據融合，增加里程計可以實現更精確的定位。它還提供了一種在沒有 GPS 可用時進行定位的方法，例如在室內或室外陰天情況下（例如在有很多樹木的田野中）。此外，它還支持在 Buggy 上開發速度控制器（PID 回路）。

開發的車輪編碼器使用簡單的 1 軸 HAL 傳感器 (S49e) 和粘在車輪內部的磁鐵。HAL 傳感器在 3D 打印件和單螺釘的幫助下安裝到后輪罩（我還沒有開發前輪安裝支架）（HAL 傳感器首先粘在這件上）：

接下來，我們必須在輪子上添加磁鐵，當它們經過輪子時，HAL 傳感器可以感應到。小型 5x5mm 方形釹磁鐵用于此，粘在后輪內側（兩個在相對側）。磁鐵必須以相同的磁極向內粘合到位，以便相同的磁極通過編碼器。使用哪個磁極并不重要，只要添加到輪子上的所有磁鐵都相同（可以多于 2 個磁鐵以提高編碼器分辨率）。

車輪編碼器采集的第一個原型是使用 Arduino Pro Mini 開發的，編碼器連接到模擬輸入端口（A0 和 A1）并由其 3V3 導軌供電，所有這些都通過 Arduino I2C 連接到 FMUK66，由來自 Arduino 的 5V 供電FMUK 到 Arduino Vraw 輸入。任何人只要使用 Arduino Pro Mini 就可以輕松構建此原型。該固件可在與更高級的 Wheel Encoder 相同的 GitHub 頁面中找到，它仍然適用于我的叉子的 PX4 固件。

第二個版本使用定制開發板，即 Wheel Encoder 板（主要使用 NXP 部件以保持 HoverGames 的 NXP 精神）。HAL 傳感器通過 3 針 JST-GH 連接器連接到此板。該板有 4 個 HAL 傳感器輸入，每個輸入都連接到一個比較器（NXP 部件 NCX2220），通過電位器可調節觸發電平。然后使用 MCU（NXP 部件 MKE16Z64VLD4）獲取信號，引腳中斷，并增加內部計數器，然后可以通過數字接口（I2C/CAN/UART）讀取。非常感謝 NXP 為我提供 MKE16Z64VLD4 MCU 的免費樣品，因為所有主要分銷商都缺貨這部分......

目前，在車輪編碼器板固件和 PX4 固件上實現的唯一接口是 I2C 接口。硬件已準備好切換到首選 CAN 接口，上面有 NXP TJA1463 CAN 收發器（受 NavQPlus 啟發，使用相同的收發器芯片），但這尚未實現。波紋管是車輪編碼器板的圖片，安裝在中間板上并連接到后輪上的每個 HAL 傳感器：

Wheel Encoder板通過I2C連接到FMUK66，具體是連接到FMUK66的I2C/NFC端口。但是，作為對原始 NavQ 的重大改進之一，NavQPlus 有兩個攝像頭 ISP！這需要使用立體相機設置來進行深度感知和其他應用。為此，必須開發一種新的相機外殼，可以容納兩個相機（在這種情況下是兩個 Google Coral 相機），它們之間有一定的距離。這就是我在這里開發的。

新的立體攝像頭外殼從原來的單攝像頭外殼中汲取靈感，使用類似的樣式、組件，并且可以將其直接安裝到 MR-Bugg3 隨附的攝像頭支架上。這個外殼有空間容納兩個 Google Coral 相機模塊，它們之間的距離為 70 毫米，這是立體相機設置通常推薦的距離。它還在中心有一個空間/開口用于超聲波范圍傳感器，例如設計開口的 GY-US42，或任何其他附加硬件，例如另一個相機模塊、紅外點投影儀（我正在關注 ams OSRAM APDE-00)、照明燈等...

外殼由背面和蓋子兩部分組成，相機模塊夾在它們之間，就像原來的外殼一樣。組裝也類似，攝像頭放在兩半之間，然后用 8 顆 M2.5 螺絲擰在一起。

下圖顯示了安裝到 MR-Buggy3 的組裝好的立體相機外殼，帶有兩個 Google Coral 相機。

我還買了一些更長的 24 針、反向、0.5 毫米間距和 30 厘米長的 FPC 電纜 ( https://www.aliexpress.com/item/1005002259855390.html )，作為特別購買的單獨的 Google Coral相機附帶一個非常短的相機（我認為 15 厘米）。

外殼的 CAD 文件可在我的 Thingiverse 上找到，并且可以輕松進行 3D 打印：https://www.thingiverse.com/thing :5935267

減震器彈簧

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 個傳感器：

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

為了結束本節，以及硬件部分，土壤傳感器的圖片安裝到安裝到 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：

適配器 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（橙色）的前進速度：

測量的 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效果不是最好的，需要相當多的調整才能將兩個幀彼此靠近以改善效果。

使用立體攝像頭設置的真正目的是在 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 將具有更高的速度。最后，使用的PX4固件為V1.14 Beta，增加了倒車功能。

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

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

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

采集和傳感器測試

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

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

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

使用土壤傳感器進行的第二項測試是評估與 pH 水平的依賴性，并測試三合一土壤傳感器的 pH 傳感器。這是使用 2 種不同的瓶裝水完成的，具有不同的 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，因為驅動程序非常簡單和早期，我想先把它刷出來并更好地測試。

?