Why I’m coming back to hardware.
I used to build underwater robots. Now I’m studying hardware timing in C++ and getting started with FPGA inference.
In eighth grade, I built a smart-home proof of concept. At that age, it felt enormous. I was putting software and electronics into a model of a home that I could change and show to other people. Looking at it now, with its blue frame and all the wiring visible, I remember how much I wanted to get the whole thing working.
School also meant science fairs and robotics competitions. I was a RoboCup finalist in 2018 and competed in WRO, among other events. I spent years building robots with teams, and the underwater vehicles became a big part of that time.
Our first underwater vehicle was an ROV, steered by a person at the surface through a tether. We had to make its electronics and mechanisms respond to the operator’s commands.
We later built Blue Marlin with the Immortals team, also under human control. In 2018, I designed my first PCB for it: a two-layer Arduino Mega shield that brought the robot’s electrical connections onto one board inside its enclosure.
The board connected the thruster speed controllers, pneumatic valve controls, lights, and analogue sensor inputs. We also brought out unused Arduino pins for later additions.
Routing both layers was one of the electrical team’s challenges. Our team report describes choosing track widths to limit voltage drop and heating, and making an etched prototype before soldering the components.
I worked on another ROV along the way, too. Watching this pool-test recording still brings back how it felt to see a machine we had worked on moving in the water.
Later, with VorteX, we worked on an autonomous underwater vehicle for RoboSub. The AUV was designed to carry out tasks without a person continuously steering it. My part included programming motion-control algorithms in ROS for underwater manoeuvring and path planning.
Our RoboSub report describes how the team approached perception, state estimation, and control. Detecting a gate was one part of the problem; the vehicle also needed to estimate its motion and turn a desired movement into thruster commands. We explored simulation and control models to study how those parts could work together.
Through an agreement for the team to test in the Suez Canal, we took the AUV beyond the pool. The footage below shows an object-pickup attempt, with the grippers working around a basket. The visibility was limited, and we were trying to position both the vehicle and its mechanisms.
In 2025, a friend and I started Volta. I wanted to see whether AI could help with the work of designing a board. We began with an assistant for datasheet work, then explored natural-language commands for schematics and PCB layouts in KiCad.
Our first prototype used Python to connect to KiCad’s board data through its API and command-line tools. We combined an LLM planner with rule-based checks and manufacturability scripts to propose design actions.
Our original one-pager set out plans for placement, routing, and design checks inside the tools engineers already used. The prototype was still early. We secured investment, but it came with the condition that we drop out of university. We chose to continue our studies and stopped working on the venture. I’ve kept the prototype.
Much of my recent work has been on AI agents and the pipelines around them. Working on Volta got me interested in the hardware running AI. I wanted to understand how much time a chip spends computing versus moving data, and what that means for energy use.
I now have an AMD Kria KV260 Vision AI Starter Kit on my desk. Over the past couple of months, I’ve been spending more time on chips and getting familiar with the board. I have a first inference experiment in mind: a small, quantised matrix operation whose software and hardware implementations I can compare.
The plan is to establish a software baseline, check that a simulated hardware implementation produces the same numerical results, then run it on the FPGA. I want to measure the whole path, including data-transfer time and resource use, as well as the energy needed to finish the workload. A faster operation would be useful; I also want to know what it costs in electricity.
Alongside that, I’m experimenting with low-level kernels for model operations and studying how to compare them fairly with existing implementations. I haven’t established a speedup or energy saving yet.
I’m also studying hardware timing with Traceperf, a C++ learning project developed with substantial AI assistance. It reads simulation traces and reconstructs read transactions on AXI, an interface connecting parts of a system. I’m working through the code and reproducing its experiments to build my own understanding.
One experiment caught my attention: a request could be accepted before its internal read began because a stalled previous response was holding up the launch. A timing model that treated acceptance and launch as the same event would miss that delay. I like having a specific behaviour to investigate, and a model whose assumptions I can check against a trace.
My goal over the next five or ten years is to help design chips for training frontier AI models, with lower energy use and cost. Next, I want to run the matrix-operation experiment on the KV260 and measure how it compares with the software baseline.