01Models that actually run on the hardware you are shipping.Most machine learning works fine on a workstation and falls apart on a battery-powered board. I take models the rest of the way: choosing an architecture that fits the silicon, quantising it until it meets the latency and power budget, and building the inference pipeline around it so it survives contact with real hardware.
Proof and capabilities → Typical engagements
- Get an existing model running on a target board within a power and latency budget
- Architecture and quantisation review before you commit to hardware
- Build an on-device inference pipeline with sensor input and real-time output
- Stand up orchestration and OTA updates across a fleet of edge devices
- Second opinion on whether an 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 behaviour, 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 behaviours: docking, station-keeping, swarm coordination
- Diagnose a vehicle that flies but does not behave
Characterise it, test it, and prove the numbers.Image sensor and detector work: characterisation, 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 programme where most schedule risk actually lives.
Proof and capabilities → Typical engagements
- Characterise 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
