Visiting the Tech Model Railroad Club at MIT

Last night I experienced the privilege of visiting the Tech Model Railroad Club on MIT’s campus.  As an avid model railroader, computer science major, and great admirer of books like Hackers and Accidental Empires, I’ve heard of the TMRC for most of my life.  As a kid, my parents bought the 1986 edition of World Book, which underneath the entry “Model Railroads” included a picture of the TMRC layout, something I’ve never forgotten.

tmrc station

The first chapter of the book Hackers tells how some of the earliest computer science pioneers were involved in the TMRC .  A few of the notable members were Alan Kotok from DEC, Richard Greenblatt the coinventor of the MIT LISP machine (which is housed next door in the MIT Museum), John McCarthy who coined the term Artificial Intelligence and helped developed the LISP language, and Jack Dennis who was one of the founders of the Multics Project (the precursor to Unix).  These members along with others helped coin the term “Hacker”, and inscribed within the “Dictionary of the TMRC language” was the (now immortal to all computer scientists) phrase “Information wants to be free.”  These guys were budding computer scientists, brilliant minds, mischievous hackers, and they were serious about controlling model railroads.

The first chapter of Hackers describes the interplay between trains, their control, and what the TMRC meant to different students:

tmrc-overpass

“There were two factions of TMRC. Some members loved the idea of spending their time building and painting replicas of certain trains with historical and emotional value, or creating realistic scenery for the layout. This was the knife-and-paintbrush contingent, and it subscribed to railroad magazines and booked the club for trips on aging train lines. The other faction centered on the Signals and Power Subcommittee of the club, and it cared far more about what went on under the layout. This was The System, which worked something like a collaboration between Rube Goldberg and Wernher von Braun, and it was constantly being improved, revamped, perfected, and sometimes “gronked”—in club jargon, screwed up. S&P people were obsessed with the way The System worked, its increasing complexities, how any change you made would affect other parts, and how you could put those relationships between the parts to optimal use.”

tram system

For model railroaders, the TMRC is probably in the top 10 most famous layouts in the world along with names like John Allen’s Gorre & Daphetid, George Sellios’ Franklin & South Manchester, and famous club layouts like the San Diego Model Railroad Museum.  For techies, there is no other layout in the world of interest that’s anywhere in the TMRC’s league.

It shouldn’t surprise anyone that model railroading and computers have always been bedfellows – even today model railroading has led the way in developing standards around Digital Command Control, interfacing locomotives, signalling, and other controls to a computer, and the Java Model Railroad Interface has provided us the world’s first successful test case of the Gnu Public License (the GPL), the open source software license that Linux and much of open source code relies on!

card operating schemeWith all of this background, I probably undersold the importance of the whole thing to my college roommate and his wife who live in Boston.   When they asked me what I wanted to do during our afternoon together it struck them as a bit odd that I’d already emailed the club from Scotland, had the phone number, and was anxious to make sure we didn’t miss the window.

Walking into the layout room we were met by the wonderful MIT alumnus and club member John Purbrick. He proceeded to give us an hour long tour showing us the various control systems, buildings, car card operating scheme, points of interest on the layout, and description of future plans.

custom built throttleTMRC uses a home grown software system (written in Java with the fronted in Python, all running on Linux) to run the trains.  The layout is still using DC block control, and trains can be run via the main computer system, or engines can be assigned to one of the many hand-built walk around throttles.  All turnouts are computer controlled and electronically operated, none are hand thrown.  For each yard or town area, there’s a diagram of the track layout with numbers on the left and right hand sides.  By keying in the number 0 on the left, and the number 5 on the right for example, the turnouts are all automatically thrown to present a route between the two points.  It’s simple, elegant, and impressive for a home built system.  As Mr. Purbrick put it, “We use a home built system on this layout because here at MIT, we have some experience with software.” Trains are detected by the software using electrical resistance, so operators can see from the software whether a train is on a siding, train with engine, or no train at all.

The main level of the layout is mostly complete, but there are plans for additional levels, and the layout features several huge helixes.  All visible mainline track is Code 83, sidings are Code 70, and there is some Code 55, and all visible turnouts are hand built.  There’s also a tram system that runs on one part of the layout.  Rolling stock varies but includes locomotives from Atlas, Athearn, and Kato. The president of Kato has visited from Japan and brought with him a gift of a few locomotives and some passenger cars.

soda machine

The TMRC receives no financial support from MIT other than free use of the space.  Just like in the late 50s (and covered in the book Hackers), the TMRC is supported from the proceeds that are made by selling soda from a machine in the hallway, and they turn a tidy profit according to Purbrick. A hand scrawled note affixed to the machine explains where the profits go and encourages patrons to email soda suggestions to the club for inclusion on the menu.

