Announcing the Emergency Quadrotor Project

Friday, June 17th, 2011 @ 20:55 | 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?



  • Thank You for Calling Big Chuck’s Lawn and Landscaping: Introducing Crabmower
  • More About the #RobotTrapShop and Building Up a New Workspace
  • A New Beginning: The 17th Chapter; Back to the A-Town
  • Robot Ruckus at Orlando Maker Faire: How to Somewhat Scale-Model Test Your BattleBots
  • Überclocker 5: Finishing Up The Everything Else
  • Überclocker 5.0: In Which I Actually Have to Build the Bot, Not Just Talk About It
  • Überclocker 5.0: The Big Post of Designy-Stuff
  • The Overhaul of the Future Begins Now: Überclocker 5.0 (Also, Welcome Back to Robots)
  • Operation RESTORING BROWN Part 7: The Epilogue; or, Dragon Con 2019
  • Operation RESTORING BROWN Episode VI: Return of the Van Lights; the Conclusion

    12 Responses to “Announcing the Emergency Quadrotor Project”

    1. Shane Says:

      Now you have to deal with gyroscopic torque too!

    2. MARSHALL Says:

      if you are building a ducted fan quad, you should check out as well. there is a ton(probably literally with all the airframes documented on there) of info and support on there and someone has even tried to build a ducted fan tricopter, it failed from the rotational torque on the first try and he said he was going to try and put yaw servos on all the arms and see if that helps. just a heads up, also i think this project is great!

    3. marshall Says:

      also i almost forgot, to save you all the trouble of building your own flight controller, the ardupilot mega ( ) may be the hardware headache saver you were probably looking for but never realized it. It has 8 servo outputs and (i think) 8 inputs, and a imu shield that mounts on top of it. the firmware could probably be modified for your use (it flys planes, quads, and tricopters) and with the funding that Iv’e seen you get, for $250 it wont break the bank either. I hope this helps! good luck!

    4. beak90 Says:

      I have been working on a quadrocopter for about 6 months now (it still doesn’t fly). I can tell you that its more complicated than it seems. The software is probably the most difficult piece. Or rather, getting the software and the hardware to play well together… And you’re gonna have to learn some math. PID control, Kalman filtering or complementary filtering, vector math that I don’t understand, and a lot of other stuff too. I will release my code at some point soon, but its not ready for release yet because its too messy and is missing some features like steering. Its just setup to hover right now.

      The problem with ducted fans is that they run on such high RPMs that they can’t react quickly enough to control the quad well. Here is a thread that explains the problem very well:
      They also aren’t very efficient, so you could use much smaller batteries and large props instead and get probably better results.

      Really the most difficult part of building a quad is getting it to stabilize. The IMU you mentioned (same one I’m using) needs to be filtered significantly and it also needs to be mounted in a way that will reduce vibrations (what I’m working on right now). The vibrations you get from the motors and props is so large that it creates a significant amount of error in the angle calculations. Even with really well balanced props! The DIY drones people mentioned that it might be the IMU itself that is causing problems. It might resonate at a certain frequency which simply makes it unusable for a quadrocopter. So if I were you I would go the simple way and use the software and hardware from the arducopter project:
      At least use their electronics and software with your own hardware. There are just so many choices for the electronics and software that its just easier to go with a proven way of doing it.

      That’s my 2 cents anyway. Goodluck!

    5. JoeyC Says:

      Software is so lame, just take the segfault-route and make the entire thing analog.

    6. Shane Says:

      You can do anything in software.

      Also, this might be easier to control because it’s so heavy?

    7. Xo Wang Says:

      Putting in the extra degree of freedom of thrust vectoring lets you take one out of the project, namely needing to balance torque. You’re free to make it a {3-, 5-, 17-, whatever}copter!

      The big appeal with quadrotors has always been that control is purely software: no v-pitch, cyclic, or counter-torque mechanisms to spoil the fun. With your design, you can break the formula. ;)

      Having a platform without messy mechanics, combined with ass-cheap brushless, plus the explosion (not literally) of equally ass-cheap MEMS sensors, are what made quads wet dreams for EEs like me.

      Anyways, what Shane said. You have a crapton of thrust to play with on a heavy platform and an Arduino doesn’t have that much horsepower. Take the opportunity to make this sucker HUGE. Your control loop will thank me.

    8. Jamo_g Says:

      You an AE now?

    9. the chuxxor Says:

      I’m da bawss.

      And yes, I do believe this will be substantially easier to control than a normal small quadrotor because of reasons already outline here.

      1. It’s much BIGGER (more inertia) than an average quad, and therefore has longer time constants associated with tilting and moving. This allows the use of a slower loop, or increased stability with a fast one, same dealie. Additionally, the inertia of the fan rotors compared to the inertia of the vehicle is very small.

      2. The thrust vectoring mostly decouples the balancing from the travel. I can have the balance running in the background with vectoring commands transparently added to the fans for movement and the balancing will make up for any thrust discrepancies resulting.

    10. Xo Wang Says:

      Mmm, I was not a terribly coherent writer last night. It’s what I get for keeping bottles in my room for “engineering emergencies.”

      I totally agree with (1). I’ve seen an 10-pound Turnigy-and-aluminum-tubing monster stabilized with only helicopter gyros (the kind plugged into one R/C channel and altered the PWM going to a servo). It didn’t even use a gravity reference: the time constants were so long the human operator kept it level manually. Your quad should have no issues there (but make it biiigggger!).

      Anyways, so now that I’ve read your post sober, I noticed you said 140% thrust-to-weight is enough for the first vehicle. That’s enough in still air, with a stick rammed through the vehicle and into the ground. But quadrotor stabilization is lot more dynamic than you’d expect: in any sort of dynamic conditions (read: wind. Quadrotor abhors a tiny bit of moving air), or when total thrust is high (read: taking off, or… vertical wind), the stabilization loop can very easily eat up one-vehicle’s-weight-worth of the available thrust.

      This would saturate one or many of the rotors, and the vehicle just falls out of the sky.

      The usual rule of thumb is 200% thrust-to-weight, but 300% is a popular design goal.

      As for the thrust vectoring for translation so the vehicle can stay level, I LOVE the idea. An interesting controls problem comes up: by tilting the rotors rather than, well, vectoring the thrust output itself, there’s some interplay between supposedly orthogonal controls. A controller would need to consider gyroing yaw torque as the tilt servos are in transit, as well as a bit of roll/pitch torque from rotating up to a few pounds of motor pods.

      But since you don’t have counter-rotating rotor pairs, you don’t have the issue where lowering the thrust (i.e. tilting) from one samewise-rotating pair of rotors causes a yaw torque. I’m really looking forward to seeing your controller for this vehicle!

    11. the chuxxor Says:

      I’m REALLY hoping that this rotor-vectoring idea works out well. It really should allow more independence between translation and rotation and just hovering.

    12. Dane Says:

      i’m bringing some 20AH prismatic cells over tomorrow, in case this thing gets bigger. is there any worry in the ‘play’ of the teensy servo motor, even with the mechanical advantage?