I build robots that check their own work. My dissertation
platform swaps its own tools and recovers when an exchange fails, with no operator
in the loop. Everything on this sheet is measured, logged, or in a repository —
nothing is an artist's impression.
Table 1 — measured performance
102consecutive autonomous tool swaps, zero mechanical failures, in the primary 67-minute trial
100%mechanical success across all 147 post-development swap attempts
39.3 smean swap time, command to confirmed tool-mounted
1.36CoreMark/MHz — RV32I CPU I wrote in SystemVerilog, measured on Artix-7 silicon
1.0
Projects
1.1MEES — Modular End Effector System
ROS 2
C++
OpenCV
RTOS
custom PCB
Kinova Gen3
Commercial automatic tool changers are expensive, heavy, and rely on pneumatics
that lightweight collaborative arms don't have. MEES is my answer for the Kinova
Gen3: a low-cost, magnetically actuated, ISO 9409-compliant tool changer plus
the software to use it with nobody watching. The use-case I designed and evaluated it
against is surgical: instruments that need exchanging mid-procedure, reliably, without
anyone stepping in. The engineering itself is general tool-switching.
A vision-guided ROS 2 orchestrator reads each tool's Data Matrix barcode from
the arm's own camera to know what it's holding. Under it sits UserBridge,
a C++ layer I wrote over the Kinova Kortex SDK that exposes the arm's expansion
port — UART, I²C, GPIO, Ethernet — to the actuator microcontrollers below. An RTOS
runs the tool carousel, and a custom PCB carries power and data through the
coupling face.
The primary reliability trial ran 102 consecutive autonomous swaps over 67 minutes
without a single mechanical failure, averaging 39.3 seconds from command to
confirmed tool-mounted. Counting every post-development attempt, the tally is 147 out
of 147. When an exchange does go wrong the system notices and recovers on its own —
I tested that by forcing exchanges to fail, not by hoping they wouldn't. A new tool
joins the carousel with one scan command and zero code changes.
Straight from the primary trial's session log, 8 May 2026 — real timestamps,
logged by the Python test driver I wrote for the rig.
Time between consecutive tool-mount confirmations
101 intervals from the 102-swap trial · mean 36.2 s · σ 0.18 s
Each dot is one real swap from the session log.
All 101 intervals sit inside a 0.7-second band — the y-axis spans 35–37 s to make
that visible. The slow ~0.6 s lengthening across the session is real too, and
exactly the kind of thing you only notice when you log everything. Hover, or focus the
chart and use the arrow keys, to read individual swaps; the table below has every
value. (The 39.3 s figure quoted elsewhere is command-to-mounted per swap; this
cadence includes the return leg between commands.)
view as table
Switch
Tool mounted
Interval (s)
The stack, top to bottom
Click a layer to see what it does.
The wrist-side coupling half on the Gen3 — the arm's own camera, just above, does the tool identification.The custom PCB that routes power and data from the Kinova expansion port through the coupling face.UserBridge's CLI during interface bring-up — UART, GPIO, I²C and Ethernet paths tested end-to-end through the coupling.
Platform behind my first-author ICRA paper, pending submission
September 2026. Repository private while the paper is in preparation.
FIC_Interface is the multi-robot platform for Fractal Impedance Control at Sussex's
Transformative Robotics Lab (TRL): real-time compliant control and teleoperation
across Franka and Kinova arms with a MuJoCo simulation backend. The platform and the
controller are the lab's work; my part is the contributor's share — extensions, device
integration, and the reliability fixes a live platform keeps demanding.
I built the tool-switcher extension (Data Matrix vision, a tool-pose database,
FIC-driven motion) and the VR playground extension and bridge used to teleoperate
the arms from a headset — the thread that feeds a co-authored paper in preparation
on ultra-low-latency teleoperation. I also enabled the Kinova gripper and wrote its
control loop.
The commits I'm proudest of are the boring ones: a buffer overflow, a serial-port
blocking bug, a Qt logging crash, and moving the barcode scanner onto its own thread.
Research platforms live or die on that kind of work.
My commits, by week and kind
24 authored commits, May–June 2026 (merges and stashes excluded) — from the repo's git history
Each dot is a day's commits in one lane; bigger
dot, more commits. Hover, or focus and use arrow keys, to read what each cluster
was. The early burst is the tool-switcher extension landing alongside the
reliability fixes it exposed; the June work is the VR bridge and control-tuning
support. The repo is the lab's and stays private — this timeline is just my slice
of its history.
The platform's simulation model of the Gen3 with its Robotiq gripper —
the same MuJoCo model my tool-switcher extension drives. Rendered from the sim's
own assets (meshes: Kinova & Robotiq, via MuJoCo Menagerie).
Lab repository — private.
1.3ART_FIC — live autotuning for the FIC controller
Python
MuJoCo
control
autotuning
Impedance controllers are only as good as their gains, and gains get tuned by
hand, at the end of long afternoons, by whoever's patience runs out last. ART_FIC
wraps the lab's ART regime-memory autotuner — a companion library, pulled in as a
submodule, not my work — around the FIC controller so it can tune itself: against a
MuJoCo pendulum, a physical servo rig, and the 7-DOF Gen3 model. I wrote the FIC
wrapper, the experiment suite, and the config round-trip, so whatever the tuner
settles on lands in the same config.xml the lab's C++ stack loads on
the real arms.
Held at six angles off rest, the tuner works out how hard
gravity is pulling on the payload at each one, then picks a stiffness to match —
more lean, more torque, more K. Real numbers from one sweep in the project's
logs; hover or tab to a dot to read a point.
view as table
Angle off rest (rad)
Residual (N·m)
K tuned (N·m/rad)
1.4RISC-V RV32I CPU core
SystemVerilog
Artix-7
riscv-tests
A full RV32I processor written from scratch in SystemVerilog, validated against
the official riscv-tests suite with self-checking testbenches, then put on real
hardware: it runs CoreMark on a Xilinx Artix-7 at 1.36 CoreMark/MHz, and I
CRC-check the benchmark output rather than eyeball it. A five-stage pipeline with
hazard detection and forwarding is in progress. Building a CPU is why I trust myself
near the bottom of a robot's stack.
rv32ui suite, fresh run
riscv-tests on this core under Icarus Verilog · 3 Aug 2026 · 40 of 41 pass
✕ ma_data fails, and I've left it showing: the
core doesn't implement misaligned-access traps yet, and I'd rather you see the
failing test than wonder what I dropped from the suite. – fence_i is
skipped — it needs self-modifying code, which a Harvard instruction memory can't
do.
1.5Real-time embedded firmware
C
C++
bare-metal
Register-level C and C++ under hard timing: ADC drivers, stepper control, sensor
sampling, and a bare-metal data-acquisition module built from scratch. The MEES
carousel runs on my
public fork of the Prusa i3
firmware — the carousel logic, serial protocol, and application entry point are
mine; the retained hardware-abstraction modules are Prusa Research's.
The carousel's wire protocol
line-oriented ASCII over UART · 115200 8N1 · synchronous — OK only lands after the motion physically completes
host → N1 TOOL A
device → OK N1
host → N2 HOME
device → ERROR PINDA home failed N2
Click a command to see what it does. Any command can carry an
N<seq> prefix, echoed back in the reply — so a lost reply can be retried
without wondering whether the original command already ran.
1.6Redundant UAS navigation — design study
autonomy
state estimation
concept only
Control-engineering lead for a university team's design study: sensor- and
control-redundant navigation that holds a usable position and state estimate under
GPS denial and degrades gracefully as sensors drop out. Concept and early design
only — the airframe was never built, and I'd rather tell you that here than have
you find out in an interview.
2.0
Research
Autonomous tool switching for lightweight robotic arms — first author.
ICRA — pending submission, September 2026
Ultra-low-latency communication for teleoperation and high-speed robotic control — co-author.
in preparation
3.0
Skills
Robotics
ROS 2 (rclcpp / rclpy) · OpenCV · control · state estimation · Kinova Kortex SDK · MuJoCo
I've been programming for seven years, mostly software; the last few have pulled me
toward hardware, and robotics is where the two meet. I care more about whether
something holds up once it's actually running than whether it demos cleanly — most of
my favourite commits are fixes nobody will ever notice.
I speak English (C1 certified — my whole degree was taught in it) and Arabic
(native). Based in Brighton, UK, and happy to relocate for the right team.
