Team 53 - Iron Chef (料理鉄人)

Team 53 - Clyde Law, Anand Ramakrishnan, Jon Xu

What Is Iron Chef?
The Robot

Version 1
Version 2
Version 3

Strategy and Code

Step-by-Step Strategy
The Code

The Competition

Round 1
Round 2
Round 3
Round 4
Round 5

Videos
Cool Stuff
MIT 6.270 Home Page

What Is Iron Chef?

MIT 6.270 - 2001 - Masters of the Universe

Iron Chef is the name of the robot we built for the MIT 2001 6.270 Autonomous Robot Design Competition. We chose the name Iron Chef for our robot because despite the obvious differences, we saw a lot of similarities between the 6.270 competition and the Iron Chef TV show featured on the Food Network.

In the popular Japanese TV show, challenger chefs are given one hour to face off against one of four culinary masters in which they must create dishes with a secret ingredient. With limited resources and time, they must invent and be consistently victorious.

In 6.270 we are also given a limited amount of resources, Lego, motors, servos, etc. We are given very limited time to create something that we can use to perform the specified task. A more obvious similarity is in the nature of the face-off between two robots and between two chefs. The matches in Iron Chef last about 60 minutes and in 6.270, they last 60 seconds. The same one-on-one competitive nature of both competitions make Iron Chef and 6.270 very cool to watch Live and on TV.

The Robot

Version 1

The design for the first version of our robot essentially consisted of a cube with two compartments on each side controlled by gates. Each compartment is tall enough and wide enough to allow the 4-inch diameter balls to pass in. The robot is driven by a differential drive since that is by far the easiest to implement and the most useful for this application. When the robot moves over a ball, a sensor in the tunnel will detect the ball within a compartment and close the appropriate gate. When the robot moves, the ball will roll along with the robot. In order to minimize friction as the balls roll under the robot, the walls and gates of the compartments have freely rotating wheels.

Version 1 - Adder-Subtractor Schematic

We implemented a differential drive system in this version using a very unique adder-subtractor transmission system. The adder-subtractor allows us to control the robot more easily by making one motor control forward/backward motion, and another motor as left/right motion.

The diagram at left illustrates how the adder-subtractor transmission works. There are two differentials located in the center of the gear box. Differentials work by averaging the angular velocities of the rotations on both sides. In the setup, the differentials are connected with an odd number of gears between them on one side (one 24-tooth gear), but an even number of gears between them on the other side (two 16-tooth gears).

In effect, if both motors A and B are turning, the differentials end up spinning at a speed of A + B and A - B (actually one-sixth that speed due to gear ratios and averaging effect of the differentials), hence the term, adder-subtractor transmission. This is because the one gear on motor A's side drives both differentials with speed A while the two gears on motor B's side drives the differentials with speed B and -B. The differentials then average those speeds together.

This is useful if we decide to drive one motor at a time. In effect, if we only drive motor B, the differentials spin at speeds B and -B. The differentials are then connected to the main drive wheels, which cause them both to move in the same direction with the same speed, so the robot can move forward and backward in a straight line by itself, using no shaft encoding. If we only drive motor A, the differentials both spin at speed A, causing the wheels to move in opposite directions with the same speed, so the robot can execute left or right spins perfectly in place, again without the help of shaft encoding.

In addition, if the robot gets stuck against something while turning, the differentials transfers torque from one wheel to another, allowing the other wheel to continue turning. In effect, we do not have to worry about which wheel we have to turn when we are against an obstacle. Shaft encoders are still used for this however to make sure we turn the right amount.

There are two large drive wheels mounted on both sides of the robot, centered with respect from the side view. Then, there are four more small free-pivoting wheels, mounted in the front and back of each of the large wheels. These four wheels provide enough support to keep the robot standing. The four wheels have no tires either, so providing as little friction as possible so the robot can execute motion easily. In addition, the four wheels are slightly raised with respect to the large middle drive wheels. While this will cause the robot to wobble slightly back and forth on a flat surface, it provides enough leeway to navigate the small valley in the middle of the playing field.

Adder-Subtractor Gearbox

Clyde Working on Iron Chef v1.0
Thanks to the 6.270 staff for taking this picture

Version 2

Essentially many problems occured with our inital design. One of the major problems was with our touted adder-subtractor transmission system. Essentially, as we added more and more parts to the robot, the robot got heavier, much heavier than we originally anticipated. Because of the way the system was designed, one motor drives rotational motion and one motor drives translational motion. However, both motors are never used at the same time, so efficiency is decreased. At any time there is only one motor trying to move the robot.

