Archive for November, 2011


Ruminations About the Next 3D Printer

Nov 30, 2011 in Make-a-Bot, Project Build Reports, The Next 3D Printer

Poor Make-a-Bot.

(I’m just going to start every post from now on with how terrible shape my projects are in, eh?)

For about a year now, it’s been faithfully producing ABS plastic parts for almost all of my current lineup. Parts that it printed can be found on Landbearshark (chain tensioners), on both Razers (entire front forks and cover plates), very prominently on Deathcopter where ABS joiners are the majority of the structure, all of Pop Quiz 2r2, and like 16 different Chuckranoplan models. It’s also printed off countless random sculptures and weird things I found on Thingiverse.

I liked the fact that the (overly) rigid metal frame meant it could move faster and hold tighter tolerances despite being built like a truck. It had a larger build envelope than most at the time, and so I could do things like make single 8″ wide parts, though not always reliably. But I never installed the mechanical endstops on it, so it was a very manually calibrated machine, and at the time, stepper extruders were still new and experimental – I switched to a hacked version of one after the DC motor extruder died, and it never really showed any of the advantages of a stepper head because of the hardware and software were hacked to be compatible.

MaB was designed in about a week and built over the course of a month or so, and it was a crude copy-paste of Everyone Elses 3D Printer just because I wanted one quickly.  It was a decently front-of-the-pack machine when I built it last fall, but it’s definitely showing its age. The open source kit-class 3d printers have progressed significantly since last year, and there are more designs and implementation forks. Fast stepper extruders are now the norm and now twin heads are beginning to enter the mainstream. Interface software like RepG has progressed to being more user-friendly and less full of random bugs.  With commercial and open-source control electronics and software as developed as they are, the most I can really do is design and implement better hardware. That should be what I’m good at, and I think it was decently reflected in MaB’s operation. But at the end of the day, MaB essentially amounted to a Thing-o-(Semi-Auto)matic with more metal.

A few days ago, after finishing some structural elements for the quadrotor, my platform heater finally ditched yet again, but this time the damage was more extensive:

The short ended up blowing up the relay board and melted the terminal block. Along with increasingly frequent nozzle blockages, the head stepper seemingly becoming weaker and weaker, and me having finally run out of 3mm ABS filament, I think this was what told me that it’s time to move on.

Time to start a new page in my somewhat underused notebook and throwing down some sketches. I know it’s going to look like a box of some kind, but there’s some things which I’m still thinking about.

RAMPS system vs. MakerBot

I can design all the MechE hardware I want, but it’s going to be useless without the controllers to run it. Recently, I’ve been rummaging through the RepRap Wiki to check on the status of the electronics, from which many designs are ultimately derived.

I’ve come to like the RAMPS system – the RAMPS 1.4 combo shield can be had for about $200 fully assembled with 5 stepper axes on it (!), and it seems to do just about everything I would want it to do, and there is an active user and developer base. However, it definitely smells like an open source project: There are tons of firmware versions and concurrent developmentsfor it, most of which are maintained by a single guy, and all of which you have to obtain and compile yourself, then edit the Arduino sketch to define your machine configurations…. which isn’t necessarily worse than having to edit machines.xml, I guess. But I’m not a linux hacker, and not in a long time will you find me “using” git clone  or using Github at all (sorry Nancy), and with instructions as terse as “5. make 6. make program 7. ./“, which are meaningless to me, it’s no wonder the barrier to entry for true RepRap machines is higher.

On the other hand, the Makerbot Gen4 setup is more of a finished product that is plug-and-play with minimum fuss. MaB is in fact a Gen3 machine. The downside? It costs $400. Damn, that’s rough. But again, it also does everything I would need, it’s designed to work with other MakerBot devices, and it seems to work well. Plus, they have the sweet ass-LCD interface board (which RAMPS seems to support at the cost of even more Linux kernel recompiling)

So the real question is what do I value more – $200 on top, or my time spent doing potentially more software configuration and putting up with Linux hacking headaches (i love software, after all). Right now, I’m actually leaning towards RAMPS, since with that $200 I can buy just about all of the mechanical parts I need, and there are enough Linux hackers around MIT since we invented that shit and Reprap operators, to slap me around if needed. The RAMPS board is also way smaller than the Gen4′s individual modules. I don’t anticipate packaging being a concern, but small and centralized is nice.