These days there aren’t many members left, apparently.  Maybe a dozen or so, although anyone can join. There was only one other member there while we visited, and the club struggles to get enough people together for operating sessions. Apparently there are several other thriving clubs in the area, but I wondered if there wouldn’t be a population of students out there who might not know of the TMRC’s heritage, it’s incredibly complex computer control system, and its delightful layout?

playing tetris on a buildingAs we made our way out at the end of the tour, Mr. Purbrick told us that we couldn’t leave without seeing the Tetris building.  From the hallway looking through the windows onto the layout, there is a control box.  When activated, the iconic tetris music begins to play, and the windows of the skyscraper light up to represent tetris blocks, which descend.  You can play a game of tetris represented on the windows of a building modelled by the TMRC, all powered by custom software and hardware components.  The creator of Tetris himself has been by to see this particular implementation, and while it wasn’t quite finished, he is said to have given it his approval.

“It’s one of our better hacks,” said John Purbrick, and I couldn’t agree more.

I’ve Never Wished I Was Less Technical

I got an early-ish start with computers when I was about 6 or 7 years old.  My dad created an MS-DOS boot disk that got me to a DOS prompt on the one of the hard diskless IBM clones in his office.  Once I had booted to the command line, I’d put another floppy disk (these were 5.25 inch floppies, the ones that really flopped) in the B drive, type in the commands which I quickly memorised, and my six year old self would be ready for some hardcore word processing.  Using Multimate at first, but then moving on to PC Write, I penned a few short stories and would love to visit the office and use the computers.  My Dad’s staff even gave me access to the holy of holies – the one real IBM PC (not a clone) which had a 5 megabyte hard disk, and was protected by a password.  I was solemnly lectured to never disclose the password, not to anyone, and I never have, even to this day.

And so it was against this backdrop that I became interested in computers.  When I was nine my family bought our first computer from a back alley vendor in the Philippines.  It was an IBM compatible XT Turbo, which was technically an 8088, with a twenty megabyte hard disk and a monochrome CGA monitor.  It was outdated when we bought it, as the 386 had just been released, but I loved it.  I spent hours learning different software packages like Norton Commander, PC-Tools, and playing games like the Commander Keen trilogy.  We kept it until I was twelve, and then gave it to a Chinese friend when we replaced it with a 486 DX-33 we picked up in Hong Kong.  Built like a tank, it is probably still in operation somewhere.

Despite this early introduction to computers, I didn’t get started programming until I was sixteen.  It was harder then – we had just got the internet but the tutorials and blogs and wealth of easy information we have now didn’t exist.  It was also difficult to get the necessary software you needed – thanks to living in China I could buy a pirated copy of Borland C++ or Microsoft Visual C++ for about a dollar, but they were a bit overwhelming to setup.  I finally found someone who knew how to program and begged him into giving me a few sessions.  He had a book, helped me setup my compiler, and agreed to meet with me once a week to teach me.  I even managed to get these sessions accepted as school credit during my junior and senior year.  I still keep in touch with Erik now, and he was one of the groomsmen in my wedding.  Together we even managed to cobble together two “junk systems” from spare parts and after a few weeks of constant trial and error, we got Slackware running in 1998, still one of my proudest technical achievements.

Every American college bound student knows that their junior year of high school is crucial for getting accepted into their university of choice, and I began targeting computer science as my major.  I was heavily advised that I should focus on a business degree instead.  At the forefront of that group were several of my math teachers, who knew that I didn’t do well in that subject, but there were also many others who thought that I shouldn’t “waste” my people skills in a technical role.

But I was really enjoying programming!  My first real project was a string indexing program which could accept a block of text (much like this blog) and then create an alphabetical index of all the strings (words) and the number of times they appeared.  Written in C, I had to learn about memory management, debugging, data structures, file handling, functions, and a whole lot more.  It was way more mentally taxing than anything I’d ever done in school, and it required a ton of concentration.  I wasn’t bored like I often was in classes.  It was hard.  Erik would constantly challenge, berate, laugh at me, and most importantly, accurately assess me using an instructional style that I’d never been exposed to before – he only cared about the results, not the trying.

