DARPA MBARC Contest: The Recap; or, Charles on How to Run a Project Class and Not Fail Miserably

I’ve been mysteriously absent in a usually action-packed January; it being MIT’s IAP , or to unproductive slobs like your truly, an extended winter vacation, I usually post buildy things almost nonstop. Hell, there hasn’t even been another Überclocker update yet (more on that later…), and I do have some more minor post ideas backlogged that I need to get to soon. There are some other seriously exciting things coming down the line too, such as the VERY FIRST RAGEBRIDGE SHIPMENT!!! by middle of next week, and the DeWut setups not long after. And I believe I’ve finally gotten a functional order system going – so, if it interests you, feel free to pick yourself up some Hall Sensor boards!

But, so long as it is fresh in my memory, let me tell the story of a particular project class which I was a quasi-lab-kinda-TA assistant to this past semester which turned into a classic robot contest struggle against time and broken parts in sunny San Diego, and in conjunction with another well known MIT lab class that I was a shop guy for, discuss my philosophy on why university design classes often fail or disappoint students.

Damn, that sentence alone was probably worth 30 SAT points. To get to the meaty part of the post, use this link.

The Class

Let’s begin with a little background on what the MBARC is. First off, the program itself has no website – for all I can tell, it’s a subprogram of another program which is ultimately under the DARPA Adaptive Vehicle Makes (AVM) program. Whatever. Given that the only search engine coverage of “DARPA MBARC” so far is from people’s LinkedIn profiles who have been involved in it, I suspect this post will unintentionally Googlebomb the program and the first thing curious onlookers will see is my impending trainwreck. That’s okay – so long as any higher-ups understand the views expressed on this page are mine exclusively, not MIT’s or any of its internal organizations, and are not endorsed by any consumer electronics company or pharmaceutical firm.

Anyways MBARC is the Model-Based Amphibious Racing Challenge. What “model based” means in this context is that you follow a specific set of design process rules and meticulously produce simulations of the vehicle’s performance (necessitating also meticulously modeling and mathematically characterizing the components and their interactions) in several challenges, using software such as Modelica or a pile of MATLAB scripts. From what I gathered through my very, very carefully planned avoidance of this part of the class, the whole point is to test out a new design process called META that DARPA is working on. It’s one of those super high level design things similar to the V-model or MAUT which are used to formalize, apparently, brainstorming and sketching an idea down, because in academia, everything needs to be formalized because someone’s career depends on having that card of credibility.

The MIT class based around MBARC is called Fundamentals of Systems Engineering, an Aero-Astro (Course XVI) graduate course, and it takes students completely through the motions of engineering an example complex system such as an aircraft. I’ve been told that in past years the class has been exclusively design-on-paper – you are given a task, you define the goals, you generate and select concepts, optimize aspects of the design through cost functions (how well it accomplishes the task, whether it be literal lowest-cost, or most efficient, least resources to manufacture, or some multidimensional combination thereof), and a whole lot of other arm-flailing. The difference is that this year, the course also required students to build the thing.

The Beginnings

I was brought on over the summer (the Chibikart Era) through discussions with course administrators and faculty. The general idea I got at the time was that I would be acting as a design advisor role – that I would essentially be coaching a student robotics team of sorts through parts selection, fab, and testing, since I’ve traversed all of these minefields many, many times. This was not an official commitment (i.e. I wasn’t being paid from the program, etc.), but I took it anyway because I like seeing things being built and people learning by building them, and I was recommended for the task by one of the professors I know well. Overall, a win-win for the Collegiate Silly Project League (of which the Collegiate Silly Vehicle League is a branch organization).

The students themselves, as I gradually learned, were mostly Aero-Astro graduates with very little experience building the type of system they were tasked with; most had not built anything at all.

Let me repeat that: that these were Aerospace students who were being made to build a ground and marine vehicle. You can make many fish-out-of-water jokes here, possibly involving flying fish. There were, however, several mechanical engineers also in the class, as well as students with long R/C model backgrounds. In the end, the teams were fairly well balanced out with these students.

I’ll also take a moment to affirm that in fact, the position was exactly as advertised – no facetiousness or sardonic assessments of “legit” engineering here. The students in the class asked me questions regarding parts, regarding design advice and potential pitfalls, and I answered them, occasionally helping out with minor fabrication or debugging. I liked the group a whole lot, in fact, because it was a welcome break from the usual style of questions I get, which are more “give me the answer” than “push me in the general direction”. Perhaps it’s just the difference between jaded grad students (like somebody here…) and bright-eyed, paddle-tailed MIT undergrads.

