Archive for December, 2011


In the Interest of Future Flying Objects: XBypass

Dec 30, 2011 in Ballcopter, Emergency Quadrotor, Project Build Reports, Reference Posts

Despite losing the Spruce Goose of Quadrotors to an unfortunate semi-controlled flight into terrain where I was the terrain (from which I’m still recovering… the square area of skin has recovered by more than 75%), I haven’t quite given up on the prospect of building a flying thing yet – but for now, they will be smaller and more easily batted from the sky. For instance, I’ve figured out why Ballcopter never worked properly. The very last update left it in a state of limbo, which I can sum up in one sentence: No, it didn’t work, but more on that later.

Eventually, Ballcopter was scrapped as its foam structure was slowly eroded away by virtue of existing in MITERS.

But there will be a day.

In the mean time, I wanted to satisfy one of my persistent self-stabilizing-flying-thing itches: how to pass control inputs from a handheld  radio to the flying thing in question without having it process several consecutive servo pulse lengths. For the most common & simplest Arduino-compatible balancing algorithms, this limits the maximum control update frequency to 50hz, since the microcontroller has to actually measure 10 milliseconds of pulse commands (for, say, up to 5 or 6 channels) out of every 20 milliseconds. The remaining time is often taken up by software floating point multiplication and division.

The reason it takes so much of the loop time is because the abomination that is Arduino’s pulseIn() command. It’s a “busy wait” loop that sits and increments a counter while the pulse is being detected. It’s neither interrupt based nor uses the hardware timers (the loop is timed empirically). So while taking in a servo pulsewidth, the microcontroller can literally do nothing else. A little inefficient, in my mind.

More sophisticated ATmega based flight controllers like the Ardupilot use the chip’s hardware timers and internally generated interrupts. For instance, as far as I can tell in the Ardupilot, Timer 1 is constantly running (counting) and overflowing (resetting to count more), and pin change interrupts on the input pins are used to capture snapshots of the counter status, and the resultant pulse width is just the difference between the values when the pin changed from low to high (pulse started) and from high to low again (pulse ended). And if the counter overflowed while the pulse was high, no problem: just add the max possible value of the counter to the pulse width variable and keep counting. Yes, I spent a few hours reading Ardupilot source code to figure that out.

And no, I’m not going to steal it and use it, because it’s written all in straight Atmel C, and so it might as well be gibberish to me. I can read and  understand it, but hell if I’m going to write it.

One method around the onboard servo processing problem is completely bypassing hobby radios as an interface medium, which people often do with joysticks (with or without tethering to a computer). For example, there is the Arbotix Commander, which is essentially an XBee and Arduino in a completely unergonomic, overpriced package which seems to have functionality problems based on a few reports from my peers – I had the displeasure of dealing with the first version personally. Shane tethers his USB Playstation controller to a laptop, but that means the laptop has to be deployed whenever something has to be operated (The upside is infinite debugging and telemetry ability, which a plain R/C radio doesn’t give you).

So really what I would like is the ability to replace the transmitter-air-receiver-servo_pulses interface with something much more direct – like serial over wireless; something that just takes the transmitter inputs and pipes them directly to my vehicle, where it can be buffered and read at will. XBees make the serial over wireless problem very easy to solve. The result would be an XBee using a cheap R/C radio as a brainless “trainer box”: most radios have a “trainer port” over which servo pulses can be sent (over a cable) to a master radio, for situations like when you’re actually training someone who is utterly clueless about flying things (me) and want to take command of the vehicle if anything bad should happen. If this pulsetrain is read and parsed at the transmitter, then I effectively offload the overhead of processing servo pulses from the vehicle – allowing it to process much faster (hundreds or thousands of Hz) and making closed loop control less granular. My inputs would still be updated at 50hz, of course, but I doubt I can react to an event as fast as 0.02 seconds anyway. The vehicle can keep itself stable much faster.

Anyways, that’s exactly what I built. An Arduino Nano, reading the pulsetrain from a transmitter trainer port, and piping the read values as bytes over to an XBee.

It’s not nearly as epic as I made it seem to be, seriously.

