I think I’ve promised a 2.00gokart “total recap post” after every session of it so far. This is a piece that is long overdue on this site, and in all honesty, probably also way past its time to present in a more formal venue. For the past now 2 years and four sessions, what I consider to be my most long and extensive project has been developing quietly in the halls here at MIT – that is, as quiet as the high-pitched whine of square-wave commutated brushless airplane motors can get you, anyway, interrupted periodically by the interdiction of concrete-backed drywall upon metal; facilities and my space directors will never let me live that down.

I’m two months late and running from when I first said to expect a wrapup of the summer SUTD special session I ran for their visiting students.  What this post will be is a ton of writing. Interspersed with as many photos and references as I can manage, of course, in my usual style of discourse, but most of it will be me waxing poetic – and perhaps polemic at times – regarding my own motivations to start this course, experiences in running it, and ultimately what my end goals are and where I want to see this class end up.

I anticipate this post being extremely long. In fact, so long that I’m going to split it into multiple sections ahead of time. In fact, it’s going to be so damned long I’m already at 1200 words and I haven’t said anything. What will be presented from here on is basically a much more concise, casual, and perhaps more profane and offensive version of my original Master’s Thesis, minus most of the the graphs and tables (because every Master’s Thesis in engineering needs graphs and tables, for whatever reason), and with more pictures and videos. The first two parts essentially amounts to me ranting, and the second half is the productive info, followed by more despotic proselytizing.

Here’s the table of contents: First, a summary of my motivation for making the class. Next,

A brief rundown of my own history with engineering projects and how that both aided and hindered my academic performance at MIT

How I took an interest in teaching and why I saw issues with the current system of design classes

A history of my involvement and leadership in the electric vehicle design realm

Recap of the 2012 class “2.00scooter”

The changes made for the 2013 class “2.00gokart”

The 2013 summer special session and the changes made for it

Where the class stands now; content, procedural, and logistics.

What I think the class brings to the world of design classes that is different or novel.

More about the resource base of the class and the cost of running

An SAE Asston (like an ISO/DIN Arsetonne) of lecture notes, resources, and links I have built up so you can run your own silly go-kart class

about 2.00gokart

Here’s the short story: “2.00gokart” is my shorthand project code referring to the undergraduate sophomore/freshman level Mechanical Engineering lab class I have been developing for the past two years at MIT, both as a graduate student and as a full-time instructor, that takes a step back from the traditional guided structure of an engineering design class and instead pushes students to learn engineering skills more akin to what they will find in real-world projects, including: being given open-ended design goals, self-defined scoping and design constraints, discovering and analyzing own parts and resources, and validation of the final product through physical demonstration.

In other words, I’m going to make you build a go-kart – I’m not even saying what kind, or how; I’m going to make your find your own damned parts and tell me why you think they will work, and then I will make you ride it… and you can’t pretend or make up that last part. The emphasis of the class is on the first two ‘bullet points’ – self-directed goals and constraints, and seeking resources, including parts. You can find myriad engineering project classes that will tell you “adhere to this set of demands or constraints and show that your product meets them physically”, but few, if any, that load the emphasis instead on how to define a project given almost no demands, hunt for the resources to execute it, and compromising and changing your design to accept what resources you have.

I’ll be blunt: These tenets are based strongly off my own experiences in building dozens (like actually dozens) of admittedly some times half-baked engineering projects before, during, and after my career at MIT as a student. My lack of thoroughness in the engineering science portion of these projects is completely in the open and not up for dispute. What I learned by reading through the lines during my undergrad career was that there was a seemingly inexorable disconnect between the goals of a design class and the goals of an engineering class. Here’s how I see it: An engineering class teaches you to use a theoretical and analytical approach to solve a well-defined problem, and a design class teaches you to use a practical approach backed by engineering science to solve an ill-defined or open-ended problem. It sounds like the theory should come first and then jack into the practice, but I’ll talk about how I do not think that is the case shortly.

I have seen it happen over and over again. A Certain Scientific Department becoming uneasy with how ‘theoretical’ it has become, and with news of other universities’ more ‘hands-on’ approach to engineering making a comeback, tries to add a lab or design component to a class that in recent history has been entirely on paper. The students have never been exposed to real parts and processes before; maybe a few of them have, from their own personal experience in years past. The groups form, there’s much struggle and frustration at how stuff just doesn’t work as well in real life as they do in Solidworks or Matlab, and in the end, maybe one or two projects “work” and everyone else leaves with a really dim view of project classes in general, and some start resenting the Department for ‘not teaching them anything useful’. Does this sound familiar to you?

This is where my personal bias from past experience comes in – and again, I am completely upfront about it: This class is about doing it my way, and you should keep that in mind as you read. The way I learned to do this was the complete opposite. I began messing with things, I built things that may not have worked, I came and learned about why they didn’t work so I could build better things. This is, superficially, what the story of an engineering degree should be. But my years of experience prior to even coming to school to learn about it meant that when it came time to act, I not only acted because it was damn near second nature to do so, but was a resource for everyone else who had never needed to “act” – or perhaps, just flat out did not know how to. I don’t mean that in the derogatory sense – you literally could have never built anything in your life before, and that was totally fine, because let’s be really honest here and admit first that the vast, vast majority of engineering majors do not come into school already being engineering majors – the school has to teach them from start to finish, everything they need to know to be competent engineers.

