The Ship's Log of Danu

Every great shipwreck in Lake Michigan has a story, and almost no one gets to see them. They rest in cold, dark water — beautifully preserved, well beyond the reach of a weekend diver, and almost entirely unvisited.

We wanted to change that. Not with a crewed submarine or an expensive expedition, but with something we could build ourselves, at home, on a workbench: a small autonomous submarine that can swim out on her own, find a wreck, look it over, and return to tell us what she saw.

That is Danu.

She is being built from scratch — hull, thrusters, power, cameras, sonar, and a brain that can make its own decisions in the dark. No joystick, no tether: you point her at a mission and let her go, and when she surfaces she sends word home.

We are not a company or a laboratory. We are a father and a daughter, learning as we go — and writing all of it down: the clever ideas and the dead ends, the firsts and the floods. This log is that record, kept in the open so anyone curious can follow the reasoning, and perhaps build something of their own one day.

The lake first. The wrecks first. And someday, if she earns it, the open ocean.

*— logged at the workbench*

The main camera is a small, bare circuit-board camera with a very good low-light sensor (Sony's STARVIS 2). It sounds fragile for the deep — until you realize it never touches the water.

It lives dry, behind a clear dome at the nose. The dome is the waterproof part; the camera just looks through it. That means we can use a high-quality sensor for a fraction of what a fully-sealed underwater camera costs, because we're not paying for a pressure housing around every camera.

A counter-intuitive bit: the sealed "backup" camera actually costs more than the better main camera. You're paying for its machined metal housing and depth rating, not image quality.

One gotcha we wrote down for later: a dome is a lens. The camera has to be refocused after the dome is installed, or footage shot through it will be slightly soft.

Danu ends up with three cameras:

• Front, on a pan/tilt gimbal — the cinematic eye. It can aim without turning the whole vehicle.
• A sealed nav/backup camera — an independent eye in case the dome ever fogs or floods.
• A rear-facing camera — so we can see behind when backing away from a wreck or watching for snags.

We briefly considered making the rear camera a second high-end gimbaled one behind its own dome. We talked ourselves out of it. A dome on the tail fights everything: it blunts the streamlined shape we want for efficient cruising, it crowds the rear thrusters and fins, it shifts the balance backward, and it adds a second big leak path — all to point a premium camera at our own propeller wash.

The lesson that keeps repeating: put quality where it pays off (the nose), and keep the rest simple and rugged.

There are two body plans for an underwater robot. A hovering box (like a typical ROV) can hold still and spin in place, but it's draggy and slow to travel. A torpedo cruises efficiently over distance but can't really stop and pirouette.

For covering ground in a big lake, distance wins. So Danu is torpedo-shaped, with a layout biased toward efficient forward cruising plus enough side/vertical thrust to maneuver. The tail fins are fixed (no moving control surfaces) to keep things simple and reliable — we steer with thrusters.

We're deliberately not building it modular. Build it as one good shape first, then tame the drag with fairings, rather than over-engineering swappable pods up front. If we ever want true hover-in-place work, the cleaner answer is a small separate companion vehicle — not compromising this hull.

Most small ROVs hold their depth by constantly running vertical thrusters — like a helicopter that has to keep its rotor spinning just to hover. That burns battery fast, which is fatal for a vehicle meant to roam for hours.

Danu gets a buoyancy engine instead. By changing its volume a little, it can make itself slightly heavy (to sink) or slightly light (to rise) and then just... drift there, using almost no power. Submarines have done this for a century; we're building a small version.

This one decision unlocks a lot: long endurance, the ability to rest on the lakebed to collect samples, and — importantly for an untethered robot — the ability to bob to the surface to phone home and sink again without spending much energy. More on that when we get to communications.

We want Danu to pick up small objects — a sample, an artifact, something interesting on the bottom. A torpedo can't hover steadily enough to do delicate arm-work in mid-water.

So the plan is land-and-grab: settle gently onto the lakebed (or brace against structure), *then* work a gripper. Wide feet keep it from sinking into silt or kicking up a cloud that blinds the camera. The buoyancy engine makes the set-down soft and controlled.

It's a good example of letting the vehicle's strengths dictate the method, instead of forcing it to do something it's bad at. We don't need a fancy hovering manipulator — we need a stable place to stand.

A natural question: should we add infrared / night-vision to see in dark water? The answer is no, and the reason is pure physics.

Water absorbs infrared light within centimeters. The night-vision trick that works on land (invisible IR floodlights) is useless underwater — the light is gone before it reaches anything. That's also why deep water looks blue: the warm colors get absorbed first.

So "seeing in the dark" underwater isn't about a special camera. It's two things: - Bright white light plus a genuinely good low-light sensor (which we have), for close-up detail. - Sonar for everything beyond the reach of light. Sound travels beautifully in water where light can't. An imaging sonar paints a picture of the surroundings in total darkness or murk.

That sonar turns out to be the key to autonomy — it's how the vehicle will spot things worth swimming over to look at.

Here's the hard truth that shapes the whole mission: radio doesn't go through water. Wi-Fi, cell, GPS, satellite — all dead within centimeters of the surface. While Danu is submerged, it is on its own and silent.

So we can't watch a live video feed mid-dive. Instead: - Everything is recorded onboard. - When the vehicle surfaces, it sends a quick update — a satellite text-message anywhere on Earth (tiny, but global), or a real data upload over cell signal when it's near shore. - The full footage comes off the vehicle when we recover it.

We considered a clever trick — reeling a little floating antenna up to the surface while the body stays down. But that's just a thinner tether, with all the snag and complexity we're trying to avoid. The buoyancy engine already lets the whole vehicle pop up to report and sink again cheaply, so that's the plan: dive, explore, surface to check in, repeat.

And Starlink? Great — but on the support boat, not the sub. A satellite dish is far too big and power-hungry for a small submarine bobbing in waves.

This is the part that makes Danu more than a fancy RC toy. The onboard computer runs a loop:

1. Search a planned area, scanning with sonar.
2. Notice something that stands out — a hard, geometric, or unusual shape against the natural bottom.
3. Go look: steer over to it, switch from sonar to camera and lights, and record.
4. Judge: decide if it's actually interesting (man-made? worth a closer pass?).
5. Report: if it found something good, surface and ping us — "found something here," with a thumbnail when there's signal — and optionally wait for a yes/no before continuing.

Two pieces of hardware make this real, and we just moved both into the main build: the imaging sonar (the eyes in the dark) and a navigation sensor that tracks motion against the seabed so the vehicle knows where it is and can return to a spot precisely. Without that, "go back to that object" is just guessing.

The onboard AI doesn't get to invent wild behavior — it chooses among options we've pre-approved (investigate, skip, mark, come home). Autonomy with guardrails.

We just got our hands on a proper navigation sensor — a DVL (Doppler Velocity Log), which tracks the vehicle's motion by bouncing sound off the lakebed. It's the difference between "I think I'm somewhere over there" and "go back to that exact spot."

But a single sensor is a single point of failure. So we're also building a second, independent way to know how we're moving — in software, for basically free.

It's called visual-inertial odometry. The downward camera watches the bottom slide past; we measure how far the texture moves between frames, scale it using the sonar altimeter (how high we are off the bottom), and correct for tilt using the motion sensors. Out comes a velocity estimate — a "fake DVL" that costs nothing but code.

It's not as precise as the real thing, and it needs a lit, textured bottom to work. But running both at once means if one drops out, the other keeps us oriented. That theme — never trust one sensor — runs through the whole vehicle.

Here's the nightmare: months of work swims off into Lake Michigan and never comes back. Preventing that is a top design rule, and the answer is layers — no single failure should be able to keep the vehicle down.

Make it come back up Normally a buoyancy engine surfaces it gently. But if everything fails — flooded, dead battery, frozen computer — a last-resort drop weight releases, making the vehicle lighter than water so it floats up on physics alone. A separate watchdog brain triggers this even if the main computer is silent.

Find it once it's up When it surfaces it reports its GPS position. We also want a recovery beacon that runs on its own separate battery and brain, so it can still call home even if the main systems are dead. Add a bright strobe for night recovery, and an underwater "pinger" to home in on it with a microphone if it's stuck on the bottom.

Don't fail in the first place Backups everywhere: two depth sensors, two battery banks, multiple cameras, two independent ways to navigate, a watchdog that forces the vehicle to surface if the main computer goes quiet.

And early on, we cheat The first dives happen on a safety line, so a rookie mistake can't cost the whole vehicle. Trust is earned before the leash comes off.

When people picture losing a submarine, they imagine it getting crushed by the deep. In a Great Lake, the likelier killer is far more mundane: getting tangled.

Lakebeds — especially around the shipwrecks we want to visit — are draped in lost fishing line, old nets, ropes, rigging, and weed. The thrusters are the weak point: a single strand of monofilament can wrap a propeller and stop the vehicle cold. And the worst instinct is to power harder to break free — which just winds it tighter.

So we design against it in layers: - Guards over the thruster intakes so props can't grab line — the biggest single win. - A smooth, faired body with no open hooks or loops for a net to catch. - Snag detection in software: if a thruster strains while barely turning, the vehicle *stops* instead of fighting, tries a gentle wiggle to shake loose, and if that fails, drops its weight and floats up. - Stay out of trouble: keep a respectful distance from wrecks and never go inside one — penetrating a wreck is how machines get trapped forever.

And the honest part: monofilament line is nearly invisible to sonar, so you can't detect it ahead. You can't beat it completely — only stack the odds and carry a way to be found and recovered if the lake wins a round.

The dream is a vehicle that lives in the lake for months and looks after itself. That turns out to be less about a big battery and more about two things: harvesting energy and barely spending it.

Harvest: a solar fin A flat strip of cells on a round hull catches almost nothing. So we're adding a dorsal solar fin — a printed spine that rises from the round hull to a flat top deck, so head-on the vehicle looks like a T. It carries far more upward-facing panel, doubles as the mast for the antennas, and — with a buoyant top and a heavy keel — makes the vehicle naturally float panel-up to charge. We shape the spine like a teardrop (an airplane-wing cross-section) so it doesn't drag too badly underwater.

Spend almost nothing The real trick is consumption. Most of the time the vehicle should be asleep, drifting and charging, woken only by a timer. Instead of running motors to hold depth, it uses its buoyancy engine. Missions happen in short bursts, then it goes back to sleep. Done right, it sips a few watts — little enough that a sunny day refills more than a quiet day drains.

The catch nobody mentions The thing most likely to end a months-long mission isn't the battery — it's biology. In the Great Lakes, mussels and algae will grow over the hull, the solar, and the camera lenses in a matter of weeks. We can fight it with coatings and wipers, but realiztically we'll still have to pull the vehicle out now and then to clean it. Nature is patient.

We got excited about a submarine that lives in the lake for months. Then we did the honest math and the honest risk assessment, and dialed it back to days — and the project got better for it.

Why the change: - Biology wins the long game. Mussels and algae would foul the hull and solar within weeks, forcing us to pull it out anyway. "Months unattended" was partly a fantasy. - You can't lose what you can reach. Leaving it far out for weeks is the easiest way to lose a year of work. Days-long trips that come home keep it recoverable. - It matches the actual goal: transit out to a further wreck, explore for a few days, come back.

So the new target is multi-day missions. That means a bit more battery — but the real trick isn't a bigger battery, it's using less: cruise slowly (power grows with the cube of speed), rest on the bottom between legs using the buoyancy engine, and sleep the computer when there's nothing to do.

And we finally have somewhere to start small: a swimming pool for first wet tests, then a reservoir for autonomy, then Lake Michigan. Crawl, walk, run.

Before building anything bigger, we did the energy math — how far can it really go, and for how long?

Slow is the superpower The power to push through water grows with the cube of speed. Double the speed and you need eight times the power. So the whole game is cruising slow: at a gentle walking pace the vehicle sips only tens of watts to move, which is what makes multi-day trips possible at all.

How long A realiztic day — some transit, a bit of filming, lots of resting on the bottom — works out to roughly a few hundred watt-hours per day. The current battery is good for about 3 days. Want a week? Add battery (a longer tube, same diameter) — but we'll measure the real draw in a reservoir first instead of guessing.

How far With energy held back for the trip home, the practical reach is on the order of tens of kilometers out and back — enough for plenty of Lake Michigan wrecks near and moderately offshore. Crossing the whole lake in one go is out of reach for this pack. Currents and weather will trim those numbers, so we treat them as optimiztic until real-world tests refine them.

The ocean is a different animal The dream is oceans someday. Honest answer: a battery-powered thruster sub can't cross an ocean — it'd need ~20× the battery. The machines that cross oceans don't really use motors; they glide on buoyancy or harvest waves and wind. So the ocean version is a *different vehicle* down the road. This one is how we learn to build it.

When I first saw the number on the page — a hull just four inches across — my gut said that can't possibly be stable. I pictured needing something fat, eighteen or twenty-four inches, to keep from rolling over or getting shoved around by the lake. I was wrong, and learning why was one of those moments where the engineering turned out more elegant than the intuition.

Stability isn't about width

A submarine doesn't stay upright because it's wide. It stays upright because its heavy parts sit below its buoyant parts. Put the batteries low and the air and foam high, and the whole vehicle hangs like a pendulum — tip it, and it rights itself. That's the trick every torpedo, every survey robot, and every ocean glider uses, and it's why they're all long, skinny tubes instead of fat discs.

Going wide would actually make Danu worse. Drag grows with frontal area, so a twenty-inch hull would have something like twenty-five times the cross-section to push through the water — gutting the very range that is the whole point of the mission. And I'd never carry it to the water by myself. Width buys nothing here. The slender shape, plus a pair of fixed tail fins, gives all the steadiness she needs.

What about current? What about boats?

Two honest worries I had — and the honest answers:

Current won't tip her, but it will push her. Lake Michigan's currents run a few tenths of a meter per second, a real fraction of her cruising speed. She won't capsize, but she will get set off course. The answer isn't brute weight; it's navigation. A Doppler velocity log feels the current directly, and every time she surfaces she snaps her position back to GPS. Drifting becomes a managed, self-correcting condition instead of a failure.

A passing boat won't blow her away — because she won't be there. Wakes and propeller wash are a surface phenomenon; their energy fades fast with depth. Danu lives submerged and deep, surfacing only briefly to check in. And she listens: a hydrophone picks up engine noise, and a nearby vessel is reason enough to delay coming up. On the surface in chop she'd bob like any small craft — but she's a powered, ballasted machine that holds her heading, not a piece of driftwood, and she's only up there for minutes.

None of this makes heavy seas or busy traffic nothing — they're real limits. But the move is to respect them: stay deep, surface briefly, listen first — not to out-muscle them. Skinny, low-drag, and smart beats fat and stubborn.

*— logged at the workbench*

Today was an electrical day — the unglamorous wiring and fusing nobody ever sees, but the stuff that actually decides whether Danu comes home. Less romantic than shipwrecks, and exactly the kind of thing that quietly sinks projects, so it got the whole day.

A fuse at every source

The pack is three battery banks, about 3.6 kWh. The rule that crystallized today: put a fuse at every source, and let it protect the wire — not the other way around. One on each bank, a big one on the main bus where the banks combine, small ones on the survival and electronics legs. And because lithium can dump enormous current into a dead short, these have to be the heavy, high-interrupt kind — not the glass fuses in a junk drawer.

Killing the power, and arming her from outside

Two decisions I'm happy with. First, a real master cut — a contactor the safety computer can open the instant something's wrong: a leak, a low battery, a missed check-in. The little switch I'd originally planned can't break that kind of current; it only ever *signals*. Second, an arm switch you trigger with a magnet from outside the sealed hull — no hole, no toggle, no penetrator to leak. Wave a magnet and she's live. That one made me grin.

The boring detail that eats hulls

Corrosion. Turns out that in fresh water — which is most of what Lake Michigan is — the usual zinc anodes barely work; you want magnesium. And the electrical system should *float*, electrically isolated from the hull and the water, so stray current doesn't quietly eat the aluminum. It's the kind of thing that looks fine for a season and then doesn't. Anode added, lesson logged.

The rest was plumbing: anti-spark connectors so plugging in the pack doesn't throw a spark, heavy wire for the trunk and lighter wire for the branches, the right crimpers, a small power hub, capacitors to smooth the surges, and a charge port so I can top her up without cracking a tube open every time.

How far can she go?

I keep coming back to wanting two-week missions. The good news from today: that's not a redesign. The hull is modular — more endurance is just more battery tubes later. So the move is to build the headroom in now (size the wiring and structure to take more banks), prove the real power draw in the reservoir, *then* add cells — rather than guess and over-build a heavier, draggier sub on estimates. The two best range multipliers turned out to be the least glamorous: a little more battery, and a glide mode that lets her sink and drift on almost no power between waypoints.

A daydream I let myself have

And then the fun part. I sketched a wild one: a solar-powered companion — a tanker that travels with Danu, soaks up sun at the surface, and refuels her in the field. A KC-135 for submarines. Instead of just falling in love with it, I ran it down hard. The honest verdict: the romantic version — a second craft that submerges to hide and docks to her out in open water — is a trap. It's a harder vehicle than Danu herself, and it doubles what I could lose. But there's a real seed in it: a simple anchored solar buoy she swims back to for a recharge. Filed away for someday.

That's the part I love about building in the open — even the ideas that don't survive contact with the math teach you something.

*— logged at the workbench*

This weekend, Danu got her brain. There were a few hours where it was genuinely unclear who was in charge — but the brain is online now, and we've made peace.

The compute is an NVIDIA Jetson Orin Nano — the small board with the big fan in the photos. It's the part that will eventually look at the camera feed, decide "that's a shipwreck, not a rock," aim the cameras, and know when to turn for home. Getting it running was the fiddliest job on the bench so far. It's done.

What it took

Two parts: install the operating system (Ubuntu Linux) onto a fast NVMe SSD — that little stick on the underside in one of the photos — then add the AI libraries (CUDA and friends) that let it run vision models quickly.

The modern way to install the OS is to make a bootable USB stick and run it on the Jetson. Which brings us to today's lesson.

The snag (and the fix)

My first USB stick — a fancy 256 GB USB-C drive — the Jetson flat-out refused to boot from. It didn't even show up as an option. Twenty minutes of "is the board broken?" later, I grabbed an old 32 GB USB-A thumb drive, and it worked instantly — no network connection needed, nothing. Ubuntu installed itself, then walked me through Wi-Fi on the first boot.

That's the whole experience of building something you've never built: the step that should take five minutes takes an hour, and the fix turns out to be "use the other drive." We'll keep showing those, not just the wins. (Filed under: if your new Jetson won't boot the USB, try a smaller, plain USB-A stick.)

