You’ve all heard what most of the other bloggers are doing for IAP, but I’ve been quiet and left you in suspense. This means that you all must be dying to hear what I’ve been up to. I expect the barrage of questions and interrogations to start pouring in any day now.
However, lucky you, I’m going to tell you what I’ve been doing anyway.
I’ve been making a robot!. As the hyperlink implies, I’ve been participating in the same robotics class as Snively, this IAP.
The class is called MASlab, and is one of the few MIT courses I’ve run up against so far that is referenced by name rather than number (although for reference, the number is 6.186 — MASlab is a course 6 class, but it is also listed in courses 2 and 16, which means you can take it for EECS, Mechanical Engineering, or Aero/Astro!) MASlab stands for Mobile Autonomous Systems laboratory, which means that a bunch of college-type kids have to build a bunch of bumbling-type robots. By “bumbling”, I mean that the robots are acting entirely under their own brainpower, in a partially foreign environment. Not all robots bumble, when placed in the environment, but many do; it’s tricky to program autonomous robots.
To roughly (and hopefully, correctly) describe the competition, us student-folk have the month of IAP to design, build, and program an autonomous robot which uses a camera and numerous other, smaller sensors to navigate around a playing field. There are (up to?) 16 balls, red and yellow, on this field, and there are red and yellow goals. Robots earn points by scoring balls in red and yellow goals, with different point rewards based on color matching. The competition lasts five minutes, which is an awfully short amount of time for a month of work. To help robots navigate the playing field, the walls are white with a blue edge on top; additionally, there are “barcodes” on walls throughout the playing field which act as landmarks for robots using mapping algorithms. Processing occurs on an asus eeePC running linux, and robot control is (traditionally — some teams decide to go above and beyond) performed over the OrcBoard, which controls the motors and accesses the non-camera sensors.
Also, in case you didn’t catch it from the second to last link: maslab has a youtube channel! Snag it at http://www.youtube.com/user/MITMaslab .
Anywho, onto the guts of it all.
This fall, three juniors with whom I live (happy, grammarfolk?) approached me about working on their maslab team, because of my previous experience with both programming and mechanical engineering. They warned me that maslab would consume all of my time over IAP; they jokingly told me that it would take up 24 hours a day, and they weren’t far off. Since January 4th, I’ve spent most of every day working on a tiny robot that likes to wobble all over the place. We’re making quite a lot of progress, though — the robot is almost entirely constructed, and we’re debugging a large part of our vision code, with sensor and odometry modules being developed in parallel.
Check it out!
I can’t bring myself to write too much more about it, though, because I’ve spent a lot of time already doing just that:
That is our team’s journal, on the maslab 2010 wiki, authored primarily by yours truly. Pretend it’s an extension to this blog post :) (Hence the title)
And, for your amusement, a recent test video (that’s not my voice, by the way):
Now, moving on.
As the older and crustier of you blogreaders may know, I’ve left something up in the air from fall semester: 18.022. Check my previous blog posts for more on that; in short, I miserably failed a test — getting a 36 — with one of the two lowest grades in the class (if I recall correctly), and learned a lesson or two from it. Now that fall semester’s over, I have some results for y’all.
I don’t have access to the online grading system for that class anymore, since I’m no longer enrolled (because fall semester’s over, not because of anything bad), so there’s no dramatic screenshot to present here. Long story made short: I pulled through and got a 94 on the third test, bringing my average back up to a comfortable number. It was quite the learning experience for me; it brought out a quality in me that I hadn’t had to call on in a long time. It taught me that if I just persevere and don’t give in when it feels hopeless, I can pull through. Sappy? Perhaps, but darned useful.
To jump back to the original topic of this post, though, there’s one thing I’m trying to do this IAP that I haven’t yet mentioned to you: 6.184. 6.184 is known as “caffeinated 6.001”. 6.001 (six double-oh one) was, some years ago, MIT’s introductory computer science course; it has a somewhat legendary status. As soon as I heard about it and checked out the course info (and textbook — available for free online, and highly recommended!), it was *the* course I wanted to take, even before I got to MIT. I was quite disappointed to find out some weeks after learning of its existence that it in fact existed no longer. They stopped offering the course a few years ago, and replaced it with 6.01. 6.01 (six oh one) is a course that teaches introductory EECS using a prebuilt robotics platform and the python programming language; the transition is rather well described, in my humble opinion, here. Now that 6.001 is dead and gone, though, 6.184 is a course offered over IAP that condenses a famous, semester-length class into 8 lectures and 4 projects. It’s a lot of work, a lot of confusion, and a lot of fun. And Yan’s taking it too!
I may have to drop it, though, this IAP; I barely have time to keep up with meals and laundry, as is, and I’ve been sick for the last four days. Time to rest up. But, hey, there’s always next year, right? (Unless they really use the LHC, which is a supermegaworldbomb — don’t let the rumors that it’s “for science” deceive you)