Although I was dead set on computer science, I really liked making money too.  My parents noticed this and for one semester during that crucial junior year they offered me financial rewards for grades achieved.  After I’d hosed my dad for over a hundred bucks due to my abnormally high grades that semester, he announced that “grades should be my own reward” and immediately discontinued the program.  There were plenty of people telling me that a degree in business would better suit these talents of mine, and if I was honest, at the time I knew they were probably right.  I was great in my non-science subjects, I could mail it in on papers and still get an A, and I knew that diligence, attention to detail, and math were weaknesses.  Getting a business degree would be stupidly easy.  Getting a computer science degree would be pretty hard, at least for me.

I was close to changing my mind when Erik mentioned, “You know, I’ve never wished I was less technical.”

This is advice that I really took to heart.  It rung true when I was seventeen.  It’s even more true today.

For me, the advantage that I incurred by getting a computer science degree meant that I could start my own consulting company and be one of the technical contributors while also being responsible for the business stuff.  It helped me obtain positions of leadership because I didn’t need technical middle men to explain things to me.  If things were going poorly, I could help manage the crisis effectively, and when things were going well I could explain why and point out the technical decisions that had carried us to success.

Guess what?  I got to do all the business stuff too!  Having a technical background has never limited my business acumen or hampered me in any way.  I haven’t coded for money since 2007, but I use my knowledge and experience every day, and I stay up to date with technology as much as possible.  I love it when our technical lead shows me the code behind the latest feature.  If anything, having an appreciation for complexity, code, and systems design has only helped me design and implement better budgets, business models, and pricing schemes.  I’ve never met any “business person” who is better than me at Excel, the language of business, and much of that stems from just knowing how to program.  This has made me the goto guy in almost every planning or budget meeting I’ve ever been in.

Unfortunately, it doesn’t work the other way.  People who aren’t technical will always struggle in any technically related environment.  I’ve met so many people who have struggled and struggled to make their great idea a reality chiefly because they weren’t technical, couldn’t contribute, couldn’t cut through the bullshit, and therefore couldn’t effectively manage their way to success.  Sometimes, they’ll try to fake it and just lose the respect of the programmers.  As many times as I’ve thought to myself how glad I am that I have a technical background, I’ve had others voice to me the frustration that they just wish they knew more about technology.

If you’re reading this, and you’re trying to figure out which way to go in life, make sure you get technical first.  If you didn’t choose that path, there’s still plenty of time – get out there and learn to code.  There are so many resources.

This is what the “everyone should learn to code” movement is really saying – not that everyone should be a coder, but that everyone could benefit from understanding the environment, pressures, and disciplines that drive a huge part of our economy.  It’s not just business either – artists can benefit from more creative displays and better performing websites, not-for-profits could benefit from volunteers who know how to help out in technical areas, and it’s just nice sometimes to be the guy who can get the projector working in a foreign country!

So get technical.  You’ll never regret it.  And if you’re a programmer and you ever see a kid who wants to learn, help them out, you may just find a friend for life.

We Consistently Underestimate Kids

I’ve long believed that we seriously underestimate kids.  Hanging around with my friend’s daughters who were 2, 3, and 5 when I was in college was really illuminating as I found myself interacting and conversing with his (admittedly smart) 2 year old daughter on a level that we often wouldn’t even attempt with highschoolers.

I have a very clear memory of being nine years old, reading an autobiography about a family who adopted several kids.  At some point they became stranded in an airport.  Don’t worry though!  It was no problem the author (and mother) helpfully pointed out, because nothing fascinates a nine year old like riding the elevator up and down for hours.  What a load of crap, I thought to my nine year old self.  It’s like that mom thinks we’re mentally disabled or something.

As a parent (I have very little additional advice and zero experience in this area) don’t be afraid to expose your kids to things that might seem advanced for a child.  Check out this video of 7 year old Philip explaining how he programmed his first video game on a Raspberry Pi computer his dad bought and helped him configure.  I guarantee you there are huge portions of the adult population who couldn’t follow his instructions or achieve what he’s completed.  There’s nothing quite like a curious kid who sets their mind to something.  Nice job Philip and well done by his parents!

Simplify Everything

There’s a lot of abstract advice about employing simplicity when building great products or writing great code.  However, life and products (particularly in the Enterprise software market, where I’ve spent most of my career) are complicated.  It’s often hard to gleen concrete examples of what these maxims are trying to communicate.

The other day I was in a pub waiting for a lunch meeting to start and I got to witness the week’s beer delivery.  This is a fairly hard problem to solve efficiently if you’re in a city where parking is difficult (or nonexistent), buildings were constructed hundreds of years before accessibility laws (meaning stairs and tight doorways), kegs are very heavy (over 200 pounds when full), and where a lot of beer is consumed requiring frequent deliveries.

