PDA

View Full Version : Discussion Transfer Function of Servo motors


ashvani
Apr 24, 2007, 04:07 AM
Hi,
All the people making UAVs must have found out transfer function of their servo motors... Can anyone share the TF for any servo?

TIA

alexcmag
Apr 24, 2007, 07:44 AM
The simplest approach with ready-made parts is to make a simple switch (like a glow-driver or landing-light switch, there is a lot of circuits with or without MCUs here), an inverter (or a simple program change) and a pair of 4066 "quad-bilateral switch".

http://www.rcgroups.com/forums/showthread.php?t=658435&highlight=glow+driver
http://homepages.paradise.net.nz/bhabbott/navlights.html

CD4066 datasheet: http://www.farnell.com/datasheets/67081.pdf

Each CD4066 has 4 channels and was designed for analog circuits like audio receiver input selection. You can use one CD4066 to auto-pilot and other for RX.

Each port when active will give you low impedance, when inactive it is very high impedance, so it can switch to one or other source without trouble.

This is the basic approach, I did it to a local college when they asked me a quick solution, so I used the code I already have, since there was not time to testing.

I'm working on a PIC program to read PPM input from receiver and send to auto-pilot (it will need to know what are the servo neutral positions), read serial input from auto-pilot and according to channel 5 on receiver will give control to the AP or to the RX. The default is AP since it will have a "back to home" feature.

The attached zip is a simple C code for PIC12F675.

Pin 1 is VCC,
Pin 8 is GND
Pin 4 is the input, servo pulses below 1.4ms will select AP, over 1.6ms will select RX
Pins 7 and 3 will be high when RX is selected.
Pins 6 will be high when PPM input is valid
Pins 5 and 2 will be high when Auto-pilot is selected or signal is lost.

#pragma bit ledok @GPIO.1
#pragma bit ledrx @GPIO.0
#pragma bit ledap @GPIO.2
#pragma bit outrx @GPIO.4
#pragma bit outap @GPIO.5

Unterhausen
Apr 25, 2007, 10:34 AM
here is my transfer function: 1
There you go, saved you a lot of time I'm sure. I don't think you really need a transfer function. When they are working correctly they seem to be right around critically damped. I just say that because they do oscillate when they go flakey.

ashvani
Apr 26, 2007, 03:59 AM
@Unterhausen

Have u tried using servo TF: 1 in any Autonomous UAV ?

dian
Apr 27, 2007, 02:43 AM
Try this filter.
Dian

ashvani
Apr 27, 2007, 06:36 AM
I have done some tests on servo S3151 (digital servo) with load and no load.

From attached figures, it is clear that 4th order fits the better than 2nd order. Though, dynamics suggest it to be exponential or 2nd order polynomial.

Do you think, 4th order is appropriate??

ashvani
Apr 27, 2007, 06:39 AM
forgot to add...

attached response is for the step input from radio stick.

Unterhausen
Apr 27, 2007, 11:20 AM
unless your airplane has very fast dynamics, the servo dynamics are not significant. Then it becomes an academic exercise. Trying to fit a polynomial is not going to get you where you want to go, particularly since you didn't give it enough of the start and end states to fit properly. You need to try to estimate the parameters of a differential equation, or if you are going to go in the sampled data domain, a difference equation.

Fitting a first order lag or a critically damped second order TF to that data should give you better results and lower complexity. I don't know what you intend to do with the polynomials, but you can see they don't act right at the ends. The correct behavior is modeled perfectly by a second order differential equation.

ashvani
Apr 28, 2007, 03:29 AM
i guess u r right ... my platform is conventional one.. not with very fast dynamics.. .. so digital servo with TF = 1 should do the job.

nichanderson
May 30, 2008, 02:46 AM
I've been doing some work with servo transfer functions, and I can say it does make a pretty big difference. Attached is step response plot for a Airtronics 94751 digital servo. That is defintely a non linear response.

The model overlaid on the data points was developed in simulink, and consists of a rate limiter, the transfer function and saturation limiter..

Nick Anderson

Unterhausen
May 30, 2008, 09:53 AM
when you say that it makes a big difference, do you mean to say that it makes a big difference in your aircraft flight response?

nichanderson
May 31, 2008, 04:55 PM
It makes a big difference in the output from your aircraft dynamics model. For anything other than small displacements, small perturbation theory (linear TF) is not useful. You need an accurate transfer function for your servos, along with a max angle for your control surface to develop an accurate response from the aircraft dynamics model..

Nick Anderson

jetblackaircra
Jun 01, 2008, 01:29 PM
Here's my two cents.... but let me preface it with this:

I do have a BS in aerospace engineering with an emphasis in aero vehicle controls as well as several years experience in designing aero control systems....

But, get your head out of a text book for a bit and quit running simulations... or here's a better one. If you're so worried about simulating your system to that level of detail I have four words for you: Hardware In The Loop. Or how's this? measure your servo response and model it, I'm sure they're all slightly different.

