Reassembling a Bridgeport J-head with Uncle Charles! And More About Hooking Up Your Annoyingly Chinese VFD

You know what? I’m tired of having sweet-ass machinery sitting around not hooked up. Last time in “Charles takes forever to set up his own shop because he’s sick of setting up shops”, I did some battle with a generic Chinese VFD and completed what the damn factory couldn’t be buggered to by adding the dynamic braking components.

Though Bridget ( <3 ) ran since then, there were some issues. The spindle brake was so worn it was difficult to change tools, and the head made the “Bridgeport Clack” from the high/low speed dog clutch being worn. The motor’s V-belt was also severely worn. I wanted to tear it down for a rebuild of sorts, so I spent a little while watching “How to rebuild a Bridgeport head” videos. I decided that all of these videos sucked, and that I was really only interested in repairing the brake and replacing the timing belt and V-belts.

So here is my documented take on how to take apart a Bridgeport 1J head. In it, I discover that it wasn’t as terrifying as I had thought originally, and that old-school American engineers might commit some abominations but damn they’re good abominations. I guess this is kind of a Beyond Unboxing, too.

Step 1: Dismount the motor, which is retained by two studs, one with a set of two jam-nuts to let it move a little for belt tensioning, and another that’s the ball handle (you unscrew the ball handle and then untighten what it’s attached to). Then, crank the head about the Y axis (roll) 90 degrees.

Six socket head cap screws live underneath the belt cover casting and retain it to the steel back-gear housing. You can take all these off; pins retain the belt cover afterwards, and it needs to be yanked off. Don’t worry, it’s not heavy. But there’s one catch:

The back-gear timing belt pulleys both have flanges. To remove the belt cover means taking off one of the pulleys with it, and that means removing the belt with it. You have to remove the four slotted head screws that keep the pulley flange on. Once it’s gone, the belt slides off with everything, like this:

This setup is quite the abomination. The timing belt has no tensioner – it relies on good will and good spacing. Mine was getting a little loose from the years. While I haven’t run the machine hard in back-gear range to see if the belt skips, I ordered a new belt anyway since it’s a “Might as well” item. The belts, and other rebuild components which will be seen, came from H &W Machinery Repair.

While the cover was off, I cleaned off the thick layer of congealed rubber dust and spindle oil. I didn’t break into the back gear cavity, however – if you do, remove the nut on the big pulley and use a gear puller or Three-Phase Prybar to pop it off, then undo the remaining screws. Some times the gear cavity is filled with grunge; if your machine had multiple owners, chances are it has both grease and oil in it.

I loosened the cover and a lot of remnant oil started pouring out, so I’ll likely keep it together but drown it through the front oil port later.

The second step pulley and back gear timing pulley live with the belt cover and has a large bearing carrier assembly under it. To undo this, I need to remove the shifter mechanism.

The pins that ride in the shifter groove also help retain it completely. Problem: One of them was completely stripped and wobbly. Due to the pressure exerted by loading springs underneath the pulley, I couldn’t get the pin to bite on its remaining threads and back out. So I drilled straight down the center and threaded the hole for a #4-40 screw that I could then grab with pliers and pull on:

The stock machine has slotted head pins; H&W sells a replacement with a hex wrench drive. Here’s the victim screw driven in…

And a few tugs later, the shifter ring is freed.

The pulley then flies off the other side, since there are loading springs underneath it.

And here we have the brake assembly. The brake is simply a phenolic drum brake setup that crams against the interior of the pulley. Nothing sophisticated at all!

To remove the brake, you have to remove the 3 slotted-head shoulder screws holding it down. However, to do that, beforehand you have to undo the three hex nuts on the top side (underside in these photos) – they prevent the shoulder screws from loosening.  After that, the brake can be wiggled off gently. It will snap closed, due to its own return springs, so watch your fingertips .

The small tongue on the upper right of the bearing bore is the cam that toggles the brake shoes.

Many times, when a Bridgeport spindle brake is worn, it means two things – one, that the brake shoes are worn down, but what I found is that the cam had also dug a little trench into the brake shoes where it makes contact. So this has reduced the effective travel length and caused the brake shoe to lose engagement. In fact, it seems like the harder you wail on the brake lever, the quicker you induce this 2nd failure mode.

