Robotics Software Engineer · Boston, MA · M.S. Robotics, Northeastern, April 2027

Autonomy that has to survive contact with the real world.

I build simulation rigs that run real autopilot firmware, then take the same code into the water. Perception, estimation and control across humanoid, quadruped, manipulator, ground, aerial and underwater robots.

See the work Resume PDF GitHub LinkedIn

Simulation · ArduCopter SITL in Isaac Sim

Real · Archelon ROV

2nd placeHackachusetts 2026, Robotics track
8 thrustersROV taken from bench to open water
5 simulatorsIsaac Sim, Isaac Lab, MuJoCo, Gazebo, ArduPilot SITL
3 papersIEEE and IET, published
May 2027available, M.S. Robotics, Northeastern

Selected work

Five builds · open any card for the full writeup

2nd place, Robotics track

Hackachusetts 2026 · team of 3 · robots, simulation and autopilot loop mine

A drone above the water and an ROV below it, inspecting a real Boston bridge

Real ArduCopter and ArduSub firmware fly a drone and an ROV through an Isaac Sim rebuild of the Charles River Dam crossing. Every waterline defect the drone flags, the ROV dives to inspect.

ROV nav error, GPS off: ≤ 0.60 m
points, lidar above + sonar below: 4.54 M
flagged defects inspected: 4 / 4

Details, my part and the stack

Team of 3 · I built the robots, the simulation, the autopilot loop and ROS 2

The Charles River Dam crossing rebuilt in Isaac Sim. ArduCopter flies the drone, ArduSub flies the ROV.

Built in one day for challenge R6, safer inspection of critical infrastructure. A Holybro X500 flown by real ArduCopter SITL runs a 37-waypoint mission along the canal walls and under the deck, where the bridge cuts GPS from 12 satellites to 7. Every waterline defect it flags becomes a task for a BlueROV2 Heavy on ArduSub, which dives with GPS off and navigates on a modelled DVL fed into the autopilot's EKF.

Both robots build one model of the structure: 2.96 million lidar points above the water and 1.58 million sonar points below it. The ROV never drifted more than 60 cm over a 200 m dive, and 4 of 4 flagged defects were inspected underwater. The demo is a replay of a recorded 21-topic ROS 2 bag, run live on stage from one Docker launch.

What is modelled and what is real

Real: ArduCopter and ArduSub flight code, MAVLink mission upload, the EKF, ROS 2 Jazzy, RViz2 and QGroundControl. Modelled: the GPS drop under the deck (the bridge lowers the satellite count), the Ouster OS0-128 lidar and 130-degree multibeam sonar as ray casts, murky water as Beer-Lambert attenuation plus silt, and a simulated thermal camera. Thirteen defects were planted as ground truth, nine above the water and four below, including a scour pit with exposed timber piles.

Result: 2nd place
ROV nav error, GPS off: ≤ 0.60 m; over a ~200 m dive, 0.16 m at the end
Combined model: 4.54 M pts; lidar above + sonar below
Defects flagged → inspected: 4 / 4; drone hands off to ROV

ArduCopter + ArduSub SITL · MAVLink · Isaac Sim 6 · ROS 2 Jazzy · RViz2 · QGroundControl · Docker · repo

Archelon ROV on the bench, in the pool from above, and fitted with hull-cleaning brushes

Real hardware · co-op lead

Archenaux Robotics · Jun to Sep 2026 · Boston

Archelon: an eight-thruster inspection ROV, from bench bring-up to open water

I led the co-op engineering team, owned the sensor stack, the vehicle runtime and the detector, and took the vehicle from the bench into lakes in New Hampshire.

of sensors brought up and owned: 6 classes
detector mAP@50, trained on zero real images: 0.969
open-water deployments: 3 to 4

The co-op writeups, footage and field record ↓

Solo · firmware in the loop

Autonomous harbour inspection · concept for a USV startup

A waterjet boat that patrols a harbour, spots what changed, and docks itself

