So... here we go, the project has been published. A bullet-list-brain-dump of what has been running through my head (minimally edited, but that's probably best at this point):

• Basic design. I want the unit to be radially symmetrical; to cancel the torque from the propeller, that means contra-rotating blades. Taking a cue from my excellent tiny remote control helicopter, I hope to use relative motor speed of the two props to control yaw.
  • That brings up an interesting point: which way is up? What is forward? In my extremely rough sketch, I defined roll as rotation along the propeller and body axis; already I have violated this convention by calling it 'yaw'.
  • Since the device will (if anything works as planned) hover vertically with the propeller at the bottom, we'll call rotation around the propeller's axis yaw. The two gimbal servos (or whatever gets used to tilt the thruster) will be designated Pitch and Roll, all relative to an arbitrarily point on the outside of the device that defines 'front'. Moving parallel to the ground with respect to the front (presumably by pitching) will be forward motion. 
• Essential design considerations I should have figured out on a napkin before publishing this project:
  • Thrust:Weight. Can I find an off-the-shelf contra-rotating propeller system (or design and manufacture my own) that can put out enough thrust to lift the entire device? 
  • Actuation speed. Will servos be strong and fast enough to tilt the propeller in its gimbal mechanism? Will the system only be stable if you leave it alone (i.e. there is some critical tilt angle beyond which it can't recover)?
  • Instrumentation. How fast can I get a signal from a 6dof sensor? Is it fast enough to react and catch the device before it flips over?
  • Control. What kind of hardware do I need? What's my control loop update frequency for the pitch and roll servos? What about motor speed control to keep the system from going into vertical oscillation?
• When will I stop spelling 'propeller' and 'helicopter' with an 'OR' at the end? Thanks, HaD, for the red underline in your text editor. 
• Breaking down the parts
  • Thruster
    • Controls yaw using differential rotation of blades.
      
    • Accelerates unit (a) axially for simple up/down altitude changes, or (b) axially and radially for tilt and roll.
    • Ideally reversible; if the device takes off and lands upside-down (and flips in mid-air), it wouldn't need a huge landing apparatus that clears the thruster range of motion.
    • Gimballed. As mentioned above, the gimbal actuators need to be fast enough to catch the unit after starting a pitch or roll; strong enough to accelerate the propeller/motor assembly (including counteracting any gyroscopic effect); have enough resolution to minimize oscillation while hovering; and be as light as possible.
  • Body
    • Light. Light, light, light, light, light. I originally envisioned a CF truss system or hollow CF tube with milled holes. We'll see what makes sense.
    • Reasonably strong to survive the inevitable crashes.
  • Sensors
    • Do I need an accelerometer AND a 3-axis gyroscope? My understanding is that gyroscopes help improve absolute orientation sensing during maneuvers, so I'm assuming I'll need both. Lots to learn here, undoubtedly. 
    • Response speed: see above. Same goes for resolution and range, I suppose. 
  • Actuators
    • Will servos work? Do I need to use something with a better power:weight ratio? What about stepper motors? Or some type of linear motor? That could turn in to an extensive side project.
    • Range of motion? I suppose that depends on linkage design.
    • Lightweight (duh)
  • Propellers
    • Should I use ducted/shrouded fans? What will give me the best thrust:weight ratio? Can I get more thrust out of a smaller diameter using a ducted design? Should this be under the Thruster bullet (probably)?
  • Motor control
    • I've heard a lot of good about these fancy 'brushless motors'. Seems like they would fit the bill, as they're lightweight, powerful, and super controllable. 
    • Maybe something off-the-shelf (as part of a contra-rotating assembly)?
  • Control system
    • Speed? Bit width? Platform? I don't need a ton of I/O, but I do need the system to be fast. Should I try to do the control using integral math, or should I spec the processor to handle floating-point calculations from the sensors? Again: lots to learn here. I've got a bit of experience with ATtiny 8-bit controllers, but I'm guessing they're a bit underpowered for this application.
    • Remote control system: I suspect the user controls will be fairly abstract in the control scheme; they'll bias the control algorithm but won't directly control servos or motors. More learning! At this point, range isn't a huge concern.
      
  • Power
    • Battery powered and fully independent of a tether is the ultimate goal. For the first tests, I won't try: if I can off-board the power for initial design, I won't have to worry nearly as much about optimizing overall weight of the other components (or worry about charging circuitry, battery 'care' circuits, or short run time). The first physical prototype(s) will be fully tethered and stabilized, at least until the basic stability algorithms are figured out.

Sounds like enough for a start. I'm going to think a bit more about this and maybe fire up some design tools to throw together a few rough models. I'd love some feedback, particularly from folks with the following experience:

• Quadrotors/hexacopters/DIY drones in general
• Inverted pendulum robots
• Brushless motor control
• High performance position sensing instrumentation

- Zach