On 2.00Gokart; Or, Designing a Design Class to Disrupt Design Classes as We Know It; Or, How to Make MIT Undergraduates Build Silly Go-Karts so You Don’t Have To

Wednesday, October 23rd, 2013 @ 2:52 | Electric Vehicle Design, MIT, Bostoncaster, Cambridgeshire

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. Edit: It’s now on Make Blog! Thanks Make! 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. 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,

  1. A brief rundown of my own history with engineering projects and how that both aided and hindered my academic performance at MIT
  2. How I took an interest in teaching and why I saw issues with the current system of design classes
  3. A history of my involvement and leadership in the electric vehicle design realm
  4. Recap of the 2012 class “2.00scooter”
  5. The changes made for the 2013 class “2.00gokart”
  6. The 2013 summer special session and the changes made for it
  7. Where the class stands now; content, procedural, and logistics.
  8. What I think the class brings to the world of design classes that is different or novel.
  9. More about the resource base of the class and the cost of running
  10. 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 not 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?”

“Yeah.”

“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 thesis 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.

During the summer of 2012, I built Chibikart 2 as an exercise of designing around only commercial (COTS) parts and accessible (online orderable) machining services. It was a success, and it formed the baseline of 2.00gokart – besides the waterjet cost (to be detailed in Section 9), it otherwise completely fits within the class budget and resource base.

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 involving one party scientifically proving to the other why he was full of it, to the mutual benefit and education of both. I anticipated some “You’re the mechanical guy and I only do electronics” to occur, but absolutely nobody tried to skimp out on their tasks. I think the students understood fully what they were getting into and what was expected of them; combined with my convicted aversion to hardline-graded requirements meant they could more readily focus on their project.

During 2.00gokart, I deviated a bit from the Mechanical Engineering department’s requirement of 2.007 students to maintain a classic written “lab notebook” and allowed (and encouraged) students to start their own build logging websites. I accepted entries on these sites as an equivalent of the notebook entry for the week, but because I was still working within the constructs of 2.007, there was a minimum notebook requirement each week – I just made a note that the meat of the entry is online. It was not required, and a many decided against it. The links to these student websites are found on an index post I made for the purpose. It’s important to remember that some of these posts are also on behalf of their teammates.

I think this sentence from the cleanup post is a great summation of the class, capturing its intent, spirit, and scale in one:

The two top placers in the drag race were a hundredth of a second apart yet represented opposite ends of the traditional EV design spectrum. One was huge, had giant balloon tires, and two massive DC motors. The other was small, lightweight, and had a single brushless motor.

6. The SUTD Summer Session 2013

While the 2013 class was running, I was requested by SUTD (the people who fund the center whose fabrication spaces I run, so I better damn listen, eh?) to run a special edition of the class for 28 students that enrolled in a MIT-immersing summer program. For those not in the know, SUTD first started taking students in 2011 and they’re still very small. Basically, I was faced with a chance to reflash like half of their sophomore class to build silly go-karts! Who would turn that down?

Coming hot off the spring 2013 2.00gokart section, I was confident it could happen again.  The time constraints of summer posed a unique challenge: I had only 8 weeks to do all this, compared to 13 for a standard academic semester here, and for 28 students working in teams of three (with 2 teams of 2). I had two TAs which I knew well to deputize tasks to, so it wasn’t total death. I could no longer assume the students were all uniformly processed through the Mechanical Engineering department beforehand, so I had to prepare to teach literally everything I needed them to know for the class. And I was also interested in the cultural change: It’s a common conception in education that Eastern students are more taught to follow orders and not overstep their bounds, compared with Western students who are taught to be more creative and individualistic – so how differently would my near-constraintless-on-purpose design task be accepted?

The most pressing matter to me was the timeline, both in class pacing and amount of work the students could do in that time. I only had these students from June 10th to August 9th, so I had to condense the 2.00gokart schedule down about a third. Many of the weeks labeled “Fabrication Week” in the 2.00gokart outline were condensed. I sent orders out twice per week as a default, since waiting one week in this round was a much tougher hit on the production schedule than before, and air shipping & 3-daying were the default. This did increase the cost overhead of the class (Section 9 will discuss more fully what is involved cost-wise for the three sessions)

Tempering the scheduling constraint was the fact that I had the undivided attention of these students, instead of having to fight for it because they are taking 5 other classes, working a UROP, running a startup company, and doing things with their frats. Furthermore, it was three students a team. Therefore, I figured the overall workload per person-week was actually lower.

The compressed schedule ended up in the following format:

  • Week 1: Team formation and concept sketching – settle on a concept by the end of the first week.
  • Week 2: Design calculations, analysis, formation of the first Bill of Materials as you settled.
  • Week 3: CAD and prototyping
  • Week 4 – 6: Fabrication, with the Mechanical Inspection occuring at the end of week 6
  • Week 7 – 8: Electrical fabrication and testing, with final inspection occuring at the end of Week 8
  • Weekend 8: Final contest

I also ‘buffered’ lots of parts. To avoid shipping delays of anything over a few days, I pre-stocked a selection of motors from Hobbyking, controllers from Kelly, and about half the warehouse of Monster Scooter Parts. I ordered parts based on a good guess of what students would land on and specify, extracted from the 2.00gokart and 2.00scooter master purchasing list. This isn’t to say that students only could use those parts – for the most part I kept the selection hidden in an Instructors’ Only closet, but if someone “ordered” a part that was in the stock, it was available after 1 or 2 days of artificial delay to keep things fair; I had a queuing area for shipments as they come in, and the parts would magically appear in them.

