Stamp
When the robot isn't bumping into things, it will be
allowed to accelerate. The speed is increased up to the
SpdMax constant by the value set in SpdRamp. We can
control the acceleration by modifying SpdRamp, the
delay time, or both.
Our biggest chunk of work will come when we run
head on into an object; this is indicated by activity on both
bumpers. What we'll want to do is back up, turn out, and
then start again.
Back_Out:
SEROUT SOut, Baud, ($80, 0, MLRev, speed)
SEROUT SOut, Baud, ($80, 0, MRRev, speed)
PAUSE 250
GOSUB Reset_SMC
SEROUT SOut, Baud, ($80, 0, MLFwd, speed)
SEROUT SOut, Baud, ($80, 0, MRRev, speed)
PAUSE 500
SEROUT SOut, Baud, ($80, 0, MRFwd, speed)
GOTO Main
This simple program uses a fixed turn time which will, of
course, require adjustment for each robot's specific mechanics (wheel size). A bit of interest can be added by randomizing this delay beyond a specified minimum; this will make the
robot look slightly more organic in its behavior.
Turning left or right based on a single bump input is
very easy. The motors already been stopped, we simply
have to reverse the motor opposite the active sensor, and
then proceed forward again.
Right:
SEROUT SOut, Baud, ($80, 0, MRRev, speed)
PAUSE 200
GOTO Main
Left:
SEROUT SOut, Baud, ($80, 0, MLRev, speed)
PAUSE 200
GOTO Main
F
o
r
E
l
e
c
t
r
o
n
i
c
s
Once again, the size of the wheels on our robot will
affect how quickly it spins so we may need to adjust the
delay timing. Remember that we can "tune" the robot's
behavior by adjusting movement delays and speed values.
One note is that — depending on the size and weight of your
robot — you may need to adjust the SpdMin constant. Some
robots will need just a little more oomph to get started.
And there you have it; a simple "bumper bot" using
the BS1 — and only about half the code space at that.
What this means is that we have
ample room to add different
NUTS & VOLTS
E
v
e
r
y
t
h
i
n
g
"behaviors" to the robot. Let's take
a look at one such behavior.
Go to the Light ...
In nature, there are animals
that seek light (like moths to a
flame). We can mimic this behav-
ior in a robot, and, when we do, we call the robot a photovore. As our eyes detect light, we can use a photocell to
detect light levels for the robot. By using two sensors, we
can compare the light levels of each and determine the
direction the robot should move to seek the light.
Figure 4 shows the connection of a single photocell to
the BS1 that will be read with the POT function (we'll need
two of these circuits for our robot "eyes"). Note that the
configuration of the RC components is different that those
used with the BS2's RCTIME function. The reason for this
is that POT actually does more than RCTIME. The POT
function charges the capacitor by taking the specified pin
high for 10 milliseconds. It then starts a timer and actively discharges the capacitor by taking the pin low momentarily, then changing it to an input and checking to see if
the capacitor voltage has dropped below the pin's switching threshold. Scott Edwards wrote a very detailed description of POT versus RCTIME back in Column #15 (May
1996 — If you don't have the issue, you can download the
column as a PDF from the Nuts & Volts website).
In order to experiment with photovore code, I created
a test program. I will leave it to you to fold it into your
robot. The reason I created an experiment program to
share here is that I want to encourage you to do the same
thing with your projects. Yes, I am a very big proponent of
knowing the outcome of a project (having a specification), but we don't have to get there in one step. I frequently get requests for assistance from youngsters who are
just starting out and trying to solve everything at once.
I'm like a broken record and will continue to suggest that
we work with intermediate or experimental programs
before "going for the gold."
Okay, so what do we want to do? Knowing that the
more light on the photocell will cause its reading to fall, we
will read both sensors and move in the direction of the
smallest reading. That's the broad stroke. What we'll find,
however, is if our logic remains that simple, the robot will
be too sensitive and will appear "twitchy." We solve the
twitch by adding a threshold to the readings; that is, the
difference between the two readings must exceed a certain
threshold before we actually move. This helps accommodate differences in components and smoothes things out.
Finally — and I only learned this after running the program a while — we need to accommodate the sensors being
subjected to conditions where the readings will fall to zero.
Due to the component values used, this can happen in total
darkness or when the sensor is bombarded by bright light (swamped).
Before we get into the code,
we need to run a calibration program to determine the scaling factor
required by the POT command. Like
RCTIME, POT reads a 16-bit value
but it will scale it to 8-bits for the program. The idea is to set the scaling
factor such that the maximum value
FEBRUARY 2004
Figure 4. Photocell circuit for the BS1 POT function.
30