My whole thesis, if it had to be boiled and distilled and refined down, is this: Give students the tools of practicality and channel their creativity first, and supplement them with the knowledge of theory and science later. When you’re trapped on the proverbial deserted tropical island, you occupy yourself with survival and make-do first, then figure out how to get off the damn island. Right now, it is my contention that we teach people ocean currents, wind patterns, and sailing first, and assume they know how to build the boat to use it already. The boat will most likely sink, and it will not be the Arduino’s fault this time.

(Acknowledgements: I’d like to thank my parents, and my… uhh, bottle of Tap Magic Aluminum here… and, like, this motor controller? *rummages around* Oh, and Hatsune Miku)

(Serious acknowledgements: The MIT Mechanical Engineering Department, the MIT-SUTD Collaboration, the Pappalardo Laboratory staff and director R. Fenner, and Profs. Frey, Wallace, Hunter, Slocum, Sarma, and any other Mechanical Engineering professor and administrative staff, for basically just putting up with my bullshit for 5 and some years and counting.)

1. My History in Building Engineering Projects for The Lulz; or, A Brief Biography of Charles

I’m loving these 1800s era compound titles.

Here’s something about me that surprises most people for some reason: I’m the only engineering blood in my family. I do not come from a long line of auto mechanics or machine shop owners, nor do my parents both work in an engineering, architectural, or design setting. In fact, one does something with finance and the other does something with IT for a major home furnishing and clothing department store, and that was only after I took off playing with silly robots. My grandparents used to play in a Chinese state orchestra, or were fish farmers – that half of the family I’ve never met in person so I’m going to assume they were fish farmers, but maybe I have a cousin in Northeastern China somewhere who builds sweet DIY robots from scrap metal. Which would explain everything, really.

My own history with engineering begins like that of any 11-year-old who was totally not supposed to be watching South Park in mid-2000 (MILLENIAL!) but was doing so anyway. After South Park one day, a strange show called Battlebots suddenly came on. That link is old – the current Battlebots.com website isn’t really much to look at – the sport has generally declined to the point where it is wholly decentralized and grassroots, and I don’t really have a good central link to point people to any more besides perhaps the Robot Fighting League forum or the Facebook group. Or my fleet page… Shameless plug over.

The robots themselves aren’t the focus here. What the intervening seven years between that first episode of Battlebots and when I left home for MIT taught me was that robots, or really building anything hands-on, was a silly hobby. My parents were supportive of my hobby, but they continually reminded me that I had to do well in classes, especially my computer science ones, and get into a good college and get a good job and a house and a wife and… hey, a shiny thing.

I do not blame them or want to shit on their efforts to make me successful. The takeaway here instead was that I found engineering to be a fun and nonserious distraction for longer than I have been told it was something more than that. My earliest robots…
were complete and utter horseshit
didn’t really work, to keep it politically correct. I rebuilt them, adding their failures to my knowledge base. I took things apart, I bought things just for taking apart (to my parents’ chagrin – aren’t I going to try using that first, maybe?) to incorporate into my latest death machine.

I still buy things just for taking them apart – we just call that Beyond Unboxing now.

In those seven years what I built up almost by accident was a extremely expansive lookup table of problems and solutions – stuff I’ve done which worked but I didn’t really know why yet. And I documented them furiously. Why? Because I knew I was going to have to come back to them later and finally understand why something happened the way it did, and because even back then I realized someone else besides me could find the information useful at some point in the future. Much of my learning during my earliest years was through hours and hours spent on builders’ websites who were gracious, or perhaps detail-oriented enough, to post their builds online back in an era when that was not just a one-click upload to a social network.

This is why I labor so intensively in blogging everything I build or do. I not only feel indebted to the old guard of Battlebots veterans for providing me with such valuable resources during my dawn, but also that it is my obligation to mark the trail for current and forthcoming generation of new builders and hackers and makers, many of which have already let me know how a single picture or post on this website has saved their asses or enlightened them. That’s fucking worth it.

I digress, but only slightly. I’ll explain how and why I incorporate this kind of public and open documentation into my “curriculum” in its relevant section.

Back to the story. My years of engineering practice prior to MIT admittedly made me a bit cocky when it came to building anything. That, combined with my attitude towards engineering as something fun and hilarious (instead of SRS BIDNESS) meant that I spent most of my undergrad career not paying attention to classes. I openly admit to and am proud to point out cherrypicking only what I found relevant to some project I had going on at the time and shutting out the rest. I spent way too much time at my UROP in the Media Lab‘s Smart Cities (now Changing Places) research group, exercising my skillset in constructing silly vehicles and learning new skills while I was at it, and irritating the shop managers with my incessant building of something which was

research-related at all
definitely for the group, guys, I swear!

