Encoder Front Page
SRS Home | Front Page | Monthly Issue | Index
Search WWW Search seattlerobotics.org

  k'nexbot.jpg (21929 bytes)

K ' N E X B O T   (K'NEX Robot Sumo) - PART 1
(c) 1999 Steven D. Kaehler

Project Overview


My name is Steven Kaehler.  I work as an electrical engineer at the Boeing Company in Seattle Washington.  My specialties are the design and use of instrumentation devices and systems (i.e. transducers, sensors, detectors, data systems and control systems) used to test airplane fuel systems.  Over the last fifteen years, I have learned a great deal about how to measure and control many different things, and have found the application of this knowledge quite useful in robotics.  I particularly like robotics because it brings together many technologies, including measurement and control, into a single cohesive system, and provides me with a lot of personal satisfaction pulling this off.

This is the first of a two-part article about my robot.  This article will present a high level overview of the design and construction while the next one will present the nitty-gritty details including the software.

I've dabbled in robotics as a hobby as far back as the mid seventies but didn't have much time after getting married, going back to school at night, buying a house, and starting a family.  However, I never lost interest in it and after an excessively long sabbatical from it, I revisited the hobby with earnest and vigor during the last two years after contacting and becoming involved with the Seattle Robotics Society (SRS).  As a result of this association and the infusion of enthusiasm I received, I have successfully designed and built a mini sumo robot.  This accomplishment exceeds anything I have done in the past in this hobby, and its success has really encouraged me and prompted me to write this article.