I have two cheap 2.4ghz transmitters, one of which I got ages ago for Cold Arbor, and another one I picked up over the summer for Ballcopter. Which really means I have 2 of the same radio. They are both made by FlySky, but the right one is a Hobbyking rebadge. These things cost $28 brand new, with receiver, and some of the consequences of that cheapness show through – for instance, they don’t come with external servo reversing switches like every other radio, but the holes and pads are present internally to use them and if you mount your own switches the functionality is even there in the microcontroller, but no we will absolutely not spent 20 more cents to install those damned switches.  They have a 4-pin mini-DIN (also known as S-Video) connector on the back which is a trainer port.  And as usual with small Chinese gadgets, there is a community devoted to hacking them. It took me all of 10 seconds of Googling to find the pinout of that trainer port.

A little scope probing of pin 1:

The PPM pulsetrain

And zoomed in further.

The biggest difference between this “PPM” signal and the servo-style “PWM” (which isn’t even “PWM” but pulse-duration modulation… which collection of idiots agreed on these terms?) is that

  • It is falling edge driven – the time between falling edges of the square wave is actually the duration of the “PWM” pulse. When the receiver detects one of these falling edges, it will stop outputting the pulse on one channel and immediately start it on the next.
  • As a result, the actual “High” time of the pulse only goes between approx. 600 to 1600 microseconds on my radio
  • The low time is fixed duration at 400us. Makes sense – the minimum pulse lengths on the servo side, then is roughly 1000 to 2000us as it should be.
  • It “idles high” – meaning the gap between signal is +5v.

So I’d have to come up with a way to distinguish a signal pulse from the long idle pulse. Arduino’s pulseIn() doesn’t even allow in-pulse timeouts. It allows pre-detection timeouts, so you don’t wait forever for a pulse if it never comes, but it does not have “hey, this pulse is over the length I care about… let’s move on with life”. I’d have to get around this by throwing away the first update and “syncing” to the rest of the pulses, since I know how many there are and about how long they should be.

The first step of the hardware hacking was disabling the internal radio. As I found out while building the Deathcopter, 2.4ghz radios will tend to step on eachother. I didn’t want to permanently take this radio module out, however. Leaving myself the chance to return this radio to ‘normal’ duty if I ever figured out something better, I just added a pin header connection to the power supply wire. It would be left disconnected when I’m using my hack.

Next was throwing the hardware together on a perfboard. This little arrangement costs way more than the transmitter ($17-34 for an Arduino Nano and $22-25 for an XBee regular 1mW), so I really hope this isn’t the terminal solution. It’s also way underutilizing the Arduino right now, since I only have Tx and Rx pins connected, and one other digital pin hooked up to the PPM output. The transmitter provides 5 volts from the trainer port, so this board has no other power supply.

The XBee is mounted on an Adafruit XBee Adapter.

And that’s it.

Yeah, I didn’t even bother trying to source a 4-miniDIN for this. At least, not until my Digikey order arrives – until then, it’s wires jammed into sockets.

I took a few minutes hours to write the single pin read, serial write software for the Nano. The hard part was, again, thinking my code does one thing but really having it do something different – just logic errors, all caused by having to differentiate the long idle pulse from the servo pulses. But at the end of it:

There we go. I’m only piping back 5 channels out of 6 here, but this was successfully done over the air between 2 XBees. This is all done using Serial.print(), which converts everything to ASCII and thus has unnecessary overhead. When commanding a vehicle, I’d just send the raw byte values because I’m fairly sure my vehicles are not literate.

So how do I test this contraption? With someone elses’s flying object, of course.

4pcb became the subject of a few transmission tests and a whole lot of floor whomping, as seen in the test video:

While not the most economical option, it does work, and it does solve the problem I wanted to solve. I’ll probably look to refine this board or permanently mounting it inside the transmitter, possibly with a plain ATmega chip by itself so I at least don’t have to buy even more Arduini. Otherwise, creating a dongle using Arduino USB host shields and an XBee would open the floor up to using just about any gamepad or joystick as a remote.

