The smaller motors may have an advantage on that note, since they not only have a lower moment of a inertia than the larger motors, but also their inductance per coil is reduced (since they usually have fewer turns per coil, and I think the smaller radius plays a role, too).
One interesting thing that I did notice from the TED video was that the guys related several key components, such as lift and rotational rate, to the radius of the propeller. I should point out though that this is not exactly the case, as they've forgotten about the pitch of the propeller as well.
For those who don't know, the fastest a propeller can
ideally churn through
any media is the same speed as its pitch. Realistically, I think that the propeller itself can achieve about 90% of its theoretical maximum, and less when the drag of the craft it's pulling (or pushing) comes into play.
I know that for a fact, in an [outrageously] ideal fluid, the calculations for the craft's maximal rotational speed is (w*P) / L, where w is the rotational speed of the motor ( unit revolutions per second), P is the pitch (unit distance per revolution) and L is the distance from the craft's center of gravity (same unit distance).
even if your not regulating the motor speed that rapidly you can still sample the sensors and run your control algorithms so that when it comes time to update the motor's output you have the best solution possible to get the desired output.
That's more or less oversampling, which should have the same effect as anti-aliasing. I think, however, that the ESC's play a role here too, as the one's I've used have a Nyquist filter on them (essentially it halves your bandwidth right then and there). Computations that have a relative frequency that is higher than the ESC's bandwitdth will be tossed out... meaning you just wasted a bunch of power on calculations that you don't use.
the tricky part is that all your sensors may update at different rates, and all your control systems have electrical and mechanical delays, you probably cant sample your fps as fast as you can sample your gyro and accelerometer. any sensors that need to process a large amount of data will not be able to update very quickly. essentially all your ins and outs operate at different sample rates. you could run it all in one main loop, but you would be limited by your slowest sample rate.
This is where frequency analysis and design comes in handy. You can apply frequency filter on the algorithms per sensor. A really basic example of this doubles as a simple way of fusing the IMU data of the accelerometer and the gyrometer: the complimentary filter. What this does is filter out the frequencies considered "noise" by both sensors and fuses them into one reading, say, your pitch angle. If you did your discrete math right, you'll get a clean reading from across both sensors, with either a small dip or a small bump in the signal gains at the points the sensor's bandwidths overlap.
you kinda have to employ some degree of multi-threading so that all your inputs and outputs can be updated at their optimal rate. i dont want to even think about the kind of mayhem that causes on your control system.
Multi-threading is definitely a must in this type of system, even though the control algo's themselves are pretty much pipelined, the sensor data will be used in multiple control algo's... Top that with sensors (EDIT: and/or algo's) operating at different frequencies and voila, a need for an OS.
Oh, and it shouldn't cause much mayhem with the control system, at least with a PID or FLC type. Outputs of some controller blocks will be an input to others (like linear motion down into rotatory motion), and they all finally get summed up to the final output.
