Archive for November, 2010

 

A Wild Melontroller Appears!

Nov 25, 2010 in Melon-scooter, Motor Controllers, Project Build Reports

Charles! I choose you! Use SOLDERING IRON!

After a week and a half of anticipation, Melontroller 1.0 arrives just in time for me to spend the entirety of the Thanksgiving weekend blowing it up.

I used Advanced Fucking Awesome Circuits‘ $33 per board service, and the results are epic as usual. I elected to just spring for one board this time instead of panelizing or ordering more, since I wanted to make sure the design actually worked. The above is the bottom side of the board, where the crackFETs sit.

The top side is the horrible mess of 1206 component and SOIC components.

And an Arduino.

I suppose this layout isn’t that dense at all, but playing the routing game in Eagle was still a bit mind-boggling, and some times mildly frustrating. Much of it stems from the fact that I’m trying to maintain a 2-layer board. 4-layer boards would make all of this much easier, but they are also way more expensive to manufacture. I don’t think I’m quite that hardcore yet.

While the boards were in manufacturing, I placed several consecutive Digikey orders for the components that will eventually need to fill it out.

Here’s the scene. It looks kind of like a shady back-alley surgeon’s office, except with electronics.

Mid-assembly with most of the SMT passives and all ICs mounted. Excuse the blobbing – this was done with 1mm diameter solder (bigger than the damn pins themselves) and an iron with a tip so dead that I had to regularly sand it in order for the solder to stick.

That’s some serious bonage. I think it’s time to get MITERS new soldering irons.

I whipped out the Big Guns to solder in the output FETs. It’s a 100 watt Weller iron with a single 3/8″ wide tip. Not very scientific, but it flowed some serious eutectic.

Of course, I also managed to bridge together the single gate pin with all 5 of the source pins a few times, but that’s what they make desoldering braid for.

Notice the exposed conductors on either side of the FETs. Those will also be braced with some bus wire or braid in order to strengthen the trace where it is the narrowest.

And the last components to go on are the Arduino (on headers) and buscaps. This thing has some serious buscaps. I don’t know why on earth I specified two whole Joules (3x 680uF on a 60 volt system) of buscap, but they’re almost comical looking. It’s almost to the point where I’d need a precharge circuit.

I haven’t written the software or done a load test yet, but the circuit powers up without shorting the power supply, so that’s a good first sign. Over the break, I intend to write some BLDC square wave commutation code and see if I can run the MITERS Public Etek. After that, it’s time to put sensors on Melonscooter once again and see if this thing can live up to its name.

In the mean time, in classic me-fashion, I’ve already started designing version 2 before even finishing (or in this case, starting) version 1.

It’s actually not as bad as it seems. This is the exact same circuit, but better organized and routed. First, the layout is practically identical across all three phase drivers.  Second, the pull-ups and -downs are better organized and placed right next to their respective pins. Also, the outputs now use plain board pads instead of through-holes. No particular reason for this change.

Also, even more buscap.

Alright, not really – the buscap bank had to be trimmed to a mere 1,300uF. Boo-hoo.

The most important aspect of version 1.1 is that it’s a full half inch smaller in the X dimension. This can actually get even smaller, but right now this is the limit of what I’m comfortable designing, routing, and soldering. My ultimate goal is to reduce it down to the size of the average Turnigy 100A.

But don’t let the picture mislead you – melontroller 1.0 is only a little longer than a credit card, and 1.1 is shorter than one. That’s already pretty damned small for something that should handle at least 40 to 50 amps with some airflow.

reduction to practice

I’ll just leave this here.

Melontroller and the Melodrama of RazEr rEVolution

Nov 13, 2010 in Melon-scooter, Motor Controllers, Project Build Reports, RazEr rEVolution

This post is also known as Why I Should Man Up and Build More Motor Controllers.

RazEr rEVolution is currently assembled as a rolling frame. This means I’ve successfully managed to build a kick scooter again! REJOICE!

Small detail: the DNIR is installed, but the whole thing still rolls and coasts almost like a stock scooter. This is pretty paramount, IMO, because one of the advantage of hub motors like this which I’ve been telling people is that it still allows you to use the vehicle “normally”. Specialized electric drives (like Melonscooter, in fact) are just difficult to blend into vehicles which are designed to be human powered.