After that, the AI libraries went on, and we got the board on the network over SSH — so we can talk to the brain with no monitor attached, exactly how we'll reach it once it's sealed inside the hull.

Where we are

• Done: design locked, parts list set, and the brain alive and answering.
• Now: the "bench bot" — proving every system on the workbench, dry, before any water is involved.
• Next: the flight controller, the depth and motion sensors, and the first thruster spin.

Thanks for being here this early — it's my daughter Aarushi and me, a workbench, and a wildly ambitious little submarine. You get to watch the whole thing unfold, USB-drive faceplants included.

From brain to nervous system Last time Danu got her brain (the Jetson). But a brain doesn't drive motors or feel which way is down — that's the job of the flight controller, a Pixhawk 6C. It reads the sensors, keeps the sub level and on-depth, and commands the thrusters. This weekend we woke it up.

Step 1 — give it its reflexes We flashed it with ArduSub, the open-source autopilot built specifically for underwater robots (the submarine relative of the software that runs on a huge range of drones and rovers). That's the reflexes: hold depth, stay level, respond to commands, and fail safe.

Step 2 — feed it power without frying it This is where a first-timer sweats. Instead of connecting a real battery — where a single wiring slip can cook the electronics — we used a bench power supply with a current limit. Think of it as a faucet with a hard cap: set it to half an amp, and even a dead short can only ever pass half an amp. Harmless.

