Archive for the 'Project Build Reports' Category


The First Testing Results of RageBridge(Two!)

Oct 25, 2012 in Motor Controllers, Project Build Reports

Barely a week after I first put out the call for RageBridge testers, I’m stoked to say that I’ve gotten the first usage reports back! Two of my boards were in use at the Combots Cup this past weekend, one in a 60lb bot and one in a 120lb class bot. Here’s what went down:

AWESOME! The board worked flawlessly until it caught on fire.

That’s actually what I want to see, because this establishes a good upper bound on what the board should be used for, as well as how it should be mounted.

The two robots used similarly powered motors in their drivetrains, but one was very weapon-centric and the other (which suffered the explosion) very pushing and drivetrain-centric. I’m told by attendees that after 2 minutes of a hard pushing match, the RageBridge board gave out. The other board seemed to have survived fine, given that in its application it was most likely not hitting the current limit as often due to the robot’s primary goal of chasing after an opponent with its whacky bar thing.

The thermal situation in the pushybot was also a little suboptimal:

Above is the robot, Ziege, a 120lb middleweight powered by 4 EV Warrior motors (admittedly a little power-starved on 60A). The black blob of tape between the two rear motors? Ragebridge. Talk about good ventilation! Basically what I’ve concluded right now, after only 1 data point, is that perhaps without additional cooling/heat sinking, it’s not a good idea to use RB in a 120lb battlebot. This is more informative than the statement’s facetiousness may indicate.

First, all ESC ratings lie to you.

Second, it’s been known to me that RB’s “40A” rating was a little optimistic. It was calculated assuming a constant current causing a certain amount of Joule loss (I²R) in the FET, and using the datasheet’s quoted temperature rise per watt of dissipation (Kelvins/Watt) to estimate a temperature rise from 25C ambient. Basically, for the FETS I used (the IRFS3004), this worked out to be around 76C for a final temperature of 100C. I picked that as the target temperature because most big electrolytic capacitors are rated to 105C. However, that does not include any additional sources of heat. In fact, the capacitor itself is a nice source of watts that is located very close to the FETs, hence contributing to their heating. The board traces, being relatively thin copper, will also contribute some resistive heating.

Interested in just how many “true continuous” amps Ragebridge could push with no help (e.g. fans, heat sinks), I set up a test rig over the weekend which was basically the board puking into a huge RL load while suspended in midair:

The “Big RL Load” in question is Cap Kart’s motor, a separately excited giant-ass DC motor. To get the duty cycle of the controller’s outputs to a reasonable range, a very small amount of field current was injected such that the rotor could barely overcome friction and spin up to a tame speed,  hence generating enough back-EMF to force the controller to work at around 50% duty cycle for the current I wanted to test. To maintain that current, I just set the Semi-Intelligent Current Limiter to the value desired.

The reason this was done was because different duty cycles load different controller parts preferentially. If I had just dumped into the big rotor windings at stall (which I tried), the controller would be running at like 5% duty cycle the whole time. That would have been all the voltage needed to hold 30 amps into the ~30 milliohm rotor winding (at the 20 volt test voltage). Very high and very low duty cycles preferentially stress one FET because it is either supplying all the current or having to freewheel all the current and is kind of unrealistic unless you know for a fact that people are gonna be running such low or high duty cycles all the time.

50% duty cycle is a nice worst-case scenario. While heating would be distributed evenly across both FETs of the conducting H-bridge half, 50% duty cycle really kills the capacitor (Here’s a good application note kind of thing with good buck converter design equations).

Every once in a while, temperature readings were taken of the region between the high-side FETs and the capacitor. This would be the single hottest part of the board, and hot it did get.

I became concerned about how fast the cap was approaching 100+ celsius after the first test. To mitigate this, I temporarily doubled the capacitance. Kind of cheating, I know, but I was also interested in seeing what the FETs were capable of. The first test was on just 20 amps, and the FETs had barely crested 50 Celsius when I called it off. They have quite a long way to go, but the capacitor was probably about to detonate.

Finally, after the extra 680uF of capacitor was added, the test was repeated at 30 amps:


The “data” was recorded with a video camera and the data points gathered by watching the video and picking the temperatures that looked like of good. So, not exactly rigorous science, but it gets the point across. With no additional heat sinking, fans, airflow, or other cooling assist, the RB board sort of levels off at around 100-105 celsius after about 5 minutes.

Thermal equilibrium is really what determines what a controller’s “continuous” rating is. RageBridge is a “30 amp” controller at heart.

The only way to raise this current ceiling is by active cooling of the board. There is very little amount of practical heatsinking that can be done to raise the steady-state current. A well-designed and many-finned heat sink is more effective on its own because the increased surface area encourages more natural convection anyway, but a plain heat plate wouldn’t increase the surface area much. Hence, it would only prolong the time until the temperature limit is reached.

The world of ESC ratings is a perilous one. If I really sold Ragebridge right now as a “30 amp” controller, nobody would buy it. The reason is that the majority of robotics and traction duties aren’t truly continuous. A typical robot will accelerate in under a second, drawing full current, then cruise at a much lower current. Vehicles may hold that acceleration current for longer periods of time by virtue of being heavier and not being geared to safely spin the whels at a  low motor current. Unless you’re trying to drive motors that are way larger and more power-hungry  than needed for the application, the average current will be far lower than the peaks.

This is why “one number” ratings, like “40A continuous”, are useless without considering the circumstances of the test. Some ways to get around this rating are citing a number as “continuous” for some number of minutes. A typical “robot duty” might be 3 or 5 minutes. In this case, I think RB2 is a good 40A “3 minute” controller.  A truly 40A continuous ESC needs to have enough thermal dissipation ability to safely dump several watts of heat in the best case. It’s probably going to have a rather large heat sink or at least a fan, or be very ridiculously low resistance , which some R/C type ESCs acheieve by being very low voltage and using many small FETs in parallel to reduce resistance even further. For R/C controllers in particular, some amount of airflow is implied, usually prop wash from a plane.

Peak ratings can be even more bogus. It’s generally not disclosed how the test was performed – for the typical R/C ESC, it’s usually “Rated battery voltage” / “Rds-on of the FETs divided by number of FETs”, resulting in hilarious ratings of 1000+ amps from a ESC with 14 gauge wires. Without a method of test – like “100 amps for 10 seconds before reaching 150 degrees Celsius” it’s impossible to really tell what the “peak rating” is. However, for RB2, it’s dead simple – it’s whatever I set the hysteresis limit to!

With this test rig pretty well practiced and easy to set up, I might go ahead and try some other well-known robot ESCs to determine what their real ratings are.

For RB, though, I intend to generate several of these graphs and make them public & part of the eventual user manual. Maybe 2 different currents under 4 different cooling conditions (no cooling, with a heat sink plate, with a fan but no heat sink, with both). It would look much like the average IC or semiconductor datasheet, and it would be kind of easy to extrapolate what a safe amperage is for the custom application based on those graphs. I’d still have to cite a “one number” specification for the eventual brochure or specs box, though, but at least with Real Dataz behind it, I don’t feel as bad fibbing a little.

With 30 amps under the belt, I decided to try adding a little bit of forced convection. Here’ a quick fan mount I whipped up for the board that uses the existing standoff/mounting holes and a very small 12v, 0.12A 40mm fan.