Also, Brigeport brake shoes are expensive. Speciality exotic part, sure, but I can do all 4 brakes on Mikuvan for less money using nice ceramic pads too! So I wasn’t going to replace these, but simply make the cam bigger.

Returning to the top side, the brake cam escapes if you untighten the set screw holding its handle pin in place. The pin slides out and the whole thing falls apart.  The cam and shaft assembly are on the upper right.

The fix? Make the cam bigger by welding repeatedly over it, building up more metal, then sanding and filing it down! This was after the rough-sanding stage. I filed a gentle round onto the engaging edges so it doesn’t cause further erosion of the phenolic laminate brake shoes.

Alright, we’re now on the reassembly path. The brake cam is going in back in…

Secured up top, along with installed brake shoes and re-tightened locking nuts.

I reassembled the shifter ring after cleaning the whole area and thoroughly greasing it. In Bridgeport maintenance, you’re supposed to oil the shifter ring daily in production use. I think I’m fine with putting in a few greasewads where it needs to be instead of having to clean up even more crusty oil grunge down the line.

The belt cover is remounted now.

Before final assembly, make sure to thread the timing belt and V-belt back onto the pulleys. Then as you line the belt cover on, wiggle the timing belt onto its large pulley.

When finished, you can then replace the small screws and pulley flange.

Putting this motor on was the precarious part, since it involved holding something pretty heavy and wiggling it from an awkward angle! I threaded the two jam nuts onto one side in order to hold it in place for….

Final head tilt. Here are the newly installed parts! And there we  have it. Shifts great, runs smoothly. Still makes The Bridgeport Clack, but further research showed me that is all in the quill spline drive and there is not really a way to R&R that short of replacement. I’m fine with it.

Moving onto controls! I can’t use this thing from a potentiometer dangling by its wires forever. You may, but I have standards.

I put a little money on eBay into some more machine style switches and buttons.

I had two buttons left over from a project long ago, so they were going to be used as the Run and Stop functions. The same potentiometers got transplanted into a panel mount which I screwed into the housings. Knobs were a matching pair (rare! legendary!) found at MITERS.  The two-position switch will control forward vs. reverse.

The wiring was concocted using disembodied Ethernet cord, which is one of my favorites for pirating cables from their intended purposes. The VFD’s Use of Manual™ just showed a bunch of normal looking switch symbols connected to the forward/reverse, start/stop/reset, etc. inputs.

This is where I discovered another great undocumented feature of Use Of Manuals. The diagram was a lie, but only enough to get you in trouble.

I had problems with it accepting my switch configuration. I found that the VFD didn’t want to read my stop button at all, and it accepted any flip of the direction switch as a “run” command. That is, I can toggle the forward-reverse switch for it to change directions, but it wouldn’t take my stop button input. I’d have to hit the STOP button on the control panel of the VFD. After that, I couldn’t start it by using the start button, but just changing the state of the direction switch would let me turn the knob and increase speed again. Well, all of my settings seemed to be correct for the job, so I was a little confused and figured there must be Undocumented Behavior. This was certainly inconvenient to use the damn thing intuitively, and I certainly wouldn’t let anyone else touch it in this condition.

It took a few friends with experience in industrial controls to point out what I was doing wrong.


That is a diagram for a normal industrial magnetic contactor, showing how Start and Stop buttons are typically wired. In these things, the STOP switch is always closed unless something causes it to open (either by accident or on purpose). The Start switch, on the other hand, briefly powers the contactor coil which pulls in not only the main contacts, but a little auxiliary contact that keeps the coil energized and hence the contactor latched. You can see how any number of interlocks (e-stop systems, overload detection, etc.) can work its way into the STOP circuit and turn the machine off when needed.

The VFD is technically designed to replace this setup, so it’s expecting the Stop button to be normally closed. Well, all my switches are N/O type (close when pressed). So the VFD was waking up in an unexpected mode, I guess, where it seems to default to treating any forward/reverse switch inputs as “Okay, start running”. Well this seems a little scary of a failure mode.

Anyways, the Use Of Manual shows all switches as N/O, so it definitely assumes you already know industrial control practices to use it. That’s another endearing characteristic of Chinesium… you better know exactly what you’re searching for, or else you might find it.