We tested that safety net *on purpose* — shorted the leads and watched the supply calmly refuse to give more than the limit — and only then trusted it with the real hardware. The power runs through a power module that sits between the battery and everything else, passing current through while reporting voltage and amperage back to the flight controller.

The snags (there are always snags) - The power module's cable didn't fit the flight controller's port. The tempting move — cut the wire and splice on a connector that fits — is also a great way to fry a board, so we tracked down the right cable instead. - Then the flight controller went silent — plugged into the laptop over USB and… nothing showed up at all. Twenty minutes of "did we just kill it?" later, the fix was rebooting the *laptop*. The board had been fine the whole time.

The payoff With the module powered up, the flight controller booted on its own power — no USB, sipping about a tenth of an amp — and then reported its own battery voltage back to us in QGroundControl (the app we use to talk to it): 14.95 volts, matching the bench supply to the decimal — you can see it in the screenshots below. A nervous system that powers itself and knows its own vitals.

Where we are - Done: flight controller flashed with ArduSub; power module bench-tested behind a current limit; the whole stack running on its own power and reporting battery telemetry. - Now: the "bench bot" — proving every system dry on the workbench before any water gets involved. - Next: the sensors — depth, compass, motion — and then the first thruster spin. 🔧

We've spent the last month heads-down — flashing firmware, chasing USB gremlins, watching a flight controller report its own heartbeat. This week we stepped back and did the least glamorous, most important thing on the whole project: we wrote down everything Danu is being built to do.