If you or I were designing a solution to this problem, we might come up with this solution:

  • 1 truck
  • 2 employees (1 driver, 1 loader/unloader)
  • 1 automatic lift at the rear or on the side of the truck
  • 1 appliance dolly that can move up or down stairs

We’d be pretty happy with that.  Not the worst solution in the world.  It’s possible we could reduce to one employee but the automatic lift will take enough time setting up and lifting that we’ll probably exceed our very short “stop with flashers on” window.  We’d therefore need to park and have someone stay with the truck, or make several “fly byes” to stay within the unloading time limit.  This will really limit how many delivers we could make in a day, possibly requiring a lot of delivery crews.

Here’s how they actually do it:

  • 1 truck
  • 1 driver / unloader
  • 1 airbag

The driver pulls up, parks the truck right outside the entrance of the pub with the flashers on, whips out his airbag from the passenger seat, rolls up the side of the truck, pulls off the keg and lets it fall right on the airbag.  He then rolls it into the pub (for those with cellar keg storage, they have their own airbag) and after about 20 kegs and less than 5 minutes, he’s out of there.

A lot less cost, a lot faster, and no expensive equipment.  

Simple.

Img_0871

I’ll Probably Never Hire Another Pure SysAdmin

NOTE: Updated Oct 17, See Below

This is a thought that’s been percolating around in my head for the last year or so, but has recently become even more crystalized: I’ll probably never hire another Systems Administrator.  A corollary to this thought would be: if you are currently a Systems Administrator or want to be one, you need to seriously begin planning on how to manage a career that will be mostly deprecated within the next 10 years.

Take a look at the current state of the art in cloud computing:

  • Spin up a server at your favor cloud provider (AWS, Rackspace, etc.), then use Puppet or Chef to deploy your software stack.  Now you’re done.
  • OR, Spin up an App at your favorite cloud platform provider, then push your code out using Git.  Now you’re done.
  • For both solutions, plug in some off-the-shelf monitoring, and you’re operating.

What’s missing here is the configuration, setup, provisioning, doc writing, black magic and/or prayer of setting up the software, hardware, and getting the code running that used to be the domain of the Systems Administrator.  In just a couple of years, deploying a web application has now become almost identical to deploying a desktop application – instead of an installer we’re using Git or Puppet/Chef. Instead of a customer’s computer we’re using a cloud platform or cloud server.

There’s plenty still to do on the networking side, but that’s headed in the same exact direction due to the same exact reasons: we want to be able to clearly define and programmatically execute the deployment of complex networks, just like we can with complex server offerings.

All of this falls under yet another buzzword: Dev/Ops.  Just like the cloud, we’re seeing this being adopted by smaller, nimbler organizations that are focused on web products, but the trend is clear, and there’s really no benefit in doing things the Old Way.  Even if you’re still running your own physical metal servers, you’re going to want to make sure that your own datacenter can leverage this type of workflow.  Now, the watchword to the development team is: it’s not done until I can one-click deploy it.

The laggards on this will be those industries that have regulatory or legal hurdles to overcome with using cloud services (read: healthcare) or the very large companies with services and technology that’s dozens of years old with no migration plan.

SysAdmins and future SysAdmins, you need to figure out where you’ll live in this new workflow.  Probably in the margins around monitoring or desktop support.  Possibly serving as the gatekeeper in a sort of “operations Q/A” role.  Expect small companies to have SysAdmin openings dry up over the next 5-10 years and get prepared.

Updated October 17: Hello Reddit/r/programming and Hacker News!  I wanted to take a few minutes and respond to a few themes that seemed to pop up in comments on HN and Reddit.

  1. I’m not saying Sysadminning is dead – just that the role is quickly changing.  Seems like a lot of people (anecdotally, many Sysadmins) thought I was saying the entire profession is dead.  Yes of course we’ll still need Sysadmins on some level, but the crucial difference is that for many areas of a business these needs will be less and much much different.
  2. Software development is changing too.  On complex deployments, developers can’t absolve themselves of the responsibility to design infrastructure considerations into the solution they’re building on the front end.  It’s a scary thought to think that organizations are out there that don’t have this level of partnership between ops and the devs.  This is why the puppet scripts should be written first and deployed on a test environment that’s identical in as many ways as possible to the ultimate operating environment (another benefit of using the cloud).
  3. Of course, any more complex deployment will need devoted SysAdmins, but like I said above, the skillset and day-to-day job will be dramatically different when wrestling with hundreds of servers instead of dozens.  More and more programming will become the norm and more and more upfront input into the solution will be an absolute requirement.
  4. I received a very thoughtful email from a former SysAdmin of mine (previous company) who pointed out that the job is much more along “system integrator” lines now, and that the internal vs. external network distinction is essentially going away.  I agree.
  5. Whenever your’e generalizing, counter examples abound.  Sure big companies and certain computing environments will still do things the Old Way but I’d challenge readers to objectively think if most business decision makers really want to hire someone and run their email server internally or just pay Rackspace/Google/Whomever to do it and worry instead about their money-making applications.  Even those organizations that need their clusters in house will invest in tech that allows them to mimic cloud operations on their own bare metal infrastructure.
  6. A couple of amusing anecdotes – the comments on HN immediately became more positive after a well known commenter defended the post, and a Googler chimed in as well.  That’s when the upvotes really started coming it seems.  On Reddit, the story was quickly downvoted!  Most users chose either a “genius” or “idiot” assessment of the post.  No real middle ground.

 

