I publish at the intersection of machine learning, computer vision, and applied science.

Undergraduate Thesis — Orthographic Gaussian Splatting from CT Radiographs

3D reconstruction from clinical CT sequences using a Gaussian Splatting approach adapted for orthographic projection geometry. Bridges volumetric rendering and medical imaging — a problem with meaningful real-world constraints and no clean off-the-shelf solution.

Led software development for a competitive Mars rover that placed top 15 globally at the International Rover Design Challenge. Built and integrated the autonomy, telemetry, and computer vision subsystems. Responsible for architectural decisions under real hardware constraints — power budgets, latency limits, field reliability.

ROS · C++ · Python · embedded Linux · computer vision · state machines

The kind of project where the codebase has to work in a desert. Not a demo.

Computer Vision       ████████████░   3D reconstruction · neural rendering · medical imaging
Machine Learning      ███████████░░   Classification · NLP · safety-constrained RL
Embedded / IoT        ████████████░   Real-time systems · ROS · hardware-software co-design  
Spatial / XR          █████████░░░░   Unity · Meta Quest 3 · immersive interfaces
Product Engineering   ███████████░░   Platform-scale PM · 0→1 builds · technical strategy
Orbital Mechanics     ████████░░░░░   Astrodynamics · GNC-adjacent · Kerbal-serious

Languages — Python C++ C C# JavaScript

ML / Vision — PyTorch HuggingFace OpenCV 3D Gaussian Splatting scikit-learn

Systems — ROS/ROS2 FreeRTOS embedded Linux CUDA ARM Cortex

Spatial — Unity Meta XR SDK WebGL

Infra — Docker Linux Git

Exploring safety-constrained reinforcement learning for spacecraft proximity operations — Clohessy-Wiltshire dynamics, Control Barrier Functions, Soft Actor-Critic. A problem that demands both mathematical rigor and engineering discipline to get anywhere meaningful.

Also: mechanistic interpretability of transformer internals. Less because it's trendy, more because understanding why a model does what it does is a precondition for trusting it.

Research and engineering are the same activity at different timescales. A paper without implementation is speculation. An implementation without theoretical grounding is fragile. I don't find the distinction useful.

I'm drawn to problems where the failure modes are non-obvious, the feedback is slow, and getting it right actually matters.