The “XBypass” sketche as used on 4pcb is here. The general idea was to wait for the first time the 9ms long timing pulse was received, then immediately start taking in n channels, storing them, and then processing them into single-byte values (for transmission convenience as well as because 4pcb takes such single byte commands).

Hub Motors on Everything, Part V: Hub Motors on Even More Things

Dec 29, 2011 in Project Build Reports, Stuff

A month ago, I received 12 skatemotor-sized motor cans that I had commissioned through by a semirandom Chinese machine shop. It was mostly an excercise of curiosity, but with 12 motor cans and no other motor parts, I decided to keep going with it – I went back to the semirandom Chinese machine shop and had them fabricate 12 sets of skatemotor parts: both endcaps, the center shaft, and the big ring nut thing that mounts the wheel.

That’s alot of little aluminum bits. What I have now learned is that someone else will actually hold the tolerances I indicate on my drawings, whereas I usually would just ignore them. The result is that the endcaps fit very tightly in the can (one is supposed to be looser) and the shaft-bearing fit is also a little tight, but it’s within sandpapering reach, not second lathe operations. The next time I do this, I have to specify a different tolerance band… though for now I do not mind making a single lathe pass and freeing up said endcap, or heating up the bearing and freezing the shaft for a real bearing fit.

Before I sent the dimensioned drawings off for quoting, I did a little re-engineering of the motor in the interest of easier assembly.

The shaft was remade as a straight pass-through, single-diameter part with key slot to clear wires. I actually designed it to mimic a 15mm metric keyed shaft such that it can form the starting stock, and the only operations done to it would be drilling and grooving.

Otherwise, the method of axial alignment has now switched to retaining rings. Yes, I know – snap rings are terrible, and I hated them the most when I was younger and eagerly disassembling appliances which always seemed to use them and I had no retaining ring pliers to cleanly remove them with and and… well, normal circular snap rings didn’t fit in this design anyway. I designed in two “low clearance” retaining rings (e.g. McMaster 97414A670) on each side of the stator. The inner ones keep the stator aligned, and the outer ones both space the bearings out and act as a restraint to prevent wire insulation from grinding on the bearings. I think this is a nice and simple system that is easy to assemble.

The stator is still a 50mm copier stator mounted on a custom 3d printed adapter hub -  there is no more “stator bore” shoulder on the shaft. I did try getting quotes for fully custom punched and stacked laminations designed to a slightly different geometry with thicker teeth to maximize torque production, but it would have cost way more than I wanted to spend (or had) – $1200 for tooling alone. While the stators would be cheaper per unit afterwards,  I think my best bet is still to find a supplier of completed (and epoxy coated) stators. The problem is that most places want minimum orders of 1000 or 10000 – small quantities for this kind of value added item is always difficult, and even if they cost a dollar each after that I still can’t dump that much.

The endcaps also got a little fatter. To fit the extra width of the retaining ring and wire-clearing gap and to give myself more room to put windings, I pushed out the interior width by 6 millimeters, necessitating protruding the endcaps out on each side. This makes the motors 42mm wide – while that’s just as wide as the old version 3 RazEr wheelmotor upon which this design is based, it does make them incompatible with the existing RazErBlades frame.

Gee, my stuff is always so much shinier when someone else makes it. Here, I’ve arbor pressed the static endcap into the can and pressed bearings into both. The bearing bore is actually a somewhat tight slip fit – again, another fiddle factor to adjust – so I dropped them in with a dose of 609 Loctite.

I have 2 sets of custom curved magnets remaining from the ‘blades project which didn’t see use in the final vehicle because I ran against a deadline. This set installed perfectly – the final one was a not-too-tight press fit into the bore, so this set doesn’t even need any glue to hold it in. However, it IS a little close for my comfort – there’s no guarantee this diameter will be the same across all the cans; so again, a dimension to change very slightly (on the order of 0.03-0.05mm or less).

I only have 1 50mm stator (the one shown), so either I’m gonna need to buy some more copier motors, ravage some more recycled office equipment, or find a source for them Yo Real Quick. I’m not keen on selling them to strangers over the internet just yet due to these sourcing issues, but it’s either that or build infinite hub motor powered vehicles…

I Swear I’m Still Working On This Thing