More parts were also made available in the general supplies cabinet. On top of the previous list of electrical components and 80/20 hardware, I also put in:

  • FR-8 (1/2″ bore with flange) ball bearings and G-10/PFR-2214 (5/8″ bore with flange) ball bearings
  • #25 chain, connecting links, and sprockets
  • Cable brake supplement hardware, including adjuster barrels (example) and pinch bolts (example).

Essentially, some of the small annoying things I would let a 2.007 student forget about and then point out later were filled in for the SUTD class due to time constraints.

I took the gap between the end of 2.00gokart and the start of the summer session to work on my van create a more comprehensive set of lecture slides that covered more of the topics in the class. This will also be a resource for future 2.00gokart sessions. I wanted a fuller set of references for the students to refer to if they had minor questions, since the greatly increased student count meant I needed to pre-emptively load-shed. Not to say I didn’t spend all my time answering questions anyway, but hey, I’m the chief instructor for a reason. The lecture subjects formalized much of what I had just drawn on the board or sent out e-mails before. Furthermore, they covered specific mechanical engineering subjects such as using fasteners:

Other topics included designing for “our” manufacturing (DFOM), i.e. laser cutting & waterjetting, and overview of the vehicle electrical system.

Procedurally, the greatest challenge of the class was keeping the TAs on the same page as me. I’ll be straightforward: None of the TAs had as much experience in mechanical design and EV systems as I do, so there were many briefings in which I gave them the gist of the task in case students had questions. Nonetheless, we still face times when students were being “bounced” between the TAs and myself. A student would ask a TA about some possibly obscure controller bug, they would be bounced to me, but I would be in the middle of helping out someone else and ask the student if the TAs had seen the problem yet. This was one of the “themes of complaints” on the end of class evaluation, and shows again why this class might not be scalable unless you had multiple EV hacker gurus.

Another time-consumer for myself and the TAs was having to babysit the waterjet cutter. The students do not use the machine themselves since we in the IDC do not have our own waterjet – instead, they queued up their cuts on DXF files which were submitted to us weekly. Cutting was done by borrowing the Architecture Department’s waterjet for the summer. In part due to the schedule being so crunched, and also because there was just more machining to do than in the spring, in the last 3 weeks I think we spent 9 or 10 hours each time in the waterjet room. I did do a lot of waterjet babysitting for 2.00gokart, too, but because that schedule was much more relaxed, the sessions weren’t as intense.

The end-of-term challenge was changed up completely this time around. Instead of everyone taking individual runs up the garage, I decided to go all-out for fun (since who’s getting graded on this anyway?) and with the other instructors, set up a road track in the parking lot adjacent to the garage of yore. The layout of the track was Scientifically Determined (read: weekend of Instructor go-kart hoonage) and fixed at a nominal length of 150 meters, taking up only half of the parking lot so we could have an easier time with getting it closed off by the MIT Police.

We made up the course to have only two really long straight areas The rest of it was fairly tight, especially the chicane, to encourage the vehicles to be Designed for Turning. One thing that 2.00gokart taught me is that the garage turns were so wide that people didn’t have to design their vehicles’ steering very well at all, and we wanted to head that one off for the summer session.  On the average, we ran 25 to 30 second lap times, but the student vehicles tended to take a little longer.

The format of the contest was derived from the garaging runs. Student vehicles were rigged up with the Wattmeters, and were allowed 2 laps to warm up and familiarize, after which the wattmeters were reset and they started from standstill for 3 laps. The total Wh consumed and seconds taken to run the track were recorded. Because the transient that is the first acceleration is very short in time compared to the rest of the race, and everyone used the same procedure, we could still compare between vehicles.

Sadly, the drag race was dropped due to time reasons – if everybody wanted a turn on the vehicles, then the events would run on very long. By time calculations:

  • with each lap taking about 30 seconds and students running for 5 total laps
  • a minute between each driver to swap vehicles
  • 30 seconds
  • 1 hour of ‘charge time’ during the lunch break

 

The event would seemingly run only 3 hours. This is how many people schedule and manage the time for “design contest” style events, and this is why they always run overtime. We actually took up the entire 5 hour timespan, since the vehicles some times broke down on the track, people had to restart and re-run, and repairs had to be made. If everything were mechanically perfect and reliable, then we would have  been closer to the calculated time, and I would quit my job. Really, part of the fun for the students was doing that in-the-field servicing, watching people rig fixes and on one occasion, entirely rebuild their front-end after bending a steering component.

The TAs and random friends that showed up the day of to volunteer were crucial to the event going smoothly. While I may wish for TAs with more in-depth EV knowledge during the fact, at the end of the semester when all the labor is done and it’s time to have fun, everyone plays a role in organizing, marshalling, taking pictures, resetting cones, etc. It actually is running a miniature racing event, after all.

I don’t yet have a comprehensive video of the event. Most of the runs were recorded, but they weren’t very exciting to watch. What was exciting, though, was the “grand prix” races we had at the end with the still-running vehicles. They pretty much capture the gist of the event:

After the students left back for Singapore, we hired a shipping company to box up all the vehicles and parts and ship it all back to them. So hopefully, this is the start of SUTD’s own silly electric rideable thing culture!