ArduRover SITL drives a 4.2 m twin-waterjet USV on my own Fossen hydrodynamics and JONSWAP sea, lock-stepped over ArduPilot's JSON backend and path-traced in Isaac Sim.

median cross-track error, after tuning: 1.64 → 0.37 m
docking error: 0.17 m
collisions: 0

Details, my part and the stack

Concept for a USV startup · firmware-in-the-loop simulation and film

ArduRover 4.5 SITL drives the boat; Isaac Sim 6 path-traces the logged run.

A 4.2 m twin-waterjet USV runs an approved patrol route, compares its lidar map with yesterday's patrol and raises change alerts. On operator approval it stands off a contact, loiters on its jets, rejoins the route and berths itself on a solar charging float. The autopilot is the real Pixhawk firmware, ArduRover SITL, lock-stepped to my own physics over ArduPilot's JSON backend.

The physics is a Fossen 3-DOF manoeuvring model with jet spool-up lag, a reversing bucket, current and shallow-water drag, on a JONSWAP wind sea plus swell. Heave, pitch and roll come from the hull sampling that wave surface, and the rendered water uses the same wave field. Tuning cut median cross-track error from 1.64 m with a 3 m weave to 0.37 m.

Cross-track error: 1.64 → 0.37 m; median, after tuning
Changes found: 2 / 2; new object, buoy moved 15.1 m
Docking error: 0.17 m; 0 collisions
Recorded run: 55,693 msgs; 559 s ROS 2 bag

ArduRover SITL · pymavlink · Fossen hydrodynamics · JONSWAP waves · ROS 2 Jazzy · Isaac Sim path tracing

3 hackathons · team

Hyperion · Dell x NVIDIA GB10 · Grok Bot · Wajo x Anthropic

A 20-robot warehouse where AI agents find the fault and get a technician on the phone

Twenty Nova Carters in Isaac Sim. Agents detect faults, re-plan the fleet with Hungarian assignment and, through Fo, place real calls to an on-call technician. Code enforces, the model explains.

simulated deliveries, 3 seeds: 27.3 → 42.0
runs replay to identical logs: 3 / 3
real phone calls in live runs: 10

Details, my part and the stack

Dell x NVIDIA GB10 · Hyperion x Grok Bot · Wajo x Anthropic

Twenty Nova Carters in an Isaac Sim warehouse, streaming live fleet telemetry.

Started at the Dell x NVIDIA GB10 hackathon: a teammate and I built the Isaac Sim warehouse of 20 Nova Carters and shipped the stack as six services in one Docker image on the GB10, where a local Qwen model on vLLM triages robot faults into tickets. I then added four agents (surveillance, war room, technician scheduler, Hungarian re-allocation) under one rule: code enforces, the model explains. Over 3 seeds they raised deliveries from 27.3 to 42.0, and every run replays to an identical event log.

For Wajo x Anthropic, a Claude dispatcher hands a confirmed fault to Fo, which places real phone calls, calendar invites and emails to an on-call technician while the fleet re-plans around the repair. Who it may contact is enforced in code: in a live run, when a technician said to send someone off the list, the agent refused. I also mounted a Franka arm on all twenty Carters as a mobile-manipulation testbed.

Simulated deliveries: 27.3 → 42.0; +54%, 3 seeds, same faults
Replay check: 3 / 3; identical event logs
Live dispatch runs: 5 runs, 10 calls; real phone calls, simulated robots
Fleet: 20 robots

Isaac Sim 6 · Nova Carter · Franka · vLLM · Claude · Docker · NVIDIA GB10 · Hungarian assignment

Solo · YC pitch

Intake-cleaning robot · startup study and pitch film

An underwater robot that clears mussels from power-plant intakes, rendered physically

Path-traced in Isaac Sim with MDL materials and procedural mussel instancers; the water is my own compositor working from depth.

render time per frame, BVH fix: 24 → 5.7 s
regulated US intake sites sized: 1,065
diver deaths OSHA counted: 6 in 13 mo