gantry extruder

I’m sick of the bed-style design.

I’ve definitely ranted about this before – the moving bed design is inherently less rigid due to the need for long unsupported shafts. It has mismatched and non-constant inertia because one axis rides on top of the other, and your workpiece grows on top of it all. If you’re Make-a-Bot, you also have way more inertia to deal with because of the sheer amount of solid aluminum involved. The more inertia in the system, the slower it can speed up and slow down, and the more vibration and overshoot on hard direction changes there is (visible as wavy patterns on the outside of the piece) – I make up for this by having massive stepper motors and very high belt tension.

All of the high-end personal printers like the 3DTOUCH (and other machines from BFB/3dsystems) and every commercial 3d printer ever have the head on a traveling gantry and the workpiece remaining stationary. I didn’t go directly to this design at the beginning because I wanted something up and running quickly and the bed design was what I saw first and the most of at Maker Faire NY 2010.  But the writing is now printed in ABS on the wall.

There’s two main architectures of Cartesian gantry that are out there – the conventional series style and the parallel style. The series gantry is essentially the moving bed but turned upside down – one axis is a long bridge that can move back and forth, and the other perpendicular axis runs back and forth across the bridge. While it’s the most common, it does still suffer from the drawback that the mass of each axis is different. If the machine is sufficiently rigid otherwise, this is not really a problem.

The parallel gantry is a little weirder, and I’m going to link to Ilan Moyer, the only guy I know locally who pimps this design like it should be, and who is way more awesome than me. Here’s a good picture of one of his projects. In this type of design, there are 2 parallel X and 2 parallel Y rods, forming a box. The rods are linked using a belt, and transmit rotational power between them. But, they are also linear load bearing rails – the head has perpendicular support rods (non-rotating) that are mounted on linear bearings on the X and Y rods. This design has balanced inertia, and the combination of rotation and linear motion is no problem with a good set of bushings or linear ball bearings. The head is also fully constrained by the crossing of two rods.

In the 3dp universe, the parallel gantry is also known as Ultimaker style because the Ultimaker is the first popularly marketed machine to use it. I’ll be honest: I’m biased in favor of it, because Erik de Bruijn himself visited MITERS last year with an embryonic Ultimaker. I even got him to ride Segfault:

I got to see the design firsthand and pretty much continuously facepalmed the whole time about why I didn’t go directly to it.

The parallel gantry is actually simpler than a series one in terms of part count, but is less intuitive for most people to think about. But it’s definitely making it into the next design. Whatever I end up mounting to it will surely be better than MaB’s giant Y axis carriage which weighs somewhere in the neighborhood of 3 pounds.

chamber heating

This is the big hardware advancement I’m trying to pursue. I’m not sure why it hasn’t happened yet, besides Stratasys being patent hawks about it. Everyone has heated build plates, but the heat from that only really helps for the first few layers. Past that, your part is still being waved around in cold (relative to the extruder) air. This is the number one reason why personal printers can’t achieve large build sizes, because the plastic builds up too much thermal stress. Every once in a while, a layer splits off to relieve it.

I couldn’t even get RazEr’s fork to work until all of MaB was covered in a 55 gallon trash bag and a space heater was pointed into it. That got the bag internal temperature to something like 40C, and even that helped immensely. I know from studying commercial printers that they seem to hold the inside at 75 deg. C or so – in fact, actively fan “cool” the plastic from extruder temps down to 75C. I’m not sure if I want to build a thermally insulated box with internals rated for that kind of temperature (more on that soon), but even walling it off from outside breezes is a plus.

If the build surface is going to be inside a heated box anyway, I’m also planning on ditching the separate PCB heater which I keep having shorting problems with and moving to an indirectly heated surface. Essentially the idea is to blow hot air at the underside of the build surface (which would be some thin aluminum so it doesn’t take forever to heat up), and having the same hot air keep the cabinet at temperature. I got this idea from when I had to pull out one last piece for the quadrotor after the heater exploded – I manually warmed the platform up with a heat gun, which to my surprise took far less time than the heater trace itself and even got it past 100C.