More Easy Fun With Telephony

Recently I decided I needed a little more flexibility with my phone situation.  Years ago I was carrying two cell phones and had three Vonage lines while running my own business.  This got consolidated down to a single iPhone, but that can be a little problematic particularly if you’re calling to/from international numbers.  This week I ported my iPhone number to Google Voice (within 24 hours too), and got a new phone number for my cell that I’m hoping to keep private and function as a throwaway.  However, I needed a bit more flexibility on some of the things I wanted to do, so I threw Tropo into the mix.  Twilio lost out because Tropo provides free inbound and outbound calling.So here’s the path when you call my number:  call comes into Google Voice, which forwards the call to my Tropo application, which then plays a menu and you can either punch out to Sentry’s main number or continue to ring my cell.  Text messages are forwarded by Google Voice, and the net result is that for inbound calls, I’ve effectively decoupled the phone number I’ve had for seven years from any handset or location and added a whole bunch of flexibility.It’s almost eerie how much power Tropo gives you over your telecom setup.  With a few lines of code I can transfer calls, accept inbound international calls with a local number, kick out text messages, provide a menu, have their computer voice speak any text I want, etc.  Call quality is crystal clear through both Google and Tropo, and I have yet to have any reliability problems.  In 2004 we thought it was amazing replacing a 150k Avaya PBX with Asterisk, but this is replacing all of that with about twenty lines of code.  For free.  With no setup or ongoing hardware or maintenance costs.I’d say the only real drawback to the situation is the inability to spoof outbound caller id with native dialing – it would be interesting to see if Apple allows you too hook other providers into it’s native dialer (yeah right) or if this is a feature within Android.  It definitely needs to be implemented at some point – and then we’d have true telecom nirvana.

Open the Gate!

The last three places we’ve lived in South Florida were “gated communities” which is supposed to make you feel exclusive and special.  They provide zero additional security (had a car stolen from one of them in the middle of the night) are often broken, and even when they work they’re a pain.  All of our gated communities would link your personal code to a phone number of yours, and when visitors keyed in “112” it would ring your phone.This causes problems:

  • The gate dialer can only link to one phone.  If your wife is traveling and you want some pizza to be delivered, the wife may not be able to pickup the phone and press 6 to let the pizza in.
  • Most can only link to one or two area codes.  One of the systems could only link to a 954 area code number.
  • If you’re riding with someone else and don’t have your remote with you, you can’t get in if your wife isn’t with you, or has the cell phone in a bag in your trunk.

The Wife has been out of town for a few days and this finally irritated me to the point where I headed over to Tropo.com and provisioned a simple phone application.  Now when you dial the phone number of my Tropo app, it answers, says “Opening the Gate!” and plays a number 6 key press which tells the gate to open.  Perfect.I heard about Tropo out at CodeConf in San Francisco and have wanted to play with it but didn’t have a problem to solve until now.  The entire thing took about 10 minutes to setup with the only really painful thing being the hunting down of a key press sound from http://www.freesound.org/ and the subsequent conversion to a GSM format.  I ended up using the excellent Sox command line sound converter to make the conversion, and then we’re in business.  Total cost for the whole thing was zero dollars.The Tropo service is really nice and their documentation is good too.  Their UI for their website is a little clunky in spots.  For example, picking an area code for your number is really painful with about 50 city suggestions and no way to search for an area code or specific city.  They’re not alphabetized as far as I can tell either and the city names are super specific so it just makes it hard.  Also, I couldn’t find a way in their API to generate a key press tone which meant I had to mess with my own sound files.  That should be built right in or they should provision a directory of key press sounds with your default files.All in all a fun little project to get done while on Amtrak bound for Orlando, and now I can open my gate whenever I want.  Tropo has done a great job with their platform and I’d highly recommend it for these types of tools or any kind of telephony or communications application.

