- Building
For this phase of the project, the primary goal was to construct a stable chassis for Gary (the robot’s name). I designed and fabricated a new, updated base intended to improve structural integrity. However, during the assembly phase, I ran into a clearance issue—the motors did not fit properly into the new mounts. As a result, I had to pivot and revert back to the previous design iteration.
Figure 1: The first version of the base (successful fit).
Figure 2: The second version of the base that unfortunately did not work due to motor clearance.
Because my immediate goal was to establish a quick Proof of Concept (PoC) and test the self-balancing algorithms, I decided not to let the chassis setback halt my momentum. To secure the electronics, I temporary mounted all the internal components, sensors, and the battery pack directly onto the older chassis using hot glue.
While not the final aesthetic design, this kept the center of gravity fixed and robust enough for testing. With the physical structure secured, Gary was officially ready to move on to the wiring stage.
- Wiring
The wiring phase presented several hardware limitations that required creative, temporary solutions, many of which became valuable learning experiences later in the project.
Power Supply & Connections
Because a dedicated 4xAA battery pack wasn’t available, I engineered a solution by combining two separate smaller battery packs to supply the necessary voltage. Furthermore, because I did not have access to a soldering iron, I had to secure the spliced power wires together using hot glue. While this worked initially to establish a connection, the lack of a proper mechanical bond introduced intermittent power issues down the line.
Microcontroller & Motor Protection
Before connecting any components, I had to research safe wiring configurations to ensure the high-voltage motor circuits wouldn’t back-feed and destroy the Raspberry Pi Pico. To safely bridge the Pico, the dual battery packs, and the motor outputs without soldering, I mapped the entire circuit out on a standard breadboard.
[Battery Packs] —> [Motor Driver] <—> [Raspberry Pi Pico]
|
[DC Motors]
The Breadboard & Sensor Bottleneck
While the breadboard was essential for a solderless prototype, it quickly became a primary source of instability. The most critical issue occurred with the ADXL345 accelerometer:
Because the header pins couldn’t be permanently soldered, I had to rely on friction and physical pressure to keep the jumper wires connected to the sensor.
This poor connection meant that as soon as the robot’s motors spun up, the physical vibrations shook the loose wires. This resulted in erratic sensor readings, momentary ‘’‘OSError’’’ crashes, and distorted tilt data, proving that a reliable mechanical connection is vital for self-balancing robotics.
- Coding
Sensor Integration & Debugging
The coding phase began by reading raw 6-byte chunks from the ADXL345 register 0x32. These data points were converted into integers and printed out as a tuple ‘’’(x, y, z)’’’ so they could be monitored and visualized inside the Thonny Plotter.
Implementing the PID Control Loop
A PID framework was written to determine how Gary reacts to falling:
K_p (Proportional): Pushes back against the present error based on how far the robot is currently tilting.
K_d (Derivative): Counteracts future error by assessing how fast the robot is falling, which dampens shaking.
K_i (Integral): Tracks past error over time to eliminate minor, steady leaning issues.
Figure 3: Assembled robot
.png)
.png)
