Team One/Journal

From Maslab 2006

Maslab teams
Team 1 · 2 · 3 · 4 · 5 · 6 · 7 · 8 · 9 · 10 · 11 · 12 · 13 · 15
Team One's Journal · Paper

Contents 1 Pre-IAP 1.1 Sometime in early October 1.2 Sometime in November 1.3 December 24 1.4 December 25 1.5 January 1 1.6 January 8 2 Week 1 2.1 January 9 2.2 January 10 2.3 January 11 2.4 January 12 2.5 January 13 2.6 January 14 3 Week 2 3.1 January 15 3.2 January 16 3.3 January 17 3.4 January 18 3.5 January 19 3.6 January 20 3.7 January 21 4 Week 3 4.1 January 22 4.2 January 23 4.3 January 24 4.4 January 25 4.5 January 26 4.6 January 27 4.7 January 28 5 Week 4 5.1 January 29 5.2 January 30 5.3 January 31

Pre-IAP

Sometime in early October

We decide that we want to do Maslab, and resolve to get a lot of coding done before IAP starts, the fact that we don't even know if we're in yet notwithstanding.

Sometime in November

We find out that we have been accepted into Maslab. Yay! Also, we all get hosed and don't really write any of the code that we said we would. Femtomatt writes some simple code that looks kind of like it does something good, but not really.

December 24

We finally get around to setting up our team's private SVN repository today, so we can keep our coding efforts coordinated. Our team still hopes to have a fair amount of our code written before IAP starts. Since we don't know the rules of the contest yet, this is kind of hard. We've been looking over previous years' contests, and hoping that this one will be essentially similar, maybe. If the contest coordinators are reading this right now, they are probably laughing maniacally.

So far, we have discussed various possibilities for our vision and navigation code. Um, it turns out that these are hard problems. Phooey. We are hoping that the relative suffering that some of us endured in 6.034 and 6.046 this past semester will somehow help us, maybe. If any previous years' contestants are reading this right now, they are probably laughing at our naïvety.

December 25

Happy Decemberween, everyone!

Ben apparently spends the day reading though papers on computer vision. His dedication is admirable.

January 1

Happy New Year! Femtomatt (and probably others) watched the stupid ball drop last night. It would have been pretty funny if the thing holding it up had broken and the ball had fallen and crashed into the giant 2006 sign and shattered glass had flown everywhere, but that didn't happen.

Potentially useful things we have discovered in the last week about various acronyms:

• HSV is stupid and annoying
• SOMs can be used to identify images of hot women
• DTRT is a powerful concept
• ORC did a lot of really clever things last year (which is probably why they won)

January 8

We all return from break and swap sketchy New Year's party stories. After this important step is completed, we discuss stuff we've accomplished over break and spend some time thinking about how to fit it all together. Marti did a whole lot of research on image edge detection and Hough transforms. Ben did some statistical analysis of RGB values on some sample images from 2005 and managed to come up with some pretty accurate methods for differentiating walls, balls, mouseholes, and the carpet without needing to convert to HSV. Leon managed to write a test program that simulates distance sensor output in a maze given a image file representing the maze layout, which will help a lot in debugging nav code later on. Femtomatt continued working on nav and steering, and got some basic working code up and running.

Week 1

January 9

Day one: we go to lecture, then go to lab, and do the requisite soldering, pegbot construction, and worldly salutations. Marti, after an initial panic upon discovering that Eden doesn't come with Emacs pre-installed, installs it with apt-get. The suggestion that we just use ed instead is dismissed fairly quickly.

In the evening, we have a long discussion about software and hardware ideas. Upon brainstorming about how to gather and unload balls mechanically, various analogies to both pinball and the epiglottis are made, the latter coming from the idea that we store balls in two chambers (with an epiglottific movable door to control which chamber balls enter) so as to better control how many balls we put into each mousehole. Everyone on the team agrees that it would be best to be able to collect balls by merely driving over them, instead of having to grab them with an arm of some kind. We also consider the possibility of having the robot unload balls into mouseholes by pushing them out behind it instead of out the front.