Dec 24, 2011 in Project Build Reports, The Next 3D Printer

Seriously! I promise I will poop out a new 3D printer by the end of IAP. Now that the holidays break is in full swing and everyone else is gone, I can focus on actually finishing up the design, rather than, say, be constant distracted by things happening at MITERS. I pushed out several orders for materials (including something like 30 square feet of acrylic sheets) and more mechanical parts before the Christmas Everything Shutdown, so hopefully I’ll have all materials in hand come January.

In the mean time, here’s another week or so of on and off work, including testing of the space heater platform and design of the XY gantry head. First, some more waterjetting which was not covered in the last episode.

I think I have made my first impossible-to-cut part. The heater grille has so many little things that can possible stick up into the machine path that, even with careful manual routing, I was unable to avoid interference accidents. And no, it does not have a powered Z axis so I can do head-lift traverses. I’m not that spoiled yet.

After writing off this piece, I tried again, but this time routing the machine to cut out everything but the little grille bits, then doing those last. That way, I can still have consistent mounting dimensions – who cares if the grilly bits are misaligned slightly? To make sure the piece didn’t float away after the separating cut, I inserted small tabs periodically to hold it in place:

I used a chisel and hammer to shear off the small tabs to separate the part. As can be seen, there was one bangup regardless, and there are parts of the resistor mounting holes which come close to the material edge as a result.

Oh well.

The proper method would have been to individually tab each one of those vents, and to manually route the path to start and stop on those tab cuts to minimize nozzle cycling. I wasn’t that patient.

0.22 ohm resistors mounted with a bit of thermal paste. I found out that no bolt head in existence fits in the little mounting tab given, so I had to drill out all of those mounting holes and actually tap the resistor’s aluminum body with M3 threads. They seem to work fine.

I actually bought one of those huge case fans seen in the Z platform models from xoxide. Actually no – I got 2, one to mess with and one to actually use, as per standard operating procedure. They move reasonable amounts of air for their size and low speed, and are indeed very quiet. The actual fan diameter is about 220mm – I found out which dimension is actually 250mm on these things, and the answer is the corner to corner measurement on the outside of the mounting tabs. Failsauce noodles.

Check out the new platform on top of MaB. This thing is going to be enormous – the standoffs mark the bounds of the build plate, which will be 250 x 250mm.

The big question after putting together the platform with wired resistors is whether or not it would dissipate the watts needed to bring the internals of the machine up to a high temperature. Fanning the resistors at room temperature showed that the 1.76 ohm arrangement (8 0.22 ohm resistors in series) isn’t very powerful at all. It draws about 80 watts, but it’s difficult to feel warm air even an inch away. Probably because the resistors are very, very well heatsunk and I just installed the sexually dimorphic father of all computer fans (this is the larger female of the species)

But future-MaB wasn’t going to be heating things up at room temperature – it’s going inside a box. For true thermal testing, I needed a box.

In this picture: a box

Conveniently enough, a box of essentially the right size was standing by.

I commandeered this early prototype of an arduino vending machine project by a certain Nancy (who is currently stomping it out in Asia – make sure to keep up with her blorg). It’s made of cardboard and very much glued and taped together. But hey, that’s all I need.

I actually love this form factor, by the way, so don’t be surprised if I just end up gluing everything to the inside of this

I stuck the platform on some big aluminum standoffs, hooked it up to 12 volts (uncompensated – I wanted a realistic simulation of losses in the wires), and closed the box up.

On the as-designed 80-watt setting, it was horrible. I think the temperature barely crested 40 celsius after 10 minutes, which is my benchmark for acceptable bootup time due to current MaB’s giant resistor board. Probably because the cardboard box leaks air everywhere and isn’t a good thermal insulator alone.  Sadly, I could not locate an IR thermometer (or even one of those stupid things you mount on your window… sadness), so the estimate is very much biased by my hand waving around in air, which given that I regularly act as my own soldering fixture, might be miscalibrated.

I went on Digikey and Mouser to see what the next value smaller resistor was available. I only have 8 mounting points, so I’d have to come up with a reasonable solution which was not just paralleling four resistors on each side of the board – that drew like 30 amps and was kind of insane. By going to 0.1 ohm resistors, I could get a power dissipation of roughly 180 watts.

