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.

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

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

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.