So I think a large surface area of slow moving hot air would be a very effective surface heater.  Indirect heating also allowed me to swap out build plates. Basically, just look at my chicken scratch:


The “RGRID” is an anticipated circular arrangement of 25W power resistors. I have found that there is no cheaper option for prototyping and one-off heaters that are easy to assemble than a rail of cheap power resistors. Winding my own nichrome heater grid is difficult (I would need to find and machine high temperature wire support material like mica or ceramics), and stealing one off a toaster or something is not optimal since they’d be wound for 120 volts. So I currently have spec’d out 8 25W 1.5 ohm resistors radially disposed on an aluminum plate with heat sink like fins cut into it. At 12 volts, this should net me a maximum 100 watts of heating power. While using power resistors as high temperature heating elements isn’t really good for them, I can’t imagine this application (100-150C) being any worse than them being run at 200+C for the old extruder designs.

Hopefully the fan will be stationed far enough away from the resistor grid to not simply melt. If I design the RGRID properly, the heat should stay mostly within the region of resistor mounting.

I’m aiming for a 200mm square build surface for now – it won’t be too excessively large until I discover if the idea is scalable or not. The little things marked “height trim washers” are to compensate for the inevitable sag of a huge overhung platform. I might actually try mathing this out and designing the platform arms with a few thousandths of an inch of upward slant at the end such that by the time I mount a fan, a pile of resistors, wiring, hardware, and the build plate to it, it will naturally sag to be flat. But it’s a little easier and adjustable to make the final surface compliant instead.

native dual heads

I really like the new MK7 head from MakerBot – it’s way simpler and smaller than the previous acrylic-based designs. In fact, I like it so much that I’m just going to drop 2 of them on my parallelogantry and call it a day. Experimental dual head extrusion has already been done on Makerbot machines and now they even sell dissolvable PVA plastic to go with it.

Playing around with the MK7 Solidworks models  (damn, when did Makerbot get so classy?), I sketched out several ways to integrate two separate extuders into one package, and one way of making a very compact quad head arrangement. It involved machining my own mounts and re-engineering the way the fan cooling worked. This led me to I think briefly about trying to design my own extruder. Not only is the MK7 rather pricy ($200 per unit) and I’d just be using 50% of the parts from it, but it still uses a pretty beefy and heavy NEMA 17 motor. I played around with some numbers to see if I could possibly use a NEMA 14 or 11 – smaller motor, less mass. But I would really only save a few ounces at most, and the MK7 weighs less than a pound. Let me reiterate: anything is better than my giant Y axis carriage.

The sticking point is still the fact that I’d have to dump a very classy $400 on two heads only to re-engineer it anyway. Most of the parts are not available separately, which kind of sucks, but it’s simple enough that I can rig it all myself if needed. During this back and forth design process, I discovered that 5/16″ vented cap screws have a center vent that happens to be a few thousandths larger than 1 .75mm plastic filament, so that’s a potential starting point for the heater mount. In the worst case, I’ll have to replicate the motor mounting/filament guiding block thing separately.

Right now, the plan is still to buy some MK7s, but that could change.

…but where do they go?

The question is actually not as simple as I make it out to be. While dumping some stock extruders on a gantry is easy, the fact is that with chamber heating, anything and everything inside will have to stand continuous operation temperatures possibly up to 60-75C. Most stepper motors seem to be rated up to 50C only, and I’m sure custom high temperature steppers will be way more expensive than I want to deal with.

It is easy to mount the axis steppers “outside” the heated zone, but the head is difficult. With a heated box, the filament has to run all inside the machine – there can’t be a 12″x12″ hole at the top like most current printers. So I’d either have to build facilities for active extruder motor cooling (Peltier devices come to mind) or somehow locate the head motors elsewhere.