In an attempt to add more motors to give the robot more power, we ran into another problem. Whenever the robot gets stuck against something, the torque that is transferred from one wheel turned out not to be enough to go against the inertial tendency of two motors at once. So in effect, the robot would not be able to get out of a stuck position. Because of this, the entire point of the adder-subtractor transmission was moot, so we went to the more simple and commonly implemented method of driving the wheels by having motors move each each independently.

Another big problem was that we had no where to place our Handy Board and battery pack. In addition, the program needed to coordinate the movement of our robot to use both gates effectively was not very easy to code. So, version 2 of our robot essentially removed the entire back gate of the robot in order to place the battery pack. Also this gave us room to make an arm to swat the center ball. This was something we wanted to implement in Version 1 but didn't have the room to do so.

These all seem like very good design decisions, however these decisions were basically made 12 hours before the first round. This didn't give us enough time to implement them well, so we decided to implement them as well as we could just so we could qualify in round 1. We planned on reworking the entire robot after we cleared round 1.

Amazingly, we both qualified and won round 1. Shortly after though, the robot was completely disassembled to make way for Version 3.

Version 3

Version 2 essentially was a mess of modules attached on the body of Version 1. The design was extremely inefficient, and we needed an entire overhaul in order to do what we wanted to do. Luckily, the program code was already mostly written due to the fact that the plan for Version 3 had mostly the same parts as Version 2. We just needed to make a better robot to take advantage of the code.

One big change was the removal of the four pivot wheels that plagued Version 2. Because the robot was so heavy, the pivot wheels exerted a lot more friction that we had anticipated, causing the robot to veer to the sides extremely easily. Version 3, the final form of the robot, removed these pivot wheels and replaced it with one wheel controlled by a servo motor. The servo motor is able to turn this one wheel to the correct orientation for turning the robot or moving it straight.

The improved features of the robot include:

Third turning wheel
Larger front gate able to hold two balls at once
Side rollers so robot can glide more smoothly against walls
Longer swatting arm
Lighter and more compact design

The final specifications are:

Differential drive

Two drive wheels located along the central axis running from left to right
Two motors per drive wheel with a 1:45 gear ratio gearbox
One shaft encoder per drive wheel, allowing for veering correction and turn calibration
Servo-controlled third turning wheel

Servo-controlled swatting arm mounted on the left side
10-inch wide front compartment allowing two balls to be held at once

Inward sweeping action of the gate gives compactness, ability to gather balls at edges, and ability to hold onto balls firmly
Gate controlled by one motor and gearbox using a 1:125 gear ratio

Side rollers
Six touch sensors

Long bar connected to two touch sensors detect a ball entering the compartment
Four more along robot edges - one at left, one at right, and two at the rear

Four LEDs and photoresistors detect table color

One at center, one at rear-left, one at rear-right, and one at front-right

Mounted beacon transmits IR signal to opponent
Physical Size

Width: 12 inches
Length: 12 inches
Height (without beacon and with gate raised): 11.5 inches
Height (with beacon): 17.5 inches

Our Lucky Headless Lego Guy

Front View

Rear View

Side View, Holding a Ball

Arm Extended

Strategy and Code

Our main strategy focuses on our ability to pick up the opponent's balls. This is based on the principle that our opponent would likewise try to maximize gains of balls on their side. Since four balls on our side guarantee a win, we immediately knock the middle ball onto our side at the beginning of the match. It also makes it easier since we will know that there will always be two additional balls that will drop. If the opponent happens to knock the ball onto their side first however, we can pick it back up later when we go to their side.

After the middle ball is knocked away, a sweep of the opponent's side will begin, attempting to pick up the balls initially on their side. Reliability and speed is the key, since the opponent most likely will have the same offensive strategy. We immediately retrieve the opponent's ball closest to us since that process is extremely reliable. We are able to move there and back very quickly.

Since we can guarantee a win with four balls, we maximize our gains by picking up the initial ball on the opponent's side, and with a second pass we pick up remaining ones if they have dropped on our opponent's side. Because we make this second pass, we don't need a ramp structure to divert the dropping balls to land on our side.

If the opponent decides to do a defensive strategy, it will most likely need to put down a ramp so that both of the balls the drop end up on their side. However, that takes time, and by then, we will be able to pick up at least one of their balls before they begin defending their side. In such a case, we will have at least 3 balls on our side, 4 if we can hit the middle ball to our side first. So, we stand a good chance if we can reliably pick up one more ball, something that could be done since it is difficult to defend 4 balls at once.

