Mini-Sumo Bugdozer’s Border Bug

During the 2000 CIRC (Central Illinois Robotics Club) Sumo Robotics Competition, Bugdozer stalled during several matches. Because Bugdozer was a sitting duck at the edge of the Sumo ring, the opponent was easily able to push out Bugdozer during at least one round.

On the way home from the event, I kept running scenarios and symptoms through my head. The wheels stopped moving when Bugdozer entered the white border (warning track) in a parallel motion. All of the stalls occurred when entering the edge from Bugdozer’s right side, but I didn’t know until later that the direction was extremely significant.

Bugdozer tires weren’t spinning or slipping, nor were the motors hot upon lifting up Bugdozer. This tends to rule out a stall from the scoop jamming into the surface or poor traction from the white paint being slippery.

The red LED emitters were still lit and Bugdozer moved after leaving the ring. This tends to rule out a power failure, CPU hang, or reset.

Bugdozer did rock and move a little, every few seconds. But the overall progress was nominal and sporadic.

“Think Like The Bot”

Bugdozer has the following priorities:


  1. Border line sensor triggered - change direction
    1. Both front and rear sensors triggered
    2. Just rear sensor triggered
    3. Just a front sensor triggered
  2. Object seen - attack
  3. No object seen - search


For example, if any of Bugdozer’s line sensors are triggered, Bugdozer moves to escape the boundary even if an attack would otherwise be underway.

Front Line Sensor Handling

Because the stalls only occurred on the white edge and NOT within the central black battlefield, my suspicions turn to the handling of the border sensor data.

Bugdozer has four front line sensors. The robot refers to an internal data table to turn the wheels away from the edge of the ring depending on which of the four phototransistors detects the gloss white border.

For example, if all four front detectors are triggered, Bugdozer backs up and then rotates. If the leftmost front detector is triggered, Bugdozer rotates right and then rolls forward right.

Bugdozer had no problems handling head on edge detections, and turned away efficiently and quickly both in game-day test trials and during the battles.

Rear Line Sensor Handling

If no front border is detected, but the rear sensor engages, the robot automatically switches to full forward motion. It is unlikely that Bugdozer would ever be purposely backing up, but in case of a push, this makes sure the motors are driving in the correct direction and with the correct effort.

Front and Rear Line Sensor Handling

But what happens when both the front and rear detectors trigger?? A post-contest code review reveals a boo-boo.

Originally the robot was coded to pick a random direction (left or right) and spin away. At some point I was concerned that this code wouldn’t work, so I removed it all to start again. I programmed an always-spin-right turn as a placeholder until I had time to concentrate on a legitimate solution.

     bra    AttackDoneSet

     db      "Line both  ",EOS
     dw      PWMMoveSpinRight,$0200           ; 0.5 second * !1024 ($400) at 1024 hertz

And then... I forgot to go back and write the final code.

When Always-Turning-Right Can Be Bad

If one or more of Bugdozer’s right-front phototransistors detect the white border, then Bugdozer appropriately spins left to avoid falling off the edge. Spinning left makes sense if Bugdozer is directly facing the border, since a forward-left movement might roll Bugdozer forward off the edge.

Bugdozer detects edge on right and spins left

Bugdozer detects edge on right and spins left

In the above case, Bugdozer is not facing perpendicular to the edge, but instead parallels it. Although the left spin still works, it has the effect of moving the rear of the robot onto the border.

If only the rear sensor detects a border, then the robot will move forward. Great! But if Bugdozer’s right side parallels the border, then a left spin causes both the front and rear detectors onto the edge at the same time.

Bugdozer detects edge front and rear and spins right

Bugdozer detects edge front and rear and spins right

Because Bugdozer wasn’t programmed with alternatives, this causes Bugdozer to always spin right until the rear sensor is out of the edge. Unfortunately, the right spin returns the front sensors back into the edge, causing Bugdozer to go back to the left-spin state.

Bugdozer continues to spin left and spin right over and over. There isn’t forward or reverse movement, just subtle trades of rotating in place.

These illustrations are exaggerated. Bugdozer actually rotates the tiniest amount necessary for the detectors to change states and then rotates a tiny amount the other way until the detectors change states again. All of the processes and routines function normally, the infinite loop is in the real world, not code. If not for slippage and variations in paint and lighting, Bugdozer wouldn’t appear to move at all.

(Or perhaps because the motors weren’t turned on for very long they never received enough current to actually move. Only when the code took longer somewhere else in the microcontroller did a motor receive enough juice to turn a little.)

Why Didn’t The Motors Overheat?

To execute a left rotation, the right motor is turned on and the left motor is turned off. The reverse is true for right rotation. Because the motors switched between being turned on and off very quickly, each was on only half the time.

Bugdozer can easily run for the entire three-minute round at full power to both motors. Running the motors at 50% duty cycle (each on half the time) uses less power.

Thoughtful Solution

To fix the line sensor problem, Bugdozer now has a table of movements to invoke when both front and rear sensors detect the edge. The simple patterns are designed to flow correctly as each sensor moves off or on the white border along the edge of the Sumo ring.

Indeed, it turns out that the stalling during the 2000 mini-Sumo competition was just a missing software case in Bugdozer’s motion decision-making processes.

Maybe this wouldn’t have been a problem if I had done some more testing after making changes. Let’s take a look at an effective way to test a sumo robot by videotaping the matches...