Sensor Mounting Techniques
Sensor Mounting Techniques
Sensor Mounting Techniques
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.
Sensor Orientation
Somewhere along the line a thought hit me, the only difference between the
two range sensors was they were mounted 180° from each other. This was
done so both connectors faced inward and kept the wiring neat. In case
you're not familiar with this type of sensor, it has an IR emitter on one
end and an IR receiving matrix on the other end. The right sensor has the
emitter on the down side, shooting upward, while the receiver is on the
upper side looking slightly downward.
Here is the orientation of the sensor on the left side of the robot.
And here is the sensor orientation on the right side, the one acting up.
Could the sensor be seeing reflections
off the actual arena surface? There was just enough extra wire to allow me
to rotate the right sensor such that the receiver was now on the bottom side,
looking slightly up, just like the left side. A quick run and a log dump
showed perfect readings, no noise or junk, or whatever was going on.
Apparently whatever the right sensor was seeing would only occur while the
robot was moving, probably a reflection of overhead lights or sunlight through
the windows and off the arena surface, even though the surface is flat black.
Conclusion
Rather then leave both sensors mounted vertically, I think I will make a new
bracket and mount the sensors horizontally like I did with FlatSpat. In this
manner the sensor won't see anything from above or below and hopefully be
more reliable.
How did it work for 5 or so events without failing? A look back over my
code changes shows that at some point I had changed the range threshold
from 0x30 to the current 0x2C. I suspect the reflections rarely gave a
reading greater then 0x30, so I never saw the problem. There was one time
we had it running outdoors at a swap meet, and it did act up a lot. May
have been the same problem.
So at the next event, look for Mini-Spat's new eyes, it will be looking for
FlatSpat, Zorro, and Mr. Happy!!
Posted by Kelly Small at
10:16 AM
|
Comments (0)