The class made extensive use of lithium polymer batteries, which should give anyone with firsthand experience watching newbie builders the shivers. Overall, it was handled well – through a combination of the students with R/C plane experience and my relevant ground vehicle history (e.g. how to mount batteries when your thing isn’t made of soft foam and CA glue), everyone ended up with proper balance chargers and fused wiring harnesses, etc.

With regard to parts specification, this is where I was able to help the most. The size of vehicle the challenge required – able to carry approximately 20kg plus its own weight (up to 30kg) meant it was too big for most R/C model parts, being in the awkward grey zone of 1/5 scale ground vehicles and small & medium robot parts like Ampflows (nee Magmotors). There were plenty of opportunities to order parts which wouldn’t work across these domains without significant mods or rebuilds.

To address popular concerns like these, I gave a few mini-lectures on popular topics such as sizing electric powertrains and how to not trust R/C hobby part ratings, and also how to wire up electric power systems without lighting the building on fire, 787-style (Too soon?). I considered it good practice for basically having to do the same thing in a few weeks, for the NEW AND IMPROVED!!! Electric Vehicle design section of MIT’s 2.007 course; details of this are, of course, also slated for a future post.

The Creations and the MIT Internal Contest

This is the fun part! In the end, all 4 teams in the class, each made of 4-5 people, made it into our internal competition held at nearby Constitution Beach in the middle of ass-freezing December (the warmest it got all day was about 45F). Everyone got on the beach and ran, for some definition of ran. Here’s the rundown of what was built, taken towards the end of the semester with about a week to go or thereabouts.

Some  innovative designs came out of The Process. In no way was the absolute most optimal design required, or else this double-hamster-ball torpedo probably would not have been selected. Inside, two independent motorized swinging weights (using the payload weights themselves) forced the freely rotating outer tube to roll along the ground. Later on, a nosecone and rear propeller unit were added.

Other teams stuck with more conventional designs with a boat hull and wheels, like the classic DUKW. I participated the most in the build of this machine since their drivetrain and power system layout was very similar to things I’ve built – though by “participating” I really mean helping out with motor and controller selection. Of all the entries, I think this one had the highest sheer amount of Lipoly batteries – the intention was 6 packs of 7S 5.0Ah.

Another similar-but-different design uses a fully wet drivetrain (not passing through seals in the sides) with “outboard” motors. A double-sided timing belt track acts as tank treads. This team worked mostly outside of the IDC lab space the class was using and which I am the quasi-guardian of, so I didn’t get to see this machine until the “final presentation”. Imagine my reaction at seeing the single-supported plastic bearing blocks for the first time. Hey, at least the custom TIG-welded aluminum plate hull was pretty cool.

The last team took the “null hypothesis” solution. A “seed design” was allowed in the class based on a Traxxas E-MAXX monster truck, and they added cargo carrying appendages, paddle wheels, and a flotation hull (front and back not shown). Otherwise, it was pretty much bone stock.

The MIT internal contest was held on a sliver of Constitution Beach, the only beach-like structure that was reasonably close. Hilariously, Logan Airport (BOS), one of the poster institutions of post 9/11 security hysteria and well known for looking silly in the media when MIT students roll through, was perhaps 1/3 mile away (the control tower is visible in the background and the nearest runway was directly across the cove). So we were all a little ironically on edge when the vehicle and equipment were unloaded. After all, if you were a highly stressed and somewhat underpaid ATC and you saw a bunch of random dudes loading what appears to be a torpedo and other shiny metal boxes onto the beach, what would you think?

The challenges followed the MBARC rules and the following courses were set up by the TAs and I:

  1. 100 meter straight dash across the sand (timed)
  2. 25 meter water challenge, with 10 meters of ‘acceleration zone’ marked off by bouys (timed)
  3. 6 laps of 200 meter water-and-land challenge, 100 on land and 100 in the water. (timed)
  4. 200 meter water-and-land challenge, as many laps as you can do, carrying as much payload as possible up to 20kg (weight * distance, basically)