The CFMs from this thing are rather low – about 10CFM rated, but it’s split fairly evenly in 3 directions (the 4th is blocked by a flap of the mount I made), so each side really gets about 3CFM.

This was also a chance to test out my new load. This is a 0.6 ohm, 550 watt power resistor. Conveniently, it’s not wound to cancel its own inductance, so it’s a nice…..little?…. RL load.

With the resistance being fractional ohms, it’s easy to push tons of current through this thing. I also have a known fixed relationship between current and voltage, so if I wanted to achieve the ideal 50% duty cycle for stress-testing the board, then I can set the power supply accordingly. For instance, if I wanted 50% duty cycle at 30 amps, I would have set the power supply to 36 volts (30 amps * 0.6 ohms = 18v output at the controller, and 50% duty cycle represeting 18 volts average means 36v input).

Unfortunately, the board has seemingly started exhibiting regulator resetting issues again. It usually occurs a few minutes into testing the current limit, and the failure is “soft” i.e. the gate drives just shut off due to low voltage. The regulator once again enters a weird latched up state that I supposedly solved on RageBridge1 a few months ago. This time, I’ll need to hunt down the error a little more carefully. It could have been that, for example, a solder joint was stressed during the last test’s heating and cooling cycles, or some other equally hard-to-find bug.

Before the board reset, though, I was able to get the temperature to hold approximately steady at 58 to 60 celsius after about 4 minutes. This is a good sign that I can (after I figure out that damned regulator issue) start upping the amps to find the limit of what airflow can do!

In the time I’ve been waiting to hear back from users, I’ve made a few changes to the board to resolve some of my (and others’) complaints and some of the issues exposed in this thermal testing:

ragebridgetwo v2

RB2′s first version had a few issues which were typical of me rushing a board out the door.

  • There was a single digital pin input to enable the Mix mode, but it had no corresponding ground or 5v jumper to attach to! Not sure what I was thinking there – to active mixing I had to solder a jumper wire (and tell other people to do so).
  • The one capacitor is clearly not enough, and some rearranging of things is needed in order to fit one more per side.
  • The gate drive regulator only takes approximately 15 volts input. I think it should have the ability to run off a 12 volt battery, because 12v systems are still extremely common in small robots as well as in FIRST Robotics. I’m not discounting the possibility of eventually going after FIRST with this thing, but having a controller which has a very wide voltage input is just nice.

The latter problem took a while to think about and fix. There are very few commercial regulators which can stand the whole range of voltages I wanted – down to 7 or 8 volts (for the really, really flat 12v battery) and up to 55-60v for a 36v nominal system which can see some spikes and surges. The standard solution for me is to buck-regulate (down-convert) to the gate drive voltage (12-15v) and then linear regulate to logic levels (5V). However, this means pretty much the lowest voltage that RB can operate at – period – is about 12-13 volts. The buck regulator, a LM2594, just switches full-on during this condition, but it has a 1.1v drop from input to output. Add in another drop of the output diode of approximately 0.75v and I am wandering dangerously close to the 10v shutdown point of the IR21844 gate drivers. That means RB technically can’t run off anything lower than 4S lithium polymers (14.8v) safely, hence cutting off the “12v lead acid” market.

A more robust method is to buck down to 5 volts first, and then boost from 5v to the gate drive voltage. Many super LV-input controllers either do this or the janky thing of just running the gate drive on 5-7 volts. The downside is that it requires 2 converter chips – a high voltage input buck regulator and then a little boost. Neither are that cheap, especially HV input regulators. But, this method allows operation almost right down to 5 or 6 volts!

Wouldn’t it be nice if they made something which could either buck or boost and take the entire target voltage input range? It turns out (after hours of rummaging on Digi-key) that such devices do exist.

One example is the LT3971, a buck-or-boost converter designed for LED power supplies. It takes 4 to 60v input and gives you whatever voltage out that you select. I was really favoring this until I realized it doesn’t have internal switches – i.e. integrated FETs. I was going to have to build a motor controller on top of my motor controller (sup dawg) with tiny FETs in order to use it! This is basically a project entirely on its own.

Then I found the LT3433, which is a much simpler device with internal switches and needing just an inductor and a handful of passives. It could theoretically accommodate 4-60v also, but presumably due to the compromises of its design compared to the more freelance 3971, it really can only work down to about 8 volts in my application. Whatever, close enough. It was also kinda okay priced in large quantity – only $3.40 in 100 or more on Digikey. I’m certainly getting gouged for buying one or two for testing (what do you mean it costs 6 dollars)…

Doing the layout for this thing was an adventure. First, it needs so many passives. It has all kinds of fancy compensators and buttons and switches. Second, I use 1206 parts.

Stop laughing. I know it isn’t 1982.

I’m invested pretty heavily in 1206 parts, though, and find them convenient to work with because they are still quite large. Really I should be working in 0603s – about the biggest thing you find in modern electronics.

Here’s the first picture of RB2V2:

Doubled caps, check. Actually useful MIX enable header, check. The main power inputs had to move, so I’ll have to rebuild my test jig, but that’s a small potato.

I also added an external LED header. One of the ways people apparently mount these things is heat-shrinking the entire thing and gluing it to the robot. I’m mildly peeved, but even they deserve blinking lights, okay? The header is pretty much a tap from the LED circuit, so there’s no resistor required.

The LT3433 and its passives have not been routed yet. It took a few rounds of arranging before I settled on something which wasn’t utterly terrible.

Here’s the final routed layout of the new power regulator. I’m sure I could have placed some things more scrupulously. What I learned here is that I hate TSSOP packages. You can’t even thread a trace through their pins because they’re so damn close together. This also isn’t a 4 layer board, so it’s not like I can just escape onto another layer. That thermal pad in the middle is really, really in the way of everything.

There’s some parts of this board which I have doubts can actually handle the output of this chip (400mA-ish maximum), but I’m hopefully never going to run that level of current on the gate drive rail unless someone’s powering lights off the fan header or something.

I’ll let this design “bake” for a while, stare at it again, and send it off for fabrication. There will not be another alpha testing round, however. I’m going to get maybe 4 of these maximum and beat them up in various ways. The power lay out and most components are totally unchanged from the current testing round. If these boards prove to be legit, then I plan on launching a production run ASAP.



The RageBridge Breeding Program: Alpha Tester Application & Other Stuff

Oct 14, 2012 in Motor Controllers

They’re done!

After my Digikey and Avnet shipments arrived, I could finally finish out the 8 remaining RageBridge2 boards in the panel. Using my handy dandy hot-swap test rig, I’ve determined that they at least power on right now without exploding, which is a good start.

Before I upload running code, I’m planning on adding a mix option to the firmware which can be activated by soldering a little jumper wire (a future board rev will add a header that can be used to select it). This way, the controller can be used with non-mixing radios (like 2 channel pistol grips) to let one channel control steering (differential) and the other speed (magnitude).

Update 16 October! The mixing firmware has been implemented.

The two RageBridge2 boards I assembled last time have been tested in real-life driving already. First, I installed it in Null Hypothesis in place of the RageBridge v1:

Then I gave board serial #2 to Adam and had him install it in his pre-Dragon*Con speedballed robot Blitz.