Here’s the cool part. Because I was not running this class under the auspices of an ABET-accredited department any more, I decided to let the students go full-blog in their documentation. The requirements were reversed: A minimum entry on their website (set up in the first week of class) was mandatory, and then they could put whatever they needed in their physical notebooks. Everyone took me up on it this time, and the websites still exist, variously updated. The class got intense enough that I didn’t enforce the updates very hard – also influenced by my agenda that the class should have as few actual requirements as possible.

7. Current state of the class

After three iterations, I think the class has reached a stability plateau in terms of procedures and technical content. I now know what needs to be done to prepare before the session, what needs to happen every week during it, and what to do in terms or organizing the event (either garage or parking lot).  My hope – something I’m not actively working towards but feel like someone might take me up on – is a Purdue EVGP or e-Kart style, multiple schools and teams kind of event with karts build to similar specifications as what I have outlined. In the mean time, I intend to run the class and make semesterly little changes and tunings as often as I can, for the length of my, umm, regime at MIT. So, these next two sections will conclude the story and hopefully leave everyone with enough information to understand what kind of shenanigans are happening at MIT with all of our electric rideables here, and how to organize your own league of go-kart legends locally.

Before the session:

  • Secure a budget for the class and someone who will be the central purchaser. Section 9 will have more information on the resources and budget info. The purchaser should have unfettered access to a purchasing card or requisition system and must be prepared to make an order every week at the least, or preferably twice per week, from several vendors at once. There should not be 17 layers of administration between the instructor and the purchasing / approving staff. Preferably, an instructor is the purchaser and has direct contact with the approver (if applicable) every week. This is how I have been handling the purchasing for the class – I have a MIT procurement card and the ability to make requisitions from preferred vendors such as McMaster-Carr and DigiKey and MSC, et. al. through an internal MIT requisition system, charging directly to a class account.
  • The class as I run it depends heavily on rapid prototyping machine access – waterjets, laser cutters, the odd 3D printer or two. Negotiate access to these for individual students or have a system where you queue student jobs and run them on the machines. If these machines have a cost element, they need to be factored into the budget (Refer to Section 9 for estimates of how much we busted on waterjetting!)
  • Negotiate any sponsorships well beforehand. I depended on the good graces of A123 for donations of batteries in 2012 and 2013, one of the last things they did before imploding back to a small condensed matter state. For the summer session, I had to buy a set of the batteries at retail price, and that was a hefty addition to the budget. For the coming 2.00gokart year, I will need to do that again or hitch up with another battery sponsor. Batteries are easily the most expensive portion of the class materials – unless you’re insane and want to use Hobbyking lipoly batteries on everything.
  • A reasonably equipped machine shop is preferred. Everyone can do it up “Chibikart Style” with nothing more than garage tools, but a small metal lathe and mill are valuable additions. The students, as I run the class, have 24/7 access to our fabrication space (pursuant to safety rules such as required personal protective equipment and a strict no-working-alone policy in my shop). It’s probably also possible with fixed lab hours, but that’s against my philosophy.
  • “Messy lab” space is absolutely essential – for 2.00gokart and the summer session, I assigned each team 1 table that was on wheels and they could roll in and out of the shop. At the end of their working session, all tools from the shop must be replaced and all of their parts, assemblies, and hardware must be only on their table. For those keeping track, that’s like 10 big lab tables.
  • Pin down the design of the final contest and secure the facilities if needed, including any safety office or regional governing authority paperwork. This is key – the first round of 2.00scooter safety meetings took 2 months spanning 3 sessions, but it has been significantly easier afterwards because now everyone has an idea of what the event entails. Feel free to show your own authority the highlights videos linked in this post.

During the session:

  • The lead instructor(s) should have a very in-depth knowledge of electromechanical systems, both theoretically and practically. Theoretically speaking, the content is not difficult and is generally first-order linear differential equations or closed-form linear constitutive equations (if you understood that, then you can handle teaching everything needed). Practically speaking, a strong debugging sense, experience with past build projects where stuff didn’t work, and strong design experience of mechanical systems is pretty much required. Electrically, most of the systems I use are plug-and-play, but debugging circuitry, bad solder joints (MY GOD THE BAD SOLDER JOINTS PEOPLE MAKE), and other wiring demons should be in your skillset.
  • TAs are helpful only if they are essentially of the same caliber as instructors, or are handling mostly non-design tasks, such as staffing a shop (e.g. only there to answer machining questions), or grading student work if the class structure dictates it.
  • If your class has a milestone or checkpoint format, then you should write these beforehand so everyone knows immediately what is expected of them each week – Section 10 has my example milestones from all 3 sessions so you can also get a feel of how the class evolved. Lectures, if applicable, should also be prepared beforehand since leftover lecture slides are a good resource for people. They should not be made available publicly (in my opinion) until after the lecture, to encourage everyone to come. I reserved the right to refer people to lecture slides if they didn’t come, then expected me to answer very simple questions.
  • Instructors must be available. This is not a lecture and go-away class, you are all-in, 100%. During these sessions, it was not unusual for me to be “in lab” from noon until midnight – my schedule is a little “off” by most peoples’ standards, but regardless, you are the mother duck to a pack of ducklings. You have to be on top of all parties’ progress and see that nobody is falling too far behind. Many engineering students would prefer not to ask questions and tough/puzzle it out, when it is far more productive to grab a hint and move on, and you should be on the lookout for people who are too stuck trying to optimize in the wrong direction. You must also be able to resolve team conflicts if teams are the format.
  • Purchasing (if separate) or you (if you are purchasing) must be organized and deadlines for BOM submission made non-lenient. I routinely did cut people off when they swore that they needed 5 more minutes to add a few more parts. The answer is you had 3.5 hours of lab to add these parts. Purchases must be prompt and in the best case should occur during the daytime so most vendors can ship out same-day – if you wait until night or after business hours to order, it most likely will add an extra day of transit.
  • An order queueing area for students to receive their parts should be reserved. I think opening the boxes of their own parts contributes greatly to student excitement.
  • Nearing the end of the term, be aware of how close the event is and any logistics you need to perform to set it up. In the ‘cleanup posts’, I go over what we had to do to set up for the events.

