Ever since BattleBots came on TV, James and Alex have been bugging me to build one.
The problem is, however, that I'm a software guy. I have absolutely zero aptitude
with things mechanical.
Fortunately for me (since the kids were threatening violence), the good folks
at Inttek, my wireless ISP, hearing of my dire
plight, introduced me to a friend of theirs, Bruce Mobley, a local BattleBot
competitor. Bruce was looking to put together a team to build and fight a high-level
This page is my diary of the design and construction of "Evil Twins."
Our adventures at the May 2002 tournament
can be read here.
03/03/02 - First Meeting
We held an initial meeting to determine overall strategy. My initial thought had been
to build some sort of modular robot with weapons and other components that could be
quickly swapped based on what opponent we were facing. This is a strategy that seemed
to open up a loophole in the rules.
However, Bruce brought along some sketches of a new design he'd been toying
with, a new "dual spinner" configuration. Imagine if you will a circular robot with
a couple of drive wheels and a spinning weapon. The shell of the robot doesn't rotate,
but a spinning weapon projects from a slot.
Now imagine two of these robots, with a central connector that links them together.
So there's a left module (spinner), a central module (connector, with wedges and perhaps
a secondary weapon), and a right module (spinner). The whole thing moves as a unit.
This design has numerous advantages. First, we can counter-rotate the weapons
so we don't have gyroscopic stability problems in the plane of movement (they cancel
out!), but we still get gyroscopic stability if someone tries to flip us. Second,
depending on which way we run the weapons, they'll act to either suck the enemy bot
towards us, or kick it away.
In addition, the design has a lot of redundancy. With 4 drive motors (2 on each
side) and two weapons motors, a lot has to stop working before the bot can't fight
anymore. By keeping the armor fixed and running the weapon through a slot (using a big
ring bearing to mount it) we gain a lot of protection. We can also make the robot
very low to the ground, about 5 inches high. This is going to be a middleweight so
we have to figure that if we're successful, we're going to run into
Hazard sooner or later. Looks like
Hazard's blade is about 5" high. Maybe we can slip under it. Even if we can't, we can
probably design the bot so that most of the energy of a major weapon hit glances off.
We decide to go with Bruce's basic design, and research improvements. I've heard
that many of the teams are using digital radio controls these days that are programmable.
Programming, hey, that's what I do!
03/04/02 - Control Freaks
Research quickly determines that the control system to go with is the Isaac system
by IFI Robotics. It's the same system as used
in the First Robotics competitions.
The system consists of an operator interface that you plug joysticks into, a radio
modem connection, and a controller that sits inside the robot. Buried inside the controller
is a Basic Stamp microcontroller. Basically (ahem),
you write a program on the Basic Stamp that controls various speed controllers and relays
based on the joystick readings relayed from the operator interface.
The Basic Stamp control language, PBASIC, is pretty primitive but it gets the job
done and should be sufficient for the task, if a bit of a pain to use.
One thing that becomes clear is that superior driving skills make all the difference
in BattleBots. We don't have the time to become expert drivers, so my idea is to use the
software running inside the robot smart enough to handle a lot of the low-level details of
driving. In other words, the human tells the bot what it wants to do, and the bot figures
out how to do that.
Watching BattleBots, I am struck by how often the robots just barely fail to hit
what they are aiming at. This is clearly because the drivers are reacting too slowly,
and also because the robots themselves can't manuever fast enough. Part of this problem
is just physics, these bots have a lot of inertia. But clearly, if we can give the bot
a faster "reflex speed" than the opponent, it's a huge edge.
This means that the reflexes have to onboard. And that means that the robot has
to be able to sense where the opponent bot is. If we can do that, we can program in
attack and defense reflexes. For example, have the robot make minor course adjustments in
the last few feet of an attack run so it hits the enemy dead center, or conversely, have
the robot actively evade.
If we can do this, we'll give our opponents a severe case of "Stormtrooper Syndrome," ie:
"They can't hit, and we can't miss."
Doing the research, the two basic choices for sensors are infra-red and ultrasonic.
It quickly becomes clear that IR sensors are too short-range. Ultrasonics can sense out
to about 3 meters, which seems to be more than enough. Found some for $25 each that
can trivially interface to a Basic Stamp processor.
My initial thought is to put 4 sensors on each module, two pointing mostly frontwards,
two pointing mostly to the rear. The sensors are pretty directional, in an arc of about 20-30
degrees, so we'll need to point them in slightly different directions. This will also give us
some overlap right in front and behind the robot, which will help it home in on the enemy.
The trick will be blending the sensor inputs with the control inputs from the
operator. I'm thinking that something that gives more authority to the sensors as the bot
approaches the target is the way to go.
03/05/02 - The Curse of the PC
Being a Mac guy, I'm not too pleased to learn that the IFI and Basic Stamp stuff is only
programmable on PCs. Maybe if I use Virtual PC I'll be able to use my beloved Macs.
Am inquiring with IFI to see if two robot control modules can talk to a single
operator interface. If so, we could design the robot so that if the two modules
get ripped apart, each can continue to fight on its own. Since the operator interface
can read 4 joysticks, this isn't an issue. And it would look seriously cool if it
Redundancy is a big issue in the bot design. We want to be able to survive
loss of individual components -- even an entire module. Bruce plans to do power
cross-feeds so that loss of a battery pack in a module doesn't take out that entire side.
I'm thinking that we might be able to rig up a circuit so that either robot control
module can control all the components, so we have redundancy on that level as well.
Regarding the link between the two modules, we're batting around several ideas.
One is a wedge module with hinges so that the modules can flex up and down a bit. We
want some flexibility so that if one module gets lifted off the ground, the wheels of
the other module will still be able to do something.
A radical concept would be to connect the two sections with some sort of slinky
connection, perhaps a garage door opener spring. This would look totally weird but
if we could get it to work, it'd be cool. Serious control problems, however.
Protecting the cables that run between the modules is an issue. One cute trick
I've heard of is running them through a tube that is free to rotate. That way if it gets
hit by a killsaw, the tube just rotates.
After much deliberation, I decide to yank my PC-based DVD player (the only PC I
own, thank god) and use it as the programming platform. I have plenty of joysticks
with lots of buttons, so that's not a problem.
Did a lot of research on suppliers, in particular sources of cheap titanium.
Weight is always an issue on Battlebots.
Ordered the Isaac 16 from IFI, speed controllers, cables, and some ultrasonic
detectors. About $2000.00 all told. Maybe I should have one of my companies sponsor
03/06/02 - Strategy
Long discussion with son James about strategy. I had him look at all the other bot designs
that have appeared in Battlebots and figure out what our strengths and weaknesses are against
Idea develops to have some hardpoints on the central connector that let us swap
in some utility weapons, instead of a fixed wedge. Wedge will be on a hinge so if we get
inverted, it just flops down.
Bruce reports that he can't seem to find a source for titanium tubing for the
frame of the robot. He is leaning towards 18-8 stainless steel, similar in strength but
twice the weight. He's also checking out batteries.
03/07/02 - Toys by Mail
The IFI Robot Controller arrives.
Print Print Print! Read Read Read! Play Play Play!
Windows sucks! No, I take it back, it blows!
Bruce is making minor design changes, he's decided on the stainless, and increased
the size of the frame octagons so that they more completely protect the circular weapons
03/09/02 - Of Men And Motors
Bruce reports that he's managed to pick up some reconditioned 24V DeWalt drills. These
babies are very popular with BattleBot builders, lots of torque.
I've been playing with the IFI controller and the ultrasonic rangefinders, but I
can't get them to work. All hope abandon, ye who enter Tech Support hell.
My nice fancy digital joysticks don't work with the IFI operator interface, it needs
the old-style analog sticks. Foo. Have ordered a couple of sticks to test them out.
Despite all these problems, have made good progress on a first cut of the driving
program, and am getting over the learning curve on the Basic Stamp. It's kind of a
throwback to the good old days of tiny processors, the silly thing has 26 bytes of variable
03/11/02 - Frugality and Frustration
Found a source for DeWalt replacement parts, quite cheap. Why do I think that half of their
"replacement" motors end up in BattleBots?
Turns out that I can't interface the ultrasonic rangefinders directly to the robot
controller. This is because the Basic Stamp doesn't actually talk directly to the output
pins of the controller; instead, it talks to another microcontroller and that one handles
the IO. So I can't twiddle the lines fast enough to trigger the rangefinders, or read the
results fast enough.
Looks like I'm going to have to get a second Basic Stamp processor board, and use
that to talk to the ultrasonics, then find a way to get it to talk to the Basic Stamp inside
the robot controller. Careful perusal of the documentation leads me to the belief that
I might be able to do this using the program/debug port on the robot controller.
I have now memorized my credit card number...
Joysticks have come in, and I've been playing with them. They are 2-axis with a
throttle and 4 buttons. Should work well.
03/13/02 - Sensational Results
Got the second basic stamp w/breadboard (aka the "Board of Education", how droll). Plugged
a sensor into it, it works great.
Bruce is busy buying parts and waiting on his frame componentry.
03/14/02 - More Progress
A soldering party results in me having 4 working ultrasonic sensors. Looks like if I query
them sequentially, I can get about 4-5 updates a second, a bit more if I get fancy and
prioritize the pings so that sensors that have something in range get checked more frequently.
Annoying problem: you can only query one sensor at a time, because the PBASIC command that
reads the length of a pulse can only do it for a pulse on one pin at a time.
Ordered some more ultrasonic sensors and spares.
03/16/02 - It is Alive!
Bruce has a single module testbed running, using the single frame component he's gotten so far. He
brings it over.
We lash it up to the robot controller and start to play with it. Some software
teething problems, not unexpected. It's very twitchy, and this is made worse by the fact that
the drive motors aren't matched; one is running backwards because of how they are mounted.
This problem may cancel itself out when we get two modules running, as long as they are mirror
images of each other. I may also be able to do some compensation in software.
Have placed a rewrite of the driving code, with all the tunable parameters put into
arrays and vectors, on the top of my To-Do list. We need to be able to control a lot of the
motor parameters, in particular their behavior when they reverse.
Also, not happy with the joysticks, they
are overly sensitive.
Watched BattleBots in the evening. We are going to have to have a contingency for
bots that are even lower-slung than we are. Our weapon is about 4-5" off the ground.
Perhaps some blades for the weapons that are L shaped and hang down a bit?
We've had to abandon the idea of putting two robot controllers in the bot, because
it's going to be expensive, and also we'd have the problem of coordinating them. We can't
use the Program/Debug serial ports because we need that for the Ultrasonics. Oh well, it
was cute, but not essential. We'll stick the robot controller into one of the weapons modules,
and if the bot does get chopped in half, we'll have a mode in the program that runs that
module as a standalone.
It's going to be tight in there, though.
Suggested to Bruce that we route the cables through the lower structural octagon and
central wedge struts to keep them protected. Since we'll have 2 or 3 of these, we can run
duplicate power lines plus control lines for the motors in separate conduits. So if one of
the conduits does get chopped, we only lose 1 drive motor on each side.
03/17/02 - Code Crunching
Rewrote the joystick/motor controller code, it's very table-based, and I added a lot more
tuneable parameters. Alas, won't know if it really works until we have a full 2-module
bot to play with.
The code that converts
the joystick inputs to motor control values is kind of cute. There are two
inputs, how fast we want to go forward and back, and how fast we want to turn left
and right. I map these into a "Drive Box", starting with a point representing the
rotational axis of the robot. I move the point up to represent going forward,
and down to represent going backwards, then draw a line through the point to
intersect the two edges.
The angle of the line depends on how fast I want turn the robot. A horizontal
line means no turning at all, and a 45-degree line means a maximum rate turn.
As previously mentioned, where the line intersects the edge of the box determines
the speed of the outboard motors. The speed of the inboard motors on a module can also
be read off the line, it's a straight geometric calculation.
One thing I have to be careful about is not to let any drive motor value go out
of bounds; too high or too low. When this happens, I scale the intersection points of
the line so that the larger one is just inside the box. This results in the robot doing
as much of what I want it to as it can. For example, as shown in one of the sketches,
if I'm going full speed forward and command a full turn, the outer wheel will continue
going full speed forward and the inner wheel will go to half speed, so I'll both turn
and continue to go forward.
The really cute feature of this technique is that I am not limited to setting the
axis of rotation of the robot in the center of the bot! I can set it to be anywhere, such
as on one of the outer wheels. I can even, if I were so inclined, have the rotational axis
outside the actual physical robot!
This permits me to do some really cute things. For example, while we usually want
the robot to spin around the central module, it will often be the case in combat where we'd
like to use one module as a pivot point and spin to whack the other one into our victim.
The problem will be coming up with an intuitive control system that makes it easy
for the driver to command these modes.
Had the thought that an airplane-style yoke might be a more natural control
method. Push to go forward, pull to go back, turn to turn. Onward to eBay!
03/18/02 - What we've got here is a failure to miscommunicate
Managed to get the Board of Education Basic Stamp to talk to the Basic Stamp inside the robot
controller using the program/debug ports. It's a bit of a hack, the problem is that there
is no handshaking on the serial connection; when the BOE starts talking, the RC had better
Fortunately, the Basic Stamp can be told "Listen for a particular byte, then read in
N bytes" with a timeout. This can be used to implement packet communication. On the BOE
side, it reads all the ultrasonics, converts the range into a number from 0-14, and stuffs
the 8 ranges into 4 bytes. It then sends $FF + the 4 bytes.
The Robot Controller listens for $FF and then reads 4 bytes. Since the ultrasonic range numbers
are never 15 ($0F), no byte of data can be $FF, so if the RC sees $FF, it knows it has to
be the start of a packet.
I also start hunting for a crummy windows laptop on eBay. As long as the clock speed
isn't measured in kilohertz, it ought to be enough.
Bruce says that the NiCad battery packs that came with the DeWalt drills probably aren't
going to fit the bill. He's decided to go with some custom NiMH packs instead.
03/21/02 - Priority on Pings
Rewrote the sensor code so that it pings ultrasonic sensors that are reporting nearby objects
more often than distant sensors, on the theory that the closer something is, the more we're
going to be interested in it.
Talked to the lower school headmistress at the kids' school about using their parking
lot for driving practice. Apparently, they have no problem with killer robots. Good!
03/22/02 - Grr!!
Got a bunch of Basic Stamp components for the final ultrasonic processor board, only to find out
that I needed to order something different. #@^&*@&@!!
Bruce at one point showed
me an electromagnet he had thought to use to lock his
older robot to the BattleBox floor (it's plate metal) and this gave me an evil idea.
Something perhaps like a skinny flat nose that projects out from the central connector,
almost like a flipping arm, but heavy and with the electromagnet in the
base. The idea being that when faced with a spinner, we
can point the nose at him, lock it to the floor of the box, and we
don't do much moving when he impacts on the nose -- he does.
No idea if it is feasable.
Working on connectors for the ultrasonics so as to reduce the labor if one of them
gets munched and needs to be replaced.
Also got all 10 ultrasonic sensors wired up. I'm using CAT-5 cable, since the solder
holes on the sensors are tiny.
03/23/02 - Yokes and Stuff
Bought a CH Products Yoke on eBay, looks like it'll be an interesting input device. Also
bought a Maxx yoke as a backup. Made yet another visit to Radio shack for components to
build an auxiliary control box with switches and dials. No idea what I'll use it for yet,
but we're going to need something to command things like inverted mode,etc.
Bruce is working hard, but still waiting for some metal to be bent, alas. Also, he
needed to do some essential maintainance on both car and girlfriend.
03/31/02 - Battle Damage
Alex, my youngest, had a fight with the Monkey Bars. The Monkey Bars won. Broken arm.
In surgery ASAP, 2 pins inserted to keep things where they should be. He's a tough kid.
My first attempt at wiring all the ultrasonic units together using some 12-pin
connectors (to make the cable routing easier to do, and easier to repair), failed dismally.
The CAT-5 wires had to be soldered into the pins in the connectors and don't deal with
04/01/02 - Wringing the Wiring
Switched to dual-row barrier blocks for the
ultrasonic interconnects. The CAT-5 seems to
tolerate being connected to screw terminals well, and the cables from the barrier block
to the Basic Stamp processor board can be thicker multi-stranded, with big crimped terminals.
I come up with a cute idea that might let me poll all the ultrasonics at the same
time. No idea if it will work, but I wire up the Basic Stamp so I can test it. If it doesn't
work the alternate wiring system will still work with my old code, 1 line change required.
04/04/02 - I am a Programming God!
Got the ultrasonics to work simultaneously! Theoretical maximum speed is about 30 updates
a second, though the computational overhead will cut this down considerably.
I am so cool! And how I did it is so deviously evil.
The Basic Stamp has 16 i/o pins. Each can be set to be an input or an output. For
my 8 sensors, I need 8 outputs (triggers) and 8 inputs (reading the length of a pulse).
the Basic Stamp lets me access these pins individually, or in groups
of 4, 8 or 16. My original design alternated pins, so pin 0 would be a trigger, pin 1 an
echo pulse read, and so on. But when I wired up the board, I changed this to pins 0-7
being the read lines, and pins 8-15 being the trigger lines.
When I first attempted simultaneous ultrasonics, my problem was that the Basic Stamp
wasn't fast enough. I couldn't loop reading the various pins and storing the results
fast enough. But with the new configuration, I can trigger all of the ultrasonic modules
with a single instruction (writing $FF to the upper byte of the i/o word), and I can read
the state of all of the echo lines in a single instruction (reading the lower byte).
Even doing this, I can't do a loop reading in the echo lines and looking at their
bits; that processing still takes too long. So instead what I do is loop waiting for any
of the echo bits to go high (they all will go high within a very short time), and then
I just read in the state of the echo bits into an array of bytes, as fast as I can.
When this is done (I read the echo bits 14 times, because I only need to return a
value from 0-14 for each sensor), I can count the number of 1 bits in each bit-column in
the array, and get my sensor value!
Don't you love it when things
work the very first time? I wired up all 8 sensors
in a laundry basket for testing, looks weird, but works fine.
Calibrating the sensors, I find that each 1 bit in a bit-column represents about .45
inches. This means that 14 samples represents about 6 inches. Well, I certainly want my
sensors to have a longer range than this, but that's an easy fix. If I want the first sample
to cover a range from 0 to 5 inches from the robot, I'll simply have the code read the
first sample byte 11 times. The first 10 samples effectively get ignored. I can use this
technique to scale the range of each possible returned value, we may want the robot to
be more sensitive to objects that are closer.
I may change the code so that it ORs the sensor bytes with the previous sample bytes
in each group, this will change the calibration since it'll take longer, but may generate
better results. But no matter what, I've got something working.
Bruce is almost finished with the first module, he's got the top frame components and
cross-members. We'll test it on the weekend.
04/07/02 - Second Test Run
After the ceremonial
lunch at Chili's, we get together for a test run. The bot is still
very twitchy, but the yoke much improves controllability. Again, it's too early to tell
how the final bot will perform, we need the second module.
We have a bizarre glitch that takes an hour to track down. When we spin the robot
clockwise, just as we get to maximum spin speed, the robot goes berserk and reverses direction.
I suspect a control problem, and we do a lot of code debugging.
Turns out the problem isn't in my code, but in the Robot Controller itself. The
Basic Stamp talks to another microcontroller and tells it what to do by sending out a
packet, just like my ultrasonic code does. In fact, it uses a packet header of 2 $FF
bytes. Sound familiar?
The problem is that when we go to maximum spin, the output value for the first
speed controller goes to $FF. And it's the first byte after the $FF FF packet header.
The other microcontroller gets confused and ignores the data for the first speed controller,
so it misreads all the data, and gets bogus information.
The fix, of course, is to not allow the speed controller values to ever hit $FF.
Pity this isn't documented anywhere!
Here are some pics of the module we tested. The orange donut is the weapons motor,
it drives the inner part of the ring bearing. When that sucker spins up, it makes a noise!
04/12/02 - The Yoke's on Me
In my search
for the perfect input device, I have amassed
a collection of Joysticks and Yokes that fills a bookcase, but I think I've found one now that
might do quite nicely. It's the G-Force Plus Yoke. It's not nearly as sturdy as the CH Products
Yoke, but it's dirt-cheap and it has two trigger and two thumb buttons, pure binary, not encoded,
so you can press more than one of them at a time. This will permit more natural command combinations.
Also arriving today was the POS (Piece of S...) Windows Laptop I bought on eBay, we're going
to need something to do last minute programming tweaks on at the competition. Processor speed is
apparently measured in kilohertz, but it was very cheap and does the job.
04/14/02 - Evil Twins vs. ToolBox of Terror!
Spent some time yesterday
wiring up a more convincing mockup of Evil Twins for sensor testing.
Spent the afternoon in bed after wife thrashed me for stealing two of
her laundry baskets. Spent the evening hacking together the first working version of the sensor
Decided after much though that rather than send raw sensor values to the main processor,
I should do as much preprocessing as possible in the sensor processor. This will slow down the number
of sensor polls I can do every second, but speed up the number of times the main robot controller
processor can go through its loop. Obviously, I want to match these up as much as possible.
Reevaluated what information
I actually need from the sensors. It actually boils down to two numbers: the speed and direction of
twisting I need to do in order to make the bot face directly at the opponent, and the speed and direction
at which I should retreat from the opponent.
Consider: if I'm attacking then the driver will be telling the bot to go forward or backward,
all the sensors need to do is tell the robot which way to twist to home in. If I'm retreating, I
want to at all times face the enemy robot -- exactly the same as when I'm attacking -- but I also
want to know how fast to back away. The closer I am the fast I back off, and when I get out of
range, I stop backing off. The end result is that the robot will hover at a set distance from
If I scale these values exactly as I scale the equivalent yoke inputs (currently as a number
from 0-100, with 50 being neutral), then I only need to send 2 bytes to the main processor (ok, 4 actually
when you count header and checksum...). The code in the main processor can then, if appropriate,
blend the sensor command suggestions with the driver command suggestions.
This will allow us to have some interesting bot behaviors. Consider the case where defense
mode is on, the sensors tell the bot to retreat, but the operator tells it to advance. The bot will
advance until the sensor retreat intensity overcomes the driver commands, and the net result will be
that the bot hovers a bit closer to the enemy. This will let the driver select a range he wants
The sensor code turned out to be a bit simpler than I anticipated. The main complication was
handling the case where the sensors detect multiple objects (say, one in front and one to the rear).
But it turns out there is a cute simplification that looks like it will work and is easy to compute.
What you do is this: for both twist and movement, you compute values for both the front and the rear
sensors. If the sign of the values are the same (for example, if they both want you to twist clockwise,
or move backwards), you pick the one of greater magnitude. If the signs are different, you take the
one with the greater magnitude and reduce it by the magnitude of the lesser.
Another nice simplification that makes for redundancy is that when I'm doing the left/right
comparisons for orientation, I just use the smaller of each pair of sensor values. So I can lose
one out of each pair of sensors and still have some functionality. Similarly, when doing the forward/reverse
comparisons, I just use the lowest value of all the front and rear sensors, so I can lose 3 out of
4 sensors and, while I won't have orientation control, I'll still be able to maintain range.
After I got all the code working, I took it outside for testing vs. our house OpFor bot, Toolbox
of Terror. The numbers, at least, look good, and I'm getting about 10-12 cycles a second. I'll want
to try and optimize the code if I can, but so far, so good.
04/15/02 - A Taxing Day
Lots of running around. Got all the photos and documents and sent in the application for the
tournament. Then back home to slave over a hot monitor, integrating the sensor processor and
the main drive processor. From what I can tell (it's hard because there's no easy way to get
telemetry out of the Robot Controller when I'm using the Program/Debug port as the sensor
communications port), it seems to be somewhat working. Won't be able to tell until we run it
in the robot.
Decided on a relatively simple button control method. If both the trigger and thumb
button on one side of the yoke are pressed, then the robot pivot point moves to that side,
and the trigger and thumb on the other side control attack/defense modes. Otherwise, any
trigger commands attack, and any thumb commands defense, with conflicts resolving in favor
Am considering using some of the extra switches on the switchbox I built as enable/disable
switches for some of the modes, to deal with the problem of stuck switches on the yoke, as I said,
it's pretty clunky. Also, if I lose both sensors in a quadrant, the bot won't be able to orient
properly, so I need to be able to disable that. Also considering using a potentiometer as a
sensitivity control for ranging.
Finally, need to think about other possibilities for command modes using the yoke buttons.
Currently, I'm only using 9 out of the possible 16 combinations (none, attack, defense, left pivot, left pivot + attack,
left pivot + defense, right pivot, right pivot + attack and right pivot + defense)
Bruce reports that the extra DeWalt motors he needs are out of stock, but worst case we
can run the full robot with 2 drive motors, at least for testing purposes. Meanwhile he is
keeping himself amused with large plates of titanium armor.
04/22/02 - Slow Progress
Lots of puttering around in the code over the last week or so. Bruce expects the motors any day now
and is starting to get the titanium panels cut and welded. He is also installing the robot controller
and sensors into the bot. I've been writing test code to help speed up the testing process, as well
as doing tests of the speed of various PBASIC commands. The plan is that once we've got the code
working properly in "easy to read and understand" form, I'll start working on speed hacks to improve
the cycle time of the main code.
As always we are concerned about the weight. It's going to be tight.
04/26/02 - Motoring on ahead
have finally come in. In the meantime, Bruce has made good progress with construction.
With any luck, we'll be testing this weekend.
Total height of the bot is about 6" to the top of the wheels. And that deceptively thin
plate that joins the two modules is springy titanium.
It's going to be a tight fit, and looks like we're going to just scrape in under the
04/28/02 - !#&@#*@ Gremlins!
Bruce delivered the bot to me yesterday, and I spent most of the day tweaking the software while
he attended a wedding. Confirmed an annoying problem he was having with a motor that seemed
to intermittently cut out and then start up again when put into reverse at particular speeds. Also noted a few other
squawks regarding the sensors. I'm starting to worry that the motor noise is going to drown
Anway, after he recovers from the wedding, Bruce comes over and we start debugging the
bot. The motor problem drives us nuts! It's intermittent, and sometimes it spreads from one
motor to another. We start tracking it down, swapping motor controllers, controller cables,
everything. Every time we track it down to a single component, it starts working again, and
then stops. ARGGGHHHH!!!
We strip the bot down to a test case, take the whole damn thing apart, and it works fine.
Then we start rebuilding the bot component by component. When we put the top octagonal member
back on (which has the robot controller on it), it fails. Bruce starts to lift the component
off again, and it starts working again.
It finally dawns on us. It's RFI. The robot controller is too close to one particular
motor, and when that motor hits a particular speed, its RFI noise on the controller frequency is
enough to kill the radio link, which causes the bot to shut down, and the motors to go into neutral.
And that of course kills the RFI, so the bot reactivates.
Even more bizarrely, sometimes the RFI only seems to cause one motor to go nuts. The
others seem to ride through it. This might be due to some of the motor controllers being set
to coast on neutral and some not; in the confusion when we discovered the cause I didn't
In any case, once we knew what the problem was, we could go about attacking it. We lugged
the battlebot about 100 feet away from the transmitter, put my wife's car in front of it,
ran a motor, and mapped the interference. The result, much to Bruce's dismay, is that we have to
move the robot controller into the plate that connects the modules. Given that we could only run
one motor because of we didn't have motor controller cables long enough to let us run them all
while waving the robot controller around, we agreed we have to be very conservative about RFI
and move the antenna as far away from the motors as possible.
Bruce had hoped to keep the plate as a very low, very flat mini-ramp segment, and was very
attached to the design. The fact that he'd spent a whole day drilling the #*# titanium might
have had something to do with that. But alas, the laws of physics, in this case the concept of
inverse-square, are merciless. So we have to redesign the central plate.
On the bright side, this will make the wiring a lot simpler, and will make the two
modules symmetrical, which has its own advantages. They'll also be a lot less crammed. A little
checking determined that the robot controller can be divided into the radio module and the
connector plate (with ribbon cables between them), so the central plate can be pretty thin, maybe
about 2 inches thick. Also, the central location will be better for shock resistance.
In other news, turns out the weight limit for middleweights is 120 lbs, so we may be able
to add our secret weapon.
05/02/02 - Garage Kit
David McGough of Inttek dropped by Bruce's place with a spectrum analyser, and much to
everyone's surprise, the problem is NOT RF interference. It appears to be a magnetic
coupling situation between the drive motor and either an internal inductor
or transformer in the robot controller unit. A shield as simple as a steel BandAid
box completely cures the problem, even with the controller attenuated by
means of a steel pot completely encasing the antenna unit. It would have
been nice if IFI had used a ferrous box instead of a plastic one!
Well, that's a load off our minds! Even though we have a solution,
Bruce is far enough along moving the controller to the central connector
that we're going to go ahead with it. It just makes life a lot simpler in
With the the controller duct taped into position, we did some driving tests
in my garage. The bot seems pretty responsive, and a lot of the fancy rate control /
filtering I'd programmed in turns out not to make that much difference. One cute thing
I did was add code that pauses motors in neutral for 1 control cycle when they pass
through the neutral point. I may end up making that 2 cycles, we'll see.
We soon realized that we don't need an inverted driving mode for the bot. If
it's inverted, the normal controls work fine; it'll just be a matter of putting some
guide marks on the bot to help us keep oriented.
One thing I'm thinking of playing with is making the driving controls non-linear,
to give more fine control at low speeds. It's something I'll have to play with carefully.
We also tested the ultrasonics. 6 out of the 8 are working, 2 seem to be dead,
and 2 pairs are reversed. The ones that work work well, even with the drive motors
going full tilt. But when we turn on the weapons motor, the ring bearing puts out
some serious decibels, and the ultrasonics misbehave. We're hoping that we can put
some sound-deadening paint or coating on the inside of the armor.
05/02/02 - Smokin!
Well, the extender cables came in (so we can divide up the robot controller) but the
gender-bender isn't the right thing and the cable orientation doesn't work either.
Did more research, found some crimp-on male IDE connectors, hope they'll do the
Bruce had good news/bad news. Good news, some armor components came in, and
they fit. Bad news: a motor controller caught fire, and it wasn't even connected to
anything at the time other than it's normal power supply. Weird. We may be able to
get a replacement but as time is of the essence I ordered another one ASAP.
05/04/02 - Yoke Hacking
the G-Force yoke has served us well, I've never
been totally happy with it. It doesn't have the control travel and smoothness of the CH
Products yoke. The problem with the CH Products yoke was the buttons; each one was
encoded as a 4-bit value using the 4 analog button inputs, and you couldn't press more
than one button at a time. The advantage of the G-Force was that it had thumb and trigger
buttons on each side of the yoke, and you could press them in different combinations at
the same time.
However, now that we have a decent control solution, I could risk hacking around
with the CH Products yoke to see if I could rewire it so that multibutton pressing was
a possibility. Upon opening it up, I found that all of the button inputs conveniently
feed into a small PC board that has one chip on it. This chip does the encoding.
Even better, the good folks at CH had conveniently labelled everything. After drawing
out a few diagrams and mapping out the traces on the PC board, out came the soldering
iron, and the chip was history. Then 4 simple jumpers connected the outer two buttons
on each side of the yoke to the output button wires. All done! We now have a CH yoke
with buttons the way we want them.
As the button assignments are a little different (I should have thought of that
and wired them up the same as the G-Force), I had to make a couple of 1-line changes in
the driver program to compensate. No biggie, and I've commented out the G-Force versions
so that, in a pinch, we can use the G-Force as a backup controller.
Also did a comprehensive review of the driving code, found a couple of minor
bugs, made some optimizations, and added the non-linear drive sensitivity changes.
Bruce reports that things are going well on his end. He's got some of the armor
on, and is working on making the wiring more robust. Still having a problem with two
of the ultrasonic sensors however. Hopefully when we get together tomorrow I'll be
able to get them working.
05/05/02 - The Fecal Matter has hit the Rotary Impeller
OK, it may be time to panic. Bruce did some weapons tests and the impact forces are so
strong that the ring bearing fractures at the bolt holes securing the tool steel to the
bearing. As you will recall, the inner part of the ring bearing is what spins.
We discuss a lot of possible fixes. The most obvious one is to machine a new
inner bearing ring out of steel (the regular bearing is aluminium); Bruce thinks he can
find some pipe of the appropriate size. We also consider reinforcing the bolts used to
attach the tool steel with epoxy, to try and spread out the impact load. Worst case,
we may either not be able to run the weapons at full speed, or accept that we are going
to have failures and bring spares.
Knowing that we have weapons problems may end up being a blessing in disguise,
however, if it causes us to think deeply about an alternate weapon. I'm thinking of a
relatively lightweight probe/wedge/hook on a pole in front of the bot, that can be used
to disrupt the opponent, get under him, and drag him around. We need to have a "Plan B"
in case the weapon dies.
I spend the rest of the day working on the drive code and the ultrasonics; turns
out that two of our transducers have indeed failed somehow. Lo and behold, I get the
darn thing working! It's a little jittery at first but adding some filtering calms it
down. I also identify a problem of crosstalk. Sometimes an echo pulse from the left
transducers bounces off the target and triggers the right transducers. Modifying the
code so that it alternates between the left and right sensors fixes this issue.
With the bot in defense mode, I chase it around the garage using a Rubbermaid
bin. It's really elusive, like herding sheep. If I corner it (literally!) it hovers
midway between the bin and the wall.
05/05/02 - A Carpenter I am not
Built a custom shipping box for the bot out of plywood today. It looks like a coffin.
Given the odds of winning the tournament, this seems appropriate.
Bruce reports success in finding new ring bearing material.
05/12/02 - Dr. Bruce's Amazing Quick Weight Loss Diet
I pop off to Washington in the last half of the week to audition for a TV show, Escape from
Experiment Island. Made it past the initial audition, so you never know.
Meanwhile, Bruce manages to get the new ring bearings made. On Saturday
we get together and split up the remaining work. Bruce has gotten all the parts he needs
and is doing the cleanup and fitwork. I make the cables that link the separated parts of
the radio, and do some radio tests. Looks like we'll be OK even if the antenna is buried
under a titanium skin but we plan on a lexan window anyway.
The new bearings seem very sturdy, and hold up under impact stresses, but they are
very heavy. Some vexing problems remain. The holes in the armor for the ultrasonics are too
small, so Bruce bores them out. This helps but doesn't totally cure a reflection problem.
On Sunday I bring over the company UPS digital scale, which I figure is probably more
accurate than Bruce's. Egad! We're at 126 pounds. The bot has to go on a diet. Dr. Bruce
to the rescue, as he finds better (and lighter) ways to keep the critical reinforcements he'd
earlier built into the structure. We cut the weapon down from 6 blades per side to 3, and
we'll go to 2 each if we have to - fortunately, at this point, most of the weapon mass is in the
bearing ring anyway.
We also find a more elegant way to armor the radio compartment. I even go searching for lighter
batteries for the radio and ultrasonic processor, and come up with lithium AA cels, which save
.15 pounds. An attempt at using 1/2 AA 6volt batteries doesn't have enough oomph, but I'm thinking
that if we really need it, two sets in parallel might do the trick, and save us another .15
pounds. Bruce thinks they are too wimpy, however; he'd prefer to drill out that weight rather
than risk battery failure.
We think we've come up with a solution to the ultrasonic problem, using plastic tubing
to guide the sound between the sensors and the exterior. It may even shield us a
bit from the amazingly loud noise of the weapon. Unfortunately, just as I got to test it, the
Ultrasonic BS2SX chip goes titsup. Home to get the spare, and write up this report.
PS: Turns out it was the chip, and not the Basic Stamp project board. Whew! I'd hate to have
to resolder all those damn wires this late in the game.
05/15/02 - The Hell of Shipping Robots
Bruce works 18 hour days getting the bot ready, and
finally, we're ready to box it up and ship it off. Only 2 days left so it's time to
risk UPS 2-Day.
When we get to UPS, our box is literally 1/4" under their size restrictions (whew)
but our 120 lb (cross fingers) bot + misc hardware + shipping container is 175 pounds!
Aeeeeiiii! We open the box, strip out everything but the bot itself, and remove the top
149.8 pounds. Breathing a sigh of relief, and counting ourselves over $300 poorer
in shipping charges, we take our leave before the UPS guys change their minds.