CrunchLabs Balance Bot: Build, Balance and Tune

Educational electronics kits often start with a simple promise: connect a few parts, upload some code, and watch the hardware respond. That approach works well because it makes abstract ideas visible and tangible. A button becomes input, a light becomes output, and a motor turns code into motion. Across the first year of CrunchLabs Hack Pack builds, that pattern has gradually expanded from basic control into increasingly complex mechanical systems.

CrunchLabs IR Turret: Build, Code, and Fire

Can a foam-dart turret teach you embedded programming? The CrunchLabs Hack Pack says yes. This hands-on project introduces IR sensors, servo motors, and tidy Arduino code

TechnodabblerAlex Denault

The Balance Bot marks a useful shift in that progression because its main behavior is continuous and self-directed. Once it is powered on and calibrated, it has to sense its own motion, decide whether it is falling, and correct itself before the mistake becomes unrecoverable. That makes the sixth box in the series feel less like another electronic mechanism and more like an introduction to autonomous robotics. This article looks at the hardware inside the kit, why balancing is a harder problem than it first appears, and how the code turns PID control into something builders can observe and adjust.

Inside the Box

The Balance Bot includes many familiar Hack Pack ingredients, but they are arranged in a way that feels different from the earlier builds. There are two DC motors, two wheels, a motor driver, a microcontroller, an LED bar, an ultrasonic distance sensor, a rechargeable power bank, plastic body parts, wooden side panels, foam bumpers, and the small hardware needed to assemble the chassis. On paper, some of that overlaps with previous kits. In practice, the layout changes the character of the project.

The most important change is the move toward a motherboard-style design. Earlier Hack Pack builds used a custom breadboard-style assembly where the electronics felt more exposed as individual connections. The Balance Bot uses a larger power PCB that acts as the main board for the robot. The Arduino Nano-compatible board plugs into it as the main controller, the MPU6500 motion sensor plugs in as the robot’s orientation sensor, and the DRV8835 motor driver handles power delivery to the motors. The board ties those pieces together while also handling power distribution and connection points for sensors and future expansion.

The DRV8835 is the bridge between the microcontroller and the two DC motors. The Arduino Nano-compatible board can decide what the motors should do, but it cannot safely provide the current needed to drive them directly. The motor driver takes the low-power control signals from the controller and turns them into usable motor output, including speed and direction. In the Balance Bot, these motors not only move the robot across the floor, they make constant corrections to keep the body upright.

The MPU6500 is the more important new sensor in the kit. It is an inertial measurement unit, which means it can measure acceleration and rotation. For the Balance Bot, those readings are used to estimate pitch: the angle that tells the robot whether it is leaning forward, leaning backward, or close to upright.

The HC-SR04 ultrasonic distance sensor adds a second kind of awareness. It measures the distance to objects in front of the head by sending out an ultrasonic pulse and timing how long it takes to bounce back. That sensor gives the robot a way to react to the outside world, whether through the stock LED behavior or through hacks such as object avoidance and Force Push.

Taken together, these parts form a compact robotics stack. The power board distributes energy and signals, the microcontroller runs the control loop, the MPU6500 provides the robot’s sense of balance, the ultrasonic sensor gives it a simple way to read the space in front of it, and the DRV8835 turns software decisions into motor movement. The LED bar rounds out the system by making internal state visible, which becomes useful during calibration, balancing, and hacking.

Building the Balance Bot

The Balance Bot is one of the quicker Hack Pack builds so far. The assembly breaks down into three broad stages: building the head, installing the electronics into the chassis, and closing the robot up with the motors, side panels, bumpers, and wheels.

The head is more than a decorative shell. It holds the power bank, the ultrasonic sensor, and the LED bar, which makes it part of the robot’s functional design. Placing the battery high in the body raises the center of mass, which helps the Balance Bot behave more like an inverted pendulum. This provides the software more time to react before the robot falls. It is a clever mechanical decision because shifts the center of mass using components necessary in the build.

The head also includes one of the more polished small details in the kit. A strip of reflective tape sits behind the LED bar, helping diffuse the light through the head instead of leaving it as a harsh row of bare LEDs. The LED bar still works as a status display, but the lighting feels more integrated into the character of the robot. The LEDs are also useful during calibration and testing, showing the state of the robot.

The second stage is where the motherboard-style design makes the build easier. Instead of wiring each board into a breadboard layout, the Arduino Nano-compatible board, MPU6500, and DRV8835 motor driver plug into the main power PCB. That keeps the wiring cleaner and reduces the number of places where a beginner can make a small but difficult-to-find mistake. The cable routing still requires care, especially around the head and the sensor wires.

The two USB-C ports are worth calling out because they serve different jobs. The top USB-C is part of the power setup, allowing the power bank to remain installed while still being accessible for charging. The side USB-C port is used for loading code onto the controller. It is a small distinction, but it is easy to imagine someone plugging into the wrong port when switching between charging, testing, and programming.

