Archive for January, 2013


The State of the Überclocker Address

Jan 27, 2013 in Bots, Überclocker ADVANCE

It’s the end of January. Where’s my damned robot!?

After about a month of dormancy and on-and-off work, it’s time to get serious… lest I pigeonhole myself, again, in the position of working on the damn thing a day before setting out for Motorama 2013. I’m generally confident that Clocker was designed with the best and latest of my design-for-assembly methods in mind, and the progress (mostly in the past week or so for actual work) should demonstrate that here.

RageBridge and DeWut?

No matter how much I get done, though, the availability of the RageBridge assembled boards and the DeWut?!s will be critical in the robot’s completion. As of even right now, I don’t have a concrete bail plan for the DeWuts in particular if the parts do not arrive in time. Fortunately, I received notification that RB shipped this past Friday, and the DeWut order has been completed and may go out on Monday. Here’s hoping the magic of modern express logistics gets them in my hand by the end of this week. Both will probably need a little legwork on my end before I can offer them up to you all, but that’s all part of the battle plan. On a related note, the Hall sensor boards and mounts are ready for your experimentation!

We begin the build of Überclocker with my favorite production machine, the abrasive waterjet.

These parts were made from one of three plates of 7075 aluminum I caught a great deal for on eBay. 7075 may actually be my most favorite material because it’s one of the strongest aluminum alloys, yet you really can’t tell by machining the stuff. I probably could have made some of the material areas smaller to take advantage of the 50% increased yield strength of 7075 over 6061, but elected to not make design changes at the last minutes to save an ounce or two.

The plates were all machined without incident, save for two of them, where the insides are shifted relative to the border. This is a classic failure mode of constant-height waterjet cutters before motorized Z-axes were fashionable – if any part of the previous cut interferes with the head, the machine generally bumps the part into a new coordinate system.

While the damage was minor enough on one of them (the top X part) that I could have milled out the slots, it would have weakened the joint significantly due to the loss of material-on-material interference in the joint. The other one pretty much needed replacement, since the error occurred (seemingly) right before the final profile runaround.  I elected to redo both parts at the earliest opportunity.

Also lined up for the first batch was the main lift gear. It’s the same pitch as Überclocker’s previous lifter gear, at 12DP, but the reduction ratio is higher (5:1) instead of about 3:1. This is to make up for the loss of the 216:1 integrated dual frankenboxen for speed reduction purposes. While the difference between a DeWalt gearbox in low gear (52:1) and another 5:1 is still outmatched by the reduction ratio of the IDFB, I think it’s less likely to destroy itself. The DeWalt motors are innately more powerful and torque-balanced than the 550 motors, so perhaps a 260:1 reduction is enough. In fact, it’s more than enough, but the maximum top speed of the lift would be an unnecessary ~15 in/s at the periphery. I’ll deal with the increased current draw, though, because hopefully RageBridge’s low speed exponential response and dynamic braking will make up for it. Maybe it’s time for a closed loop speed feedback…

The small gear is a steel pinion I purchased from McMaster whose hub will be removed and bore broached for a 1/8″ keyway.

Round two of parts. The top and bottom plates are made of my most recent favorite top and bottom material, 1/8″ G10/FR4 garolite in black. There’s some of the usual delamination from high pressure piercing. In the past, I’ve taken care of this by injecting copious amounts of CA glue into the bubble and then slamming it in a vise. A perhaps imperfect repair, but it at least brings some of the strength back in the bubble area.

The tensioner and drive sprockets were also cut at this time. These used the profile shifted sprockets I designed for Chibikart to account for waterjet taper. The tensioners are basically sprocket rings glued to a ball bearing as shown in the topmost example.

A little bit of stuffing with Loctite 609 retaining compound later, and I had the tensioner sprockets. The bore was designed such that they were a near perfect tapered press-fit as cut on one of the MIT waterjets I frequent the most. Different machines would necessitate familiarization before I am able to do such a thing.

Continuing the steps of small, easily pressables, I installed the fork shaft bushings and the outboard support bearing for the lifter motor. The bushings needed finish-reaming after installation since this bore wasn’t that perfect – luckily, I was able to borrow a 1″ adjustable reamer from one of the campus shops. A ring of 609 ensures their retention. After the finish-reaming, I decided to increase the diameter a little further to allow for some alignment slop when it came time to assemble the frame, since otherwise bushings will lock up with any small amount of misalignment.