But enough harping on why hub motors are cool. The reason I wanted to throw rEVolution together mechanically is just so I can take it out of MITERS for a little while while I seek a motor control solution….yet again. Overall, I’m still in need of a medium to high power BLDC motor controller that isn’t the size of a house brick and has sensored inputs. Kelly controllers (and associated generic Chinese motor controls of the same genus) are the size of house bricks, and R/C airplane controllers, while cheap and available with high amp capacity, are sensorless and therefore have extremely poor startup characteristics for hub motors. The Turnigy ESC has been performing great on Melonscooter, but only because it has a 4:1 belt drive helping the motor.

In this picture:  (1/4)² inertia divider.

But what about the DECs? The thing that I had the biggest e-b0ner in the world for? Well, they were (and are still) performing admirably driving the Skatemotors. They’re well matched to each skatemotor, power-wise. But the DECs are still industrial motor controls, and with that come some issues. Specifically, they really do control speed. We call these things “speed controllers”, but at least airplane motors and most small EV controllers (including the Kellys, which can be configured in a few ways) are open loop. They’re knob controlled – you turn the knob, the motor goes. You turn the knob more, the motor goes some more, but there’s no guarantee.

The reverse is what causes trouble with rEVolution. The DECs appear to use synchronous rectifiers, which means the motor will brake if the command results in a motor speed lower than the current one. While this is used on LOLrioKart’s controller too, the DECs actually attempt to hold 0 speed unless specifically disabled.

Unfortunately, that last part kind of ruins the ability for the scooter to be kick scooted. Now, they do show this same behavior in the skatemotors, but those motors are substantially smaller in diameter and length – so your inertia overcomes their deceleration much more – and I’ve specifically programmed the Arduino running the two FSR throttle and brake inputs to throw the shutdown line on the DECs if each successive throttle reading is less than the previous one i.e. you’ve let go. So the skates can coast, no problem.

So then why not just use the same arrangement for rEVolution? Well, if I’m going to have to hook up a microcontroller and write software for it, I think I can do the whole system better and possibly learn something while I’m at it.

Shocker.

Anyway, that’s why rEVolution is currently a very elaborate kick scooter. Give me some time…

Here’s some pics of the mechanicals in the mean time!

Assembling the finishing details was fairly easy. The Garolite top plate goes on top of the aluminum frame, and then the steering neck / folding joint sandwiches it. Originally, the four holes were tapped for M6 x 1 screws so I could use the Razor scooter’s stock mounting screws. However, I’ve managed to lose them, and not having M6 screws at my disposal, I dynamically rethreaded the holes for 1/4″-20.

The two cutouts in the top plate are to go around the joint reinforcement screws. I’m proud to say that after a few bunny hop tests, they are holding up well.

Here’s the finished profile of the scooter, showing the interesting side. A Deans-shaped cutout holds a battery connector for charging and the main power switch.

In folded mode. I’ll be honest: This thing is heavy. It’s probably bordering on 20 pounds just because there’s so much \m/etal in everything.

Beauty shot!

Right now, I think the design looks a little “off”. The wheel widths are so disparate and the rear wheel such a commanding color that it just sort of dominates the entire design, and the front looks weak and atrophied by comparison. It’s like a queen ant – small head, huge abdomen. Like Shane did with Pneu Scooter’s new front forks, I might re-engineer the two-piece Razor A3 fork such that it holds a more manly wheel – maybe another one of the McMonster Truck Tires that I hollowed out for the back!

Compared side-by-side with Melon-scooter (which, incidentally, now has head and “tail” lights since I do operate it alot in open traffic…because it’s fast enough to keep up with most area traffic).

It’s not really that much smaller. Still a size class or two down, and currently, much less mobile.

melontroller

I’ve talked about it before, many times, the most recent time after I ended up reverting to the Turnigy sensorless controller. One of these days, I was going to build a BLDC controller that actually works, and is a little smarter than the average airplane monkey. Since I pledged that if I had to ever write code to drive a motor controller it might as well be a system of my own design, I’m going to take myself up on it right now.