Contest setup

This section, of course, is highly variable dependent on what your exact circumstances are, so I can’t really say that much besides give data points on how it went down for us:

  • In 2012, the safety office was adamant that we set up some kind of ‘catch netting’ to prevent people from running into the concrete walls of the garage. It became obvious to me that they did not really think the implications and details of this through, nor did I think it was a proper response to people riding scooters around gingerly, but without the signoff from them we would not have gotten the venue. Therefore, I and 3 other folks spent 12 hours on the Saturday before the event rigging up steel cables through construction debris netting, and about 1.5 hours setting it up in the garage. The cost for this ‘feature’ was about $1500 total. The way the nets were set up, it was a reasonable way to stop a person standing up on a scooter (you’d probably just get epicly clotheslined) but the go-karts would have shot right through the two steel cables.
  • You are going to need way more time than you anticipate. I, luckily, have some years of event planning and running experience in the sphere of robot contests, so I immediately budgeted 6 hours for the contests. They always needed that or even more, because you’re never going to run vehicles back to back continously.
  • In 2013, I piled the garage full of low bricks of fiber insulation (chopped up recycled cloth and paper material) (example link – it comes in bricks). It was far faster to set up, more effective than the netting for go-karts because each row of five weighs 100+ pounds, and if you joined them together they are a flexible soft wall. Luckily none were actually needed. They made a return protecting the curbsides in the summer race. Overall setup and teardown for each of those events were under 30 minutes each and no labor was expended beforehand. Therefore, I approve of these things immensely.
  • You are going to need way more time than you anticipate.
  • There should be a driver meeting to go over procedures, safety expectations, and starting order, and everyone who is driving should be there.
  • I held a separate track marshal/instructors meeting to make sure all the event staff were also on the same page about who is standing where, who’s timing, who is reading wattmeters, etc. All volunteers should know their roles at the start.
  • You are going to need way more time than you anticipate.
  • Two-or-more-way radios are an immense help to reduce arm flailing and shouting, especially if half your venue is located next to the air intake of a very large biolab building.
  • If you actually have a circuit race with multiple racers, a flag system is most likely needed to communicate track issues or people who blew up their motor around the bend.
  • You are going to need way more time than you anticipate.

Lecture content

I held weekly mini-lectures on various EV-relevant topics. These were concentrated mainly in the beginning of the semester when people were still in the design phase, and covered topics that were directly relevant to the design task. Here’s the example 2.00gokart (Spring) lecture schedule:

For the summer session, since we had 8 weeks but two sessions per week, I doubled up the content:

I’m going to include the full set of lecture slides from these sessions in Section 10 for reference. The “week one” website lecture there was handled by one of the TAs – we agreed that giving people a primer of what we preferred to see online documentation-wise would help people out if they haven’t had a website to manage before.

The electrical lecture was split up into two sessions since for the most part, the first half of the class is concentrated on mechanical design, so the first Electrical lecture is more of a ‘heads up, these are things you need to pick and include in the CAD model of the vehicle, but don’t worry about putting it together yet’ sort of affair, and second one is where I have more wiring tips and other details.

Changes to the class I’m intending on making next Spring (2014)

I foresee running the 2014 contest in the format of spring 2013 with only a few possible changes:

  • I’m debating switching the spring class over to the road course, too, since it offers that much more excitement, especially if multiple vehicles are running at once. However, the garage runs offered a reasonably challenging, but still straightforward simulation & prediction element to the design, something that I think should be part of the class if it is running as a departmental lab section – much of MechE still has everything to do with analysis, and it would be beneficial to train up those skills early. I would need to come up with a framework for students to estimate their energy usage and speed, etc. on a track type environment if I go that route (Feel free to suggest good links in the comments…)
  • I’m planning on introducing more wildcard components. One of these under heavy consideration is cracking open a hybrid car’s battery pack, typically made of NiMH cell modules. I can get more watt-hours for cheaper by salvaging them (A grand rundown on the one I already opened up is forthcoming). Students may be offered a choice between the A123 bricks and NiMH cell modules.
  • I want to start encouraging R/C part based drivetrains – odd, I know, since I’ve spent 2 years trying to stamp them out in the interest of science, but to balance this with the introduction of students to a wide variety of resources means demonstrating how they may be used within the rules of the class. The biggest challenge is getting an R/C system to stay under the maximum amperage of the batteries, and I’m thinking of methods of doing average-current control with a microcontroller frontend – if this bears fruit, it will, of course, be documented here.

8. Reasons why I think 2.00gokart is innovative for the space of design-oriented classes