And then, we faced off at the Somerville mini Maker Faire:

Basically what it reduces to is two somewhat gimpy bots driven by two out-of-practice drivers. The motor that smoked in Blitz was on the front lifting tines, and it was being driven by a Victor 883.

But despite my best efforts to test these boards out in a strenuous condition, Blitz and NH are kind of… the same. They both run 4 overvolted drill motors (and keep breaking them… clearly these things have gone totally to shit) coupled to 4 inch wheels, and while NH has a higher top speed due to my more overvolting, the RageBridge boards limit the  motor current such that the motors kind of behave the same anyway.

I need more data points before declaring the RageBridge Certified Legit™. That is why I will now officially announce the….

ragebridge breeding program

These 8 boards will be released “into the wild” as much as possible such that I am not in control of their use and installation save for a short user manual page. I’m therefore going to put the call out for participants.

You may qualify for the RageBridge Breeding Program if…

  • You have a load, such as a robot, vehicle, grain thresher, etc. which runs between 18 and 36 volts, has 2 DC motors, and would like about 40-50A, but can live with 60 amps at most. This is because the RageBridge has intelligent constant-current limiting set to 60A. So if you don’t mind a little… anemic acceleration on your twin Magmotor mountainboard, that will work just fine. At this time, the 2 output channels cannot be combined into a single high-current channel.  The 36 and 24v boards are currently not the same in order to test out different components, but the production version will run the whole range of voltages.
  • It exists right now and you can swap RageBridge into it. Sorry, projects which will be finished Real Soon Now cannot qualify.
  • It uses an R/C radio as an interface. RB currently cannot take analog inputs (e.g. throttle pedals) or TTL serial commands. “Vehicle firmware” which does take these inputs is one of the things I intend to work on as soon as possible, and serial commands is also on the list of things to add. The firmware is easily flashable in the field for when that happens; you will need an FTDI cable. After all, I do write the firmware for this controller in Arduino…
  • You are willing to send $50 USD to help me offset the cost of boards and parts. If it works great for you, then awesome – 36V dual motor controller for $50, and I’m not gonna ask for it back! But…
  • You understand that you are not receiving a finished product and there is no warranty on functionality or reliability. Do not use this to hoist people up elevator shafts or to run your heart-lung machine, for instance. Would you even use an Arduino to run a critical medical device like that?! Each RB board will be tested before it ships out and I can only take “returns” for DOA.
  • You are willing to send me video, pictures, and/or test data showing the board working in your environment.

If you agree with the conditions, send me an email (charlesg@ this 3-lettered university name .edu) with the subject “RAAAGE” (that’s 3 A’s) and the following information:

  • Your load details – what it is, and what voltage it runs, so I know which board type to send you.
  • How soon you intend to install and test the RB board
  • How you intend to mount the board in your load (via its mounting screw, heat shrunk, above a fan, on a boat with a goat, etc.)

Because there are only 8 boards available, I clearly cannot take everyone. I’m seeking “diversity of loads” here – vehicles, robots, elaborate dentistry tools, etc. I will set a deadline for “applications” of MIDNIGHT on Wednesday, October 17th (that means as soon as the clock turns to 12:00 and it becomes the 17th). Eastern Standard Time. I’ll notify both accepted and rejected parties then. They’ll ship during the week.

Preliminary specifications:

  • 18 to 36v nominal operation
    • Absolute maximum voltage for “24v” boards is 37v, absolute maximum voltage for “36v” boards is 57v.
  • 40A continuous at room temperature with no additional convection or insulation.
  • Constant-current region above 60A (your load will see a maximum of 60A, plus or minus a bit of ripple).
  • R/C servo pulsewidth range of 1900us to 1100us with 1500us center. +/- 20us deadband.
  • 5V power available for receivers
  • 4.5″ x 2″ outer footprint
  • 1.7″ x 1.7″ hole pattern for mounting, sized for #4 screws.

the ragebridge fundraising program

I intend to send out one more board revision before releasing the design to manufacturing. This new revision will wrap up some of the hardware loose ends like component placement, manufacturability, trace routing optimizations, and like, making the RESET button actually reachable with an average finger.

Boards and parts (especially parts for 10…) are still really expensive, especially in low test quantities where I can’t take advantage of price breaks.

If you like the RageBridge and its new addition of a constant current output mode to the small- and medium sized robot/vehicle controller world, and want to support its development, then please let me direct you to my donations page. There is no suggested donation, and contributing does not constitute a pre-order for any product!

The whole mission of the RageBridge project is to try and make a compact, reliable dual channel high-powered motor driver using 21st century designs and parts, with no “fanciness” like dual encoder inputs, built-in PID controls, 8 different ways of taking commands, etc. in one unit. It is a rebellion against the new trend in robot controllers to integrate all of these functions and charge more money for it while not really being that good at, you know, driving motors. Basically, I want to give the venerable Vantec series and Victor 88x series of controllers a this-decade equivalent. Raw, simple power for applications which demand it, and nothing more.

the ragebridge kickstarter

Support us on Kickstarter! The link to RageBridge’s campaign is…

Not yet. I fully intend to pitch this sucker up on Kickstarter when I have a demonstrably working device. No promises and renderings here – I’m fully intending to use KS to gauge the initial market and to tell me how many times to hit the button. So if you’re just totally into a public fundraising campaign or find paypal links repulsive, hang tight!

Some more 3D printing shenanigans: The Up!

Oct 11, 2012 in Make-a-Bot, Reference Posts, Stuff

Scheduled plug: I’ve added a pile of new things to the Stuff for Sale page! Go check it out.

An exciting new thing came for me in the mail right after Maker Faire, and I think I’ve gotten finished playing with it enough to post.

Back in June, I wrote up the Democratic People’s Republic of Chibikart for Instructables and entered the Make It Real contest. It won one of the first prizes, which is an Up! Plus 3d printer, to add to my flock of 3D printers.

That was in July. I just got it a week ago, due to Instructable’s famed lack of shipping organization. That said, I was greeted with this in the shop last week:

Shiny. Let’s open it up!

I see the thing…

Very shiny (looks like glossy enamel) indeed. And orange, I guess because this was an Instructables-commissioned machine.

The Up is a pretty simple machine. It uses the ‘overhung arm’ architecture where the table is mounted on one moving axis and the head is mounted on another traveling, perpendicular axis. Now, I actually think this is the worst design for 3D printers because not only do you have issues stemming from workpiece acceleration (it’s moving), but the axis inertias are also mismatched.

Furthermore, the arm that sticks out is really flexible – it seems to be only mounted by one flap of sheet metal. It The X movement of the extruder is transmitted as vibration into the arm, and the end can resonate a fair amount – at least 3 or 4 mm of wobble at the end! Luckily the printing occurs very close to the arm’s support, so it seems to retain resolution accuracy. But still, it makes the machine design side of me cry a little. The new Up! Mini addresses this with a dual-rail axis design.

It also has a really really loud buzzer that makes it sound like an overly enthusiastic microwave oven whenever it starts, warms up, and begins/ends a print.

It also comes with a fairly extensive toolkit. Fairly typical 3d printer diddling tools like tweezers and a paint scraper are included, as are build platforms, mounting screws, and a nozzle wrench (but no replacement nozzle). I also got a pair of fabulously pink work gloves, but I’m not sure how they’re supposed to be used (are you supposed to grab the nozzle while hot?)