In the end, “Ampflow-kart” as I started calling it (due to its use of gratuitously overpowered Ampflow F30 motors – this thing pretty much had 4 horsepower on board) won the challenge because it.. did things. It successfully navigated the land and water course and also attempted the 3rd challenge, the amphibious payload race, but the water side began failing midway.  Unfortunately, the torpedo succumbed to sealing issues immediately and failed electrically almost right away. The R/C cars performed great in the land but stripped the stock plastic drive gear in the water (probably due to a combination of both high speed and load). The aluminum hulled tank was forced to switch to wheels after the tracks were found to be too easily clogged with sand, but the wheels unfortunately caused it to dig into the sand too much to effectively run the land challenge. Unknown electrical bugs possible related to the receiver being soaked with seawater prevented it from continuing in the water challenge.

None of the teams were able to *complete* all 4 challenges, and not enough time was allotted in the day to even attempt the fourth.

The National Competition

After the class, team Ampflowkart was selected to participate in the national MBARC challenge. Most people left after the class, but the remainder merged into this team. Most of January was spent performing upgrades to the hull and water side drive.

Fatter wheels, a more lightweight frame, and the more powerful A28 Ampflows were added. Like it needs more horsepower. The drive electronics from the aluminum tank, a set of Sabertooth 60A controllers, was recycled. Remarkably, they held up well – I showed the trick of running two ESC channels in mechanical parallel on a 4-brush motor like the Ampflows, by each powering half of the motor. So, one “dual channel” ESC ran one motor.

RageBridge was the emergency backup if the Saberteeth failed. I soldered up and tested 2 of the latest revision (with trimpot) boards for the team, but fortunately they were not needed!

The hull was painted and had a extremely flat top surface added to aid in sealing the lid (curing the resin upside down against a glass mirror allowed it to be very smooth). The water side was upgraded with better propeller shrouds and a steering rudder, though when this was found to be ineffective, the team returned to using differential thrust.

I was asked to come to the competition by the team in January – wasn’t really planning on it, but hey – free trip to San Diego and a chance to help out with rushed pit repairs (because at robot contests, there are always rushed pit repairs. Always) given the rest of the team was fairly inexperienced in this regard. The competition was held at Marine Base Camp Pendleton, north of Carlsbad, CA, on their beachfront installation Camp Del Mar.

The vehicle, now re-christened Sasha for reasons I was not around to hear, was shipped ahead of time along with most parts and tools. The rest were brought on the plane ride, which was fairly uneventful and was not on a Boeing 787. A decision to carry-on a Lipoly pack per person (there were 9 of us going and 7 batteries to bring) was scrapped because… yeah. The team ordered a full set of batteries plus replacements to be shipped to CA directly as a result.

The hotel received the shipment prior to our arrival, so the night before the first day of qualifying and testing runs was filled with last minute hotel room machine shop work. Just like a robot competition should be. I must say that this hotel was one of the most laid back I’ve ever been in about Dremelling and drilling steel at midnight – “as long as nobody complains”.

The briefing on practice day about entry/exit policy (since we WERE on a military base, after all), alloted times, allowed spectators, etc.

The Marines of the I-MEF brought out an AAV-7A1 on the beach as a reminder of what the teams were supposed to build.

“Sasha” prepared for battle, with the optional Beaver of Intimidation attachment up front.

Two other schools participated in the challenge. U.C. Berkeley entered two vehicles, one of which was this fuzzy caterpillar tank using very innovative homebuilt track-paddles that seemed like the most time-consuming thing in the world to assemble. It was driven by two generic 450W scooter motors, a chain drive, and an Arduino motor shield. And it worked. Very reliably, just rather slowly. Its sheer consistency was feared by the other teams, but unfortunately the slow part… uhh, caught up? with them in the competition. The tracks were also easily bent by the rocks on the beach, and by the end their water speed was significantly hampered by this fact.

The other Berkeley vehicle was an R/C truck mod with flex-shafts spun by outrunner motors controlling 2 propellers in the back. Basically Sasha’s stryofoam and duct tape cousin with a congenital illness or two. It was very fast on land, but the flex shafts proved to be unreliable.

Vanderbilt University showed up with a much more fearsome and customized R/C truck mod which had a fabricated frame and hull, but stock R/C truck driveline and suspension components mounted to it, powered by the biggest inrunners I’ve seen. This thing was a rocket on land and also quick in the water because of its thrust-vectoring jet pump similar to this one. It was our biggest contender, and essentially ended up winning the first 3 contests.