The goal of this section is to explain why I think the electric vehicle design class is different from, and better than, most traditional engineering ‘design classes’ in how it engages students and prepares them for further study or progress in an engineering curriculum. What’s an engineering design class? I take it as any class where the principal objective is to create a functioning product while applying appropriate engineering principles and theory in support of that goal – it doesn’t have to be “Senior Machine Design” or “Automotive Design” specifically. Recall the quote from the start:

a design class teaches you to use a practical approach backed by engineering science to solve an ill-defined or open-ended problem

There are things which I call design classes others might call a “lab class” where the focus isn’t entirely on the project. I think in either case the points I will express are applicable. It’s also important to keep in mind that I don’t consider building a silly go-kart to be a panacea for all engineering school ills, but as long as I am here at MIT, I’m going to use that as a way to enhance learning for as many students as I can manage, and hope others also find the resources engaging.

In a non-ordered list, since I can’t bring myself to conclude which point is the most important:

It builds appreciable engineering and design skills right away.  The class is purposefully designed as a skill-builder for freshmen and sophomore students. I don’t construe this remotely to be a giant senior year engineering showcase. I explicitly keep it lightweight and fun-oriented so you can focus on becoming familiar with basic electromechanical parts, fabrication skills both electrical and mechanical, and using modern design software to visualize your designs before committing to physical materials. You build a robust system that is large enough that misapplied theory, I Saw It On The Internet (Isioti Syndrome), and ignored flaws tend to show themselves quickly.

The classic example I give is shafts running in aligned bearings – on a little robot that has a wimpy sheet metal frame, you can really goof up the fabrication or the placement of parts, etc. but just bend it into shape. It doesn’t take much force to encourage 1/32″ aluminum to go where you want. The same cannot be said about 1″ square frame bars. You appreciate the principles of mechanical design and structures more viscerally as your entire frame sags and your wheels cant inwards because the structure is not rigid enough. Whereas almost any amount of gluing and set screwing will transmit the torque you need to lift a little robot arm, the same joints will rupture instantly when you put the torque of a drive motor behind it. The steering linkage supported by a single bronze bushing will bind up instantly (“but it worked in Solidworks!”). Things have to actually designed carefully – the fudge factor is lowered. Trust me, though, you can still fudge the hell out of one of these.

In the class the way I run it, students learn modern rapid prototyping equipment like waterjetting, laser cutting and 3D printing. A lot of people around here snicker at such new-fangled technologies and stick to their CNC guns, but tools are tools. Not introducing students who will be working in the field with these tools, most likely, does not make the tool nonexistent – it just makes you dated. I try to teach effective use of these tools, which is why students generally do not use any of these machines (besides the laser cutter for quick prototyping) on-demand – I screen the parts for make-ability using something else we’re both standing immediately next to. I pretty much refuse to 3D print rectangular blocks with holes in them and taunt them mercilessly about rectangles with holes on the waterjet, and ask if it could be made in other ways. For instance, could you have just bought a more precise and better made square with a hole in it, because…

It introduces students to resources beyond a class supplies cabinet and to the limitations of those resources. In many design classes, you work around parts that have already been given to you. Caveat: This is completely okay if the problem is entirely solvable within the scope of the parts given. I’m not saying all “lab supply closet” classes are bad – they serve their purpose to teach a specific method or produce a specific end goal. But in the more general case, you’re given “a task” – to make a product, to design a machine, to optimize this toothbrush, and the professor says Go. What do you do?

If you are a traditional engineering student, you kind of sit blankly on Google trying to decypher the cryptic Chinglish descriptions of some part you’re looking for, because you haven’t actually done this before. Neither have your friends. The first time many MechE students see shopping for parts here is in our senior classes. I have counted more instances of people producing very convoluted solutions to a problem that 5 minutes of rummaging through the McMaster-Carr catalog could have avoided, than I care to disclose. I have done the same, but years ago, so now I know a little better.

In the class, I introduce students to a sample plate of places to shop for mechanically oriented projects as part of the mini-lecture series (See lecture material in Section 10). You learn how several vendors can offer the same part in minor variations, and how to discern the differences from some cryptic specifications. For people who always deal in precision industrial or medical parts, everything comes with a full-out datasheet, but not everything is like that; I show people the back roads and shadetree shops  of parts buying in case they ever need to use them. You learn that ordering from China without an express post option is a horrible, horrible idea because the class is gonna be over before your parts come. This has happened.

But the physical examples aside, the key theme is more like…

It encourages students to seek information out on their own and discourages ‘thinking in terms of classes’. There have been many instances of a student presenting me with a part from a place I’ve never heard of because it was the only place they could find the part to their specifications. Or they found it lower priced on some other website, or even found it locally. What it comes down to is the class stops being its own little universe where all issues are resolved at office hours with the instructor. It doesn’t stop at physical products you can buy either – discovering that a part exists on one site, finding the CAD file of it on another, getting the best price from yet another is more an example of what I mean.

That’s how I shop for bearings.

I shamelessly tell people to research it if I get asked a very open-ended or poorly formed design question. Good example: “How do I make my steering linkage?” or “Which of these motors do you think will work?” – notice how those questions are phrased, such that if you answer them, you basically give the correct answer.  I’ve received feedback a few times that the class was really’ you teaching yourself’, both expressing that positively and negatively. The positive folks discover a world of go-kart design websites and records of prior work by their classmates and grow their bill of materials by 150% the day after.

