I've worked on various military and commercial flight control systems
and 10ms update rates are common, I think 20ms was the slowest. The
fastest input sensors (usually the position sensors) have about a 25Hz
I've worked on a few military digital FCS as well. Ours were multi-
rate systems with control law code running between 20 and 50 Hz. But
I'd expect the (~1 kg, ~1 m) quadrotor to have a lot faster dynamics
than full size 10K - 50K+ lbs vehicles
you would be wrong because the 10K+ vehicles are doing Mach 3. Our
large transport aircraft, fighter aircraft and 10 pound UAVs all use
around the same update rate. In all cases you are fundamentally
limited by your input sensors and actuator response, if you are using
standard RC servo's your talking 50ms response time (no load), so if
you can't control your vehicle at those rates it will never work by
simply increasing the update rate to .1 ms rate cause the servo's
I was referring to the vehicles I was working on (subsonic
I wonder if we don't work for or with the same company - how many have
that broad a product line these days?
I also wonder if there's something about the design of the flight
control computer that makes them all run at about the same rate (as
opposed to sensor & actuator characteristics)? I'm sure you'll correct
me if I'm wrong, but I can't see the 10-lb UAV having the same sensors
and actuators as the transport and fighter.
If you look back in the thread you'll see that I'm not using servos,
but direct DC motor control. my initial thought was to base the
iteration rate on the bandwidth of the motor / rotor, but Tim reminded
me that wrapping an inner loop around the motor could be used to
increase their b/w.
A flight control loop running at 50-100 Hz will work not work if you
are using the "wrong type" of sensors, i.e., the "wrong type" of gyros
The "right type" of sensors are integrating-type sensors, whose output
is delta-V for accelerometers (i.e, not acceleration) and delta-theta
for gyros (i.e., not rate). These sensors work by maintain a mass (or
spinning mass) at some null position using an internal control loop.
The output of the sensor is the control signal needed to maintain the
With such a sensor, low rates for the control loop are possible, since
the sensor itself has integrated out all the high frequency details
that would otherwise cause problems (Nyquist etc).
Low-cost MEMS sensors (of the type that probably would be used by the
OP) are the "wrong type" of sensor. These sensors do not have an
internal control loop that maintains the mass at a null position.
Rather, these sensors allow the mass to displace, and output an open-
loop signal representing the displacement. As such, they measure
instantaneous values of rate and acceleration, and do not integrate to
delta-theta and delta-V. In addition, since the masses are typically
very small and undamped, the instantaneous values of rate and
acceleration are particularly prone to high frequency content, such as
actual content caused by vehicle vibration and the like, and non-real
content caused by electrical noise and the like. As such, these
instantaneous measurements come with all the downsides of digitally-
sampled systems (again, Nyquist etc), multiplied by actual vehicle
dynamics such as high-frequency coning and sculling motions. And as a
result, a much higher rate is needed for a flight control loop that
uses such a sensor.
In past work, we have used a 600 Hz loop frequency for the flight
control loop of a system that uses such MEMS-style sensors. We in
addition ran a strap-down navigation calculation using quaternions
that were updated crudely at the 600Hz rate, but which were normalized
and used at a much lower 100 Hz rate.
Yes we will be using MEMS sensors, at least at first because they are
the "right price". This project is essentially a radio controlled toy.
Can you give me more details on the distinction between "delta-V" and
acceleration, or "delta-theta" and rate gyro outputs, and how such
sensors are able to get around the Nyquist "problem"?
Rate integrating gyros have an electromechanical assembly with a rate
input, and a control loop that maintains the gyro wheel centered within
the case. The rate output from the system is a filtered version of the
rate command to the gyro itself. Nowadays this rate output is integrated
for the duration of one sample time, so aside from control loop bandwidth
issues it a fairly close measure of the angle through which the gyro has
passed in that sample time.
Force balance accelerometers have a force (i.e. acceleration) input to
the electromechanical assembly, and a control loop that maintains the
proof mass centered within the case. The acceleration/delta-V output is
very analogous to the delta-angle output of a rate integrating gyro.
One approach wit MEMS sensors would be to sample your sensors _fast_
(i.e. well above their bandwidth), sum up their readings within the
controller's sample period, then decimate at the controller's sample
period. It's basically a one-step CIC (cascade integrator comb?) filter.
Another approach is to just sample, and accept a high level of noise.
This may be good enough, if you're just looking to keep the thing upright
Using a CIC filter (or some sort of averager) was our concept as
well. I think it may have to wait for the 32 bit processors - I doubt
the 8-bit can handle the iteration rates, and the ARMs seem to have
some capability to do A/D and perhaps even averaging in the
"background" (without requiring direct s/w intervention). We'll
probably always be stuck with MEMS sensors, however.
I'm fairly confident we can get something to behave "good enough" with
the AVR (similar to the video that Peter posted) from a radio-
controlled standpoint. For fully autonomous operations we'll almost
certainly need the 32 bit chips.
This was done with a Parallax Propeller Chip. That is considerably
more processing power than an 8 bit micro controller.
I doubt that sample time is an issue with the Propeller chip. As
pointed out above there are probably other devices that are much more
limiting when it comes to response.
Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here.
All logos and trade names are the property of their respective owners.