Early Algal Bloom Detection of Shallow Estuary

Early Algal Bloom Detection of Shallow Estuary to Prevent Aquatic Biodiversity Losses

A Primer on Tools to Solve Complex Problems

The hardest part about making a tool, is realizing the niche case that it could serve in society is not the full solution to the problem at hand. No one tool, or system of tools can solve complex problems such as food production issues: these problems can have various root causes, such as topsoil losses from industrialized agriculture, or disruptions in the food chain due to biodiversity losses.

With these caveats in mind, I decided that my Hovergames 3 project should have a narrow use-case, specific to my geographic region, and hyper-focused on a local food production loss mitigation strategy. The region is comprised of a 150+ mile long estuary where issues such as nutrient overload and chemical runoff (fertilizer, pesticide, irrigation from residential & commercial) have led to documented biodiversity loss, primarily sea grass. This known loss of seagrass directly has correlated inversely with sea trout populations in the region. Trout is a fishing commodity in the Lagoon, thus a concentrated effort to restore sea grass growth via reduction of algae blooms.

The Technical Rigor to Detect Algal Blooms

Following up on Hovergames 2, I continued the challenge of getting ROS 2 and Micro XRCE-DDS (PX4 has moved on from the Micro RTPS bridge in favor of a more scalable approach with the micro dds client). With the new Micro XRCE-DDS architecture, the px4_ros_com and px4_msgs packages are no longer required. Instead, users can opt to install micro ROS via snap package, or build locally in their ROS 2 workspace. I decided to drive down to the DDS Agent and install that on the NavQ for now, and eventually install micro ROS on the NavQ+.

For the vanilla NavQ, I was able to create a modified Yocto recipe with ROS 2 in HG2. Now for HG3, I refined the ROS 2 recipe and image modifications, while adding a prototype micro dds agent. This agent will act as a broker for the micro dds client on the PX4 and any other client application or ROS 2 node I wish to run on the NavQ (or NavQ+ if they are all connected to the same network).

The meta-dds layer can be found here. I appended xrce-agent to the Hovergames recipe bb image (imx-image-hovergames.bb) and changed all ROS 1 / Melodic references to ROS 2 and Foxy. I plan to eventually get the Micro XRCE-DDS client examples built on the NavQ, but it is still a WIP. (TODO)

While I am not sure how ROS 2 will play a role in this project exactly (TODO), another method of transport between the FMUK66 and NavQ on top of Mavlink is definitely a plus, considering DDS is not as lossy as Mavlink over UART or UDP.

I first tested the NavQ Micro XRCE-DDS agent over my Wifi network, with a HelloWorldPublisher and HelloWorldSubscriber running on my laptop. The agent program on the NavQ brokered the messages and I was able to receive the topics on the subscriber example:

To get the NavQ connection to the FMUK66, I first took a look this forum post. A T1 adapter is required for the NavQ to convert packets from the FMUK66. Once ordered, I was able to power the T1 and connect to the Eth port on the FMUK66 before pinging:

I was able to get ping the FMUK66 via the NavQ and initiated the client through the mavlink console using this command:

microdds_client start -h 10.0.0.3 -p 2019

The connection was successful, and I was greeted with the DDS topics printing on the Mavlink console:

Moving on to the NavQ+, I repeated the same steps as above, although instead of having to build from Yocto, I just cloned the Micro XRCE-DDS agent repo and just built using the CMake super build approach defined in the eProsima docs. Utilizing ROS 2 galactic on the NavQ+, I was able to read sensor information from the pixhawk via the DDS global space. For a video that shows reading sensor data over through the Micro DDS agent see here.

Sensor Buoy Electronics Payload (SBEP)

The high difficulty in setting up a low-power, efficient, & reliable electronics payload to record sensor readings from the Bosch BME688 is an understatement. I chose the RFM95 LoRA breakout module to transmit to a base station (raspberry pi 3b with the same RMF95 transceiver). Shown below is a simplified circuit with only one solar panel (but more will be used, up to 4-5) connected to the DC solar Li-Ion/Li-polymer charger. This charge controller charges a 3-cell battery (3 cells in parallel). The battery powers the RPI Pico and the RFM95 & BME688 gas sensor. A low EMI efficient power module to regulate voltage coming from the battery. The RPI pico connects via SPI to the RFM95 module (using default SPI pins GP 16, 17, 18, & 19). For the Bosch BME688 gas sensor, I connected GP6 & GP7 which are I2C pins.

Unfortunately, due to the RFM95 Radiohead libraries lacking support for the RPI Pico (most likely due to software interrupts?), I instead used the Arduino Uno R3. Even with working interrupts, I noticed the Bosch gas sensor readings were being clobbered by the SPI-connected RFM95 module interrupts, so I decided to connect the gas sensor via SPI, just changing the digital pin to a different chip select than what was already used for the RFM95. This appeared to finally work, so many tears were spent trying to get the RFM95 radio working along with the BME688!

I essentially wrote arduino code based off of two arduino libraries in order to send gas sensor values over LoRa:

1) Bosch BME68x-Library

2) RadioHead Packet radio library for embedded microprocessors

The resulting Arduino *.ino file can be found at my github here.

I opted to send reliable datagram packets, so that I can set a client and server address and not have others intercept my radio packets. Encryption is also another option for security conscious efforts. Once I had the arduino sending BME688 gas sensor values over LoRa, I setup a Raspberry Pi 3 model b to receive packets based off of this PIP package, although any single board computer or even a tablet or Laptop (mini pcie, serial, or USB connected LoRa 915mhz or whatever matches the client radio) can probably be used to read LoRa packets! All that needed to be changed from the example was to add server and client (Arduino) address, and contain the "send_to_wait" and "on_recv" functions within an infinite while loop.