Engineers call this a requirements document, and it's easy to hear that as a rulebook. It isn't. Requirements are the *whole dream, written precisely* — what she must do, how deep and how long and how far she must go, and yes, the lines she must never cross. Every part we buy and every line of code we write now answers one question: which requirement does it serve? The full set is public, like everything else here: the Requirements.

What she must do

• Find Lake Michigan's shipwrecks on her own — no pilot, no tether. She runs the mission; we review at surfacings.
• Film them and bring the footage home — 4K video and sonar imagery, recorded onboard. The drive she carries back is the treasure.
• Surface to report — radio doesn't go through water, so she rises on a rhythm: GPS fix, send findings, take new orders, dive again.

The numbers she's built to hit

• 300 m operational depth — deep enough for the wrecks worth visiting.
• Multi-day missions — 3 to 5 days out on ~3.6 kWh, sleeping on the bottom between work.
• 30–50 km round trip — real reach along the coast, on battery, at a patient cruise (speed is the enemy of range — drag grows with its cube).
• Light enough for one person — about 2.2 m and under ~40 kg, launched from shore by one determined dad. That single constraint shapes the whole vehicle.

These are design targets, not measurements — the reservoir tests will grade our homework, and we'll publish the corrections. That's what built in the open means.

The lines she never crosses