Details, my part and the stack

Startup study and pitch film · Isaac Sim path tracing + a custom water renderer

Path-traced in Isaac Sim; the water itself is a ray-marched medium composited from depth.

Divers clean zebra and quagga mussels out of power-plant and desalination intakes, and OSHA counted six suction-related diver deaths in 13 months. I built the case for sending a robot instead, then the film to pitch it. The robot and intake are rendered with Isaac Sim path tracing, MDL materials and procedural mussel-clump instancers, writing raw HDR and depth for every frame.

The water is my own compositor working from that depth: absorption, backscatter, ray-marched god rays and lamp beams, caustics, Snell's window and drifting particles. Profiling the render found that hiding instances far below the scene bloated the BVH and made every frame 24 s; sinking them into the wall instead brought it to 5.7 s.

Render time per frame: 24 → 5.7 s; BVH fix, GPU-bound
Market sized: 1,065 sites; regulated US intakes
Water model: custom, post

Isaac Sim path tracing · USD · MDL · NumPy compositor · Python

Real hardware: the Archelon co-op

June to Sep 2026 · Boston, MA · my own footage

A four-month Northeastern co-op on Archelon, a bespoke eight-thruster inspection ROV. I led the co-op engineering team reporting to the CEO and worked across five repositories. The four writeups below are that work, and each states plainly which parts were mine and which were the team's.

My ownership: Vehicle runtime · sensor bring-up · detection pipeline · shared simulation core
My contribution: Sensor simulation and IMU characterisation feeding the mapping attempt
Led by others: Factor-graph SLAM back end (senior engineer)
Field record: 10 to 15 pool sessions · 3 to 4 open-water deployments, New Hampshire

This is the vehicle I worked on during my co-op, in the water, with the sensor stack I owned. Everything below is footage I took on site. The simulation work further down is how I got here safely, not a substitute for it.

Pool · sensor stackThe stack I was responsible for

Pool · FPV pilotingFlying it from the camera feed

Open water · New HampshireOff the boat, into a real lake

Pool · team testingWet testing with the team

What each clip shows

The stack I was responsible for

Ping360 scanning sonar, three cameras, a VectorNav VN-100, Bar30 depth and the lighting rig. This is the hardware behind the driver bug where the sonar reported a wall at 0.3 m while the real wall sat at 4 to 5 m.

T200 thrusters · Ping360 · VN-100 · Bar30

Flying it from the camera feed

Head-mounted display and a hand controller, driving the vehicle on the video feed rather than by line of sight. The operator interface on the other end of this is the PyQt UI I built.

MAVLink · joystick piloting · PyQt UI

Off the boat, into a real lake

Surface station on the console, tether over the side, no pool wall to stop the vehicle. Three to four of these deployments, which is where tether handling and recovery stop being theoretical.

Surface station · tether ops · recovery

Wet testing with the team

Ten to fifteen pool sessions. This is where a dead depth sensor turned out to be a missing bit in an I2C probe mask, and where the joystick moved every topic and not one thruster.

10 to 15 sessions · 7.1 GB analysed

Lake · live detection

The detector running on the vehicle

Three cameras at once in murky lake water. The model was trained entirely on a seeded procedural world that emits its own labels by 3D-to-2D projection, so it never saw a real frame in training, and reached 0.969 mAP@50.

YOLO11 · synthetic-only training · 3 cameras

Lake · rejecting clutter

Saying no is the hard part

Weeds and silt marked not_mine instead of firing. Getting clutter false positives from 54% to 0% across three model generations took more work than raising precision on the targets themselves.

54% → 0% clutter false positives