The people who don’t take to that as well? I hope I have just introduced them to another side of the engineering dice. It comes down to being resourceful and discovering ways to help yourself (and your team) through the project, and reserving raising your hand and asking the teacher for very specific moments.

It exposes students to engineering management issues like supply chains, project schedules, and project scoping on a personal level. If I did have to pick favorites, this might be it. A very important skill that I learned through building many, many small crawly or rolley objects is how engineering projects tend to go. Many times, the issues with design classes isn’t that people produce bad work or are total noobs, but that nobody has a sense of the organization require to successfully execute all the plans that a brainstorming committee might produce. The plans are way too ambitious or complex for everyone’s collective skill level and the technical demonstration is like, two weeks away, guys…

One example of how I accomplish this in the class is the make-versus-buy tradeoff that is the weekly waterjetting. Waterjet machining is not on demand – I queue up the parts and run them once a week. In that week of waiting for your parts, could you have made that part in the machine shop 15 times over? How much did that impact your fabrication schedule to have a week of deadtime? Were you able to fill that week attacking a different part of the vehicle? The best case I’ve seen is students sending me the truly weirdly shaped combination motor mount and Pizza Hut and Taco Bell to be waterjetted, then spending the intervening time cutting out frame pieces and prototyping assemblies, finishing it just in time for me to deliver the piece on Friday. The same general pattern – do this now, or wait for someone else to do it so you can focus on another aspect – is present all over the world of engineering.

Once you have been through the cycle, you start to understand that on a more profound level than an engineering management lecturer telling you about timelines and delegation and Gantt charts. I throw all of this at you in a project that’s just complex enough to require planning and ahead-of-time integration (I do not allow controllers and batteries zip tied to anything), but small enough that you still know the state of every aspect of it. I don’t fudge deadlines or try to bail people out. It’s a veritable microcosm of a larger, team-based, big-budget show. Once you see the parts of a small project, you understand better how the same structures apply to larger ones.

It commits you to standing behind your work instead of whipping something up just to pass a requirement. I make you ride it. In front of all your friends.

This ties into the reason why I try to keep the class as free of hard turn-in requirements as possible. Too many requirements, milestones, deadlines, and evaluations means people just try to get something together so they can get the next 10 points. The project becomes a mishmash of bad hacks and we’ll-fix-this-laters. My schedule is purposefully very fluid with the exception of two or three hard deadlines: the vehicle inspections. If you rig something for that, it’s pretty much staying rigged and being raced that way. I think the 2.00gokart schedule in particular worked out immensely well – people completed far ahead of time and I had to schedule several drive testing nights because they were excited to run their semester-babies.  Trading go-karts in particular is a hilariously chaotic part of the last week.

Overall, I think the message is worth repeating, from the “introduction”: Give students the tools of practicality and channel their creativity first. The department has plenty of ways to back student knowledge with theory and science, and my hope is that when the two worlds crash back together again, my students will be extra-prepared.

Going hard in the week before the mechanical inspection…

9. Resource base and budget discussion

I left out one more reason. In my opinion, for the value you get out of a group of students who take the class and can go on to do bigger and better engineering projects with their skills, the class is relatively inexpensive. Let’s be frank: building things, especially large things, costs money. I don’t want to contrast with the build-a-little-robot sort of class, since the scale of the parts costs is almost an order of magnitude, if not more. A little robot drive motor costs single dollars and a nice small-EV motor can be over a hundred dollars. I also do not want to draw comparisons to the large organized kart racing events – they can spend tens upon tens of thousands of dollars on just a build, not to mention getting a team to competition and the associated support equipment costs.

I contend that a 2.00gokart style class is in sort of its own middle ground league with respect to cost. The specific reason I call it “relatively” inexpensive is the level of in-depth exposure the student gets to so many facets of modern engineering – mechanical, electrical (wiring), electronics (programming, sensing circuitry, controllers), fabrication and machining, CAD, etc. It’s all embodied in one person. Contrast this with a large team build where one student might have only one role in a much larger, costlier project scope and I argue the overall value of the class is decreased if it’s to teach engineering and engineering management skills, like what I describe above – if the role is to exercise them (such as in a sr. design class) then the comparison should not be made. One MIT professor terms this the “engineering Renaissance Man” effect.

I originally made it the goal of 2.00scooter to keep the budget to around $500 per student inclusive of any overhead such as shipping. Section 10 holds the actual accounting spreadsheet I used to tally costs for both years. Shipping was considered a fully separate category to keep its cost ratio calculable. I included the cost of “free” stuff that the students received from me in their budgets, including that year’s “semi-free” Razor scooters. I also kept a category of “consumables”, considered to be stuff like public hardware. The findings of the semester were:

  • Net cost per student including shipping and free stuff overhead of $503
  • Total money spent of about $6100 with consumable costs of $1100
  • The parts cost overhead % was right around 33% – the hidden costs of each vehicle added 33% to their values

It’s important to note that this does NOT include the following:

  • Access to a really nice and finished shop. I don’t have a list of literally everything you need to run the class like, say, MAS.863 does!
  • Batteries, which were donated for free. The cost of each A123 brick is $120 – so if you had to buy all the batteries and gave them out 3-for-free like I did, then the class cost might double!

The 2.00gokart session in 2013 broke down like so:

  • Net cost per student including overhead of $632
  • Total money spent of $10,200 with consumables cost of $3500
  • Overhead of 45% of parts cost.

