Sample rate selection for digital control project

Thanks!


Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

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 (-3db) bandwidth.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

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
- Roy
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

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 won't respond.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

I was referring to the vehicles I was working on (subsonic rotorcraft).
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.
- Roy
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

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 and accelerometers.
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 null position.
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.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

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"?
Thanks Roy
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On Mon, 15 Jun 2009 19:09:18 -0700, Roy wrote:

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 mostly.
--
www.wescottdesign.com

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

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.
Thanks again Roy
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
This was done with a Parallax Propeller Chip. That is considerably more processing power than an 8 bit micro controller.
http://www.youtube.com/watch?v=4IZ5eAeneWk
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.
Peter Nachtwey
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

To be fair, I've seen similar performance out of vehicles that use 8- bit chips (PICs or AVRs). And its a pretty likely that he's using MEMs sensors.
- Roy
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

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.