• Fail to the surface, findable. Any single failure ends with her floating, locator running — drop-weights, an independent timer release, a strobe, an acoustic beacon, stacked.
• The AI advises; deterministic checks decide. No plan flies without passing the geofence, energy-reserve, depth, and deadline validators. The safety chip doesn't even know the AI exists.
• Look, film, never take. Great Lakes wrecks are protected — legally and morally. Danu films; she does not touch.
• Never past proven depth. She dives no deeper than what we've pressure-tested to at least 1.5x.

Why write it down at all?

Because requirements are cheap to change and hulls are not. Arguing with a sentence costs nothing; discovering mid-lake that two goals contradict costs the vehicle. This isn't theoretical — writing *multi-day endurance* against *one-person launch* is exactly the kind of tension that reshaped our battery-tube sizing just last week. The document caught it while it was still a purchase order, not a rebuild.

And because a spec deserves better than a PDF... trading cards

We're releasing the requirements as a numbered card series on Instagram and X — one card at a time, covering all of it: the mission, the performance targets, the safety net, the ethics. Each card states a requirement; the slides behind it show the design that achieves it. Card #01 — Explore on her own drops today. Collect all ten.

Where we are

• Done: design locked - full BOM speced - Jetson brain online - flight controller + power system verified - requirements written and published.
• Now: the bench bot — sensors on I2C are next, then the first thruster spin.
• Next: REQ cards #02–#10, one a week, while the bench bot comes alive.

