01Give a model real tools, and be deliberate about which ones.Most AI projects stall in the same place: the model is fine, and nobody has decided what it is allowed to touch. I build the layer in between — typed tool and resource boundaries, usually over MCP — so an assistant can operate real systems without being handed something loaded. That runs through to putting models inside existing engineering workflows, and to the case where inference has to happen on the vehicle itself, inside a power and latency budget.
Proof and capabilities → Typical engagements
- Wrap an existing system — hardware, database, internal service — in an MCP server an assistant can drive safely
- Design the tool and resource boundary for an agent that touches production or physical systems
- Put a model inside an existing engineering workflow where it earns its place
- Get a model running on a target board within a power and latency budget
- Build an on-device inference pipeline with sensor input and real-time output
- Work out whether an agentic or edge deployment is feasible at all
Airframe to autonomy, including the parts nobody wants to own.Whole-vehicle work rather than one slice of it: structures, propulsion, avionics, telemetry and autonomous behavior, plus the fabrication to actually build the thing. I have taken vehicles from a requirement to a flying, tested prototype across electric, turbine and underwater propulsion.
Proof and capabilities → Typical engagements
- Design and fabricate a purpose-built airframe for a payload or mission
- Select and validate propulsion, including thrust-stand testing
- Integrate and tune a flight stack (ArduPilot, PX4, MAVLink)
- Implement autonomous behaviors: docking, station-keeping, swarm coordination
- Diagnose a vehicle that flies but does not behave
Characterize it, test it, and prove the numbers.Image sensor and detector work: characterization, bench bring-up, and the data infrastructure that turns raw test output into a decision. This is my day-to-day professional practice rather than research work, and it covers the unglamorous middle of a sensor program where most schedule risk actually lives.
Proof and capabilities → Typical engagements
- Characterize a sensor and verify it against its specification
- Bring up a test bench and automate the capture path
- Turn wafer-sort and final-test data into yield and parametric analysis
- Build dashboards over production test databases
- Investigate capture artefacts: fixed-pattern noise, torn frames, hot pixels
Custom logic where a CPU will not do.FPGA design and hardware/software co-design for cases where timing, throughput or determinism rule out a general-purpose processor. Includes partial reconfiguration, where the fabric changes function at runtime rather than being fixed at build time.
Proof and capabilities → Typical engagements
- Board and FPGA bring-up, from first configuration to working data path
- Partial reconfiguration so one device serves several workloads
- High-speed data capture and streaming pipelines
- Register map design, and verification that doc, RTL and software agree
- Timing closure on a design that will not meet constraints
