TL;DR
We built a quadruped robot from scratch, simulated it in PyBullet, and taught it to walk using a hill climber algorithm. In essence, this is what happens when you take two software engineers and throw them into a hardware project. Spoiler alert: it worked!
Project Overview & Motivation
When we started this project, I hadn't touched CAD software or a 3D printer before. My partner had a bit more experience, but it was definitely a learning experience. We wanted to see how far we could get learning mechanical engineering through a hands-on project.
The project came with some key constraints:
- Robot must use legged locomotion (no wheels allowed)
- Limited to 8 specific motors
- One designated battery type
- Must use an onboard Raspberry Pi
Given our limited mechanical engineering experience, we chose to build something we understood conceptually - a quadruped robot similar to Boston Dynamics' Spot, but obviously much simpler. This let us focus on learning the fundamental skills without getting lost in complex mechanical design.
Technical Implementation
Design & CAD
We started with ambitious plans - initially wanting to build a robotic horse archer with targeting systems and cool ML capabilities. Reality quickly set in, and we scaled back: first to a Nerf gun, then to a water cannon, and finally to just focusing on getting the basic robot to walk.
We ended up "forking" from an existing open-source quadruped robot project, adapting it for our specific motors and battery constraints. The main challenge was optimizing for lower weight while maintaining stability. We started in SolidWorks but switched to Fusion360 for better collaboration and laptop compatibility.
Parts & Assembly
This phase taught us a lot about hardware development bottlenecks. Long lead times for parts became a major constraint - for example, waiting a week for the correct length servo horn. We had several prints that either didn't fit the motors as intended or failed outright, each setback costing days of development time.
Key learning: Experience helps anticipate these setbacks. Precise CAD work, ordering backup parts, and structuring development to avoid single-part bottlenecks became crucial strategies.
Simulation
After accidentally pushing the motors beyond their limits and breaking a leg (oops), we shifted focus to simulation. We chose PyBullet for its simplicity and sufficiency for our needs. The simulation provided two key benefits:
- Safe environment for testing without breaking hardware
- Faster iteration on walking gaits (5 iterations per second, each testing 12 seconds of walking)
Getting our CAD model into PyBullet was surprisingly challenging. The URDF format requires careful handling of links and joints, and parallel drive mechanisms proved particularly tricky. We eventually found a script that could automatically convert properly formatted assemblies into URDF format.
Technical Implementation:
We implemented a hill climbing algorithm for gait optimization with the following key components:
- Gait parameters: frequency (ω), amplitude (a), phase offset (b), and vertical offset (c)
- Fixed simulation duration (10 seconds) with 0.5s settling time
- Fitness metric: forward distance traveled
- Parallel evaluation of multiple candidates per iteration
Each simulation run evaluates a candidate gait at 240 Hz simulation steps. We found that while longer simulation durations (20s+) provide more stable evaluations, they significantly increase computational cost. Our current implementation balances evaluation stability with iteration speed.
Walking Implementation
We implemented a simple hill climbing algorithm for gait optimization. The simulation environment let us test various parameters and gaits without risking the physical hardware. Full implementation details and code are available in our GitHub repository.
Results
[Coming soon! Videos and performance metrics of our robot in action.]
Discussion & Reflections
One key question we had was "How different is building a hardware project from a software project?" The answer: quite different in some ways. Many steps only make sense sequentially, and it's harder to break things into independent modules.
In software, you can typically parallelize work and get quick feedback (run the module, fix issues, repeat). Hardware development has longer feedback loops - you need the design before ordering parts, you need parts before testing assembly fit, and some issues only become apparent once you have physical components in hand.
What we wish we had: better ways to close the feedback loop sooner. Some of this might come from experience and better development processes, but it seems fundamental to hardware development that some things just take time to validate.