One plan I thought up involved making perpdicular, slotted bellows which surrounded the head but allowed freedom of movement in XY. Bellows are relatively inexpensive on McMaster and come in useful widths like 12″ and 24″. This is a mechanically complicated solution, but it makes enough sense in my head and does not seem difficult to implement, but will require a custom extruder design. It keeps the motors on the outside and the bellows trap the internal heat (mostly – the seal isn’t supposed to be perfect)

The other solution is a Bowden Cable feed, which is used on the Ultimaker and a few experimental Reprap builds. This in principle allows me to locate the motor anywhere I want, such as right next to the feedstock reels, wherever they end up.

But while the Ultimaker can let the guide sleeve curve gracefully over from its side-mounted extruder, I might not have that luxury if I have to keep the entire thing internal. I would imagine traveling up the side of the machine and then curving sharply over and downwards to enter the head is quite alot of length (and bending). While the Bowden feed seems to work well at the Ultimaker scale if the extruder can quickly change directions on command, I might have alot more (possibly up to 2 feet) of plastic noodles to deal with. The potential for elastic compression of the plastic in the guide sleeve is much greater, especially if it’s warm.

The ultimate hack-up solution is to use the Bowden feed with the crossed bellows. It might be the case that I find 75 degrees is not necessary to get good prints – or somehow, stepper motors work just fine in that environment.

My favorite plan at the moment is to just mount the motors to the head and have it pull filament as needed, which is the system in popular use, and possibly try and route external air cooling (or dare I say liquid cooling?) to them.


I’m going to buy an Ultimaker kit, wall it off, and stick a heat gun into it.

The bottom line is, if I were to start CADing immediately, it would be a parallel-gantry, dual Conjoined MK7 direct-on-gantry extruder, indirectly-heated bed and chamber machine that runs on RAMPS 1.4. And will probably be mostly black acrylic with 1/4″ and 1/8″ aluminum rigid machine structure inside. I’m not going to start designing right now, however – I want to get some of the parts in hand to measure up and confirm before moving on, and I also need to think of a snappier name that won’t make Bre Pettis go wtf bro.

What does the 3d printing universe think?

Also, at 3050 words, this is my longest post on the site ever…and I didn’t even build anything o_O


Nov 29, 2011 in Motor Controllers, Project Build Reports

First, if you’d like to see what the aftermath of a ducted fan nibbling on my arm is, here’s a picture. Be ware, it’s fairly bloody, so if you’re not the kind of person who regularly receives small injuries or who is into Internet gore, it would be better to pass  it up.

Anyways, it’s here! The updated Tinytroller signal board from a few posts ago has materialized from MyroPCB’s mysterious printing facility somewhere in northern Tajikistan, or so I believe.

Well gee, it looks the same as the previous panel. I’ve gotten into the habit of buying boards in quantities of 4 or 6, because Myro’s panelization fee is paltry and I just send the entire panel as one “part”. As long as it stays under 30 square inches for their entry-level service, I can has more boards. At the rate I’m killing Tinytrollers in beta, this is probably beneficial.

The board is actually a little different. While I only moved one resistor on the power board (circuit otherwise remaining the same), I’ve replaced the first iteration electrolytic logic power capacitors with all ceramics. This is partially an experiment – all ceramic buscaps can have extremely low ESRs, ESLs, and be more reliable (being solid state) than electrolytics. While it’s totally not warranted for a non-precision app like a motor controller, I did find a pile of 1210 package, 22uf 50v ceramics on eBay for cheap. This means the potential for 88uF native on the input, more if I abuse the footprint and use the caps sideways or just pile them on top of eachother. The output capacitance remains the same at 66uf (22uF, 16v ceramics in parallel).

I also shifted the signal board headers leftwards a few mils such that they actually clear the power input capacitors.

I spent the evening putting the boards together – these are the last six 3107s that I can just reach out and grab, so I hope this actually works. I’m also out of Arduino Nanos – more from the mysterious eBay electronics cloud are coming, but they’ll take a while.

The downside to a totally new board is totally new debugging cycles. I spent a while chasing down a dead short on the signal board. It was in fact so dead that it took jumping 5 amps around and feeling which traces heated up several times before I cornered it to a clearance-related issue which was literally right under my jumper wires…which explains why I ended up somehow pumping that much current through the “board” without doing damage – I might as well have twisted those wires together.