Over the years, I have observed that robotics is a multi-disciplined hobby, pulling together electrical (motors,actuators), electronic (controls, sensors, interfaces, microprocessors), mechanical (structural & drive systems, gearboxes), chemical (sensors & batteries), civil (terrain analysis, locomotion methods & technologies), architectural (structural & aesthetic elements), biological (behavioral, life simulation), software engineering (programming & PC's), and other sciences.  To be an expert in all these fields is rare if impossible, yet one is bound to encounter many of them in the course of building a robot.  This is where clubs like the SRS and others come in.  Collaborating with other people who share a common interest, who know certain disciplines, or who have "been there", allows a pooling of talents and ideas for everyone's benefit. Publishing articles about how things can be done captures for everyone ways under, over, or through the technical hurdles.

This article contain a synopsis of my efforts to build a robot.  There are links to pictures and interesting places related to the article.  Every attempt has been made to accurately present the information in this article.  Any omissions, errors, or misrepresentations are purely accidental and unintentional.


I share this experience with you in written word because I hope it will encourage anyone who wants to do this, but feels overwhelmed by the task of building a working robot, and because I enjoy doing it.  Let me say up front that I respect anyone who even attempts to build a robot.  My own experience has taught me this this is no trivial task.  In fact, when I consider how simple my machine is compared to some, and how much work it took to get it together, I am astounded.  Building a functioning machine from scratch or even a kit where hardware and software are successfully married can take a lot of time and determination (and sometimes money), but it can be done.

There are kits that can give you a head start, such as Lego Mindstorm, Parallax Growbot, and others (Mondotronics), but doing it on your own allows a much wider variety of options.  Unfortunately, along with this approach can come project stalling as one tries to decide which way to go.  In fact, one can go down many dead ends before finally achieving success with this approach.  No doubt many unfinished robots lie in dark corners gathering dust because of unsolved technical difficulties.  But even making the attempt (with or without success) is noteworthy, and if you are willing to stick it out, you can see it through to fruition.

I find the idea of creating a machine that reacts to its environment like a living creature intriguing.  It is a great challenge to deal with the complexity of the world using only a limited array of sensors, something we humans take for granted until we attempt to build such a "sensitive" machine.  Our bodies have a vast array of highly complex sensory systems and extraordinary processing capability.  One can't truly appreciates this until attempting to emulate it.

A robot's general responses to its sensors is usually well defined by programming, but sometimes, its exact behavior may not be known ahead of time, and things can happen (during contests, for example) that even the designer doesn't expect.  Also, with a large array of sensors and possible responses, the variety of a robot's behavior can seem almost "lifelike" since not all possible combinations may have actually been tested.  This behavior sometimes leads me to calling my robot "he" even though it has neuter gender because it is almost like a living pet and I have developed an affinity toward it.

Before I go on I must confess something important.  My robot, K'NEXBOT, which is the main subject of this article, was not actually ready to compete on contests day of last May due to many compounded and insurmountable "technical difficulties".  I am still proud of what was accomplished but cannot make any great claims about its capabilities or performance.  Not being in the contest was certainly disappointing for me because I had worked so hard for many months beforehand and put in some very long, late nights the two weeks prior to the contest.  I thought I might just make it, but I just couldn't quite pull things together even on the day of the contest, and so K'NEXBOT made a only one brief appearance in the tethered exhibition at the very end of the contest event.  I know many of you can identify with this.  Since the contest, I have done considerable work on it, and am confident that it is now ready for a real contest.  The upcoming SRS Robothon event planned for this fall should provide some much needed feedback on the robot's performance and possible improvements for next year's official sumo contest.

Somewhat off the subject, I have included a discussion about how the concepts of closed-loop control might be applied to robotics.  This short article explores the conceptual similarities between a robot and a control system and a collection of control systems.  It grew along with this article but isn't directly related to it.  I have included it simply as a thought-provoking vehicle.  Click HERE to read it if you're interested.


Starting a little over a year ago, just after the 1998 Northwest Robot Sumo Tournament (NWRST), I began research for the design of a mini (10x10cm, 500g) sumo robot able to compete in the May 1999 tournament.  Bill Harrison, president and founder of Sine Robotics, sponsors these events annually and continually encourages people to compete in them.  He sponsors workshops for building sumo robots and has built many types of robots including numerous sumos in all the smaller classes (500g, 1Kg, and 3Kg).  His enthusiasm and leading-by-example are highly contagious and after seeing last year's contest, I became inspired to give it a try.


The contest itself consists of a series of three-minute matches on an 80cm round, black, rubber-covered platform with a 2.5cm white perimeter ring where two qualifying robots try to push each other off.  The platform is elevated about an inch off the surrounding floor.  Since the ring stands about 3cm above the floor, going over the white line inevitably means falling off the edge.  The two robots begin on opposite halves of the ring anywhere behind one of two 20cm parallel gray lines located 10cm on either side of ring's center.  These starting lines are (or should be) invisible to the perimeter line sensors of the robots and are used only for setting the match up.  Five or more seconds after being started and released, the robots begin their battle.  They can move anywhere on the ring and may only touch the white line, since whoever crosses the perimeter line and touches the floor outside the ring first, loses. (SRS Rules)

One of the biggest challenges of this class of robot is incorporating enough "brains" and "brawn" into the mini-sized package to located and defeat your opponents.  Thanks to highly integrated processors and microcontrollers now available, "brains" aren't too much of a problem, but "brawn" requires powerful motors and batteries, and this means rapid weight gain.  So a delicate balance must be struck.

This class of robot typically doesn't move very fast, but are still quite interesting to watch and often amusing as they roam around the ring and lock horns as they battle each other for the match.  The enthusiasm of spectators is wonderful to watch as the little robots go at it.


It seems that all robots have names.  I suppose this is because, though they aren't really alive, they acquire an identity and a "life" as they come into existence.  Within the SRS this seems to be the case and everywhere else I have visited as well.  I suppose too that it's easier to talk about robots by being able to refer to them by name.  I think Bill Harrison has some of the most interesting names for robots I've ever heard.  So in keeping with this great tradition, I thought about the names I could give my robot for some time before settling on "K'NEXBOT" (short for K'NEX-based Sumo Robot).  The robot received this name in recognition of the fact that he is constructed primarily from K'NEX structural building components including a pair of K'NEX drive motors, and because no one else had used it.  Other hardware was added to hold the robot's components together, attach the various circuit boards, and enable the robot to fit within the contest's size and weight constraints.

The challenges in the beginning of this effort were deciding what product or kit to build upon, and then discovering a combination of pieces that would build the robot without exceeding the length, width, and weight limits. K'NEX pieces have metric dimensions but the joiners often extend beyond the ends of structural rods thus pushing the dimensions a few millimeters past the limits.  Also, the plastic used to make K'NEX is rather dense, making the pieces surprisingly heavy, so I had to carefully choose and minimize what was used.  Where I work I have access to precision digital laboratory scales and so was able to weigh components and K'NEXBOT as I built him.  He currently tips the scales right at 500g without any ballast.  This was not just a lucky break as I'll discuss later.


Someone might say that a true purist would scratch build everything on a robot.  No doubt some people have done this.  There was a time when this was the only option since kits just didn't exist for assembling robots in functional blocks (i.e. quickly plugging together frame, controller, sensors, motors, etc.) and good software development tools now commonly available just didn't exist.  Today most toy stores are filled with such a wonderful assortment construction kits and battery-powered toys that the creative builder can construct literally anything he or she can imagine.  Hacking these kits to make something truly unique, innovative, and autonomous only seems fitting and can be really fun.  To not take advantage of these engineering shortcuts would be to reinvent the wheel and waste the time and diligent efforts of some very ingenious toy makers.  After all, time is money and I certainly don't have infinite amounts of either, but I probably have more money than time and so would rather invest it where it will give me the greatest return.

The cost of K'NEX was less than Legos or other motorized kits I looked at, offered good flexibility and strength in structural design, had reasonably good-looking motors, and proved to be a moderately though not excessively expensive to use.  The choice of this particular product, though experimental and untested, did prove to be workable and I was able to get a operational machine to fit within the contest constraints.  Building a larger robot based on this product would be quite possible and an interesting challenge (a fire fighter perhaps?).

My kids benefited from this experiment too.  They love to play with K'NEX, and now thanks to this grand experiment, they have a great selection of K'NEX hardware, including two motors I had to buy them to replace the ones K'NEXBOT used.  Wouldn't you know that the new ones I got them are better than the ones I used on K'NEXBOT.  Needless to say, they were thrilled to get the "leftovers" from my robot-building exercise since K'NEXBOT didn't actually use many of the kits' pieces.  Now they want me to build them a controller that can be incorporated into the K'NEX so they can build their own robot.  Hmmm...could have interesting product marketing possibilities.


tether.jpg (32662 bytes)

K'NEXBOT was designed to compete autonomously, and if desired, by remote tethered control in robotic mini sumo contests.  Since I have not practiced tethered control very much, this would not show my best side, however the capability was already built into the robot, and I had an adaptable pennant from a prior project that required only minor rewiring.  The buttons permit the eight movements to be selected with a single button.  The top and bottom are forward and reverse. The diagonal buttons pivot forward and reverse to the left or right.  The side buttons spin clockwise and counterclockwise.  To connect the tether, the rainbow ribbon cable jumper that connects the I/O board to the BOTBoard is removed and the tether is plugged into the I/O board socket.  This feature adds remote control to the robot's capabilities, but I prefer to operate it autonomously since this most nearly emulates an artificial life form and is the most fun to watch.

In addition to sumo behavior, the robot can also function in "non-sumo mode" where it backs away from lines and contacted obstacles, and moves toward open spaces rather than pushing things as would be typical in a sumo contest.  This feature allows me to show off the robot without the benefit of a competitor or even a ring provided the floor color doesn't confuse the sensors.  Rest assured though, a companion is in the works.


motors.jpg (26956 bytes)

K'NEXBOT uses a pair of independently controllable K'NEX drive motors for locomotion.  These are simple permanent magnet DC motors built into gear boxes that accept K'NEX rods through their cores for drive shafts.  The wheels are 3.5" K'NEX rubber tires that have been "hogged out" on the inside to reduce their weight.  Front and rear "skids" provide balance on the two drive wheels which can be run forward or backward on command.  This drive control scheme permits eight different types of motion including forward and reverse pivoting and clockwise and counterclockwise spinning.  If the motors had been driven with a controllable PWM signal, even more combinations would be possible by running them at different speeds.


Line_Sensors.jpg (22877 bytes)

K'NEXBOT has four floor-facing optical sensors located on the bottom of its frame, near the four corners.  They detect the 2.5cm white line around the edge of the black circular contest ring.  The robot can touch this line but not cross over it, except when pushing an opponent.  The robot will scan for the opponent and if it doesn't find something, will wander around the ring, stopping at and then backing away from the white line and scanning again as it attempts to locate the opponent.  These sensors were built from opto interrupter-type sensors gear tooth counters by cutting the bridge between the phototransistor and the LED and attaching them side by side facing the same direction.  Instead of seeing the LED directly, the phototransistor now sees the reflection of the LED off of whatever surface they is facing.  This requires high contrast between the ring surface and the perimeter line to function properly.  The phototransistor outputs are conditioned to TTL-level signals prior to being fed to the microcontroller I/O port.

The rear sensors have pieces of exposed, developed color film negatives over them to block ambient light.  The front line sensors are located just ahead of the wheels out near the ends of the front blade.

K'NEXBOT can also operate on a white surface with a black boundary line if the robot is reset upon such a surface.  At reset, the processor remembers the original surface color and then adjusts all subsequent sensor data accordingly before processing it.  The indicator LEDs will light on the open spaces and go dark as black lines are encountered, but the robot will behave exactly like it would on an official (black) sumo ring.  Programmatically, this was very simple to implement and it added to the robot's capabilities for very little cost.

blade&ir.jpg (22986 bytes)

K'NEXBOT also has a simple bumper sensor system on the front consisting of two microswitches mounted on the corners of the frame behind a plastic "blade".  Upon contact with an opponent, one or both of these microswitches will activate depending on where the opponent or obstacle is.  The robot will then pivot toward the activated switch in an attempt to activate both switches indicating that the opponent is centered on the blade.  It will then go straight forward, trying to push the opponent out of the ring, stopping only if both front sensors indicate the boarder line.


K'NEXBOT has one additional highly specialized sensory system that adds a convincing illusion of intelligence and awareness, and helps locate opponents and obstacles pretty well too.  It is a short-range infrared distance sensor that points straight ahead out of the front of the frame.  This sensor, a Sharp GP2D02, returns an eight-bit value corresponding to the range from the robot to an object up to a meter or so away.  Upon microcontroller reset, the system calibrates itself to a maximum distance and then only registers objects closer than this threshold.  The sensor has a field of view of about five degrees, making it very effective for object-locating applications.  Normally the robot will "look around" or pivot searching for the opponent at the beginning of the contest and whenever it encounters the perimeter line.  Upon "seeing" something, it will move toward it.

The receiver portion of the IR sensor has a piece of exposed, developed color film negative over it to help filter out ambient light.  This doesn't seem to degrade its performance at all.


botboard.jpg (21673 bytes)

A pair of DIP switches located on the BOTBoard (lower left corner) allow the robot's operational mode (SUMO, NON-SUMO, IR TEST, etc.) to be selected at will.  The mode is established only on reset.  Both switches off select normal SUMO mode.  Switch 1 on and switch 2 off select NON-SUMO mode.  Switch 1 off and witch 2 on select IR TEST mode.  The fourth combination (switch 1 and 2 on) is not currently used.

K'NEXBOT uses the IR sensor differently depending on the settings of the mode switches.  In normal "SUMO MODE", it will use it to locate opponents or obstacles.  In "NON-SUMO MODE", it will use it to find unobstructed open space.  In "IR TEST MODE", the robot acquires data from the IR sensor, lights the status LED if something is within sensor range, and processes sensor input but doesn't execute the programmed behavior.  In all modes, the program sends a selected variable (based on the mode switch settings) to Port C.


K'NEXBOT uses two sets of batteries for power.  A 9V battery regulated down to 5V for the controller and interface circuits, and four "AAA" rechargeable alkaline batteries wired as a +/-3V pack to run the drive motors.  This allows them to run forward or backward using simple SPST switched on/off power control (a kind of goofy "H" bridge).  The motors are wired so that when both go forward or reverse, one motor runs off each side of the pack, taking maximum advantage of the available battery power and minimizing any cross-coupling effect.  The downside of the rechargeable alkalines is that they must be removed to be recharged.  This has not proven too inconvenient however, since the batteries last quite some time per charge.  Also they are lighter than standard alkalines.


K'NEXBOT's "brain" is a Marvin Green's BOTBoard1 utilizing a Motorola MC68HC811E2F processor which contains 2K of EEPROM for program code and 256 bytes of RAM for stack and data.  The BOTBoard1 is powered by a separate 9V battery, regulated to 5VDC.  It is mounted on the side of the frame above one of the drive wheels, opposite the I/O board as shown in this photo.  The sensor and control systems also derive power from the 9V battery, leaving the other battery pack (+/-3V) exclusively available to the motor power system and minimizing possible noise coupling and loading effects between the systems.  I have never experienced any noise problems on K'NEXBOT as a result of this design philosophy and so highly recommend it.


IO_Board1.jpg (20195 bytes)

K'NEXBOT's "brain" is connected to the sensor interface and motor control (I/O) board  via a rainbow ribbon cable.  The I/O board, which is mounted on the side of the frame opposite the BOTBoard, connects the sensors together, feeds them power, holds the motor control relays and drivers, and provides signal conditioning between the robot platform and the BOTBoard.  The I/O board connects to the robot's systems via a 16-pin header and a couple two-pin connectors.  Battery power comes onboard via this ribbon cable also.  A programmatically-controlled activity LED provides visual indication that the program is running normally.  This arrangement allows the robot's major components to be disassembled and separated quickly and easily for repair or modification.


The BOTBoard1 is programmed in SBASIC from a PC via a special serial cable.  The process consists of 1) hooking up the BB to the serial cable and power.  2) compiling the SBASIC code to an ASCII assembly language source code file, 3) assembling the ASCII code to object code, and finally 4) downloading the S-Record code into the processor's onboard EEPROM.  I have automated this process using batch files on my PC so that once I'm ready to try my code, a single command line launches it and in about five minutes, it's ready to try.

