Research and Robotics Projects

A collaborative research grant between the Robomechanics Lab and FieldAI, this project develops an approach for mud-adaptive locomotion. Mud exhibits a complex, viscoplastic behavior, which introduces unmodeled shear, resistive, and suction forces during swing, intrusion, and extrusion phases of a robot's gait. These forces are dependent on the mud's rheology, which current high fidelity simulators model but are difficult to leverage for large-scale reinforcement learning. My work involves reduced-order modeling to characterize these nonlinear forces on the robot, and designing learned controllers for adaptive locomotion.

• NVIDIA Isaac
• Newton
• Genesis
• Reinforcement Learning
• Python

Quadruped gaits are usually labeled as a walk or a trot, but one gait can run at many duty factors, speeds, and stance widths. We show that duty factor, the fraction of a gait cycle each foot spends on the ground, predicts how robust a quadruped's locomotion is far better than gait type. At a matched duty factor, walking and trotting perform statistically the same.

The trend holds across three independent controllers: whole-body trajectory optimization, a reinforcement learning policy that learns to pick higher duty factors as terrain narrows, and centroidal MPC on a real Unitree Go2. On a 15 cm beam, the Go2 crossed every time at a 0.75 duty factor, with no tail or reaction wheel.

• Submitted to ICRA 2026, Pending Review
• MPC
• Estimation

I contributed to Quad-SDK, a full-stack, open-source, ROS-based framework for quadruped control and locomotion. As part of Quad-SDK's migration to ROS2, I've added support for MuJoCo as an alternative to Gazebo's hard contact model. MuJoCo's convex-optimization-based contact solver produces smoother, better conditioned dynamics, which has grown in popularity for modern robotics research for simulation and learning control policies. I added compatibility between a range of quadrupeds and Quad-SDK's existing environment samples, wiring them both into the original control stack.

I've also written plotting code to visualize hardware bag files and analyze quadruped performance under various conditions. Quad-SDK has plotting code written in MATLAB, which produces paper-quality plots at the cost of generation speed. I built faster tooling suited to day-to-day debugging and analysis with Python. This code has been used to debug and analyze quadruped performance on several quadruped projects in the Lab.

• MuJoCo
• Quad-SDK
• ROS2
• Simulation
• Python

This NYC-based hackathon involved constructing and controlling an SO-100 robot arm to complete a task. I calibrated the follower arm's joint offsets and torque limits to match the leader configuration, and collected training data via teleoperation, logging joint states and camera frames. After gathering 150 demonstration episodes, we trained an Action Chunking Transformer (ACT) policy via behavioral cloning for 100K training steps, using the recorded joint trajectories and visual input as supervision.

Our first policy suffered from significant jittering, preventing our arm from reliably performing our task of drawing on paper. We traced this issue to the encoder noise rather than the policy. By subtracting the leader and follower joint trajectories, we isolated noise in the system, and applying a low pass filter smoothed the actions. We also experimented with inference-sided solutions, which included frame skipping to increase execution speed.

• Calibration
• Reinforcement Learning
• Action-Chunking Transformers
• Signal Processing
• Vision Feedback

This course project aimed to implement a variety of increasingly complex controllers and estimators for a self-driving vehicle. I began by tuning proportional, integral and derivative gains for PID performance. Since longitudinal control varies the speed, I linearised the lateral control using pole placement, discretised the model, and implemented LQR — which completed the track in under 130 seconds after tuning the model.

I also implemented planning and estimation. A* replanned the trajectory when a slower car acted as an obstacle, letting the vehicle overtake on the straight, and EKF SLAM estimated the rough position and heading of the vehicle throughout the race when ground-truth was not available.

• Linearization
• PID
• LQR
• MPC
• A*
• EKF SLAM

Rapidly-exploring Random Trees planned a collision-free path by sampling the environment from a start to a goal state. SLAM then estimated and visualised the uncertainty along the robot's trajectory, with known obstacles modelled as landmarks to reduce it. The robot's confidence decreased when it couldn't see an obstacle, and rose again once it localised.

The RRT algorithm generated 100 trajectories, and the final plots capture the extreme cases — the shortest path, and the minimum and maximum uncertainty at the goal state. A Kalman filter computed the uncertainty at each time step.

• RRT
• SLAM
• Kalman Filter
• Obstacle Avoidance
• MATLAB

A combination of assignments from a graduate course covering optimisation and mathematical design techniques for the control of serial manipulators. The first showed a resolved rates simulation for link speed optimisation: inverse kinematics via a closed-loop resolved rates algorithm let the robot adhere to speed constraints (1mm translation tolerance, 0.0524 radians rotational), simulated via first-order interpolation in MATLAB.

The second used both the gradient of a curve and the Jacobian projected into the null space to keep the end effector orthogonal to a surface, simulated with a minimum-norm pseudoinverse redundancy resolution algorithm. Maintaining that orthogonality is directly applicable to welding or writing.

• Resolved Rates
• Null Space Projection
• Jacobian
• Cost Functions
• MATLAB

Data was collected with a webcam overlooking foam cubes scattered across the workspace, annotated in Roboflow, then trained with YOLOv8 to identify the pixel location and colour class of each cube. Because the dataset was small, colours close to the table had lower confidence, so higher-contrast colours were used instead. The centre of each bounding box was found with OpenCV and the coordinates scaled to the workspace.

Once joint angles were computed, the robot was sent commands using the Doosan Robot Language, a Python-based framework. I used the sockets library to establish the client-server connection that drove the arm.

• OpenCV
• YOLOv8
• Python
• Pick and Place

An external device to assist type III SMA patients with sit-to-stand transitions. It autonomously detects when the user wants to stand, actuates a spring tied to a spool, and a cable routed down the wearer's leg pulls them up. It achieved 10% assistance against the previous iteration's 3–4%, with total volume down 17% and width down 28%.

The main challenge was using a single motor to actuate both the spring charging mechanism and the cam that changes state, solved with a geared switching mechanism. To detect the transition we ran motion capture with markers routed like the cable, built 3D splines through the points, and discretised them to approximate how much cable length changes from sitting to standing — then actuated at the point of maximum knee torque.

• Mechatronics
• 3D Splines
• CAD
• SolidWorks
• Machining

Built for a graduate mechatronics course, this device was designed to alleviate joint pain and rebuild hand and forearm strength, with applications in PT clinics for testing and monitoring grip strength. A knob sets the squeezing strength, shown on an LCD; a limit switch on the handle counts repetitions and triggers a buzzer.

It ran on a PIC16F88 microcontroller programmed in PICBasic Pro — reading the potentiometer needed ADCIN rather than the Pot function to translate force correctly. The force is translated through a fourbar linkage that stretches a spring, which on this budget was a rubber band.

• Mechatronics
• PICBasic Pro
• PIC16F88
• Fourbar Linkage

The PROOF Lab's Doosan H2515 6-DoF arm needed an end effector for pick and place, so I designed and 3D printed a gripper that opens and closes its jaws under a PWM signal from an Arduino sent to a motor controller.

The arm's flange provided a 24V digital IO, which I stepped down to 5V with a voltage divider for the Arduino. A gear and hinging mechanism drives the jaws, letting actuation be toggled directly from the robot's own programming language.

• SolidWorks
• Mechatronics
• 3D Printing