There is an area near the top row of headers where I grouped the 5v and GND lines together a little too closely (less than 3 mils) and it looks like Myro’s etchwork might not have sufficiently caught the gap.

It was dispatched with some knifework. The rest of the circuit seems to be unchanged and sound. I ran this board on the “sit and PWM into thin air” cycle for a few minutes to verify the gate drive and logic power operation – anything drawing more power than it should would be noticeably hot by the end.

Here it is… looks kind of the same as before, right? The little wire jump on the right is to make up for the fact that I had to cut the errant 5v trace.

There are some Arduino pin definitions that have changed on this board, but tomorrow I will re-upload the current control code and modify it to run on this version of the board. I should be able to read all three phase output voltages as well as the DC bus voltage. Then it’s one step LOTS OF SOFTWARE away from SENSORLESS TINYTROLLER!!!!

I’m thinking of putting this Tinytroller in melonscooter. Not only because I want to try running my own equipment for once, but because Tinytroller has demonstrated proficiency at variable regenerative braking with Straight RazEr, and it’s even survived the Radu Test, where Radu floors your creation around everywhere (it’s a rite of passage for MIT Random Small Vehicle Team creations). Melonscooter also has the capability of drawing far more amps, and the Turniby C80/100′s extremely low inductance and resistance means the current control has to be very robust.

Also, I’m fairly sure this thing can commutate faster than 550 Hz.




The Decommissioning of the Quadrotor Project

Nov 26, 2011 in Emergency Quadrotor, Project Build Reports

I bet everyone forgot about this thing!

I almost did, anyway. After the last test some time in July ended in one fan cracking its motor mount, fortunately not resulting in catastrophic failure, I lost my enthusiasm for flying objects and literally hid it under my cart of parts and stuff – as in, it fit perfectly between the wheels. I pledged that one day I will once again have a quadrotor boner and return to finish it off, since I did have a spare fan and all.

Well, I figured Thanksgiving weekend was as good as any. This year, MITERS seems to have accumulated a fair number of freshmen and newbies with quadrotors (and trirotors). The pressure was on to just finish it once and for all. It was a roughly 1 hour job to pull the damaged fan casing out and mount the spare, including printing a replacement tailcone.

noise isolation

During the testing of the Z-axis yaw rate control loop last time, I noticed a fair amount of mechanical noise coupling into the gyro readings. The gyros are mounted facing the same axis as the fans, almost in plane with them, and essentially on the end of a long carbon fiber stick. While the filtered readings were clean with stationary fans, they would become very erratic as soon as any power was applied. This was clearly visible in the test videos where the fans are jiggling quickly almost like they’re loose. The noise was of the same order of magnitude as the signal I was trying to get from the gyro – as a result, the filtering was not very effective. That was number one thing I was out to address before I moved onto the other axes of control.

I elected to remount the center Arduino Nano carrier board using memory foam – a tip I picked up from tricopter-nick, which is in fairly wide use.

With all 4 fans functional again, I was able to find out that the noise coupling was significantly lessened. It was still causing some trouble, but only when fan speeds were significantly higher than before – the “barely-touching-the-ground-hover” was mostly erratic jitter-free. Refactoring the yaw rate control code to not pre-scale the gyro readings also made the control less granular (and consequently even less shaky), and I also implemented a 2nd-order filter instead of a 1st-order. As a result, I was able to increase the loop PI gains by 2 times to yield a faster response to stick inputs. A little bit more driving on the ground like a doped-up robot on ice confirmed that the updates worked.

So now I was at the same external functionality I was 4 months ago. Yippee.

The only way I could get more data and test if the filtering and shock mount actually mattered was by continuing with the rest of the stability code.

how i killed the giant quadrotor

I hit the reset button on the Arduino. Actually, to be more specific, I left the controller calibration code in and then absentmindedly hit the reset button on the Arduino.

On occasion, I’d notice the fans peg off to one side and not respond to rudder stick inputs. They would some times recover again, but usually it required a power cycle to fix. I have a sneaking suspicion that my 2.4Ghz FHSS transmitter and the 2.4Ghz FHSS Xbee modules I had as a data link were Frequency Hopping over eachother’s Spread Spectrum at times.  Regardless, my usual rigorous procedure is to completely power down the electronics and then restart them.

