Introduction
While upgrading one of my Mini-Sumo robots, I found that sensor
placement and orientation can have a big impact on your final results. This article will discuss the problems
I ran into, trouble-shooting, and solutions.
Time to Upgrade
Mini-Spat has competed in 6 PAReX events, as well as several demos at
swap meets, high schools, and colleges. In other words, there's a lot of mileage on the little guy. During
the Nov. 2003 event it died twice in competition, and in the Nov. 2004 event, there were a few times when it
lost it's mind and wandered the ring aimlessly. The original circuit board was a low-profile wire-wrap board.
With the extremely short wraps I was concerned about it's reliability and decided to upgrade to a PCB.
Upgrade Woes
The PCB was finished and mounted to the robot. There were no software
changes made, except swapping the left and right servos, due to PCB routing issues. Fired up the robot and
watched it act just like it did with the old board, in other words, a robot possessed. Since the PCB seemed
to be correct, and nothing else had changed, I started looking at what I had done in software, trying to
figure out what went wrong.
Basic Trouble-Shooting
The basic problem was the robot was seeing things that weren't there.
When Mini-Spat drops, it's suppose to move forward, then start spinning in a circle looking for the opponent.
If there's nothing in range, it should just keep spinning. Most of the time it wouldn't even make one full
turn before wandering off in search of a ghost. Other times it would work fine for several runs.
By inserting some breakpoints in the code, I would stop the robot
when it thought it saw something, and flash the LED to tell me which sensor was acting up. Turns out the
right range sensor, a Sharp GPD012, was at fault. Further investigation showed that two of the three
connector pins had broken solder joints! Ahh problem solved!! A quick fix with a soldering iron and it was
back on the ring, failing exactly the same way. Insert your favorite expletive here!
Digging Deeper
Well at least I found the intermittent problem. Most Mini-Sumo's don't
have a display on them so it can be hard trying to figure out what's going on sometimes. I have a diag
routine which can blink an LED to show me an 8-bit sensor value, but you can't use it while the robot is
running. I guess the ideal interface would be a wireless link to a PC, then you could receive all kinds of
data to see what's going on. Well those links aren't cheap so I fell back on the RS-232 link that I had
brought over from the original board. A long 2-wire cable connects the robot to the laptop, but it's still
not practical, even on the 30" ring. Since the failure was a range sensor, I did all kinds of tests without
the motors running, and the sensor performed perfectly.
Ok, since this is an analog sensor, maybe the motors are
generating some electrical noise and hosing things up. Putting the robot on blocks and running the motors
during the tests, made no difference, the sensors worked as expected. The only thing left was to monitor the
sensors while the robot was running normally. To do this without the cable attached, I would save the sensor
readings to RAM, and then connect the cable and dump the data to the laptop.
I had about 250 ram locations to use and as fast as the sensors are
updated, it would fill in about 38ms. So I once again set the robot to stop when it saw something and send me
the last 250 readings. What I saw was quite interesting, the left sensor read a 0 or 1 the entire log. The
right sensor varied from 0x20 to 0x28, before hitting my 0x2C threshold and stopping. The 0x2C is about the
length of the ring, so I would "see" things in the ring, but didn't care about what laid beyond. If I did the
same test with the motors off I got readings just like the left sensor, nothing greater then 2. If I ran the
motors on blocks, again the readings were good. I changed out the sensor and again had no changes. So the
actual motion of the robot had something to do with it. |