Myriad ideas for improving odometry are raised, including such things as having the robot drop ultrasound beacons and using them to triangulate the robot's position. More realistic ideas included using an electronic compass to compensate for gyro drift, and using barcodes as identifiable landmarks.

January 10

Lecture, and then lab. A couple hours into lab, Ben has to leave early for some undisclosed purpose (he claims it was for Mystery Hunt practice, but we all know what that means). Not long after, Marti has to leave for something else, maybe. Sometime after that, Leon and Femtomatt decide that maybe they should get around to actually doing the assignment for that day.

Back at the concrete fortress that they call home, the tetriferous foursome spends several hours deliberating on the design of the robot. Two major ideas are raised: the double-chamber structure discussed yesterday (which we soon name the Epiglottis configuration), and a single chamber running down the middle of the robot (which, after Femtomatt is outvoted three-to-one, we name the Shaft configuration). It is noted that the 12x12 inch size constraint, along with the length of the motors, ends up placing very tight constraints on the design. After much debate about the virtues and iniquities of each design, we finally decide that we will make mockups of both tomorrow to see how they actually perform.

The rest of the evening is spent preparing for tomorrow's checkpoint and learning valuable life lessons about Java's type system. Due to Ben's previous progress with color statistics, recognizing red blobs is already fairly simple for our code; we hope to finish with tomorrow's assignment fairly quickly and move right on to construction.

January 11

Red ball recognition takes somewhat longer than we had expected — although we already had most of the code in place, it takes quite a bit of parameter adjustment. This should probably be a lesson to us. Also, after we find that the BotClient is only showing blank black images, we spend quite some time trying to figure out what's wrong with our camera only to eventually discover that the camera is just fine and the BotClient isn't working quite right. This should probably also be a lesson to us.

Eventually we get the ball recognition working, and hilarity ensues as the robot mistakes jackets, backpack straps, and people's ankles for red balls. Finally, we surround the robot with a wall of Ignorance and Backpacks, within which there is only The One True Red Ball. That works pretty well.

We then move on initial construction. After making some cardboard models, we conclude that the Epiglottis configuration that we had thought about earlier is problematic for unloading, so we settle on the Shaft configuration. We then have all sorts of fun with the hole punch and the shearing tool, building ourselves a plastic chute enclosed in metal brackets to hold balls. We also cut down the base of the robot in order to closify the motors.

In the evening, Ben starts work on barcode recognition, while Femtomatt goes AWOL. Both of them will be ditching the team for Mystery Hunt, so Leon and Marti will probably have their work cut out for them.

January 12

Our team splits into two groups in lab today: one to work on the barcode checkpoint, and one to work on construction. Much progress is made on construction; we mount the motors and nearly complete the ball chute. The main component that still needs to be built is the roller that will pull balls into the chute and push them out again. Leon and Ben manage to hack a servo to spin continuously, so that we can use a servo to power the roller instead of another motor (read: five sensor points instead of nine). Also, after much finagling with tiny L-brackets, Leon and Femtomatt successfully get a well-centered axle for the roller mounted on the servo.