10 to 15Pool testing
Wet sessions with the vehicle in the water. This is where the depth sensor turned out to be an I2C bitmask, where the joystick moved every topic and no thruster, and where the companion computer browned out on rail sag rather than heat. None of those are findable in a simulator.
3 to 4Open-water deployments
Lake deployments in New Hampshire, taking Archelon from bench bring-up to operation in real water. Tether handling, surface station, and a vehicle that has to come back.
7.1 GBPool-test data analysed
Logs from those sessions, which is where the Ping360 sonar driver was caught returning a fake wall at 0.3 m on every beam while the real wall sat at 4 to 5 m. The bags looked valid, so nothing downstream flagged it.
3 buildsFirmware flash-verified
Flashed and verified on the vehicle before it went in, with a 14-second preflight GO / NO-GO check gating every dive and a boot service that survives power-on.
321k samplesIMU characterised on
A 30-minute stationary log, Allan variance and Kalibr noise parameters, gyro ARW 0.26 deg/sqrt-hr. Re-recorded after the first attempt turned out to be contaminated by a nearby speaker coupling into the MEMS accelerometer.
8 + 3Hardware brought up
Eight T200 thrusters plus three M200 auxiliaries, Pixhawk autopilot, Ping360 sonar, Bar30 depth, VectorNav IMU and a Raspberry Pi 5 companion, on a 50 ft tether.

Every result on this page that is labelled measured was taken off real hardware or a real dataset. Simulation is how I get there safely; it is not what I do instead. The footage in this section is mine, taken during these sessions.

Archelon ROV on the bench showing four thruster nozzles and dome lights — Bench, between dives

Front view of the vehicle with hull-cleaning brushes and lights — Hull-cleaning brushes fitted

Three-quarter view of the vehicle with tether attached — Tether and tracks

The engineering, in four writeups

Co-op 01 / Sensors, perception hardware and the operator UI Every sensor on the vehicle, and the interface the pilot flies it with my ownership

Primary engineer, sensor stack and operator interface

Eight-thruster inspection vehicle in simulation — Eight-thruster inspection vehicle, vectored six-degree-of-freedom configuration.

This was my primary work: bringing up and owning every sensor the vehicle carries, and the interface the operator actually uses. Ping360 scanning sonar, three cameras, the VectorNav VN-100 IMU, depth, and the lighting.

A sensor that returns plausible-looking garbage is worse than one that fails, because nothing downstream flags it. The Ping360 drew a fake circular wall at 0.3 m on every beam while the real wall sat at 4 to 5 m. The bags looked valid, correct message counts, correct rates, non-zero ranges, so it cost two pool sessions before I traced it to first-echo detection in both the Python and C++ drivers and fixed it with a regression test.

The sensor stack in detail

Sonar. Ping360 mounted vertically, which means roughly 40% of beams hit the vehicle frame itself and return a tight 0.30 m. That is only separable when the vehicle is still, so the sector mask is part of the driver rather than a post-process. Raising the serial link to 2 Mbaud took a full 360-degree sweep from 23.3 s to 5.9 s.

IMU. I characterised the VN-100 and the autopilot IMU the estimate depends on: a 30-minute stationary log, 321k samples, Allan variance and Kalibr noise parameters. Gyro ARW came out at 0.26 deg/sqrt-hr. The first attempt was contaminated by a nearby speaker coupling into the MEMS accelerometer, visible only as tonal peaks in the FFT.

Cameras and lights. Three cameras streaming to the topside station, plus the lighting rig. Underwater the D455 stereo depth returned only 8 to 40% valid pixels, and flat-port refraction invalidates the factory calibration outright, so I derived an empirical correction that flattened a known-flat pool floor from 15 mm to 6 mm median plane residual.

Depth. The Bar30 read nothing however it was wired, because BARO_PROBE_EXT was a bitmask missing the bit for the MS5837, so the autopilot never probed the I2C bus for it.

Sensors owned: 6 classes
Sonar sweep time: 23.3 s → 5.9 s; serial raised to 2 Mbaud
Gyro ARW: 0.26 °/√hr; measured, 321k samples
Depth-camera correction: 15 mm → 6 mm; plane residual, known-flat floor

Ping360 sonar · VectorNav VN-100 · RealSense D455 · Bar30 · I2C · ROS 2 Jazzy · PyQt5 · Docker