Something about that seems off, right? I included $1500 of MIT waterjetting (done through the Hobby Shop) and $1000 of Big Blue Saw waterjetting for the sessions before my machine charge approval went through (that got it through REALLY QUICK!) and that I put in initially with the Consumables.

If the waterjet charge was moved to the one-time costs bracket, then the overhead drops to only 24.1%. This puts it in line with the trend of grouping people together in twos means less total orders and less shipping costs per part ordered, hence why the net cost was only an increase of about $100 for an increase in hilarity of 10,000%. But, for those without free waterjet access, the cost will be very real, so I would say the more fair comparison is the original.

For the SUTD summer session, I did not keep an equivalent accounting doc since it was too chaotic and this time I had the accounting kept track of by one of the financial administrators in the IDC who was working with the program (Oh, dear, I now have admin staff…). I know the final numbers, however, enough to draw some comparisons:

  • $21,000 spent total, everything included, for 28 students, which comes out to be $750 per student
  • $3090 of that was waterjetting costs alone!

The extra increase is explained by the fact that I bought something like $5000 of parts beforehand in order to make sure we wouldn’t suffer from shipping gaps. Many were included into the vehicles, but ultimately that skewed the cost per vehicle because a good percentage, maybe 40%, ended up unused. If I run with the 40% fallout rate estimate, it becomes $670 per student. But that doesn’t mean  Singapore didn’t get its money’s worth – I bunched all of that up and shipped it back with the karts. Good luck over there.

The general idea is a Few Hundred Dollars Per Student. Remember again to not compare to a giant team effort – spending, say, $6000 on a project but with a 17-person team might mean a low per-person cost, but everybody may not get the same level of immersion in the content. I’m unsure of how much 2.007 proper spends per-student not including facility costs (i.e. just parts) – I’ve heard $250-300 floated around before.

Lastly, here’s a summary of what resources I have in my ‘sampler basket’ of places to shop. If you have seen my Instructables or been in one of my resource lectures at any venue (e.g. Dragon*Con’s Maker Resources panel) then you have seen the whole gamut.


A slide from one of the resources presentations showing a website and a part of interest

In terms of parts, we concentrated mostly on the usual suspects for small electric vehicles:

  • HobbyKing for motors, primarily. For class consumables, I ordered wiring, connectors (XTs, Deans, bullets), heat shrink tubing, and 5-pin JST-XH harnesses for people who wanted to easily create sensor rigs
  • Monster Scooter Parts, TNC Scooters, PartsForScooters, ElectricScooterParts… the list goes on. These houses deal specifically with the kind of generic Chinese scooter and e-bike whose parts we repurpose for our own applications. Specifically worth mentioning in some of these include TNC stocking cheap go-kart throttle pedals when other people don’t.
  • McMaster-Carr for maybe 75% of the non-motor-and-ESC mechanical hardware on any one of these vehicles. I also purchased large amounts of (less expensive) wiring
  • Kelly Controller‘s KDS and KBS lines were the most popular for motor controller choices.
  • Burden Surplus Center was popular for some things which were found much cheaper – vehicles with large amounts of sprockets, for instance. Seats and steering parts also tended to come from here, as did some tires.
  • Harbor Freight is worth a mention since a majority of the IDC shop tools come from here. Don’t laugh. Several teams opted to use their $8-10 wheelbarrow tires for their main drive wheels, which saved money over a scooter-grade one but had to be “re-engineered” slightly.
  • SDP-SI was the supplier of belt drives and timing belts almost exclusively. Most of their stuff is very small and precise – timing belt parts are about the only thing I get from them that’s EV-relevant.
  • We ordered 80/20 rails directly from 80/20-the-company – they have local dealers which cut us severe discounts. McMaster has the extrusion material at a slightly higher price.
  • Online Metals took the brunt of my massive 500 pound aluminum plate order
  • Speedy Metals was the go-to for students who wanted small metal orders thereafter. McMaster was acceptable for some alloys, but expensive for others, and not all students took advantage of this – some decided to go ahead with metal orders from McM for speed of delivery.
  • Our batteries came from A123. Yours could, hypothetically, too.
  • I ordered bulk ball bearings for the summer session from USA Bearings and Belts. Else, during 2.00gokart, people usually ordered straight from McMaster or VXB, another vendor of Inexpensive Chinese Ball Bearings.
  • I designed these Hall Sensor conversion kits for brushless motors and sell them through my “company”, Equals Zero Designs. For the class, to avoid conflicts of interest, I supplied students with the sensor rigs for free (produced using lab tools, of course – I wasn’t literally giving away free stuff).
  • Quite a students found parts on eBay they wanted to substitute for a more expensive but similar part on one of these websites. My credit card approvers tend to dislike eBay/Paypal transactions, so I often just offered to replace those items for no cost penalty to their budget.

I’d say 99% of any one vehicle on average came from those vendors. Occasionally, the odd hardware store nut or bike-shop brake cable were used – these are also great resources if you have competent ones in your area. We made very little use of Home Depot, which seemed to be a staple of the garage go-kart builder at one point. Maybe now that we have the Shopbot, everyone’s karts will be made of MDF and OSB next year.

