Implemented a bootstrapping approach that initialises a 3D point cloud from two keyframes and continuously uses 2D–3D correspondences to estimate camera motion. The system is being extended to a tightly coupled Visual–Inertial Odometry (VIO) pipeline using a Multi-State Constraint Kalman Filter (MSCKF) to fuse IMU data and mitigate scale drift inherent to monocular setups.

Part of the Real World Robotics course at ETH Zurich. The course comprised two major projects. The first focused on in-hand cube rotation using RL trained in simulation and deployed via Sim2Real techniques. Policies achieved 6.0 rotations/min using domain randomisation, reward tuning, and regularisation. For the, second, imitation learning project, an architecture search showed that DINOv3 backbones combined with Diffusion Policy outperform alternatives (DINOv2 and ResNet as visual backbones, and ACT as policy) for multi-colour object sorting.

Inspired by human biomechanical synergies, this project introduces distal articulation coupled to the PIP joint to reduce control complexity while improving dexterity. Criss-cross tendon routing with a target PIP–DIP ratio of 0.7 was used to expand the fingertip workspace and improve grasp robustness on small-diameter objects compared to the original design.

This project involved prototyping various spine solutions, CAD design, full mechanical desing analysis and then manufacturing of the spine. Unfortunately, the full robot was not fully validated before my internship finshed but the simulation video below shows the a proof of concept. In this video the roll axis of the spine is actauted using a triangular torque ramp signal. This is supposed to simulate the disturbance injected to the hindlegs of the cheetah during agile manoeuvres. The tail (unctrolled in this case), acting as counter-weight, significantly reduces the roll of the hind-quarters.

This video shows the initial validation of the 3-DOF spine with only the yaw and pitch differential motor connected and being controlled using an impedance controller.

Final-year undergraduate project to investigate the Duckiebot platform for Machine Learning by implementing an object detection model. A pre-trained YOLOv5 model, fine-tuned with a publicly available Duckietown dataset, was utilised to detect Duckietown-specific objects in Python.

To enable autonomous object avoidance, a simple Braitenberg controller was employed. The final solution could detect objects (duckies) in the scene and compute wheel commands to avoid the objects for relatively simple scenarios. The project formed a foundational model that future students can improve and build upon for more sophisticated behaviors.

The year-long process was designed to follow the general Product Development Process of concept generation, basic design, detail design, design for prototyping, parts procurement, and testing. Design decisions had to be motivated by rigorous calculations based on mechanical strength, output torque, amperage, etc. that optimized or accounted for the various URs. Where calculations were unfeasible, sound engineering judgment had to be employed with a valid explanation. A 3D CAD model was generated using the various outputs of detail design.

Finally, all the design parts were obtained from the workshop, and the model was integrated. This was an empowering moment when the product was finally in hand after being designed entirely from a sketch. In the final demonstration, the product achieved all the URs except for being able to bend the strongest 6mm Carbon Steel pipe. It was diagnosed that the plastic covers around the bending arm were generating friction when loaded, which was unaccounted for. Despite this, I was extremely proud of the product my team put together and was seeded with a passion for design.

Responsible for the Steam Generator's basic design, utilizing high-level cycle analysis to optimize for efficiency and cost effectiveness within defined user requirement specifications.

Developed as a verification tool to enable on-target firmware testing. The model accurately reflects the I/O and timing specifications defined in the hardware datasheet.