See also our final paper.
It’s the first day, so the objectives for DayOne were spelled out in a straightforward manner. Daniel Kane and Anders Kaseorg spend most of the day on image processing code, taking time out to write a Hello World program and build a basic Pegbot. Seeing the compiler warning message Slow RGB -> HSV Conversion when working with the sample code, our team wonders if we could get better performance manually writing our own transforms of image data instead of using the HSV conversion function. Some work is done with finding the RGB values for the different colors. Andrew Spann goes on a wild goose chase to get a soldering iron from the 6.270 store. People there are helpful, but a tad disorganized so we get a late start at soldering. The Orc Pad finally gets assembled then beautifully displays the message Self-test Failed!. After calling for help it is determined that we have a defective Orc Board and we are given a new Orc Board. The new board bears the magnificent number 17, so of course everything now works perfectly. As lab closes today, we still have a little bit of pin-hole connection soldering to do for the gyro, but our coding is in good shape and we now have an Orc Board with everybody’s favorite integer written on it.
Evening Session: An amibitious Anders decides to play with the robot some more and soon discovers that the Orc Pad LCD loses its connection when bent. Andrew goes to the Random Hall basement and solders a few random connections before finding the one that was bad. Anders then gives the robot a host name, sets up an email client, and for irony’s sake uses the robot’s internet capabilities to connect to this very page.
It’s DayTwo. The day opens with some soldering tasks needing to be done. Andrew and Yoyo solder the gyro, short-range infrared sensor cable, and connect the motor to a power source. Daniel and Anders run the Orc Spy program, work on code, and work on finding a team name. Being predisposed to something with the word “Random” in it, Daniel overhears Andrew mention “random organic chemicals” in a soldering discussion with Yoyo and declares this to be the team name. In later conversations, it is decided (or at least vehemenently asserted by the current journal author) that the only organic chemical likely to go into making the robot except the flux component of solder is C8H10N4O6
* and that isn’t very random. It is desired to rename the team “Order of Random (Something that starts with C),” a pun off of Order of Random Knights and the ORC board/pad. Discussion of team name is tabled and we get back to doing actual work. With the short-range infrared detector assembled, the whole team begins examining the logistics of the sensor. Grabbing a meter stick and a wooden board, we use the Helping Hands device from the soldering kit to elevate the infrared sensor so it doesn’t reflect off the distant floor like it does when it is naively laid against the table. A balanced range of data points are taken and found to be very well repeatable. The short-range sensor is found to have a minimum useful range of three inches. Accuracy starts dropping off after about 2 feet, and we’d call the maximum useful range about a yard. Beyond this distance, the value of the voltage reading is still much higher than background (unless you have the sensor placed too close to the floor), but there isn’t enough sensitivity to small changes in distance to classify the input as anything other than “modestly far away.” We experiment with holding the board at various angles relative to the sensor and seeing how wide the sensor beam is. Our data suggests that the sensor fairs a bit better when oriented vertically, since sensor has different lenses for emitting and measuring IR. We begin some image processing using the GIMP. We end the day with the robot successfully able to roll forward and stop a couple inches in front of a wall.
Evening session: Daniel Kane and Anders Kaseorg work on a image processing system while Andrew Spann and Yoyo Zhou are assigned to work on getting the robot to wander around semi-intelligently, but instead work on writing this journal and analyzing the sensor data taken earlier today. We now have an operational image processing system that uses RGB values. After briefly flirting with a mathematically amusing but not-very-practical idea of representing colors in RGB coordinates as three dimensional planes and calculating distances to planes, we instead use a scheme where we feed a program sample images where we’ve manually isolated the main color categories one at a time. The program downsamples from 24-bit to 12-bit color depth then takes each point and generates “voters” based on a uniform distribution from that point. Each color is then voted on and each RGB value is assigned either no color or one of the main colors and goes into a 3-dimensional lookup array. We still have some problems counting small clusters of pixels in shadows as red, but this voting approach gets stronger as we feed it more test data, which we haven’t done much of yet. As for our short-range sensor characterization, we ran a least squares regression on a 1/x relationship with variables for scaling, vertical, and horizontal translation. We used a data set ranging from 4 to 24 inches with more data points at shorter ranges when running the least squares optimization.
Anders recompiles the kernel to enable the PC speaker, so our bot can play music. Yay!
DayThree is upon us. Time to boldly and valiantly procrastinate our journal entry until later tonight.
Our image processing program is coming along smoothly. After some initial difficulties with getting the camera to work correctly, we take a few pictures of walls and barcodes and begin training the robot to decode the barcodes. The picture color classification scheme that we are using works very well in our tests. Since it looks like MASLab staff is about to undertake a massive repainting job of balls and other objects, we postpone intensive image training to another day. Image training consists of taking sample images, cutting and pasting the portions representing different colors into separate training files consisting of samples of a color and pure white background otherwise, then feeding the training files into the program which generates the look-up table used by the robot.
We also have the robot primitively rolling around and turning whenever the short-range IR sensor detects anything in its path. We’re working on calibrating the gyro to be useful.
After some image processing using the GIMP and training, our robot can recognize barcodes, since it has knowledge of the colors black, white, blue, and green. Red, yellow, and anomalous floor-colored mush will be for another day. For some reason, when we color things blue, they appear as red in the BotClient, which we suspect may be buggy.
We’ve been trying to think about mechanical issues as well, thinking of a gate to sweep in balls and ways to implement lifting balls into a high storage space to be dumped out later, including conveyor belt and a paddlewheel, but the implementations do not seem free of issues. Also, something as simple as a hatch opening from which to release balls held above seems non-obvious.
Earth. Wind. Fire. Water. Heart. When your powers combine, Windows crashes.
We learn that the gyro will be free rather than costing us sensor points. Yoyo Zhou attempts to do some calibration experiments to make the wandering gyro useful. Our gyro currently proclaims with the professional consistency and enthusiasm of a Sloanie that there are 393 degrees in a circle. Anders Kaseorg teaches the robot to classify colors not needed for barcodes (you know, the ones that have to do with scoring and objectives and insignificant details like those). Daniel Kane starts disassembling the robot in preparation to turn the wheels upside down so that we now have wooden board mounted on top of rather than under the motor axle, which will be important for any future design plans that we come up with. Andrew Spann spends some time drawing out variations of paddlewheel-type mechanisms before deciding that they’re both too wide and prone to jamming. He then spends longer than he thinks he should have sawing and drilling wooden pieces to extend the height of the ball-bearings for use with our flipped robot chasis. The team discusses implementations of an Archimedes’ screw lifting device and decides that it’s worth a further look, but for now we need to get ready for checkpoint 1 before discussing plans for space-age-robot-with-multi-phase-electro-nano-immuno-chemo-physio-biology-tology capabilities. The camera is mounted at a height of 7 inches, right in the middle of the goal post line and a convenient place for reading barcodes, but right now it can’t see balls less than a foot in front of it so we’ll either angle the camera down some, adjust the height downwards, or both. Our all-Random-Hall team ends the day sitting and talking to Random Hall MASLab staffers playing a game called BadIdeaWorseIdea.
CheckPointOne was today. We passed. Don’t ask us how.
Okay, fine. We make some more adjustments to our bot. It’s still on pegboard; we remove the short-range IR for now, since it wasn’t going to be used to pass the checkpoint, and lower the camera. We also try to fight the main wheels’ outward-bowing tendencies. Yoyo tests the module which turns arbitrary angles by using the gyro, and finds it to be extremely buggy. Meanwhile, Anders discovers that his laptop’s IP address is controlled by a laserjet printer. He then works on a camera wrapper and a method to locate a red ball in the camera’s field of view in 3-space. Andrew designs a vertical screw from a PVC pipe. Daniel decides that if one Archimedes’ screw by itself will be too prone to jamming and not work then a great idea would be to use two of them, which would most definitely keep balls from escaping. Additionally, he calculates how to drive the motors to reach a point in 3-space by traveling along a circular arc and he gets attacked by our bot when it decides to drive backwards and run away from the red ball instead of moving towards it in an early stage of testing.
Testing in the playing field is complicated twofold: our robot sees pegboard brown as red, so in its search for red pixels it saw another teams’ robot in the playing field and valiantly raced towards it; further, our battery appears not to have been charged. Fortunately, these problems fail to stand in our way. There is a slight hiccup when the robot sees the brown bottom of a field goal container, but the plan is to mount the camera high enough that those will never be visible; staff also tell us that the bottoms will be painted white (I think). Shamefacedly, we also realize after the fact that our bot’s musical talents have been forgotten. For another time, for another time...
It may be Saturday, but we’re still hard at work. We visit the
leading authority to investigate the newest
cutting-edge research on the design of intelligent, autonomous robots. Dude, that laser scanner is awesome.
Our team doesn’t do anything today. Don’t try that at home, kids.
After a weekend of not MASLab, our team returns to the lab ready to work. Andrew Span saves the world from imminent destruction by misspelling his own name. Andrew spends all day laboriously sawing away at some PVC pipe, eventually succeeding in producing two screws of opposite chirality. The screws shoot laser beams that light things on fire. The central rods for the screws and the supporting case still need to be made, but overall our mechanical design is progressing nicely. Yoyo Zhou brings a live cow into the MASLab laboratory and begins feeding it sheets of polycarbonate. Yoyo works on setting up wheel encoders for odometry purposes. Anders Kaseorg climbs mount Kilimanjaro and defeats Charlie Chaplin in unarmed combat. Anders gets our existing code to run in separate threads and makes a short To Do list. Daniel Kane invents a time machine and uses it to go back in time and tell himself completely insignificant details about how his day went and what the weather was like. Daniel begins work on making central rods for the screws to turn around. Our team casually leaves the lab at the end of the day only to be confronted by an angry 10-foot tall bear demanding to know the answers to trivia questions concerning the Andy Griffith Show. By the way, you should only pay attention to every other sentence of today’s journal entry—the other half are false. I can’t believe I forgot to tell you that sooner.
“Steep Prices and Trees!”
Instead of using our names and cherishing our individuality, today our team is collectively known as The South. It does not matter that the number of people from the South on our team is less than four. We are The South today. The South works on designing a wooden shaft for our Archimedes’ screws. The shafts are fixed into place with screws projecting from the axis. The South now has two infrared sensors and an optical encoder. That’s amazing! The last time I was in the South we didn’t even have any computers, just a rusty old wheelbarrow, three rubber tires, and a box of Goldfish crackers. The South begins designing a servo-operated gate for the bottom chamber of the robot. The South wants to try to finish CheckPointTwo on Thursday so we can spend all of Friday on MIT Mystery Hunt.
Evening session: The member of The South who actually comes from the location furthest south out of The South decides to talk to actual mechanical engineers about our robot’s design. People are surprised that we actually were able to cut a smooth set of screws from PVC pipe (I imagine that the design thought process of our all-mathematician team violated various rules of good mechanical engineering practice such as industrializability, etc.) and tell us a lot about rotating shafts that we did not know. In particular, there is much more work to building a gear box than any of The South had anticipated and we also will need to use a better design of the outside casing for the Archimedes’ screws to cut down on wobbling. Finally, the member of The South who lives the second furthest south attempts to install Eclipse on his laptop so he can write Java in a nicer environment. Will he succeed, or will the journal abruptly end and leave you forever wondering?
Team Three Journal will be right back after a brief word from our sponsor, empty space:
Our lack of mechanical competence is really starting to burn us now. Construction of the casing for the Archimedes’ screw is going slowly, and the screw certainly won’t be done in time for CheckPointTwo (we should have the gate finished and thus be able to be “in possession” of balls, but alas, no field goals for us this week). We’re pretty confident that this idea works, but attempting to test it by manually rotating the screws results in uncontrolled wobbling of the shafts rather than rotation, so we can’t fully test it out until the entire apparatus is assembled. The casing might be done Thursday, but it looks like we’re needing to put more and more of our manpower into making things work for CheckPointTwo so it might get put off a while. The gear box unit still needs some time, but we probably need to order parts for it anyway. And now for a quick commercial break from our sponsor, empty space, which would like to remind you that resting every now and then is a good thing:
We finish assembling a lower gate. Right now it’s too big and we are concerned that it will get in the way of the camera. Yoyo and Anders begin stacking lab stools in an absurd way to form an elevated platform on which we position our camera so that it now faces the center of a blackboard about two yards away. Taking some chalk, we mark out the boundaries of the blackboard and calculate the angles for the field of vision. We are planning to mount the camera relatively high. We wish to take advantage of the fact that everything with the same height as the camera will always have a fixed angle in the camera’s field of vision. The current thought is to mount the camera at 9" so that the top of the field of vision is horizontal (this is level with the middle of blue tickmarks on the walls and the top square of barcodes). The downside is that this gives us a blindspot in front of the robot which is larger than we would like, but for now it also has the effect of keeping the robot from seeing the gate. Until we paint the gate a different color, we are pretty sure the robot will see the wood as red. Okay, that’s all for now. Today’s journal entry was brought to you by empty space, the official lengthener of student papers everywhere.
We passed CheckPointTwo a day early! We got so much done day. Except for writing our journal entry.
(Entry to come after
Mystery Hunt)
We use the power of Time Travel to go back in time and write this journal entry. Because Team Three is quite clearly a highly professional team, this is most assuredly the only time we or any other MASLab team have used the power of Time Travel for journaling purposes (just be glad we aren’t using the Power of Ten or Replicating). We got a lot done today. Andrew Spann and Daniel Kane mount the camera and infrared sensors onto the robot while Yoyo Zhou and Anders Kaseorg work out code for the robot’s wandering and image processing, respectively. The servo-mounted gate on the front of the robot is also functional. The robot can now successfully wander about and follow walls, only rarely gettting stuck. When it sees a ball, lunges towards it with a sudden burst of speed. The robot still has a major flaw, however. When presented with two fin wall extensions on opposite sides of the playing field directly opposite each other, the robot has great difficulty getting from one half of the playing field to the other. It will usually just go back and forth in whichever half of the field it started in for many minutes before going the right way. Finally, we take some pictures on the freshly painted field for final calibration purposes.
At noon a black hole mysteriously opens up and beckons us to enter. We decide that instead of going to lab we’ll take the mysterious portal.
After fighting our way through a mysterious fractal maze, we confronted a strange man demanded that we make a decision: in one hand he held a red pill that we could take to wake up from this dream into the real world, in the other hand he held a box of Goldfish crackers which wouldn’t do anything special but looked yummy. We were hungry and really sleepy too so we took the box of Goldfish crackers. “You fool!” yelled the old man.
Whew! We emerge from the portal, a little shaken but unhurt. Strangely, we are more tired and possibly won’t sleep well because we still feel like solving puzzles. Oh, yeah, you’re probably wondering our motivation for the story earlier. Was it based on something that happened during the mystery hunt? Is it a metaphorical autobiography of the author’s childhood days? Does it have a moral that can make our society a better place to live? No, not really.
It’s suppose to be a holiday today, but since we’ve obviously been doing so much work recently we put in a long day at the lab. At the end of the day, we have assembled the screw mechanism casing, begun work on a Kalman filter mapping program, replaced the pegboard bottom with plywood, and begun experimenting with the wheel encoders. We are unsure if we will have a fully operational lifting mechanism for Thursday’s mock contest (gear box might slow us down), but we are making rapid progress. Today is the 17th of the month. Being a Random Hall team, that means we should do something special for today’s entry. But we won’t, too bad.
My spoon is too big. My SPOON is too big. MY SPOON IS TOO BIG. Guess what? After spending the day putting finishing touches on the screw case mechanism so that it is now jam-free and working wonderfully, we have run into the problem that our robot is too big. At this point, all three dimensions of the robot are either currently just a little bit too big given the fact that the bin slopes inward in such a way as to mock us by appearing bigger than it really is. Now we get to sit around and play the “bureaucracy engineering game” and try to make the robot fit in the bin. Various bad ideas to stretch the bin into a rectangle are suggested by Spann, mostly involving heat guns and shower rods. On the coding side of things, we are faring a decent deal better.
Politics at its greatest: do we appease the powers that be or focus on making real progress? Due to massive parallelization, everything is “almost done” but very little will be actually ready for tomorrow’s mock contest. We essentially either have to hastily rush our modules or just let the robot run on its CheckPointTwo code and gear. At this point, we’ve made the executive decision to ignore the mock contest and turn our robot loose with essentially the same code as on CheckPointTwo and lacking our screw module. The screw module is in an operational state, but it is not yet attached and we lack enough metal brackets of appropriate size to attach it. Our coding improvements for mapping, odometry, and overall strategy show steady progress but we don’t feel like spending the time writing bogus code to hastily implement what we have for the purposes of today’s contest that will just have to get rewritten later.
Mock competition. We gleefully follow those orders and submit a robot whose wheels can’t even move because the optical encoders catch on the carpet. After removing our optical encoders so that the bot doesn’t do worse than it did during CheckPointOne we managed to score one point by accidentally driving over a ball that we never saw, which somehow winds up not being a terrible score for today’s contest. Afterwords we vowed to fix the numerous problems arrising from our wheels bowing outward, our upper level being poorly mounted and having made no significant changes since CheckPointTwo. The wheels bowing outward was eventually fixed by using zip-ties to hold the motors up. We managed to solve the problem of most zip-ties being too short by connecting two of them together to get one twice as long.
“The different branches of Arithmetic—Ambition, Distraction, Uglification, and Derision.”
–The Mock Turtle (from Alice in Wonderland)
Mostly mechanical stuff today. Andrew Spann mounts the screw assembly to the back of the robot and improve the cleanliness of loading and spinning. Yoyo Zhou punches new holes on the wheels’ L-brackets and mounted the wheel encoders sideways so they are less likely to catch on the ground. Daniel Kane makes miscellaneous tweaks to the main piece of the chassis. At this point the only mechanical work we have left to do is cutting down the top deck a bit so our robot meets maximum size restrictions and fix the motor running the screw assembly into place. With the wheel encoders in place now, we are ready to begin testing our odometry program tomorrow, which Anders Kaseorg has been working on.
“Hyperbolic cosine!”
A quiet day at the lab. Our robot is now cut so that it actually fits in the box. Unfortunately, we still have too much mechanical stuff to do. We need to mount the Eden in its final position (shouldn’t take long once we get back into lab, but we need some parts from there first to prevent the wheels from bowing before putting the Eden on the topside of the wheel assembly). We also need to finish mounting the motor for the screws. We have the parts in hand, but need to do some drilling before we can mount them. We’ve done some preliminary testing of the optical encoders and odometry code, but our persistent lack of mechanical skill has hindered our ability get code through testing stages.
Three feet of snow, zero progress!
After a marathon lab session that keeps us in lab until 9:45, Daniel completes the top gate and Andrew finishes assembling the screw motor and thus we finally have all of our mechanical construction put together. The back of our screw casing is replaced with transparent polycarbonate that makes our otherwise ugly robot look much, much better. As much as we are intrigued by the idea of having a magical black box attached to the back of the robot where balls enter from the bottom and mysteriously appear on top of the robot, being kind to the audience and letting them see what is going on is definitely the right move (and it lets us debug easier if needed). On the coding side of things, Anders has primarily been working on odometry and mapping, which is just shy of a useful state for the purposes of MockContestTwo tomorrow. Yoyo has been giving miscellaneous improvements to the basic behaviors and has also been helping out a lot with mechanical construction of the wheel encoders and gate. At this point some of our feasible and interesting ideas such as music robot and Orc Pad Tetris have been scrapped in favor of actually getting our main code done. Yoyo and Anders both stay up late into the night coding...
“Magandang Tanghali po! Have you been to the Philippines? We stopped in the day before yesterday. We hope you can visit during the day’s rolling. Like that’s possible.” “Let’s see, today we can believe in you for 3 minutes. Any longer than that, and even the King of All Cosmos can’t be made to believe in you!”
–The King of All Cosmos (from Katamari Damacy)
Our robot manages to disimprove during MockContestTwo and think it is constantly about to run into a corner. The robot moves backwards and turns randomly and makes it out of the initial enclosure but then keeps on thinking that it is about to run into a wall even when nothing is in sight. Total score: 0 points. A further inspection of our code reveals the following bugs: a sign error in the vision code, the vision code trying to scan pixels above the camera’s field of view, one break statement too many once our robot sees a red ball, and a shutdown time that was counted in Super Mario seconds instead of real time. After fixing these problems, we have a working robot that does a good job of finding and running over balls while not getting stuck. The screws lift two balls at a time reliably, but when lifting three at a time there is a chance that it will stall. We are now devoting as much effort as possible to program our robot to dock with the mouse hole and score field goals. We are having difficulties with the fact that some of the walls in the playing field are in very severe shadows. The biggest problem with this is that it makes it difficult for our camera to tell the difference between walls and floor. We are currently not sure how much this will impair our attempts at making a docking program.
More snow, less sleep.
So what if MIT is closed today? We go to lab to do more testing and coding, for an alarming amount of our planned software remains unwritten or unusable, and we definitely lack the time to make everything work as we originally planned.
At this point, by far our biggest concern is getting a working docking program written. From a business point of view, spending the last couple days on new coding instead of debugging is a bad idea, but the potential payoff of getting a successful field goal versus mere possession is way too big to not try it. Odometry and mapping is finally starting to come together. The robot understands its orientation, movement, and the locations of objects, although we are still working on making it use this information in a useful way. Even once the robot sees the goal and knows its relative alignment, docking correctly is still difficult. The screws are giving jamming problems during lifting. The loading and unloading portions, which were of most concern to us in the planning phases, are clean. We see that some of the screws connecting the shaft rod to the Archimedes’ screw are the cause of the jamming and we will take care of it tonight.
9pm—after a dayful of mistrials and inconclusive tests, docking is now working! We discover that there is a significant lag between noticing that the IR sensors report we are too close to the wall and actually stopping; with this realization, by traveling slower, we deploy the gate in a position that will not intersect the position of the field goal posts. All of our basic behaviors are complete except for advanced mapping (the robot makes a small local map when docking, but we currently have no large overall map). We will spend tomorrow making sure the robot as a whole operates correctly.
Last minute tweaking of our screw mechanism, which now works brilliantly and can handle multiple balls. On the coding side of things, we now have better telemetry and a better wandering algorithm. You can now see overlaid onto the camera how far the IR sensors are detecting and you can also pull up a local map of the area. Our wandering algorithm drops imaginary force fields onto our map of the playing field to attempt to keep our robot from hanging out in the same area for too long. The robot is repulsed by the force fields and attempts to reach areas where it has never been before. The strength of the force fields decays according to a first order reaction, so it is more influenced by the most recent fields. In early versions of this algorithm, the robot was backing up too much when it approached corners and alcoves so we have biased the robot to be more inclined to move forward than in reverse. This makes our robot more aggressive in searching out new areas, so as a side affect it is more likely to get stuck on a wall, but overall we feel that it is an improvement over our earlier algorithm which essentially moved forward until a wall was detected and then turned. We wish we had more time to test our force field algorithm a bit more, but at this point just about everybody wishes they had more time. As long as the density of balls on the field is respectable, we should be fine. We run into most problems when we have been wandering in tight spaces for a long time without seeing any balls. If we are on low battery, then there is also a chance that when our robot slows down to dock it will not have enough energy to move. At around 6:30, we are called for robot impounding and Archimedes Pi is taken away from us. Now we can relax a little bit until the contest tomorrow.
To be consistent with the narrative style of the journal so far, we should now briefly state what each of the four team members did tonight since this is the first taste of free time we’ve had in the last few days. Daniel Kane had a birthday today. Andrew Spann fell asleep while sitting at his computer shortly after writing the first paragraph so he doesn’t know enough information to actually write this bit.
“This year’s the year!”
After scoring no points in the Mock competition Tuesday, how well can we do on the real thing today? Suspenseful! Or not, since you've probably heard the outcome by now.
We return to lab only to find that our robot’s Archimedes’ screws are having problems unloading today. We make the last minute adjustment of padding the top of the shafts with duct tape so the ball will remain in the center at the very top. We also add some graphite powder to the gate to ensure smooth opening. Today was a day for cosmetic changes. We add some musical beeps to the robot upon startup and scoring but unfortunately its a bit too quiet for the audience really hear during the contest. Our USBMOD had been very flaky for the last day or so and at 3:45 we get total Orc Pad failure (the deadline for being down in 26-100 was 4:00). Working feverishly from 26-100, by some miracle we find the problem with the USBMOD and get a suitable replacement.
The contest begins. We wander around and pick up the balls in near view, but never quite make it to the second half of the field. We keep moving constantly but do a little bit of looping in the beginning area, but never get stuck and eventually wander to new places. We smoothly grab 4 balls then see a fifth ball and the goal. We grab the fifth ball and then with about a minute left begin docking procedure. The robot successfully docks and deposits the first four balls. We programmed our robot to know when the last time it picked up a ball was and to use the fact that it takes a little over 20 seconds for the screws to pick up a ball. The robot sits patiently at the goal until the fifth ball makes it up the screws then pulls out shortly after and attemps to wander to new places but doesn’t get to anywhere interesting before time runs out. With a score of 25, we win first place.
The pictures in TeamThreePaper are all from this final contest.
There can be no sequel. When the exhibition round comes, we merely stand quietly by our robot on the display table rather than running it in the field again. Given the general paucity of white-walled fields populated by red balls and yellow goals we certainly aren’t putting up the $300 fee to keep the Eden computer. Much like IBM’s Deep Blue, it appears that our robot will vanish into a state of disassembly only to be quietly talked about in myths and legends.
And what will become of TeamThree? Andrew and Daniel are entering the
COMAP Mathematical Contest in Modeling the weekend after this MASLab finish. Yoyo, Anders, and Daniel are joining with a couple other Random Hall residents and invading some course 6 grad classes. Although the adventures continue, our journal documentation ends here. If you want to find out what happens you'll just have to use your imagination, or wait a few years and try a search engine. Thanks for reading TeamThreeJournal and TeamThreePaper!