Jeopardy and Watson

We had a great time last night watching Watson take on two humans in a round of Jeopardy.  Or at least, I had a great time.  The wife and her sister weren’t quite as into it as I was, but they watched it just the same.Here’s a recap:

  • The show did a great job explaining what was happening (they burned half the episode on explanations).
  • It’s interesting how most people don’t understand what the true challenge of this event is (even techies) – Watson has huge volumes of information (he knows a lot of stuff), but the real challenge is understanding the meaning behind a question.  In other words, it’s an understanding/comprehension challenge, not a fact challenge.
  • IBM came up with a really neat tool that showed the audience how Watson was playing the game.  They would show the top three answers he came up with and a confidence interval.  Watson would buzz in with the highest rated answer that crossed the confidence interval.  If none of the answers made it across the threshold, he wouldn’t buzz in.
  • Alex Trebek gave a tour of the datacenter which had ten-ish racks of IBM servers.  The size of the install was very surprising to our non-technical viewers.
  • Watson glows green when he’s confident in his answers, and when he gets one wrong, he glows orange.  This feature was a big hit at our house.
  • Two perfect examples came to light exposing the difficulty of this challenge.  One question made references to the Harry Potter world and a dark lord who challenged him.  It was clearly a Harry Potter question due to the contextual clues, but the answer was “Lord Voldemort”.  Watson answered “Harry Potter”, but his second choice answer was “Lord Voldemort”.  A human who understood the meaning of the question would never have answered in that way.  The second occasion involved Jennings answering “the twenties” to a question, which was wrong.  Watson buzzed in right after him and answered, “the twenties,” which no human would ever do.

One question I had was if the text transfer of the questions happens in step with Alex Trebek’s reading of them.  Does it happen character by character or does Watson get a few precious seconds while humans are reading the screens?  Conspiracy theorists would probably ask how Watson’s first choice was an 800 dollar question (unusual) and he hit the daily double immediately, but it could be part of the IBM team’s strategy.All in all, that was probably the most fun I’ve had watching a TV game show.  Looking forward to the next two episodes.

Jeopardy, Artificial Intelligence, and a Chess Playing Robot

Tomorrow Jeopardy will feature a computer facing off against former champions Ken Jennings and Brad Rutter.  I have been looking forward to this for a couple of months since I first heard about it, and it is an amazing feat of computer science that a computer can go head to head with humans on a game show as complex as Jeopardy.  IBM is the true leader in feats (stunts?) such as these having staged previous competitions against former chess master Garry Kasparov.  The show has already been filmed (in a special sound stage at IBM’s location) but I do have an inkling of what the engineering team probably went through prior to the event.

Artificial Intelligence

My freshman year in college, I managed to convince my professors that I could and should skip the computer science prerequisite for everything, COS120.  This put me into a data structures course in the first semester of my freshman year, and several linked lists and b-trees later, I was able to take any class I wanted in the spring.  I made  bee-line for a class called “Intro to Artificial Intelligence” as I was more than intrigued by the possibility that I could build Skynet and cause the human race its final doom.  Sweetening the pot was a rumor circulating the labs that the class would make use of the very recently released Lego Mindstorms.  Fulfilling the dreams of nerds and lego aficionados (with there being an admittedly strong correlation between the two groups) the Mindstorms were fantastically expensive to a college kid (several hundred bucks) and required programming knowledge to really make them hum along.  This AI class in other words was my ticket to Lego Nirvana, not the other way around.

Legos and LISP

I managed to sign up for the class and was one of (I think) two freshman.  Having spent high school and the fall semester doing work in C and C++ along with learning Perl and a new fangled language called PHP, it was quite a surprise to show up for class and begin learning LISP.  For those of you who are non-techies, LISP is a complete paradigm shift from how most programming languages allow you to express yourself.  The analogy might be like going from sketching in black and white to being handed multiple colors of modeling clay and being told to sculpt in three dimensions.  LISP is the oldest programming language still used in a mainstream capacity today.  LISP treats data and the program the same, so you can build a self modifying program which is one of the reasons Artificial Intelligence researchers and applications use it so much.  LISP has a weird looking “list based” syntax (LISP stands for LISt Processor) and allows you to solve weird problems in fairly elegant ways.  In fact, some like it so much and feel it is so powerful that LISP is the reason that Paul Graham (a well respected computer scientist and technology entrepreneur) credits for his business success. He felt he was able to elegantly and more efficiently out-build his competition simply because of their language choice.  I don’t really agree with Graham, but the point is that LISP is a very cool and very different language that was a pleasure to learn.  This class remains the only one in college where I did every single homework assignment.  The problems were just too fun and the ways of solving them were extremely different. Along with LISP of course came the Legos.  Almost immediately, we began building simple Lego robots that would following a line on the floor, be able to navigate a room, follow a light source in a dark room or navigate a maze.  It was unbelievably cool and a testament to Lego’s design prowess that their system allowed for such flexibility.  Each kit provided a command unit and several motors and sensors.  There was a touch sensor, light sensor, and a few others, and the command unit would download the programs via a cable hooked into a computer.  There was a Lego provided GUI-based way you could program the processor, but hackers had already provided several other languages, and we used Not Quite C (NQC) which was very similar to the C programming language with a few restrictions.

