Differences

This shows you the differences between two versions of the page.

Link to this comparison view

madoverlord:projects-battlebot [2016/10/04 14:42] (current)
Line 1: Line 1:
 +====  (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 <A HREF="​http://​www.inttek.net/">​Inttek</​A>,​ 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
 +<A HREF="​../​robots/​tournament.t.html">​can be read here</​A>​.
 +
 +
 +
 +
 +
 +
 +
 +
 +
 +
 +=== 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
 +<A HREF="​http://​www.legalword.com/​Hazard1b.html">​Hazard</​A>​ 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 <A HREF="​http://​www.ifirobotics.com/">​IFI Robotics</​A>​. ​ 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 <A HREF="​http://​www.parallaxinc.com/">​Basic Stamp</​A>​ 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 ===
 +
 +
 +
 +<TABLE BORDER=0 CELLPADDING=6 CELLSPACING=0 ALIGN=RIGHT><​TR><​TD VALIGN=TOP><​TABLE BORDER=0 CELLPADDING=0 CELLSPACING=0 ALIGN=RIGHT><​TR><​TD VALIGN=TOP><​html><​a href="​http://​media.madoverlord.com/​Lg/​DSC007/​DSC00715.JPG"><​img src="​http://​wiki.animeigo.com/​MO/​Sm/​DSC007/​DSC00715.jpg"></​a></​html>​
 +
 +</​TD></​TR></​TABLE></​TD></​TR></​TABLE>​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! ===
 +
 +
 +
 +<TABLE BORDER=0 CELLPADDING=6 CELLSPACING=0 ALIGN=RIGHT><​TR><​TD VALIGN=TOP><​TABLE BORDER=0 CELLPADDING=0 CELLSPACING=0 ALIGN=RIGHT><​TR><​TD VALIGN=TOP><​html><​a href="​http://​media.madoverlord.com/​Lg/​DSC006/​DSC00691.JPG"><​img src="​http://​wiki.animeigo.com/​MO/​Sm/​DSC006/​DSC00691.jpg"></​a><​a href="​http://​media.madoverlord.com/​Lg/​DSC006/​DSC00692.JPG"><​img src="​http://​wiki.animeigo.com/​MO/​Sm/​DSC006/​DSC00692.jpg"></​a></​html>​
 +
 +<​html><​a href="​http://​media.madoverlord.com/​Lg/​DSC006/​DSC00693.JPG"><​img src="​http://​wiki.animeigo.com/​MO/​Sm/​DSC006/​DSC00693.jpg"></​a><​a href="​http://​media.madoverlord.com/​Lg/​DSC006/​DSC00694.JPG"><​img src="​http://​wiki.animeigo.com/​MO/​Sm/​DSC006/​DSC00694.jpg"></​a></​html>​
 +
 +<​html><​a href="​http://​media.madoverlord.com/​Lg/​DSC006/​DSC00695.JPG"><​img src="​http://​wiki.animeigo.com/​MO/​Sm/​DSC006/​DSC00695.jpg"></​a></​html></​TD></​TR></​TABLE></​TD></​TR></​TABLE>​
 +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<​TABLE BORDER=0 CELLPADDING=6 CELLSPACING=0 ALIGN=RIGHT><​TR><​TD VALIGN=TOP><​TABLE BORDER=0 CELLPADDING=0 CELLSPACING=0 ALIGN=RIGHT><​TR><​TD VALIGN=TOP><​html><​a href="​http://​media.madoverlord.com/​Lg/​DSC007/​DSC00733.JPG"><​img src="​http://​wiki.animeigo.com/​MO/​Sm/​DSC007/​DSC00733.jpg"></​a><​a href="​http://​media.madoverlord.com/​Lg/​DSC007/​DSC00734.JPG"><​img src="​http://​wiki.animeigo.com/​MO/​Sm/​DSC007/​DSC00734.jpg"></​a></​html>​
 +
 +<​html><​a href="​http://​media.madoverlord.com/​Lg/​DSC007/​DSC00735.JPG"><​img src="​http://​wiki.animeigo.com/​MO/​Sm/​DSC007/​DSC00735.jpg"></​a><​a href="​http://​media.madoverlord.com/​Lg/​DSC007/​DSC00736.JPG"><​img src="​http://​wiki.animeigo.com/​MO/​Sm/​DSC007/​DSC00736.jpg"></​a></​html>​
 +
 +<​html><​a href="​http://​media.madoverlord.com/​Lg/​DSC007/​DSC00737.JPG"><​img src="​http://​wiki.animeigo.com/​MO/​Sm/​DSC007/​DSC00737.jpg"></​a><​a href="​http://​media.madoverlord.com/​Lg/​DSC007/​DSC00738.JPG"><​img src="​http://​wiki.animeigo.com/​MO/​Sm/​DSC007/​DSC00738.jpg"></​a></​html>​
 +
 +</​TD></​TR></​TABLE></​TD></​TR></​TABLE>​
 +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.
 +
 +
 +
 +
 +
 +<​TBAR,​03/​19/​02 - Bruce the Battery Boy>
 +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<​TABLE BORDER=0 CELLPADDING=6 CELLSPACING=0 ALIGN=RIGHT><​TR><​TD VALIGN=TOP><​TABLE BORDER=0 CELLPADDING=0 CELLSPACING=0 ALIGN=RIGHT><​TR><​TD VALIGN=TOP><​html><​a href="​http://​media.madoverlord.com/​Lg/​DSC007/​DSC00722.JPG"><​img src="​http://​wiki.animeigo.com/​MO/​Sm/​DSC007/​DSC00722.jpg"></​a></​html>​
 +
 +</​TD></​TR></​TABLE></​TD></​TR></​TABLE>​
 +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 ===
 +
 +
 +
 +<TABLE BORDER=0 CELLPADDING=6 CELLSPACING=0 ALIGN=RIGHT><​TR><​TD VALIGN=TOP><​TABLE BORDER=0 CELLPADDING=0 CELLSPACING=0 ALIGN=RIGHT><​TR><​TD VALIGN=TOP><​html><​a href="​http://​media.madoverlord.com/​Lg/​DSC007/​DSC00716.JPG"><​img src="​http://​wiki.animeigo.com/​MO/​Sm/​DSC007/​DSC00716.jpg"></​a></​html>​
 +
 +</​TD></​TR></​TABLE></​TD></​TR></​TABLE>​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 ===
 +
 +
 +
 +<TABLE BORDER=0 CELLPADDING=6 CELLSPACING=0 ALIGN=RIGHT><​TR><​TD VALIGN=TOP><​TABLE BORDER=0 CELLPADDING=0 CELLSPACING=0 ALIGN=RIGHT><​TR><​TD VALIGN=TOP><​html><​a href="​http://​media.madoverlord.com/​Lg/​DSC007/​DSC00724.JPG"><​img src="​http://​wiki.animeigo.com/​MO/​Sm/​DSC007/​DSC00724.jpg"></​a></​html>​
 +
 +</​TD></​TR></​TABLE></​TD></​TR></​TABLE>​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,<​TABLE BORDER=0 CELLPADDING=6 CELLSPACING=0 ALIGN=RIGHT><​TR><​TD VALIGN=TOP><​TABLE BORDER=0 CELLPADDING=0 CELLSPACING=0 ALIGN=RIGHT><​TR><​TD VALIGN=TOP><​html><​a href="​http://​media.madoverlord.com/​Lg/​DSC007/​DSC00723.JPG"><​img src="​http://​wiki.animeigo.com/​MO/​Sm/​DSC007/​DSC00723.jpg"></​a></​html>​
 +
 +</​TD></​TR></​TABLE></​TD></​TR></​TABLE>​
 +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<​TABLE BORDER=0 CELLPADDING=6 CELLSPACING=0 ALIGN=RIGHT><​TR><​TD VALIGN=TOP><​TABLE BORDER=0 CELLPADDING=0 CELLSPACING=0 ALIGN=RIGHT><​TR><​TD VALIGN=TOP><​html><​a href="​http://​media.madoverlord.com/​Lg/​DSC007/​DSC00717.JPG"><​img src="​http://​wiki.animeigo.com/​MO/​Sm/​DSC007/​DSC00717.jpg"></​a></​html>​
 +
 +</​TD></​TR></​TABLE></​TD></​TR></​TABLE>​
 +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 ===
 +
 +
 +
 +<TABLE BORDER=0 CELLPADDING=6 CELLSPACING=0 ALIGN=RIGHT><​TR><​TD VALIGN=TOP><​TABLE BORDER=0 CELLPADDING=0 CELLSPACING=0 ALIGN=RIGHT><​TR><​TD VALIGN=TOP><​html><​a href="​http://​media.madoverlord.com/​Lg/​DSC007/​DSC00705.JPG"><​img src="​http://​wiki.animeigo.com/​MO/​Sm/​DSC007/​DSC00705.jpg"></​a><​a href="​http://​media.madoverlord.com/​Lg/​DSC007/​DSC00706.JPG"><​img src="​http://​wiki.animeigo.com/​MO/​Sm/​DSC007/​DSC00706.jpg"></​a></​html>​
 +
 +<​html><​a href="​http://​media.madoverlord.com/​Lg/​DSC007/​DSC00707.JPG"><​img src="​http://​wiki.animeigo.com/​MO/​Sm/​DSC007/​DSC00707.jpg"></​a><​a href="​http://​media.madoverlord.com/​Lg/​DSC007/​DSC00708.JPG"><​img src="​http://​wiki.animeigo.com/​MO/​Sm/​DSC007/​DSC00708.jpg"></​a></​html>​
 +
 +<​html><​a href="​http://​media.madoverlord.com/​Lg/​DSC007/​DSC00709.JPG"><​img src="​http://​wiki.animeigo.com/​MO/​Sm/​DSC007/​DSC00709.jpg"></​a><​a href="​http://​media.madoverlord.com/​Lg/​DSC007/​DSC00710.JPG"><​img src="​http://​wiki.animeigo.com/​MO/​Sm/​DSC007/​DSC00710.jpg"></​a></​html>​
 +
 +</​TD></​TR></​TABLE></​TD></​TR></​TABLE>​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<​TABLE BORDER=0 CELLPADDING=6 CELLSPACING=0 ALIGN=RIGHT><​TR><​TD VALIGN=TOP><​TABLE BORDER=0 CELLPADDING=0 CELLSPACING=0 ALIGN=RIGHT><​TR><​TD VALIGN=TOP><​html><​a href="​http://​media.madoverlord.com/​Lg/​DSC007/​DSC00744.JPG"><​img src="​http://​wiki.animeigo.com/​MO/​Sm/​DSC007/​DSC00744.jpg"></​a><​a href="​http://​media.madoverlord.com/​Lg/​DSC007/​DSC00739.JPG"><​img src="​http://​wiki.animeigo.com/​MO/​Sm/​DSC007/​DSC00739.jpg"></​a></​html>​
 +
 +</​TD></​TR></​TABLE></​TD></​TR></​TABLE>​ 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<​TABLE BORDER=0 CELLPADDING=6 CELLSPACING=0 ALIGN=RIGHT><​TR><​TD VALIGN=TOP><​TABLE BORDER=0 CELLPADDING=0 CELLSPACING=0 ALIGN=RIGHT><​TR><​TD VALIGN=TOP><​html><​a href="​http://​media.madoverlord.com/​Lg/​DSC007/​DSC00740.JPG"><​img src="​http://​wiki.animeigo.com/​MO/​Sm/​DSC007/​DSC00740.jpg"></​a><​a href="​http://​media.madoverlord.com/​Lg/​DSC007/​DSC00741.JPG"><​img src="​http://​wiki.animeigo.com/​MO/​Sm/​DSC007/​DSC00741.jpg"></​a></​html>​
 +
 +<​html><​a href="​http://​media.madoverlord.com/​Lg/​DSC007/​DSC00742.JPG"><​img src="​http://​wiki.animeigo.com/​MO/​Sm/​DSC007/​DSC00742.jpg"></​a><​a href="​http://​media.madoverlord.com/​Lg/​DSC007/​DSC00743.JPG"><​img src="​http://​wiki.animeigo.com/​MO/​Sm/​DSC007/​DSC00743.jpg"></​a></​html>​
 +
 +</​TD></​TR></​TABLE></​TD></​TR></​TABLE>​
 +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<​TABLE BORDER=0 CELLPADDING=6 CELLSPACING=0 ALIGN=RIGHT><​TR><​TD VALIGN=TOP><​TABLE BORDER=0 CELLPADDING=0 CELLSPACING=0 ALIGN=RIGHT><​TR><​TD VALIGN=TOP><​html><​a href="​http://​media.madoverlord.com/​Lg/​DSC007/​DSC00766.JPG"><​img src="​http://​wiki.animeigo.com/​MO/​Sm/​DSC007/​DSC00766.jpg"></​a><​a href="​http://​media.madoverlord.com/​Lg/​DSC007/​DSC00767.JPG"><​img src="​http://​wiki.animeigo.com/​MO/​Sm/​DSC007/​DSC00767.jpg"></​a><​a href="​http://​media.madoverlord.com/​Lg/​DSC007/​DSC00768.JPG"><​img src="​http://​wiki.animeigo.com/​MO/​Sm/​DSC007/​DSC00768.jpg"></​a></​html>​
 +
 +<​html><​a href="​http://​media.madoverlord.com/​Lg/​DSC007/​DSC00769.JPG"><​img src="​http://​wiki.animeigo.com/​MO/​Sm/​DSC007/​DSC00769.jpg"></​a><​a href="​http://​media.madoverlord.com/​Lg/​DSC007/​DSC00770.JPG"><​img src="​http://​wiki.animeigo.com/​MO/​Sm/​DSC007/​DSC00770.jpg"></​a><​a href="​http://​media.madoverlord.com/​Lg/​DSC007/​DSC00771.JPG"><​img src="​http://​wiki.animeigo.com/​MO/​Sm/​DSC007/​DSC00771.jpg"></​a></​html>​
 +
 +</​TD></​TR></​TABLE></​TD></​TR></​TABLE>​ 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, <TABLE BORDER=0 CELLPADDING=6 CELLSPACING=0 ALIGN=RIGHT><​TR><​TD VALIGN=TOP><​TABLE BORDER=0 CELLPADDING=0 CELLSPACING=0 ALIGN=RIGHT><​TR><​TD VALIGN=TOP><​html><​a href="​http://​media.madoverlord.com/​Lg/​DSC008/​DSC00817.JPG"><​img src="​http://​wiki.animeigo.com/​MO/​Sm/​DSC008/​DSC00817.jpg"></​a><​a href="​http://​media.madoverlord.com/​Lg/​DSC008/​DSC00818.JPG"><​img src="​http://​wiki.animeigo.com/​MO/​Sm/​DSC008/​DSC00818.jpg"></​a><​a href="​http://​media.madoverlord.com/​Lg/​DSC008/​DSC00819.JPG"><​img src="​http://​wiki.animeigo.com/​MO/​Sm/​DSC008/​DSC00819.jpg"></​a></​html>​
 +
 +</​TD></​TR></​TABLE></​TD></​TR></​TABLE>​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 <TABLE BORDER=0 CELLPADDING=6 CELLSPACING=0 ALIGN=RIGHT><​TR><​TD VALIGN=TOP><​TABLE BORDER=0 CELLPADDING=0 CELLSPACING=0 ALIGN=RIGHT><​TR><​TD VALIGN=TOP><​html><​a href="​http://​media.madoverlord.com/​Lg/​DSC008/​DSC00820.JPG"><​img src="​http://​wiki.animeigo.com/​MO/​Sm/​DSC008/​DSC00820.jpg"></​a><​a href="​http://​media.madoverlord.com/​Lg/​DSC008/​DSC00821.JPG"><​img src="​http://​wiki.animeigo.com/​MO/​Sm/​DSC008/​DSC00821.jpg"></​a></​html>​
 +
 +<​html><​a href="​http://​media.madoverlord.com/​Lg/​DSC008/​DSC00822.JPG"><​img src="​http://​wiki.animeigo.com/​MO/​Sm/​DSC008/​DSC00822.jpg"></​a><​a href="​http://​media.madoverlord.com/​Lg/​DSC008/​DSC00823.JPG"><​img src="​http://​wiki.animeigo.com/​MO/​Sm/​DSC008/​DSC00823.jpg"></​a></​html>​
 +
 +</​TD></​TR></​TABLE></​TD></​TR></​TABLE>​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.
 +
 +
 +
 +
 +
 +<​html><​a href="​http://​media.madoverlord.com/​Lg/​DSC008/​DSC00824.JPG"><​img src="​http://​wiki.animeigo.com/​MO/​Sm/​DSC008/​DSC00824.jpg"></​a><​a href="​http://​media.madoverlord.com/​Lg/​DSC008/​DSC00825.JPG"><​img src="​http://​wiki.animeigo.com/​MO/​Sm/​DSC008/​DSC00825.jpg"></​a><​a href="​http://​media.madoverlord.com/​Lg/​DSC008/​DSC00826.JPG"><​img src="​http://​wiki.animeigo.com/​MO/​Sm/​DSC008/​DSC00826.jpg"></​a><​a href="​http://​media.madoverlord.com/​Lg/​DSC008/​DSC00827.JPG"><​img src="​http://​wiki.animeigo.com/​MO/​Sm/​DSC008/​DSC00827.jpg"></​a><​a href="​http://​media.madoverlord.com/​Lg/​DSC008/​DSC00828.JPG"><​img src="​http://​wiki.animeigo.com/​MO/​Sm/​DSC008/​DSC00828.jpg"></​a><​a href="​http://​media.madoverlord.com/​Lg/​DSC008/​DSC00829.JPG"><​img src="​http://​wiki.animeigo.com/​MO/​Sm/​DSC008/​DSC00829.jpg"></​a><​a href="​http://​media.madoverlord.com/​Lg/​DSC008/​DSC00830.JPG"><​img src="​http://​wiki.animeigo.com/​MO/​Sm/​DSC008/​DSC00830.jpg"></​a><​a href="​http://​media.madoverlord.com/​Lg/​DSC008/​DSC00831.JPG"><​img src="​http://​wiki.animeigo.com/​MO/​Sm/​DSC008/​DSC00831.jpg"></​a><​a href="​http://​media.madoverlord.com/​Lg/​DSC008/​DSC00832.JPG"><​img src="​http://​wiki.animeigo.com/​MO/​Sm/​DSC008/​DSC00832.jpg"></​a><​a href="​http://​media.madoverlord.com/​Lg/​DSC008/​DSC00833.JPG"><​img src="​http://​wiki.animeigo.com/​MO/​Sm/​DSC008/​DSC00833.jpg"></​a><​a href="​http://​media.madoverlord.com/​Lg/​DSC008/​DSC00834.JPG"><​img src="​http://​wiki.animeigo.com/​MO/​Sm/​DSC008/​DSC00834.jpg"></​a><​a href="​http://​media.madoverlord.com/​Lg/​DSC008/​DSC00835.JPG"><​img src="​http://​wiki.animeigo.com/​MO/​Sm/​DSC008/​DSC00835.jpg"></​a><​a href="​http://​media.madoverlord.com/​Lg/​DSC008/​DSC00836.JPG"><​img src="​http://​wiki.animeigo.com/​MO/​Sm/​DSC008/​DSC00836.jpg"></​a><​a href="​http://​media.madoverlord.com/​Lg/​DSC008/​DSC00837.JPG"><​img src="​http://​wiki.animeigo.com/​MO/​Sm/​DSC008/​DSC00837.jpg"></​a><​a href="​http://​media.madoverlord.com/​Lg/​DSC008/​DSC00838.JPG"><​img src="​http://​wiki.animeigo.com/​MO/​Sm/​DSC008/​DSC00838.jpg"></​a><​a href="​http://​media.madoverlord.com/​Lg/​DSC008/​DSC00839.JPG"><​img src="​http://​wiki.animeigo.com/​MO/​Sm/​DSC008/​DSC00839.jpg"></​a></​html>​
 +
 +
 +
 + 
 +
 +
 +
 +
 +