The overall software for the project was the most daunting task of all, taking many hours over many weeks just to get working.  I started with ROBOT.BAS from a past Encoder article by Kevin Ross on robot basics and went from there.  This article and the heavily commented program really helped me understand how to structure the software to accomplish what needed to be done.  It was extremely helpful to have something to start with, a model if you will, of how to write a robot control program.  Although the example above did not do sumo behavior, it gave me a template to use to create what has grown into K'NEXBOT (pseudo code).

What kept me out of the last sumo contest was that I didn't start working on the software until about two weeks before the contest.  I used up most of the time prior to the contest getting the hardware working yet still needed to do a lot of software.  I thought I could pull it off.  Wrong!  In fact, I have been debugging and tweaking K'NEXBOT for about two months since the contest and am finally somewhat satisfied with the way it works.  As far as estimating time to complete this software project, it took four times as long as the time I had to really debug the code. So a word to the wise, allow at least a couple months before a contest to go through your code and get it working.  I tried debugging code at a contest which was very stressful and completely ineffective. I don't recommend doing this to anyone.  Besides, it usually doesn't work unless you are really, really close, which I wasn't anyway.


This article wouldn't be complete without my sharing what I learned about building a robot while doing this project.  As with most projects, one often learns what not to do as well as what to do.  This project was no exception.