A Chess Playing Robot

All in all, we were having a blast, and just like kids get bored with a slide and start daring each other to go down backwards, or standing up, we began competing to build a bigger better robot.  Our professor was also the chair of the department, and he sensed he had something brewing, so he got the class together and challenged us to come up with a project that could bring fame and glory to our small liberal arts university.  A robot that could get us soda from the machine!  A robot to gather up homework assignments and drive them back to the professor!  Not as popular as the food or waiter suggestions.  Finally from the back of the class came the ultimate idea: a chess playing robot!  A senior in our class had been working on an independent study in addition to taking this class, and had produced a fairly workable Chess simulator, written in LISP.  The class began buzzing with excitement.  We could build the robot, then challenge students to beat it! I started to get a bad feeling about the project – building a Lego chess playing robot would be quite the undertaking.  My good friend Aaron Williamson upped the ante – “I could get the university TV station to film a match!”  Uh oh.  A third student offered to get one of the most popular professors in the school to face off against the robot, and just like that we had ourselves our very own TV spectacle: Man vs. Machine.  Nerds vs. Normals.  Technology (us) vs. Philosophy (the professor).

The work was divided up and we immediately had to start pulling late nights as we only had a few weeks to get everything together.  There would be a vision processing team (the robot had to know where the chess pieces were), a robotics team which would build the gantry crane and arm mechanisms, and the chess software team.  The Public Relations we soon learned, would take care of itself.  I was on the vision team, and our job, we felt, was quite possibly the hardest.  This was 2000, and web cameras were novel, low resolution, expensive, and rather rare.  At least, they were expensive for college students, so we used the only one we had available: a web camera attached to a Silicon Graphics O2 workstation that provided a 640×480 resolution color picture.  It provided enough resolution so we could film the board, and our algorithm would take one picture, save it, then take another after the human moved, and compare them to determine which two pieces had moved.  This seems pretty trivial, but it was complicated by a fisheye effect from the lens, and the fact that the robot arm (or human) wouldn’t actually place the pieces very accurately. Lighting and other conditions could also change depending on where the human was standing or for a host of seemingly random factors. As we started to work, even simple things seemed to derail us.  Silicon Graphics apparently used a proprietary RGB format which was reverse of standard RGB, so we had to write a converter.  Irix, the SGI OS, turned out to be a pain to develop for, at least compared to Linux, so we performed the processing on another computer.  This meant we also had to set up the workflow between the IRIX machine which captured the image, and the Linux machine which processed the image, and then interface with the robot and the chess playing program, which ran on another machine. The date for the campus wide demonstration was looming, and we were determined to not be humiliated.  The student newspaper ran a feature, and our opponent was quoted that “no hunk of metal would best him” to the delight of the student body.  

Media_httpwwwpeebsorg_gamba

Finally, the day was upon us, and we began preparing the lecture hall which would be ground zero.  We had lots of equipment to move from our basement computer lab to the lecture hall, and as we began calibrating everything alongside the film crew which was also setting up, we noticed that the vision system wasn’t working.  At all.  It couldn’t find the edges of the board, couldn’t determine the grid, and it couldn’t see which pieces had moved.  We were in trouble – the fluorescent lighting conditions of the basement worked but the incandescent lighting and TV lighting in the lecture hall didn’t and we needed to recalibrate everything.  Working like mad we began tracking down all intensity assumptions in our program and moving pieces around until finally we got it working. The format of the competition was designed so that while the computer was thinking we’d explain to the audience what was happening, and our opponent would also discuss the philosophical ramifications of sentient machines.  This was designed for another, secret reason – if something went wrong, we wanted to be able to troubleshoot without drawing too much attention.  We had a backdoor programmed into the chess program which could reset it if there was trouble, or in the event of a catastrophic failure, we could take over and manually play out the match.  The ethical dilemma of should we tell the audience what happened if that were to come to pass was hotly debated.