The next step was to just pump up the power supply to 180 watts. When you’re just dumping into resistors, watts is watts, so the final setting turned out to be approximately 17.5 volts at the heater (the alligator clips eating like 2 volts on top) and 10 amps. This time, the results were much more promising. It certainly reminded me of the inside of a commercial printer, but again, without an IR or traditional thermometer, it’s hard to judge. I would estimate that it was over 60 celsius, but not with certainty.  I thought about hijacking MaB’s platform heater thermistor for a moment in order to get a good air temperature reading, but it was a little more work than I wanted to deal with at the moment.

The good news is that the shady case fan worked fine in the higher temperature environment.

My resistors are delayed due to the holiday break, but once MIT opens again briefly next week I should be able to get more testing done (as well as pick up a reasonable thermometer from somewhere)

a bit more design

I’ve been really lagging on the actual machine design this time, something which I took the past 3 days or so to address. The reason it took so long was because I’m a grad student that I… you know what, fine. I admit it. I’m a grad student. I spent more time thinking about different ways to design it rather than just merrily beasting along. Starting the first part file is always the hardest part of designing something entirely new, because you have to select yourself a ground point for the whole thing. At this point in the design, I was just aiming to have some kind of parallel gantry to stick Tinystruder to – dimensional adjustments and remodeling can come after I get a good look at everything.

Here’s some of the “mechanical penthouse” solid geometry. I picked an arbitrary square size – in this case, 400mm, selected for me by the fact that McMaster sells 400mm long shafting. The pulleys were selected from B&B Manufacturing and SDP-SI (who seem to gun for eachother and have “competitor” part cross references that are exactly eachothers’ part numbers) based on both price and diameter – the pulley diameter determines how far offset the X and Y rods have to be. This part was relatively simple.

What wasn’t as simple was designing the axis anchor blocks. Above is the most elaborately t-nutted thing I’ve ever designed…but it sucks. It requires 4 unique parts to be cut, and a cube only has 6 sides. When you have a waterjet, everything looks t-nuttable.

But what was important was that designing this thing gave me the critical dimensioned I needed for the part. After that, I could quickly whip up a better designed replacement:

Some times, thinking outside the box isn’t the right approach – the box must be thought about from a different axis. This axis anchor design is much better executed, requires fewer unique parts, and is fully constrained by 4 corner bolts. It even has provisions for a real belt-clippy-thing on the bottom (one axis runs the blocks inverted for clearance, so the thing on the left is still “Bottom”). It’s also smaller.

I legitimately thought about just machining a block of aluminum for this – the whole assembly can be replaced with a small cube that has two holes in it. One to hold the linear bearing, the other to hold the cross rod. But that wouldn’t be in the spirit of things, now would it?

The general idea explored in the anchor blocks was applied to the head mount. Because my cross rods don’t start in the same plane as my axis guide rods (unlike, say the Ultimaker), the end effector is a little tall. The rod separation is 40mm. There was no particular reason why I made the rods offset instead of in plane – it was just the first thing which came to mind.

And possibly because skew-offset rods are easier to install, and that further-spaced supports for the massive steel and aluminum testicle that is Tinystruder means more torsional stiffness along the axes.

Because Tinystruder sticks out more one way than the other, the gantry can’t be perfectly centered upon the build plate. This is a composite image of the maximum positions that Tinystruder can travel to at the moment, centered upon the build plate i.e. able to hit all corners. However, this puts the Z-axis in a slightly inconvenient position (halfway hanging out of the square base), so I might have to extend the platform arms even more to compensate for it. Or adjust some other dimension, or make the build volume rectangular, etc.

Now that the hard part of the machine design (in my opinion) is done, I hope there’s nothing to distract me in the near future so I can finish it off.


A Bunch of Waterjetted Things

Dec 17, 2011 in Project Build Reports, RazEr rEVolution, The Next 3D Printer