Where “Sasha” excelled was sheer carrying capacity and horsepower. Being R/C part based, the other entries (save for Berkel-tank, or DUCTank as they called it) simply could not carry more than 1 payload mass (5 kilograms) effectively. In the last challenge, the max payload * distance run, we loaded up the vehicle with all 20 kilograms of weight. While it hung low in the water, earlier testing confirmed that max payload was the best condition for it because the propellers were forced completely underwater and could not pull in air from the surface by revving too fast – essentialy allowing more thrust before the onset of cavitation. The added weight also allowed for more positive traction when the vehicle approached land again, and the brute force of the Ampflow motors and giant balloon tires meant it could navigate the rocky portions of the beach with ease.

Unfortunately the giant balloon tires did have their own downsides – the team elected to use stock R/C buggy hubs on their own custom 3/4″ aluminum axles, which entailed necking down the 3/4″ aluminum to only 8mm and then drilling a cross pin. During one of the land challenges, a wheel broke off.

Now, you may ask “but why didn’t you stop them?”. While I certainly could have raised reservations about the design, I also didn’t want to interfere too much. I did mention the possibility for weakness once or twice, but didn’t push the issue. If it wasn’t clearly and obviously bad, I let them ask the questions first.

Either way, uh oh. The group of mechanical engineers, myself included, huddled for a short while to come up with what could be done in this situation, given that we had no machine shop access. The fix had to be sourceable from Home Depot and the tools/parts we brought.

The solution we came up with was to make a stack-of-washers-JB-welded-together preloaded spacer for the necked portion of the shaft. The stock buggy hub tightened on with a thread, so if it was tightened against the tapered neck and the outside stack of washers compressed against it, then most of the bending loads at the end will be transmitted through the washers into the fatter aluminum shaft instead of cranking on a tiny 8mm part. With a cross-hole.

Plenty of JB weld was used to fill gaps and make sweeping fillets, and most of the team was deployed with hotel hair dryers to accelerate the cure overnight.

The work paid off the day after when the real competition ran. Nobody suffered extraordinary Lipoly flameouts, or sank, or had any more serious mechanical damage besides broken belts from Vanderbilt (who had a single 1/4″ wide XL belt trying to hang onto a 2.5″ diameter inrunner motor?) and Berkel-tank’s bent track screws. Sasha the Ampflow-powered Beaver-bot performed perfectly without incident, but did have brief water-side controller overheating problems during the fully-laden run just due to pushing too much power.  In the end, team MIT wins by a significant margin (about 20%) over Vanderbilt. Above is the dinner party where all the vehicles were on display and awards/accolades given out.

Whew, that was alot. All said, I think the team members learned much from an actual project deployment and fixing in-the-field scenario, and also picked up much practical making-the-parts-work-together skill during the build. People who were not R/C electronics experienced at the beginning were the wiring/electronics crew chiefs by the end. I was lucky to be aided by another team member who had extensive experience in Design-Build-Fly as well as others from FIRST Robotics years ago, so the pit crew dancing was not as chaotic as it could have been. I primarily hung back and let them do their thing and jumped in only when something needed backup.

On the way back while hanging out in the SAN airport, I whipped together a super-short highlights video with some of the videos I captured (being shoehorned into the role of Event Videographer because I was, somehow, the only person with a functioning video camera that day…)

So that’s a wrap for the first half of this post. I’m already at 3200 words, and I’m not stopping any time soon, because…

Charles on How to Run a Project Class and Not Fail Miserably

Full disclosure: I actually participated at a teaching assistant/lab assistant level in two classes this past semester. Besides the Systems Engineering With Ampflows class, I was also a TA for MIT’s renowned MAS.863 “How to Make Almost Anything” class.

In semesters past, I’ve been a TA for 2.007 (Design and Manufacturing 1, or the Precursor to FIRST Robotics), ran a lab section thereof last year focusing on electric vehicle systems, and I’ve indirectly advised probably dozens of students on their own projects or class projects I’m not part of.

All of these times spent answering questions of the same general style has led me to several conclusions about university design classes, especially here at MIT.  I’m not campaigning for change, nor out to criticize the way one class or another does things. I’m just relaying my personal thoughts based on the examples I have been afforded. I’m hoping that more people realize that project classes can be beneficial and terrible at the same time, and that very small organizational initial conditions can throw it one way or another – students with completed projects and excellent ability to use the class knowledge, or half-assed late night tape-togethers with poor retention and bad memories.

So here’s some of my gripes with project and design classes in general, listed in no particular order of importance.

1. The project needs to be scoped to match the class skill level

