PEARL

Creating PEARL 3.5

I first worked with the PEARL team remotely in 2024–25 while studying at McGill. In summer 2026, I joined them on site to help build PEARL 3.5 from the earlier boat. This was a substantial integration effort: the team upgraded its autonomy and communications, made vehicle health and mission state easier to follow in real time, and prepared the platform for operations with an aircraft.

On the boat, I worked with MOOS-IvP, an open-source framework for robot autonomy. I developed missions, vehicle messaging, telemetry such as position and battery readings, and the routines we used to launch, observe, and troubleshoot tests. I was also part of field operations and demonstrations on the Charles River. That work connected the boat’s sensing and navigation to the aircraft operations we were developing alongside it.

Building the aircraft

We built a custom quadcopter from a Holybro X650 frame, combining ArduPilot’s open-source autopilot software with a Pixhawk flight controller and an onboard Raspberry Pi computer for MOOS-IvP. The aircraft carried GPS, a telemetry radio, a downward-looking range sensor, remote identification hardware, and a Landmark camera-based precision-landing system. This gave us a configurable research aircraft whose flight controller, mission software, and landing sensors could work together.

I worked with the team on assembly and integration, with my main responsibility on the autonomy and communications side. Flight testing also led us to improve the battery mount, protect the range sensor, revise the landing gear, and add emergency flotation for over-water operations.

Making the aircraft and boat work together

I adapted the existing fixed-wing MOOS-to-ArduPilot bridge for quadcopters. MOOS is the messaging layer within MOOS-IvP; the bridge connects its mission commands to the autopilot. ArduPilot handles low-level flight while the mission software issues commands and tracks their progress. Sending a command doesn’t prove that the autopilot accepted it or reached the requested state. I added acknowledgements, bounded retries, timeouts, and checks of the aircraft’s reported mode and state so the mission software could check its response and detect missing or stale updates.

I led the aircraft work through software-in-the-loop tests, which run the autopilot in simulation, then indoor flights, outdoor testing at Briggs Field and the Sailing Pavilion, and the Charles River demonstration. In July 2026, I presented the aircraft portion of the team’s talk and helped run the live demonstration at MOOS-DAWG, the community’s Development and Applications Working Group meeting. The drone completed its programmed flight and landed on PEARL using visual precision landing. That physical recovery gave us a foundation for the coordinated mission and return software I developed next.

Making field tests repeatable

I configured communications for the onboard computers and built the direct boat-to-drone messaging path so their coordination wouldn’t depend on an internet connection or a shoreside relay. I also brought PEARL’s battery, wind, and link-health measurements into the mission software. Operators could see whether a radio was connected, whether its telemetry was current, and whether the information needed for takeoff or recovery was actually available.

I made the aircraft computer’s setup reproducible through infrastructure-as-code: configuration files and scripts that can rebuild the system. I used Packer to prepare its software image and Ansible to configure it. I also built a browser monitor and health reporting for the onboard OAK stereo camera, with color images, paired camera views, and a view showing the differences used to estimate depth. Alongside mission logs, these tools let us inspect the system during a test and investigate what happened afterward. They also give the next person a documented way to rebuild the setup instead of relying on a collection of manual changes.

Beyond a single landing

I extended the system so the aircraft can fly an assigned route and then coordinate its return with PEARL. The boat proposes a meeting point, both vehicles travel toward it, and the aircraft follows PEARL’s fresh position as it looks for the visual landing target. The final landing is gated on both vehicles being in place and on current health, battery, wind, and visual-target information.

The July 2026 river landing demonstrated the physical recovery. The later mission software connects that recovery to an assigned flight, allowing the aircraft to complete its work, find the boat again, and return to the mobile platform.

The meeting point accounts for the vehicles’ configured speeds so the slower boat doesn’t have to chase the aircraft. Once they arrive, PEARL holds position while the aircraft follows its live location and searches for the target. Permission to land is checked continuously, not granted once and assumed safe forever. If the target doesn’t appear or the required information becomes stale, the coordination stops and the vehicles hold rather than continuing toward a landing.

I also separated recovery from takeoff. Low aircraft battery should increase the urgency of returning, not prevent it, while taking off requires enough reserve in both vehicles. ArduPilot retains responsibility for descent and target-loss handling after the landing command. The current coordinator doesn’t measure deck motion or automatically determine whether the landing area is clear, so those remain operating considerations outside its software checks.