为NXP Hovergames3开发的AutoSQA项目文章

描述

这是一篇关于我为 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，因为驱动程序非常简单和早期，我想先把它刷出来并更好地测试。