Robotics engineer

Mohammed
Abdul Rahman

I build motion software — global planners, local controllers, reactive replanning for manipulators, and the bringup that makes any of it run on real hardware. Currently working on physical AI: learned policies for bimanual manipulation, and getting them off the simulator and onto a UR12e.

Now
Advanced Robotics & AI intern, Siemens
Study
MS Robotics (ECE), Northeastern University ’27
Before
Team Robocon MJCET, five seasons
Based
Berkeley, California
mohammedabdulr.1@northeastern.edu Run my robots Résumé (PDF)
02

Work

Eight systems worth showing. Everything else lives on GitHub.

Interactive Six of them run in your browser. Draw a map and search it with A*, Theta*, RRT, SMAC or the hybrid; drive a TurtleBot with your cursor using any of five local controllers; race all five over one plan; block a UR12e mid-motion and watch it cancel and replan around your hand; click a point on a Go2 course and watch four cost functions drive to it, then put back the two constants a physics cross-check refuted; run an eight-phase bimanual assembly controller against its own analytic plant. Not videos — four download the Python from these repos as the page loads and two run copies, marked as copies, because those repos are private.
  1. 01

    Bimanual deformable garment manipulation

    Trained and evaluated ACT, Diffusion Policy and smolVLA on multi-garment folding in a bimanual setup in Isaac Sim, alongside work with π0, π0.5 and OpenPI across the VLA stack. Sim-to-real transfer onto a UR12e is in progress.

    • Isaac Sim
    • π0 / π0.5
    • OpenPI
    • ACT
    • Diffusion Policy
    • smolVLA
    Success rate
    60.4%
    Peak, long top
    78%
    Categories
    4
  2. 02

    Pick and place that replans around what the camera sees

    UR12e and a Robotiq Hand-E. A RealSense depth pipeline with workspace filtering, robot self-masking and colour-based body exclusion isolates live obstacles, so when a hand enters the planned path the controller cancels cleanly, waits for the arm to settle and re-plans from the current state.

    • ROS 2 Jazzy
    • MoveIt 2
    • BIT*
    • RealSense D435i
    • OctoMap
    Detection
    100% ≥4 cm
    Detect latency
    0.10s
    Blind within
    11cm
    IK solution pool
    120
  3. 03

    Reactive autonomous navigation stack

    A planner/controller architecture written from scratch for TurtleBot4 — no Nav2 behaviour tree server. A*, Theta*, SMAC and RRT sit behind one global interface; DWA, Pure Pursuit, Stanley, TEB and MPPI behind another, all five driving the same suite closed-loop. The C++ port is benchmarked below.

    • ROS 2 Jazzy
    • C++
    • TurtleBot4
    • nav2_costmap_2d
    Global planners
    4
    Local controllers
    5
    A* after C++ port
    99–192×
  4. 04

    K.A.L.B — kinematical autonomous legged robot

    A twelve-axis quadruped with locomotion modelled after the MIT Cheetah. Gait stability and autonomous navigation validated with SLAM in Gazebo. Now collecting locomotion and obstacle-avoidance demonstrations for inverse reinforcement learning, aimed at a Unitree Go2.

    • ROS 2
    • Gazebo
    • gmapping
    • AMCL
    • Inverse RL
    Watch it walk
    Actuated axes
    12
    Legs
    4
    Gait
    Trot
  5. 05

    Custom DWA local planner

    The dynamic window approach written from scratch instead of pulling in nav2_dwb_controller — velocity sampling inside the dynamic constraints, trajectory rollout, cost evaluation on goal distance and clearance, and an RViz marker for every candidate so you can see what it rejected.

    • ROS 2 Humble
    • TurtleBot3
    • RViz
    Watch the rollouts
    GitHub stars
    6
    Written from
    Scratch
  6. 06

    Robot foundation model

    A flow-matching VLA, a latent world model and an RL-tuned reasoner on one backbone, with an orchestration layer above it that never touches the weights — models/ does not import orchestration/, which is what keeps two philosophies from being stapled together. Every robot writes into one 32-D action space with a per-embodiment mask, and a competence head exports abstention so the layer above can ask “can you do this?” in a forward pass instead of a rollout. It trains on 3,008 episodes collected in robosuite and it has never once completed the task — 0 of 16. The one real result is the competence signal: prediction error separates failures at AUROC 0.946 ± 0.008 against controls at 0.11, which the repo still refuses to call a win because the same checkpoint predicts the next latent worse than copying the present. Its own evidence index opens by counting twelve times a number looked healthy while the thing it stood for did nothing.

    • PyTorch
    • Flow matching
    • GRPO
    • Pydantic
    • RDT-style action space
    Read the action space
    Action space
    32-D
    Embodiments
    7
    Failure modes watched
    9
  7. 07

    Orchestrated bimanual assembly

    The same instrument stack — latent world model, calibrated competence head, RL-tuned reasoner, Conductor and harness — driving a LoRA-finetuned π0.5 on the NIST Assembly Task Board in Isaac Sim, two UR5s on a shared workspace. The question is narrow on purpose: does the instrument stack earn its place with the policy and the task held fixed, harness on against harness off. Nothing broader. The muscle changes and the instruments do not — they are ported by import, so there is one definition of copy_margin rather than two that will drift, and “ported wholesale” is a claim you can check with grep. Eight of the fourteen tensor widths change in the swap and three agree by luck, which is exactly when an unasserted assumption survives, so all fourteen are asserted and printed at run start. Six phases, each gated by a passing artefact the CLI checks rather than by discipline; the reasoner GRPO phase is the highest-risk one and has never run.

    • Isaac Sim
    • π0.5 / openpi
    • LoRA
    • GRPO
    • ROS 2
    • UR5 × 2
    Run the phase machine
    Gated phases
    6
    Tensor widths asserted
    14
    P0 gate
    >90%
  8. 08

    Quadruped navigation cost, and the constant that faked it

    Four cost functions for a Unitree Go2 — default Nav2 inflation, a hand-tuned legged costmap, a supervised learned cost and maximum-entropy IRL — sharing one planner, one controller and one 120-course suite so that only the cost function varies. The first table showed Nav2 losing decisively at 70.0%, with 20 of its 36 failures being slips on ice an occupancy costmap has no channel to represent. It came from FALL_RATE, a constant in my own simulator I had tuned by hand until the methods separated. A MuJoCo cross-check against the real Go2 MJCF found the drag sign backwards — ice is the slowest surface at 0.30, not the fastest at 0.95 — and no falls at all on flat low-friction ground. With the invented hazard removed, Nav2 goes to 87.5% and the effect disappears. All four are now indistinguishable and every interval overlaps. Everyone building a robot-learning evaluation writes a surrogate like this; almost nobody validates it, and the null result is the evidence for doing so.

    • MuJoCo
    • Nav2
    • MaxEnt IRL
    • PyTorch
    • Unitree Go2
    • ROS 2
    Break the physics yourself
    Courses
    120
    Nav2, before → after
    70.0 → 87.5%
    MuJoCo cross-check
    33× realtime
