Humanoid, quadruped & mobile robotics · ROS 2 · NVIDIA Isaac Sim
🤖 Robotics Architecture Series
Three robots. Three morphologies. One interface.
A deliberate series of projects testing whether a clean ROS 2 + Isaac Sim control
architecture transfers across robot types — wheeled (Jetbot), bipedal (Unitree H1),
and quadrupedal (Boston Dynamics Spot). Same external /cmd_vel + /odom
contract; different policies, different DOF counts, different motion capabilities.
🚀 Featured Project — Spot Quadruped
Spot Quadruped Control — ROS 2 + Isaac Sim 5.1
A ROS 2 control stack for the Boston Dynamics Spot quadruped in NVIDIA
Isaac Sim 5.1, built around NVIDIA's pre-trained flat-terrain walking policy. Spot
autonomously navigates a configurable sequence of (x, y) goals using body-frame velocity
control with full holonomic motion — linear.x, linear.y, and angular.z commanded
simultaneously.
Third project in the architecture series. Unlike the H1 humanoid (forward-only kinematic),
Spot's policy supports lateral strafe and reverse — so the waypoint controller projects
the world-frame goal direction into the robot's body frame and commands all three velocities
at once. No rotate-first state machine needed.
🎥 Demo
Validation
Representative navigation run. Path coloured by navigation state. Demonstrates closed-loop
body-frame velocity control on /spot/odom feedback.
What's Different About Spot
Holonomic motion — linear.x, linear.y, and angular.z all usable simultaneously
A ROS 2 control stack for the Unitree H1 humanoid in NVIDIA Isaac Sim 5.1,
built around NVIDIA's pre-trained flat-terrain walking policy. The robot autonomously navigates
a sequence of waypoints using a heading-first state machine (ROTATE → WALK → REACHED) wrapped
around the policy's velocity interface.
Second project in the series. Same two-process architecture as the Spot and Jetbot projects;
external /cmd_vel + /odom contract identical. The interesting design
moment for this project was the OmniGraph bridge — see below.
Why OmniGraph for the bridge: Isaac Sim 5.1 ships Python 3.11; system
ROS 2 Jazzy is built for Python 3.12. The natural "import rclpy from a standalone script"
approach crashes inside Node.__init__ due to a C-extension ABI mismatch.
Solving this by moving all ROS pub/sub into OmniGraph keeps Python controllers in their
native environment and avoids fragile workarounds. This pattern was reused unchanged
for the Spot project.
Validation
Representative navigation run across a 2 m square. Path colour-coded by state
(amber = rotating, blue = walking, green = reached).
First project in the series · differential drive · 3 completed phases
The wheeled robot project where the architecture started. Same two-process design,
same external /cmd_vel + /odom contract, applied to a Jetbot
with differential-drive kinematics. Built progressively across three phases — basic motion,
closed-loop waypoint navigation, and reactive obstacle avoidance with LiDAR — with a
deliberate modular refactor in between to support the perception layer cleanly.
The architectural decisions made here scaled directly to the H1 humanoid and Spot quadruped
that followed. The Jetbot project remains the most thoroughly engineered of the three —
clean module hierarchy, unit-testable pure functions, dedicated architecture document.
Functional core / imperative shell — pure math, state machine, and perception
modules isolated from ROS 2 and Isaac Sim I/O
Type-safe state machine — Python enums and dataclasses, fully unit-testable
without simulator
Composable obstacle avoidance — implemented as a post-processing function on top
of the waypoint controller, keeping both pieces independently testable
PhysX LiDAR over RTX LiDAR — worked around a known Isaac Sim 5.1 bug in the
RTX FlatScan node by switching backends; produces identical /scan output
Architecture documentation — design decisions, trade-offs, and rejected
alternatives explicitly recorded
📍 Project Roadmap
✅ Phase 1: Motion control with articulation-based wheel velocities
✅ Phase 2: Closed-loop waypoint navigation with /odom feedback
University of Hertfordshire · Jun 2024 – Sep 2024 · Real hardware
Developed a real-time ROS-based control pipeline for a physical 25-DOF Shadow
Robot Hand, integrating sEMG-driven ML inference for gesture-based manipulation.
Hand pose commands derived from forearm muscle electrical activity via a Myo armband,
classified by trained ML models, and dispatched as joint targets to the real robot.
🎥 Hardware Demos
sEMG-driven gesture control of a physical Shadow Robot Hand (part 1 and part 2)
Low-latency sEMG signal acquisition using the Myo armband
Designed and trained ML models (SVM, CNN, LSTM) for gesture recognition
Integrated ML inference directly into the ROS control loop
Validated in Gazebo simulation and deployed on physical Shadow Robot hardware
ROSShadow Robot Hand (25-DOF)sEMGMyo armbandPyTorchGazebo
🌱 Vision
My long-term goal is to develop affordable, real-world robotics systems
that can learn from their environment through observation and interaction.
I'm particularly interested in learning-driven robots that improve their
behaviour over time using perception and feedback — with a focus on practical, everyday applications.
The aim is to reduce complexity and cost while enabling intelligent robotic systems
that can operate effectively in real-world environments.