Well that’s quick fix. I didn’t order modular contacts with my switches, but luckily they’re manufactured modularly enough to use the same set of contacts, just internally turned upside-down, to become N/C. Now my control panel works as expected – the stop button puts the VFD into slow-down-and-brake, then start will ramp the motor back up to the previous speed it was at. In run mode, I can change speeds at will, including braking down to zero speed manually.

And here’s the test video.

Now that I understand this setup (or do I….), I can build the second control box accordingly. It’s also easy now to add an anti-face-eating emergency stop mushroom button anywhere in line!

The next machine to go online will be Bridget’s cute Japanese friend, Taki-chan!

how about no

A New Beginning, Episode III: Revenge of the Charles

I’ve been doing a lot of these posts lately, it seems. Just last year, after departing my shopmaster/instructor position with MIT and hence no longer having a workspace there, I moved in to the Artisan’s Asylum, a local makerspace (which also happens to be the largest makerspace in the USA, founded and run for a while by the now creator of MegaBots). Now, barely over one year later, I’ve moved out again…

T H E   E Q U A L S    Z E R O   D E S I G N S   &   G R E E T I N G S   C O M P A N Y

…into something I can finally call “the shop”. God damn, remember when companies had REAL NAMES that didn’t sound like a syllable uttered while asphyxiating a small animal?