A submarine's most basic question is the one you'd ask in a dark pool: *how deep am I?* This week, Danu learned to answer it.

The depth sensor came online — and not in a "the light blinked" way. A reading traveled the whole chain: from a stout little sensor no bigger than a thumb‑tip, stamped "30 BAR," out through a coil of hair‑thin wires, into a tiny splitter board, and finally into the flight computer that will one day hold Danu steady in the cold black of Lake Michigan. On the screen, a number that finally meant something real: depth.

Then came the part you can *feel*. Put your lips on the end of the sensor and blow, gently — and the number climbs. One breath registered as about a meter of depth. That's the whole trick of the thing: it can't tell your lungs apart from a meter of lake sitting on top of it. Pressure is pressure. (It's also the best kid‑at‑the‑workbench demo we've found yet — blow into the tube, watch Danu "dive.")

The other half of the week was humbler. The compass — the sense that tells Danu which way it's pointing — fought back. We'd bought a bargain magnetometer, and it turned out to be the kind of bargain that eats a weekend: no labels on the pins, fussy voltage, a little spider's web of hand‑soldered wires just to get it to say hello. We got it *working* — but "working" isn't the bar for something we're going to seal inside a hull and send into the dark. So we ordered the proper, purpose‑built board instead. Sometimes the cheapest part is the expensive one.

So Danu isn't fully "sensing" yet — depth is proven, heading is on the way. But that's the honest shape of building something real: one sense at a time, each one earned. When the compass lands, Danu will know how deep it is *and* which way it faces — the ground floor of actually finding its way.

Built in the open, one breath at a time.

Card #02 in our requirements series is up — and it answers the first thing anyone asks about a submarine: how deep?

300 meters

Danu is built to operate at 300 meters. For perspective: Lake Michigan's deepest point is about 281 m — so 300 m means she can reach the bottom anywhere in the lake. And nearly every wreck worth finding sits far below where a scuba diver can safely go (~40 m). The depth isn't a flex, it's the whole point. It's what puts the wrecks in reach.

Rated by her weakest part

Here's the honest engineering most specs hide: a vehicle's depth rating isn't the depth of its *toughest* part — it's the depth of its weakest wet one. Danu's pressure tubes are good to ~900 m and her lights to 500 m, but her depth sensors, buoyancy foam, and navigation sonar top out at 300 m. So 300 m is the rating. The shallowest link sets the limit.

Never past a tested limit