My best performance in classes came when I had some project that was directly or indirectly relevant to them. I conceived Segfault during my early controls classes, but only got it right at the end when I took an intensive control systems design lab. It languished for an entire year in between, with multiple attempts at trying to make the balance controller work. LOLrioKart was a lesson in blowing up semiconductors over and over until a power electronics lab finally gave me the confidence to attack it correctly.  The classes I did the worst in were the ones that I couldn’t connect to anything I was building. The drudgery. Anyone who knows me will know how many times it took me to pass our ‘measurement and instrumentation’ class, which was basically heaps of statistical analysis and technical paper writing that I found completely irrelevant to anything I was interested in. Fluid mechanics was mostly a wash, as was pretty much all of solid mechanics and materials – you are hard pressed to get me to remember anything from those classes at all – they’re just distant memories at this point. Don’t even get me started on the Mechanical Engineering senior product design class.

Some people have said, in words or in meaning, that I avoided all the “hard” classes at MIT. Some times “hard” is replaced with “good”. I don’t deny this  – the aversion to classes is not an independent trait that I can trace start to finish and capture the all details to transmit them here. In fact, it was very much tied to my engineering identity at MIT, one that I was intentionally or otherwise cultivating amongst my peers at the time with these “non-serious, just for fun, really!” engineering projects, and it is incredibly relevant to my thesis that theory follows practice, not vice versa, for better results. The combination of these and other factors was ultimately what led me into this path of teaching and mentorship I am on today.

2. MITERS, the Relevance of Hivemind Building, and the Real Story of 2.007

No mention of my history would be complete without mentioning MITERS, the on-campus “hackerspace” or “makerspace” or “facespace” or whatever term is now the hot word to describe a communal shared space full of interesting tools and even more interesting people. I often downplay my role in the “MITERS revival” that took place after 2007, when I joined up, but the fact is that I immediately found MITERS to be my niche at MIT and took control of as much as I could. I and a core group of 3 or 4 people spent most of 2008 ‘building shop’ – cleaning out junk, opening up space, purchasing new tooling and tools, etc. all in an effort to make the space that much more useful to everyone else. Part of the shop building was just myself or someone else needing to make something using a new weird process and we bought tools ad-hoc for it.

And I built stuff and paraded projects around like a maniac while advertising for MITERS (This site holds almost all of that history, for those interested) -  Until 2009, we had trouble filling officer positions (all 4 or 5 of them) because the regular members were just us.  But gradually, through many Orientation demos and hovering through the hallways and other publicity events, new members started trickling in. I think the best years for that so far has been 2010 and 2011, when we probably added dozens of regulars and a handful more dedicated users to the roster. MITERS was a starting to become a resource for people who just needed to do one or two little things and were walk-in referrals by their friends, basically, so we all began to take on the role of mentors and teachers to some degree.

Even back then, a few of the freshmen and sophomores had seen our work on the Internet, especially mine since I both blogged extremely often and began to attract the attention of tech blogs and maker-oriented sites – LOLrioKart was pretty big during this time and I became known, for better or worse, pretty much for it. Whether I liked it or not, I was slowly emerging as a face for “engineering weird shit at MIT”. Some times, my acts of public bravado (such as the infamous LOLrioKart speeding ticket incident, which was really a “operating a 4-wheel vehicle in a restricted [bike] lane” ticket) attained local mythical status. It’s often said that successful organizations tend to be built around one personality, and for a time I was doubtlessly feeding into that – intentionally or accidentally. Just about everything I did was somewhat related to MITERS or promoting MITERS or attracting more buildy-frosh to MITERS. Hence my mention previous of my “engineering identity”. By some time mid Junior year, I was pretty much convinced that The System was not supportive of my building things for fun, so I felt the need to make sure there was a way around it – by showing what can be done in a nonstructured environment, away from professors’ demands and shop managers’ shoulder-looking, and publicizing it. Those who know me well would know I do not take Systems at face value, and part of that attitude was cultivated during my “regime” at MITERS.

The influx of members during that 2009-2011 timeframe began to feed into a new dynamic. People were building things because their friends had built something and they thought it was cool and also wanted to try, and MITERS went through (and continues to go through) “phases” of projects where many students and members get interested in some device and then all build something like that. It’s the only reason pictures like this from Maker Faire are possible:

I think we noticed electric scooters as the first major “wave” of hivemind-building in 2011. Then tesla coils and go-karts and quadrotors and DIY audio amplifiers and mopeds
and vans
… The list goes on, and changes depending on who you ask.

Here’s the thing about the “hivemind” though. Nobody was just copying or imitating someone. You wanted to build a scooter, so you might have asked me (or Shane, Adrian, etc.) what parts to use and where to get them. But you found your own piece of scrap aluminum and built it all on top of that. I might have given you a part or two, left over from other projects. There was no “ISO Standard MITERS Derpy Electric Scooter”, but numerous takes on the same general idea. Not all of these projects got finished, and some in fact still hang from the MITERS ceiling like olden-time criminals made examples of in public, warning newcomers against the hazard that is getting way too excited about something and then taking too many classes to finish it. Hey, you all better finish your damned go-karts soon.

