
Build Log
All the action will play out on Twitter (X), but we’ll copy over content to this blog to make it a bit more chronologically readable.
First time on the water
It didn’t sink, but steering could be better!
First time in the water for Bob! Goals were:
Don’t sink
Test out launching/transport cart
Evaluate weight distribution
Test thruster pod and gather speed/power data
Evaluate rudder size/control authority
Test drive UI
After scouting a few potential locations, we ended up launching from the Marina Del Rey public boat ramp. The 3ft-deep keel and thruster pod made transport and launch a bit tricky; we required a shallow enough ramp to drive the wheeled cart into the water, along with sufficient dock access alongside the boat.
The transport cart worked perfectly! It's a Global Industries workbench frame with pneumatic wheelbarrow wheels mounted on an axle. I installed additional bracing, as we had to remove the left frame member, allowing us to roll the cart directly into the water and slide the boat out smoothly. Everything also fit nicely into the trailer.
With Starlink running the entire time, I remotely accessed Bob on my phone to view live video footage as we drove along the coast.
Spotted someone with a much cooler rig than ours at the docks.
Hanging out with the guys.
A major concern was whether the Cubemars DW20 thruster pod would have enough power for the significantly draggier Hull #2. Due to time constraints, we opted not to create a custom fiberglass hull for the second build, instead using an off-the-shelf SoloSkiff micro skiff. Essentially a 14ft rotomolded boat/kayak hybrid, it's much tougher and accommodates larger solar panels and batteries. However, it's less hydrodynamic, reducing top speed. Whether the additional 100 watts of solar offsets this is still unknown.
Results were surprisingly good! We averaged a cruising speed of 2.3 knots at medium thruster power (75 watts). Remember, power consumption (watts) scales with velocity squared, so slower cruising is beneficial. We'll collect solar energy for roughly 5 hours each day and distribute usage over the full 24-hour cycle. At that speed, our journey would take approximately 394 days without any current assistance. Testing within the narrow 1000ft marina channel limited how far we could cruise, and no one felt comfortable pushing it out into the main waterway.
Our chase kayak stayed busy! We may have rammed into her a few times. 300lb of boat is a bit scary when it's coming at you at 5knots. I love the little face that the camera portholes gives it.
It quickly became clear that our rudder was significantly undersized. Initial estimates based on hull area-to-rudder surface area ratios proved inadequate, resulting in insufficient control authority against the wind. The rudder actuator swings from -35° to 35°, driven by a pushrod stepper motor. That part of the system worked well, though we needed some minor tweaking to the hardstop homing routine.
Due to limited rudder effectiveness, we operated manually rather than using waypoint autopilot, effectively driving the boat in first-person view. I developed a UI with split-screen forward video feed and rudder/power controls. Video feeds were from Frigate (docker container) and wifi Tapo cameras. The UI, hosted via Flask/Python in a Docker container, sends commands through a Redis pub/sub connection to the main Docker container handling physical IO. The funniest failure occurred when reversing the propeller RPMs caused the UI to crash—turns out I hadn't handled negative RPMs properly. Driving around further revealed a need for hotkey buttons to quickly execute maneuvers like max port/starboard turns and emergency propeller stop.
Aside from that, software performance was pretty good, with 14 Docker containers running seamlessly. Starlink was flawless, maintaining wifi connections up to 1000 feet away. Data buffered via Telegraf was stored on a remote server at home.
Solar and battery performance was also good. Our 400W solar panels peaked at 290 watts, not unexpected due to the early March sun angle at Los Angeles latitudes.
Overall, a major success for our first outing:
Didn't sink
Launch cart effective
Propulsion successful (up to 7 knots)
Rudder needs resizing
Fun for everyone!
Out-of-water testing the next weekend:
On the to-do list is refactoring telemetry logging code. Currently, a single-threaded loop sequentially retrieves data from sensors (Odrive, GPS, IMU, etc.) and pushes it to Redis, then InfluxDB. Moving each sensor to separate threads or using async would improve update rates, especially critical for high-frequency data like propeller metrics, while maintaining lower update frequencies for sensors like the solar MPPT controller.
Next time, pending rudder adjustments, we'll test waypoint tracking autopilot. The new UI allows easy waypoint editing via a waypoints.json file. Navigation calculates target bearings from GPS data, and our 3-axis magnetometer ensures accurate heading even without GPS motion. PID controllers will manage rudder angle based on bearing error. I've also built a GPS simulator for virtual testing, which performs extremely well in simulations. As far as Bob knows, he's been cruising the same loop around the marine for the last 8 days 😂
While awaiting the next outing, I resolved the thruster issue experienced during our Marina trip. We had unusual problems at higher power levels, limiting motor performance to about 70 watts. After troubleshooting, I found an overlooked "inverter soft_max_current" setting restricting total power, despite correctly configuring motor parameters. The ODrive documentation is incredibly thorough in some place and a little bit lacking in others. Eventually got it figured out by running the motor in a bucket, allowing me to push it to arbitrary power levels without worrying about running into the Coast Guard boats in the Marina.
The rudder extension plate, laser-cut stainless steel from SendCutSend, has already shipped and will be TIG welded onto the existing rudder on Monday.
The DIY underwater camera works! I'm determined to catch some shark footage . Next steps are to bore a hole through the hull and mount it,
Our next sea trial in approximately three weeks will involve a more serious shakedown. We plan to rent a sailboat to tow it into open waters, aiming for 5-10 miles of testing. If everything goes smoothly, we’ll be on track for a mid-April launch party!
Hulls and more hulls!
Time for another shareholder update. All of this is brought to you by the incredible generosity of Twitter. We’re breaking new ground with venture-backed hobbies. Shoutout to the top contributors!
@DanielMavlyutov
@tonsing (Caffeinated)
@ScottNorman (Earthrise)
@jimbelosic (SendCutSend)
@mov_axbx
133 days until launch! I’m targeting June 1, 2025. Because we’re totally solar-powered and making a massive change in latitude (LA @ 33° North to Cape Horn at 55° South), we need to leave at a specific time of year. Solar power changes dramatically with latitude and season, and as the old adage from Apollo 13 goes, “power is everything!”. As you can see from the graphs, we may need to shut down the Starlink in the Arctic Ocean to conserve power. The python analysis is super crude right now, but it gives us a ballpark on power budgets and helps inform the best launch date.
We’ll cruise for a significant stretch at southern latitudes. This is why the keel might look odd in some of the photos you’ve seen. Actually, the keel is perfectly straight in the water, but the upper deck with solar panels is intentionally tilted at a 20° angle toward the sun. This configuration improves solar efficiency during our southern latitude journey and provides an additional self-righting advantage should the vessel flip over (see the earlier post about hydrostatic righting moment for more details).
It’s starting to look like a boat!
We took delivery of the massive CNC’d foam hull last month. Big shoutout to Elijah for not only cutting it but also delivering it. The foam required 24+ hours of machining time! The material is 3lb density EPS foam, which strikes a great balance—lightweight but dense enough for clean cuts and a smooth surface finish.
The hull construction method we’re using is akin to building a surfboard. While there are plenty of approaches to fiberglass structures, this one is simpler and skips the need for a separate female mold. The first step was splitting the entire hull lengthwise to make room for the battery, spine, and rudder actuator. Given the hull dimensions—24 inches wide and 170 inches long—it was clear early on it wouldn’t fit in a vertical bandsaw. Enter the DIY hotwire cutter: nickel-chromium wire, a bookshelf, and some power supplies made for a classic engineering hack. There were a few hiccups, like snapping the wire multiple times during the process, but overall, it worked like a charm.
Once we had the two halves, the interior carving began. We needed precision here to create a conformal fit for the actuator and giant tube. For this, I turned to what may be the scariest Amazon tool I’ve ever purchased: a hot nichrome blade. It’s essentially an electrified ice cream scoop for foam, and was super effective. Unfortunately, the parting line was slightly off-nominal, resulting in a few depth errors and blowouts, but these were patched later with expanding foam.
The rudder actuator is a beast. It’s an IP69K-rated (washdown grade) unit with stainless steel construction, using a stepper motor and ballscrew combo to drive a 6-inch stroke shaft. It’s rated for 200 pounds of force, though we’ll current-limit to less. I’ve always been a fan of overkill torque margins; friction changes over time, and you’d rather have too much power than too little. The actuator setup features a simple tiller arm design driven by a bell crank. With just one machined part (a bushing holder), the rest of the assembly leverages McMaster parts, SendCutSend components, and some TIG welding.
As for rudder sizing, I’ll be honest—it was a wild guess. The hull-to-rudder area ratio is approximately 1:145, placing it somewhere between a supertanker and a racing yacht. If the control authority ends up too low, we can weld an extension to adjust. Calibration and homing for the actuator remain open questions, but I’m leaning toward a robust hard-stop approach for simplicity and reliability. Just run it over to 45deg, let it stall, and set the angle. The reason we need a solution here is that there is no encoder, so after power cycles it'll have no idea what angle it initialized at, hence the need for a homing routine.
After carving, it was time to join the foam halves. We used 6lb density expanding foam to bond the interstitial spaces, keel, spine, and hull into one cohesive structure. This approach provides strong structural coupling. The stainless keel runs up to the spine for added strength, eliminating a common failure mode where a lead keel detaches and compromises stability. This design makes it virtually bulletproof, with the lead bulb securely bolted to a solid keel structure.
There were a few missteps along the way. The Triclamp clamps stuck out past the hull in some spots due to the parting line being slightly off. Expanding foam came to the rescue yet again, blending and smoothing everything out. If you’ve noticed the white tube in photos, that’s a conduit for power cables running to the prop drive system. Meanwhile, sanding took up an unreasonably large chunk of time—it felt like car bodywork. The 15-minute foam cure time was the silver lining, enabling quick progress with multiple cycles per hour.
Fiberglass Layup Time!
For the fiberglass layup, we opted for a wet layup directly onto the foam—no female mold needed. The process involved alternating layers of resin and cloth, with a lot of roller work to get the wrinkles out. We used marine-grade 4:1 resin with a slow hardener and 6oz twill fiberglass. All vacuum bagging supplies, including peel ply (a nonstick resin separator), polyester breather felt (a vacuum pathway), and Stretchlon bagging film (500% elongation), were sourced from FiberGlast. Sealing the keel penetration required extra tacky tape, which turned out to be one of the more annoying parts of the process. After chasing down inevitable vacuum leaks, we got a solid seal. Tomorrow’s unbagging will reveal the results, but even with minor wrinkles, function takes priority over aesthetics.
Cameras!
We’ve iterated heavily on the camera setup. Initially, we tested GoPros, but they were ultimately unsuitable for this project. The API is unreliable, and they struggle with long-term use. After much trial and error, we landed on TP-Link Tapo cameras. These cameras offer RTSP streams, excellent low-light performance, and solid reliability. The current configuration includes two forward-facing cameras, a rear-facing 360 PTZ camera, and an underwater camera. For the underwater unit, two big challenges arose: waterproofing and signal transmission. Water attenuates Wi-Fi heavily, so we opened up the PCB and got lucky: the designers used a u.FL connector and a Kapton Wi-Fi antenna. This allowed us to install a 3-foot antenna extension, running the signal above the waterline. Waterproofing involved three-step epoxy potting. Each component of the camera was carefully sealed, creating a solid brick of epoxy with only the glass lens exposed. It’s currently undergoing a month-long soak test and performing flawlessly. I’m optimistic this solution will hold up in real-world conditions.
Bob #2 Update!
The second boat, Bob #2, is designed to handle more extreme conditions (think hurricanes). To save time and increase durability, we chose a rotomolded HDPE hull with a dense foam core. While heavier and less hydrodynamically efficient than Bob #1, this hull is nearly indestructible. Bob #2 also features doubled battery capacity (100Ah @ 24V) and an additional solar panel, bringing total output to 400W.
Construction on Bob #2 is progressing quickly. We’ve secured the aluminum honeycomb solar deck, riveted SunPower arrays, trimmed the hatch, and drilled anchor holes. The keel structure is ready for installation and will be riveted in place before the interior is backfilled with lightweight 2lb expanding foam, locking everything together. The solar deck and avionics box remain modular for transport.
Sea Trials:
I'm currently seeking permission to conduct trials in one of Los Angeles's reservoirs. A controlled environment like this would be ideal for safely running 24/7 tests without the risks posed by boat traffic or unpredictable conditions. If you have any connections or suggestions for securing access to a suitable reservoir, please reach out!
Once we have a testing location secured, we'll spend several weeks validating critical systems, iterating on software performance, testing telemetry, and evaluating the hull's structural integrity. Running laps in a closed body of water might not be glamorous, but it's the perfect sandbox for thorough debugging and optimization before any future ocean voyages.
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...
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.
Old avionics packaging trials
On the healing bench
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.
I love the fact they give CAD models for everything
Viewports all bonded on
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.
Injection molding marks hiding behind the sticker on Starlink. I think my warranty might be voided!
Still needs some cleanup
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?
Drill guides
Love the Bambu
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.
New hardware test cart!
300w sunpower solar cells
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!
Little buddy has no idea of the journey he's going to go on....
At least there was an Arduino example I could port to Python
Board working great
Doing 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.
Am a sucker for a good ebay deal
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...
Diy 50ah 8s1p lifep4 cylindrical cell battery for the 3in triclamp spine tube
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.
Too much programming, not enough machining lately
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
2 weeks of Hardware-in-the-loop testing + LiFePO4 cell build!
2 weeks of Hardware-in-the-loop testing + LiFePO4 cell build!
Didn't blow up the cells. The two 6s packs had all their copper bus bars installed. It was really fantastic to not have to spot weld hundreds of cells together. The shape of the bus bar will allow a small amount of bending in the main spine without transmitting excess bending loads into the terminal of the battery. This is why I went with this type of bent bus bar instead of an M14-M10 female-female threaded coupler. Shout out to @sendcutsend for the fast turnaround time on the parts. $100 shipped for a few dozen laser cut and precision bent brackets made in the USA. It’s truly a great time to be doing hardware.
I admit that shrinking the 4” heatshrink was extraordinarily satisfying. The fit inside the 3” Triclamp tube is super snug, maybe .005” gap. Each cell gets a balance wire at the midpoint of the bus bar, and that runs back to the BMS. I went with the Enepaq TinyBMS from Lithuania. The quality of the build was good, and their software was quite straightforward. It can use UART, Modbus, or CAN. Currently, I’m running fairly conservative settings, as this is my first time using LiFePO4
Charge upper cutoff: 3.55v
Lower voltage cutoff: 2.9v
Charge rate = 0.3c
The Chinese LiFePO4 cells are tracking together fairly well. The manufacture said they would match cells, and everything seems to be within 4mv on average.
Now that I’ve got a 1000whr (50ah@20v) flight battery hooked up, the HITL cart can run through the whole night with the entire system on (Starlink, servos, Pi, Gopros, ect). I still need to walk through all possible voltage scenarios to verify that the MPPT and BMS are behaving as expected. My worst fear is an unrecoverable scenario where the Sunsaver MPPT gets into a fault state and doesn’t power the load channel on, which is upstream of the whole system. This can happen if it doesn’t detect a valid battery on the charge lines. This could happen if the BMS takes the battery offline. I’m considering if it’s a good idea to route the raw solar cell 36v lines (55v open circuit) to the PCB as an emergency backup. It would seem silly to have a perfectly healthy 300w array and be dead in the matter if the BMS has a bad day and doesn’t connect the battery. In this case, I could limp it on solar power alone back to land. I would have to buck the 55v down to my 24v system voltage, but that’s doable.
Currently, I’m on the fence about whether I should run a single 6s pack or dual 6s packs. There is room in the 10ft Triclamp spine for two packs, but I’m afraid of adding too much complexity to the power management system. A second BMS would be required, and switching logic to cycle between the packs on a weekly basis. The number of cycles for running a single pack(~300) isn’t super high compared to a reasonable LiFePO4 lifetime. Is it really worth the extra weight to have fault tolerance in this one particular area, when I still only have one solar array and one MPPT? The spacecraft systems engineers can chime in here. We might just do a lot of testing and send it?
Logging:
Grafana+InfluxDB continue to crush it. I am a huge believer in logging every channel of every device, 24/7. It baffles me when I see legit startups without a unified data ecosystem and DAQ systems. Lots to say there, but I digress...
It's slightly scary to charge a giant homemade battery for the first time off a brand new solar system. I was watching super closely for weird behavior. The voltage curve for LiFePO4 is so flat, you really need a few hundredths of a voltage resolution to see movement during most of the curve. You can see the solar voltage and power production fluctuating as clouds passed by. The 300w array peaked at 250w. More important is the integrated energy collected, about 800whr, or 2.88MJ. This equals a specific performance of 2.66 watts/array_watt/day. Pretty decent performance for a cloudy day. On a sunny day, would hope to see closer to 4.0.
Python pulls everything off Modbus, I2C, rs232 and pushes to the InfluxDB container every 5 seconds, for a few tenths of a watt cpu load. Anytime day or night, I can switch on Tailscale on my phone and pull up the real-time stats on the outdoor HITL+Starlink table.
GoPro is Working… Mostly
As I mentioned before, the GoPro is a bit of a finicky device to work with, and it seems like a lot of you have had similar experiences. I love the image quality, exposure control, and Timewarp stabilization. But, unfortunately, it's not really designed to be a long-duration camera. While it's incredibly rugged and battle-tested in the field, the interface does present some issues that need to be managed.
The backup option is a more traditional IP camera like a HikVision. The problem is that all these cams have potato image quality, especially with a 1/3" CMOS sensor. If we have any hope of capturing the Milky Way, it has to be either a GoPro or a DSLR. Shoutout to @radshaan and his team of sharp engineers. I sent them a GoPro Hero 12, and they've been helping with the codebase.
Quick Overview of the System Architecture:
Raspberry Pi 4 as the bare-metal compute
GoPro Hero 12 with the battery removed, running Labsfirmware and a USB power mod
USB connection via a powered 2.4A USB 2.0 hub
Docker (@Docker) containers, including a dedicated GoPro container
Portainer (@portainerio)
InfluxDB (@InfluxDB)
Grafana (@grafana)
Tailscale (@Tailscale)
Google Bucket storage
The GoPro uses a USB-NCM network adapter and communicates via HTTP requests. GoPro maintains a moderately well-documented API, but the tricky part revolves around the USB network adapter. If the container crashes or gets interrupted during a capture event (e.g., while the shutter is open), it tends to leave the GoPro in an odd port state. This usually results in one of two outcomes: the USB device either doesn't show up at all, or the ETH2 network adapter won’t ping. Both are frustrating and difficult to recover from. Typically, I have to drive to the lab and physically unplug the device.
The ideal solution is a managed USB port where I can disconnect both data and power lines on command. My plan is to route the USB data lines through my PCB and use a TI eFuse on the 5V VCC lines. This will allow me to perform a hard power cycle since the GoPro won’t have a battery. So far, every time I’ve power-cycled it, the GoPro comes back clean once I rebind the USB port and renew the IP on ETH. PCB Is like #6 on the priority list...
It’s been a lot of trial and error to figure out how to manipulate the various setting IDs through the API. There are about 200 settings controlling everything from frame rate to resolution, and the tricky part is you can only adjust the settings for the current mode. For example, if you’re in Timelapse mode, you can’t alter Video mode settings. There isn’t a clear map of mode-to-settings, so I’ve been slowly figuring out what works.
I've really enjoyed working with Docker containers throughout this project. To be honest, my DevOps skills have been a bit behind the curve, but I’ve been making an effort to catch up. It’s great having completely isolated environments for all my different tasks, whether they're short- or long-duration processes. Trying to manage this through async or threading in one big Python file would’ve been a total nightmare. The containers let me keep everything neatly separated—the InfluxDB database, the sensors, the flaky GoPro, and the navigation systems. Big shoutout to @portainerio for sponsoring me with a business license. I’ve been using their platform long before they found me on Twitter because, frankly, I think CLI is overrated. A clean UI for managing containers just makes sense.
Today was the first day that the entire pipeline functioned end to end. I rebooted the Pi at 8 a.m., and all containers started automatically. The GoPro container wiped its SD card, configured the modes, and initiated a 2-hour timelapse with a 30-second interval per frame. Once it finished, the file was retrieved over USB and uploaded to a Google storage bucket through the API, all over the Starlink Mini connection. Every few hours, I can check my Google Drive to see the latest timelapse clip. Pretty cool stuff! Next, I need to dive into the NightLapse settings, which are optimized for low-light capture. Maybe I can even convince someone to turn off the parking lot lights...
It took about a week of waking up at 5:30 a.m. to get a few hours of coding in before work, testing everything in the back parking lot with my outdoor HITL environment. Now, it's stable enough that I can do most of the work remotely via Starlink. Hopefully, in the next 2-3 weeks, I’ll have a quick PCB design ready for the USB-unplugger-omatic and the setup will be bulletproof.
The last two-week sprint goal was to get the entire hardware-software stack operational and see if everything worked as expected. Now that it's stable, I can begin more thorough testing and return to the much-neglected mechanical work on the hull. My large pile of SendCutSend parts is staring at me, just waiting to be assembled. Hopefully this weekend I can get out a keel mechanical update.
Battery Spine Fab Has Begun! Steel Is Real.
Fabrication of the custom 8ft long triclamp spool went great!
Battery Spine Fab Has Begun! Steel Is Real.
Fabrication of the custom 8ft long triclamp spool went great!
I’ve mentioned the Triclamp setup before, but I probably never elaborated on why I’m going this route. In short, I despise engineering custom seals. With all the off-the-shelf methods available, why reinvent the wheel? With everything else going on in this build, I wasn’t about to start designing bespoke flanges and digging through the Parker O-ring guide. The thought of using fiberglass to make a custom battery box which would then be submerged below the waterline was simply too scary. The triclamp ecosystem evolved to be dirt cheap because of the huge quantities from the food and beverage world. Everything has a 32ra finish, is laser welded, is stocked everywhere, and costs less than a cheeseburger.
I chose the 3-inch Triclamp size because it’s the closest match to the largest cylindrical 60mm LiFePO4 battery on the market. With a 3D-printed liner, I can make up the diameter difference and route the power and balance battery wires back to the central BMS. It’s a super elegant solution: I get a sealed battery pod, a structural spine, a support mast for Starlink, and easy routing of electrical harnesses—all in one go.
Of course, finding an off-the-shelf 8ft long 3in Triclamp spool wasn’t happening, so I had to weld my own from .065 sanitary tubing and flanges. Not the worst job in the world, but the welds need to be solid. Not only does the seal need to be airtight, but they’ll also be loaded in cyclic bending, so full penetration is a must. To avoid any blow-through on the ID, I machined a tight-fit plug to serve as a backstop and heatsink for the weld. It’s a trick I remembered reading about from the old Saturn V tank seam welding days, and it worked like a charm. Boat #1’s pod is done, but I ran out of argon gas before I could start on boat #2—next weekend’s project.
Tomorrow’s plan is to start wiring the cells. The giant LiFePO4 cells have a nice advantage—threaded studs, so no need for spot welding bus bars. I’ll use copper bus bars for the cell-to-cell connections, and everything will be torqued down with some red Loctite to keep things secure. I’m setting up the cells as two separate 6s1p packs. A single pack can absorb a full day of solar input, and having two gives us redundancy. If we lose a cell, we can simply flip the relay to string B and keep going.
The scale has finally sunk in. This is only 60% of the boat length. Transporting is going to be a non-negligible problem. It no longer fits in a pickup truck bed, at 14ft long. Might have to find a canoe or paddleboard trailer.
Speaking of fab, a round of @sendcutsend is on order. A huge thanks to@jimbelosic. Not only did he personally sponsor Project Bob, but he spent almost 3 hours last month telling the story of growing SendCutSend from the very first machine. His story is one that America needs more of, just a hard-working dude dedicated to making physical tangible goods. Keep it up!
We’ve got stainless keels, hanger brackets, G10 nose plates, copper busbars, and G10 Starlink box closeouts on the way. Honestly, having an easy waterjet option for the G10 is a lifesaver—I’ve milled that stuff in the CNC before, never again. Once these parts arrive, we can start assembling the servo motor, prop shaft, and bearings on the keel.
Hull geometry is now frozen!
Well, folks, we’ve officially left Hull-a-geddon in our wake. The CG is now sufficiently low, and after tweaking the waterline curvature, we’ve finally got our righting moment curves looking respectable. Big win there. The analysis tool I built was worth the effort, and it was pretty cool to see it churning through the STL files. For those who find themselves in the incredibly niche position of needing to perform stability analysis on hull shapes, you can check out the code here: Project Bob on GitHub
With the hull saga wrapped up, the geometry is off to the machine shop, and foam has been ordered—fingers crossed for delivery next week. Shoutout to a local shop owner following along on Twitter who offered up some time on his 22ft 5-axis router to machine the foam core of the hull. Talk about community spirit! Simplified the geometry down to a 3-axis part, but having that 5-axis head available for optimal approach angles is a nice bonus. Once the hull is CNC’d as a monolithic shape, we’ll slice it in half along the long axis to insert the spine and keel. It’s too tall for the vertical bandsaw, so I’m thinking a homemade hotwire cutter with some nichrome is in my near future.
Starlink Mast:
Finally made some headway on this. The original plan was to RTV the Starlink into a 5-sided box with the top dish surface exposed. But after digging a bit deeper, I realized I could transmit through an RF-transparent thin plastic skin. This lets me enclose the Starlink inside a thin-walled HDPE box, sealing the backside with G10. Bonus: I can hide the GPS and Iridium antennas inside this box too.
This weekend’s to-do list includes quantifying the uplink degradation I get from .04” HDPE or 1/16” G10. Stay tuned.
Save those dollars:
I can't thank ya'll enough for funding this project. Totally blown away by the support. I'm doing everything I can do to stretch the dollars! Below was a recent find on eBay. The specialty high angle high toque 17-4SS helical shaft coupler I'm using in the keel's prop shaft, 95% off.
Retrofit Time: Magnetic Encoders Installed
The retrofit magnetic encoders finally arrived from Phoenix. The reason for this retrofit is that the Automation Direct motors use an SSI (Synchronous Serial Interface) absolute encoder protocol, which isn’t compatible with the ODrive servo amplifier. This kind of issue is typical when mixing and matching servo motors and amplifiers from different brands—each seems to use its own protocol, making integration a headache.
For reference, here are some of the common protocols:
SSI (Synchronous Serial Interface)
BiSS(Bidirectional Synchronous Serial)
EnDat(Encoder Data)
HIPERFACE
You can see the old glass encoder below. The glass units have amazing resolution, sometimes as high as 21 bits per rev (2,097,152 counts per rev). Fortunately, mounting the new mag encoder to the motor was straightforward. Since I’m not concerned with extreme positional accuracy, a 2048-count magnetic encoder will suffice. I’ll make sure the entire motor assembly is sealed and waterproofed before bolting it onto the keel.
HITL & Avionics
Building the hardware-in-the-loop (HITL) table. This is standard in spacecraft design, so adopting best practices for boatcraft seems logical. Essentially, it’s a complete set of avionics laid out on a flat table. It goes by various names—flat-sat, non-form-factor build, vehicle-in-the-loop, HITL, etc. This setup allows software to be written and tested against real components under actual load conditions. Observing how your software stack handles edge cases, like power undervolt scenarios, is crucial. With everything onboard, I can easily place it on the roof for extended trials with the real solar panels and Starlink. We’ll also use this as a test environment for any software/firmware updates while the boat is at sea.
The system incorporates multiple communication channels and types:
GPS (I2C)
6DoF IMU (I2C)
3DoF Magnetometer (I2C)
Rudder Stepper (5V pulse/dir)
BLDC Propeller Servo Amplifier (UART, SPI, or analog)
MPPT Solar Controller (UART)
GoPro (USB)
Starlink (Ethernet/WiFi)
Motor Amplifier:
I initially went down a path that I had to reverse. I hoped to use the same Beckhoff EtherCAT system that many of my PLC/controls/test stands are built on. However, two key issues emerged, leading me to abandon that approach. I’m quick to pivot when a design or architecture shows signs of trouble—call it strong opinions, loosely held.
Problem #1: The Beckhoff modules required a baseline power draw of 2.1 watts just to operate the bus, plus 0.8 watts for each servo+stepper module. Losing 10% of power just to operate the communication layer isn’t ideal.
Problem #2: The setup process was excessively challenging. We vastly prefer the Codesys environment over the TwinCAT environment for several reasons, including ease of deployment in a lightweight Docker container on a Raspberry Pi. Unfortunately, this required going down to the register level for motor setup, debugging, and tuning. I spent a lot of time trying to get the motor to run in torque mode with a velocity limit, but not a velocity target. After 8 hours of wrestling with the state machine and its unhelpful fault messages, I began exploring alternatives.
Start of the week
End of the week
Odrive:
ODrive caught my attention as a more open-source, hacker-friendly option. I hadn’t considered them for past projects due to their lack of EtherCAT support, but in a simple UART-based application like this, they’re perfect. Not only were they cheaper with an online shopping cart (no quotes required), but they also responded to emails within a few hours. Their support engineer had even seen the boat mega-thread—what a small world!
FOC:
One key feature I needed was the ability to use FOC (Field Oriented Control) in a sensorless motor setup. FOC uses two PI controllers for the d-axis and q-axis currents, which are then converted back into three-phase voltages using inverse transforms. These voltages drive the motor's power electronics via Pulse Width Modulation (PWM), ensuring the stator's magnetic field remains optimally aligned with the rotor's field. The benefits include high efficiency, smooth operation, precise torque control, and reduced acoustic noise. FOC is widely used in applications like electric vehicles, robotics, and CNC machines where performance, efficiency, and dynamic response are critical.
The Motor:
Initially, I was considering a high-quality Tmotor drone motor. On paper, it looked perfect—right KV, robust matching ESC. However, my use case requires the motor to run for over 6,000 hours, well beyond Tmotor’s design expectations. The best they could estimate was around 800 hours mean-time-between-failure (MTBF). The motor's bearings were small, optimized for weight, but not for longevity.
I decided to revert to the reliable AutomationDirect motors, specifically their South Korea-based DC servo motors. I’ve used them successfully in past projects, and they’re built like tanks with no specific weight optimization. These motors have giant bearings and a 14mm output shaft, so I’ll sacrifice some energy in bearing drag, but the reliability is worth it. The MTBF is estimated at 30,000 hours.
My control strategy for this brushless DC servo motor is quite specific. I want to operate at a precise power target, without concern for position feedback mode. This requires a double-nested control loop: torque (current) as the inner loop, and velocity as the outer loop. Crucially, each can be capped at a configurable value, allowing me to cruise at 40 watts of real-time power consumption. The velocity achieved will simply be a byproduct of the torque loading on the prop. This approach, focusing on power level rather than velocity, gives me more predictable control over the energy budget. There’s still much to figure out regarding how the MPPT will balance energy from the solar cells versus the battery.
Why Sensorless?
Simply put, I hate encoders—the best part is no part. Since I have no requirement for position accuracy or even velocity ripple, I can afford to be loose with rotor position. Encoders are usually glass-etched disks with a photocell or magnetic analog hall sensors with a diametric magnet. While they’re standard in industrial CNC machines, I don’t want to risk failures in a 6,000+ hour saltwater and high-vibration environment. Fortunately, rotor position can be derived from the back-EMF of the motor coils, allowing the FOC algorithm to properly switch the FETs without an encoder. ODrive offers a beta version of this control, and after just 5 minutes of tuning, the motor was spinning smoothly!
Here you can see me removing the fragile glass absolute encoder from the AutomationDirect motor. To clarify, my plan is to retrofit a more rugged, lower-resolution encoder (borrowed from DoomScroller) onto the motor. This should provide 10x the reliability of the factory glass encoder. However, I want the motor controller to have the ability to fail over to a sensorless control scheme if/when the encoder fails. Maybe I’m being overly cautious, but I’ve seen enough encoder failures in much more benign environments…
Other misc updates.
Parts are starting to arrive. I’m begun to translate ya’lls generous donations to metal and electronics!
I’ve been chasing down mass properties errors in the CAD model, trying to get the CG/CB correctly positioned. Ensuring a self-righting design was made a lot harder with the addition of the Starlink Mast. The avionics pod had to be lowered by 2 inches. Current CG is right at the waterline. Current weight is 205lb.
The foam for the hull has been ordered. CNC in maybe 2 weeks?
Keels need to get ordered this week from SendCutSend.
Starlink has arrived!!! Now that I’ve got my hands on it, I can get CAD’ing on the enclosure. Open question whether I can put it in a radome or if the panel needs a clear view of the sky. I need to build a rocking rig to see how the pitch/roll affects upload rate.
Power
Project Bob: I may or may not have created this entire project so that I could relive the scene of staring at the ammeter in Apollo 13.
Power benchmarks have started. The Pi needs cores disabled, I think we can shave a watt off. The servo drive for the propeller drive system is also burning a watt. I really want to run multiple Pis, but the 100mbs network switch alone draws 3 watts Anyone have a source for an ultra low power switch? Maybe should go wifi on the secondary Pi.
Progress on purchasing! The money has hit the bank account. Once again, I'm speechless in the face of ya'lls generosity. Every single person that donated even $5 will get their name on the sponsor list. We'll laser engrave a plaque with a list of everyone to mount on the prow.
Bought:
MPPT charge controller
LiFePO4 cells
Sunpower 100w solar arrays
RasberryPIs
Stainless triclamp hardware for avionics pods
Starlink mini
Manufacturing of the hull should start in ~2 weeks. We're waiting on the foam to be delivered from the supplier.
Day 2: two boats secured
Two boats secured. An incredibly generous donation from @DanielMavlyutov is going to let us build dueling boats. The race is on.
Project Bob Update: Day 2
Two boats secured. An incredibly generous donation from @DanielMavlyutov is going to let us build dueling boats. The race is on. This means we can take a bit more risk en route, taking one through storms to get the wildest footage possible. Once again, I'm blown away by the support from the Twitter universe. I had no idea there was such a willingness to support at this level.
Manufacturing update. The hull geometry needs to get released to the CNC shop. Here is an overview of how that's going to work. There is some risk in this approach, but I don't want to waffle on this for a month. Will we regret it? Possibly? This is the surfboard type approach, doing a wet layup with 6oz eglass twill directly on the plug. It will mean that the keel is captive after the glassing occurs. There will be access to the motor enclosure from the top side, under the solar panel. This should be sufficient, as the bearing shafts should never need adjustment after initial installation. The avionics pod will have a slide out tray, about 6ft long, carrying the batteries and electronics.
It does appear that we can get a conformal acrylic camera pod pointed towards the prop. This would be awesome for diagnosis on propulsion issues, as well as whalespotting.
Also entertaining the idea of a redundant and independent small drive pod in the rear. Would only be used to limp to land in case of a main prop failure.
https://twitter.com/andrewmccalip/status/1817705645224964604
Day 1
Get in loser, we’re going to circumnavigate the earth
Read the unrolled twitter thread here.
We’re going to circumnavigate the world with a droneship
Andrew’s next hobby project is here.
The goal is to complete an around the world ocean trip, autonomously navigating 25,000 miles over the course of one year. The droneship will be streaming to X live via Starlink through the whole journey.
Will it work? Who knows. Do we have a specific goal? Not really. We're just here for the grand adventure and the inevitable memes.
Why??
Insatiable curiosity, or just poor impulse control? Honestly, building stuff is fun. I like to wade into the deep end of subjects I’m not qualified for and come out the other side with a story and a new skill.
A lot of things inspired this idea. For my day job, I build spacecraft + satellites which orbit the earth. When I watched our reentry footage (), it was a conscious altering thing to watch the camera film all the way from orbit to sitting on the desert floor. It just puts things in perspective, that we live on this giant but ultimately tiny blue marble. To have hardware in my hand that went on a journey around the entire control volume that we as humans occupy, that’s special.
Wired had a hilarious quote in their LK99 interview, which I have come to like. “McCalip preferred not to dwell, but instead chose to focus on what he had set out to do: making the thing”.
So that’s what we’re going to do. We’re going to build the thing.
I’m reminded of that intro to the movie Primer.
“…They took from their surroundings what was needed... and made of it something more…”
A year ago
A year ago to the day, and coincidently my birthday, the LK99 madness kicked off with this tweet.
The entire saga was an absolute blast. We did it live and in public. The outpouring of support was unreal. From national labs to twitter anons, we were all just peers. For a moment, it looked like nature had gifted us with something extraordinary.
I remember at one point, we were one of the top Twitch streams in the world, with a webcam pointed at the door of a furnace. It was 100% on the fly improvisation as problems came up. From trying to buy red phosphorus, to building our own vacuum ampules, we just live tweeted the entire process as it was happening. It was a meme and coffee fueled rager of a week, where no one slept, and the entire world watched.
What I took away from this is that people love seeing real-life engineering adventures unfold live. It tapped into a deep-seated desire for authentic stories, rather than crafted Hollywood ones.
The webcam incident stuck with me, and a few weeks ago someone happened to mention it, and that got me thinking. What is something dramatic that would unfold over a long period of time, that the internet could get excited about? What’s a journey we could go on, where no one knows how it will end? Could we do something that no one has ever done, in our nights and weekends, for pocket change?
Trawling for likes:
I can’t believe how lucky we are on the timing. Starlink Mini just hit the market and is the enabling tech of this whole project. Of course, we’re going to livestream from this thing 24/7. The home base for this project is X (the everything app). We’ll also put updates up on the website. But X is where it’s at. @elonmusk has no idea what I’m planning to do with Starlink, and SpaceX isn’t sponsoring this in any way, though I may need to call in some favors to get my dish enabled for ocean roaming?
On the site, we’ll set up a live video stream from the Gopro, alongside the full set of telemetry channels. The route will be published as well, full transparency.
Honestly, the absolute best case scenario is if it gets picked up by pirates that were monitoring the boat’s Twitter account while the world watches live. Peak entertainment.
The boat. Why Bob?
It’s a reference to the Bobiverse, a fantastic scifi series where a von neumann probe is loaded with a human consciousness and sent out into the universe.
It’s also a pun.
The team:
My lab partner in crime is back for this one. PhD astrophysics sailor who spent a year in the Arctic. @lepsthomas
Cracked PLC test engineer @Jeff15603296 is doing all things software for this project. We’ll be hijacking his NI-killer PLC infrastructure for the backend and server side stuff.
@laskerer is going to make magic happen on the bizdev front. This idea don't have a business component, so I'm interested to see how he does it 😂
Some of these people don’t even have a Twitter presence, that’s how locked in they are. I’ll do my best to drag them online.
•Sam Knoles
•Marat Kulakhmetov
•Jordan Croom
Project Bob: Day 1
Let’s take stock of where everything is right now. We’ve been working for a few weeks to do the sanity checks, and we’re looking okay so far. It’s not physically impossible.
Excel:
•Energy budget feels within 25%
•Mass budget has been worked over is probably within 10%
•Prop budget is largest uncertainty. Need to conduct propeller experiments to downselect a diameter and pitch.
•Hull drag numbers anchored by DELFTship software.
CAD:
•Reasonably mature.
•Center of gravity and buoyancy in reasonable locations with all mass props accounted for
Hull:
•A twitter anon has incredibly kindly volunteered their giant CNC 5 axis.
•Goal is to buy foam this week and finalize geometry in ~10 days.
•Cutting and fiberglass in ~3 weeks
Propulsion:
•Not super mature.
•Keel is roughed in.
•Down selected to a prop drive after the failure of the magnetic coupler approach
•17-4 SS helical coupler candidate bought, needs testing. Can it survive 500mil cycles at 10deg off axis
Rudder:
•Basic rear mounted skeg/rudder chosen.
•Unsure about sizing. Our turning radius is way less critical than most other small boats.
Solar:
•Sunpower cells selected as array type
•MPPT need a final decision. Thinking Victron?
Batteries:
•18650s, but no brand decided. A kind twitter anon has donated 100 cells already. Undecided if these will be for development or the real flight pack.
•Packs need to be spot welded and assembled. Might get some help from the gundo boys.
PCB:
•Architecture for the deadman switch has been roughed in. More on that later. This is super important.
•Schematic design this week.
Software:
•Docker stack is being borrowed from previous applications. It has tens of thousands of hours of runtime and is fairly battle hardened.
•Grafana / InfluxDB / Telegraf contains in the process of being set up.
•Haven’t got my hands on a Starlink Mini yet to test what networking will be like.
Administrative:
•Website set up. This is mainly for the blog. We found out last time in LK99 that its hard to tell a story in hundreds of chronological twitter posts. I’ll mirror all content there.
•Givebutter donation site setup. This is going to cause a tax headache if donations actually happen.
•Youtube live account set up. We also found out the hard way in LK99 that you need to do this far in advance. I still need to work on the software stack to handle the Starlink video retrieval scripts. We’ll need to automate this in a server and continually stream the chunks as we bring them back every hour.
What’s this word, antipode?
To make it a true circumnavigation according to the rulebooks, you must meet the following:
Start and finish: The trip must begin and end at the same location
Direction: Travel in one general direction, preferably continuously
Distance: Travel a distance that is equal to or more than the length of the equator (24,900 miles or 40,075 kilometers)
Antipodes: Touch at least one pair of antipodes, which are two spots on opposite sides of the Earth
Equator: Cross the equator at a minimum of two points
We’re going to follow a variation of the classic clipper route. Because we’re launching out of Los Angeles, we’ll need to drive up into the Indian Ocean. See here.
As far as we can tell, no individual or non-professional group has ever accomplished an unmanned autonomous full circumnavigation. Two notable efforts were:
Saildrone circumnavigated Antarctica, but did not complete the larger journey of 25,000+ miles. saildrone.com/news/unmanned-…
Seacharger was a brilliantly successful hobby attempt that went 6,500 miles before a rudder failure. seacharger.com
Our route is going to take us to some of the most extreme places in the world. The southern Arctic Ocean is legendary for its weather. I’m hoping to use live weather satellite data to perform some maneuvering around major storms. These waves of the things of nightmares.geodatos.net/en/antipodes/u…
The weather?
Our thoughts about the southern Arctic Ocean are something like this.
The roaring forties have legendarily bad weather. It has been a terrifying place to take a boat, in both ancient times and modern day.
Seeing those videos had a large effect on our design of hull for the boat. Obviously, it should be able to self-right itself even if flipped over 180deg. The construction of the hull needed to be more similar to a buoy right than a ship, with a solid interior of closed cell marine foam.
Originally a more optimized trimaran hull was desirable for solar area efficiency, Unfortunately we couldn’t settle on what an acceptable load case would be to design the top solar deck to. If you have a breaking wave hit the deck, this is a huge dynamic load of hundreds of pounds per square foot. The risk of undersizing your cantilever beams in your deck is just too scary, the risk/return doesn’t seem to close on this concept.
Budgets. What do we have to work with. Let’s do some hand calcs
Everything in engineering should start with an excel sheet. Do your rough sizing, order of magnitude estimates, sensitivity studies.
In this case, we have a few critical coefficients that everything in the project is heavily dependent on. This is a multivariable optimization problem where we’re bounded primarily by power generation and consumption.
•Watts per newton of propeller thrust.
•Watt-hour/meter^2/day of solar collection
•Newtons / meter^2 of hull drag
Let’s tackle one at a time
Electrical: Power is everything:
(my favorite piece of media so far)
We’re going to have to watch every watt of consumption. If we consider our end of journey 24hr avg power output, we’re looking at 38 watts for the whole ship.
Starlink is the HUGE consumer. Average power during upload is going to be 30w. This is basically the entire propulsion budget, so we’re going to need to get this duty cycle to <10% of overall time. Burst uploading large chunks of video every 2-4hr is probably the way. Would people rather see a 5fps 1080p stream or a 480p 24fps stream?
Rudder servos need to be powered off most of the time. The average Hitec digital servo draws 1200millwatts. The strategy will be to turn on the servo at perhaps a 1% duty cycle. We’re mostly going in a straight line after all.
Gopros are very power hungry. Avg consumption looks to be around 3 watts. But if we’re not shooting video, that defeats a major point of the project. I think we’ll keep one camera powered down as a backup / diagnostic rear facing camera. Another power savings is that we’re not going to run the livestream GoPro at night. That’s a 36watt-hour savings!
ESCs are fairly efficient. I’ve chosen a Tmotor Alpha ESC with sinusoidal field oriented control. Should be one of the most efficient on the market. If you have any better suggestions, I’m all ears. Perhaps 250mw of power dissipation in the FETs.
Pis are reasonable. A 3+ in idle condition is going to draw about 1.2watts. We’ll send the secondary backup Pi into a sleep mode after the watchdog GPIO on the primary goes high.
GPS. A sparkfun gps with an I2C bus is quite low, hundreds of milliwatts.
All this needs to go into the avionic budget sheet with duty cycles. Last time I checked, we’re at 6 watts on a 24hr averaged basis.