The number one mistake was not commenting the calibration code out after the first time. After I temporarily decommissioned it the first time in july, I had “borrowed” one of the Turnigy 100A controllers for melonscooter. With melonscooter having moved onto greener melon vine patches,  I returned that controller to quadrotor duty, but it had to be recalibrated again.

The calibration procedure for these R/C controllers is full-stick within 1-2 seconds of powerup (2000uS pulse width), hold, then neutral stick (1000 or 1500uS, depending on your type of stick). This has to be done within 2 seconds of powerup, or else the ESC initializes and waits for command. The problem is when 2000uS is commanded after the ESC is already on and initialized, that means gun it.

For reasons I can only explain as “meh”, I elected after testing the yaw rate controller for the last time and seeing it lock up to just hit Reset on the Arduino to clear all the readings and start over, without powering down the ESCs. About 1 second after I did so, the stunning realization of idiocy hit me – along with the entire thing.

I only really remember leaping back as it flew upwards and sideways towards my head – keep in mind stabilization code wasn’t even written yet – and batting it out of the air with my left arm before ducking and turning around. It did a powered somersault over my head and crash-landed on top of a substantially more solid vehicle, and consequently shattered into many pieces.

It took me a second or two to realize what had happened, upon which I leapt for the big red key switches of main battery disconnection. The two remaining fans were still spinning – a consequence of me knocking over the radio – but luckily only slowly.

Pieces of fans were being collected from across the room afterwards – this destroyed rotor was found a few feet away with motor still attached.

I didn’t escape without damage. Batting the Deathcopter from the sky, I was grazed by what must have been a ducted fan leading edge:

In what is probably the luckiest near-miss I’ve ever been in, I’m only missing about 3 square inches of skin from my left forearm where the fan scraped it off. There’s 3 very evenly spaced cuts where I presume a rotor dinged me while disintegrating, but none were deep. Bleeding was slight, so the damage was cleaned, bandaged up, and ice-packed. It could have gone way more wrong in many possible alternate scenarios.  I’m still periodically testing my left hand fingers and wrist for full motion just in case.

What’s the lesson for other quadrotor builders who use RC controllers?

Well, besides don’t be a total dumbass and violate your own safety procedure,

calibrate the motor controllers once and cross it out of your code after.

This accident was totally avoidable if I wasn’t trying to rush to get to writing the stability controller.

Nevertheless, with 2 fans completely destroyed and the other two now in unknown condition possibly with structural damage, and the frame in many pieces, I think this project is done. Maybe I will instead concentrate on other flying things, or maybe I’ll build a more normal quadrotor or a tiny and cute one I can swat without worry.

Tinytroller Trolls Straight RazEr

Nov 24, 2011 in Motor Controllers, Project Build Reports, Straight RazEr

Last time, Tinytroller was trolling Straight RazEr already, but it still had the occasional strange phase latchup issue. Well, I swapped Arduino Nanos, and it turns out the other one just has a damaged pin or has mild Turet’s or something.

So now it works great. With the current sensor bandwidth increased to the 800 Hz it should be at, the throttle nonlinearity dubbed “turbo lag” has been eliminated, at least for this drivetrain. Time for video!

While you can’t really observe a speed controller working (it’s in the same vein as watching epoxy set and batteries charge), the difference between current limits is clearly obvious using a standstill-launched Straight RazEr. In the video, the hardware current limit (the point at which the sensors peg on either voltage rail) was made to be 60 amps, and tests were performed at 10, 20, 40, and 60 amps. Motor phase amps were controlled to be around those values at all times, and I set the throttle mechanical zero position to induce a little bit of drag braking so I wouldn’t splat too hard on the far wall.

40 and 60 amps looked very similar, mostly because I had to begin braking almost immediately to avoid planting into the wall. I’d really need a larger hallway for a more conclusive test. When everything is properly working, it seems like 60 amps is no problem for this board. There were no observed noise effects or aberrant resetting instances. The current sensors can only be bridged so many times with low-ohm precision resistors, and I think at currents higher than this the traces might begin to blow up again.