Co-op 02 / Perception & machine learning Training a detector with no real data to train on sole engineer

Archenaux Robotics · sole engineer, simulation and ML pipeline · 26 commits

Deployed detector on a recorded survey run. Live confidence overlay.

Imagery of the target objects is classified or does not exist. So I generated it. A seeded procedural world generator emits ground-truth labels by 3D-to-2D projection, which means every frame is labelled for free and any scene is reproducible from its seed.

The difficulty is deliberate: seven object types, three turbidity levels, current drift, marine snow, kelp and seabed distractors that a naive detector calls targets. The blocking problem was never recall, it was that the model flagged every barrel.

Why I publish the bad number too

The evaluation also showed 0% recall on three object types, because the real-photo training set contained no flat or torpedo-shaped examples. I would rather publish that than a clean chart. An unevaluated detector is worse than none, because someone trusts it.

Clutter false positives: 54% → 0%
False alarms, empty frames: 0 / 9
Recall, moored & drifting: 100%
mAP@50: 0.471; sim; 0.61 real-photo

Grid of generated training scenes — Generated scenes

Precision recall curve — Precision / recall

Python · PyTorch · Ultralytics YOLO11 / YOLO26 · OpenCV · Gazebo · Docker

Co-op 03 / Embedded & hardware bring-up Three failures that looked like software and were not my ownership

Archenaux Robotics · primary engineer, vehicle runtime and sensor bring-up · 52 commits

Inspection vehicle beneath a ship hull in Gazebo Harmonic — Eight-thruster inspection vehicle, vectored six-degree-of-freedom configuration.

Archelon runs ArduSub in a vectored six-degree-of-freedom configuration. I own the runtime that ships to it and I did the sensor bring-up, which is mostly a story about failures that look like software and are not.

The depth sensor read nothing no matter how it was wired, because BARO_PROBE_EXT was a bitmask missing the bit for the MS5837, so the autopilot never probed the I2C bus for it. The joystick moved every topic on the dashboard and no thrusters, because ArduPilot silently discards RC override from any system ID other than the one it is told to trust. The companion computer browned out under load, which turned out to be rail sag down the tether rather than thermal throttling.

On numbers nobody can trace

None of those are findable in simulation. I wrote the power-budget analysis that justified swapping the companion computer, and it says plainly which of its figures are measured and which are estimated, because a number nobody can trace is worse than no number.

The runtime itself is a containerized stack shipping to the real vehicle: MAVLink router, MAVROS, cameras, joystick piloting, RViz and QGC as one multi-arch image, with a 14-second preflight GO / NO-GO check gating every dive and a boot service that survives power-on.

Thrusters: 8 + 3 aux
Firmware flash-verified: 3 builds
Pool-test data analyzed: 7.1 GB
Open-water deployments: 3 to 4

Pixhawk 1 · ArduSub 4.5.7 · MAVLink · pymavlink · MAVROS · Ping360 sonar · VectorNav VN-100 · Bar30 · T200 / M200 thrusters · I2C · Raspberry Pi 5 · Docker

Co-op 04 / Simulation infrastructure A simulator other engineers can actually run my ownership

Archenaux Robotics · owner, shared simulation core · 97 commits across two repositories

Autopilot software-in-the-loop wired to Gazebo Harmonic over a JSON physics backend.

A simulator only one engineer can start is not an asset. I own the core the other projects build on, and most of its value is that it runs on someone else's laptop on the first try.

Three containers on one network: autopilot software-in-the-loop, physics, and a ground control station with joystick passthrough, plus a dev container. GPU is optional with auto-detected vendor overrides, and a browser-based fallback means the interface works on headless, Wayland and WSL hosts. That last one resolved a display crash blocking a teammate.

Commits, two repos: 97
Machines validated: 3
Compose overlays: 10
Clone to running: 1 command

Docker Compose · ROS 2 Jazzy · Gazebo Harmonic · ArduSub · MAVROS · Bash · noVNC