The clock struck 7:15, in came the audience, and on came the red blinking lights of the video cameras.  The lecture hall was packed out, and the professor did a great job making jokes as we introduced the event and briefly explained the rules.  Our class professor could have died of happiness at that moment.  As we began the competition, the professor picked white and made the first move.  “Take THAT you cold calculating MACHINE!” he proclaimed to resounding applause from the audience.  That pissed me off.  I had been championing a feature where the robot would insult and taunt its opponent with every move, but was shouted down for not being classy enough.  We had to endure a night of insults that could have been combatted and we all admitted in hindsight that we should fought fire with fire. At first, everything looked like it was going well.  The robot was working, it could see what was happening, and the chess program was making good decisions.  We started to relax a little, and the audience was clearly intrigued as the gantry crane would slowly move to the right spot, lower its arm, then grab the piece and move it.

Then disaster struck.  Just a few moves in, our opponent performed an En Passant which while being a rather esoteric move, also has the rather interesting distinction as Wikipedia puts it, as “the only occasion in chess in which a piece captures but does not move to the square of the captured piece.” Uh oh.  Our vision system was designed to look for what changed and was looking for either a move or a capture, not a weird combination of both.  Our program chose the two best coordinates to send which caused the chess program to have the wrong board information, and we watched in horror as the gantry crane moved into the wrong position, knocking over several pieces as it vainly swiped in air to make its move. “Uh oh, Houston, LOOKS LIKE WE HAVE A PROBLEM!” yelled our opponent as the crowd roared its approval, and he immediately launched into a discussion about how pure logic will never overcome the malleability of the human mind. It was chaos as we raced to reset the board, recalibrate the vision system, and instruct the chess program of the true state of the game.  I believe we had to simply reset the game state completely, in essence telling the computer that the game had started with the board situated the way it was since it didn’t understand an En Passant.  Things were looking up as the computer managed to make a move and actually captured a pawn to the crowd’s approval.  

For the next fifteen or so moves we each took turns giving a short talk about how the robot was built, the technologies we used, and the challenges we overcame. As the evening wore on, the game developed nicely.  I’m not a chess player but I could tell that the computer was holding its own and it could already beat everyone in the class, so we were optimistic about our chances.  Still, it was roughly an hour into the game and even though I wasn’t following every move closely it was a surprise when all of a sudden the professor announced “Checkmate!”  I looked over at the board and it was indeed checkmate!  However, the computer didn’t agree.  Turns out that either during the initial setup of the board or during the insane scramble to fix our En Passant adventure, someone had incorrectly placed the King and Queen on the computer’s side.  The computer had been defending its queen instead of its king, and thus had fallen prematurely. A disappointing end to what would end up being one of the most memorable projects of my college career.  Still, we couldn’t help but feel proud of being able to build something unique and stage a public spectacle of sorts that everyone seemed to enjoy.  Tomorrow as I tune into watch Watson and the team from IBM, I have a small sense of how they’ll be feeling, and win or lose (there are already rumors leaking out as to the results) it is an incredible achievement.  Congratulations and good luck!

Postscript:

Christmas – a Time of Giving

Normally around Christmas people are focused on giving.  Giving to family, friends, maybe even coworkers.  Some give time to charities, some make donations to others.  One of my annual traditions for Christmas is giving to the Electronic Frontier Foundation (EFF), a digital liberties organization that fights for freedom of speech online, privacy, and other causes that are generally too technical to garner attention from other organizations.

This year I’m adding a very similar organization to my annual Christmas list, Software Freedom Law Center (Hi Aaron!),  which similarly advocates for issues that increasingly plague and impact our lives, whether we understand them or not.With all the buzz going on right now about Wikileaks maybe you’ve thought about these issues a little more than normal.

Depending on your understanding of the issue or political orientation, it might be hard to believe, but freedom of speech online is a relatively fragile thing.  Maybe it’s because technology appears to be finite and controllable, maybe it’s because online speech travels much faster and is easier to consume, but it seems that governments and governing bodies tend to naturally flock towards the idea of speech regulation of technical mediums.Groups like the Software Freedom Law Center and the Electronic Frontier Foundation work to preserve freedoms on our behalf.

When I say “freedom of speech online” or “freedom online”, we’re also talking about fighting against overly broad software patents, violators of the GPL, warrantless wiretapping of online communications, and a whole bunch of other issues that may seem only tangentially related to speech, but do impact your voice online.In addition to the work they do, I’ve had the privilege of interacting with and knowing a few individuals from both organizations, and they’re great people as well!  So Merry Christmas, and if you’re looking for a great gift idea or a cause to support, check out both groups.