Round 3 of cutting sees the front “reactive outrigger” parts finished and the replacement frame rails also finished. Now I can really get onto assembling the robot’s structure.

The legs, now that I actually hold them in my hand, are massive. If the bot ends up a little overweight, these are the first parts getting selectively lightened!

The order of assembly of Clocker this time mandates the fork mounting structure be assembled first. This then slides, with the frame’s back member, into the sides. In previous Clocker iterations, this would of course have guaranteed the need to disassemble the entire bot before any work can be done on it, but I hope I correctly allotted space this time around to swap motors and repair drive components without needing to do so.

A first look at the assembled frame of the bot. These pieces are just shoved together for now – there are more parts to make and assemble before I can install all of the t-nuts.

Another item of minor fabrication is attaching the clamp hub shaft collars to the components they will be driving. The two fork tine collars will be tightened securely, while the one on the gear will function as the slip clutch for the system.  #10-32 screws were used for this effort since they fit flush into the counterbored holes in the shaft collar, and plenty of high-strength Loctite 262 were dumped into the threads to make sure I can never, ever take these things apart again. Ideally, I would never need to…

With most of the minor assembly complete, I turned my attention to solving an issue that had been on my mind since the first time Clocker was in a tournament. The clamp actuator has always been really slow, in part because I’ve been using highly geared motors on the Acme thread. Many matches in Clocker’s history have had missed grabs because the clamp just didn’t come down fast enough. Other clampbots in the past have used pnuematics and R/C servos for the clamp arm, so they’re quicker (but each has its own downsides).

One way to solve the problem would have been with a fast-travel leadscrew such as the one I used on Make-a-Bot with 8 threads per inch and 2 starts (so basically a 4 thread per inch). that would net me a 2.5x speed increase. Problem is, that would also entail remaking the Acme threaded sprocket – and I didn’t have either nut or sprocket one on hand. I decided that the force loss was acceptable enough to just take out one stage of the Harbor Freight drill innards which made up the gearbox for the clamp motor. This was a 36:1 gearbox, so taking one stage out is a 6:1 increase in speed.  Because Clocker’s clamp is hypothetically not backdrivable (unless something truly terrible has happened), I don’t actually need that much clamping force to hang onto someone, especially with the big squishy rubber bumper on there.

So, onto the lathe the ring gear goes, and one pass with a parting tool was enough.

The actuator, reclosed with 1″ long #6 screws. I forgot about the fact that my little tension roller standoffs existed, though, and had to go back and trim down two of the 1.5″ long screws that were in this duty so they would fit those.

With that matter taken care of, I embarked on Epic Standoff Evening where I popped out many little round threaded things from tinylathe. With the exception of the tubular spacers (for the fork) at the top, These parts are actually all 7075 too – due to the magic of eBay, once again, I caught a great deal on 3/8″ and 1/2″ rods of 7075. Because some of these parts, namely the axle standoffs, were modeled as steel, I ought to be creeping slowly further down from the initial weight estimate, which is good.

Threading the ends of the standoffs led me to come up with quite possibly the worst tapping fixture known to mankind. No taps were harmed (I think…) in the production of this image. I only used the other drill to hold the piece steady – it was not counter-rotated. Really the way this came about was trying to figure out how to hold the round piece still to thread it without damaging the precision-ground surface, like what would happen if I threw it in a vise like I usually do.

One of the other simple operations was to trim off the hub from the spur gear. At this point, my 1/8″ keyway broach had not yet arrived, so I couldn’t broach the thing, but at the very least it can be prepared.

We conclude this address with pretend-o-bot #1. Still to go in this picture are making the drive wheels, machining the fork’s main axle from the giant aluminum shaft, machining the front leg parts, and finish machining the top and bottom plates. I’ve hopefully ordered the last round of random hardware needed to get the build done. Past that, it’s just waiting for the hired out parts, and possibly formulating a ditch plan…

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

Jan 24, 2013 in MIT & Boston, Shop Ninja

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.


SensorChibi: Adding Hall Sensors to Chibikart with Hall Sensor Boards

Jan 13, 2013 in D.P.R. Chibikart, Project Build Reports