Much progress is also made on the barcode reading code, but problems with Java make things much more difficult (apparently, the getSubimage method doesn't work quite as expected). Marti apparently encounters problems while tweaking the Veroc algorithm he is using for barcodes, but Finale tells us that we can pass the checkpoint tomorrow instead. Yay!

By the evening, barcode recognition is nearly done. We discuss logistics for the weekend, and Femtomatt, who fully intends to punt lecture tomorrow to attend the opening to the Mystery Hunt, vows to code with a vengeance come Monday whenever the hunt is over, and promises not to work any further on OrcPad Tetris until our code is much farther along. The rest of the team hopes to convince him not to work any further on it, ever.

January 13

We all wake up Way Too Early to go into lab. Femtomatt sleeps in the lab for two or three hours, and then leaves to go to the Mystery Hunt. The other three, who are not slackers, make progress on barcodes, but soon find that slight differences in lighting cause our color classifier to go berserk and unleash its unstoppable hidden mutant powers. Later discussion leads us to think that perhaps our color classifier should be made more robust, if only to prevent it from destroying the world.

Java's class loader continues to pour out its undying, fangorious wrath upon us. We try to determine how to appease it, without success.

Much more progress on construction is made. The Eden and OrcBoard are mounted on our new chassis. A temporary roller for the shaft is put together. Journal sentences in the passive voice are written.

Not surprisingly, we don't finish Checkpoint Two today.

January 14

Ben and Femtomatt each do Mystery Hunt instead of working on Maslab. Ben's team solves roughly twice as many puzzles as they did last year, and Femtomatt's team gets second place. Huzzah!

Marti also apparently doesn't do anything. For this, he cannot be blamed.

Leon makes some progress designing a fantabulated IR beacon that we hope to use to improve our odometry. Leon is awesome.

Tomorrow, we will get back to work.

Week 2

January 15

We spend some time in lab today, and make some kind of vague, incrementalated progress on vision. Sadly, our wandering code is still largely nonexistent.

Our robot is still very hacked together; once we have a better idea of final measurements, we will probably take a day to rebuild it. Fortunately, the design is quite simple overall.

Leon apparently makes more progress on the IR beacon. Leon is still awesome.

January 16

We finally pass the barcode checkpoint today, and we think (i.e. naïvely hope) that we will be able to pass Checkpoint Two tomorrow. We will be making a concerted effort to catch up so that we won't be late on Checkpoint Three.

After continued vision experimentilibation, Ben decides that HSV thresholds may be more effective than some of our RGB statistics — we still plan to use an RGB lookup table, but this may change how we generate it, for the better. Another possible color recognition improvement is a generalization method that, given a lookup cube, fills in unidentified cells with the nearest identified color classification. Unfortunately, the incredibly convoluted, iterative method with nine nested for-loops that Femtomatt writes this afternoon is broken, and several hours of staring at the code fail to reveal the problem. Nine nested for-loops. What the heck was he thinking? In any event, Marti will probably write a recursive version tomorrow.

We are discovering that telling the difference between the wall and the floor is often very difficult. However, Femtomatt has an idea for mapping that may make the best of the problem: rather than trying to determine where walls are and avoiding those areas, instead keep track of where known open floor is and cling to those areas. It may be worth trying, at least.

January 17

Our color classifier is getting better every day, and we discuss several options for improving it even more. The main problem right now is distinguishing the wall from the floor. Possible solutions include comparing textures (the color changes smoothly between pixels on the wall, but not on the floor), or using a flash of light and looking for the reflectivity of the wall. However, it is decided that we should wait for next week to try out these things and focus on checkpoints for now.

Femtomatt sets up a structure for the robot's overall decision-making. It is sort of a mix between plan/act and a finite state machine — essentially, its method of planning depends upon the state, and each state has rules for occasionally switching to other states (for example, the return-to-mousehole state plans how to get back to the mousehole, but switches to the dock-with-mousehole state when the mousehole comes in sight).

Leon wires up the gyro and succeeds in getting the robot to make precise turns. He also takes measurements on the gyro drift over time. He finds that it drifts only a few degrees over five minutes — not too much, but enough to cause odometry problems. Also, this drift is mostly below the resolution of an electronic compass, so a compass wouldn't help much.

We have some success with the roller — it seems that the hacked servo doesn't spin fast enough, so we use a motor after all — however, the current roller is not terribly protufic yet, so we need to make a better version.

January 18

The design review today indicate that a number of teams are doing very similar things in both software and hardware, but it also gives us some interesting ideas to chew on.

Ben and Leon continue to tweak the mechanical design. Although they do an admirable job, it becomes clear that not having any mechanical engineers on the team is only going to make things more difficult. It is fortunate that we intend to keep our mechanics as boneheadedly simple as possible. We also learn some valuable life lessons about how much trouble centrifugal force can cause.

Marti spends several hours working on some code to do image edge detection using Hough transforms, but is plagued both by insidious bugs and the full-fledged wrath of Java's army of malebodious idiosyncrasies. Also, it turns out that maslab.jar requires Java 1.5, which is not supported by OS X 10.3, making local development for some of our team somewhat more difficult. Thus ends our daily complaints about Java. On the plus side, parameterized types are awfully hot.

Femtomatt continues to work on navigation infrastructure, and sets up a framework for map telemetry. Unfortunately, most of the nav code we have thus far is more or less impossible to test until the robot is farther along, which means that we have a great deal of code that works well in theory, and may or may not actually work in practice. Hopefully, this won't get us into too much trouble.

January 19

Finally, some solid progress! The roller is observed actually working today, although it needs a great deal more tweaking. Ben and Leon spend plenty of time in the shop, and come up with a pretty solid gearbox for the roller motor.

In a flash of insight, Femtomatt manages to slay the Java class loader's evil hoards of defeniferous minions by noticing a glaring omission in our classpath that causes Java to not be able to find classes when the current working directory is not at the root of the class tree. We probably should have figured that out earlier.

Although our robot is not ready for much of anything yet, we go to mock contest zero and move our robot around by hand while taking no less than 784 pictures, of which about 588 will actually be useful for vision calibration and simulations. With any luck, our color classifier and vision algorithms will be pretty solid with all these data to work with.

Walking back from the mock contest, Femtomatt and Marti have roughly the following conversation:

• Femtomatt: I have two ideas for mapping, but they both have a lot of problems. The first idea is to blah blah blah yackity smackity. But then, fuh huh jigga ho hum. Any ideas?
• Marti: Maybe you should do some research.
• Femtomatt: Oh. Um, okay.

[not all that much later]

• Femtomatt: Huh! It turns out the the first hit on Google for "robot mapping" is a paper that describes an algorithm for mapping in real time on a low-end computer with bad odometry!

It just goes to show: when you need to find the answer to a problem, you should ask someone who knows.

The dinner at ITA Software was quite good, and our team's consensus is that ITA seems like a pretty cool place. Also, the folks there use emacs and Common LISP, which makes them even more awesome.

January 20

We're getting tired. It's a good thing that it's Bad Ideas Weekend — we could use a break.

Success! The full glory of the roller is revealed today, thanks to the tireless efforts of our MechE impersonators. It can now suck up balls without jamming one time in three, and it can shoot them out into a mousehole fairly accurately from two or three feet away.

Marti finishes up the Hough transform code, and discovers the wondrous, um, wonders of the Emacs Code Browser. It's like using Eclipse, but with full emacs key bindings, and without the crashing-all-the-time-on-OS-X-for-no-apparent-reason-ishness. Rock.

Not surprisingly, the gradienterrific techniques in the robot mapping paper that Femtomatt discovered yesterday are somewhat more advanced than we have time to implement (especially since we don't even really understand them beyond the conceptual level). Nonetheless, after reading it over some more and doing some more research with Marti, he comes up with some ideas for mapping using some of the basic concepts from said paper, which might actually even work, maybe. It will take some more discussion to flesh out the details.

January 21

Aside from some token coding, we basically don't do anything today. We needed a break.

At least three members of the team play some video games. We sleep more than usual. Some of us also enjoy some harmonifious weekend revelry.

Perhaps we will be more productive tomorrow.

Week 3

January 22

We discuss mapping ideas further today. The concept that we agreed to try for is to have the map store each image "scan" separately, and then to use features to line up scans with each other. Not only does this allow us to use features to correct our odometry, but we can effectively correct odometry retroactively by using newer scans to help correct older ones, and find our way back to somewhere that we haven't been for several minutes. The implementation will likely be a bit tricky and obfuluted, and if it doesn't pan out then our backup plan is to use a simple topological map.

Marti and Leon win the Most Dedicated award for going into lab late at night and getting the robot to pick up a ball and score a goal. It is apparently not fully reliable yet, but we're definitely moving in the right direction.

Ben gets blue line filtering to work, and in trying to optimize it for speed, discovers why Femtomatt has been so adamant all this time about avoiding using division in our speed-dependent code wherever possible. It turns out that division is really slow (and often unnecessary).

January 23

After Marti wakes up from a several-hour nap in lab, he and Femtomatt discuss our plan for mapping in depth, and work out some of the issues. One concept which we believe may help is to assign each scan a uniqueness rating (yes, William and Elwyn, we know that "there can be no degrees of uniqueness"; cut us some slack). This value is based on how many and what kind of features are present in the scan — for example, barcodes have a higher rating than blue ticks, and several blue ticks have a higher rating than just one. This helps us to decide which scans to use to align the rest of the map.

Leon gets a haircut today. Shnarockin!

Ben starts in on building the New and Improved chassis for the robot, so hopefully it'll be looking all nice and pretty in time for mock contest one. No, it's not laser cut, or water-jetted, or polycarb, but at least it doesn't have any pegboard in it...

Several members of our team climb up a whole bunch of stairs today, because some folks challenged us to.

January 24

With mock contest one approaching, we decide that we'd better buckle down and get the robot ready to actually do anything. Leon assembles the quad-phase encoders and works on odometry for a while. Femtomatt works on integrating the various vision algorithms we've been working with (blue line filtering, ball finding, mousehole finding, etc) so that they can all be run together more efficiently. Marti does some more work on mapping.

Ben and Leon finish up the new robot chassis and start playing around with IR sensors. The roller is so overjoyed to be in its new home that it decides to start working much more effectively than it used to.

Femtomatt ditches the rest of the team to go Square Dancing in the evening, despite it being our team's clean up day today. Tsk, tsk.

Ben spends several late-night hours tweaking the color classifier even more; except for cases with wonkulous lighting, it now classifies everything almost perfectly — or at least as perfectly as we're probably ever going to get it. Also, the lookup table is now 64 by 64 by 64, instead of 32 by 32 by 32. Yeah, that's right, six bits per color instead of five. Take that.

January 25

We decide today on the name for our robot: Kompressor. True to spec, our robot does not dance.

We spend the entirety of the day getting ready for the mock contest. Ben and Leon tweak the robot mechanically, getting the roller to work just right, and adding some long-range IR sensors to detect walls. Marti puts together some basic wandering code to hold us over (since our mapping is far from finished right now). However, we are slowed down by pestitulent troubles with the IR sensors.

Femtomatt finishes up the integrated vision code, and does some quick measurements to come up with a formula to determine where an object is based on where it appears on the camera image, accurate to within a few inches. As he mentions in his code comments, it breaks at least two different abstraction barriers. He intends to make a non-terrible version of that method in a day or two when we're not crunched for time.

After some birthday revelry for our team's second eldest member, we return to lab to make sure everything works simultaneously. We have some success with wandering code, but our battery begins to cut out on us, so we are forced to postpone testing until tomorrow morning.

January 26

Mock contest one today. Despite our efforts this morning to get wandering working properly, our robot, like many others, is simply not ready today. After the mock contest is officially over, Marti and Leon stay behind to get it working, while Femtomatt heads back to Fred to catch some much-needed sleep.

The good news for today is that we are finally getting all of our code to work together, and the code structure that Femtomatt set up over break is starting to pay off. The driving code keeps a queue of tasks to complete in order (such as "turn left by this much" or "move forward until this happens"), while the navigation code acts as a finite state machine of sorts, where the state determines what tasks get queued in reaction to the vision and sensor input. Thanks to The Power of Abstraction, this makes it pretty easy to build behaviors (such as "pick up this ball and then put it in that mousehole") out of simple pieces.

Wandering still doesn't work, but much usquilatory progress is made. We're still putting off mapping until we get other things working.

January 27

We finally get wandering working today. Ben and Leon use peak control to improve the driving and make adjustments to the mounting of the IR sensors.

Marti and Femtomatt focus on vision. Marti uses his Hough transform code to eliminate extrifitic noise in the blue line filtering, and works towards being able to know where a wall is relative to the robot using the slope of the blue line. Femtomatt works on an improved method for mousehole finding, and continues to try to make the vision code really fast, where by "really fast" we actually mean "not unreasonably slow; and no, we're not considering the possibility of using external C-- libraries, because we don't think it would be worth the trouble".

Working late into the night, Marti and Leon get mode switching to work properly, so that the robot switches from wandering to acquiring balls when a ball comes into view. Femtomatt, also working late, makes pretty solid progress on vision object recognition.

We have our work cut out for us this weekend, but the pieces are starting to come together, and we're starting to think that this is really all going to work.

January 28

Today is a typical day; we all continue to work on vision and driving, preparing in particular for mock contest two. Things continue to progress, but there are no particularly exciting or exphilious developments today.

Maslab is a blast, without question, but a small part of us is looking forward to when IAP is over, and term starts again, and we'll actually have some free time on our hands.

Week 4

January 29

With mock contest two tomorrow, our team works somewhat more feverishly than usual. Femtomatt works all day on vision code, putting some finishing touches on indepindious mousehole recognition and getting a solid start on barcode and powerball finding (although we had working barcode recognition from the day four assignment, it is not terribly robust). The fact that barcodes and the powerball are both green makes things much trickier.

Meanwhile, Ben, Marti, and Leon put their heads together over the robot to get wandering, ball acquiring, and scoring perfected. Our whole team works well past daybreak, taking quick trips to 7-Eleven or sleeping in the lab as necessary, but by the end of the ordeal wandering and ball-eating work quite reliably. Putting balls in mouseholes is still not-so-good, but it might work sometimes, maybe.

January 30

Mock contest two today. Our robot does reasonably well — it picks up several balls, and is able to put one of them into a mousehole (which is due rather more to dumb luck than to the quality of our scoring code), for a total of nine points. The round is prematurely ended when the robot fails to realize that the ball it is trying to pick up is too close to a wall. Also, the roller jams and a ball it has already picked up falls back out. Clearly, there is much room for improvement.

After catching up on sleep, our team meets in the evening to plan out the home stretch — we have fewer than sixty-six hours to make our robot awesome. We make a list of things to do, and divvy them up. Leon and Ben will be working primarily on mechanical issues and driving code, while Marti and Femtomatt will attempt to implement mapping.

Later in the evening, Femtomatt spends several hours working on vision; barcode and powerball recognition are just about done now, and are rieffently accurate. Unfortunately, although the vision code can recognize mouseholes just fine, it still does a very poor job of judging the distance and angle of the mousehole. Hopefully, we will fix that tomorrow.

January 31

The final sprint: day one. Our team works harder than ever, writing new code and testing old code to a bloody pulp. A probably non-exhaustive list of what we do today:

• Ben and Femtomatt take many measurements of the camera positioning — putting balls in front of the robot, asking the robot where it thinks the balls are relative to itself, tweaking the parameters, wash, rinse, repeat. By the end, it can judge distances and angles quite accurately using vision.
• Leon works on constructing the IR beacon (he has tested it before, but we've never used it on the robot yet). We discuss the problem of how to prevent the robot from knocking it over as it drives around. It's too bad that it's far too late to, say, paint the beacon bright pink and get the software to recognize and avoid it, but there's no way we're going to go back to tweaking the color classifier — it's just not worth it.
• Marti works a ton on mapping code; Femtomatt helps a little too. The code uses gradient descent to line up features in successive vision scans. As it turns out, the blue ticks are too small to accurately detect with vision, especially when the robot sees them at an angle — they're too hard to discern from noise. Instead, our mapping relies almost completely on barcodes to align scans.
• Leon and Ben put many hours into perfecting the roller. We hope that the jamming we ran into during mock contest two won't happen again. They come up with some code that uses current sensors to detect stalls, and progressively increases the power to unjam it, or reverses it if need be. As we are learning, when it is impossible to completely avoid errors, you're better off getting really good at recovering from them.
• Continuing work on mapping, Marti puts together some digraph code to act as a topological map connecting the barcodes in the maze, and uses his ninjastic 6.046-fu to implement Dijkstra's algorithm for finding routes back to known areas. The map will include some distance and angle estimates as well.
• Femtomatt works long and hard ironing the bugs out of the vision code. By the end of the night, it can judge distances and angles for every kind of feature, as well as the orientations of mouseholes, and will ignore balls that are inside of mouseholes.
• Ben starts initial work on good mousehole docking, a non-trivial problem. More remains to be done.

Before falling into bed, we go over what we need to do tomorrow: mousehole docking and ball acquiring still need work, and mapping needs to be finished up. We'll be scheduling our sleep so as to get the most out of the remaining hours until impounding. Our hope is that by dawn on Thursday, everything will be done, and we can spend the last twelve hours tweaking parameters and testing everything somewhere around fifty million times. We'll see how that goes.