Simulation range

Twelve robots, captured from simulations I built

Humanoid · MuJoCo

A 67 kg humanoid that walks because a controller says so

What it shows

Unitree H1-2, 51 actuated joints, built from torque control upward in MuJoCo. The measurement that starts everything: hold every joint at its commanded angle, let go, and the pelvis drops from 1.030 m to 0.415 m in six seconds. Angles are not momentum.

MuJoCo · LIPM · whole-body QP · Pinocchio · 90 modules

Humanoid · Isaac Lab

Which reward term is actually doing the work

What it shows

Unitree G1 humanoids training in parallel in Isaac Lab. Ablating one reward term at a time over 29 runs: removing the −200 termination penalty collapses learning to 4.2% of baseline episode length while the reward climbs, because falling becomes free.

Isaac Lab · PPO · ONNX · reward ablation · 6 GB GPU

Quadruped · locomotion

A policy that actually walks

What it shows

A Unitree Go2 under a trained policy, blind versus perceptive on the same terrain. Tracking improves from 64.6% to 69.9% once the policy can feel the ground. Gait is verified on contact timing and foot clearance, never on the reward curve.

Isaac Lab · PPO · MuJoCo · Python

Quadruped · navigation

Velocity commands from a planned path

What it shows

The layer between a navigation stack and a learned gait: a path becomes body-frame velocity commands the policy can track, with footstep planning over an elevation map built from a depth camera.

Isaac Lab · elevation mapping · footstep planning

Manipulator · SO-101

Pick and place, with an evaluation harness that argues back

What it shows

MuJoCo pick-and-place on the SO-101 arm, tested against its own failure modes: a contact gate that rejects a faked grasp, and a harness that fails when the evaluation is wrong rather than when the robot is.

MuJoCo · SO-101 · evaluation harness · Python

Manipulator · parallel RL

Many arms, one physics step

What it shows

Franka reach environments running vectorized on the GPU. Same principle as the humanoid and quadruped training: every robot advances inside a single solver call, which is what makes RL tractable on laptop-class hardware.

Isaac Lab · vectorized envs · CUDA · PyTorch

Manipulator · VLA

Language-conditioned pick and place

What it shows

A 7-DoF arm driven by a vision-language-action policy: an instruction in, a joint trajectory out. Built so every layer between the camera and the actuator is inspectable rather than a black box.

Isaac Sim · VLA policy · ROS 2 · PyTorch

Surgical · RCM

Precision manipulation under constraint

What it shows

Laparoscopic arm simulation: remote-centre-of-motion constraint solving, damped least-squares IK near singularities, and the millimetre tolerances that make a general-purpose manipulator stack inadequate.

Isaac Sim · RCM · DLS IK · ROS 2

AMR · ground robot

Scan matching, built rather than imported

What it shows

A ground robot mapping a warehouse with 2D LiDAR: ICP front end, mapper, loop closure and pose graph written from scratch. Point-to-line registration lands at 2.3 mm against 8.1 mm for point-to-point on the same run.

ROS 2 · ICP · pose graph · occupancy mapping

LiDAR SLAM

Measuring where SLAM fails, not just where it works

What it shows

A wall is degenerate at 3747 against 1.9 on open floor, so the same scan matcher that is excellent in a corridor is near-useless facing a flat surface. Every figure is reproducible from the repository, including the inconvenient ones.

ROS 2 · scan matching · loop closure · Python

Underwater · detection

Detection with no real training data

What it shows

A seeded procedural world emits its own ground truth by 3D-to-2D projection, so every frame is labelled for free and any scene is reproducible from its seed. Clutter false positives went from 54% to zero across three model generations.

YOLO11 · PyTorch · Gazebo · OpenCV

Marine · Isaac Sim

A second physics backend that argues with the first

What it shows

The vehicle ported to Isaac Sim as a second physics engine: animated water with underwater rendering, hydrodynamics covering buoyancy, damping and added mass, and a bridge closing the control loop against Isaac physics.