They’ve made some appearances here and there on my website and others already, but if you haven’t seen them yet, now is the time that I’ll make them public. For a while, I’ve been sproadically making Hall Effect sensor “adapter boards” that can be mounted to R/C outrunners for sensored commutation uses, needed for most ground / vehicular applications. It’s about to get way less sporadic:

Yep, that’s a big cake of them to the left. I’ve also added sizes to the collection. Now, 80mm (“melon”) motors and 50mm outrunners are supported, also. I’m still a bit peeved that Hobbyking had to make their new SK3 “63″ motors actually 59mm in diameter, necessitating a fourth board design. These boards were sent to my usual slow-and-easy PCB house, MyroPCB, and done up in black.

Why 50mm? My general belief is that 50mm outrunners are about the smallest you can really use for a vehicle before they start getting too fast (Kv rating too high) to easily gear down. I foresee the 50mm motors being useful  more in scooters than anything else, where a low profile helps compared to the chubbier 63mm motors, unless your scooter is the size of a small bus.

But the other reason is that the Democratic People’s Republic of Chibikart (Hereafter known as just “chibikart” because why did I pick such a name?) uses them, and on a go-kart where pushing off with your leg is just ruining the point, sensors are pretty critical. I’ve been at a loss to explain how to add sensors to the motors because there is so much customization involved, so Chibikart was published without sensors, but with the sensor boards and attendant plastic ring things and automagically calibrating controllers, I think I’m getting pretty close to an “official solution”.