03

Measured

Claims I could check, checked — including the ones that came out badly.

My résumé claims porting the planners to C++ cut trajectory rollout latency by 2–3×. That was an estimate, so I wrote a harness that loads the real modules and times them on identical maps. The estimate was low, and it was low in a more interesting way than it was wrong.

A* global planner

Median of five runs on 8-connected costmaps.

  • Python
  • C++
MapPythonC++ SpeedupRelative (log)
128 × 1287.50 ms0.046 ms163×
256 × 256110.26 ms1.115 ms99×
384 × 384884.21 ms4.598 ms192×

Not all of that is the language. The C++ port also introduced a closed set, so it expands 21,015 nodes where Python expands 61,631 on the same map. Roughly 3× is algorithmic; the rest is a heapq of tuples against a priority_queue of PODs.

DWA rollout and scoring

Median of 25 runs, 2.5 s horizon at dt = 0.1.

  • Python
  • C++
WindowPythonC++ Per trajectoryRelative (log)
Accel-limited one control cycle, ~30 traj. 0.3037 ms0.0098 ms26×
Full velocity space 2,626 trajectories 4.2121 ms1.0570 ms4×

The gap shrinks as the batch grows. At the window the controller actually evaluates each cycle, numpy pays fixed per-call overhead across a few dozen trajectories and loses by 26×. Give it 2,626 and vectorisation amortises that down to 4×. So the C++ port buys the most where it matters least — both clear a 20 Hz budget on the real window — and the global planner is where it earns its keep.

Obstacle detection — UR12e replanning

Synthetic frames with known ground truth, through the detector’s own callback.

  • Detected
  • Missed
Obstacle radiusDetected Centroid errorLatency 40 trials
2 cm0 / 40——
3 cm0 / 40——
4 cm40 / 402.3 mm0.10 s
6 cm40 / 402.1 mm0.10 s
10 cm40 / 402.1 mm0.10 s

Below about 4 cm an object returns fewer points than the detector’s threshold and is never seen. Above it the thing saturates — size stops mattering, the centroid lands within ~2 mm of truth, and detection takes two frames at 20 Hz. Zero false positives in 300 frames with the arm in view. The pipeline runs in 2.47 ms against a 50 ms budget, so latency is set by the debounce counter, not by compute.

…and where it goes blind

An obstacle walked in toward the forearm, 25 trials per distance.

Distance to nearest linkDetected 25 trials
8 cm0%
10 cm0%
11 cm76%
12 cm100%
30 cm100%

