Sample rate selection for digital control project

Hi,

I am trying to determine the sample rate for a new hobby project (digital control of a quad-rotor flying robot). The few references I've found seem to suggest there are no rigorous calculations available to decide the sample rate. They suggested the following "rules of thumb":

  • Use ten times the rate suggested by Shannon=E2=80=99s sampling theorem.
  • Make sure that there are four to ten samples per rise time of the closed loop system.
  • Make sure that there are 15 to 45 samples per period of the oscillating closed loop system.
  • Sampling frequency should be 10 to 30 times the bandwidth.
  • Choose =CF=89cTs to be 0.15 to 0.5, where =CF=89c is the crossover freque= ncy and Ts is the sampling time.
  • Choose the sampling time in such a manner that the decrease in phase margin of the discretized system is not more than 5 to 15 degrees of the margin in the continuous time system.

I don't have an actual vehicle, nor do I have a model (yet). I've seen data on the web that indicates the (open loop) step response of rotor thrust has a rise time of 0.1 sec, which implies a bandwidth of 3.5 Hz or so (I'm presuming the inertia of the frame will only increase the rise time). So it seems that I could get away with 35-100 Hz sampling rate (per the 4th rule)

Does anyone have any better rules or calculation procedure? What if the un-augmented system is unstable? Are there rules of thumb or calculations to select the closed loop bandwidth?

Thanks in advance, Roy

Reply to
Roy
Loading thread data ...

What do you mean by crossover frequency?

Remember that a one-sample delay is a 180-degree lag at the sampling frequency, and 18 degrees at a tenth of the sampling frequency. Remember too that processing usually involves many samples of delay.

How fast can you sample and process at reasonable cost? Why go slower than that? "Prompt" filters -- those with low delay -- will be more useful than linear phase.

Jerry

Reply to
Jerry Avins

Argh. No. Forget Shannon's sampling theorem. Shannon's sampling theorem is for communications. You're designing a control loop.

Better.

You _want_ your closed loop system to oscillate?

5 to 30, or more. Never less than 5 unless your back is against the wall and the bastards are holding your first born hostage.

You'll probably find that this is just the above rule, restated.

Ditto.

You should find that your closed loop bandwidth is higher than the bandwidth of the plant (consider an integrating plant -- it's "3dB" bandwidth is essentially zero, yet the closed-loop bandwidth of the plant isn't set by that first pole at all).

You should also find that if you wrap inner loops around your motors the rotor thrust rise time will shorten considerably, at least for small increments of motor speed. (I'm assuming that you're changing rotor thrust by changing motor speed, rather than by changing pitch).

If the system is unstable you'll find that there's a minimum bandwidth that you cannot go below without losing phase margin. You'll also find that there's a distinct bandwidth vs. disturbance tradeoff. Decide how far you're willing to let the thing fall if the wind flips it on it's side, and select your bandwidth accordingly (translating bandwidth and the acceleration due to gravity into distance is left as an exercise to the reader).

100Hz feels right, but I'd probably want to crank that up to 500Hz just for comfort's sake.
Reply to
Tim Wescott

Just sample as fast as possible. The nearer to analogue you get the better.

Hardy

Reply to
HardySpicer

... keeping in mind that as you sample faster any filters -- particularly integrators -- will need greater precision keep track of their states. (See Bruce Varley's comment in sci.engr.control, in your anti-alias thread).

Reply to
Tim Wescott

Tim (et al)

A followup question:

Yes, I am planning to fly the vehicle by altering the thrust via control of the 4 motor speeds. I had not intended to wrap inner loops around the motors themselves. I am concerned with having too much computational load (initial controller will be an 8 bit micro). I had just planned to close the loop on angular position/rate, and perhaps an outer loop on position (all via complementary filtered or even Kalman filtered IMU). I was considering using some lead shaping on the feedforward control to boost the motor response. Do you think this is sufficient or would the inner motor loop control be preferable?

Thanks again Roy

Reply to
Roy

I don't have a feel for whether it'll be sufficient or not, but in a perfect world (i.e. where both processors and engineers take infinitesimal amounts of time to complete their work), inner loops are preferable.

Good 16-bit processors just aren't that much more expensive than 8-bit ones in hobbyist quantities; even the 32-bit ARM chips from Luminary/TI aren't _that_ much more. No matter what you do you'll spend ten times more on the non-processor part of your BOM -- why cut corners on the processing?

Reply to
Tim Wescott

I would use a 32 bit CPU woth good debugging tools. The development/ debugging tools will cost more than the 8 bit or 32 bit micro controller

Peter Nachtwey .

Reply to
pnachtwey

BOM?

Rune

Reply to
Rune Allnor

Bill Of Material

Reply to
Richard Owlett

I don't disagree. My partner is the EE/board designer/microcontroller guy, and he has experience with the AVR, so that's the first board he made (I guess I'm the Aero E/controls/theory guy). I tried to talk him out of it. He did like the Luminary Board, so that may be our next board. To be fair, there are several examples of hobby and university research/lab quadrotors out there that make use of 8-bit AVRs or PICs as the main controller (but they are pretty much r/c only - not autonomous).

- Roy

Reply to
Roy

The toolset was one of my partner's concerns. There seem to be good free development tools out there for the 8-bit micros (AVR in particular). There seem to be free tools for at least some 32-bit CPUs, but we don't have any experience.

Does anyone have specific recommendations for 32-bit chips or boards? As I said earlier, the Luminary (now TI) seemed reasonable and the ARM appears to have free tools available. This is the board my partner found:

formatting link
Thanks Roy

Reply to
Roy

I've used the Luminary board, and like it. If you're working in a Windows environment it'll just fire up and go (if you're a crazed Linux nut, you'll find less support, but it's possible to use it -- in theory at least).

My personal bias when doing low volume stuff is to go with a hot processor. That way you can spend your time concentrating on the underlying problem, instead of constantly working to shoehorn the application into the processor.

Later, if power/price/space concerns motivate you, you can go to a smaller processor.

Reply to
Tim Wescott

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.

Reply to
joepierson

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

Reply to
Roy

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.

Reply to
joepierson

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

Reply to
Roy

On Jun 8, 8:30=A0pm, Roy wrote: This was done with a Parallax Propeller Chip. That is considerably more processing power than an 8 bit micro controller.

formatting link
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

Reply to
pnachtwey

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.

Reply to
Malachy Moses

PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.