One day (okay, midnight-early morning) I sat down and began scratching out a schematic in Eagle. What did I want in this controller?

  • 50 to 60 amps continuous. Real continuous amps. With FETs that can handle this, I’d say a hundred amps peak pulsed is probably doable.
  • Operating voltage in the 36 to 48v range, since I’m unlikely to go higher than the number of cells I have a battery charger for.
  • Single motor, sensored commutation.
  • Current sensing. It’s taken a long time, but I’m finally convinced that current control of an electric motor is b better than speed control. I’m still a die-hard open loop guy, but if I had to implement some kind of actual control loop, it’s going to be the one with a real world physical state variable (torque, current, acceleration, and inertia are all linked pretty much directly)
  • Arduino-compatible. Because…. because.

After a couple of hours of blitzing, here’s the result.


Eagle, what the hell did you do to my schematic?

I literally opened the schematic again after seeing how it wanted to place the components to-be-routed on the board and my gate drives started sucking in the passives around them. That image capture is from after alot of rearrangement.

But the gist of it is:

  • An Arduino Pro-mini
  • IRS21844SLBBQLOLWTF half-bridge synchrec drives
  • IRFS3107 cracked out FETs in the even more cracked out D2Pak-7 package.
    • Seriously, if this whole system works out, I’m asking International Rectifier for sponsorship. Not because I need it, but because they’re awesome.
  • Three ACS714 Hall-based, bidirectional current sensors. One on the DC rail, and two on the actual motor phases. Result? Ability to measure both DC and AC side current in both directions.  Life could get interesting in the future.
  • Two analog and two digital inputs, because I can’t quite decide what I want to do with them yet. So they’re generically named.

And after about 9 hours of advanced ninja board routing, here’s the end result:


Advanced Ninja Board Layout, MIT Course number 6.9000

I’ve sent out the BOM to Digikey and the board itself (just one for now) to Advanced Circuits (who I absolutely adore now because they tooooootally saved our bacon and even gave us a massive discount on the boards for our 2.009 project which we needed EXTRA EXTRA SOON and are therefore the most awesome PCB fab house anywhere, so much so that I’m making this whole block of text one huge link to them).

With some luck, and some code wringing, there ought to be some Melontroller in my future.

The D2PAK fets don’t have that much PCB copper to sink heat to, so my continuous amps goal might be a bit optimistic. But that’s one thing I want to test. I don’t care – honestly, I would much prefer to melt components right off the board because I purposefully commanded them to flow such a high current continously and the know that the design itself is sound, rather than have everything just detonate when I plug it in. The former is a glorious death, the latter a shameful one.

mini-melontroller

Now, the controller above is too massive to fit in RazEr. I’m already mulling over making a much more compact board, possibly with the Arduino on surface mount headers so it can park over the 3 phase bridge. The bridge would also be smaller both physically and ampacity-wise. Mini-melontroller should fit on a standard credit card.

How to Make-A-Make-A-Bot

Nov 06, 2010 in Make-a-Bot, Project Build Reports

The Man has been holding me down.

And by The Man, I mean MIT, which is well known for holding you down. There’s this little quirk about senior year called “graduating” that comes at the end if I behave. I think I should at least make some effort towards it, which is why I’ve been missing for a week. Most of that time has been absorbed by the Mechanical Engineering senior design course, 2.009, an exercise in realizing the futility of large team dynamics, the sanctification of rigidly defined process structures, vapid goals, forced decision-making, and irrelevant gimmicks An Exciting and Wonderful Adventure into the World of Product Design and Engineering Processes.

Right.

That.

So, when I last saw MaB almost two weeks ago, it was still a bundle of rendered lines and pixels on a screen. I decided to take my own advice for once and not look at the design for several days, letting the little intricate details settle and sort themselves, rather than staring at the design over and over. I’ve been well known historically for convincing myself that some incredibly numbskulled design choice was a good one… like the entirety of Segfault… simply because I got tired of inspecting the design. MaB was going to consume all the aluminum plates I had on standby, so I wanted to not make it completely fail.

Mix in a few classes and you have me forgetting the thing existed until a few days ago. But let’s get started:


ffffssssssssh.

I carefully tiled all the parts onto my four spare 1/4″ thick, 12″ x 24″ 6061 plates. These were all leftovers from the robot builds, collected over the past several build seasons. As it turns out, 4 plates was just enough to fit all the structural components on and still allow for fixturing area and dead space.