After I made a klein bottle as the printer’s first test, I let it run overnight on this compound of 5 cubes.

I’ll take a moment mention the UP! software. As far as I can tell, it’s closed source. It offers the usual array of tunable features – layer thickness, speed (just fast, medium, or fine), and infill (loose, dense, solid, hollow…), but only generates a square mesh (while Replicator can generate hexagonal meshes or just line scribble). It also slices way faster than ReplicatorG, but the user interface is a little strange with its button press sequence to do a common task like scaling or rotating, but that is a minor complaint.

What is REALLY nice about it, though, is how it generates the support lattice. This is the one place where I think it beats everything for intelligence, because alot of planning has to go into making a homogenous-material (i.e. not dissolvable or something) support that just falls away when done. If you’re a Stratasys printer, you can just puke support material everywhere because the intention is for said support to be dissolved away in the bubbling cauldron of lye. This is a very different, controlled kind of puking.

That entire cocoon for my cube thing came off in one piece, with absolutely no knifing or prying. Same deal with the “raft” layer. Contrast this with the amount of scraping and filing I have to do to the average Replicator(G) print and it seemed almost magical. I’m not sure how it is able to do this -it doesn’t seem to pause for a temperature change when moving between supports and part, so I think it must just be very careful extruder control to make sure the parts just barely come into contact.

It generates several different types of support – there’s the loose lattice that is used to build up the bulk of the support, then a very fine and nearly solid layer that is the one which makes contact with the part (which makes the near trivial breakaway even more amazing). There’s also a “cross hatch” like option which is used only for the loose layers.

Either way, seriously, what? I wouldn’t mind seeing a more robust support generation scheme for Replicator. Or, even better, maybe I should try hybridizing this guy with our Replicator 1 and make an Uplicator. I’d love to combine the high speed-capable gantry head of the Replicator with the Up’s slicing engine and controls.

There’s also one more thing I like, which isn’t Up-specific but I have not seen it until now: perfboard build plate. I am a definite fan of this. On that giant 4.25″ wide print, there was less than 1mm of lift on one corner of the hexagonal base. In ABS! As far as I can tell, the little holes in the perfboard cause the molten ABS to flow into them and hence achieve a mechanical interlock, way better than counting on the strong force interaction or something with a smooth tape. The Up came with 3 pieces of 2mm-space perfboard. I’m tempted to go buy a 6 x 8 panel from Radioshack and check out how it works with our Replicator.

I did a little more research into it and found that perfboard is now a common build surface, especially in conjunction with “ABS juice” that is made of ABS bits dissolved in acetone and painted on the platform.

The more you know…

After experimenting with the Up, I was determined to tune our Replicator to achieve similar qualities. Most of all, I was out to play with the support generation to see if I can achieve a less tenaciously integrated support lattice. I had been opposed to messing with before since technically it’s not “my” Replicator, but belongs to our research group, but I have literally not seen anyone else use it except me, so who’s gonna complain!?

I began by turning down the support flow rate ratio in Skeinforge way down. I had noticed before that the support material was almost as thick as my part lines, which seemed unnecessary. Next, I increased the density of the interface layers (which seems to drive the density of the support layers) so there was more ‘support resolution’. This did involve figuring out a better system so I could get the raft off the part easier (the denser interface layers appeared to want to stick to the part more than anything else). One more parameter I messed with was turning up the “support gap” ratio, which caused the lattice to be spaced further away – this was increased from its native 0.005 (meaning pretty much touching) to as far as 0.1.

I tested these settings by printing a few overhang dongles using full support and rafts, then when I thought I was at a good location, by test printing a difficult object which required full supports: this figurine on Thingiverse.

I think it turned out pretty damn great. Full disclosure: I tried this on the Up! and it got about 3/4 of the way up before the wiggling of the build plate caused the nozzle to bump the whole print off the machine. Oops. That’s what you get for being non-gantry, I guess.

Chunking off the support was pretty easy, but there were definitely lots of areas where I had to knife pretty hard. It looks like I’m the first person on Thingiverse to even try this print, too.

Additionally, one thing I noticed was that the long runs of very thin support lattice (seen in the first picture of the print) tended to warp and buckle much easier than a thin walled part would, probably because the flow rate is modified so much. On smaller prints it was okay, but I’ve definitely had support detatch from itself and curl up before. Once that happens (it seemed to happen at the base of the model), it is generally very hard for it to pick itself up again.

So I decided to try turning on the “crosshatch” option, which normally in RepG makes a pretty damn solid lattice that is utterly impossible to do anything with, but turning the flow rate down even further. The result is what I will call “point cloud” support. The string of plastic breaks between intersections (or leaves very very fine threads) and basically forms a coarse-, open cell, layer-by-layer deposited foam:


The “point cloud” is supported by the interaction of all those fine drool threads  and is remarkably solid if you push on it, but it falls away in huge chunks and the remainder is easier to scrape off. Still not Up! class, but a pretty awesome departure away from having to chisel your part out of its own pupa.


I next tried this method on the ultimate test: something I 3d scanned, so is not going to be remotely clean or easy anywhere.


The model in question is a Hatsune Miku mini-Nendoroid figure that I own. Now, if you know me, you know that just about the only thing I can be considered a ‘fan’ of is Miku and the Vocaloid media franchise and user community. It’s difficult to explain what it is without sounding like an internet startup guy, hipster and open-source advocate at the same time. In short it’s crowdsourced user-supported synthesized music you’ve never heard of.

Hey, when did I get a 3D scanner?!

It’s not mine, per se, but the IDC lab space has been getting some new toys since the last semester, partially in support of MAS.863, the renowned MIT Media Lab class that teaches fabrication and design skills (which Mechanical Engineering doesn’t have an equal to, by the way). This NextEngine triangulating laser scanner is one of them.

Since this was pretty much my first stab at 3D scanning, I neglected to take more than a few orientation scans (which meant the model had a ton of uncloseable holes in it) and then tried to save it at full resolution into an STL. The result was a 130 megabyte STL file that nothing could open or slice. I had to go back and greatly simplify the polygon count in order for ReplicatorG to even think about working with it.

While the STL just had too many gaps and errors for Replicator to generate a successful tool path (there’s some places that are just totally missing or filled with garbage), the “point cloud” support worked as intended. It looks really messy and disgusting on the outside, but the interior is a regular grid of very fine blobs and lines.

Since the whole point of this exercise is really just to get me a Miku figure clone, I tried it on the venerable Up. It handled the errorful STL wonderfully, though it pointed out to me where each and every one of the missing faces was. This was once again an overnight job…

Miku ended up being 4 discrete solids because of the holes in my model – the scanner couldn’t really capture the detail of the hair joint in the orientations I had it, so the point/mesh cleanup routine chopped them off. And no matter how removable the Up support is, it was still made out of the same ABS and so I had to cut part of her loop antenna structure off to remove the internal support, then reglue it back on.

Her legs are also… uhh, detachable?

But some hot glue fixes both problems.

I’m going to sacrifice this figure by supergluing the joints together so it can stay in one pose, long enough for me to scan it from every orientation. Then maybe I can get a higher resolution and fully one-shot printable model up on Thingiverse.

