At the LIDAR Lab (led by Professor Ye Zhao) we are focused on improving the capabilties of humanoid, quadruped, and bipedal robots for locomotion and manipulation tasks in a dynamic environment. Seeing these robots move and perform tasks is fascinating because it feels like we are turning science fiction into reality!
Supernumerary Humanoid Robot Arm
The goal of this project was to explore a new morphology for a humanoid robot (Digit) and develop better insight into whether the addition of more limbs was a net positive. That was the claimed research purpose, what really drove the hard work was my desire to building a primitive real life Dr. Octopus!
The first iteration of this was a single 4 DOF arm mounted on Digit’s head to perform manipulation tasks while Digit’s hands are occupied.
Hardware Design and Manufacturing
I was responsible for all things hardware on this robot arm. This included actuator integration, transmission design, electrical component selection, wire harnessing, and making sure we had a reliable robot.
Tools Used and Lessons Learned
- Onshape: best CAD software for version management
- ANSYS structural FEA
- Daisy Chaining and CAN network setup
- Machine Design: sized components like pulleys, shafts, and set-screws
Control System
I worked with Paul to develop the control system where I contributed to hardware testing and gain tuning. We started with evaluting the robot’s reference trajectory tracking performance in simulation using Mujoco and the robot’s URDF. This was used to get the joint level performance requirements that guided motor selection.
After weeks of electrical debugging of our CAN bus and PD gain tuning, I bridged the gap between simulation and hardware.
Reinforcement Learning
With the help of Fukang, I trained successful policies using Mujoco playground and Jax based PPO. These tasks show Digit performing novel tasks which highlight the utility of the new arm. We are currently working on overcoming the dreaded Sim2Real gap as we deploy on hardware.
Hardware Demos
During ICRA 2025 we gave a live demo to spectators, which was the ultimate reliability test of our hardware.
Below is our first hardware demo which we have come a long way from! I did gain deep respect for all the robot hardware demos online because of how difficult it was to set this up.
My final side quest before I left the lab was teleoperating the Robot arm using a VR Controller.
Older Projects
Sensor Integration in a bipedal robot for Terrain Classification
Cassie is a bipedal robot that is used in the Foot Project under the Laboratory for Intelligent Decision and Autonomous Robots). The purpose of the project was to explore bipedal locomotion of robots in different terrains.
The goal:
Robots of the future need to be able to detect their environment and respond accordingly using an effective combination of sensors, actuators, and a classification algorithm. If the foot of the robot can be integrated with the right combination of sensors, the robot could receive quality data about the environment which would result in a high classification accuracy that opens a broad range of possibilities: the robot could be made to adjust its gait, successfully navigate emergency situations that involve slippery surfaces, and adapt to the environment it is in.
Current State:
The mechanical team prototyped the foot which is designed to have a similar structure to the hooves of a mountain goat. The split cleft structure of the goat’s foot is replicated using 2 tarsal segments that are spring loaded and controlled by a central servo and the orange rubber segments represent the soft sole of the hooves to provide better foot traction.
Comparing the prototype to the actual foot of a mountain goat. Mimicking evolutionary design can be quite challenging! Image credits
My role:
As a mechanical engineer my decision to work on the electrical and software team was driven by my curiosity to learn more about sensor integration in robots.
Our team was responsible for integrating 5 sensors into the foot of Cassie robot, and organizing the data collected from the sensors to allow software team to train the classification algorithms. As the bridge between the software and mechanical teams, we had to use space judiciously while collecting accurate data. Once the data was collected I implemented a Random Forrest Classification algorithm.
The sensors communicate using I2C and the master processor was the Raspberry Pi. We had to transition from using a teensy microcontroller to a raspberry pie due to the insufficient processing power of the teensy which was necessary for uploading the classification algorithm. It was my first experience with embedded programming! I used python to collect data from the temperature sensors and wrote the data to a CSV file for the software team to analyze. Organizing real time data was difficult and it took multiple iterations of writing code to achieve the results.
Our sensor setup involved the following devices that helped us with terrain classification.
- Accelerometer: To detect changes in motion (which could be used to adjust the gait of the robot)
- Bosch Pressure Sensors: Detecting changes in pressure exerted on the foot by the ground. These control the actuation of the servo when the foot contacts the ground.
- Capacitive Sensor: To measure the change in capacitance of materials of different surfaces. The sensor is essentially a conductive plate (Aluminum) stuck onto an insulating pad to avoid interference with the foot.
- Acoustic Sensor: For detecting the sound that the foot makes when walking on different surfaces.
- Temperature Sensor; Used to detect change in surface temperature (different materials have different thermal properties like specific heat which affects their temperature compared to the surrounding)
Humans are great at identifying the terrain we are in, and we primarily use visual cues along with auditory feedback to classify terrains. To match this accuracy, we used a diverse set of sensors for terrain classification. The foot was then tested different terrains with an Instron to simulate the force of walking.
Random Forrest
I decided to use Random Forrest as the classification algorithm after feature extraction had been performed on the incoming sensor data, the classification results were impressive leading to a 96% successful classification rate.
Mistakes and Failures
A major issue I did not consider before testing and integrating sensors was the choice of wire colors and the plan for routing the cables. While a lack of organization made our initial prototyping process a lot faster, organizing the wires before combining all sensors would have resulted in a simpler setup and prevented us from resoldering the entire system again.
An important problem I could not solve while sampling data from sensors was having a variable sampling rate. All the sensors were sampled at the same frequency and the data from the Capacitive Sensor had a lot of noise because we could not use a sampling rate that was high enough.
The classification algorithm I wrote only worked for offline classification where the data was collected first and then classified. This is short of the final goal of live classification where Cassie knows which terrain it is in while it moves.
ME 2110 – Creative Decisions and Design
ME 2110 has been the nightmare and highlight of many mechanical engineering students at Georgia Tech. In this class we learn about the “structured design process” but the most fun part is the intense 8 weeks spent designing and building a robot from scratch along with 60 other teams in the class. This was the first robot I built, and in hindsight its design was trivial, but it felt important at the time!
WHAT?
Ray is robot designed and fabricated by our team of three people called “The star war”. The objective of this project was to build a robot that autonomously defeats the Imperial Walkers (clears plastic toys from our zone), retrieves lightsabers, rescues Baby Yoda (brings a soft toy into the safety zone), destroys the Death Star (deposit a squash ball in each of 4 quadrants), and escapes egress (moves backwards). There were many rules that the robot needed to be designed around, with the most important ones being the constraints on size, the choice of power sources, the time for executing all tasks, and a $100 budget.
HOW?
The robot was designed on SolidWorks and fabricated from MDF , along with some custom hinges and mounts. Based on the constraints, wood was the most suitable choice for fabrication because it gave us the flexibility of rapid prototyping and testing while also keeping costs low. Most of the fabrication was done using laser cutters and 3D printers for custom parts while a band saw and basic shop tools were used for simpler parts.
The main power sources were two motors, two pneumatic pistons, and springs from mousetraps. All mechanisms needed to be designed around the given power sources which were controlled using an Arduino.
RESULTS?
There were two mock competitions before the final one to determine the seeding, and after Sprint 2 (Second mock competition) we were the second seed in the entire class! We had high expectations for the competition, but we underperformed, scoring 60% of the points we normally did. We got eliminated in the third out of seven possible rounds. Our failure can be attributed to a lot of factors the two most important being the following:
- Design Choice: Ray was primarily a moving design where the robot relied on perfect positioning and movement in order to execute all mechanisms. This worked perfectly under ideal conditions, but during the competition the playing field had 3 other moving robots that altered the playing field and we did not account for that in our design. This led to the robot misaligning and losing out on multiple points.
- Testing: Most of our testing was done under ideal conditions, where the playing field was empty. Towards the final competition we realized the problems that would arise if the playing field was not perfect, and we tried our best to mitigate some of these issues. If we had been more thorough about testing for multiple different situations from the beginning, we could avoid many problems.
Akshat Jain 