I’m confident enough in these little widgets to pitch them up on my eventual web store, Big Chuck’s Robot Emporium (d.b.a Check out these pretty product pictures:

This stuff is getting too legit. I should still make you place orders in the comment thread.

Anyways, here’s what a 50mm SK3 rig looks like installed on Chibikart:

The rings are held in place by pressure from the motor mounting surface – it has to be flat bulkhead mounted, or mounted using the X-shaped plate that comes with these motors generally, to work. So, a setup like Straight RazEr which directly uses standoffs on the motor would not work with this design.

I used a chunk of ribbon cable that conveniently had blue, yellow, and green wires next to each other to make the connection to the board. Because everyone’s going to have different wiring arrangements, I’ll leave it as an exercise to the user to make their own cable harness.

Chibikart has actually been experiencing some technical difficulties recently, and I took this installation as a chance to tear the whole electrical system down and check everything. The symptom was severe battery voltage drop (seen on the motor controller side, after the switch and fuse), usually leading to the controllers dropping out during acceleration. Some times, it just wouldn’t even accelerate. I noticed this getting worse and worse recently.

I started the teardown by injecting a wattmeter between every load point – at the battery (checked out great), behind the fuse (terrible), and in front of the fuse but behind the main switch (also terrible). So the problem was clearly related to the big key switch. When I took apart the joint, the switch was fine, but the wire had corroded in its somewhat poorly crimped terminal!

With the problem found, I restripped and securely soldered that joint. I don’t really trust regular crimp type terminals, and this episode just reinforced my disdain, but they are popular enough that I can’t just get away from them.

Especially not on the batteries. I noticed one of the K2 bricks had a terminal which was clearly darkened from heat. But only one, and not even the one I cracked open. The heating signs may have indicated a bad connection, but I could find no corresponding contact blemishes on any of my connectors. It may have been there for a long time, like since before I adopted them.

Out of some caution, I replaced the K2 bricks with matching A123 bricks (which, despite A123′s slightly indeterminate state at the moment, will be restocked again, I’m told. Also, the lead image of the linked article is Chibikart 1′s battery. I am an amused hamster.)


Well, there was a problem. I’d given the Jasontrollers a ‘haircut’ to minimize the wiring mess, but that also entailed cutting off the Hall sensor inputs on them. Oops!

I was able to pull them out just far enough to solder to the wires, so I spliced on a new connector:

Protip: A 4S (4 cell) Lithium battery balance connector is basically a keyed 5 pin connector with wire pigtails attached.  It’s much easier to splice wires than to try and crimp and install these tiny connectors, or solder pin headers, in my opinion, so they might be the Recommended Solution for these sensor boards as a product. It took under 10 minutes to splice both sides, ribbon cable and Jasontroller stubs.

The final setup. Chibikart now has a little fluffy bunny tail made of unused Jasontroller wiring connectors, but in case I ever find that they are useful for something else, I won’t cut them off for now.

The process of tuning the controllers was extremely easy:

  1. Line up one of the sensors with the dead center of a stator winding slot – this guarantees that the 120 electrical degree spacing square waves generated by the Halls have at least one edge that is the zero-radial-flux region  between 2 magnets.
  2. Run the Magical Autotune routine of the Jasontrollers for each side. I decided to do it explicitly using the “self train” wire, but it was clear to me that one side had already picked it up when I was done “training” the other.

I’ll have to write this up officially for the product pages, but if the controller did not have Magical Autotune, the process is much more involved and painful, and for a known working set of 3 sensors it might go:

  1. Line up one sensor with the dead center of a stator winding slot
  2. Fix the Hall Sensor cable combination (for instance, Hall sensor signals [A,B,C] get connected to controller inputs, [A,B,C] for the resulting connection [AA,BB,CC]).
  3. Label the controller phase wires (e.g. [u,v,w]) and the motor phase wires (e.g. [x,y,z])
  4. Start with connecting the motor and controller phases in any combination (e.g. [ux,vy,wz]) and see if the motor turns. If it does not continously rotate (e.g. just wobbles, or moves a small amount and locks up), swap two wires. For instance, the example hookup might become [uy,vx,wz].
  5. If the motor still does not turn, swap the two wires you didn’t swap before.  For instance, the example hookup might become [uy,vz,wx] after this point.
  6. Repeat step 5, continuing to swap the 2 wires you didn’t swap before. There are 6 total ways to arrange 3 unique things with 3 other unique things (3 nPr 3). The example connections list might be
    1. [ux,wy,vz]
    2. [uy,wx,vz]
    3. [uy,wz,vx]
    4. [ux,wz,vy]
    5. [uz,wx,vy]
    6. [uz,wy,vx]
  7. If none of the 6 combinations result in motor rotation, then you have to pick 2 Hall sensor wires to swap. For example. [AB,BA,CC]. Repeat step 5 through 6.
  8. If the motor spins with a combination, but in the wrong directions, then cyclically shift the entire connection. For example, [ux,vy,wz] becomes [uz,vx,wy].
  9. If the motor does not turn any more, cyclically shift one more time. At least one of the shifts will be rotation in the reverse direction. One more cyclic shift and you would arrive back at the first again.
  10. Once rotation has been established, you must time the sensors correctly. This involves an AC or DC ammeter, and the goal is to move the sensor board along its slotted mounts in very small amounts while monitoring the current draw at a reasonable motor speed. Move the sensor board to the point where the current draw is the lowest, for that speed.

In other words, Hall sensors actually suck. Incredibly so – which is why I am so glad the Jasontrollers get the hell out of sensored mode as soon as they can! The timing you establish using that procedure is only the minimum for that speed. For instance, if you time the sensors while the motor is spinning very slowly, then the timing will be too retarded for high speed operation, resulting in high current draw. If you time the sensors at wide open throttle, the timing will be too advanced for low speed running and the motor could have trouble starting since the phases will “fire” too early.

Maybe I’m opening a huge can of magnet wire shaped worms by introducing these things, but hey.

test video

Check out this sweet video of Chibikart totally not needing a punt to start from standstill, even on carpet, while turning! Still no reverse, though.

These sensor rigs will be available on as soon as I hammer out the shopping cart and payment details. If you’re really aching, feel free to email me, though!


The Curious Design Space Intersection Between Engineering and Cute Anime Girls

Jan 11, 2013 in Stuff

As a brief aside from my ongoing efforts to transform my new “storefront” website, which apparently 1700 of you have already seen in a state of abject disorganization with phrases like “polka dotted bacon strips” interspersed between stock grainy photos of robot parts, I’d like to draw your attention to a particularly niche interest of mine which I hope to draw more into the spotlight through 2013 as one of my ill-thought-out New Years resolutions (one of which was making that website, and 90% of which have already been shamelessly abandoned).

First of all, a design space is a somewhat wishy-washy word for the set of all independent variables, and hence all theoretically possible variations, of a certain design. We can say for example that the design space of all wheels encompasses variables like diameter, tread pattern, tread material, core material, bearing type, bore size, width, and potentially many more. A design space for Uberclocker’s fork might be all the possible lengths of forks, angles of departure from the ground,  and placement of the center axle that meet the goal of not making the robot lurch forward upon lifting an opponent, which we would have to define specifically as a test case. Design spaces are usually associated with goals or cost functions, and design space analysis is aimed at meeting the desired criterion of the design through systematic breakdown of requirements and approaches.

What the hell does that have to do with anything? Nothing. I’m just saying that the design space intersection between engineering projects and anime girls is too small. The total space of all that can be designed and built, and the total space of all that is representable as adorabu and Japanese, needs to be expanded.

Which is why I would like to present the work of Cynthia Lu now, as a testament to her powerful integrative design approach towards expanding the space of solutions for making engineering kawaii. Cynthia is the mastermind behind Arduino-chan:

What. I know, right?! She also has a tumblr which contains other gems like Team XBee. I foresee much fanfiction potential between Arduino-chan and her XBee friends, seeing as how often real XBee modules are used in conjunction with Arduinos. She’s also working on her visual art and graphics design career in other ways.

(For more information on the extremely Japanese practice of moe-anthropomorphism, see this TVTropes article, because I’ve abandoned Wikipedia completely for such things, though their article is also quite comprehensive.)

Anyways, I have nothing else particular to say on the matter. Stay tuned for an update on Chibikart running with Hall sensors, as well as an Überclocker update!

RageBridge is Out for Production!

Jan 05, 2013 in Stuff

Where in the world is RageBridge? Well, right now, it’s in the hands of the Shenzhenistani, as I have committed 100 boards to be fabbed and assembled as of Wednesday night.

That’s right. I’m all in. Come late January and going into February, I and my cohorts and enlisted minions hope to be able to begin filling orders. A new website is being set up and populated, and soon it will even have meaningful content to link to! Right now, it’s kind of a hollow shell and embarrassing to look at.

Here’s what went down after the publication of the Market Survey, which you should STILL take if you haven’t!.

(By the way, if you haven’t gorged yourself on How to Build your Everything Really Really Fast… well, it’s right there.)

While the survey was filling out, I was in fact busy designing yet another board revision. I promised no more, but in fact I wanted to add a few last finishing details. The adventures of the previous update with the boost converter told me that I had to better isolate the processor and current sensors (consumers of 5V logic power) from the current-laundering schemes of the 15V boost converter. One suboptimality was the placement of the 5V bus capacitor:

The red circle is the ceramic 5V logic regulator output capacitor, basically the big 10-gallon bucket of electrons that smooths out the wavy voltages coming from the inductor (L1). The issue is that it is on the other side of the inductor as the rest of the 5V circuit, indicated by the green highlight. Imagining that every trace was a resistor (which it is of course), the voltage-smoothing effects of the capacitor are very limited on the side which needs smooth power the most!

Oops. Chalk it up to Energetic Board Design. While this resulted in no problems in testing, I still wanted to change it. The ICs all have their local bypass capacitors, but they are very small (0.1uF). So, any disturbances injected onto the 5V rail will cause worse voltage fluctuations than if there were a large capacitor sitting on it. Think dropping a rock into a bowl of water vs. the proverbial 10 gallon bucket.

The fix was to … add another capacitor on the other side. Pretty simple.

It involved a little component-moving, but now there is another ceramic capacitor of equal size on the other side of the inductor. I also necked down the trace width severely going from said inductor to the 5V logic side compared to the path to the gate drive boost converter to function as a sort of resistive bottleneck – the power consumption of +5V logic is going to be pretty steady, but the boost converter will pull power in pulses. It’s another attempt to shield the more sensitive logic from the rough and tumble of the power side.

But that’s the little change.

The big change is the clearing of space for, and subsequent installation of, a small potentiometer to ADJUST YOUR CURRENT LIMIT!

Directly inspired by the market survey, I realized that a staggering amount of people wanted control of what the limit was. A larger percentage simply wanted adjustability, but a significant number also wanted the ability to completely disable it.

Well, I obliged, and agree that it’s a good idea. After all, 1 current limit does not fit all motors, and I fully believe in the freedom to explode your electronics if you choose to do so; because it’s another sale for me, right?

A 4mm miniature trimpot connected to my LAST ANALOG INPUT will function as an adjustable current limit input. Then, in the latest code, the pot is read a few dozen times (to make sure it’s not crazy) once at power-on to establish the limit. So, it’s not something you adjust live, but can be changed on power-cycle. After a certain threshold, the current limit is removed entirely and hence physically limited only by the motor and system resistance, plus or minus grenading the transistors.

I tested the proof of concept on the black board by … gluing a potentiometer onto it.

Pretty much. After getting this to work, I committed it to the board design with some more component moving and rerouting of traces to clear a path to the last ADC pin.

Here’s a picture of the version 5 boards, also the release candidate.

Because at this point it was basically the 2nd week of December, I elected to pass over MyroPCB, my usual board house, in the interest of just getting a board or two from Advanced Circuits (my other preferred place). It would take much less time, which was of the essence – I wanted to make sure it wasn’t delayed by the Christmas holidays. So, sadly, these board versions are green. Rest assured, however, that the boards being produced are completely murdered out. Black board, black chips, and black FETs. I ought to have the thing black conformal coated for that effect. Too bad, though, that the capacitors are brown with white striping. Hey Panasonic, throw me some black-on-black caps!

Under the left board is a production sample heatsink plate. I sourced these using my e-tentacles on, and they come with a silicone insulator pad bonded to it. So, assembly of the boards will be just plopping the thing onto the heat sink. I’m going to build another version of my Nifty Bullet-Connector-Based Test Jig to power and function test the boards when they arrive. Inevitably there will be some duds, so I’d rather spend a few hours with comrades and pizza sniffing them out.

I’m sufficiently amused by the whole process of setting up a board for production through Myro that I kind of want to write all up, step by step, as a case study. It’s definitely not trivial and there was much legwork to me done on my end, like setting up the bill of materials (BOM) with specific details that I would otherwise have hand-waved or ignored. Myro’s quoting and purchasing process is also a little… mysterious. Getting boards done through them before was invaluable experience for stepping up to assembly.

With all that said, here’s the current battle plan:

The boards will be ready to ship, if all goes right, by the 1st week of February. I intend on bringing a pile to Motorama Robot Conflict 2013 – if you’re going, feel free to swipe one off me there.

Orders will be taken through my brand new website Quit laughing – I know there’s nothing worth reading there yet. January will be spent making a better manual, collecting test data for current and temperature, and refining the firmware.

The trim levels and pricing are the following:

  1. $180 gets you the board, with heat sink plate, but without wire pigtails. A header pin group will be provided but not installed for people who want to, for instance, solder signal cable pigtails.
  2. $200 gets you the board with headers and 6″ long power and motor wire pigtails soldered, ready to connect using servo cables to your signal source. No connectors are included.

The tech support policy is send your questions to a future form service that will be on the website.

And finally, the return policy is flat fee, no questions asked for exchanges stemming from failures and burnouts, except for dead-on-arrival which will be the buyer’s responsibility to ship back for exchange or refund within n days, where n is a number to be determined. The fee is not yet settled. Think Castle Creations’ policy regarding these kinds of things.

Finally, in a commitment to make the controller world a better or at least more varied and colorful place (…says the creator of the black board), the source code and design files will be made available on when shipments begin. Who wants to try and race me to the first quadruple-FET-per-leg Ragebridge?

Keep in mind these terms are not final and are still being discussed and vetted!

But that’s not all.

Whatever happened to the DeWuts?

Remember the cheesy 3D printed DeWalt motor holder? I handed the design off to my preferred Sketchy Chinese CNC Co. Ltd. in mid-December to be duplicated in steel and aluminum. I’m actually more excited about this than the RageBridges for some reason, probably because I still like mechanical things and Überclocker 3 is counting on these hardcore.

Anyways, these ought to be coming home to roost in mid January (soon! Oh, how soon…).  I intend on pushing these out to the new web shop too, for shipment also at the beginning of Feb.

The anticipated price for these is $100 for the full kit, bring-your-own motor. The full kit constitutes the three 6061 aluminum billet components of the mount, the 1566 steel integrated output shaft with retaining ring, the Delrin gearshift locking lever with securing hardware, and motor mounting screws. With the average cost of aftermarket DeWalt drill motors and gearboxes being about $70-80, figure on having a DeWalt 12-18v drive setup ready to roll for a bit under $200. I’m not planning on full-assembled kits yet, but after more thinking and discussion this could change, too.

Overall, this has been a very exciting start to the 2013 year, and a great if somewhat belated start to the Third Five-Year Plan (A post on the progress made under the Second Five-Year Plan will be forthcoming).