Once the electronics are in place, the remaining assembly is mostly structural. The motors mount into the chassis, the wheels press onto the motor shafts, and the foam bumpers and wooden side panels close the body. The bumpers are a practical addition because the Balance Bot will fall during testing, especially when experimenting with calibration, PID values, or distance-based movement.

The build also leaves room for expansion in a way that feels deliberate. There are openings and mounting options for head movement, arm movement, and the IR antenna used by the remote control hack. CrunchLabs also includes the gears needed to start experimenting with motion in the head or arms. These small additions raise an interesting possibility for future Hack Pack support: optional component packs with servos and related hardware would fit naturally with this style of expandable build.

The robot should be held upright when powered on, as part of the calibration process to help the MPU determine the up direction. Pressing the top button near the battery once turns the bot on, and two presses turns it off. If calibration goes wrong, power cycling (restart) the bot is often the easiest solution.

Why Balance Is Hard

A two-wheeled balancing robot is an inverted pendulum. The body sits above the wheel axle, so gravity is always pulling it forward or backward. To stay upright, the robot has to measure its angle, move the wheels in the right direction, and repeat that correction fast enough to keep the fall under control.

The key sensor in this process is the MPU6500 (an upgrade to the aging MPU6050). An MPU, or motion processing unit, combines motion sensors that measure acceleration and rotation. The same general idea appears in familiar devices such as Wii Remotes, Nintendo Switch controllers, phones, drones, and VR headsets. When those devices detect tilting, shaking, turning, or orientation changes by relying on inertial sensing. The Balance Bot uses that same class of technology for a more demanding job: staying upright.

Inside the MPU are tiny mechanical structures built directly into the chip. These MEMS structures move slightly as the sensor accelerates or rotates. The chip measures those tiny movements electrically, then turns them into acceleration and gyroscope readings.

For the Balance Bot, those readings are used to estimate pitch, which is the forward or backward angle of the robot’s body. If the body leans forward, the wheels need to move forward to catch it. If the body leans backward, the wheels need to reverse. The MPU also tells when the Balance Bot is lying down (or has fallen down), pausing the motors instead of letting the wheels keep spinning. That makes the robot easier to handle on the bench, and it protects the build when it falls during testing.

With the stock code, the Balance Bot balances properly, but it does not stand perfectly still. It takes a moment to settle, oscillates slightly, and can drift backward over time. Small pushes are recoverable. Larger pushes can lead to a faster correction and a fall. That behavior is the lesson: balance is a continuous correction problem, and the MPU provides the information needed to begin that correction.

The Code: PID and Dynamic Set Point

The Balance Bot code runs as a feedback loop. It reads the current pitch from the MPU, compares that angle with the target angle, calculates a correction, and sends that correction to the motors. The loop repeats while the robot is balancing. The challenge is choosing how strongly the robot should react each time it starts to lean.

void loop() {
  
  //reads data from MPU if the interrupt flag tells us data is ready
  if (IMUdataReady == 1) {
    //stores the yaw, pitch, and roll into the ypr[] array as radians
    readAngles();
    // convert radians to degrees
    pitch = -(ypr[1] * 180 / M_PI);  
    roll = (ypr[2] * 180 / M_PI);
    yaw = (ypr[0] * 180 / M_PI);
  }

  if (is_upright()) { //if the bot is standing up
    // if we want the setpoint to change based on output
    if (useDynamicSetpoint){ 
      dynamic_setpoint();
    }else{
      //otherwise just set the setpoint equal to init
      pid_setpoint = init_angle; 
    }
    // PID control
    // provide current pitch from readAngles as PID input
    pid_input = pitch; 
    pid.Compute(); // computes the PID equation

    // Use PID output to control motors
    activateMotors();
  } else { //if not standing up, turn motors off
    analogWrite(AENBL, 0);
    analogWrite(BENBL, 0);
  }

  handle_sensors();

  last_state = bal_state;
  cmd_count++;
}

That reaction is controlled through PID: Proportional, Integral and Derivative. The proportional part responds to the current error, which is the difference between the target angle and the measured pitch. The integral part accounts for error that builds up over time, which helps when the robot keeps drifting in one direction. The derivative part looks at how quickly the error is changing, which helps soften the response as the robot approaches balance. The code combines these three constants with the robot’s current pitch error to calculate a motor output, which tells the wheels how hard to turn and in which direction.

The initial values found in the stock code are a good compromise, but they are not magic numbers. These values are tuned to make the robot balance well enough while still leaving room for experimentation. For example, increasing the response can make the robot react faster, but it can also make it jitter or overcorrect. Reducing the response can make the robot smoother, but it may become too slow to catch itself. That trade-off is where the code becomes interesting.

// PID values control the response of the motors based on the 
// pid_setpoint angle and current pitch angle to try to keep the 
// pitch near the pid_setpoint

// the Proportional term of PID - directly proportional to the error 
// (setpoint - pitch) between setpoint angle and input
double kP = 24.2;