Quick update on a few things as I manage to momentarily surface from intensive planning and building for next year’s 2.007 contest – which, given the whole point of the thing is to issue a challenge to students, I’m actually going to not say anything about until the spring semester begins in February. I promise it will be either a riot, a circus, or a shitshow… possibly some combination of the three.

I got a chance to finally cut out Tinystruder’s structure:

I found enough useful scrap plate to make 2 Tinystruders’ worth of structure. However, the second faceplate didn’t cut correctly since it turned out to be routed over a missing chunk of the scrap… oops.

All of the hardware that I need to finish Tinystruder has arrived from McMaster and others, including the tiny 693 bearings and the correct tube fittings that have a normal 10-32 thread on the end instead of some weird tapered NPT bullshit.

Also, steppers! I got the Polo(lololololololololo)lu 35 x 28mm steppers – they’re a bit shorter than I expected, but I most likely had the 35 x 36 size in mind. If they can crank the filament, then all is good. For convenience, I also got one of the Allegro A4988 driver chip breakout boards, which is incidently the same type that the Reprap RAMPS boards use as axis drivers.

I received my order from Makerbot that consisted of the custom 0.4mm nozzle (boy is it tiny) and the drive rollers. I also purchased one roll of 1.75mm ABS on a reel from, which seems to be about the sketchiest place you can possibly get plastic filament from since there’s no business information, contact information, shipping information past a flat charge, etc… which would help you distinguish a legitimate vendor from some shady Eastern European place that steals your credit card information to fund organized crime. Well, I’m so far glad to say that the place is legitimate, and way cheaper than most 3d printer supply sites.

The only ingredient I’m now missing in this whole affair is the pair of cartridge heaters which Makerbot is still out of stock on – and nobody else seems to make 12 volt cartridge heaters.

No problem, I simply ordered some heaters of the same size (1/4″ diameter x 1″ long) off eBay, where they’re like 8 bucks each. Downside? They operate at 120 or 240 volts. I got a 120 volt variety and plan to just plug it into the wall through a variac for testing purposes. Not very scientific, but who cares? It either melts and extrudes or it doesn’t – I’m fairly confident those smaller steppers can crank the filament at 230 to 240 deg C.

scooter utensils

While I maintain that 3d printed scooter wheel forks are totally fine for average use – both RazErs use a 3d printed fork and fly over railroad crossings, cobblestone, and those blind people curb things with no problem – they are definitely less durable than equivalent metal ones. Case in point, I managed to totally shatter RRev’s fork by trying to mount a rough step curb cut. I totally forgot that I wasn’t on melon-scooter (which can handle a 1″ curb just fine, with its giant regularly-underinflated pneumatic tires), and the next thing I knew, I was riding on top of the front wheel.


With Make-a-Bot out of 3mm ABS filament, it was time to retire the printed fork and just make something metal. Of course I elect to take the utterly lazy bum way out instead of making all of, or even part of, the scooter fork from machined aluminum stock.


Maybe I should have added more t-nuts. But, the majority of the loads that this will see are upwards from the ends of the fork, supported by the Razor A2/3′s rubber block thing. Rearward bending moments are transferred into the steering fork through the crossing piece in the back.

These were last-minute shoehorned into the same batch that Tinystruder parts were being cut on.

I have yet to make the little spacers – this assembly was mostly forgotten in the rush of MEETERS. I’ll finish it off tomorrow and try it out on RazEr rEVolution – if it’s workable, I’ll probably make a pile in varying widths for future scooters.



Dec 13, 2011 in Melon-scooter, Motor Controllers, Project Build Reports, The Next 3D Printer

In the spirit of eventually working towards running in-house developed equipment on all of my vehicles , I decided to man up and finally pitch Tinytroller at the final boss fight of scooter controllers: controlling the Turnigy C80/100 “melon” motor that runs melon-scooter.

Melon-scooter has been out of service for about a week and a half – the chopped Jasontroller worked extremely well until I let it out of my sight one Friday night at MITERS when a bunch of freshmen and new members were in attendance. When I attempted to leave later, I found that the motor was shorted through the controller and there was no response from it when powered on. And of course the froshlings had all quietly left by then, with nobody telling me that my scooter was behaving a little strangely and not like… going and stuff.