Step-by-Step strategy

Swat the middle ball to our side
Grab the opponent's ball

If grabbed, then return to our side and drop ball off
If not grabbed, then go for the other corner ball and return to our side

Second pass - take another swat at the middle ball that drops at 20 seconds
Make a grab at a corner ball whether it's there or not
Turn left 90 degrees and go for balls in the valley until we hit the wall
Return back to our side and drop off balls
Go back to the middle and swat middle balls until 60 seconds is up.

The Code

The above steps are reflected in the code directly. We have one program controlling the entire activities of the robot. Since the program was small enough, we didn't need to make unnecessary library files or increase unneeded complexity. A common code practice that we incorporated was output to the LCD display. This was a good technique to incorporate for debugging purposes. The robot would report what it's doing or trying to do. The calls to first_pass, second_pass, and last_attempt perform all the above described detailed strategy.

We also made limited use of multithreading, creating threads to keep track of the time, keep track of the current table color, and to determine when to close the gate.

Unfortunately, due to time constraints we never got to implement much of the recovery code in order to make our robot robust enough to recover from deviations in our environment. In many of our rounds, we get stuck against the wall very easily.

You can view the code here. Again due to time constraints, the code is slightly messy. There's also a lot of old, unused code that was never cleaned up as well.

The Competition

Our robot fared fairly well in the competition and got farther than we original thought given all our design problems. The contest is a double-elimination contest, where each team is allowed to lose up to two times before they are eliminated. You can view the 2001 6.270 contest rules here. The following is an analaysis of all the rounds we participated in.

Round 1

This is was the qualifying round of the competition. In order to compete in the later rounds of the contest, the robot had to be able to positively affect its score.

Version 2 of the robot was used in this round. Version 2 was basically built to qualify, but not necessarily win, but because our opponent failed to start, we both qualified and won the match.

Our robot's arm deployed but failed to knock the center ball back far enough to get it. Then it proceeded to the ball closest to it on the opponent's side. It sucessfully picked it up and began moving back to its own side. However, it got stuck against the wall on its right side, but luckily it had moved back far enough to get the ball in the neutral area, giving us the 2-1 win.

Round 2

This match was against Team 10 - Don't Worry, the team that won the entire 6.270 competition undefeated. Unfortunately, that means we lost this round.

Team 10's robot was extremely fast, being able to knock the center ball, grab one ball on our side, and come back to block us from getting our first ball. Because of this, we lost 1-5 since our robot was unable to move much.

This was also the round that we first used Version 3 of our robot. Unfortunately the new features in this version failed to help us in this round.

Round 3

We won this round 4-2 (the announcer said 3-2 in the video, but there was a ball he didn't see). Our opponent, Man at Arms, was essentially a stationary robot that quickly caged the middle ball, in addition to providing a ramp for further balls to drop down onto their side. Apparently, they had some trouble after their ramp/cage was deployed. For some reason, the cage began moving backwards onto our side after our arm had hit it. In effect, they gave the middle ball to us and the ramp that was central to their entire strategy did not work anymore. We were able to grab one more ball from their side as well, giving us a clear victory.

Round 4

We won this round as well, owing to another problem with the opponent. Apparently it appeared as if the opponent oriented itself incorrectly at the beginning of the match, causing it to get stuck at the very beginning. Thus, our robot was able to knock the center ball onto our side and proceed to the first ball on the opponent's side. On the way back from the opponent's side though, it got stuck against the wall on its right, much like in Round 1. For some reason, the side rollers that we had added in Version 3 failed to help glide us out of the predicament. We never got the opponent's first ball out of their side, so we won with just the center ball, 3-2.

Round 5

This was the round that we lost and finally got us eliminated from the competition. The robot began as usual, successfully knocking the center ball to our side. However, right after it did that, it immediately closed its gate and started moving backwards.

Apparently the sensor that sensed the ball got stuck, so the robot thought it had a ball even though it didn't. Problems with our opponent's robots in the previous rounds had helped us win them; now our luck had turned on us. After this happened, the robot was unable to do much and got stuck on our side of the board.

Meanwhile, our opponent, Kirpal the Autonomous Rickshaw, had managed to get two balls on their side, so we lost 1-4.

Videos

The following are videos of our competition in DivX format. In order to view them, you will need to get the DivX codec here. A big thanks to Jackie and Ron for taking these videos for us.

Round 2 (11.8 MB)
This video features a very confused Jackie thinking we were the other robot