Environmental monitoring is changing rapidly with unmanned aerial vehicles (UAVs). I worked on a specialized amphibious UAV platform built for georeferenced water sampling and real-time chemical analysis in rivers and open basins. The mechatronics, airframe, and much of the onboard electronics were developed by others; my contribution was focused on ground-side software and on how the embedded stack should be structured.
The Amphibious Mechatronic Challenge#
Unlike camera-only drones, this UAV had to land on water, operate against river currents up to 2 m/s, and interact with the environment physically.
The platform centered on an IP43-rated 8-rotor coaxial drone with a custom dual-board payload on ARM Cortex-M4 MCUs:
- Main Board: point-to-point 2.4 GHz datalink to the ground station, telemetry logging, and Dead Reckoning with a dedicated IMU/GNSS for position and attitude when GPS was degraded or lost.
- Slave Board: mechatronic control of the sampling framework over an RS485 field bus.
Robotic Arms and Fluidics (System Context)#
The vehicle carried a motorized pantograph arm to lower a multi-parameter water probe (pH, dissolved oxygen, turbidity, and more) to about 1.25 m below the surface, mechanically compensating for pitch while floating so the probe stayed vertical.
For deeper water, an automated winch could lower a Van Dorn bottle to about 30 m, with servo messenger release and a thermal wire-cutting fail-safe for entanglement. An onboard fluidic path (micro-pump, flow meter, solenoid manifold) supported rinsing (“avvinamento”) before filling onboard vessels to limit cross-contamination.
That complexity sat outside my direct design work; it is the context in which the tools I built had to operate reliably.
What I Built: Electron, Vue.js, and Serial Control#
I designed and implemented a desktop application with Electron and Vue.js that talked to the hardware over a serial link. Operators used it to:
- define and generate acquisition plans (how and when sampling should run), and
- send commands to the drone’s pantograph and related acquisition workflow.
The app was the operator-facing bridge between mission intent and the mechatronic payload, not the flight stack itself.
RTOS Architecture: Definition vs Implementation#
I also defined the software architecture for the onboard firmware around an RTOS—FreeRTOS in this project—including how tasks, communication, and timing boundaries should be split so flight-adjacent logic, sampling, and I/O could coexist predictably.
The actual FreeRTOS-based implementation was carried out by a third-party team; my role was architectural specification and alignment with the ground tool and serial protocol.
Outcome#
The result, as a system, was flight dynamics, robotics, and fluidics working together for automated environmental workflows. On my side, the deliverable was clear ground tooling and a documented RTOS-shaped architecture that another group could implement without ambiguity.