Isaac Sim · RTX offscreen · ROS 2 · pytest

Experience, awards & papers

Open to 2027 new-grad roles, from May 2027

Jun 2026, Sep 2026

Robotics Engineer, Co-op, technical lead

Archenaux Robotics · Boston, MA

Led the co-op engineering team reporting to the CEO across five repositories. I owned the containerized vehicle runtime, the learned detection pipeline, the shared simulation core, and the sensor bring-up that took Archelon from bench to open water. On the mapping stack I contributed the sensor simulation and IMU characterisation; a senior engineer led the factor-graph back end.

Oct 2022, Aug 2024

Vice-President, Robotics Team

Vellore Institute of Technology · India

Co-led a team of 80 designing and manufacturing FPV drones, autonomous drones, battle bots and AMRs. Mentored students in ROS 2, Gazebo and OpenCV.

Jan 2024, Jun 2024

Robotics Intern

Mafkin Robotics · Chennai, India

Autonomous ship-hull cleaning robot for biofouling, which increases drag by up to 40%. Implemented real-time 3D SLAM in Gazebo using RTAB-Map.

Sep 2023, Dec 2023

Research Intern

Universiti Teknologi Petronas · Perak, Malaysia

Autonomous drone and AMR technologies for surveillance and navigation. SLAM and navigation in Gazebo with RealSense D455i, RPLIDAR, wheel encoders and IMUs, integrated through ROS 2.

Sep 2025, Apr 2027

M.S. Robotics

Northeastern University · Boston, MA

Mobile Robotics · Robot Sensing and Navigation · Control Systems

Sep 2021, Apr 2025

B.Tech Mechatronics, Robotics and Automation

Vellore Institute of Technology · Chennai, India

Industrial Robotics · Control Systems · Kinematics and Dynamics · Mechatronics System Design

Open source & other projects

Grouped by what they prove

Legged robots & RL

humanoid-balance-locomotion

Balance and locomotion for a 67 kg, 51-DOF Unitree H1-2 in MuJoCo, built from torque control up: CoM/CoP estimation, ankle and momentum strategies, LIPM walking with a whole-body QP, an RL comparison, and a ROS 2/Gazebo port. 90 modules, every constant measured.

MuJoCo · whole-body QP · Pinocchio · ROS 2

isaac-lab-rl-benchmarks

Reward-term ablation on a Unitree G1 across 29 training runs on a 6 GB laptop GPU, plus sim-to-sim ONNX parity and policy deployment with no simulator. Every figure regenerable from 54 measured fact groups.

Isaac Lab · PPO · ONNX · 29 runs

barkour-isaac-lab-rl

Bringing a quadruped Isaac Lab does not ship: Barkour vB through URDF conversion, a manager-based RL environment, PPO training, evaluation and a simulator-free deployment path.

Isaac Lab · URDF · PPO · Barkour vB

Manipulation

so101-manipulation-eval

MuJoCo pick-and-place on the SO-101 arm with an evaluation harness tested against its own failure modes, including a contact gate that rejects a faked grasp.

MuJoCo · SO-101 · evaluation harness

surgical-robotics-isaac-sim

Laparoscopic arm simulation in Isaac Sim: remote-centre-of-motion constraint solving, damped least-squares IK near singularities, teleoperation and deformable tissue contact.

Isaac Sim · RCM · DLS IK · ROS 2

vla-manipulation-ablations

Vision-language-action manipulation ablations with held-out generalisation tests and an OpenVLA-7B feasibility study, all measured on a 6 GB laptop GPU.

VLA · OpenVLA · PyTorch · ablations

Autonomy & SLAM

visual-slam-vio-ros2

Stereo-inertial SLAM built from the geometry up: camera and stereo models, camera-IMU extrinsics and time offset, feature-based VO, IMU preintegration, sliding-window optimisation, and a ROS 2 layer around ORB-SLAM3 on EuRoC and TUM-VI.