One of the toughest issues was coming up with the basic hardware approach that would fit within the contest constraints without bankrupting my savings account.  I was hoping to find some sort of motorized (possibly tracked) vehicle that would be small enough and powerful enough to qualify to compete.  I wasn't able to find any such thing until after I had settled on K'NEX.  Naturally, after the fact I saw other even better choices that I couldn't seem to find during my search.  The next generation of sumo I build will undoubtedly be much different.

I opted to go with ordinary geared DC motors rather than RC servos to provide drive.  At the time, I thought the K'NEX motor approach would be cheaper and had planned to incorporate multi-speed motor control.  Since this never materialized, I probably spent the same money but a lot more time building the interface to the DC motors while servos already come with this.  In the future, I might opt for servos mainly because they simplify this part of the project immensely.

I considered using the Basic Stamp as a controller and probably would have giving it a try but stumbled upon Karl Lunt's SBASIC for the BB1 about the same time and decided that this approach would work better.  There were other controllers that were candidates as well, but since the BB's need only free software, an inexpensive serial cable, and a PC, this approach won the toss.  As it turned out, this was a perfectly fine way to implement the design.  I found the SBASIC environment to be comfortable and easy to work with, making the programming code very readable and debuggable without other tools, though a good HC11 emulator that runs under DOS would be nice.  Any one know of one?