This one is almost sounding like a no-brainer, but it’s harder to pull off than you might expect. It is my opinion that the systems engineering class had two major flaws with respect to matching the skills and experiences of its students.

First, it overestimated how many had extensive enough experience to handle a full-on mobile robot build. In mechanical engineering, we don’t tell freshmen and sophomores to “build a lathe”. Sure, given enough guessing and and checking, a team of previously inexperienced machine designers will probably return something that looks vaguely lathe-like, can spin and hold something while allowing you to move a tool against it in some way, and might be powered by connecting a battery to the spindle motor. But what it wouldn’t have is concentricity, deflection and stiffness control, smooth sliding bearings, etc. The small details set a visually complete project from a functioning one, and great high-level conceptual classes do not teach the details; those pretty much come from experiencing it all firsthand, in my opinion.

Related to the first issue, it made the classic academic mistake of assuming that real world parts all click together and function – underestimating the amount of potential pitfalls and caveats when it comes to working with real parts. This was really where I was bolstering team efforts the most. I’ve been through calibrating a motor controller before, or binding a receiver, or not using the tiny set screw that came with your pulley to transmit several horsepower. The amount of connector swapping and adaptor making required, for example, was a testament to glossing over the small detail of what connector did these batteries come with again? I think now all of the students have a much greater appreciation of having to interface with real world components and taking it into consideration while they design, not all afterwards.

This part makes it seem that the only way for people to do well in project classes is to make sure they all have built things before – which leads to a slight infinite recursion problem, right? I think the value of a project class is when the target is just out of reach enough that people rise up to the challenge. This implies that the project take into account students’ backgrounds, and possibly involve different tiers of projects for students who are skilled in the subject matter versus not.  Yet this is actually one of the biggest pitfalls of project classes – generally the projects are one-size-fit-all in terms of constraints and demands because instructor time and class resources are limited. What may be a world of complexity away for some students may be boring to others. 2.007 suffers from this issue almost implicitly because it teaches almost the entire Mechanical Engineering class for one year, and there is a huge spread of student skills and knowledge.

Part of the reason 2.007 began adding “special” sections (of which my “2.00gokart” effort is one) is precisely to cater to those students which might have different interests or find the class too simple otherwise. Hence, in my section, I make some simple assumptions – that you basically know how to use a manual lathe and mill already (I had to give some refreshers to a few students last year, but by and large they at least have been around the block before), that you’ve built something in high school or on your own, and that you have a concept of what torque, speed, power, etc. were (but may not fully understand how to integrate all of it together yet). The mathematical and theoretical requirements of the class weren’t harder – hell if you could get me to do that – but just applied differently and on a bigger thing. In fact, basically all “vehicle design” equations are first order algebraic or differential equations, something everyone should know by then. Some of these assumptions will change for the coming semester – I do want to start mixing in some totally green newbies into the class and see how well they can pick up peer-based learning.

Speaking of bigger things

2. The project either needs to be the focus of the class, or small enough in scope to not accidentally become the focus of the class out of necessity

What I mean by this is that if 90% of the class is spent on learning the material, making models, learning the theory, etc. then the last 10% of the term better be enough to finish the project without everyone putting in a thousand man-hours.

Here is where the distinction between “lab” class and “project” class is important. A typical lab class may have students working on several premade systems (the lab stations) with only a small project component at the end. MAS.863 and some of the Course 6 classes I took (e.g. 6.131, Power Electronics) were set up in this fashion. The idea is to not build something team-based and epicly complicated at the end, but to merely extend a lab exercise with your own twist to demonstrate learning. If the student goes overboard then and can’t finish, then the philosophy of giving someone just enough rope to hang themselves with holds true. 2.737, the Mechatronics class I built Segfault’s controller for , was a great example of this on my end – Segfault was an extremely ambitious project; though most of it had been built by the time the final project season rolled around, I still spent many sleepless nights testing the analog feedback loop, and it was working for the first time about 20 minutes before showtime. I am extremely glad it did work, because otherwise I would have flushed my entire class grade (up to that point, my performance in the class was admittedly sub-par).

A project class on the other hand, I assume focuses on the design, construction, and validation of one big thing. It’s essential that as much content as possible in the class relates to that thing, I believe. Whether it be outright construction of system modules or assignments targeted at facilitating the construction of that thing. We try to do this in 2.007 by relating homework exercises to usable mechanisms and practicing Arduino coding with test setups that could mirror a robot’s electrical system or sensor setup.