A spec sheet is a promise, not proof. Before Danu dives anywhere real, every hull, dome, and seal is pressure‑tested to more than 1.5× its operating depth — 450 m of pressure for a 300 m sub. If a part hasn't been proven, it doesn't dive. (Depth itself is the one thing she always knows exactly — it's just pressure. She can only ever get lost sideways.)

Meanwhile, on the bench

Fittingly, this was the week Danu's first depth sensor came alive on the workbench — we pressed on it and watched the pressure reading jump, the exact sense this card is about. The requirement on the card and the part in our hands, meeting in the middle.

Card #02 — Built for the deep. Eight to go. The whole spec is public: the Requirements.

For months, Danu has been a plan — a requirements doc, a bill of materials, and a pile of carefully machined parts waiting on a bench. This week she started to feel like a machine.

She senses Three of Danu's senses came online, all reading live on the workbench:

• Depth — the pressure sensor that tells her exactly how deep she is. It's the one thing she'll always know for certain; underwater, you can only ever get lost sideways.
• Leak — the sensor whose entire job is to scream *abort and surface* the instant water reaches somewhere it shouldn't.
• Water temperature — reading the lake around her to a tenth of a degree.

She moves Her first thruster spun up on command. That sounds small, but one spin proves the whole chain end to end: power leaving the battery bus, running through the speed controller and into the motor — driven by a command that started as a slider on a laptop. Every link was a place it could have broken. None of them did.

She thinks (a little) Danu carries two computers: a flight controller that runs her reflexes, and an AI computer that will eventually make her decisions. This week they spoke to each other for the first time — a real data link between the two, with the mission-control software now seeing and steering her *through* the AI computer, exactly the way it will work when she's on her own. That quiet handshake is the foundation the entire autonomy system stands on.

The part nobody puts on the highlight reel Building in the open means sharing the floods, not just the wins — and this stretch had a nasty one. A brand-new depth sensor would work for two minutes, then vanish, every single time. It wore five different disguises — a power problem, a wiring fault, a bus conflict — and cost us days of chasing ghosts, until we swapped in a spare and proved the unit was simply defective out of the box. There was also a leak sensor that detected water flawlessly but flatly refused to appear in software, until we dug up one buried setting its own manual promised we would never need.

The rule that keeps earning its keep: dry-test everything on the bench before it ever touches water. Every one of those gremlins would have been a nightmare sealed inside a tube at the bottom of Lake Michigan.

Why the bench Before Danu is sealed into an aluminum hull and lowered into the lake to go find shipwrecks, her entire nervous system gets proven — sense by sense, wire by wire — on a workbench, where a mistake costs an afternoon instead of a vehicle. This week, that nervous system came alive.

What's next Right now, every command still comes from a human at a laptop. Next, we start teaching Danu to make those calls herself. The reflexes are wired and the senses are online — now comes the mind.

Everything that can be tested on a table has been tested on a table. It's finally time to start working on the actual sub!

Here's what's working.

Both compasses are green

The RM3100 is the good magnetometer, the one that doesn't get confused by thruster motors running a few inches away. It's calibrated, sitting at Priority 1, and the Pixhawk is happy with it.

It took three of them to get there. The first didn't show up on any bus at all, and after a lot of continuity checking it turned out I'd been soldering at over 800F when you want about 600. Cooked it . . . turned the iron down and the replacements went in fine.

Sixteen cells, and a math problem I didn't expect

The battery is 4S16P: sixteen cells in a circle, four of those stacked, three times over. 192 cells, about 14kg, roughly half the weight of the finished sub.

So I needed a plate to hold sixteen 21mm cells inside a 103mm tube. Turns out "how do you pack 16 circles into a circle" is a solved problem with a known best answer, and it isn't a tidy ring. It's two irregular rings, and it's been proven optimal to about fifteen decimal places by people who care considerably more about this than I do :) I pulled the coordinates from Packomania.

3D Printed the plate. All sixteen cells dropped straight in. That was a good moment.

Then a mid-span collar so the stack doesn't lean, and a top plate with small crush ribs around the outside so the pack can't rattle inside the tube. To find the right rib size I printed a test gauge with four different diameters stacked on one part, so one print told me the answer instead of four (sort of ... I still ended up printing a few more test plates to hone it in a bit).

103.75mm. Slides the whole length of the tube, touches all the way round, doesn't need forcing.

The deadman can tell one dead computer from two

The supervisor is a small STM32 whose entire job is to notice if the sub has stopped thinking and, if it has, drop the weight and float it home. It listens for a heartbeat from the flight controller and one from the AI computer.

The rule is that it only fires if *both* go quiet. One dead computer isn't an emergency. Two is.

That now works in both directions. Cut the flight controller's heartbeat and nothing happens. Cut the AI computer's and nothing happens. Cut both and it counts down and fires into a test load, exactly as it should.

Getting there meant giving each brain its own wire. They'd been sharing one, which sounds fine right up until you notice that a single broken connector silences both at once, and that looks identical to both computers dying. Two wires, and now the test actually proves something.

Danu is on the internet

Cellular near shore, satellite everywhere else. The LTE half is up: registered on T-Mobile, 160ms round trip, pulling an address.

Two things stood in the way. The SIM had never been activated, which is a five-minute fix once you're confident the problem isn't your antenna or your wiring. And the modem defaults to a USB mode that needs a driver NVIDIA doesn't ship in the Jetson's kernel, so nothing bound to it and the system spent ten attempts insisting the modem didn't exist while it sat right there in the device list. One setting changed, worked instantly.

The antenna side came out better than I expected. Four networks visible at -73dBm through a flexible antenna the size of a stick of gum.

The best part

Cell carriers don't hand out real internet addresses anymore. You get one shared behind their NAT, which means nothing on the internet can reach your device.

So I put Tailscale (VPN) on it. The sub dials out, and from then on I can SSH in from anywhere as if it were sitting on my desk.

Tested it properly too. Turned the WiFi off and tried to reach it. danu.local didn't resolve, which is exactly right, the local network was genuinely gone. Then ssh danu connected over cellular.

I can log into my submarine from anywhere in the world. It's in my basement sitting right next to me. But still.

Next

Bench work is over. Now it's the real thing: three battery packs to weld, trays to build, tubes to fill, and about 25 liters of foam to shape by hand so the whole thing floats.

More soon.

One of the three battery packs is finished. 64 cells, 14.28 volts across the whole thing, and all four groups reading exactly 3.57 . . . which is about the best first-pack result I could have hoped for. Four groups sitting at the same voltage means every parallel connection is doing its job and every series joint is solid.

Two more to go.

What's actually in there

Each pack is what's called 4S16P. Sixteen cells wired in parallel to make one big cell, then four of those stacked in series to get the voltage up.

• 16 cells in parallel -> 3.57 volts, 88 amp-hours
• 4 of those in series -> 14.28 volts nominal, 16.8 fully charged
• Per bank: about 1.3 kilowatt-hours
• All three banks: roughly 3.9 kWh

For scale, that's a bit more than a typical e-bike battery per pack, and three of them. At full thrust the sub pulls about 145 amps and would empty the whole lot in under two hours . . . but we'd only need that occasionally when fighting a current. Cruising is about 3 amps. Poking around a wreck with the lights on is about 12.

192 cells total. I have cut and welded a lot of nickel this week . . . gashes and scrapes on all my fingers .. nickel is sharp!!!

Why there's copper in there and not just nickel

Each cell gets a thin nickel tab spot-welded to it. That tab only carries that one cell's share — 48 amps for the layer divided by 16 cells is 3 amps each — and a tab is only about a millimeter of cross-section, which is fine for 3 amps and nowhere near enough for 48.

The bit between the layers Between the layers, the connection is a full nickel disc (each of the four layers gets a nickel disc welded to both of its faces while it's still open and reachable) rather than a strip, and that changes everything: a disc has roughly 26 times the cross-section of a tab. Plenty for the whole 48 amps, and because cell N sits directly above cell N, the current only travels about 10 millimeters sideways to the nearest weld before crossing over. Then the layers stack, two discs meet, and I weld them to each other through notches cut in the printed plates.

The two ends of the pack are copper. Not because nickel couldn't carry the current — it could — but because that's where everything bolts and solders to the outside world, and copper is simply the better metal for a lug and a soldering iron. Nickel oxidises and wets badly. Which is also why we can't take a shortcut and spot-weld the copper: it conducts the welding energy away before anything fuses. Weld to nickel, solder to copper.

The trick — and I did not get this on the first try — is to spread those welds out across the whole disc rather than putting them round the rim. If they're only at the edge, current has to run out to the rim, cross over, and come back in, which is a long way to go for no reason. Welded at every gap between cells, the current just crosses wherever it arrives. About 70 welds per interface.

The BMS

Every pack gets a battery management system (BMS) — a board whose entire job is to stop the pack hurting itself. Overcharge, over-discharge, over-current, short circuit. The one's we are using have 15 power transistors on it, eight handling discharge and seven handling charge, which is why it can be trusted with the currents this thing pulls.

It has separate terminals for charging and for load, which matters more than it sounds: everything that draws from the pack has to go through the board. Wire something around it and the protection doesn't apply to that thing.

The one thing it can't do is talk. No data connection at all. It'll cut the pack off to save it, but it won't tell you why, and it won't warn you first.

Which brings me to the interesting part.

Watching the pack instead of trusting it

Sitting on top of each pack is a small board that does the things the BMS won't:

Per-group voltage. A 16-bit converter reading each of the four groups through precision dividers. The number that matters isn't the total — it's the spread between the highest and lowest group. A pack can sit at a perfectly healthy 14.8 volts while one group quietly drifts off on its own, and by the time the BMS notices and trips, you've lost a third of your power. Under 20 millivolts of spread is fine. Over 50 and something isn't right.

Current, properly. A half-milliohm resistor in the main path and a chip that measures the voltage across it. At 48 amps that's 24 millivolts . . . not much, which is why the chip counts charge in and out continuously rather than guessing. On lithium the voltage is nearly flat from 30% to 80% full, so voltage is a terrible fuel gauge. Counting the actual coulombs is the only way to know how much you have left, and "how much is left" is the number that decides whether you turn for home.

Temperature, in four places — the highest-current solder joint, one mid-stack connection, the fuse, and a cell in the middle (centre cells run hottest).

Pressure and humidity in the tube. This one is a safety sensor. If a cell ever vents, it releases vapour, and pressure and humidity spike *before* heat ever conducts through a steel can to a temperature sensor. The same reading also catches a leak, so one sensor covers both of the ways a sealed tube ruins your day.

All of it runs off a regulator that idles at 15 *micro*amps. That sounds like a small detail until you work out that an ordinary one would quietly eat a quarter of the pack over six months sitting in the garage :)

How three packs become one

Each pack reports over a shared data bus to the main computer, which passes it up to mission control — so we can see all three, group by group, on a webpage rather than by pulling a tube apart.

On the power side the three feed a single bus through one-way devices. That matters because without them the strongest pack would try to charge the weakest, and a pack that failed would drag the other two down with it. One-way means each pack can only ever give.

Aarushi's contribution this week was mostly asking why it was taking so long and whether it was done yet. One thing I've noticed, the goal line keeps moving. The further I get with this project, the more I uncover to be done.

Where we are

• Done: Bank 1 built and measured — 14.28 V, all four groups matched. Welding process calibrated. Pack monitoring designed and parts in hand.
• Now: Building the electronics module that sits on top of bank 1 — BMS, voltage and current monitoring, temperature and tube sensors.
• Next: Banks 2 and 3, then all three into their tubes.