==== (Projects) ==== // 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 absolutel // === Birth of a BattleBot - A Destructive Diary === 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 BattleBot. 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 happens. 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 the robot! === 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 them. 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 bearing. === 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 space. === 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. Bugger! 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 be listening. 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 it gracefully. === 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). Conveniently,
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 processor code. 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 the enemy. 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 to maintain. 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 of defense. 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 === The motors
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 weight limits. === 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 them out. 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 check that. 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 === Yesterday,
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 the modules. 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 job. 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 === While
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 plywood cover. 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.