Figure that your software will take many times longer than you think and budget the time.  I worked to two weeks before the contest and eight weeks after the contest to get K'NEXBOT working the way I wanted.  My estimated software effort was two weeks while my actual software effort was ten!

It is probably smart to buy what you really can't build yourself.  If you are electrical/electronic, buy a pre-built motorized gearbox.  If you are mechanical, buy servos or pre-made power controllers, if you are a software person, buy the electronic and mechanical parts as a kit.  The problem is that it's easy to get stuck on the parts you don't understand trying to get to the parts you do understand.  Paying a little extra up front might alleviate some frustration down the road.

Build your own test area/track/arena/etc. if possible.  This is tough for fire-fighters and larger sumos, but pretty easy for mini sumos and other small robots.  I built a rectangular test area on a board with a white surface (posterboard) surrounded by a black line (vinyl electrical tape).  I then programmed my robot to self-calibrate to the first surface it sees after being reset.  This allowed it to run on my test arena but still work for the real sumo contest without program changes.

Bring your robot to SRS meetings and test it there if at all possible.  This is also a great way to get feedback on ideas or problems you may be having.  Besides, everyone likes to see a cool robot in-work or being tested.

Mimic contest conditions as much as possible, especially bright lights and other interference-generating systems.  See if video cameras, TV/VCR remotes, and other IR sources will generate problematic IR signals and use IR filters (purchased or exposed, developed color film negatives) if possible to reduce the effects of daylight.


So, in spite of all the hurdles mentioned above, would I say that building a robot was worth the effort?  You bet!  Would I do it again?  Absolutely!  In fact I am working on a second one now, B.A.R.T.  I really enjoyed my first successful project because it gave me an even greater appreciation for people who have done this sort of thing, and a wonderful sense of accomplishment to admit I had also.  If you can work with someone on a single project, this might help avoid some of the pitfalls that only one brain and set of eyes may miss, but don't be afraid to try it on your own.  The SRS listserver has also proved to be an invaluable source of information and answers to perplexing questions.  I highly recommend joining the list and participating.  It really is fun and rewarding to see your robot do what it's supposed to do, though this isn't the most important thing, and doesn't usually come without a good bit it trial and error.  This is a very cool hobby that gets better by the day as technology continues to march ahead.  Look how far it has come in the last ten years.  I can't wait to see what the next ten years has in store.

I hope you have enjoyed this little excursion.  Next time I'll share the nitty-gritty details of my robot's guts with you, including the software, so stay tuned.


K'NEXBOT, the Technical Stuff


Comments, questions, suggestions, corrections, whatever, email me at Steven.D.Kaehler@Boeing.com