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.
Bugdozer has the following priorities:
(highest)
(lowest)
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.
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.
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.
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.
AttackLineFrontAndRear:
lda #ATTACK_FRONT_AND_REAR_LINE
bra AttackDoneSet
AFrameFrontAndRearLine:
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.
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
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
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.)
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.
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...