The only thing I can do now is wait for the new board and see if it’s still as good.

On a side note, RazEr rEVolution and Straight RazEr are almost equal in a drag race, with Straight RazEr taking a slight lead. This I did not know until I had 2 working scooters, and it also comforts me to know that RREV’s hub motor is brütally oversized. I never measured the output of RREV’s chopped Jasontroller, but ballparking it by equivalent torques (for roughly equivalent accelerations) it has to be in the neighborhood of 50 or 60 amps peak.


TinyTroller: It’s Still Trolling!

Nov 23, 2011 in Motor Controllers, Project Build Reports

Poor Tinytroller.

No, I haven’t killed it againyet. After completing and testing a third full board, I decided to proceed immediately to vehicle testing. This time, I included all the anti-noise hacks from the very beginning, and also increased the gate resistance to 40 ohms from 30. It means I should probably stop investing big money into 2 amp gate drivers, since they’re definitely not being used to capacity now (the alternative is, of course, to design a bigger power stage to match).

The vehicle of choice is the slightly neutered Straight RazEr.  Straight RazEr has sort of become a testbed for bad ideas; for a brief period, I converted its existing battery to 6S4P (from 12S2P) to try out the Hobbyking cartroller, and it was actually used day to day. Because the Cartrollers have no current limiting whatsoever, I replaced the stock “short melon” Turnigy C80/85 motor with a rewound one from the original Landbearshark drive pod. The rewound short melon has a torque constant roughly 3 times higher (correspondingly, a Kv 3 times less) due to being rewound with twice the turn count per tooth and re-terminated in Y instead of Delta. The increased core inductance and resistance made for a more friendly controller test platform.  It was still capable of pulling a few thousand watts, though. The problem was that the original sensors I installed turned out to be very poorly timed, probably from me just stuffing them recklessly into the slots. If I wanted to use Straight RazEr as a test platform, I needed to move the sensors outside the motor in a manner that I could adjust and optimize their timing.

Fortunately, Straight RazEr’s frame had a useful cutout section next to the motor that I could clip a set of sensors on. I designed a mount for 3 Hall sensors that would latch on to a .25″ thick frame member, and stared at Make-a-Bot long enough for it to finish:


It’s not a Fancy Routed Sensor Board, but it holds 3 of them in the correct mechanical alignment of 17.14 degrees for a 14-magnet, 3 phase motor.

It literally clips on to the circular cutout section part of the frame and is retained solely by friction, which is fine since it doesn’t weigh very much and there is indeed alot of friction. During the initial “run-in” test with this board, I was actually tapping on the mount with a hammer to get it to move along the frame.

For the first time, I elected to mount Tinytroller properly like it was designed to be. I lined the bottom of the power board in some 0.5mm silicone padding, and made a quick rectangle of 1/8″ aluminum to space the edges of the board up. The whole assembly was then screwed to the underside of the 1/8″ aluminum top plate. So there should be no heat problems if Tinytroller is working correctly!

The first run was on a power supply in case the sensors were so far out of tune that it would just try to draw All the Amps (up to IMAX, of course). The test was mostly conclusive, but it revealed a very strange problem that did not come up earlier. Occasionally, the motor would ‘latch up’ into one state, and any attempts to move it physically were met with opposing torque. The controller would also seemingly run the motor, but it ran very rockily and draw huge pulses of current. I figured it was one of the current sensors giving bad data (causing the state table sequenced current reading to be garbage). After replacing both current sensors (goodbye, $8!), the problem still did not go away. More investigation discovered that some times, phase C’s gate drive did not shut down when commanded – meaning phase C was always active, whether high or low. Hence, the motor “preferred” a state where phase C was low since the bootstrapped high sides would eventually turn off.

Even stranger was its tendency to disappear and reappear with power cycles, and even just letting go of the throttle and then commanding it again. I replaced the IR21844 on phase C, but the problem was still occasionally coming back – so now I’m thinking logic instability, or half-dead Arduino. This Arduino Nano has been through a whole lot.