Resource- and reading-wise, the students primarily used lecture content by myself and the TAs. However, I did curate for them a good amount of readin’ material:

  • How to Build Your Everything Really Really Fast was essentially “the class textbook” for 2.00gokart and the summer session.
  • Electric Scooter Power Systems was… I don’t know, the second volume of the textbook? I can be making so much money as a professor with a captive book-buying audience right now.
  • Chibikart also was a reference for many folks – you can see it if you look at everyone’s steering kingpin and upright assemblies very carefully…
  • Gizmology, RoyMech.co.uk (oldie but goodie) were two websites I sent people to for some general mechanical engineering knowledge, particular their notes on spur gears, bearings, shafts and coupling thereto, beams and structures, bolted joints… you get the gist.
  • Fundamentals of Design is an invaluable resource that’s basically all of MIT Mechanical Engineering in one epic 7 course dinner you have to puke in the middle of to keep eating. It dives deeper into the why of mechanical engineering than I do. I refer people to its sections regularly, especially those focusing on structures, fasteners, bearings, and power transmission.
  • Many builders’ and makers’ websites and build blogs. An acutely toxic dose of them are in my own left sidebar – I’m not going to list them all out because everyone who builds and documents is a resource to others.

There are ones I’m probably forgetting at this moment, so this list may be updated without notice. This list of resources is not comprehensive – remember, I don’t have  a “class in a box” list because the whole point of the class is not to have a damned box. You may feel free to supplement any of your own resources.

10. Reference document section

In this section will be reference documents and full lecture note sets from 2012 and 2013, including any other resources I see fit.

The terms of use: These documents are freely available for you to use as purely a reference for your own project build or for basing your own class, seminar, or other learny-activity involving electric vehicle design. They are provided as-is and I will not answer questions or offer support pertinent to their use.  You are not forbidden from using the material verbatim in your own lecture notes with attribution; however, remember that the class is purposefully unbounded and this may not capture the extent of the information. If you redistribute them, you must include the license file in the zipped folders that says basically this.

It’s not my hope for this class to spin off a thousand copies of itself. I rather hope for this document-article-post-thesis-novel to make people think about the goals of design classes and the role of individual learning in engineering education. I saw a condition at MIT which I found unsatisfactory, so I used what tools and connections I had in order to try and craft an alternative. Your circumstances will most likely not be the same. 2.00gokart is not an attempt to start some sort of design revolution, nor is it meant to overturn the foundations of a modern engineering education. It is simply one other path, out of myriads, that motivated and spirited people have built in the interest of advancing the quality and accessibility of education for everyone. After all, even grizzled old professors at one point used to be young and boisterous. I don’t intend to stop running the class after this – hell no, so don’t think this is some kind of final mass ejection, but have written this summary as yet another exercise of my drive to document as many things I do as possible. In my opinion, you can never have access to too much information if you are determined to search for your own knowledge’s sake, and the more high quality and comprehensive information there is, the easier that search becomes.

Thanks for your time, now go spawn a go-kart.

 Editor’s note: I reserve the right to make spelling, grammar, usage, layout, and minor wording edits indefinitely. I’ll try to be transparent with them.

 

Recently

  • The Dragon Con 2014 All-Robots Update
  • Silly Go-Kart Design: The 2014 Summer Season
  • Chibi-Mikuvan: Detroit Recap and The Conclusion
  • Chibi-Mikuvan: The Penultimate Update!
  • Chibi-Mikuvan: Getting “Tired” of All This; Making the HCL Actually Function; Plus Other Work
  • Chibi-Mikuvan: Experimenting with the Trackstar 200A and the Hysterical Current Limiter
  • Beyond Unboxing: The Great Cambridge Chainsaw Massacre; Ryobi RY40511 Cordless Chainsaw
  • Chibi-Mikuvan The Extended Universe Edition: Water Cooling Loop and Digital Dash
  • Chibi-Mikuvan: More Stickers is More Power, Right?
  • Miscellaneous Van Adventures: Fuel and Coolant
  •  

    5 Responses to “On 2.00Gokart; Or, Designing a Design Class to Disrupt Design Classes as We Know It; Or, How to Make MIT Undergraduates Build Silly Go-Karts so You Don’t Have To”

    1. Graham Says:

      I’m an engineering student at UVic, and I wish we had a class like this one, basically everything is theory for us.

    2. Dane Says:

      Bravo,

      This is an intense writeup. The detail is awesome and everything is in one place. Just putting something like this together takes time, and, i may be speaking for the internet here, but,

      Thanks From The HIVEMIND.

      -Dane

    3. Allen Says:

      Not sure you want +10 points of efame, but if you had someone shoot it, this would be a great addition to the open courseware. I’m sure many people will find the lecture slides useful, but if you could get all some of those hours of Q&A on film, there’s probably massive amounts of information that isn’t captured anywhere else. Many neckbeards throughout the internet would be highly entertained.

      Either way, that’s for the contribution.

    4. Darkknight512 Says:

      I agree with you entirely Charles. I love how you pretty much encompassed the idea of engineering competitions in this course.

      I learned a lot more from 6 week in FIRST robotics then probably all the design classes I’ve had combined. I am also part of a Formula Hybrid team and it clearly true that everyone that is on the team and builds a significant portion of the car will learn the concepts of their courses way ahead of time making their lectures both more interesting and more effective in creating good engineers.

      I wish you taught everywhere so that you will have a larger impact on the way engineers are trained in schools.

    5. Simon Says:

      You should write a book. Seriously.