C++ · GTSAM · ORB-SLAM3 · EuRoC

av-perception-planning-stack

Twelve-module driving stack in pure Python: camera and lidar perception, fusion, localisation, tracking, prediction, behaviour selection, planning, control and a fail-closed safety layer. 227 tests across 71 files.

Python · 12 modules · 227 tests

av-safe-decision-contract

Coordinate-frame transforms and a fail-safe perception-to-planning decision contract for an AV stack: rigid map/base_link transforms with a contract that degrades safely rather than guessing.

Python · TF2 · safety contract

Simulation tooling & drones

gazebo-to-isaac-migration

A ROS 2 diff-drive rover ported from Gazebo Harmonic to Isaac Sim 6.0.1, with a harness that quantifies cross-simulator variance and five deliberately planted defects: joint limits, permuted inertia axes and silent controller retuning.

Isaac Sim · Gazebo · benchmarking

autonomous-drones-ros2-gazebo-ardupilot

ArduPilot SITL and Gazebo in Docker with MAVROS bringup and seven finished autonomous missions, from takeoff through a perimeter survey. Runs on a laptop with no hardware.

ArduPilot SITL · MAVROS · Gazebo · Docker

Robotics course series

Written and produced end to end. Narrated courses covering humanoid balance, quadruped RL in Isaac Lab, LiDAR SLAM, visual SLAM/VIO, manipulation, surgical robotics, autonomous driving and drones. Most clips at the top of this page are captured from that work.

Isaac Lab · MuJoCo · ROS 2 · Gazebo

Hackathon & capstone

emme-onboarding, hackathon winner

Won Track 2 at The Open Accelerator healthcare hackathon, hosted by Red Hat with IBM Ventures and the Mass AI Hub. Health insurance documents turned readable, with confidence-tiered confirmation. Built in a day, deployed live.

Flask · Postgres · Gemini · Vercel

Automated seed-spacing robot

Undergraduate capstone: an autonomous mobile robot for precision agriculture using ROS 2, SLAM Toolbox and Nav2, with a CoreXY manipulator for seed placement.

ROS 2 · Nav2 · SLAM Toolbox · CoreXY

About

I am an M.S. Robotics student at Northeastern, graduating April 2027, coming off a co-op where I led the engineering team on an eight-thruster inspection vehicle.

My work sits where perception hardware meets software. On the vehicle I owned the sensor stack, sonar, cameras, IMU, depth and lighting, plus the operator interface and the containerized runtime that ships to it. I also trained a detector on a world I generated, because imagery of the real targets does not exist.

Simulation is how I get there safely, not what I do instead. Every number on this page that says measured was taken off real hardware or a real dataset, and the bring-up behind it meant I2C bitmasks, refraction calibration and a power rail that could not hold under load. I publish the attempts that did not work alongside the ones that did, because an unevaluated result is worse than none.

Outside the co-op I write and produce robotics courses, which is where the quadruped, manipulator and parallel-training clips above come from. Teaching a thing end to end is the fastest way I have found to learn where my own understanding is thin.

Languages

PythonC++ Embedded CBash CMake

Robotics

ROS 2Nav2 MoveIt 2GTSAM iSAM2 RTAB-MapSLAM Toolbox MAVLink / MAVROSArduPilot / PX4

Perception & learning

OpenCVYOLO11 PyTorchTensorFlow Open3DSensor fusion

Simulation

Gazebo HarmonicIsaac Sim Isaac LabMuJoCo SolidWorks

Hardware & tooling

PixhawkJetson Orin Nano Raspberry Pi 5ESP32-S3 Ping360 sonarRealSense D455 DockerLinux

Contact

Open to 2027 new-grad roles

Email franklinrichardjep.f@northeastern.edu GitHub github.com/FERBIN12 LinkedIn linkedin.com/in/ferbin12 Phone +1 (857) 260-4748 ResumeDownload the PDF

Also: simulation focus · field & deployment focus · general