Figure 2. Bumper-Bot schematic.
Figure 3. Control byte mapping.
inputs are the bumpers, we'll use them as an indicator to
start running the program.
IF bumpers = %11 THEN Wait_For_Start
bumpers = PINS & %00000011
are only connections for two. If you need to
control more than two motors, you can get
additional modules that will respond to different motor number sets. The standard unit
has a "-1" at the end of the part number.
Additional units are labeled "-2", "- 3", and so on.
To simplify our program, we can create a set of constants for each motor (left and right) and for each direction.
SYMBOL MLFwd = %11
SYMBOL MLRev = %10
SYMBOL MRFwd = %00
SYMBOL MRRev = %01
We start by scanning the bumpers — a very simple
task. You may wonder why I would devote a subroutine call
to what is, essentially, a single line of code. The answer is
optimism. Huh? Well, I'm pretty sure I'm going to do other
things with this core code, so I can simply update this section using different sensors without upsetting the rest of the
program. Okay, to collect the state of the bumpers we will
read the Stamp input pins and mask those that aren't used
Since our inputs are active-low, we'll get a value of % 11
in bumpers when there is no contact. If this is detected at the
start, we will loop back to Wait_For_Start until one or both
inputs change. Once a bumper input is detected, the program
delays for one second to let us get our hand out of the way.
And now we get to the heart of the program. Before we
do, let's look at the serial communication between the
Stamp and the Pololu Motor Controller. Communication
takes place in four-byte packets like this:
The reason for the apparent contradiction of the direction bit for the right motor is that the motors installed in a
robot are flipped 180 degrees of each other. In order to make
the robot go in one direction, the motors must spin opposite
each other. If both motors were going forward or reverse, the
robot would just spin in place (we use this fact for turning).
Okay, then, the rest of the code should be easy to
understand and it's fairly modular, so we'll go through it a
section at a time.
IF bumpers = %11 THEN Accelerate
speed = SpdMin
BRANCH bumpers, (Back_Out, Right, Left)
SEROUT SOut, Baud, ($80, $00, control, speed)
The first byte of the packet is a sync byte and will
always be $80. The second byte identifies the device type
and will be $00 for motor controllers. The third byte — control — identifies the motor number and direction (more in a
second), and finally, the fourth byte holds the speed (0- 127).
The control byte holds the motor direction in bit 0 (1 =
forward, 0 = reverse) and the motor number affected by the
command in bits 1-6 (see Figure 3). It may seem odd that
there are six bits (0-63) for the motor number when there
The purpose of the main loop is to scan the sensors
and BRANCH to the code section that handles robot direction control. The first check is for a bumper,s value of % 11
which means no sensor contact. When there is no sensor
contact, we will continue forward and accelerate if not
already at top speed. When a bumper input is detected, the
SMC02 will be reset to stop both motors, the robot speed
will be reset to its minimum, and BRANCH is used to
select the object avoidance code.
speed = speed + SpdRamp MAX SpdMax
SEROUT SOut, Baud, ($80, 0, MLFwd, speed)
SEROUT SOut, Baud, ($80, 0, MRFwd, speed)