The systems engineering class, though, was taken up primarily by the design-on-paper portion – at least 2/3rds of the semester saw little activity in the shop as people were modeling and simulating, and really all the building happened in the last month (November and some of December). As a result, they could not take advantage of Hobbyking, et. al. as much as they otherwise could have, since the lead times were too long, especially near the end. Many trips were made to area hobby stores to search for products which could have been ordered with sufficient lead time for much less cost. Even during the last build push, parts of the teams were still working on finishing the class assignments and reports while the previously experienced people were the ones hammering away at the vehicle.

If the project can’t be small in scope and the class is heavy on material, make it 2 semesters! Perhaps the biggest gripe I gathered from the systems engineering class was that the timespan of the project was simply too short for the sheer size of the project. There are some other design competitions for aerospace engineers  – such as Design Build Fly, in which the first semester is the design and the second is the build and fly. We here at MIT seem to be enthralled with the concept of the 1 semester learn-and-do-everything clusterfuck, and I think some of it is just not necessary and counterproductive to creating a robust, functional project.

Given the choice, I would absolutely split 2.00gokart into 2 semesters. The first semester would be design and analysis based, with lab bench level experiments to learn how to find motor constants or even designing and building a small, simple DC motor controller (or brushless if you’re really ambitious). The next semester is the build of the vehicle itself, with revisions to the design and continual analytical development as problems are discovered. The material would be much more in depth and people would have more time to absorb it all, instead of hurriedly moving onto the next thing because you did enough to get the B.

3. The process of ordering parts must be streamlined and competent

This point is perhaps the most important, in my opinion, because I see it being ignored so often. Hence, I’m putting it last. That way, it sticks with you longer!

Like many project builders, I find that if I am working efficiently on something, I am ordering parts almost daily.  At least a McMaster boatload per week. Without the parts to execute your design, there is absolutely nothing you can do but sit and twiddle your thumbs. Just the thought of knowing something is coming within a certain timeframe can help you plan and schedule operations to meet it. Part shipments act, to a degree, like waypoints in the build process. If you can buffer all your parts beforehand, good for you, but I guarantee you forgot something. One screw, a spare sprocket, the battery that doesn’t fit into your compartment as it turns out. And if it takes 2 weeks of purchase order processing by The Bureaucracy to get that part, then you’re pretty hosed – mistakes do happen, and it’s a matter of when, not if.

An efficient ordering system is critical if not all the parts are supplied by the class right away. Somebody with a credit card. A blanket purchase order at the supplier of choice. Even people with personal money that can be reimbursed at the very end in one shot, if appropriate. The worst possible scenario is that everything has to go through multiple levels of administration and authorization before being sent out. Many suppliers of useful parts these days don’t even have formal purchase order systems since they’re just online shops. Flexibility and response time is key. You say that you supply everything the class needs to finish the project. Are you sure?

In the systems engineering class, many students ended up taking on hundreds of dollars of personal expenses just because it was the quickest way to get something – that Home Depot trip needs to happen now, or we need another piece of bar stock from the machine shop. Whatever it is, it could not wait for the parts requested to be sent to the financial administrator, for the email to be read, then the order placed for them with the possibility of introducing errors in the transcription of “We want this” to the actual part, and possibly wrong shipping service selection (Next Day? Oops, ground!). In our case, it was handled reasonably because the financial administrator was extremely competent and understanding, but for many cases, just not fast enough because we students love to come up with a new need at exactly the time the business day ends.

In last year’s 2.007 electric vehicle class, I compiled orders from 6 or 7 different vendors twice each week. Not just once, but on Monday and Wednesday. The idea of the class was to get people to experience the importance of specifying and ordering parts to a successful project. The class had no “kit” to speak of – nearly everything, save for a free wheel, was put into a bill of materials, submitted and approved by me (I had the right to question parts if they didn’t seem right – often resulting in the +2 “OOOOHHHHH” Of Enlightenment), and ordered. It was a ton of extra work on my end, and our financial administrator also had fun keeping track of what week’s receipts we were on, but I think that was the one defining aspect of the class which set it apart from the rest of the department.

I’m pushing 5500 words now, having overshot the previous longest post on my site by like another 1500. This is probably more to digest than anyone is every going to read, but I had to put it out there because of my belief that project classes can foster the greatest possible learning and self-driven achievement from students if they are done right. I’m never going to pretend that my concepts are perfect, but I think they’re just different enough from the usual build-it classes around here.