I would even wager to say that even if you were just copying someone else, it’s still productive if you’re honestly into your project for its own sake. Build it anyway for your own enjoyment and learning regardless. I bring this up because of the contrast between the MITERS “hivemind” and my own experiences in the Department of Mechanical Engineering. There’s this conversation I’ve had numerous times that seems to indicate a certain disturbing (to me, anyway) attitude in the student population. It always occurs in a public or semipublic setting, such as a departmental gathering or just outside various professors’ offices, and I probably got it the most in the 2009-2010 era when several of my projects were “Internet famous”. It goes something like:

“Hey, you’re Charles, right?”


“I’ve seen your projects and stuff on the Internet [my usual sign to try and escape] – they’re pretty cool!”

“Thanks – I do all of it through MITERS [or other obligatory MITERS plug]”

“I’ve heard of that place, and really wish I could build stuff so I can hang out there more”

“Why don’t you? Lots of people just come in and hang out too, and you can learn stuff from people there”

“I just don’t think I could build anything new”

“Why does it need to be new? Why not just build it for fun [or for your own learning, or something equally ?”

“I dunno, I just don’t want to copy someone else if they’ve already made something”


I realized that’s what academia does to you. In academic engineering, everything you do is under the shadow of research. The pressure to be “new” or “innovative” or “groundbreaking” blocks out skill building by doing it for your own sake. Ideas fight for the right to be justified, analyzed, and scruitinized, instead of just to exist. This would be fine if it were limited to grad students, since by design you’re a research machine and you should already know what’s coming. However, there’s definitely this unspoken sentiment that if you can’t make something “new” or innovative or beyond the norm right away, it’s not worth doing. It has been a concern of the MITERS officers recently with regards to our “image” on campus of this super hardcore group of hackers who won’t stop for any newbie questions. Perhaps it’s just a consequence of MIT being a giant amoebic agglomeration of overachievers that people make this assumption immediately. I felt this exact same pressure when I entered graduate school in the department and it was one of the factors which ultimately caused me to suspend my masters’ studies and instead focus on the then-nascent 2.00gokart project full time.

That past spring, I dug a little deeper with my involvement in the Mechanical Engineering sophomore design class 2.007 – the one which, years ago, spawned off FIRST Robotics. My “story of 2.007″ is a tragic recount of my own build season with the class, but what’s missing from that is all the time I spent immediately jumping in and aiding fellow students.

2.007 is a class well known for its chaos and intensity. Many students who have never built mechanical systems before were suddenly faced with parts choices, design decisions, and figuring out how to make a certain part they designed. And people stumbled hard – if you weren’t already well-versed in building or at least have seen and used machine tools before, and fell behind, recovery was difficult. The class expected students to know mechanical engineering parts already, but what class had taught them that beforehand? There were lectures about what gears and bearings and linkages were, but none about how to connect them to one another. People do figure it out, but they still do stumble to this day, and that’s something I’m not sure how to remedy without restructuring the entire class content and pacing of the department (which I HAVE thought about many times, but that’s for a separate
opinions column)

This was what I was faced with – trying to inject other students with just a little bit of the knowledge needed to carry them through their design. I showed a lot of folks my dirty tricks such as caliper abuse (codified in 2010), and also in 2010 I first put together “How to Build your Robot Really Really Fast” – these days codified into How to Build your Everything Really Really Fast. Starting in 2010, I also held “secret ninja robot lectures”, as I called them, after lab hours were over which were basically open question consulting hours. If anything, the spring of 2009 when I took 2.007 was the wake-up call to me that I could contribute positively to how people learn mechanical engineering. By which I mean “I think ya’ll are doing it wrong… lemme try.” My position as legitimate undergraduate lab assistant in both 2010 and 2011 only strengthened that desire.

2.007 isn’t the only design class in the department, but it’s the one I rag on (and praise) the most because I’ve been more deeply involved in it. MIT actually does have quite a selection of design classes, but I witnessed the same kinds of patterns in either taking them or knowing people who have. The  majority of ours in Mechanical Engineering are catered towards seniors and juniors, the students work in (some times very large) teams, and invariably the people who produce the best work in those classes have picked up their experience before MIT or doing something that was not just taking classes – they did research (such as UROPing) or worked on one of the engineering competition teams or for a startup company or on their own projects or something, where they were able to get the hardware knowledge. And the final product is usually the concerted effort of just a few of said people. Teams without one or more of those people tended to bodge together something that passed the requirements and could be dressed up for the final big show so the class didn’t look bad.

There are freshman level introductory design classes, too, don’t get me wrong – but you seem to spend a lot of time messing with foamcore and cardboard and “prototyping”. They put emphasis on the sketchbook and the Pugh chart and the ‘sketch model’ made of wooden dowels and blocks of foam. So on one end, you learn the ‘design process’ and the other end you produce working hardware, but where do you learn about how to design with and around the hardware or to use the tools available to you? The answer if you asked around enough is either 2.007 (in which we’re expected to teach everything from Solidworks to electronics for mechanical engineers to remedial machining already), or research & urops and clubs. It seemed absurd to me that to excel in the Department of Mechanical Engineering as a student, you had to basically already  know mechanical engineering, or you were prone to feeling left out, frustrated, and bogged down.

That’s basically the root of the ‘agenda’ behind 2.00gokart. To create a design class for freshmen and sophomores (and other newbies) that gave people meaningful hardware experience right away. To introduce them to tools of creating working mechanical devices early, and to expose them to the idea that at some point down the line your designs aren’t going to come from a box of parts in the lab cabinet – you have to source parts and appraise their usability yourself. Yet make it such that it is fun and enjoyable with minimal ‘grunt work’ deliverables and contrived process structures, such that people focus on their project instead of just trying to satisfy requirements, and the takeaways are realized in their other classes after it’s all done. I believe this is all entirely possible to do – I’ve already done it three times.

3. 2.00EVT and 2.00Scooter: The Early Years

By which I mean “2010 or something”.

The class of 2011 was some kind of record enrollment year for MechE, and 2.007 in 2009 (my year) was extremely crowded. To alleviate that, the class began soliciting “special section” proposals from, for example, various competitive engineering teams, or from Ocean Engineering, etc. In 2010, the Electric Vehicle Team, Solar Car, and Formula SAE all took on several students each and had them work on alternate projects and assignments. I knew the leadership of the EVT very well during that time, and Shane and I became quasi-TAs for the section in addition to our other 2.007 obligations (and my own other academic obligations).

In the 2010 session, I primarily stayed back teaching-wise and acted as more of a design consult, just like in mainstream 2.007. That year’s session saw the creation of three vehicle(-shaped-things), including this gem, Longbike:

It was during this EV section that I began to really consolidate all the resources that I’d gathered and had provided ad-hoc to people who asked. My first compilation of ‘where to buy stuff’ lecture notes dates to this era, as does my first in-person lecture (to like 4 people, but hey, gotta start somewhere) on the topics; for instance for people who wanted to use commercial motor controllers and wanted to know how to interface to them design for their limits. This was stuff I had been doing already for years, but fellow students found it genuinely interesting, which continued to stoke my belief in needing to create a design class that pushed people to develop skills first.

Some examples from the 2011 EV Team class

The 2011 session was still run by the EV Team and saw a total of five students and four vehicles produced, but only three of them ended up working. The emphasis was directly on scooters and all of the students got to keep their parts or vehicles at the end. The limitations were a $300 per vehicle budget, and you could get a “subsidized” Razor scooter to pluck apart for folding hinges and handlebars for $25 (typical retail value $40).

However, by then, the EVT captains were trying to do this thing called graduate – and they had limited time to devote to running the class. The organizational structure was fairly weak, the scheduling became broken-down, and Shane & I ended up practically running the class nearing the end. EVT was not planning on running the section again since by the next year, their core leadership will have moved on elsewhere.

I found the class desperately in need of improvement, and at that point I was ready to take it on. It aligned with my interests – electric vehicle design and technology, specifically on the small end of things. By its nature was very open ended – one student chose to modify and re-engineer a commercial electric scooter, which was accepted and ended up working out great, while others went various routes of custom frames and drivetrains. And it conformed to my design class agenda – we assigned each student a $300 (plus or minus) budget and they were allowed to pick and choose parts from Hobbyking, etc., frame materials from McMaster and other vendors, and so on. The basic foundations of what is 2.00gokart today were laid then.

The 2012 class, the first “2.00scooter” that I ran as the lead instructor, is recounted in full detail in its own post. Gee, that lead sentence sounds familiar…

4. “2.00scooter” or Electric Vehicle Design 2012

To produce 2.00scooter, I took the rules that the section was supposed to run under in 2011, and made them more concrete. I also wrote a one-for-one map between the mainstream 2.007′s “milestone” weekly submission requirements and my own section, such that students still had a weekly progress check, but departed significantly from the pacing of mainstream 2.007 which spent 4 or 5 weeks just in designing and prototyping. I replaced those instead with a design period of roughly 2 weeks, followed by compilation of a bill of materials and development of the vehicle’s CAD model. The version of the class rules and schedule as run in 2012 will be available at the bottom.

The summary of the schedule was basically:

Week 1: Come up with concepts, sketch models, etc.

Week 2: Design calculations and analysis. Top speeds, accelerations, efficiency/power usage estimates, etc.

Week 3: Compile a first bill of materials to order, and start CADing the vehicle. BOMs are compiled and ordered every week from here on out.

Week 4: Continue CAD modeling and design refinement, begin fabrication

Week 5: Finish CAD models, fabrication week.

Week 6: Fabrication week, prepare vehicle for mechanical inspection.

Week 7: Fabrication week, vehicle “rolling frame” inspection. The infamous “Milestone 7″!

Week 8: Address problems found during MS7 inspection; begin electrical assembly.

Week 9: Electrical assembly and testing.

Week 10: Electrical inspection; final vehicle inspection

Week 11: Last fabrication/changes, the final contest.

Week 12: Reflection/learning summary, final presentations.

It’s important to note that these were not very concrete dividers between weeks. In fact, between weeks 1 and 4, students would often change their designs for a new part or run calculations on-the-fly while shopping for parts. This is fully intentional, and I in fact question students who settle on something very early on about whether or not they have thought their design choice fully through. This kind of back-and-forth approach is in fact something I did, and still do all the time. I never just pick a pile of parts and then try to optimize a design around them – if I’m not forced to use something in particular, the design is fluid until I find a combination I’m satisfied with Some people needed to redesign a subsystem completely after finding out that a part wasn’t quite what they had imagined. Fabrication, too, was not limited to the weeks that said “fabrication week”. In fact, students could start building and prototyping right away if they wanted to, but few chose to do so – in part because that year, I did not provide free “starter materials” to anyone. In short the “milestones” were good ideas and following them would mean you would get done on time, but the actual levels of progress were a wide spectrum during each week.

Purchasing was handled only by myself – so even though I say the students “buy their own parts”, what that meant in practice was student submitting a ‘bill of materials’ to me each week, then I compiled the orders into one set spanning several vendors. In the later weeks, as students started knowing exactly what they need to finish and the timeline became more urgent, I upped the frequency to twice per week, on Mondays and Wednesdays. This allowed very quick work if you stuck with McMaster-Carr or another vendor which was in the northeast area and could turn parts around in 1 or 2 days. For example, McMaster-Carr for us is almost always next-day turnaround. Orders placed on Monday through scooter parts vendors typically came back on Thursday or Friday.

Centralizing the purchasing through one channel meant that I could also sanity-check and monitor what people were buying. Some times, I substituted parts from one vendor with a better price (e.g. a Surplus Center sprocket) for an identical one with another vendor (e.g. McMaster) and allowed the students to keep the ‘original’ price for the budgeting. This was entirely an effort on my end to reduce the shipping and handling overhead of placing many small orders for parts which were all generally available at one.

The one “twist” I added to the section from 2011, besides a functional framework, was the encouragement of a ‘grounding point’ for student designs. In 2011, one of the frustrations expressed was that people didn’t know where to start. You had free reign of every type of part that could end up on your vehicle, which was great if you knew you wanted a certain motor or something, but if not, then it was a sudden infinite-dimensional problem to solve. Here’s what that twist entailed.

As discussed in the dedicated post, I gave people a free pneumatic wheel they could use in their designs. I didn’t say for what – luckily everyone used it as, you know, a wheel. Nor did I even require its use. It could be a freely traded item – one student could have built an 8-wheeled scooter just from everyone elses’ free wheels. But this little twist I think contributed strongly to the success of at least a few students. Often times, trying to start the design somewhere is the hardest part – even for me, and there is no consistent place I end up starting to design a device – whether it be robot or vehicle. The addition of this optional grounding point meant that those who knew what they wanted out of their vehicles could ignore it, but for the less experienced and newbies, they could start designing around it immediately and not fall behind. For those that used it, it was also budgetary alleviation and could help them afford a higher current controller or gaudy lighting or what-have-ye.


There were two final contests – one was a fairly standard  drag race of 50 meters length, and the other was “The Garage” That contest, in my opinion, was fairly innovative and I have not seen it done before. Starting around summer 2011, we began doing something with the vehicles we called “garaging” – not sticking them in a garage, but running them up all the decks of a very conveniently shaped on-campus spiral parking garage. At first, it was for amusement and because the garage was about the only place where you could go wide open and not, say, cause expensive property damage or be run over by a taxi – for instance, there’s very few other places you can test the likes of tinykart and bentrike around here. The building is about 150 feet (50 meters, whatever) and about 400 long (130-ish meters?), and had 4 total floors which were ‘interleaved’ so to speak, so you continually went upwards. And those spirally ramps at the end.

We began recording these runs for time and energy consumption later on in 2011 and discovered that the product of the two, time (s) * Wh (Joules), yielded a score that was highly sensitive to several factors. Throttle for one; how much you gunned it. But if you didn’t push it as fast and took longer time, you could still come away with a high Wh * s score anyway. The “line” you took also influenced the score – sweeping, wide, constant velocity vs. short dashes and slowing down for the end turns, but then having to use more energy to accelerate again. (Of course driver weight had to be normalized for since that was by far the biggest influence…)

We began to make ‘maps’ of all our project vehicles courtesy of a Matlab script Shane whipped up:

Garaging continued to be a fun activity, but I decided to make it the central event for 2012 because it was such an unexpected game of optimizing your variables. Students would be armed with a wattmeter which was zeroed at the beginning of their run, then their stopwatch time between start and finish was totaled up and the wattmeter’s energy consumption value in Wh inspected at the finish line. Here’s some of the 2012 vehicles on the same map:

The two axes of the graph represent constant time and constant energy consumption. It shouldn’t be much of a surprise that the only kart of this season that ran, Melonkart, used up more energy because it was that much more heavier, had twice the number of wheels, but a controller that wasn’t much more powerful than the eventual overall winner, Cruscooter. The karts here are clearly in the upper left – low time, high energy, but the scooters that adhered to the good old sensored brushless combo all sort of clustered together at the local minimum. It’s not really reasonable to draw solid conclusions without a normalization for total mass of driver and vehicle, but you get the idea. For the same driver and vehicle, you can move the score point around on the graph by changing your approach or other vehicle characteristics, and that was the fun part.

Finally, if you’ve not seen it before, the 2012 highlights video.

Procedurally, the 2012 contest went extremely smoothly, way better than I was expecting (basically something between a flash mob and lecture when the professor doesn’t show up). The contest procedures, where to meet, and what to bring, etc. were communicated with the students in the final lecture session beforehand. This contest’s procedures has been the reference model for all of the other ones so far, for myself. Before the event, I purchased a set of 2-way radios for the staff, including myself, to communicate with up and down levels of the garage. The 50 meter drag race was “yellable” but the loud ventilation fans in the building underpass meant radios made everything way easier. What I was short on was camera and media personnel since I had to divert people to being track marshals and in the garage, the “per floor” progress checkers. Hence, 2012 has less media than I would have liked, far less than what I’d devote to a project anyway.

2012 did show me some shortcomings of my original idealistic vision. To summarize the summary post (…) whose conclusion I still consider valid, keeping mental track of 10 peoples’ designs was a nightmare for me – I think that semester was my busiest yet, since I hadn’t even figured out the workflow of managing a bunch of students for real yet. In the summary post, I also said that having different vehicle ‘types’ made it hard to compare results between the students, and this is true to a degree – I think if the contest is going to be single-driver time trials anyway, the necessity of having a ‘class’ of design is lessened compared to if I were going to run everyone together.

Overall, I considered 2012 a resounding success. The students who took this class are now all mechanical engineering seniors themselves, and languishing in their senior product design classes. Muahahahahhaa.

5. 2.00gokart, the 2013 edition

Melonkart, to the right, was the inspiration for ’2.00gokart’ as we know it. The two builders Jackie and David proposed that they team up and combine their budgets of $300 each to construct a larger and more complex vehicle. I was back and forth on allowing it, but hey, experimental section. My decision to make 2.00gokart 2013 a team-of-two effort was swayed also by the fact that there was a 1-person go-kart attempt, but it ended up very tenuously complete and to great frustration of the student during the term. I decide that a $300 budget was just too low to make a good kart (which has more components and more materials usage), and that it was too much to expect a large sample crowd of sophomore MecheEs to complete, in 80% of one semester, and with other class commitments. I didn’t finish LOLrioKart in 1 semester – in fact I think it took me like 1.5 years to get it ‘right’. It is possible to do if it’s the only thing you are doing, I think, but in a class at MIT you have to be compatible with your other obligations.

After collecting some reviews from the students and fellow EV’ers at MIT, I took the Melonkart Theorem and made it into a set of rule addenda to reflect the new class. In the bottom of the 2012 recap post, I gave my ideas for what would become Spring 2013′s 2.00gokart. In short, the rules stay basically the same, but everyone gets more free stuff! I backpedaled a bit on the originally very optimistic new rules. As-run that spring, I used the following:

Instead of individual projects, students work in teams of two

I give them 3 sticks of 80/20 extrusion (6 foot lengths), two plates of aluminum, and the pneumatic wheel.

Up to 3 A123 batteries were allowed for free, with a fourth at a $75.00 budget deduction

The limited ‘basket’ of other parts was removed and a full $500 allowed to purchase any parts needed.

The “noise floor” of the budget is 50 cents – you could buy a whole box of screws to use 2 of them, and it would be free unless each screw individually was over 50 cents.

I added the ‘statically stable’ clause to the rulebook.

With regards to each of those changes, here’s my reasoning.

The biggest difference was, of course, the complete elimination of the ‘basket of parts and materials’ ideas, because that sort of went against my whole philosophy for the class. I’m not sure why I even thought of including it – probably from burnout from ordering the same thing 17 different times from McMaster, but much of the point of the class was to show people how to search for parts and resources, and I didn’t want to dilute that after coming back to my own proposal months later. Pursuant to this, I upped the “drivetrain parts budget” from $150, basically the price of a motor and controller of reasonable quality, to a full $500 for all parts I did not provide. The amount of $500 was roughly what Team Melonkart spent on their vehicle discounting stuff I would eventually provide – a wheel, some materials, and a handful of hardware.

It also happened to mesh well with the then-up-and-coming Power Racing Series. I was on the hunt for examples of other racing series or college/high school courses of a similar budget line, and what I found was that there weren’t really any equivalents. Quite a few schools have electric go-kart or electric car racing teams, but those are usually large team efforts, and my class as-designed is individual or very small teams. Two examples of the ‘big event’ kind of electric kart racing is Purdue EVGP (check out their very detailed reference document – this needs to make it into my own lecture notes and class references) in the U.S. and e-Kart , a national championship of many technical schools and universities in France – Shane and I met one of the university organizers at a conference in Monaco in 2011.

An e-Kart race. The karts are… bigger.

Where 2.00gokart differs from these events is in the smaller vehicle size/speed class and the focus on individual student efforts instead of a massive team. I leave the latter for the already established senior design classes and team sports to deal with.

I settled upon the 80/20 extrusion method of building after spectating the build of tinykart, then embarking my own build of Chibikart and Chibikart2 (nee DPRC). I thought that the system sped up the design process significantly, and it was easy to work with and easy to connect together. The big enabler for this method is our available on-campus waterjet machining, such that students could make the interconnecting plates and structures quickly. Furthermore, by the start of this term, my How to Build Your Everything Really Really Fast instructable was up and running, and it served as a major resource for the students all through the semester.

I provided each team a 1/8″ aluminum plate and 1/4″ aluminum plate in 2 x 2 foot size, which they were allowed to use up over the course of the semester at no budgetary cost. If they needed other materials, then those had to be specified and purchased. Most vehicles were able to stay within the free materials allowance.

Waterjet machining was provided by the Hobby Shop because of the additional degree of freedom I needed for this class – I taught the students how to tile and arrange waterjettable parts on a plate, so I had to run the machine myself. The main 2.007 section uses a shop where the shop staff cut your parts out for you, usually one at a time with no pre-tiling allowed (i.e. “send one part file, request n copies” with no control give to you as to which orientation or tiling you wanted, and the machine is also busy enough during the term that the much longer cuts needed for my section in much thicker material would have been hard pressed to stuff in. I don’t blame the main shop at all for being inflexible – in fact I think it’s the only way they can process 150+ students who all need to waterjet something for their robots now that the technology is in the open.

One addition to the lab which aided the students’ vehicle development very much was the provision of free birch plywood and high density particleboard (hardboard) to prototype their frame joists and other parts with, using our 36 x 24″ laser cutter. That way, you could iterate quickly through several different designs, test fits and clearances physically, and actually make functional prototypes because the wood material is quite strong on its own (don’t try to ride it though…) before “committing to aluminum”.

The “static stability” clause was a compromise between requiring 4-wheeled vehicles (true go-kart style) and having a complete design free-for-all. It was a shortcut way of making sure nobody built a scooter or recumbent bike or similar. While there’s nothing explicitly wrong with that, this clause was one of my deliberate ‘screw tightening’ changes to the class to mix it up. The final wording of the rule can be found in the example rules sheets in Section 10, and it only required at least 3 rolling points of contact with the ground. This explicitly allowed trikes and even scooter or bike-like objects which had a ‘training wheel’. I didn’t know why the hell you would do that, but figured somebody might figure out a creative way to make a lighter and faster vehicle that fit the requirement. For instance, sidecar racers.

There was also no requirement that the training wheel touch the ground under operation – only static stability mattered.

That essentially sums up the deltas from the 2012 class. The scheduling also remained unchanged, since the only things which were different were vehicles and construction methods.

I put together a cabinet of “free to use” parts, primary electrical accessories, that included the following:

80/20 slide-in nuts

3/8″ long and 1/2″ long button-head screws

Electrical supplies such as 12 gauge red and black wire

Electrical crimp spade connectors for terminal blocks, ring terminals for motors, and Quick-Disconnect terminals for the battery tabs.

Bullet connectors, Deans, and XT-60 connectors – three popular R/C type connectors.

Regarding the “50 cent limit” for the budget, it was to offer students some flexibility in not having to literally list every screw and bolt they used. It was a ceiling chosen because I thought $1.00 was too high (many small but important parts, like bushings and some larger individual hardware, are under $1s each) – that was the limit I remembered dealing with in  FIRST Robotics. 50 cents means there existed many more choices on McMaster between, say, a mil-spec or otherwise high grade part, and a “generic” one, something that I did want the students to figure out the difference between.

The 2013 contest ran almost exactly like the 2012 contest procedure-wise, since the same venues and scoring methods were used. I paid more attention to media this time, so there’s more video and picture of peoples’ runs. They are not currently all up in a publicly viewable cloud app, but here are some of the better previews taken from the 2013 cleanup post.

Pictures by Dane Kouttron or Mark Jeunette

And, of course, the 2013 video.

Finally, we did tally everyone again during the garage race, so the 2013 results:

Notice how there was still a great span of times, but the whole graph is generally shifted upwards towards more energy usage. Bigger motors, more wheels, heavier frames, all of these contribute.

My assessment of the inaugural run of “2.00gokart” is that it, too, was a success. The biggest issues that stuck out to me with this class were relating not to the technical content and the ability of the students to perform them, but more towards future scalability.

There’s two prongs of scalability pertaining to the class I want to put forth. First of all is literally scalability – from two runs only, I could tell that the class in its current form would have a difficult time scaling up. It was pretty overwhelming handling 10 different designs mentally in 2012, and in 2013, I had 16 students and 8 vehicles. I think (and with the SUTD summer session’s 27 students) that my working limit is somewhere around that. The issue is a class like this right now still takes one or two “gurus” who know the area in and out both theoretically and practically – you have to both convey the technical knowledge AND debug a motor controller’s blinking lights. You can’t just assign an army of TAs to the task for this reason. I was lucky to have Banks‘ help who also helped me develop the “2.00gokart prototype” the previous fall, which resulted in some of the rule changes discussed above. My overall conclusion for scability is it’s necessary to have fewer highly knowledgeable instructors than one instructor and many TAs who don’t really know the details.

I also was ready to deal with “team dynamics” – or people coming to hate their partners – but because the teams were so small and the class generally knew each other already, there was very little of this. I see team dynamics becoming an issue if the groups got larger or the demographic were less self-intimate. With two people a group, everyone had oversight over the whole project, which is small enough in scope to allow this, and I would be “the tiebreaker” if there was a conflict of ideologies, but there were never any – issues were resolved on their own, generally, and maybe a few times involvin

Show more