Ideate, Model, TEST! A long, behind-the-scenes look at 2.009 by Michael C. '16
like, really long.
Clockwise from top right: sketch model review, sketch model review (on a real stall), mockup review, final alpha prototype on stage. Top left photo by John Chow.
End-of-the-semester class presentations are usually pretty dry events. Busy PowerPoint slides, droning presenters – “excitement,” “magic” and “this made me want to switch majors” aren’t phrases often heard in the audience.
Then again, most class presentations don’t involve a live band, an audience of 3300, and an overall class budget of a half million dollars.
Under the tutelage of Professor David Wallace, MIT’s senior capstone mechanical engineering product design class (known as 2.009) has steadily grown into a huge spectacle that attracts audience members from around the globe. It’s the closest thing you’ll find at MIT to the campus spirit-unifying atmosphere of a football game. Over the course of the 3+ hour event, 8 teams reveal the products they’ve been working on over the semester.
But while the presentations are exceptionally polished, with massive props and huge numbers of support staff behind the scenes (one presentation this year involved two people rappelling from the ceiling of the auditorium; my team's involved a real toilet on stage), the products don’t start out that way. The theme of this year’s presentation was “magic,” but it wasn’t magic that created these products – it was engineering, design, and good old-fashioned hard work.
While a product is a very tangible thing, every product starts out as an idea. And ideas are decidedly less tangible – they’re fuzzy, often hard to express, and even harder to convey convincingly to others. The difference between a great idea and a lousy idea isn’t always clear when you’re just verbally discussing it. Some people are better at being louder in meetings, at expressing their ideas first; this has little correlation with which ideas are actually good.
But this process of structured ideation is incredibly important, because it's these early design decisions that drive months of work. It's one of my favorite things about product design – every tangible thing starts off as a conversation, as a thought. It's the reason why 2.009 is called "Product Engineering Process", with an emphasis on Process: roughly half the class is spent on the process of generating and mocking up ideas, with only the last month focusing on building up an alpha prototype of one particular idea.
Apple’s head designer Jony Ive recently described many university design programs as “tragic” – because “so many of the designers that we interview don’t know how to make stuff, because workshops in design schools are expensive and computers are cheaper.” He added that students were being taught to use computer programs to make renderings that could “make a dreadful design look really palatable”.
A photo from the Build Challenge. Students sketched out ideas, which were then converted to kits and assembled by students in an hour.
The spirit of 2.009 couldn’t be farther from that of the design programs that Jony disparaged. 2.009’s motto is “Ideate, Model, Test.” Even though Computer-Aided Design (CAD) software is ubiquitous these days in mechanical engineering courses, a huge focus of 2.009 is trying to prove out ideas as quickly as possible. Often, making a computer 3D model isn’t the best way to start an idea. Instead, fast and low-fidelity mockups (like rough cutting blocks of foam, or using quick-fabrication methods like laser cutting) can be better ways for exploring ideas.
It’s not cheap to have such a big focus on physical models (one early build challenge cost $20k alone), but it’s the right way to teach the product design process. At the beginning of the semester, students start with primitive “sketch models” to pitch their ideas. As ideas get cut and refined, so too do the manufacturing processes. 3D printers, waterjet cutters, CNC mills, thermoforming chambers – few manufacturing processes are inaccessible to students.
A quick, functioning prototype for a foam wire cutter. Mocked up in 5 minutes.
Each team of 20 students gets a budget of $6500 for the three months of 2.009. Most teams will use all of this budget, and more. The biggest cost isn’t monetary, but in person-hours; students will regularly pull all-nighters and stay in lab til 3am (or later) before major deadlines throughout the semester. One student’s only sleep in 2 days was 45 minutes lying in the back of an ATV in a drafty loading dock.
3 weeks before final presentations
The hours take their toll, but they’re also reflected in the prototypes. Earlier on in the semester, my team's sketch model, conceived and built in less than 24 hours, wowed reviewers with its laser cut acrylic parts, high degree of fit and finish, and working sensors. Purple is the only morning lab section, and we joke that we're the “tryhard” team. Perhaps coincidentally, in the course cartoon video the Purple team is caricatured with a nerdy glasses-wearing rabbit.
For the Technical Review, however, we're in decidedly worse shape. It’s 1 hour until instructors will be coming by to examine the prototype of our self-opening and locking restroom door, and nothing is working. The team has split into several subteams: locking, opening, sensors, and enclosure. While the mechanisms are all machined and laser cut, and the laser cut enclosure looks great, the sensors are glitching.
Two of our team’s stronger coders sit with brows furrowed next to the door. After an hour of debugging, they’re still not sure what is causing the microcontroller to intermittently shut itself off and restart. But there’s no time left – the first round of reviewers is heading in. We're forced to explain our progress so far without an actual working prototype, and the first round of reviews is disappointing.
By the second round of reviewers, we've identified the problem – the motor for the opening mechanism is drawing too much current, causing the current to the Arduino to briefly drop, leading to a reset. The solution – plugging the Arduino into a laptop during the demonstration – isn’t ideal. A huge amount of work had gone into making sure the device could be battery-powered and compact. But having something to show is at least better than having nothing but words. The prototype at least shows the mechanical progress and sensing progress that the team has made over the past two weeks.
Clockwise from top left: a small prayer before we close up the enclosure; the laser cut enclosure, in front of several failed laser cutting attempts that took me at least 6 hours to oversee; Josh B. and Sally M., working on the tech review model before reviewers come; our full tech review model.
The next few rounds of reviewers go much better. Having a working prototype makes all the difference, and Purple’s presenters refine their pitches and explanations as they get more practice. One reviewer’s comment that “why haven’t you patented this yet?” reinvigorates the team just as energy is starting to dip.
By 11pm, the reviewers are finally all gone. The few stragglers from Purple team finish up cleaning up the lab space, and head home.
It’s time to sleep.
3 days until final presentations
Purple's presentation team is meeting in the fishbowl lounge, which is what we affectionately call 3-144. We have three presenters (Jarrod, Sally, and Camilo), and three additional question answerers (me, Sophia, Eric).
We're preparing our presentation quite differently from other teams. Most teams have presenters working on their own slides, writing their own scripts, then trying to integrate at the end. Instead, I'm essentially directing the presentation – making the whole slide deck, writing the script, and trying to coordinate across our presenters' very different styles. The goal is to have a very unified slide deck with a clear and coherent structure. In fact, I'm aiming to not have our presenters use clickers to advance slides on stage; someone backstage will have memorized the script and transitions so well that there will be no need for presenters to change slides themselves.
That's the idea, at least. Things don't go great in our first runthrough in front of lab instructors. The main source of friction is between myself and a presenter; we each have strong, clear ideas of what an effective presentation should be like. On the presentation spectrum of "conversational" to "showman", I'm decidedly in the former camp and he is decidely in the latter camp.
Things get heated. Voices are raised. We decide to adjourn the meeting and cool off for a bit.
1 day until final presentations
The presentation team is doing much better. We've unified on a script, and drawn the best elements from different people's respective styles. While we still have a lot of rehearsal to do, we're definitely on the right track.
Presentation practice in an empty classroom.
One thing I'm proud of is that we spend a lot of time getting details right. For example, our product explosions are unparalleled by any other team's, and that's because we spend a lot of effort on them. SolidWorks is capable of generating exploding animations, but the motions aren't up to my standards of smoothness; additionally, using a SolidWorks animation gives us less control on timing. So instead, I have Eric (our SolidWorks professional) generate high-DPI images of each individual part – each bevel gear, each motor, each aluminum plate. I remove the backgrounds on the images and painstakingly stitch them together in Keynote, until they match the correct part positions in SolidWorks. Then, using Keynote's Magic Move feature, I "explode" each part to a subsequent slide.
It takes an insane amount of time relative to the effort it takes to generate a quick SolidWorks animation. But to me, it's not about doing what's fast, it's about doing what's right. The whole team spent hours and hours designing and fabricating our product, and I'm not about to present it in a shoddy way in front of 3300 people.
I think the results are well worth it:
The actual prototype, on the other hand, is in a minor crisis. All of the individual components are built and (mostly assembled), but the whole product hasn't been integrated yet. Which means that there are less than 24 hours to go and we still don't have a product to demo.
Sometime around 4am, someone Slacks out a video of the prototype working. We cheer. Everything is finally coming together.
5 hours before final presentations
Everything is not coming together. We're seeing our board intermittently resetting again. It seems like the same issue we had with the Arduino during Tech Review, 3 weeks ago. Except that this time, plugging our product into a laptop is not an option. Josh hasn't properly slept in around a week. The problem seems to be that we're running off just the controller on our PCB, which has no power regulator; when the opening motor operates we're seeing a current drop again. The quick hack is to add a complete Arduino, which has a power regulator, in series before our board is connected to power. This keeps the current steady to the board, and it seems to fix the problem.
Crisis averted. For now.
1 minute before final presentations
Camilo, Jarrod, and Sally have missed almost all of the previous teams' presentations because they're backstage trying to test our product as many times as possible. I'm told that it's worked 60 times in a row. There's really nothing we could change now anyway.
3, 2, 1, go.
As Jarrod begins the live demo, I think I can hear Purple Team collectively holding its breath. Sally walks through the door, turns around and…
…IT CLOSES AND LOCKS!!!! The Purple section of the auditorium doesn't cheer, it roars. I'm pretty sure I can distinctly hear Max in that cacophony of noise.
In fact, we're able to demonstrate the product working 3 times live during our presentation, which is pretty uncommon for a 2.009 demo, and especially important for a product that absolutely needs to be reliable.
2.009 photos by John Chow
During the Q&A session, I get a question that involves poop. Or at least my answer involves poop. My phone blows up with approximately 34283 poop emoji texts.
And…that's it! It's surreal that 2.009 is over. I still remember attending 2.009 as a freshman, then a sophomore, then a junior – thinking that I couldn't wait until it was my turn. It was incredible actually being on stage when the confetti fell.
Good luck, future Course 2's. I can't wait to see what you build.