I guess my point is that I don't care how much you model a system, you're going to have to tune in on the actual hardware at some point. You will never be perfect with your simulation. That's why in the aircraft industry they do a lot of hardware in the loop sims. Easier, faster, and more accurate than a full simulation.

matttay
Jun 01, 2008, 02:40 PM
It makes a big difference in the output from your aircraft dynamics model. For anything other than small displacements, small perturbation theory (linear TF) is not useful. You need an accurate transfer function for your servos, along with a max angle for your control surface to develop an accurate response from the aircraft dynamics model..

Nick Anderson

I think what you run into is that servo responses, analog or digital, is much, much, much faster than the natural frequencies of the model. If you turn the gains up on a elevator PID, and subject it to a step function, I think you'll find most models will exhibit a damped sine of about 1 Hz, perhaps even slower (my easystar is quite a bit slower).

I think we've all seen a movie of a fast motorcycle where the steering is oscillating quickly just before the rider loses control. This is called wobble, and as it approaches 3-4 Hz, even experienced racers will begin to have problems. At 8-10 Hz, there will probably be a crash. I'd be very surprised if anyone was flying an RC model that was "looser" (faster response) than a racing motorcycle. I say this only because the 50 Hz frame rate inherently limits the natural response of the model to perhaps 3-4 Hz. On top of that, if a model does have a very quick response, then you would not expect to EVER see massive changes in flight surfaces. It'd be very small changes of just a few degrees. On my easystar, the autopilot typically oscillates around +/- 10 or 20 uS of elevator to hold altitude over the short term. This is about 1 or 2 trim adjustments. In terms of angle, it's a few degrees at most. I need to look very, very hard to see this.

Also, in playing with an autopilot driving a variety of airplanes in FlightGear, whether or not the output to the control surface is delayed by 20 mS just doesn't matter at all that I can see.

Thus, good ol' engineering experience tells us that if something is 2 orders of magnitude faster than the loop response, it can usually be safely ignored.

Unterhausen
Jun 01, 2008, 10:03 PM
be interesting to see what the frequency response is. An autopilot that puts 90 degree steps into a control surface is in pretty big trouble, and guaranteed to hit a rate limit. It's also guaranteed to be going back the other direction right away.

I'm just thinking from my acrobatic models which have pretty big throws; if I cycle the sticks on my Tx as fast as I can, the servos track perfectly to the best of my ability to observe it. If I were to do that in the air, the plane would depart quickly, as I've gotten pretty close to demonstrating when I took off with high rates.

I can see throwing in a second order critically damped system with rate limiters into a model for simulation, it's not that big a deal for today's computers. If you do controller order reduction after the analysis is all done, I'm thinking those dynamics probably would be gone. From what I've seen, there are plenty of UAVs flying successfully with no compensation of aircraft dynamics built into the controller at all. Which doesn't exactly make me happy.

dmgoedde
Jun 02, 2008, 09:49 AM
Based on extensive Beta testing of the AttoPilot, I firmly agree with the guys here that take the approach of hardware in the loop. In practice, the servo transfer functions and flight control just aren't that complicated. I'm only using simple PID where the error term comes from target vs actual for pitch and roll angle, I reset time is on the order of 0.2 seconds (because the smaller planes have pretty fast dynamics) and actually currently D term is not used. In the end, every airframe tested with Atto pilot has been easy to tune for good pitch and roll control, from 12 ounce MAV's to 7 pound LT-40, merely by relatively gross adjustments of the Kp gain.

The one take away that hit me in this thread is a reminder of a thought I had last year but have not implemented in the Atto code: position change rate limit for the servos; not allowing the commanded servo position to change more than some upper limit per 1/50th seconds. Properly used, it will give equivalent flight control, yet minimize wasted power draw from servos, and extend servo life and reduce gear wear and tear.

Dean

Unterhausen
Jun 02, 2008, 12:42 PM
I agree about limiting the servos. Just listening to the crossbow autopilot hammering on the servos as a result of noise is a little disturbing. I guess on most micros, limiting the travel is probably the most efficient method of implementing this, you could also just low pass filter the outputs.

dmgoedde
Jun 02, 2008, 02:32 PM
I agree about limiting the servos. Just listening to the crossbow autopilot hammering on the servos as a result of noise is a little disturbing. I guess on most micros, limiting the travel is probably the most efficient method of implementing this, you could also just low pass filter the outputs.
Hmm it just occured to me that because thermopiles have a response time of around 1/40 second (give or take, depending on how it is made), there is a built in jitter filter right there. The angular error simply cannot jump very far really fast or jittery. I have never seen Atto hammer the servos. Of course when I get that 200Hz Kalman filtered IMU up and running, I may need to implement servo rate limits.

ashvani
Jun 18, 2008, 12:47 AM
my experience is tht as long u have slow dynamics fixed wing aircrafts.. the PID does the job... and u don't have to worry about servos response.. bcz its much much faster than the craft dynamics..

but if you want to design optimal control or anything further sophisticated for the UAV then for simulation purposes u need to consider the servo response.. else it doesn't give u what u want...