Anyways, I’ve found derpybike to be quite useful in the mean time. Since the failure was totally not under my control, I can’t quite tell what went wrong. When I opened the case of that controller, nothing appeared to be burnt or detonated, but some FETs are most definitely shorted through and the drive circuitry is dead. I’ll probably just order up another Jasontroller (or use one of those 500W bricks?).

The C80-100 is a pretty formidable control challenge for a homebrew motor driver because it has both very low resistance and very low inductance. I measured the line to line resistance to be around 20 milliohms – meaning any little twitch or fuckup by Tinytroller can send pulses of hundreds of amps through the system. The low inductance means the current through the stator cannot be modeled as approximately constant, especially at my relatively low (8khz) PWM frequency, wreaking havoc with non-robust current controllers. It’s built similarly to many other huge electric flight motors, so if I can control the Melon, I can probably take on other scarier airplane motors too.

Melon-scooter normally runs sensorless since I originally built it with a Hobbyking 100A airplane ESC, then subsequently a sensorless Jasontroller. To use it with Tinytroller (which is not yet sensorless), I had to append sensors in a similar fashion to Straight RazEr. It’s that red thing by the motor:

I bodged together Make-a-Bot’s heater one more time (last time, I swear!) and used the last 2 feet of my 3mm ABS filament to make this sensor mount. Unlike Straight RazEr’s mount, this is a two-piece since I needed to fit it into the very close gap between the motor and my frame.

Like so. Unfortunately I made this one a little too close – the ABS plastic actually rubs alot on the motor. It doesn’t seem to be affecting sensor operation, but it just makes an ugly scratchy sound. Oh well – it will have to do for now.

The first test was performed on 24 volts so I could (more) safely full throttle the motor in order to time the sensors properly. For a while, I was trying to find the absolute minimum point of phase current draw at no load, full speed, which corresponded to the point of optimal sensor timing. Wandering even a little outside this region caused the current to increase very quickly, some times up to 40+ amps no load… that’s 1000 watts dumping into the motor just spinning while sitting there. However, Tinytroller handled the mis-timed excessive current draw just fine – no fiery death like I expected.

I was able to get the motor current down to 7.5-8 amps no load, where it has generally been.

I did still have plenty of PLA plastic left, and I was going to print out a Nice Case for Tinytroller that enveloped the whole thing and had custom wire entrance and exit holes and whatnot, but decided PET film tape was enough for now. I made a little greenhouse (literally?) for Tinytroller which should keep most of the gunk out of it.

Plus, I figured it was going to explode anyway, so why waste time on a nice case?

All bundled up and connected.

I tried something a little different with this attempt at running melon-scooter. While Straight RazEr’s control scheme relied on a single throttle, with the bottom (released position) being a slight brake (negative current), neutral coast somewhere in the middle, and the top being full driving current, I put a handlebar throttle next to the thumb throttle on melon scooter and had Tinytroller read both.

The handlebar throttle controlled the amount of driving current and the thumb throttle controlled the variable regenerative braking. When neither was actuated, neutral coast (zero current) was commanded. Actuating one blocks out the reading of the other such that the readings don’t conflict and sum to a net zero, though that itself is a valid control scheme too.

After making sure it did indeed survive a no-load spin on the 12S battery pack, I threw the deck back on and went for a test ride. If it was going to explode, it might as well do it while the motor is running full bore on 40 volts. The no-load speed was measured to be 4330 RPM, a fair amount slower than even the Jasontroller’s 4700 RPMs. It could be attributed to sensored control with the sensors at the point of zero timing advance (sensorless will always tend to be faster) or it could be my battery being low after not being charged for a week.

The low speed terrible sound was still present – and boy was it ever noticeable on the melon. The “terrible sound” is a bug feature that has been with Tinytroller ever since I added the timer interrupt routine. It can be clearly heard as a clacking sound at very low speeds in the etek test video. I’m completely unsure as to where it comes from, and I can shift the Band of Terrible Sound up and down in the PWM output range if I add various length delays to the interrupt service routine & state changer. This just tells me my timers (1 and 2 on the ATmega) must be running into eachtoher somehow.