The bigger lesson here, though, is that I really like the “point cloud” support method. I’ve made so many changes to my Skeinforge settings that it’s not really worth trying to narrate them all here. So I’m just going to upload my slicing settings here (stuff the whole folder into your .replicatorg/sf_50_profiles directory and it should automatically recognize from within Skeinforge.

I’m actually kind of serious about trying an Uplicator hybrid. Pretty much all 3D printers are just a few steppers and a heater or two, so I don’t see much difficulty. They even sell the control board for the Up, but sell the CPU separately…for one hell of a sum. I wonder if that’s just an ATMega chip on a breakout board.

The only issue I see right now is that the Up homes differently than the Replicator – the former homes at “Z maximum” and the latter at Z minimum, necessitating different limit switch placement. In the mean time, Up!

but there’s a catch

With two competent hobby-class 3D printers sitting next to me, there’s something that has been a little forgotten which I will now finally decommission.

Poor Make-a-Bot.

The last time I turned this thing on was in late March some time. Ever since then, it’s been sitting quietly on a table, gathering MITERS grunge. The hardware, Makerbot’s Gen3 boards, and the extruder (a stepper chopped MK5), are generations behind. It was really never meant to be a 3D printer – too beefy and solid, but with my extra-stiff axes and much larger stepper motors I could still hold good resolution even at moderate (50-60mm/s) speeds. It’s really better off as a PCB router or very small mill.

Make-a-Bot isn’t being dismantled. Instead,

I’ve sold it to a hopefully loving new home that will turn it into something else awesome. Bye Make-a-Bot :(

The RageBridgeTwo Breeding Program Begins!

Oct 08, 2012 in Motor Controllers, Stuff

I received the RagebridgeTwo boards literally the day before we left for Maker Faire NYC 2012! Here’s what the whole panels looks like!

That’s pretty. MyroPCB sent this panel to me sandwiched between two scraps of MDF which seems to have been the disposable bed of their PCB drills. I spent quite a while looking at the drill patterns from the other orders and wondering what they were (at least one seemed to be a user-generated breadboard…)

I’m fairly amazed with how well the thing turned out. After the designs posted last time, I made a few more minor layout and trace routing changes in order to be more compatible with Myro’s 2oz design rules. They seemed to want 8 mils trace/12 mils space for 2oz – which seems a little loose, as Advanced Circuits could go as low as 6/6 last time I checked. The trace widths weren’t a problem, but several places had problems with 12 mils spacing between elements.

I don’t think I did a very good job with the space thing, since that would have involved routing almost all the board over again (the gate drive area is a tight squeeze), but Myro ran them anyway and they seemed to all have etched properly.

I decided to make 2 boards out of the panel just to make sure that the routing worked. After all, no use in populating all 10 only to discover that I made a truly phenomenal routing derp (and I didn’t have parts for any more than 2 at that time anyway…)

Now with more FETs.

I’m going to try out several different FETs between these ten boards in order to gauge what the effect on continuous operating current without airflow is. I have the following types:

  • Infineon’s 034N06, 60v and 3.4mohm. These are pretty much the “worst” ones I have – I bought these originally when I was wanting to not blow up 5 dollars every time a FET goes (like I was with the IRFS3107s).
  • Infineon 017N06 60v, 1.7mohm. These are the current choice for Ragebridge and are in all the robots. Conduction losses halved from the 034s. These, along with the 034s, are both compatible with a 36v mode for these controllers. The only thing that limits the hardware to a certain voltage is the choice of FET and capacitor – for 36v operation, I’d want at least 60V FETs and 63v capacitors. 75v FETs would be even better, but they get pricy in low-resistance models.
  • IRF3004-7 type, 0.9mohm, 40V. These will be the best choice, I think, for the standard 24v type RB, but IRF is pricier than Infineon (whose nearest competition is the 011N04of 1.1mohm Rds-on and somewhat lower gate charge).

Once I prove the boards working or otherwise, I’d like to snag some of the new Infineon 010N06s that just came out. Basically, the lower the on-state resistance of the FET, the more current I can push through the controller, so long as the switching time is much shorter than the on-conduction time. Right now, with the 1.7mohm FETs, I can push approximately 30 amps continuous in still air while adhering to a 100 degree celsius junction temperature. If I wanted to edge closer to the maximum temperature of the junction, at 175C, then I can push about 40 amps. Again, this is with absolutely no airflow and no heatsinking effect from the board bus traces or large-gauge copper wiring. Any airflow at all would be sufficient to push the current rating up.

The two test boards are loaded one with 034N06 and the other with 017N06. I only have a limited quantity of the 60v types, so the majority of the boards will be limited to 24v nominal (~30v peak).

Fully populated but not yet programmed. I didn’t even leave myself an ISP header on this thing – that 6 pin header is an FTDI cable connector. So how am I supposed to program the blank ATMega chip? How will I even turn it into an Arduino?!

The answer, as usual, is provided by Hobbyking. Seemingly on a war path to be the next DIY electronics dealer, Hobbyking has recently been peddling everything from said Arduini to robot kits. Aided by the hobby multirotor craze (Yes! There are such things as crazy quadrotor guys just like there are crazy 3D printer guys and crazy electric rideables guys), HK now sells quite a few different flashing tools for microcontrollers. This cute spring-loaded programing socket is a steal at $20 – a similar device from a more “legit” manufacturer would certainly run you triple digits.

And as far as I can tell, it actually works, very well. The springs are stiff, so the pins dig into the chip legs tightly and allow some wiggle room too. Only downside, it seems, is that there’s no orientation guide (that I can tell), so it took me a minute of staring at my Eagle files to discern which orientation to use it in (Hint: Tight group of 3 pins faces away from the dot on the micro).

Seriously. Get that right now, especially if you think you might ever be flashing anything 32-TQFP shaped.

I used it in conjunction with an AVRISP mkII programmer, since I couldn’t get that damned “USBASP” thing to be recognized by my computer or to function at all. A 6 to 10 pin ISP crossover cable was made with some quick breadboarding wire to bridge the gap.

After the Arduino buttloader is loaded into flash, the rest of the program uploads are taken care of via FTDI cable.

I had some fun discovering that “Upload via Programmer” in Arduino means “Erase everything and upload just the compiled sketch” – I spent quite a while probing my RESET circuit to see why my FTDI communications weren’t working, and then it hit me that the damn thing wasn’t even blinking once at startup.

The only changes from the Ragebridge version 1 firmware were some pin definitions, since I had moved several connections around to better suit the chip orientation. Furthermore, the now fully-symmetric current sensor layout meant that one of the current control loops had to be inverted.

What I want to do next with the firmware is to make a “mix” mode for the two input channels, which means you don’t need a transmitter with onboard mixing (or to set it up) in order to use the the controller. Eventually I also want to make it take commands in the form of serial packets (over the FTDI TTL serial connector). However, it will not have any more complications than that – no fancy encoder inputs or selectable analog inputs or kitchen sink interfaces. Ragebridge was designed as a rebellion against those modern ‘universal’ ESCs anyway.

Right now, though, it’s just bone simple R/C servo PPM input.

The one thing which prevents a ‘MIX’ mode from being immediately useful on this board is the fact that I neglected to put any hardware selector on the board. One of the digital inputs can be tied to ground or 5V (e.g. with a PC jumper) to activate mixing, but I just.. forgot to put one on there. Instead, you’d need to solder a wire to a random place with GND, which isn’t very useful.

These, and other random layout shortcomings, will be addressed in a 3rd board revision.

In anticipation of possibly having to test 10 boards, I went ahead and designed myself a jig. Similar to a bed-of-nails tester, it just holds a bunch of 3.5mm bullet connectors in place to make all the important power connections (bed-of-bullets tester?!) so I don’t have to solder 8 wires every time.

Here are the connections completed. Inputs and outputs are both my standard 4mm bullet connector interface. A 3.5mm bullet just happens to squish enough to fit into the wire holes on the board, so…

Board #1 under test. Conclusion: it works.

Whoa, I assembled a board, totally untested in the middle of the process, and it works on the first try. That’s actually pretty damn new and exciting.

The second board had an interesting problem where one PWM out was seemingly underflowing repeatedly, very quickly. A bit of probing led me to discover that one of the current sensors had died (or was dead to begin with) and so was pegging at 5 volts. Constantly triggering the overcurrent procedure, it continually decremented the output PWM command, went past its valid ranges (+/- 255), then underflowed its signed int holder and kept decrementing from the top again. This caused the motor to occasionally freak out as the output command entered then exited the valid range.

The spazzing also damaged one side because it was while the board was hooked up to a non-regeneration-friendly power supply. I fixed it by replacing some gate drive components, but I guess now I know which board I am hanging onto!

The test motors were an EV Warrior and a derpy 24 volt scooter motor. Basically the test involved alot of slamming the motors back and forth (on a battery, of course) after validating controller functionality on a current-limited power supply. This was  to test if the controller was sensitive to pulsed current-induced noise, and if the smart current limiter was working.

Alright, time to start on the next set of boards. This is like 5 hours of solid work, and in the end, I totally ran out of parts! I’ll have to wait until the next Digikey order comes in before starting the soldering process again. First to run out were my gate drive zener diodes, and oddly enough, 1uF capacitors. I also ran out of ATMega chips and gate drivers.

The development process for this thing is starting to get reeeeally expensive. I have yet to total up the cost per board in this quantity, but the chances of me giving away free samples to alpha testers is very, very slim.

Once I get my refill orders in, I’ll populate and test the rest of these boards, and then set up the structure for an alpha testing run. I intend on releasing these “into the wild” as much as possible in order to find their limits and how people are going to mess up on using them. The guidelines below aren’t set in stone, but are what I have in mind as to what would make a good alpha tester:

  • You have a device, whether it be a robot or vehicle, that uses 2 DC motors in some way. Right now. Not “will in a few weeks or months”.
  • Your system runs 24 to 36v. Up to 48v is possible, but I would need to specially configure a board for it. HV testing is something I’m interested in doing.
  • Your system usually pulls 30 to 60 amps, and can live with 60 amps at most (This means some high-current systems like Magmotor-powered go-karts will experience constant-current mode for longer).



Maker Faire NYC 2012: Infinite 3D Printers, Chibiing in the Rain, and More!

Oct 03, 2012 in Events, Project Build Reports, Stuff

Alright, here’s the grand report from the World Maker Faire NYC! As previously reported, I journeyed down with a pile of undergraduates and a tower of Chibis:

The trip to Queens took about 4 hours each way, and I pretty much made everyone listen to Hatsune Miku the entire way. I’m truly sorry, guys.

On another note, everyone who came with me have blogs full of fun build reports and pictures: Ben, Banks, Cynthia, Nick. Also technically in this picture, but buried behind everything and forming the basement and ground level of Chibi Tower is Nancy’s Giant Hexa(rideable)Pod.

We actually loaded 2 large cars to the brim with creatively tessellated things and people for the trip. I’m a fond fan of floor-folding seating for minivans, to the point that the Chrysler Town and Country is actually one of the very few cars I would actually buy (you know, instead of build).

The only things I ended up bringing and showing were the two Chibikarts. While Kitmotter came along, as reported initially, I never took it out for the weekend save to show someone what was inside a hub motor. RazEr Rev also did not make it into the pile. Overall, I think not spamming projects contributed greatly to me being able to… actually look around the faire and enjoy it and stuff.

Here’s everything, and everyone, unloaded and unfolded/reassembled. Let’s count: 6 scooters, 3 go-karts, 4 multirotors, a hexapod, plus DGonz’s robots. In terms of highly mobile electric powered objects, I’m gonna say that MITERS pretty much dominated the field. And that’s just what came down with us – after the day got started, the oneTesla crew and Team Blindlead, among others, also arrived.

One thing I was kind of tired of from last year (and demos in general) was answering the same questions over and over again. I don’t mind it to a certain degree – however, the same trends inevitable crop up: What batteries does it use? How fast does it go? ….is it solar powered?

Out of interest towards answering more in-depth and meaningful questions, I made these cute little stand-up signs with a few minutes on the laser cutter. The local stationery stores tried to charge me $10-$15 for a bent piece of acrylic that holds a sheet of paper, which I was less than enthused about. The signs have basic info on the project.

I estimate that they deflected about 50% of people who were superficially interested, and the questions that remained were somewhat more high-level, asking about how the motors worked and what controllers I used, as well as if I sold kits or plans. You people are really going to make me do this, aren’t you?

The placement of the MITERS table this year might have coupled significantly into the spread of questions, though. Last year, we were in the “big tent” where many kid attractions and organized Maker Faire events were taking place. This year, we were in the mishmash of hackerspaces and individual maker groups on the other side of the event. Many kids and parents, I think, were diverted towards the ‘tourist’ events. Only the more brave parents and fellow hackers/makers tended to peruse the hackerspace groups closely, it seems.

Alright, I could post a pile of pictures about what a Maker Faire is, but it would be duplicating the many other photo galleries on the Internets (including the official). If you haven’t been before, then I recommend finding a maker faire (or mini-maker faire) around you. I’m going to instead focus on the things which I took away from this event.

3d printers and open source hardware

The first thing I noticed was there were alot of 3d printers.

Like, way more than last year.

Here’s some that look to be half-Ultimaker and half… Hey, is that a un-shelled SuperMake-a-Bot?!

By the way, that’s a never-before-seen picture of the design. That is as far as I got on it before it was abandoned, and I never made the final post regarding it. I *almost* want to keep going now…. Pretty much everything was figured out at that point, but the project was dropped due to lack of originality or improvements on the previous generation, and for being ass-expensive.

Yeah, lots of 3d printers. This one’s an Up! Mini which debuted earlier this year. It, as far as I can tell, is an Up! in a box. Well, with other mechanical improvements like stiffer axes.

Alright, you people are just fucking with me now. From a Shenzhen operation is the Weistek WT2, which seems to be either creatively-restructured MaB or a larger, metal shell-less Thing-o-Matic (which is basically what MaB is anyway). The guys at the booth didn’t really speak English – what info I could extract from them in Chinese basically confirmed my theory that it ran all OS stuff including Makerbot’s Gen4 electronics.

I’m clearly not the only person to notice that there were a whole lot of 3D printers. Here’s an entire Make post dedicated to them. There are, if I haven’t made it clear, a lot of 3D printers!

What I found more interesting and more distressing was the fact that so many of them were making the same open-source thing. In a few cases, they are clear derivatives and straight up knockoffs being marketed as originals with no acknowledgement to prior work. Like that pile above. I really did a double take when I first saw that table, and had to ask myself if I was in fact in the Makerbot camp. Nope – Makerbot was behind me at the time demoing Replicator2s, and these were clones of the MK7 extruder and their related components.

Part of what spurred my interest in checking out the guts of many of the demo machines was the controversy over Makerbot going quasi closed-source with their new Replicator 2. If you missed the near-riot that occurred on the Internet as a result, there are plenty of strongly worded letters and appeals to Open Source that are definitely worth reading and thinking about. The OSHW community is basically being forced to recognize the existence of ‘design freeloaders’ now that Makerbot, one of the champions (or former champions, whichever you prefer) of high-value and high-complexity OSHW systems that are commercially available, has embarked on a seemingly more conventional entrepreneurial path, and that perhaps it’s time for the Unspoken Rules of Open Source to be publicly discussed. There’s alot of sides to the story, but I’ll take this moment to discuss my own perspective as someone who generally throws everything he designs up on the Internet for your amusement.

1. I support Makerbot’s decision to become more consumer-focused and to create better products

In product design, especially machines-that-make-products design, one of the worst things you can do is involve end-users in the manufacturing process. That opens up an entire world of manufacturing variations that could make your machine not work or work so shittily that people think it doesn’t work anyway. The goal of most industrial processes is to produce 1 part with 1 machine operation with zero variation between parts which last 100% of their designed lifetime and no more. Many studies have been done, papers been written, and theses been founded on manufacturing variability and waste/reject management.

But that’s no fun at all, IMO – the infimum limit of this function, in my mind, is Apple products. It’s not something that I think anyone should ever aspire to become, because not being to make your products fixable at all is just not cool. The other side of the coin is all the do-it-yourself 3D printer kits on the market these days which require many hours of assembly and fumbling small parts, in which the end user can introduce so many variations in both assembly and operation.

I’ll venture to say that 75% of the Repraps and Makerbot Cupcakes / Thing-o-matics I’ve seen are poorly tuned or built and as a result return only mediocre prints. It took me days of poking to get MaB to perform on-par with a well-built ToM. In Makerbot’s own words, it takes 8 to 9 hours of their support to build an average ToM from kit. When you sell to everybody, you no longer have the security of your audience being all highly-skilled hackers and modders who will take circuitous routes around a design or assembly problem. I was perfectly fine with performing 2 hours of tuning and software changes on our allegedly tested and working Replicator 1 and still calling it reliable and ready-to-run. The mentality is different for those of us who have a long hacking history versus beginners or people who saw someone else with an assembled kit and figured they could wing it.

To make your product work for all the possible combinations of things that could be put together wrong or not quite tightened enough, you have to compromise the functionality of the design. Things have to fit loosely so anyone with a laser cutter that may or may not have a fried lens and is running an inch out of focus can still cut it successfully. You have to use generic parts which are available at at hardware vendors, which may involve an indirect path of functionality to accomplish a relatively simple task (the many different 3D printed carriages for RepRaps come to mind). Kinematic coupling really only works if your base material isn’t prone to warping due to humidity and temperature (*cough* plywood) because it has to be easily obtainable.

Sure, it’s no fun to us as hackers if someone makes a product so streamlined and customized that it can barely be modified or chopped to our content. But that’s not going to be what 99% of people want. We are not the 99% when it comes to finished products, we are the 1% that is willing to suffer a bit of hammering for a chance to learn how the product works or to satisfy curiosity. But then the hacker market is necessarily constrained and easily saturated with similar products, which is why you have to keep moving and innovating. I’ve noticed that the OSHW community also takes “innovating” to be a rather constrained ideal of making the next new cool thing. Which it totally is, but making the current thing better or the past thing up-to-date are entire other axes which I think are underappreciated.

I’m not saying that building good product is entirely orthogonal to making it have hacker appeal, but to minimize your support time for every working machine involves taking out the end user as a source of errors, and this in part leads to the proprietization of hardware because it’s simply easier to accomplish the task (building working machines) that way. Especially if it’s not just you hacking away on a weekend, but a company that needs revenue to keep on rolling.

So that’s the long part of this polemic. I’m a fan of newer and better things from 3D printing companies even if I don’t get to directly build them. So long as Makerbot doesn’t start gluing their motors in or using pentalobe screws, I’m chill with them. As someone who maintains a handy database of mechanical engineering skills, I’m still more liable to building my own than paying 4 figures, but hey, I’m not part of the intended market.

2. I believe that the hardest part about designing a new product is the origination of the idea.

Everything else is derivatives, refinement, tweaks, and little variations. As someone who has generated dozens of original projects, I will say that 90% of the effort is spent grounding the design at a single point (deciding where to start the damn thing) and then building the first iteration. The rest of the time, provided you don’t just straight up start over, is spent making the thing actually work and not blow up when you plug it in.

I understand the frustration, then, when you see your project and work cloned by someone else without consideration for any of that initial design thrust. I’m not talking inspired works or even my undergrad and high school aged peers building variations of my projects. That’s for their own learning and amusement – recall that Make-a-Bot was a straight up cleanroom clone of a Thing-o-matic after I saw one at Maker Faire NYC 2010 and wanted one.

But never did I try to pass it off as something I designed and made from scratch, and hell if I tried to sell it. That’s not the case with the 3d printing outfits I saw at Maker Faire. The greatest offender to me was pictured previously with their pretty much straight knockoffs of MK7 extruder parts. I chose to not ask them the hard question (“Hey, this design looks kind of familiar – any other machines similar to these?”), but I think I really should have.

It may be true that they figured out how to make the extruder body from a cheaper plastic (UHMW, instead of ABS) that was easier to machine, and outsourced production to China for lower price. And it may be true that instead of a custom hobbed drive roller they literally took brass gears and cut a little groove in them, but that is skimming the 10% of effort away from the 90% that went into designing the original MK7.

So many other designs were blatant pulls from the Reprap project (Josef Prusa himself had 1 table, away from the 3D printer village, on which was parked 1 Reprap. Guy couldn’t even speak because he had lost his voice) with no attribution whatsoever – pretending that they were totally novel developments – that it was indeed very disappointing.

I’m totally aware that Reprap’s OS nature lends itself to this kind of thing, which is why I’m not entirely okay with the idea of open-sourcing everything. In my opinion, the core technology that forms the foundation of your product should not be shared freely unless you really were not in it for the money. Alot of people say they are not, but when these clones start arriving and they get hissy, it’s clear what the main motivator is because at that point they are either drawn by the lucrative market or too heavily invested to just let knockoffs slide. Speaking of investment,

3. Open-source software people and open-source hardware people work in essentially disparate domains, and even then, a 3D printer is a far cry from an Arduino board.

I have always had a beef with open-source software people. There’s tons of them around MIT, trust me. Oh, and all open source software sucks. Seriously. All of it. Generally they try to replicate the function of a closed-source software but with harder to use interfaces (no, I am not going to diddle with a command line, and don’t even get me started on OpenOffice) and inconsistent documentation mostly made of “run this linux script in a shell”. It’s usually made by 1 dude and his friends, and hosted on Git.  When it comes to software, I *am* that 99% of end users and I will not put up with mostly-working bullshit.

But enough about me, and more about the software. Software is cheap and easy because you just need a computer (a generally mass-produced item whose manufacture involves no end users, because damn if the computer you bought doesn’t work, right?), knowledge, and time. This explains why at the MIT Career Fair this past month, a solid majority of companies present were software startups and established software companies in some way.  Software is so cheap and easy, in fact, that MIT’s EECS department is starting to complain that no students want to do hardware any more, they just all want to work for/start the next Facebook.

What is different about hardware? Hardware needs to have a physical embodiment. Something needs to get made, and something else needs to get appended to it in order for the thing to work. As of right now, I cannot wish an object into existence, though the Replicator comes pretty close. But even that had to be manufactured and assembled somewhere, and the ABS filament it extrudes came from some oil well in the ground and had to be refined many steps before it could become my (unit linear) quantum of solace. My point is that the amount of resources that are irreversibly committed to a hardware project is much, much greater than a software project. With software, at worst you lost on the opportunity cost of pursuing a failed project. While that could certainly lead to doom, if you bust money on hardware that fails or doesn’t sell, you have immediately lost physical resources. The level of commitment of hardware is far different from that of software, and from my reading of the poetic floor wax of the recent OSHW debates, it is something that OSS people do not seem to understand.

The strongest opinions on Makerbot seem to be coming from the software end of things. Much comparison has been made to the Arduino project staying open source even in the face of clones from China and “-duino” derivative projects. But here’s the thing about such comparisons – it’s way, way easier to stuff a board than design a mechanical product (nevermind mechanical products with integrated electronics).

An established chain of tools exists for stuffing a board: Generate a set of Gerber files using your favorite design program, send it to a board house where a magical machine (with decades of history) uses your files as an image as a mask to etch copper where it shouldn’t be. The copper is washed and cleaned (automatically), holes and drilled and vias are packed (automatically), and the whole thing is dunked in a bath of solder to plate it. After that, provided that you’ve supplied the board house with your bill of materials and ordered the parts, the board is automatically filled with components by a pick-and-place machine and then automatically soldered in an oven. And this works, 99.9999% of the time, or else Foxconn would be out of business.

You cannot do that with a mechanical part. Take this picture of a simple motor mount for Segfault:

It’s a plate with holes in it. How simple can it get?

I can think of 3 different ways involving 3 different machines which can be used for this part if I wanted production, and that’s only in the time I wrote the last sentence:

  1. I can use a waterjet, like I did above. Waterjetting typically costs $120/hour, a machine is usually a cool quarter-to-half-mil, and I’d need a commercial 3 phase 480v electrical hookup to use it in the first place, and that ain’t cheap. This would make some sense for low quantities, like 1 to 10. By the way, Big Blue Saw is totally a thing.
  2. I can hire out the part to be 2D profile milled using a conventional CNC mill. The finish on the side would probably be way prettier and I can light the resulting chips on fire for amusement. 20-30 parts can probably be tiled into a single plate of aluminum and the machine would probably pop them out in under an hour with modern high speed machining. The machine can be fed by a technician and so maybe 200+ parts is reasonable for a day. We’re not talking exotic high-speed 5-axis CNC here.
  3. If I needed to make 10,000 a day, then I would have tooling designed to be used on a progressive punching machine where literally 1 cycle can produce 1 part. That tooling, again, can be made in many ways depending on who I contract it out to exactly and what machine that have, and what tolerances I care about, and what material I really need (can I get away with a softer metal to ease on tooling wear?)

What I’m trying to say is that hardware is way more involved than software – again, an issue of resource commitment. I can’t hit recompile on that motor mount after the $150/hr CNC technician has finished half the run of my parts on a machine which costs the company another $200/hr just to keep running. Part of the wonder of rapid prototyping tools lies in the fact that it is wholly within reason today to make exactly 1 part and be done with it. This explosion of design pathways is part of the reason why automatic quoting systems for 3d conventional machining have been much more difficult to make – I’ve yet to see anyone pull off a Big Blue Saw-like interface  (FirstCut is pretty damn close, but look at that pricing. Upload a solid model of a cylinder and see!) for CNC machining.

So I disagree with the attacks on Makerbot using Arduino and other OSHW boards as examples. It takes many real revisions and failed hulks of prototypes to make a working machine on this scale, and therefore you have far more to lose when the resulting effort is cloned 1-for-1.

What’s the message I’m trying to send with this hopefully perspective-enhancing piece? I’m not aiming to swing the Internet Backdraft towards any one direction, but hopefully the opinion of somebody who deals mostly in machine design and hardware design will add to the discussion which seems a little one-sided towards software and electronics hackers right now. I hope that will help solidify what OSHW stands for and aims to promote. As a closing statement, I direct you to the useful stuff section of my site.

Anyways, onto more fun things, like…


One novel event for this NYMF is a run of the Power Racing Series which took up a fair chunk of the NYSCI parking lot.

I’d been contacted by the event organizers beforehand asking if I wanted to run Chibikart as an exhibition, since they weren’t expecting many entries. With pretty much all the silly MIT vehicles in tow, we couldn’t resist taking a few runs at the track. Above was an impromptu “2 wheeled race” that happened on Saturday.

I had a little too much fun with Chibikart 1. It’s now sporting two completely toasted motors as a result of my drifting antics. The left side wheels are also pretty much ground down to the plastic. I found that the combination of a slightly wet ground (It was raining for some part of the weekend) and actually heating the tires up through turns made Chibikart very easy to controllably put into a lift-off oversteer induced drift. Pretty sweet, but unfortunately it doesn’t really have the torque to follow through, so it’s still more of a powerslide.

Chibikart 2 faired substantially better, and was actually more squirrelly – I spun it out a few times in the turns. Both of them also got disgusting because the rain had turned the usually quiet dust and debris on the parking lot surface into a nice liquid grime. Everybody who raced looked like they were actual open race car drivers by the end – covered in crud.

Chibikart 2 and tinykart tag-teamed an entry for the long endurance race on Sunday, which was essentially both of us running batteries to empty repeatedly because we never figured that these things were going to go more than 10 minutes at a time. On one occasion, I attached a tinykart battery to Chibikart and actually just held it in my lap for those laps. In the end, Team-unofficial-MIT finished 122 laps and was “4th place”. Now, we couldn’t actually win anything because the vehicles were totally not to spec and were entered in the event at the discretion of the organizer because they were in need of cars to fill the track.

So I must therefore officially protest the abundance of “We won over MIT!” chest-pounding that seems to be found in the highlights videos from several teams, including the official race promoter video. We challenged someone?!

While I recognize that being from a place like MIT inevitably means that we are viewed in psychological competition every time we do something in a large crowd (Georgia Tech gets similar heat, especially at Robot Battles), and that drumming up a little hype is not bad for an event, come on man. I’m totally into the idea of building a to-spec Power Racer after watching and participating, but the reaction from fellow competitors when we enter unofficially doesn’t bode particularly well for an official entry, nor is it particularly welcoming and liable to making me help promote the sport.

We conclude with a picture of Fort MITERS, constructed in about 5 minutes when it suddenly started pouring on Sunday.