Next, it was to pop the entire frame out on the Machine Without Which I Am Nothing.  I pretty much devoted an afternoon to a marathon waterjetting session in which all the parts were cut without incident. Now, I’m pretty traumatized by the complete loss of heavily tiled parts in the past, but this time, the worries turned out to be unfounded.

Well, mostly. It helps that I was careful and kept a close eye on everything. This could easily have turned into a nasty situation – the closely tiled parts on the inside of the perimeter caused the nozzle lead-in to separate the scrap into two pieces… one of which proceeded to jut upwards.

I caught this moments before the machine was to make a pass to the left again. After every part outline finished cutting, I’d retrieve it out of the plate for peace of mind. That usually unnecessary action probably saved this whole plate.

Something I decided to play with on this build was the nozzle offset setting on the machine. Normally, the machine tries to stay one nozzle radius to the right or left of the cut line to finish exactly on dimension. In the past, I’ve accepted that the draft angle that results from such an action causes my tabs to not fit into their matching slots – while the nozzle side face is on target, the bottom could be as much as 4 or 5 thousandths larger on a 1/4″ thick part.

I’ve just dealt with the sanding and occasional light machining that is a consequence of this. But after observing how well the Cupcake parts fit together, I realized that I might as well try to see if I can get even more lazy by not even having to sand the parts afterwards.

Because Makerbot Industries cuts the vast majority of their parts with a laser cutter – which cuts on the line, ignoring the kerf offset, holes and slots are always slightly bigger, and tabs always a little smaller than nominal dimension.

I changed the offset a thousandth of an inch at a time – normally it’s set to 0.014″ for a .028″ diameter orifice. I started turning this down to 0.013, then to 0.012. At that point, I could just push the two parts together for a perfect fit. If you’re keeping track, that means my ODs are 0.004″ in total length (two offset…offsets) smaller on average and IDs are .004″ larger on average..

So this is what a pile of MaB looks like. That’s all the parts I have designed so far…

Oh, so I never let a post involving waterjet cutting go without mentioning Big Blue Saw at least once. You, too, can have your own pile of MaB (or pile of anything you feel like designing). I’ve been so utterly spoiled by MIT’s multiple machines that some times I forget about the fact that not everyone has access to one…. and some times, the next best thing is to just hire it out. Surprisingly enough, it doesn’t cost 9 billion dollars per part, and for larger quantities you practically break even on the foregone material cost.

Now merge into this pile a second one of McMaster, SDP, and Ebay orders that had accumulated over the past week or so, and dump it all on a table at MITERS. This is (about 50% of) Make-A-Bot, the other half being the electronics and the software that actually makes it move. You know, The Course VI Part Of Things that I have to deal with every time I build something, since as a Mechanical Engineer I absolutely must build complicated cross-discipline coupled systems projects with electronics in them somewhere.

The McMaster orders contained the majority of hardware, including fasteners, the axis guide rods, bushings, bearings, etc. I nabbed 4 NEMA 17 long-case stepper motors from eBay, which should have about twice the torque of the stock Cupcake CNC motor – hopefully more than enough to muscle the heavier aluminum frame around. Next, from Stock Drive Products, were the two X and Y axis belts and several 44 tooth and 17 tooth timing pulleys.

Alright, so I’ve cut myself a puzzle. Now let’s start putting it together.

The time: 7PM

Because of my “compensated kerf compensation”, everything sort of fell together. For the sake of convenience, I dashed some of the parts over a belt sander anyway for a free-slip fit rather than a push fit. I figured all of this has to come apart again eventually because I installed something backwards.

(I did.)

Above is the base and some of the Z-axis tower assembled, but relatively unfastened.

The X-axis stage holder is probably the best finished, most well-kerfed assembly I’ve made yet.

As usual, blitzCADing means I left a few details out. For example, while I made these cute frog-eyed axis rod stops, I neglected to transfer their hole pattern to the actual front and back baseplate walls.

Oops. I guess that’s what a clamp and cordless drill are for. The rod stops were clamped onto their anticipated final location and then #4-40 tap drilled.

The action’s picking up a little now. This is the whole Z axis attachment point, with an almost terrifying amount of interleaved T-nuts. Some of these things MUST be redundant.

I didn’t care. Square nuts are easily slipped in from the side, and I’m going to wager that Z-axis fine alignment can be changed by selecting which nuts I tighten.