This is the number worth knowing, and I would rather publish it than not. ARM_SEG_RADIUS carves a 12 cm tube around the kinematic chain and everything inside it is discarded as the robot’s own body — so a hand closer than about 11 cm to a link is invisible, not detected late. It is a deliberate trade against phantom detections off the arm itself, but it means the safety claim is “avoids what it can see”, and things within 11 cm are not in that set.

Garment folding, against the literature

Published figures, each on its own task. Not a head-to-head.

SystemReported Measured onSource
This project ACT / Diffusion Policy / smolVLA 60.4% avg, 78% peak Bimanual multi-garment folding, 4 categories, Isaac Sim —
SpeedFolding Avigal et al., IROS 2022 93%, <120 s per fold Real garments from a random initial configuration, engineered bimanual primitives, 4,300 annotated actions 2208.10552
ACT Zhao et al., RSS 2023 80–90% Six fine-grained bimanual tasks — battery slotting, condiment cup. Rigid objects 2304.13705
smolVLA Hugging Face, 2025 78.3% SO100 pick-place, stacking, sorting. Rigid objects blog
Diffusion Policy Chi et al., RSS 2023 +46.9% over prior SOTA 12 tasks across 4 manipulation benchmarks 2303.04137

Read this as context, not a leaderboard — no two rows share a task, a robot or a success criterion. Two things it does show. The 78–90% those architectures report is on rigid objects; none of it is deformables, which is the part that makes garments hard. And the one row that is garment folding, SpeedFolding at 93%, gets there with engineered bimanual action primitives and 4,300 annotated actions rather than an end-to-end learned policy. The distance between 60.4% and 93% is mostly that gap, and closing it is what the sim-to-real work is for.

Intel Xeon 2.10 GHz · g++ 13.3 -O2 · Python 3.11, numpy 2.4. Nothing is reimplemented: both harnesses call the planners' own code. Harness and method.

04

Stack

Things I have shipped something with, not things I have read about.

Frameworks
ROS / ROS 2 (Humble, Jazzy) · MoveIt 2 · Nav2 · Gazebo · RViz · Isaac Sim · MuJoCo · Autoware
Planning
A* · Theta* · SMAC · RRT / RRT-Connect · BIT* · DWA · Pure Pursuit · Stanley · TEB · MPPI
Physical AI
ACT · Diffusion Policy · smolVLA · π0.5 / openpi · flow matching · GRPO · inverse RL (MaxEnt) · sim-to-real transfer
Perception
YOLO · OpenCV · depth estimation · sensor fusion · OctoMap · visual SLAM (PySLAM)
Hardware
UR12e / UR5 · Robotiq Hand-E & 2F-85 · TurtleBot3/4 · Unitree Go2 · Jetson Nano · Arduino
Sensors
LiDAR · IMU · wheel encoders · Intel RealSense D435i · GPS/GNSS RTK
Languages
Python · C++ · C · URDF / XACRO · CMake
Design
SolidWorks · OnShape · Eagle PCB
05

Path

Five ABU Robocon seasons, then grad school.

  1. 2026 –

    Advanced Robotics and AI intern Siemens

    Berkeley, California. On-site, from June 2026.

  2. 2026

    Graduate lab assistant Northeastern University

    ROS 2 bag collection from a Ford Mustang Mach-E autonomous vehicle platform, with visual SLAM run over the recorded drives for trajectory analysis. Configured the UR12e URDF with Robotiq gripper integration and built the MoveIt 2 planning stack for faculty research, plus an end-effector camera mount now used across several setups.

  3. 2025 – 27

    MS Robotics, Electrical & Computer Engineering Northeastern University

    Expected May 2027. Robotics Lab.

  4. 2020 – 25

    Team Robocon MJCET

    Junior programmer → programmer → robotics control engineer → team lead/captain → team mentor

    Five ABU Robocon seasons. As team lead I took the team to its first national appearance in over five years at Harvest Day (2024) — two holonomic drives with ball shooters, pneumatic seedling collection and silo placement, on a ROS stack with custom waypoint navigation, colour-based ball detection, and a learned policy that chose silo placements against the opponent’s moves.

    Before that: lagori (2022), an omni shooter paired with a swerve robot, computer vision tracking incoming balls and a model predicting where the stack would fall; Angkor Wat (2023), omni and mecanum platforms detecting rings and poles; and pitch-pot (2021), a holonomic chassis with pneumatic arrow handling and a spring-based shooter. Mentored the 2025 basketball season.

  5. 2020 – 24

    BE Computer Science & Engineering Osmania University

    Hyderabad, India.

  6. 2022

    Robotics engineer intern Consciente Technologies

    Computed Denavit–Hartenberg parameters for a custom 5-DOF manipulator and configured the MoveIt planning stack for integrated control, then implemented a coordinate-based autonomous navigation system taking terminal goal inputs and deployed it on physical hardware.

06

Contact

Happy to talk about any of the above, including the parts that did not work.