// the Integral term of PID - integrates the error over time to 
// minimize accumulating error (if P is regularly falling short)
double kI = 225;

// the Derivative term of PID - takes the derivative (or 
// instantaneous rate of change) in order to soften the PI response
// as it approaches the input value
double kD = 0.76; 

 // this is your "trim" to adjust the pid_setpoint (balanced) angle 
// in case your bot is favoring forward over backward movement or 
// vice versa. 
float init_angle = -0.5;        
//Nominally init should be around 0 degrees, but may vary based on 
// the mounting of the MPU sensor. negative values correspond to 
// forward bias, positive values correspond to backward bias

The dynamic set point adds another layer to that idea. The Balance Bot is not always aiming for a perfect vertical angle. It may need to lean slightly forward or backward to stop itself from rolling away. That matters because the small DC motors are not perfectly smooth or precise. They have gearbox backlash, a bit of delay, and a noticeable kick when they respond. Instead of treating upright as a fixed target, the code lets the target angle move slightly as the robot responds to drift, pushes, or driving commands.

That flexible target helps explain why the bot can look slightly unsettled even when it is working correctly. It may overshoot, correct back, and settle through a series of small movements rather than stopping perfectly in place. If the dynamic adjustment is too weak, the robot may drift. If it is too strong, the moving target can make the robot jumpier and less predictable.

Beyond the Build

The Balance Bot feels more expandable than any of the earlier Hack Pack projects. Much of this comes from the way CrunchLabs designed the unused space around it. The ultrasonic sensor is already mounted in the head, even though the starting behavior uses it mostly for simple interaction and LED feedback. There is a place for the IR antenna, even though remote control is treated as an additional hack. The side panels and internal chassis leave room for head or arm movement, and the kit includes the gears needed to start experimenting with those ideas.

That makes the expansion feel intentional. CrunchLabs could have shipped the robot with every feature enabled, but that would have made the kit more expensive to produce, more complicated to assemble, and harder to explain. Instead, the Balance Bot keeps the first build approachable while leaving clear paths for the next step. It also ties the robot back into the rest of the Hack Pack ecosystem. Parts and concepts from earlier boxes, including IR control, servos, motors, and lighting, can be brought forward into a robot that is already balancing on its own.

The ultrasonic sensor is still the best place to start as it is already present. In the starting configuration, it gives the robot a simple way to react when something is in front of it. With a different program, the same sensor becomes part of the robot’s behavior. Object avoidance lets the bot detect a nearby wall, back away, and turn. Force Push uses the sensor to maintain distance from a hand, making the robot move backward when the hand gets close and follow when the hand moves away.

Force Push works reasonably well, but it also shows why robotics is more complicated than adding another input. The usable distance range is fairly narrow. If the hand gets too close, the robot can react too aggressively, accelerate backward, overcorrect, and fall. A next iteration version might better limit the maximum reverse speed or soften the response when the bot enters that close-range zone.

The LED bar also becomes more valuable as the robot gains behaviors. It is easy to treat LEDs as decoration, but on the Balance Bot they work as a visible status system. A useful software hack would connect the lighting to pitch, motor output, or sensor distance, turning hidden control values into something the builder can see.

The hardware expansion points make the project feel more like a platform than a finished toy. Adding the IR antenna turns the robot into a remote-controlled balancing vehicle. Adding a servo can move the head or drive arms. Those ideas are familiar from earlier Hack Pack builds, but the context is different here, as any added movement has to coexist with the balance loop.

The community improvements point in the same direction. Multiplexed turns the Balance Bot into a laser tag target, adding IR detection, extra lighting, hit reactions, and a final defeat sequence while preserving the balancing behavior. Luke added motors and printed arms to help the robot stand itself back up after falling. Those projects show the advantages of the built-in expansions.

That is the strength of this box. The starting build is quick, but the design leaves room to grow. The best hacks extend the robot’s ability to sense, respond, recover, and communicate. That is also why the Balance Bot feels like a stronger invitation to experiment than several earlier boxes. The extra work is more intimidating, but the result is more meaningful because it changes the behavior of an autonomous robot.

Concluding the First Year

The Balance Bot feels like a fitting close to the first year of Hack Pack because it changes the center of the lesson. Earlier builds introduced useful pieces of electronics, coding, and mechanical design. They showed how sensors become inputs, how motors become outputs, and how code can coordinate a physical system. The Balance Bot brings those ideas together in a robot that has to manage itself.

HackPack - Technodabbler

CrunchLabs Hack Pack blends hands-on engineering with playful design, guiding learners through real electronics, code, and problem-solving in a structured build.

TechnodabblerAlex Denault

It also shows how well the Hack Pack format works when the hardware leaves room for exploration. The starting build is approachable, but the system underneath is complex enough to reward deeper experimentation. As a first-year endpoint, the Balance Bot does not need to summarize everything that came before it, but successfully builds on it. To date, it is of the most useful kit for demonstrating how code, sensors, motors, and mechanical design become a robot.