It’s about fuckin’ time. The hankering for workspace had reached a crescendo over the past few months between myself and Adam, my long-time partner in hood rat stuff & bad things, also now captain of Team Brutus. My recent contract projects have been bringing me newer, more interesting, and most importantly BIGGER work, and facing the prospect of having to also work on Overhaul again in a few short months (#season3), Artisans was becoming impossible. On the other hand, Adam has simply been making do without a permanent base camp for a while. Given both our proclivities and the rapidly rising prices in the area, it was another now-or-never scenario.


The building: a former clothing & sportswear factory which the company sold to new owners intent on eventually developing it into MOTHERFUCKIN’ CONDOSDO YOU PEOPLE NOT. HAVE. ENOUGH. CONDOS AROUND HERE OR SOMETHING? I digress. In the mean time, which means the next few years as they figure out exactly how ugly to make the new block o’ flats (that building being my local benchmark for ugly as fuck and overpriced construction) they’ve divided up the former factory floor into a few smaller parcels to function as rentable studios or offices, one of which fell into our lap. You can tell I really love the new property development trend in this area.

It’s on a typical “New England First Floor” – which means floor 1.5, with the basement halfway down. and us halfway up. So, no driving vans in, but direct freight elevator access to a real loading dock 6 feet below. In other words, just enough to be a pain in the ass and just good enough otherwise for me to deal, as the world likes it. The inside is stupendously large for both of us who have been conditioned to think that working butt-to-butt in a shared shop with Isaiah the Last Indie Wirebender is natural and acceptable. Nothing against you wire art, Isaiah, but my robots have tried to consume your workpieces several times while I was machining, and they’re really reaching their rebellious stage lately, so it’s better for both of us.

It’s ~2,300 square feet when finished – shown above is pre-construction of interior walls – putting it right about the size of MITERS. The multi-layered heavy wooden factory floor is finished in a classic “Inconsistently Leaking Machine” fashion sure to fetch thousands of hipster Bitcoins per month in the future when it becomes someone’s hotbox closet floor ,because weed is gonna be legal real soon now in Massachusetts! Oops… I mean #MakeAmericaStonedAgain-chusetts

With the beginning of the new shop space, so shall my Artisan’s Asylum presence come to a close. Luckily, most of my life is containerized. Not only did I count on having to move relatively often, as long as I didn’t own the whole damn block I was working in, but having stuff in nicely labeled containers appeals to my inner Jamie Hyneman greatly.  I bought a dozen more totey-bins (which by the way are called ALCs, or Attached-Lid Containers, but searching TOTEY-BIN returns the correct result on Google Images!) to more finely divide some of my parts since they would otherwise get too heavy.

By the way, it’s been physically verified that Mikuvan can contain 24 of these things – 26 if I use up the front seat.

As with moving out of any space or building or home, taking a look back once you’ve restored it to the condition you found it is a little somber. Alas, great adventures lie ahead! Onwards, through the skies, and across the seas… also over a few curbs, because 26ft box truck. You know what? Driving a truck in Cambridge ain’t so bad! You just BIG your way everywhere you want to go! Want to turn left? FUCK YOU! Want to merge onto Route 28 during rush hour? FUCK YOU TOO!  Uber driver? FUCK YOU SPECIFICALLY IN THIS FASHION!


The robots in their new homes, free to frolick in the open pasture… oh, none of them currently work? That’s too bad.


I picked a convex corner to slowly grow out of. While we have a “space plan” this is the two of us we’re talking about here, so everything is really coming together somewhat organically as needed, so long as it is vaguely understood to resemble some plan, if interpreted selectively. In other words, #yolo.

My former “workbench” at Artisans is made of a 60″ wide wire shelf, and it will become the new 3D printer farm and shipping center for Equals Zero Designs. Not shown here is a collection of Craigslist workbenches that appeared in the space some time later in the week.

As luck would have it, the IDC was getting rid of its original-issue fixed desks and cubicles to make space for more researchers. The large office desks that were a familiar sight in my build reports from 2012 onwards were going to get replaced with smaller, more portable tables. So what’s gonna happen to them?

They end up with me again. The corner I was in was the first to get cleared. While the desks were taken apart and shuffled, there is a very high chance that my former IDC desk is now in our new shop, another somewhat fitting and poetic closing of one of life’s little loops.

A photo taken later in the week of moving when the benches have been arranged and the IDC tables have been erected again. Notice that they’re a little crooked. They did depend on the cubicle divider walls for structure, which were not part of the deal. I might add some additional legs or some bracing to the desk later. However, for seriously heavy-duty work like “I am putting my laptop computer here”, along with EE work, they’re fine as-is. In fact, the widthwise span has already been set up as my EE bench as of the now.

Charlesland fades into Bercustan as you move rightwards above, with the border lying somewhere on a 3D surface defined by the location of the last series of hand tools we borrowed from each other. I’m going to build a wall of lipo batteries soon and make Adam pay for it.

Now, no new workspace that we have anything to do with is complete without….





My children weigh 4,600 pounds combined! Don’t you dare call them fat,  you droplet of coolant curdle!

Getting these two machines – the result of an industrial auction – is a worthy post by itself, and we learned a lot about rigging and moving heavy things that week. There’s quite a few resources on the Internet from people who have documented their own DIY machine moves, so I will gladly contribute to it. Let’s just say it involved….



 Don’t look at me, I wasn’t driving.

So what’s next? I’m basically moved in and have been hacking at things for a few days now. Ongoing facilities improvements will occur – such as moving the machines to their final spots where power will be run to them. I’ve been kept busy by contract work for most of this fall so far, but #season3 is on the horizon and I have some new and exciting content for the Beyond Unboxing series coming up soon, not to mention Brushless Rage development.

Loose Ends and Tag Closing for Bits of October: Site Updates, Chibikart and Mini-Jasontrollers, New Expensive Things!

Now that the season of Dragon*Cons and Maker Faires and everything else has finally settled down, I’ve reached the curious state of having nothing to do with my life, being between large builds in much the same way you’d be between coffees or meth hits. My day to day activities revolve around managing the IDC (excuse the cheesiness) fabrication facilities, of which there will be some updates shortly, and monitoring & mentoring the classes running in the center, including the renowned How to Make a mess out of Almost Anything. I’m not a TA for the class per se, but part of the process of making sure the shop isn’t lit on fire is some times giving extra attention to those who would be most likely to do it.

That isn’t to say that my life is entirely empty and devoid of meaning. I’m tending towards taking the downtime to fix up my eternally problematic go-kart children, starting with Chibikart2. During some hard running at the Powerwheels race, I lost one of the Jasontrollers to Sudden Jasontroller Death Syndrome, a fairly common failure mode for them when they are over-run. The failure is always gate drive destruction since the circuitry is so fragile, and always not worth repairing to myself because it involves replacing so many small shitty transistors. Next up on my list after this is probably to add the electronic solenoid shifting to burnoutChibi and finally get rid of my super-rigged cable linkage. I’ve also been collecting many prospective parts for the “Chibi-Mikuvan” project, so stay tuned for a massive Beyond Unboxing the likes of which have never been seen!

But first, by popular request, I’ve added Pad Thai Doodle Ninja and Colsonbot CAD files to the References page. PTDN’s files are only made of 3D printable frame parts, but Colsonbot is the full bot – you’ll need Autodesk Inventor or a compatible viewer for anything but the STL files. All of the details on these bots are available in their respective build threads.

Onto Chibikart’s controller update. Like the dual controller mount I made for BurnoutChibi, I designed up a two-mini-Jasontroller snap-fit mount which also holds an 80mm fan. Essentially the same idea of BurnoutChibi’s. I was planning to current-hack these controllers to 40A, and for sure they will need supplementary air cooling.


The mount was printed on my Up machine, and this is about the largest object I’ve found it can handle reliably. It came out well, with minimal warping. I sincerely recommend the Up (now on 2 Plus!) to anyone thinking of getting a small hobby-class 3D printer.

Short of popping it in the Dimension, the Up is my go-to for structural parts. The ABS formulation they use is a higher hardness/toughness than the soupy generic stuff you feed to RepRaps and Makerbots. I was concerned about the snap fits being too aggressive and snapping off themselves, but they turned out to be just on the side of the acceptable line.

The mini-Jasons were cleaned up of unnecessary wires, leaving only the motor phases, power, the Hall sensors, throttle, and the ‘regen brake switch’ which may or may not be wired in in the future. The regenerative braking on these things is a fixed low current on-off kind of affair, so it’s not very helpful.

I plucked the 80mm case fan from stock – there’s nothing particularly special about it.

In the past, I’ve current-hacked these things with a blob of solder on the current sense shunt, but it’s such a bad hack and is unreliable – I’ve actually had the blob melt back off before. To remedy this, I began looking for large current shunt resistors packages that fit in between the leads of the existing shunt. This is the result – for a mini-Jason, a “2818” (.28″ long, or so) package current sense resistor is a nice fit. One that is 8mm (“31xx” – “35xx”) will fit even better and not require much solder bridging would fit better, but I could not find any that were not also square in shape – rectangular, the long way, is preferred.

I actually had this hack vicariously tested by Daniel (YAMEB) a while back. These shunts are 5 milliohms (not 10 – I measured erroneously the first time), so it took a nice sandwich of 10 milliohm resistors to get my 40 amps. The exact part number I used was WSHA-.01CT-ND, and it has a 5 milliohm brother in the form of WSHA-.005CT-ND.

I cleaned up the floorpan of Chibikart after removing the old Jasontroller – it was positively disgusting and filled with 2 years of floor grunge buildup, plus mud and dirt from running at two slightly wet Maker Faires. The new installation drops right into where the old controllers used to sit, after redrilling some mounting holes.

Systems wired back up. The first test drive was without the fan hookup, and without the sensors connected.

To rehash, these controllers “self-calibrate” sensors if you connect them and then run once to full speed. I couldn’t achieve this on the ground since the vehicle never really reaches “full speed” in the space available, so I had to freewheel it, being mindful of the 4700rpm-ish commutation limit. After one power cycle, the controllers had learned the sensor configuration and Chibikart could apply “static pressure” to something again. To get a good transition between sensored and sensorless, the sensors have to be aligned properly first (check out Equals Zero Designs’ page where I have an actually well documented example.) – and that’s all you need to do, not actually try and optimize their timing position.

This was, of course, the important part.

Now, the 12v PC fan could not handle 24 volts, so I just dropped a giant 40 ohm resistor in line so the fan only saw about 15v. This resistor surely dissipates more power than the fan actually removes…

With two motors on 40 amps, instead of on ~25 before, Chibikart2 is way more fun. Not, say, tinykart Black Edition level fun, but it is far more peppy. The small Colson wheels are starting to reach their traction limit.

I hit 1.1kW on indoors testing, and there is much room for improvement yet. Because the controllers are doubtlessly still running constant current before I run out of hallway, the power will only increase with vehicle speed.

Say, I haven’t garaged something properly in a long time (mostly because said garage was under repair construction this past summer). Maybe it’s time to take Chibikart back to its proving grounds.

Next, some of the ongoing facilities improvement projects that I have going on in the space! The place is kind of like I-95 around New England – always looking like someone’s working on it and the construction shifts every once in a while. I swear, though, it’ll be over soon – just like they say in Connecticut (In my six years in this area, I have never once driven through 95 in CT without hitting some kind of construction…)

First up, a full size Shopbot – the full 5 x 10, gifted by the Architecture department. I’ve been itching to have one of these for a while – with an 1/8″ carbide bit, they’re practically mechanical waterjets! Expect some Shopbottables to emerge on my end soon due to the “It’s the closest tool next to me and I don’t have to ask anyone to use it” effect. It will be very handy for producing Chibi-Mikuvan’s body panels since they’re all larger than what can be stuffed into the laser cutter.

Above, Media Lab students operate the machine as part of the MAS.863 “Build something big” week.

Next up, the legendary Form 1. Full disclosure: There’s four Form 1en in the space at the moment – this one is “The Lab’s”, and the rest belong to researchers and classes residing in it. Four. That’s more forms than Formlabs (okay, probably not), but the Form 1 density must be up there.

The Form is a SLA-like machine which can hit much higher resolutions, but the  material isn’t too strong – it’s an acrylic resin, so it has some mechanical strength, but does shatter and snap. Dat rez tho…

These are some of Brian Chan‘s insects. Check him out on Shapeways! I also printed the crab, lobster, and some other doodads from his collection.

Of course, with every 3D printer that makes it in here…

The  model is “Pillared Miku” though I used the version without built-in pillars – the Form software generates its own support lattice.

Now, moving up in the Expensivity scale is our latest acquisition:


An Objet24 (By Stratasys™)! This is just contributing to the slow rounding out of 3D printer technologies in the space. Objets are incredibly high resolution, very nice, and very expensive. This unit was purchased used from a local company for only $7,000, but you’d easily eat up that much per year in materials alone. The Objet Goo comes in 700 gram jugs that each cost $300-350 and up.

And this is the entry level machine.

The Objet technology combines SLA (light cured resin) with inkjet style nozzles so it can control the deposition very finely. No giant bubbling cauldron of goo here. It also has its own Windows XP computer built into it.

Now, I know XP is pretty much the OS that saw the Internet grow up with it, but this machine was built in 2011….

…and even worse, it requires a very specific network setup to talk to. Objet-Stratasys (ObSys? Stratajet?), I’m going to publicly shit on how bad the Objet communication infrastructure and software are. I should not have to configure a point-to-point LAN, disable Windows Updates, and disable firewalls just for it. The whole setup procedure gives me the vibe that they had to ship the machine and had 1 day left to write the drivers, so took whatever the developer’s computer was at the time and just made that the exact requirement. That, or given Objet is an Israeli company, probably just opens your computer up to direct monitoring by the Mossad.

I’m amazed I didn’t have to start Space Pinball and log into Pandora before the printer would communicate.

The slicing software is also slow, prone to crashing, and has an inconsistent UI. For such a beautiful piece of hardware, the software end of it seems so incredibly rigged.

Of course, the first thing to do with every 3D printer that makes it in here…..

Yeah. This was like a $30 Miku given how much of the material I used.

This corner of the room has been reconfigured to become what we now affectionately call “printrgartn”. The Form 1 is immediately off to the right, as is the Replicator 1. I’m trying to commission an Up for the lab (in supplement to my personal machine).

What’s absent, sadly, is a powder printer. I need to do some Powder Print Affirmative Action here.

2.00Gokart Student Blogs

The 2.007 class is structured with 12 weekly “milestones” which students must use their class lab notebooks for and write down their progress, thoughts, calculations, sketches, etc. Some students are detailed or previously experienced in using notebooks / journals (such as from an internship at a company which requires it for engineers), others write down pretty much exactly what the milestone requires and that’s it.

I was definitely part of the latter crowd. It was difficult for a professor to actually squeeze out of me a competent lab notebook of any sort.

To encourage more diversity and accessibility in design documentation, this semester I encouraged people to write about their builds on their personal websites or blogs. Now, the Department™ still requires the paper notebook as part of the grade. But, for the last milestone, a reflection and summary type writeup, I decided to break from that and give the students some flexibility. You now had the option of submitting the final MS as a site entry or blog post.

Here’s who took me up on the offer, and those who’ve had a running log of everything they’ve been doing too!






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.