Robotics Field & Deployment Engineer · Boston, MA · M.S. Robotics, Northeastern, April 2027
I take robots from bench bring-up to open water and debug them where they fail: sensors, firmware, tethers, networks and the operator's console. Then I build the simulation that stops it happening twice.
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.
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.
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
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
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
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
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
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
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.
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.
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.
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.
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.
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.
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.
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.
Ping360 sonar · VectorNav VN-100 · RealSense D455 · Bar30 · I2C · ROS 2 Jazzy · PyQt5 · Docker
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.
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.
Python · PyTorch · Ultralytics YOLO11 / YOLO26 · OpenCV · Gazebo · Docker
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.
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.
Pixhawk 1 · ArduSub 4.5.7 · MAVLink · pymavlink · MAVROS · Ping360 sonar · VectorNav VN-100 · Bar30 · T200 / M200 thrusters · I2C · Raspberry Pi 5 · Docker
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.
Docker Compose · ROS 2 Jazzy · Gazebo Harmonic · ArduSub · MAVROS · Bash · noVNC
Real hardware · co-op lead
Archenaux Robotics · Jun to Sep 2026 · Boston
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.
Hackachusetts 2026 · team of 3 · robots, simulation and autopilot loop mine
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.
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.
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.
ArduCopter + ArduSub SITL · MAVLink · Isaac Sim 6 · ROS 2 Jazzy · RViz2 · QGroundControl · Docker · repo
Autonomous harbour inspection · concept for a USV startup
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.
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.
ArduRover SITL · pymavlink · Fossen hydrodynamics · JONSWAP waves · ROS 2 Jazzy · Isaac Sim path tracing
Hyperion · Dell x NVIDIA GB10 · Grok Bot · Wajo x Anthropic
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.
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.
Isaac Sim 6 · Nova Carter · Franka · vLLM · Claude · Docker · NVIDIA GB10 · Hungarian assignment
Intake-cleaning robot · startup study and pitch film
Path-traced in Isaac Sim with MDL materials and procedural mussel instancers; the water is my own compositor working from depth.
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.
Isaac Sim path tracing · USD · MDL · NumPy compositor · Python
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
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
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
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
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
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
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
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
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
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
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
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
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.
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.
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.
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.
Northeastern University · Boston, MA
Mobile Robotics · Robot Sensing and Navigation · Control Systems
Vellore Institute of Technology · Chennai, India
Industrial Robotics · Control Systems · Kinematics and Dynamics · Mechatronics System Design
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.
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.
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.
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.
Laparoscopic arm simulation in Isaac Sim: remote-centre-of-motion constraint solving, damped least-squares IK near singularities, teleoperation and deformable tissue contact.
Vision-language-action manipulation ablations with held-out generalisation tests and an OpenVLA-7B feasibility study, all measured on a 6 GB laptop GPU.
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.
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.
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.
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.
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.
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.
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.
Undergraduate capstone: an autonomous mobile robot for precision agriculture using ROS 2, SLAM Toolbox and Nav2, with a CoreXY manipulator for seed placement.
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.
Also: simulation focus · field & deployment focus · general