Regardless, Terrible Sound mode results in very high current draw for the duration of that “band”, and with the massive windings and rotor of the melon, it was felt as a very strong rumble or high frequency ripple torque. I can’t imagine it being too good for Tinytroller. As soon as the band of terrible sound is passed, the ride instant becomes smoother and more controllable, but transitioning back into the band results in the motor suddenly slowing and becoming rough. Considering that the Band of Terrible Sound occurs at a useful low cruising speed of about 4-5 mph, this is indeed quite a problem. I might have to dig deeper into the ATmega manual to find out what timer registers are being refreshed or reset when I dont’ expect them to be.

poor tinytroller

Melon-scooter managed to make it 90% of the way around the block before it suddenly flaked and shut off. I was able to cycle power and have it function again, but only for a very short while. After which it seemed that at least two low-side FETs were shorted, since the motor was reluctant to turn even with the power off.

Before that, during bench testing, I had noticed my big red key switch becoming flaky and occasionally shutting off or dithering on and off, power-cycling the controller many times. It very well could have been a flaky switch that shut off from vibration, and the sudden power kill would result in huge negative voltage spikes which could have destroyed components.

I’d hate to think that the only thing that took down Tinytroller this time was a flaky power switch, but the performance was fairly smooth and flawless once the Band of Terrible Sound was passed. Slowing down was difficult – re-entering the Band of Terrible Sound meant I  had to hold on to prevent the handlebar from punching me in the stomach as the motor suddenly acted like I had jammed a rock into it. Getting something reliably working is, in my opinion, 90% of the challenge of actually making a useful product or project, so I’ll just continue the Tragedy of the Tinytroller some time.

more 3d printers

I’ve also been sketching out some more designs for the Next 3D Printer. Adding a filament guide to the interior of the machine that had to be flexible enough to reach the far corners of the axes while folding up neatly and predictably has been a fun engineering exercise, and I now understand why commercial 3d plastic extrusion printers are so damn huge. I need alot of buffer space to run the set of wire and cable guides which hold the filament and the electric umbilical.

However, one thing I did decide on and finish designing was my new Z axis. In the first post about the new machine, I sketched out an idea for a combined chamber heater and build surface heater. Well, that idea has since been turned into reality Solidworks.

Hey, it’s like the exact same thing. The resistors are 10 watt types, currently spec’d to be 0.22 ohms each and to be run in series for a roughly 1.8 ohm string, which ought to net me about a hot 80 watts of heating power. The surface itself was made transparent for imaging purposes, and actually is supposed to be aluminum and not clear plastic or something.

I’m not a thermal systems engineer, so I just whipped up a radiator pattern for the resistors that kind of made sense in my head.

Some more design progress on the Z table. The parts here are “edge stitched” together in my usual style with tabs, slots, and interspersed t-nuts. Four LME12UU type linear bearings comprise the guide system, two on each side, held apart by spring washers. I’m reusing the central leadscrew nut from MaB because for some reason it cost $30 and I still have 5 more feet of the same leadscrew, and I’m not buying a whole new one. The structure is mostly 1/4″ aluminum beams and 1/8″ bracing plates – I’m trying to minimize the use of giant 1/4″ stock on this machine, but because the Z table is so big (250mm square build plate, with a total length of about 290mm front to back!) it was warranted here.

Did you know that they make PC case fans that are 250mm across? I didn’t know either until I accidentally found one on eBay while looking for real industrial 200-300mm class fans. In fact, they make case fans up to 360mm. Why the hell do you need a fan that big on your computer?

It turns out they don’t actually move much air at all – I ordered a sample one from xoxide for kicks, and it seems to be for case modders and PC builders who want to take the “large but slow moving air mass” school of case ventilation to the absurd limit.

But that’s actually exactly what I need – I’m not trying to build a hair dryer  or a heat gun, but something which will gently fan the sweat of my 8 power resistors onto the back of the build plate. Time will tell if they survive 60-70 celsius (I’m guessing not), but for now I have one designed in. More industrial grade fans are spec’d out if I need them, but if these fans do work out then more gaudy internal lighting for me. Maybe it’s time to start case modding your 3d printers.