Archive for June, 2011


The Emergency Monorotor?!

Jun 22, 2011 in Emergency Quadrotor

The thrust vectoring module seen in the previous update has become a working object. So what I have now can potentially be turned into a midair single axis Segway, but I don’t think it quite works like that.  This module has been a physical refinement of the construction process – I’ve already made several changes and additions to the design which will be reflected in the rest of the modules. This one probably won’t make it onto the vehicle itself given its role as the guinea pig of the experiment.

The loose cage has now been assembled. Because the gaps here are so large from experimenting with laser cutter kerf, I used massive puddles of wood flour filled epoxy to assemble the joints. Most of them are filleted in addition to have epoxy between surfaces, and I clamped the entire thing down for a day (read: pile a large lead acid battery on top of) so it could set properly. The result is quite stiff, except at the corners where there is only 1/8″ lite plywood. It’s quite flexible there, and in the interest of not making a quadrotor with the torsional rigidity of thin sheets of plywood, I made an additional “corner thickener” for the outer corner which will bear the load of the frame tubes through those sidewalls. It’s attached through thick CA glue.

Next, notice that I’ve made a new controller mount. That flange is simply too floppy for me to want to mount anything to it, so that part will be “supplemented” with the 1/4″ thick part behind the cage. It will bolt through the 1/8″ wood and into the trunions below.

The rest of the modules will be built with the extra corner thickener and the bigger controller mount.

Those little plastic blocks to the left were made by my ever hard-working but rarely mentioned 3d printer:


Pictured are all the frame joiners, the pivot for the EDFs, and the smaller half of each trunion. MaB is sort of my unsung hero project – making alot of things easier, but always just kind of working so I never write anything about it. Unlike my other crap which breaks every time I think about staring at it wrong.

After cleaning the little nubs off with some selective sanding and knifing, the parts are ready for use.

Now, I don’t trust a 1/2″ nub of plastic with holding back 28,000 RPMs of ducted fan, so those nubs have center holes that reach almost all the way to the fan flange so I can glue something in which has meaningful shear strength – like chunks of the carbon fiber frame tubes.

I also printed off this cute little tailcone for the motor. It has 1mm walls and is vented so the motor can still flow cooling air through the center. Not having a blunt edge at the back will probably gain me back another ounce of thrust or something.

Here’s the servo linkage all hooked up. I actually reprinted one of the pivots to have a built in servo horn of sorts so I could use my stock of ball links. This arrangement worked well. The 2-56 threaded rod link allows me to fine tune the angle of the fan with respect to servo neutral.

(You know you’re in the future when you can say “I reprinted it and…”)

Here’s the rig readied for testing with the Controller Mounting Extension attached. The board bolting into the fan trunions is much stiffer than a chunk of wood hanging off of the main structure, and it also makes for more economical laser cutting since a huge tab like that doesn’t tesselate well at all.

Downside of printing with light fill to make things print quickly: They’re not structural really, at all. I think this was on 25% fill or something, but it exploded as soon as I applied meaningful bolt tension. I’ll clearly be doing these small parts in near-solid.

Here’s a short test video with me running the fan on 3S lipos…and a very discharged lipo at that. So there were maybe 10 volts going into this thing, period. It was still enough to shuffle the thing across a table with a 20AH lead acid battery on top of it.


There you have it. I have yet to do a full power test on 10S lipos, but that needs to happen in order for me to see if the cage is structural enough…and if the servo can even wrestle the fan around at those speeds.

Oh yeah, here’s the biggest lipo I’ve ever seen. Seriously, how did this not set the plane on fire again?


I’m not the only one who makes funky vehicles.

Jun 19, 2011 in MIT, Bostoncaster, Cambridgeshire, Stuff

