Avionics pods,
Things are progressing slowly but surely. I’m probably averaging 20hr per week of work on it, distracted only by manufacturing op-ed pieces 😂 It doesn't look like as much physical progress, but I'm feeling WAY better about the avionics now. It's not the hull floating that worries me, it's sending a complex computer system out into nature unattended. 4,000 lines of code so far...
Alright, update time, I made some mistakes. Not the end of the world—they’re already fixed!
The original plan was to fit all the electronics into a 6-inch Triclamp mast. I knew it would be tight, but there weren’t any viable options larger than 6 inches in diameter. I designed the PCB to fit this constraint, but it was an extremely snug arrangement with components like the MPPT, BMS, Raspberry Pi, cameras, etc. Once I started assembling the flight hardware, a few unmodeled details like ribbon cable headers started interfering with the side walls. I tried to thin things out wherever possible, but it became an increasingly frustrating packaging challenge.
Eventually, I called it. I pivoted to an IP66 fiber-reinforced plastic enclosure, a much more familiar setup with DIN rails and cable trays. Naturally, I chose one from McMaster. The only significant loss was some welding work; everything else transitioned smoothly into the new enclosure.
This change made life a lot easier, and I was able to assemble a near flight-ready prototype in just a couple of nights. The biggest question mark was RF performance of the Starlink through the lid. The internet wasn’t very helpful, with the general sentiment being PUT NOTHING ABOVE THE STARLINK. I found no measurable performance loss shooting through 4mm thick walls of fiber reinforced thermoset. I took the ETFE sticker off the top of the Mini and used 3m film adhesive to bond it to the roof of the enclosure lid, no going back after that move! Below, you can see the injection points from the hot gate runner system they used for the Starlink Mini enclosure. As AVE would say, sounds like glass fiber 30% PA.
The cameras were the biggest adjustment. Using 3D-printed drill guides and a hole saw, I cut dual 3-inch portholes in the enclosure. The viewports are made from ¼-inch waterjet-cut polycarbonate from SendCutSend, sealed to the box with Hysol. The cameras are mounted on ABS 3D-printed holders. After much deliberation, I’ve moved away from GoPros and fully committed to TP-Link Tapo C120 cameras. The selling point? They broadcast RTSP streams over WiFi and are rock-solid in terms of reliability. While they’re rated for indoor use, the weatherproof enclosure keeps them perfectly safe. I’m running two forward-facing cameras for redundancy—if one viewport gets obstructed, I’ll still have a backup. If I had more bandwidth, I’d consider an F1-style setup with an indexable film over the lenses for a clean view. Might need to find hydrophobic gorilla glass projects for polcarb?
The camera software has been trickier than anticipated. After a few weeks of fiddling with Docker scripts, I’ve finally achieved something stable. The workflow involves capturing 1080p 30fps raw footage and storing it on an SSD during daylight hours. For streaming, I downsample to 720p 20fps with a lower bitrate to send via Starlink to YouTube Live. I’ll also compile the day’s footage into a 100x speed timelapse. Ensuring resilience to frame drops and corruption has been a priority—FFMPEG has been temperamental in this regard. I settled on Frigate as a standalone Docker container for video capture, retention, and browser-based review. It’s been a lifesaver after some earlier mishaps where the Pi’s disk filled up, causing major crashes.
The hardware-in-the-loop (HITL) testbed has also evolved. It started as a DIN rail table mounted to a utility cart. Now that the real batteries are installed in the hull spine, I needed a way to simulate flight conditions more realistically. Being able to detach the setup from the solar panels and wheel it into the middle of a parking lot with a clear view of the sky has been a game-changer. The Iridium module, in particular, acquires a signal much faster when it has an unobstructed 180-degree view.
Other systems are progressing well. The Iridium and GPS antennas work effectively, even blasting through the Starlink itself, which avoids the need for external SMA antennas. Load management through the Pi/ESP32 combo allows selective shutdown of power-hungry devices at night, conserving precious energy. During testing, I shorted an auxiliary channel and confirmed the Infineon smart FET’s current limiting worked as advertised—justifying the work on the PCB.
The magnetometer, IMU, and gyro are all operational. The magnetometer provides accurate heading data without GPS velocity, thanks to the MMC5983MA. The IMU and gyro are mostly for fun but might eventually inform power-saving features, like shutting off Starlink during extreme seas. The security guards were probably wondering why I was in the back lot, spinning the thing 90deg every few minutes. Got to check the heading calibrations!
The hull is still awaiting its turn at the CNC router. Foam is in hand, and fiberglass supplies are ready to go. Just waiting on machine time. *insert waiting Pablo meme 😄*
The rudder system is coming together with a simple lever-arm tiller configuration. It’s driven by an IP69K-rated stepper actuator from Tolomatic (a great surplus find on eBay). I hate fooling around with seals, better to let someone else engineer that. This gives 4 inches of stroke, driving the tiller for ±30 degrees of rudder swing. The pivot uses Rulon bushings on a ¾-inch 316 stainless shaft, welded to a slab-style rudder roughly 1 square foot in size. The keel will provide most of the straight-line stability, so the actuator will only make occasional adjustments to conserve power.
The battery is still going strong! 8s1p 50ah is the final flight configuration. After 50 cycles, the cells seem to stay in balance nicely. Looking forward to someone building a nice easy to integrate all in one MPPT + BMS with opensource Python code...
In software land, the number of edge cases causing non-recoverable faults is steadily shrinking. The long tail of things is mostly quality of life stuff with operating the camera streams and power management. I can’t run a strict time based schedule, as the solar panels produce a different amount of energy every day as cloud cover changes. I’m right on the coast of LA, so the marine layer is fairly regular, and I’m not getting ideal power levels. The large power consumers (motor, Starlink, cameras) need to be dynamically scheduled based on actual amp-hours of storage accumulated the day before. I wish I had room for more than 300w of solar, but at 15ft it was already quite big.
The ESP32 is acting as a supervisor board, with the ability to override any load switch FET and perform a power cycle on a per-channel basis through Iridium. The board also performs automatic reboots of the Pi if its watchdog pin goes low (indicating a failure to boot).
Have I mentioned that I hate devops? It’s great, but seriously, the biggest pile of fiddly little problems. Tailscale is great, until you are running a container server side and a container boat side and each one needs to resolve DNS names across constant Starlink network drops. How to configure health checks to auto reboot the container if MagicDNS is stale. Blah blah blah, boring but important details.
Still loving the fact that I can pull up Grafana from the airplane to check on the status of my system. I finally migrated the InfluxDB and Grafana to a server on land, instead of it living on the boat. This way I get uninterrupted access to the data while the Starlink is off. Even configuring the Telegraf service to do proper disc based buffering during blackout periods was a bit of a pain.
Next steps:
Hull CNC foam cutting
Fiberglass skin
Mount prop drive system / endurance submersion testing
Machine rudder parts / Integrate actuator
Finish flight wiring harnesses
Stop writing software