ClusterBot — First Test Run of the Arduino Robot

GGG ·
  • #arduino
  • #robot
  • #motor-driver
  • #tutorial

Every robot build has a moment where you stop adding things and just run it. ClusterBot’s moment: no sensors, no obstacle avoidance, no autonomous behavior — just a sequence of pre-programmed moves to confirm the motors, driver, and code are all working together.

The test sequence runs through forward motion, a few spins, a turnAround() subroutine, a stretch of backward movement, and one hard brake. Simple enough that if anything goes wrong, it’s obvious what to fix.

This build is from 2012, when the channel was still MeanPC.com — same Lonnie, same garage, same workbench.

What the test covers

ClusterBot is driven by a Toshiba dual H-bridge motor driver (the same TB6612FNG used in later builds) controlled by an Arduino. The motion subroutines — forward(), backward(), rotateLeft(), rotateRight(), turnAround() — each set the direction pins and PWM on both motor channels. Having them as named functions rather than inline pin writes makes the test loop readable:

void loop() {
  forward(200);
  delay(2000);
  turnAround();
  forward(200);
  delay(1000);
  backward(200);
  delay(2000);
  hardBrake();
  delay(3000);
}

Nothing happens between hardBrake() and the next forward() call except a 3-second pause. Then the whole sequence repeats.

Hard brake vs. rolling stop

The interesting one is hardBrake(). On the TB6612FNG, two different stop behaviors are available depending on how you set the direction pins:

Rolling stop (coast): set both PWM outputs to 0, or set STBY low. The motors lose drive and the robot coasts to a stop under friction and inertia. This is the equivalent of putting a car in neutral.

Hard brake (short-circuit brake): set AIN1 and AIN2 both HIGH simultaneously (and BIN1/BIN2 both HIGH). This connects both motor terminals to the same voltage level, creating a short-circuit path through the motor windings. The back-EMF generated by the spinning motor has nowhere to go and acts as a braking force. The robot stops noticeably faster than a coast.

void hardBrake() {
  digitalWrite(AIN1, HIGH); digitalWrite(AIN2, HIGH);
  digitalWrite(BIN1, HIGH); digitalWrite(BIN2, HIGH);
  analogWrite(PWMA, 0);
  analogWrite(PWMB, 0);
}

The TB6612FNG datasheet describes this as the “brake” mode in the input logic table. It’s not electrically harmful — the motor driver is designed to handle it — but it does produce more heat than coasting and puts more mechanical stress on the drivetrain. For a lightweight robot like ClusterBot, it’s perfectly fine and gives a satisfying sharp stop.

What’s next

With the basic motion confirmed, the next stage is adding sensing. ClusterBot gets an HC-SR04 ultrasonic sensor and obstacle-avoidance code — making decisions about which direction to turn based on what the sensor returns, rather than following a fixed script.

The code structure for that follows directly from the motion subroutines already written: read the sensor, decide on a direction, call the appropriate subroutine. The test-run code is the foundation it all builds on.

References and further reading

Watch on YouTube