Amy, a fellow Mechanical Engineering now-graduate and MITERese, also does. In fact, her stuff always seems to be simpler, more elegant, and way more functional than mine. Through peer pressure from multiple fronts, she has since began consistently keeping her own website ( updated with the latest project work. She’s reponsible for the incredibly stealthy Picofahrrad:

It now in fact has a hub motor, one of the few (the only?) operational hub motor vehicle outside of me and Shane.

Her latest is a five day electric mini-kart build which is so fresh and clean it hasn’t even been named yet.

The original goal was five days, and it was attained; it works as of like right now. I made a 8S6P LiFe pack for it, not shown in the incomplete picture above, but it goes on those polycarb corners. This thing in total weighs like less than the landbearshark’s left track pod.

Announcing the Emergency Quadrotor Project

Jun 17, 2011 in Emergency Quadrotor

Pursuant to my previous discoveries and advances in the field of quadrocopter propulsion using inexpensive generic components, I have commissioned the construction of a tele-operated flying model to demonstrate the practice of the design and construction principles which were discussed in my investigations on the subject I WANT TO BUILD A FUCKING QUADROTOR.

After I evaluated the two flavors of giant Hobbyking ducted fan, I simply couldn’t pass up the opportunity (or resist the temptation) to make a large quadrotor (/quadrocopter) using them.  Quadrotors and other flying vehicles have been on my mind for a while, at least since last year; but due to the expense of EDF units, I haven’t ever taken any action on them. The Edgerton Quadrotor, built last year primarily by a group of high school students over the summer, only added to that desire. While I certainly could have built a relatively simple one like that using propellers and cheap outrunners, and it would probably have been more efficient than a ducted fan equivalent, I just don’t like open props. Especially in an application where they have to be horizontally mounted and have the very real possibility of coming straight at my face. Otherwise, as history has shown, I’m just a fan of ……. fans. In other words, I’m embarking on yet another hare-brained engineering adventure that has absolutely no justification for existence. Sounds about on par with everything else I do, right?

I did get to fly the Edgerton quadrotor straight down a flight of stairs, though. And by that I mean it went out of control exactly straight down said flight of stairs… I wasn’t really flying it at the time.

So therefore, I now announce the Emergency Quadrotor Project. The plan: four Hobbyking 102f type EDF units, four of the 600-class helicopter motors, and two giant 37 volt lithium polymer batteries (probably setting a cargo plane on fire as I type), and combine them with a Razor IMU, a set of ultrasonic rangefinders for altitude determination, and …an Arduino or something. The total thrust out of this thing should be on the order of 30 pounds, with the vehicle weight being slightly more than half that, yielding a high thrust reserve for whatever I might end up mounting on it.

Yeah. That‘s where I’ve been for the past week. Designing this thing like a maniac. Twice.

We begin with a ducted fan.

I meticulously modeled the ChangeSun 120mm fan up, including a mockup of the T600 motor. Now, those blades aren’t swept (just a straight loft) and all aerodynamic-like, so I don’t think I could duplicate them and have it work as effectively, but otherwise I like this reverse-engineered model alot.

As usual when I binge project development work, I just sat down and started CADing. I just wanted to put the fan in a sturdy mount which I can also then attach to a frame. In this case, I dynamically settled upon a carbon fiber space frame-like design, using carbon fiber tubes retained in wooden pods. The wood parts are designed to be laser-cut, and the fan is mounted solidly at an angle using 3d printed blocks. As shown, the fan is canted 10 degrees inward. Tilting the thrust inwards (i.e. causing their projected thrust axes to intersect at a point above the vehicle’s center of gravity) will enhance the tilt stability of the vehicle over fans pointed straight up, and most commercial quadrotor toys have this cant to some degree. The vehicle will still need a stability controller, however – this doesn’t automagically make it stable.

Since these fans do not come in a right-hand version, there’s no way for me to cancel the resultant torque from the fans spinning. I planned on adding a set of servo-controlled vanes under each fan, but they haven’t been designed in this picture.

Using birch plywood as a weight benchmark, each corner pod weighed out to about 1.8 pounds.


About 8 hours of CADing (don’t I wish I got paid for this stuff?) later, this is the layout.  The size is approximately 33 x 18″, an aspect ratio of about 1.6. I wasn’t interested in having a square quadrotor as much, but the frame tubes can pretty much be arbitrarily long or short. The rectangular design here was more to explore a square payload area.

I’m really proud of these little frame joists that I “dynamically generated” in my CAD trance without really thinking about. This whole thing can be reversibly knocked down for travel and storage, and alot of component spacings are therefore adjustable too. It’s definitely not the stiffest method of connecting things, however. I briefly considered just using the common kevlar thread and epoxy (or CA glue) method of stringing together carbon fiber rod spaceframes, but that would have committed me irreversibly to a design. This first round is more to get a feel for what I do want, since I really have no clue right now. So therefore adjustable is good.

The joists can all be 3d printed Live From MITERS. In fact, I just got a new 5 pound roll of ABS plastic, and if there’s 5 pounds of anything that’s not hauling ass on this, something is wrong.

Here, I’ve positioned the speed controllers of choice – the Turnigy 100 amp HV, which has been my staple EV controller since forever (all the way back to the original Snuffles the First). Could it be that I’m FINALLY using it for a legitimate purpose? The total weight of everything here is about 15.5 pounds, 6 of which are in the ginormous death-lipos of certain fiery annihilation™, and another 6.5 in just the fans themselves. I think the entire rest of the thing only weighing 3 pounds is fantastic, considering if I had made this my way it would all be billet and waterjet-cut aluminum plates. This is not including wiring, switches, electronics, or gaudy lighting, so I expect the final vehicle weight to be closer to 18 pounds or so – still a 40% thrust overhead, which is more than enough.


At the continued peer pressure of A Certain Scientific Course 6 And Controls Guy (you should ask him Arduino questions), I trashed the entire design up there and started over.

That’s right: THRUST VECTORING!!!

The compelling argument was that as long as I was inserting servos into the pods to move vanes, I could just as well mount the entire fan on a pivot and move that instead. The overall part count is actually less, and it would definitely be more mechanically robust than some scrawny wooden flap pieces. This isn’t true thrust vectoring as found in fighter jets and rockets – I really only have control over 1 degree of freedom, i.e. the tangential component of the thrust as seen by the vehicle.

However, this is the essential direction for cancelling torque from the spinning rotors and controlling yaw movement directly. Furthermore, there is the potential to direct the thrust from each fan in orthogonal directions to emulate a midair omniwheel drive. It would allow decoupling of translation and rotation requirements from the fan speed, letting them only handle vehicle roll, pitch, and yaw stability. All of this amounts to a massive but still relatively simple controls problem. The inputs to the vehicle are desired planar motions (X, Y, altitude) and one rotation (about Z), and the outputs are eight commands – four fan speeds and four servo positions.


The model’s a little more sophisticated now. Two things have changed: The inward cant is built into the 3d-printable trunnions, and I’ve moved the servo to the other side. No particular reason for that one…

I ran into a huge geometric headache trying to adapt inward canted fan pods to straight frame rails. So I took the cheater’s way out and superposed the translation and rotations into the fan mount itself. So now each fan is canted towards the vehicle center by 5 degrees, but the pod itself can be perpendicularly mounted.

There’s also alot less wood in this mounting scheme.

And again with the little frame connectors. This thing is starting to look like a flying Reprap or something – so many 3d printed joists! I should actually knock a few out on MaB to see if this is even sane.

I’ve extended the upper plate of the fan pod so it mounts a Turnigy controller. The controllers are spaced very closely to eachother, so hopefully that means I can keep the wiring runs short. The system should be drawing 50 amps or so per fan normally. Putting the controllers like this in the intake airstream path should contribute to their cooling – there’s not really space underneath to put them in the exhaust stream.

The total vehicle weight for this design seems to be about 4 ounces lighter than the first, mostly due to less wood. I hope this is big enough that +/- 4 ounces isn’t gonna matter.

I anticipate sticking the electronics, like the IMU, right in the center of the X, with altimeters at the long ends to take differential measurements such that the vehicle’s tilt can be factored in.

I’m confident enough in this design such that I’ve went ahead and laser-cut the structure one fan pod. It will be put together to review whether or not I have Impossible Screws, or if the 3d printed parts are going to be nontrivial. I actually caught one very important error beforehand – there was actually no way to put the fan in the pod, nor take it out afterwards. These joints are designed to be glued, and if I glue the pod together beforehand, no dimension allows admission of the fan’s flanges. And if I put the fan in first and then glue the seams… well, that’s kind of permanent. The solution was to insert little square cutouts at the edge of the hole so the fan’s flanges can be passed through.

The material is poplar plywood, commonly called “Lite ply”. The stuff’s very cheap and very flexible. And really light. It’s not quite balsa, but it’s close. It also laser cuts very quickly – I tested up to three times as fast as 1/8″ birch plywood (common material for aircraft modeling) and still had positive cuts. In fact, normal 1/8″ woodcutting speeds left a massive charred kerf. With this test fanpod as the lesson, I’ll probably cut all the rest much faster.

Next is to 3d print one set of fan pivots and throw together a thrust vectoring rig using Chuckranoplan‘s servos. I should be able to thrust test this thing soon.

did someone say flying reprap?

The Eucatastrophic Revival of the Land-Bear-Shark

Jun 11, 2011 in Land-Bear-Shark, Project Build Reports

or, The Concise Summary of the Reasons why I Hate Everything about Electronics and Software and Therefore Do Not Understand Why I Insist

on Constructing Complex Electromechanical Implements Involving Them; A Memoir by Charles Z. Guan.

One day I will actually write a book on why I keep building custom electric vehicle components knowing full well that I hate electronics and software and that it always blows up the first …. few… times or is generally just a pain to deal with.

Alternatively, I could complain on the Internet and then go right back to doing what I was before. But before all that, a video.

There you have it. After the past week of rebuilding and debugging of the electronics, I have a LBS that…

  • Doesn’t use the Turnigy 80mm brushless motors like I said it would
  • Doesn’t have the wireless hands-free controllers like I said it would
  • Doesn’t go nearly as fast as I said it would…in fact about 2/3rds the previous design speed.

…so what did I actually build? I’m not sure, but it looks kickass and rather cute at the same time. It reminds me of some kind of miniaturize fancy construction equipment (you know like they make miniature cows or something). It’s very square and squat, the appearance complemented by the disproportionately large track pods…and honestly, would look at home in the MIT anime (I’m making one, I promise) as-is.

Last time, the Shark adventure ended with the motor controllers exploding upon application of power. Kind of reminds me of a certain other basket-case vehicle”s history. Not wanting to resort to just putting some Victors or something on it, I went ahead and made an entirely new board from my panel of 6 that I ordered, and being slightly more intelligent this time, tested it on a current-limited bench power supply first.

First runs of  motor controller designs seem to either work, or explode spectacularly due to some fundamental error in judgement. I couldn’t get the new board to not dead-short the power supply. Any time the IR21844s were enabled, the boards would instantly become roughly 6-ohm loads and heat up quickly. 6 ohms? That’s a clear sign that FETs are turning half-assedly on, or half-assedly off, being unable to reach either the blocking state or the fully on, conducting state. Now, these controllers have already been live-edited once – I left out a critical connection in the current sense circuit, so I was checking for more unrouted connections and other signs of rushed board routing.

It was more useful to look at the schematic.


Unlike the Segfault boards, the issue in this case is what’s not connected. As in, the Vs (high side FET’s source) and M terminal (motor output, also known as the high side FET’s source) weren’t connected. This meant the high side can never really turn on… or turn off, or anything really. The gate might as well be left floating.


Well, at least this is an easy Little Blue Wire fix.

After verifying that, yes, the controllers no longer were power resistors, and that they responded to a PWM input with a proper output, and that my lack of attention and dismissal of EAGLE’s frantic cries of “YOU HAVE REMAINING AIRWIRES!!!” had done me in once again, I installed the controllers back into LBS. I decided to take the more cautious route and test everything on a power supply.

This is where the three hours of software nightmare began. Using the crude motor actuation code I made last week, I was able to get the motors to move forward and backward, not under radio control. This was just to verify the operation of the controllers and make sure the current sensors were working.

I began writing a more sophisticated driving program that took inputs from a handy R/C car radio (the HK GT2 if you’re interested). The first program was very simple, just taking the servo pulses centered about 1500 microseconds and linearly mapping them to motor PWM values… about a bone-simple as you can get. Hell, even people in 2.007 managed that one. I even taught people in 2.007 how to do that. It also read the status of the rider-detect switches and latched the contactor accordingly. This was one thing I wanted to get right, since I wouldn’t want my rideable 2.007 robot to run away.

But no matter what, I could not get the motors to respond reliably. The contactor would latch and unlatch unpredictably, the motors would twitch and some times lock on full speed. The ADC pin that the rider detect switches were connected to would seemingly turn into an output at will, driving the circuit low (and of course causing the contactor to open and the motors to stop). Then, it would randomly cut back on.The Arduino would frequently lock up, and the serial port some times spewed nonsense repeatedly until the board was reset.

Initially, I thought it was a grounding issue, since the 2.007 Arduino Nano Carrier has some limited protection features built in on its logic power supplies that could have been messing with system ground levels. I tried rewiring the board to run off a separate power supply, figuring that the contactor closing could have been introducing noise into the 15 volt supply that fed the board through the ground.  I tried disconnecting everything at the advice of master Course 6 guy, and that pretty much ruled out any hardware being the cause of the problem as the board continued to twitch, reset, and lock up. The next step was to knock out functionality in the code, line by line, isolating the problem to one line of code.

Was it the math involved in processing the throttle and steering pulse inputs? Nope, with the exception of some possible variable typecasting issues, which were cleared with no impact on the problem.

Was it the multiple consecutive pulse reads that could have resulted in some weird timeout behavior? Nope. They did that in the class all the time and it worked fine.

Was it issues with Arduino built-in functions such as constrain () or map() and the inputs being incorrect or out of bounds? Nope, even reduplicating the functions explicitly didn’t solve anything.

And finally, after commenting, correcting, and deleting just about everything, we arrive upon the last line.

LMOTOR and RMOTOR are constants that designate digital output pins, and ICMDx is the byte being sent to the PWM times on those pins. If you see what is wrong with these two lines, you get a cardboard brownie.

Spoiler warning: The syntax for analogWrite is PIN,VALUE… not VALUE, PIN. I was telling the board to write a PWM command to… I’m not sure, pin 9000 or something. This probably caused the process to jump to a random location in memory, causing all kinds of weird shit to happen. In other news, Arduino functions don’t have error checking for this stuff?!

After this minor detail was redressed, the rest of the code  and original wiring scheme was restored and it worked just fine. Everything. There were no noise problems or anything of the sort. The vehicle responded to radio commands like one of my robots would, and it was driven around as a robot for amusement for a few minutes. Then after making sure the basic driving code behaved as expected, I spent a further five hours adding in such luxuries to the program as radio failsafes (stopping upon loss of radio signal, instead of spinning wildly in a circle as it did up until that point…), more intelligent processing of the rider switches (in other words, not holding the last good throttle value and causing the vehicle to take off immediately upon reactivation), and throttle-steering ramping. The ramping was critical to making the vehicle actually controllable since it more or less just forced a constant acceleration and made the radio controls less sensitive to minor movement.

tl;dr i hate software

Like many Course IIs (and closet VIers), I still view software as a time-consuming impediment to finishing projects, that is made primarily of black magic and guess-and-check. That thing you leave until the very end when the mechanical and electronics are hooked up and ready, despite being the one factor that makes or breaks a project. I’ve kind of lost the ability to “think in software” like back in my high school AP Computer Science days – lines of code that seem perfectly reasonable to me now usually are huge logic errors when executed. It’s more of an annoyance than anything, and I suppose only writing more code will exercise those skills again enough to make programming expedient.

It’s not even real software. It’s Arduinos.

Anyways, back to things that matter. I’m not bitter at all, I promise.

Drive testing revealed that the electronics were getting really hot. The CIM motors are 12 volt motors by nature, and pretty powerful ones at that, so placing them into a 20 volt environment made their current draw that much higher. The locked-antiphase control meant that there was an idle power consumption – namely about 50 watts. Add to that the very high scrubbing friction that the tracks experience when turning and the fact that most of the testing was done at low speed (no forward movement alleviation of the turn) and you had motor case temperatures exceeding 60 celsius and controller temperatures not much below that.

Well, I couldn’t really care less about the CIMs at the moment, but I wanted to make sure my precious custom controllers don’t smoke themselves. Solution 1 was just dropping a slightly trimmed server heatsink under the FETs. This turned out to be not too effective, since the D2PAK FETs don’t have that good of a thermal resistivity from the plastic face. Additionally, the board was still edge-fastened, causing the whole thing to bow a little bit and really not letting the FETs have any heatsink contact. More time drilling holes (to use the center mounting holes) would have alleviated this problem, but…

Forced air works just as well in this case. I took out the heat sink and hot glued on a pair of small 1U rackmount server fans, and all was good. The fans run off the 15 volt supply, and the stiff breeze over the board and components that stick out relieved the heating issue – it is at least some finite amount of airflow such that all components and copper traces contribute some to heat removal.

Before this was added, I think the capacitors were acting as a heatsink for the FETs. Hey, copper leads, aluminum plates…

I realized I never actually posted a picture of the rider switches, so here is one. A submini snap-action switch and a 3d printed mount that clips over one of the mounting bolts for the pivot joint. When a rider is present, the slotted pivot presses on the switch. Only one switch has to be engaged for the vehicle to be activated, and when no switches are engaged, the vehicle shuts off the main contactor after 2 seconds.

One little afterthought which can be seen in the video is this wheelie tail. I designed this in about 10 minutes early one morning and cut it out an hour afterwards, so there was really no thought put into it…such as the fact that it’s made of mystery scrap plastic (behaves like Delrin, so I assume it’s something similar) and has huge stress risers at the pivot point.

It also revealed a discrepancy between the CAD model’s tread thickness and the real life one. The tail was supposed to ride about 2 inches off the ground, but in reality this was less than 1 inch, which prevented me from adding wheelie rollers of any reasonable size. In the test video, they are simply shown dragging on the ground. Hey, Delrin is a low friction plastic… stop judging me.

I will probably remake these, as there’s plenty of scrap left to be further up and slightly less out, and mount roller skate wheels on them. Or the wheels from the skateboard that was parted out to build it.

Recharging, after an entire night and morning of drive testing. I’m slowly getting the hang of this thing. All the drive testing in the video took out about 8 amp hours out of the 24 or so onboard – I’m not sure what distance this translates into yet.

next steps

So I’ve built a robot. Hey, I think I’ve done that before!

When testing LBS, my fears of the wheelbase being too short to stay on top of were realized. If you accelerate or brake too hard, the entire vehicle just lurches forward or backward. This is grounds to give the vehicle a little bit of “Segway action”. While it will not balance you outright, the springs in the suspension allow the vehicle to tilt forward and backward enough to sense an angle. While I previously said that the board wouldn’t be involved in the control, I didn’t think about the implications of having a slightly tiltable suspension. I was more thinking of pure weight-shifting scheme which would cause issues with accelerating reference frames. I think the vehicle can at least be programmed to stay under you. That is, upon acceleration, it will recognize a tilt occuring in the opposite direction and slow or stop the acceleration to compensate. I’m probably also going to experiment with forward and backward lean control for the throttle if the acceleration adjustment does work out – after all, if it’s trying to stay under you, there’s no reason that leaning can’t be the only control input.


The Triple Weekend Update Part III: Playing With Inexpensive Chinese Ducted Fans

Jun 05, 2011 in Beyond Unboxing, Reference Posts


I already am publicly known to have an unhealthy obsession with Inexpensive Chinese Brushless Motors (ICBMs). But did you know that I’ve also recently grown an addiction for Inexpensive Chinese Ducted Fans? There’s no smart acronym for “ICDF”….except for maybe the Iraqi Coastal Defense Force or something.

Hey Charles, do you have enough of these things yet?

For one reason or another, over the past month or two, I’ve just been buying random ducted fans from Hobbyking (where else?). At first it was out of a desire to find a good propulsion source for Chuckranoplan 0004, which I promise is still under way. But then with the advent of Fanscooter and its derivatives, I’ve been thinking about ways to use these cheap EDFs effectively…. or just in large quantities, to get higher thrust values for any propulsive task I can think of.


Now, real EDF systems from European and American boutiques are known to be great performers and are well-built – generally made of metal alloys or laid up from carbon fiber and dynamically balanced. These are the things that tear ass at upwards of 50 to 60,000 RPM in model fighter jets that go 200 miles an hour or more.

The problem is that they are EXPENSIVE. Like, dear Robot Jesus are they expensive. The TF8000 is generally my calibration point for how much I can’t afford a quality large EDF setup – the fan itself, without a motor, is $600. The motor is usually an exotic German make (like Lehner or Hacker) that costs $700 to $1000 by itself. Throw in the extra bigass controller you need to run that motor and you’re looking at nearly $2,000 for a single thruster setup. Granted it is like 30 pounds of thrust, but still – how do these guys even?

I mean, besides massive funding.


That’s why I have decided to explore the parallel design space loci a little, since it doesn’t cost too much for me to do so. Hobbyking currently has two large EDFs, both in the 5 inch (120mm) range, and I got them both.

  • HK #OR003-00113-7B Haoye 125mm rotor, 7 blade. This one has been around longer, but I only got it recently on a whim. It has a set screw type propshaft for 6mm motor shafts, and a removable nosecone. The construction seems to be pretty standard “cheap EDF” – unreinforced plastic (ABS, judging by the smell… read on to find out), but the rotor looks to be glass filled nylon. The price is $30, and the maximum motor diameter is about 50mm or so.
  • HK #102F “ChangeSun” 120mm rotor, 4 blade.  For 40 bucks, I threw one in on a parts order for Chuckranoplan. I like the construction of this one much more. The propshaft is a collet-type one, not a set screw, and the shiny aluminum nosecone is also a nut. The rotor and casing are both made of fiber-reinforced nylon and both are very stiff…which fiber is, of course, dubious – carbon fiber is claimed, but why do I not believe that? The maximum motor diameter is 52mm.


Finding motors to drive these fans was difficult. HK doesn’t have purpose-build EDF motors larger than 36mm (the type which has a tailcone and longer shaft). I also was not too please with the reviews on their large inrunners (up to 45mm diameter), and I hate inrunners anyway. The only thing left that was in stock were 600-class helicopter motors. I ended up getting a T600-880 and then a T600-1100 – two different winding variants of the same motor so I could test different battery voltages. There were some motors with potentially higher power, but they were not in stock and if I backordered them, I would probably get them some time in late September of next year.

Just to give an idea of how stupidly big this thing is… here it is next to a commonly scale item. The outer casing on this is about 130mm.

I also bought this cute little prop balancer from HK after feeling that I would need it.

A few unrecorded test spins of the fans revealed their very, very Chinese nature – the rotors themselves were severely off-balance. Using the über-cool magnetic levitation feature, I attached little chunks of rubber magnet stock I found at MITERS to the interior of the rotor using CA glue until I was satisfied.  That step was easy enough. At least the Haoye unit had a straight propshaft (set screw notwithstanding): the ChangeSun’s propshafts were completely and utterly useless. They fit the motor shaft well, but they were drilled off-center and wobbly, and the aluminum alloy was also rather soft.

Seriously, what a corner to cut. The rotor itself and casing are both very nice injection-molded parts, but the one critical component to connect them is garbage. Because of this inherent Chinese-ness, I can’t recommend them to anyone who isn’t willing to put some work into polishing them up.

For the ChangeSun 120mm fan, “polishing up” meant putting the 5mm adapter on a lathe and carefully reaming the bore to 6mm. In order to eliminate one major source of uncertainty in this, I elected to perform the operation on a nicer campus student shop machine.

Four blades versus seven… which one will win?

As usual, I’m interested more in the static and quasi-static (read: slowly moving forward) thrust of these fans. I’m not likely to build something that travels very fast or anywhere near the “prop speed” for these things, so my testing would focus on static thrust characteristics.

The T600 motors seem to be a good fit for both, but is a little tight on the Haoye 125mm (This would later prove to be a little tighter than I imagined). On the Haoye, the vent holes of the motor can stick out just enough to make it look like it was meant to be there…as well as providing a better airflow path.

On the contrary, the motor is pretty much flush with the backside of the ChangeSun 120mm fan. The vent holes are therefore much less effective here. This may have implications for continuous high-power operation of the whole assembly. A longer (read: more powerful) motor would be better for it.

In the picture, I was executing the auto-”Hey, hold this while I plug it in” test on the Haoye fan. I didn’t hold on for too long…


To measure the static characteristics (thrust, RPMs, power consumption), I set up the Fankart test rail. The EDFs are screwed to some cut-off 2×4 sections, which are in turn clamped to the linear ball bearing platform. I rigged up an electronic pull scale behind it, and located the controller (and Turnigy power meter) near that.  You can already see the dot of retroreflective tape I attached to the rotor so it can be measured using laser tachometry.

I make “laser tachometry” sound ultra-sophisticated, but it’s this one. You should get one since it’s useful, but it needs reflective markers – a sharpie mark won’t do.

Next up was the Haoye fan with the T600-1100 motor already loaded. At the very start, I noticed the current draw was much higher than I would have expected. But the ESC is (allegedly) 80 amps, so I kept going anyway.

At somewhere near top speed, the fan suddenly locked up…and then this happened.

The destruction was instant.

Model airplane controllers really amaze me in how close the components are pushed to their absolute maximum ratings. They also have absolutely no protection whatsoever – at least, in this case, the protection wasn’t fast enough to respond to a sudden locked rotor at full throttle. The thing lit up and actually started shooting jets of fire.

Yeah, it’s pretty gone.  The shorting current was enough to blow off several wires completely and heat up my double 14-gauge battery jumper. So when this happens to your plane in midair, does the whole thing just light on fire or something?

I literally had to hammer out the motor from the casing. Something went terribly wrong…

Yes, that is a ring of melted ABS plastic hanging out of the motor. I know it’s ABS because it smells like all three cancer-causing constituents of ABS plastic, and is the smell that Make-A-Bot constantly creates when it’s in operation.

It looks like a severe case of… well, severe case interference from the distal end of the motor can to the walls of the housing. What this tells me is that the T600 is just a bit too large in diameter to really fit the housing, and the vibrations induced from operation are enough to make the can scrape the inside. At high speeds, this translates into quick rapid heating that melts the housing and turns the plastic goopy.

I assume at some point enough plastic goop is hanging onto the motor to drag it to a stop. No data was recorded on this run because I was too entertained by watching controllers explode.

While the long-term solution for this problem is to find a different motor, the short term one is to just bore the housing out. I took everything out an extra millimeter so the motor had plenty of clearance.

After that, I remounted everything and, using a different controller, put the test rig back together.

results and discussion

The test on 10S LiFePO4 cells with the T600-880 motor yielded:

  • 19100 RPM
  • 2.9kgf static thrust
  • 95.5A peak
  • 30.01v minimum.

I elected to not even try the 1100kV motor in the Haoye fan after this, since it would probably just try to pull a thousand amps without getting much work done. Judging by the very low RPM figure, the readings are reasonable. It’s clear to me from looking at the fan blade geometry that the Haoye is designed for a very high vehicle speed. The blades are very heavily pitched (actually perpendicular for the most part) and not very swept or twisted at the tips (not much washout, a plane word I learned). From the findings on Fankart, this would make for worse static thrust per power consumption, and the results reflect that here.

Further tests with the ChangeSun fan on 12S LiFePO4 (38.4 volts) found that it’s very well paired with the T600 motors at that voltage.  I got the following data points:

  • 31.1Vmin, 53A continuous, 2.8kgf static, 24800 RPM with T600-880
  • 30.0Vmin, 86A continuous, 3.8kgf static, 28500 RPM with T600-1100
  • 36.7Vmin, 75A continuous, 4.1kgf static, 28540 RPM with T600-880 on 12S LiFePO4

I also decided to not test the T600-1100 on 12S since it was clear the continous current was going to be over 100 amps, and the motor will definitely not take that much. I think even 75 amps max is pushing it for the T600-880 motor.

I think to prevent future friction stir welding situations, the motor should be a large inrunner, preferably with an aerodynamic tailcone. The problem is that HK doesn’t carry huge inrunners yet, and real inrunners (from say, Neumotor, Lehner, Hacker, etc…) would be kind of lame to pair with a cheap fan. So if you know any Chinese inrunners in the 50mm size class and of more than 2+kw continous power, let me know.


Wait…what the fuck is this, a 2.671 paper?

Anyways, the conclusion here is that for a little over $150, you can get a solid 4 kilograms of thrust from the HK102F “Changesun” fan paired with a T600-880 motor, running on a 100A Turnigy HV controller. 12S LiFe cells is very much equivalent to 10S traditional ltihium polymer, and if you pair it with a DEAR GOD WHY DOES THIS EXIST 10S pack like this 5.0Ah pack from HK, then for less than the cost of like, one fan blade on the TF8000, you can have a full 4kg class power system for around $300*.  Most likely, that battery can feed two T600-880 powered fans at the same time – 150 amps continous (75 amps each) is only 30C, which is within the rating of the battery, and have a system capable of 8+ kg thrust.  Put two of those system side-by-side, and you’re looking at something which can lift Überclocker straight up in the air.

Just saying.

Oh yeah, if you want to hear what a (balanced) one of these sound in action:

*You better have a machine shop to clean up those propshafts though. I have not tried running the CS 120mm fan with the stock propshafts. They scared me too much even on low speed.