After I fully assembled the Z axis tower, it was time for the Pass-or-Fail-at-Being-a-Mechanical-Engineer test. By that, I mean dropping the Z linear guide rod down the holes which are supposed to support it, and see if it falls all the way through by itself.

Okay, so I cheated: All nominally 0.500 holes in aluminum were given a run-through with a 0.505″ reamer. I was after the slip-fit, not a press fit or shove-fit, again for convenience of assembly. All the bronze guide bushings were also given the same treatment. After pressing them into their carrier holes, their IDs deformed enough such that they no longer  mated with the guide rods. A pass with the reamer in a cordless drill cleaned up the bores again to something freely sliding.

After that, both Z axis guide rods made it all the way to the bottom without incident. The compression rod is also shown (That’s not the Z axis leadscrew – it’s just a threaded rod that will be used to load the Z-axis tower in compression)

After the Z rods went in, I pitched together the Z stage. The bushings had already been given the once-over by this time, and the assembly… compiled, I suppose, with the help of a rubber mallet.

And it was beautiful indeed. No stick-slip, no jamming, no tight spots throughout the travel. I was very surprised it turned out this way, and I’m willing to bet the flexure bearings are accommodating at least some movement that would otherwise have caused total disaster. But with the Z axis rods as well-aligned as they are, maybe not?

After securing the base and the Z tower, I moved on to hammering the Y axis carriage together.

Here’s a quick assembled view of both axes. The Y axis motion is also extremely smooth. Due to its lack of gravitational preload in a convenient direction, there’s some stick-slip between the bronze and the polished steel, but it’s nothing a dose of Teflon-bearing oil didn’t fix. That, or just some exercising and running to fit the two cylindrical surfaces to each other.

After slipping the carriage onto the Y-axis rods, I installed the X axis guide rods. Note that they’re a different color and texture than the smooth steel Z and Y ones.

Out of the interest of reducing axis inertia, I elected to try some ceramic-coated aluminum guide rods. McMaster priced them out at just a dollar less expensive than a case-hardened steel rod of the same length and diameter, but the primary motive was to try and save the pound and a half that was the difference between the aluminum and steel. The coating on the aluminum is supposedly harder than the equivalent case treatment on a steel rod.

But after trying them out on the X-axis stage, I’m not sure if I like this setup. The bronze bushings exhibit strong stick-slip with the coating, even with a healthy dose of oil… and it even seems to be scraping off bronze onto the rod surfaces. My guess is that while the ceramic coating is harder than the steel, it’s not smoother. The case hardened steel rods have been subject to some pretty intense polishing.

I wasn’t nearly as satisfied with the X axis feel as much as the Y and Z. As a result, if axis inertia proves to be a false demon, I’ll just switch back to steel. Sadly enough, they don’t make hollow steel shafting in this size.

Otherwise, there’s always ninja linear bearings.

The coated aluminum rods only came in 13″ and 15″ sizes for whatever reason, and I needed 14. So enjoy this cute robot face that is the result of trimming the rods to length.

Enough silliness. This is where the hardware stood at 2 AM, after 5 net hours of assembly time (because there’s always things to distract yourself with at MITERS). There is currently no…

  • Head
  • Motors
  • Belts
  • Pulleys
  • Leadscrews
  • Motherboard, driver boards, extruder controllers
  • … or anything else, really.

Oh, speaking of the leadscrew, I’m 99% certain that the new Thing-O-Matic uses a 3-start “rounded” ACME threaded rod and matching flanged nut, 3/8″-12 diameter, for 1/4″ of vertical travel per turn. Makerbot Industries hasn’t released details yet, but I extracted what I could from all the up close, almost pornographic images I took of the 3d printing exhibits at Maker Faire.

Example: McMaster 6350K151 and its matching screw, 6350K113. Problem? The screw only comes in stainless steel, in 6-foot sections, at a shiny $133 each.

No, not happening. So what else goes 1/4″ per rotation and is 3/8″ in diameter? A two-start 3/8″-8 ACME leadscrew, of course. I’ve spec’d out McM 99030A315 for the leadscrew and 95072A126 for the nut.

I piled everything onto the base and slipped it in an empty corner for now.  Until another day, Make-A-Bot!