Since I figured that Tinytroller would explode or require servicing very soon, I didn’t bother installing the bottom plate onto SR, and instead just duct taped everything in. New in this pile of wires is a 40 amp fuse and holder – with the maximum current dictated by the sensors to be 40 amps, it shouldn’t ever need more…. right? I also put the battery back together in series (42 volts) for this test.

The results were semi-conclusive. When Tinytroller wasn’t spasming due to phase C’s instability and latching up, its 15v switching regulator was doing so. For some reason, immediately after power on or after a “latchup”, the 15v regulator would start buzzing at audible frequencies and its output voltage would drop to under 7 volts. For a regulator that is supposed to switch at 150kHz, being able to hear it means something has gone horribly wrong. Because 7 volts is well under the IR21844′s cutoff voltage, the effect is that the controller just “turns off”. It seemed unable to reset itself from this condition, but some times after a power cycle the problem would disappear, only to spontaneously reappear.

Having seen this issue once before, Shane immediately deduced that inrush current (from dumping the 40 volt battery onto the controller instantly, as SR has no precharge circuitry) could be causing the LM2594 to freak out. It’s probably reasonable to expect that a sudden step in voltage from 0 to 40 volts, with its associated ringing and overshoot, could put the regulator in an unknown state. Given that the “ON/OFF” pin is just shunted to be on at all times, I suppose it’s also not unreasonable for it to not be able to correct itself. Corroborating this explanation was that two successive fast power cycles usually solved the problem.

I decided to give the logic power a little bit of “rise time” on its input by inserting a resistor in series with the diode feeding the input capacitor. The resistor is 68 ohms, a value that I bought thinking I might need it one day for gate drive. With the 100uF input capacitor, the 10-90% rise time is about 10 milliseconds. The average DC current draw of the 15v side is low enough to keep the power dissipation reasonable, and I only lose about 3 volts to the resistor.

Gee, putting resistors in series with my regulators. It’s like I’m being forced back into the days of chained-resistor-linear-regulators like the Melontrollers or something. Afterwards, Straight RazEr was taken up and down the Halls of MITERS a few times, and I even tried a few full throttle launches to try and induce more failures, but to no avail.

I have yet to observe a single 15v regulator latchup since adding the resistor in, so I might make it a permanent feature of the board design… or search for proper inrush limiters in a compatible package, as it’s rather unsustainable to keep a fixed value resistor there in case I ever add more things to the 15v bus. I only saw the phase C latchup weirdness once during bench testing after adding the resistor, but never during on-the-ground testing.  It literally could be a flaky ATMega pin on the Arduino board causing the Phase C problem. The only question left for me is to find out whether or not any of these problems carry over to the revised board. I’m fine with the only board hack on this design being “add a resistor to the regulator input”, but I think I’ll hold off on adjusting other parameters until I have a version of the new board together.

There is another thing I will change, however. Tinytroller has an interesting nonlinearity, dubbed “turbo lag”, which causes the current command to rise quickly as motor speed increases. This was amusing to see on Straight RazEr since it produced what felt like quadratic throttle. The reason for this is that my current sensor filters, both hardware (input to the Arduino) and software (the I_RC variable and associated code) are very slow. I designed them originally to filter the PWM frequency, which was 4kHz when most of the circuit schematic was drawn, and I merely copied and pasted it over. The hardware filters were designed with a 400 Hz break frequency in mind, one decade under (or 1/10ths) the PWM frequency.

Well, first off, I’m using 8kHz PWM, but the real problem is that I did the EE n00b thing where I was designing towards 400Hz as if it were 400 rad/s. So my actual current sensor bandwidth is something like 80Hz, a number easily reached by even the modified Melon at low speed: 80 electrical Hz = about 11 mechanical Hz, or something like 660 RPM. Near and beyond this speed, the magnitude of the current reading drops off quickly, which leads to the sudden increase in command in order to “keep up”. Luckily, 1/10ths of 8kHz in rad/s is about 5000, so I just need to change my filter resistors from 10K to 1K. We’ll see if that results in some more linearity.

On the other hand, I kind of like the turbo lag effect.