Kyle Tran

The V2 software ran against a laptop simulator before any hardware was attached, and its command center still does, in the browser. Its mission was a state machine — transit → deploy → sample → retract → advance — with geo-fenced boundaries and automatic return-to-home on low battery.

V3 is modular by intent: the hull, payload and software are configured for each job, starting with surface water-quality surveys. Swap the pod and the same platform could carry sonar for bathymetric mapping, cameras for an underwater survey, or tools for collecting samples.

Next comes fabricating the boards and assembling the electronics, pod and fish finder into the new hull, then firmware for autonomous waypoint navigation, surface sampling and depth logging, and field trials. We’re talking with the Charles River Watershed Association about collecting water-quality data for them. The CRWA and the Port of Oakland both told us their teams still collect sediment samples by sending divers down, and that is what my robotic arm is for: a deck arm that works with the winch to bring water and sediment samples back.

After every match, win or lose, we'd pull the robot apart and work out what broke and why — every design generation came straight out of that damage analysis, so I learned to design for repairability first.

The best part was teaching. As club president I ran workshops on CAD, soldering, physics, and fabrication. A few members went on to build and compete with robots of their own.

I started on paper, sketching chassis shapes, sensor placements and drivetrains, then drew the layout that worked as a master sketch in Onshape and modeled every part off it. Checking each dimension and constraint in CAD before exporting meant every printed part fit on the first print.

Most of the design came out of testing. Matthew and I took turns: one of us ran the robot through the course while the other watched for what went wrong.

What I’d carry forward: prototype early, before committing to prints; structure code as modules from the start instead of untangling it later; and design for the person testing it, even on a prototype. The LCD menu made every test run faster.

That same asyncio architecture carried straight into the survey boat's firmware — concurrent tasks on one Pico, just on water instead of in a maze.

Every joint is sized for its worst pose: the arm straight out with a 1.2 kg payload at the tip, accelerating at 3 rad/s². That puts the shoulder at 11.30 N·m and the elbow at 4.70 N·m, and a 1.5 service factor makes them 16.95 and 7.05 N·m to design for. The shoulder’s NEMA 23, at 1.9 N·m, gives about 24 N·m through 15:1 at 85% efficiency, the elbow’s NEMA 17 about 8.4 N·m through 22:1, and each servo needs 0.96 N·m of its 2.5. The joint and link masses behind those numbers are estimates rather than CAD figures, and wiring and fasteners always come in heavier than expected.

The tightest bearing check is the shoulder’s rated life: 2,522 h against a 2,000 h target for its 6704. The motors get checked through their gearboxes too. Every ratio here is above the minimum its motor needs, so a stalled motor could push its gearbox past the design torque; the simulator turns that into a driver current limit for each joint, about 37% of peak current at the base, 70% at the shoulder and 84% at the elbow.

At ±0.05 mm there is room left for backlash and structural compliance, which are the larger errors anyway. At ±0.15 mm four fifths of the budget is gone to one source before the arm has moved. That is why the discs get a finishing pass: the laser gets them close, and the mill takes the profile the rest of the way, cleaning up the cut edge exactly where the rolling contact happens.

The encoder sits on the gearbox output, not the motor. It reads the joint angle directly, so the gear ratio drops out of the precision question and only affects torque and speed. It is a 12-bit AS5600 at 0.09° per count, about 2.8× under the target — thin, but backlash and compliance are the bigger errors at this tolerance, so a 14-bit part would be buying precision in the wrong place.

An IMU was the other candidate and does not work here. An IMU measures a link’s orientation against gravity, so it is blind to rotation about a vertical axis — that alone rules out base yaw without leaning on a magnetometer. Even with good fusion an IMU holds roughly 1–3° statically, against a ±0.25° target. It may come back as a supplement on the end effector for an absolute level reference or vibration sensing, but not as the joint sensor.

Forearm roll has a wiring problem rather than a sensing one. The wire sits untwisted at encoder center and a single hard stop sits directly opposite, so the joint swings freely between but never accumulates past a half turn of twist. That stop is physical as well as in firmware — a software limit alone does not protect the wire if the encoder glitches or the board loses position across a power cycle.

Further out, this is the deck arm for the survey boat, working with its winch to bring water and sediment samples back. Our conversations with the Port of Oakland and the Charles River Watershed Association showed that their teams still collect sediment by sending divers down. A submersible on the tether collects the sample; the arm takes the full container off it, stores it aboard, and puts an empty collector back. That is the reason for grip-force feedback and a compliant gripper rather than a rigid claw — a tethered submersible under a moving boat will not present itself at a repeatable position.

The interface between the two is not defined yet, and the marine side is deliberately deferred: sealed encoder housings, waterproof connectors, marine-rated bearings, anodised rather than bare 6061. None of that gets designed until the mechanism works on a bench.

Still open before hardware: the tolerance the finished discs actually hold, whether J1 moves from printed PLA to aluminum, and real link masses from CAD to replace the estimates above.