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’s 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 ωcTs to be 0.15 to 0.5, where ωc is the crossover frequency 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
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Roy wrote:

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
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On Mon, 08 Jun 2009 20:30:21 -0700, Roy wrote:

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

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
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
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On Fri, 12 Jun 2009 15:40:13 -0700, Roy wrote:

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

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

BOM?
Rune
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Rune Allnor wrote:

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

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
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On Sat, 13 Jun 2009 11:56:35 -0700, Roy wrote:

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.
--
http://www.wescottdesign.com

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

You want autonomous? On the cheap? Seriously? Consider the difference in processing needed by an RC sailboat and an autonomous one. Controlling rudder and sail set is easy. Deciding what to set to is the hard part.
Jerry
--
Engineering is the art of making what you want from things you can get.

  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

...and they have lots of very smart but inexperienced students, who work 24/7 for weeks on end (with - mind you! - no pay), to get those things implemented.
No need to follow the universities' lead unless you are troubled by scores of idle PhD-level cybernetics students hanging around the front gate.

Not necessarily impossible, though. You could set a number of way-points, let the thing loose and have the autopilot visit them all in sequence.
Rune
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Rune Allnor wrote:

Indeed, but I doubt that an 8-bitter that also acts as autopilot and rudder and trim servos is up to the added requirements.
In an R-C boat, the "skipper" controls the rudder and sail positions, appropriate to wind and intended destinations (your waypoints). An autonomous boat needs to sense the wind direction and make those decisions by computation. Updating the waypoints via GPS may not be accurate enough. Will we need onboard video to replace the skipper's eyes?
Jerry
--
Engineering is the art of making what you want from things you can get.

  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

I have no idea what is required to get an airplane to fly. Maybe some sort of 'dithering' of the controls? Lack of precision in individual corrections is compensated by sheer number of corrections?

You questioned the OP's ambition of coming up with an autonomous aircraft, and then compared it with controlling a sailboat. I commented on the OP's ambition for the aircraft and disregarded your comparision with the sailboat.
Anyway, the premise for the comparision is flawed: The aircraft has an on-board power plant while the sailboat does not.
Rune
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Rune Allnor wrote:
...

A boat moves in two dimensions, an aircraft in three. I thought that a simpler problem might make the difficulty of autonomy clearer. Despite a few years of DARPA-sponsored competition among university teams, no autonomous automobile is robust enough for serious consideration.

So consider an autonomous power boat, then. Power or sail, autonomy is the sticky part.
Jerry
--
Engineering is the art of making what you want from things you can get.

  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On Sat, 20 Jun 2009 11:46:43 -0400, Jerry Avins wrote:

As Rune mentioned Roy's problem is probably simpler, or at least less subtle.
I suspect that if you know the boat's speed, position and direction, and if you know the wind speed and direction relative to the boat, that you have all the information that you need to at least competently handle the boat -- doing it with real flair would take either lots of programming, or a really good human skipper.
--
http://www.wescottdesign.com

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

Maybe we're using the same word to mean different things. I don't think of an autopilot as creating autonomy. A system that changes course from waypoint to waypoint and avoids unanticipated obstacles is nearly there.
As for wind speed and direction relative to the boat, that changes with the boat's speed through the air. On most tacks, a sail's function is redirecting air that would pass over the side over the stern instead. (When before the wind, a sail slows air that passes over the bow.) Efficient sails are traditionally analyzed as airfoils, but I think of them as turbine blades. Their leading edges should face into the apparent wind and their trailing edges should be just to windward of the stern. Their curves are intentional, not evidence of the difficulty of pulling them flat.
Nevertheless, one could sail adequately with a perfectly flat sail. For every real fore-and-aft sail, there is a flat model that acts similarly. That flat sail nearly aligns with the boom. I think it's easy to see that the best set for that sail bisects the angle between the apparent wind and the centerline of the boat. You might not win races by setting the main boom to bisect the angle between the centerline and the telltale, but you'll get where you want to go and pretty handily at that.
My (analog) RC model boat had radio control for the rudder, but servoed the sail according to the principle above. To keep it simple the boat was cat rigged (one sail, no jib) and to make it simpler yet, the sail was trimmed by rotating the mast-boom assembly with a worm gear located below deck. No sheet, no "ropes" to tangle or go slack. As long as the wind was up. it would go within 45 degrees of it; any closer, and I had to tack to get there. *But the rudder was in my hand.* It may have had an autonomous sail, but it was not an autonomous boat.
Jerry
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

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

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: http://www.luminarymicro.com/products/lm3s1968_evaluation_kits.html
Thanks Roy
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Just sample as fast as possible. The nearer to analogue you get the better.
Hardy
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On Tue, 09 Jun 2009 12:33:01 -0700, HardySpicer wrote:

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

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.