Thread Tools
Nov 12, 2011, 02:12 AM
OlliW
Thread OP
Discussion

The Heli Gyro as a Controller: Theory and Experiment


Hey Folks,

I'd like here to expose my understanding of what a heli gyro is doing from the view point of controllers. So, what I don't want to discuss is what a gyro is and what it is for and how you use it and how you install it and how you set it up... we should assume here that we all perfectly know what a gyro is. I want to look here "inside" the gyro, i.e., the algorithms used in the firmware of the gyro. Inside I believe you'll find a (PID) controller, and that's what I'd like to discuss here.

At this point you may ask what are my qualifications to do that. Well, none. It's hobby. The only source of information is the web, but, if you spend time and dig deep enough, it's amazing how much high-level information can be retrieved (so, I am not talking about Wikipedia's controller pages ). So, my "qualification" is to have spend significant time with diging deeply into the web and to have combined the available information to a story which makes sense.

It is clear that I, as essentially all of us, do not really know what is implemented in commercial gyros. However, I think it is a very good guess that it are PID controllers, or variants and descendants of it.

My interest into this started in my coax times, where I built what I called a 4-1+2in1 about 1 1/2 years ago, a project which developped into what I called a coax-gyromixer. So, I am on programming gyros for coax heli's since some time, it's however only since recently that I got serious also with cp gyros, because my flying skills allow now to and because of the emergence of the GA250 gyro, which is perfectly suited for DIY projects (see here http://www.olliw.eu/2011/gyro-ga250/).

At this point I should mention cruzado's GA250 firmware project: http://freecode4ga250.blogspot.com/. You'll find also a thread here in this subforum. Also, I'd like to mention my own project on an alternative firmware for the GA250: http://www.olliw.eu/2011/ga250-gyro-firmware/ or the rcgroup thread here. Obviously, for the latter I worked out the stuff below.

Before I'll get into the gyro controller thing, I actually like to say this:

You'll find a lot of threads on gyros and fbl, with tests and tips. I mostly don't like them, because, to be honest, the way how conclusions are drawn there is IMHO often "middle age". I hence want to mention my "philosophy". It seems that two different points are easily confused, namely what is what the heli is doing or can do, and what is what the gyro is doing or can do. The pivotal example here is "back bouncing", which seems to have become kind of a mantra. I think there is a simple test: Compare the stop performance in rate mode with that in heading hold mode. In rate mode you (essentially) see what your heli is capable of doing. If you don't get the same stop performance in hh mode, well, then it's not the heli but the gyro... . So my philosphy is simple, the tail should be as bounce-less AND crisp as possible; it's easy to trade one for the other .

I understand that this comes as a provocation, but that's my opinion, and certainly, you don't have to agree.

It will probably be useful to indicate my flying skills. Well, I am not into 3D, I am certainly not into 3D, I may never get there, but I think I am an advanced cruiser. I am currently practicing inverted flight, but have not mastered it yet. I should also mention that I am flying a 450er (with paddles), no 250, no 500, no 550.... So, I guess I am pretty much a standard flyer, with standard setup, and standard demands as regards flying power/performance.


In the following I will first talk about the rate gyro, which will be short. I will then "derive" the heading hold gyro. This will result in (IMHO) important conclusions, in particular for tuning. It will show e.g. the problems in developing a hh gyro and why a hh gyro tends to back bounce. I have mentioned some conclusions before in a couple posts here at rcgroups, but people often didn't believe or made fun of it. This is of course perfectly fine, I understand that it sounds silly what I am saying, but I will thus support the claims by experimental data, which I record during flight with a "gyro-tester-telemetry" unit, as well as simulation results.

It will take me some time to post all this here, but it will come ASAP.
Last edited by OlliW; Jun 30, 2012 at 01:41 PM.
Sign up now
to remove ads between posts
Nov 12, 2011, 02:12 AM
OlliW
Thread OP

The Basic Rate Gyro


I will here present what I believe is the basic controller of a rate gyro.

Whenever one enters the design of a controller, the first question one has to answer is, what is the variable which should be controlled? Almost always the answer is simple and obvious. The control variable of a temperature controller is - right - the temperature. You got it. The control variable of a rate gyro is - right - the yaw rate.

The basic controller for a rate gyro is a P(ID) controller for yaw rate.

In fact, in my experience with my own modded GA250, a simple P controller does give already a good flight behavior. Hence I wrote P(ID) instead of PID, to emphasize that the ID parts of course would allow to enhance the performance, but the additional efforts for tuning are IMHO not worth it.

I have made a figure to describe that a bit better, and also to introduce my notation:


I think the picture is telling enough. There is one point, however, which will become crucial below:

With respect to the yaw behavior, the helicopter is a "self-regulating process".

I think I don't want to explain here what this is; by just entering the buzz word into google you'll get excellent descriptions. In simple words, a self-regulating process is a process which will stop by itself or reach a stable state if you don't issue a command (i.e. set point change). In the case of the heli this just means that if you don't pull the rudder stick the heli doesn't yaw, and if you move back the rudder stick to center that the heli will stop to yaw. So, not really spectacular at this point.

A self-regulating processes may be modelled in different ways. The simples model is that of a PT1 process, but I will show you below by experiment that a heli (i.e. my heli) cannot be described as PT1. Some delay and/or deadtime is present, which points to the PT2 and/or FOPDT models, but PT2 will also be shown to not be realized. So the simplest appropriate model for our heli is FOPDT. It is, by the way, also the standard model for self-regulating processes, and essentially all tunning recipies which you have heard about are made for FOPDT (I am sure you have heard about Ziegler Nichols and it's improved versions ).

With respect to yaw rate, a heli can be described as a FOPDT process at the lowest level.

The FOPDT model is only the most simplest approach to describe the heli. I do in fact see behavior which is not correctly described by this model. However, my experimental facilities do not allow me to record good enough data to develop a more precise model, and - in fact - I don't actually want to go deeper into that (where are also other projects waiting ). I rather accept the limitations of the FOPDT model and will happily live with them.
Last edited by OlliW; Nov 12, 2011 at 01:26 PM.
Nov 12, 2011, 02:13 AM
OlliW
Thread OP

The Basic Heading Hold Controller


I will here present what I believe is the basic controller of a heading-hold gyro.


1. "Deriving" the heading-hold controller structure

As before for the rate gyro, the first question we have to answer is, what is the variable which should be controlled? For hh the answer seems to be less obvious, at least that's already the point there people start to "disbelieve". So, let's think this through more carefully.

Let us first consider what we expect the heli to do with a hh gyro. Clearly, we expect it to hold the direction whatever what. However, direction just means the angle. We can check that: if we do a pitch pump, then the tail will break out, i.e., it will yaw. A rate gyro will work to get the yaw back to zero, however, the tail will have moved a bit to the right, but since the rate gyro works to get the yaw to zero, it will obviously not try to bring back the tail to the original orientation, since that's not possible with zero yaw. In contrast, with a hh gyro we expect that it brings back the tail to it's original position, so we don't expect it to get the yaw rate back to zero, but to first induce a negative yaw and only once the original position is recovered to get back yaw to zero. Clearly, a hh gyro cannot be a controller for yaw rate. It is a controller for the yaw angle.

The basic controller for a heading hold gyro is a P(I)D controller for the yaw angle.

Technically we do that by intergrating the signal from the gyro sensor (the gyro sensor measures the yaw rate, and the integral yields the absolute angle).

However, a "problem" appears now. If we just would build a controller with the signal of the gyro integrated, then the rudder stick would command changes in the absolute angle! You can find this operation mode for multicopters, but that's not what we want for a helicopter. Here we clearly want a rudder stick command to result in a change of the angle. Well, what we have to do is to also integrate the rudder signal and to feed this to the input ouf our angle PID controller. This way we have build a controller which aims at keeping the angle = orientation of the heli upon distortions, but there the rudder stick sets the yaw rate. That's exactly what we want. I have sketched the resulting controller structure in the next picture:


In principle, this was it already. I find it however most insightful to further analyse the resulting controller structure. The following is actually based on a simple (mathematical) trick, namely that in a closed loop you can "move" the blocks to different positions in the loop if you obey some rules (which I don't want to outline here, you can find that in any text-book text on controllers, please scan google).


2. The headinhg-hold controller structure for implementation

The first thing to observe is that the just presented controller struture I is not suitable for practical implementation, as it would suffer from overrun or the 360 mutliplicity of the angle. Fortunately, this can be avoided by using one of the tricks, namely that the two integral boxes which you find before the "-" box can be combined and moved behind the "-" box. This way only the difference between the angle signals from rudder and gyro is considered (u' = y' - w' in my figure), which is (supposedly) always small. I have sketched the resulting controller structure II again in a picture:


Now, by playing again tricks we can arrive at the following two controller structures III and IV. The trick simply consists in absorbing the integral box (i.e., the 1/s) either into the controller (yielding structure III) or the process (yielding structure IV). It is important to remember that these structures are absolutely equivalent to the original structure I!

Let's first discuss the structure III. Here the integral box is absorbed into the controller. The result is funny, namely it tuns our "original" PD controller into a PI controller:

original controller: C(s) = P + Ds

"new" controller: C'(s) = 1/s * C(s) = P/s + D = I'/s + P'

From the controller prespective, the I term of the implemented controller is in fact a P term, and the P term acts as a D term.

This sounds silly. It sounds exactly like mathematical tricks tend to sound. However, this observation is in fact crucial,since it affects how you have to tune the controller, and it's a main message of all this here. Anyhow, whatever the interpretation of the PID terms, the controller structure III is obviously the one to be used in an implemantation. I mean, how to implement a PID controller is standard, and algorithmwise that's certainly the right thing to do also for a hh gyro. As before, I have sketched this controller structure III in a picture:


I'd like to point out again the "mysterious twist" in all this. I mean, you would have considered a PID controller anyway for a rate gyro, while here I have made now a big fuzz just to "derive" the very same controller you would have considered anyhow. So, what's all this about? Well, it's about how one has to tune the PID parameters.

Depending on the tuning of the PI(D) parameters you get a rate gyro or a heading hold gyro.

So, it has to do with the interpretation of the PID terms (i.e. this funny I is P and P is D statement), and it has to do with the tunning rules. All this may nevertheless still look strange at the moment, but the later posts will (hopefully) clear this up.


3. A controller structure appropriate for "understanding" the heading-hold gyro

Playing the same trick in another way provides a further stepping stone, namely instead of absorbing the integral box into the controller it may also be absorbed by the process, which yields the structure IV. The controller is hence not modified, it's still the PD controller we started with, and the P and D do exactly what you expect them to do and how it's described in all basic controller articles. Here again the picture:


However, crucially, the process has changed! It is not a self-regulating process anymore, as it was for a rate gyro, it is now what is called an "integrating process".

With respect to the yaw angle, the helicopter is an integrating process.

I will again not explain here what this exactly is, please use google. But it's really the relevant point. As in theprevious post also an integrating processes can be modelled in different ways. The simples model is that of a I process, but it's kind of obvious that it's no appropriate since some delay and/or deadtime is always present. This points to an IT1 process as simplest model. If however, we use the FOPDT model we concluded for our heli in rate mode, we would get the IT1DT model. From my experiments I cannot clearly decide which one has to be used.

With respect to yaw angle, a heli can be described as a IT1 or IT1DT process at the lowest level.

So, if you want to understand how a gyro in heading hold mode operates, you have to look for the literature of integrating processes and IT1 processes in particular, and if you want to know how to tune your gyro in order to have it operating in heading hold mode, you have to look for the tunning rules for IT1 processes. And if you do so, you will find quite different rules than the Ziegler-Nichols rules. Just to throw in a buzz word, which you may scan by google yourself: symmetrical optimum.

With this consideration the "mysterious twist" may clear up a bit: If you tune your implemented PID controller as you may have read it in all the basic articles, you will end up with a perfectly tuned - rate gyro (all the "standard" PID articles out there for RC people expose the set of rules developped for self-regluating processes, for which the Ziegler-Nichols rules are kind of synonym). If however you tune your implemented PID controller with having the I=P,P=D and IT1 comments in mind, you will end up with a heading hold gyro.

You may have noticed that I have not said that you will end up with a perfectly tuned hh gyro (as I did for rate). You will in fact not find the result perfectly tuned, because you will have "a lot" of back bouncing (or a soft tail)! I will try to show that in the following posts, but the basic reason you may see already now: If the tunning of the PID controller is different depending on whether you like to get rate or hh mode, and if a perfectly crips tail is the result of the rate-mode tunning recipe, then the hh-mode recipe cannot give a perfectly crisp tail. In fact, as compared to rate mode, the I term has to be substantially increased in order to get a good hh tracking, which leads to overshot and oscillations which you note as back bouncing.


4. The basic heading-hold controller structure

There is a standard procedure in the literature (use google ) to at least somehow deal with that, namely to introduce a prefilter (e.g. a T1 filter, or an acceleration/deceleration limiter) in the rudder channel. It is important to realize that this should NOT go into the controller path and/or the feedback path! Again the picture:


Such a prefilter allows one to reduce the overshot or back bouncing, but, of course at the cost of slowing down the response, i.e., the tail won't be as crisp as the heli would allow it to be (see my "philosophy" of comparing to the rate mode!).


5. Conclusions

OK. So that's where I want to stop, I believe that the structure V is the approrpiate basic structure for realizing a hh gyro, and from my experiments it provides quite good results. It has however an intrinsic problem in that it doesn't provide a most crisp tail. But that's IMHO not a problem of the particular structure, but fundamentallly related to the fact that the heli represents an integrating process in hh mode. The structure may obviously be further improved by additional (obvious) blocks, feed forward and gain scheduling are probably the most important/obvious to name here. They allow to further improve the crispness, but they actually do not overcome the basic problem.

It seems to me, that even the better commercial gyros are build on these structures, although I am also kind of sure that the really "good" gyros employ some further tricks (I have some ideas here). As regards the "cheap" gyros, I get the feeling that many of them do not obey the simplest rules. I have tested for instance the GY520, which attracted positive response, but find it on my heli absolutely bad (in comparison to which the good old KDS800 performed impressingly well).
Last edited by OlliW; Nov 12, 2011 at 10:43 AM.
Nov 12, 2011, 02:13 AM
OlliW
Thread OP

Experiments I


PS: if anyone knows how to link in these figures with a smaller size, I would greatly appreciate this.
--------------------

So, now I like to show how I recorded some relevant data and present some first results.


1. Helicopter used for the testing

I of course didn't wanted to disrupt my beloved TRex for this project, so I build up a second heli from the parts in my trash box. Some new parts had to be bought of course, but the mechanics remained quite a mix of CopterX, HK450Pro, and Align. And it's not really good, but it allows to fly around.

Some few infos, which might be considered relevant: tail servo DS520, besc Robbe Roxxy 950-6 with gov on; motor hobbymate HB2835 3800 kV, pinion 13, ca. 2900 rpm at idle down and 3200 rpm at idle up, but the rpm varies a lot depending on the charging state of the lipo and can be as low as ca 2500 rpm at the "end" of a battery.


2. Gyro tester telemetry unit

I wanted to record relevant data during flight. Hence I missused a GA250, which I reprogrammed accordingly, and linked it to a RFM02 868MHz transmitter. At the other end of the line I missuse my DIY telemetry reciever, which is hooked up to a PC for data recording. How the gyro tester is installed and how it looks like is shown here:


The GA250 gyro tester unit allows me to measure the yaw rate, the rudder signal length, and the servo signal length. I found it crucial to get a high data rate, currently it's 20 ms. It shouldn't be any slower as you will see, but unfortunately it's not easy to get it significantly faster. Each data packet is transmitted together with a time stamp, which has a resolution of 1 ms. Unfortunately I can't currently record also the rpm of the main blades; that's not possible with the GA250 hardware and would need a second uC (if one wants to stick with AVR).


3. Relay experiments

In the literature one can find many procedures for determining parameters which can then be used for a proper tunning (process modelling). The most widely known procedures are probably the open-loop step response and closed-loop ultimate gain methods (see Nicholson Ziegler). I did both, any will show data below, but I want to start with another technique which is known as relay tuning. It's beautiful as one doesn't actually have to do a lot. In this technique the PID part in the controller is replaced by a simple relay, which "flips" the servo signal between -h and +h depending on the sign of the error (u in my above figures). The result is a permanent oscillation of the tail, with a certain amplitude A and period Tu. These parameters are related to the underlying process model, which I will assume here is FOPDT.

The first picture in the following shows data of such a test, just to give an impression of what's actually recorded. The gyro signal is not well seen because it's buried by the rudder signal in the plot. The "pulses" indicate the times at which I had switched from normal gyro operation to relay mode and back. The second picture shows the recorded data for one of these "relay on pulses" in more detail, and how I have analyzed the data in order to get the amplitude A and period Tu. I also tried an fft analysis of the data, an example of which is shown in the third picture, but didn't found this precise, so I sticked with the "time domain" analysis.




A first result of this experiment is: Oscillation does occur! Hence, a P, PT1, or (non-oscillating) PT2 model can be ruled out as these would not yield (undamped) oscillations. The FOPDT model is thus indeed the most simple model for my heli.

The period Tu does coincide (according to theory) with the critical period as it is used in the a-la-Ziegler-Nicholson tunning methods. The critical gain Ku is obtained as Ku = (4 * h)/( pi * A). However, these are not the most interesting values to know, I would rather prefer to know the parameters in the FOPDT model, i.e., the process gain Kp, the dead time Tt, and the response time T1. Obviously not all three can be determined from Tu and A alone. Let us see later what we can do here.

At one day I did such relay experiments quite extensively; I'd like to share with you the results for servo amplitude h = 192, where I actually ran the servo also at different frequencies, 333 Hz, 250 Hz, and 55 Hz. The results are summarized in the next picture:


The first thing to note is that the results for "one and the same settings" appear to be not reproducible, e.g., for 333 Hz three values are obtained. I believe (strongly) that this is related to the fact that the rpm is not the same in these experiments! There are several indications for that, I don't want to go deeper into this.

The second thing to note is that for 333 Hz the critical period is about 160 ms, which gives us a first idea of the time scale with which we are dealing here (the value is for my heli, but I think it would be similar for "all" 450er).

The third thing to note is that there seems to be a trend with the servo frequency, e.g., the critcal period gets longer with lower servo frequency. Well, this makes of course a lot of sense, and is not surprising. However, I like this result because it does IMHO demonstrate that the data and adopted analysis does indeed provide reasonable results/information.

The fourth thing to note is that the critical gain is about 3-4 (in the units used here).

All these values should be used with a sufficient error margin. Nevertheless, this simple experiment gives us quite some useful information on the dynamics of the heli, i.e., the process which we wish to control.


4. Open-loop step response experiments

I knew that this experiment is going to be "dangerous" and "difficult", I mean, you have to fly without any gyro help... but yet I tried it... once... and I am not going to repeat that.

I had finally set the dual rate to 10% in order to keep the reponse of the heli to a reasonable yaw rate, and it would respond very "lethargically" yet I could not get it to reach the "self-regulation"... see for yourself:


The conclusion is that in order to get a reasonable step-response result one has to use very small steps, maybe dual rate 1%, but I strongly doubt that the dynamics of the heli at this small commands is of any relevance for a proper tuning of the gyro. One information might be extracted, namely that a step of 40 in rudder yields a yaw-rate "step" larger than 300, which suggests a high process gain larger than 8. That's good to know, but we would have guessed this anyhow... BTW: This funny modulated yaw response for positive yaw I have consistently observed, which would indicate that the FOPT model is not perfectly realized.


5. Closed-loop ultimate gain and step response experiments

I've of course also tried the classical closed-loop ultimate gain method to determine Tu and Ku. With a servo frequency of 333 Hz I actually did not reach the ultimate gain (I should have implemented a quadratic instead of a linear gain dependence). Apparently the gains I have implemented had been to low to induce undamped oscillations. However, with a servo frequency of 55 Hz self oscillations was obtained at the highest gain (0%). This is shown in the next figure:


This finding is quite consistent with the relay result and intuitive expectation. With a lower servo frequency the tail can't respond as quickly, hence the possible gain to reach oscillation is smaller. However, the period of the oscillations is determined to ca. 120 ms, which is significantly smaller than the 180-195 ms found in the relay experiment. What does this tell? Well, it tells that the FOPDT model does not perfectly describe my heli. On the other hand, these times are on the same order, so they give us a good idea.


6. Closed-loop step response experiments in rate mode

I have also done what one would do first, namely to measure the behaviour for sharp stops, since this directly shows the crispness and back bouncing of the tail. In the following a simple P controller (rate mode) was implemented. The first picture shows the data of a complete step-response measurement run. I actually didn't find it easy to produce a sharp and reproducible rudder step, so I had to practice this for almost half a day. Each step below produces a (ca.) 360 turn. In the second picture I show the step responses for six gain settings in detail.



A couple of things are noteworthy. First, a 360 turn takes ca. 0.7 s corresponding to a yaw rate of ca. 515/s. The gyro sensor has a sensitivity of 1 V per 440/s and is connected to a 10-bit adc with a reference voltage of 2.7 V. Hence 515/s corresponds to a voltage of 1.17 V or an adc signal of 444, which is very close to the height 414 of the rudder step. The measurements are hence perfectly consistent.

Secondly, at the highest gains oscillations are obviously present, while at the lowest gains the tail responds very sluggishly. The intermediate gains would be the ones one would choose.

The data, in particular those at the highest gain show also an asymmetry in the response, namely for positive yaw steps the process gain seems to be smaller as the response is more oscillating. I have observed this consistently for this heli (you note this also without any measurements!).

It is now also interesting to carefully inspect the gyro signal after the rudder stick has been released to center. The data for 20% gain may serve as example. At the first step a short overshot is seen, which indicates a bit of back-bouncing. However, in this case its really minor (look at the red signal!). For the 30% gain setting no overshoot or back bouncing is observed, yet the tail stop very quickly. A gain inbetween 30% and 20% feels (to me) quite "perfect", very crisp and no back bouncing.

These data show us what the heli can do, and according to my "philosophy" I will use them as reference to judge the hh mode behavior.
Last edited by OlliW; Nov 14, 2011 at 02:30 AM.
Nov 12, 2011, 02:14 AM
OlliW
Thread OP

Simulations


Here I will show and discuss some simulation results.

This post actually became possible only last week... before I was doing my considerations analytically, with a pen and a piece of paper, but I thought it would be helpful to also produce some simulated graphs... so I started looking around. The first thing you cross is Mathlab/Simulink, but it's ugly expensive... however, there is also Scilab/Xcos... and it's for FREE... a full fletched GUI based simulation software for FREE! I am always amazed what cool stuff one can find on the web, so I became a Scilaber.

1. Relay simulations

One obvious thing to do is to simulate the relay experiments, which yielded Ku and in particular Tu. At this point it's useful to talk a bit more about the relation of the FOPDT parameters Kp, T1, and Tf, and the resulting Tu and Ku. You find the following relations (but be carefull in scanning the web, most often one finds an equation for Tu with an arctan, as it is most easily derived, but it is not very accurate...):

(1) ( Kp * Ku )^2 = 1 + ( 2*pi * T1/Tu )^2

(2) Tu = T1 * 2 * ln[ 2 * exp(Tt/T1) - 1 ]

Tu is obvioulsy determined by T1 and Tt, but in a nontrivial manner. Interestingly, if Tu is given, the deadtime Tt must assume values between 0.25*Tu and 0.5*Tu (for T1>>Tt and T1<<Tt, respectively). For Tt = T1 we find Tu = 2.978 Tt. So, from our (ca) 160 ms determined before we conclude Tt = 40 ... 80 ms. That's quite a long deadtime, which indicates that the FOPDT model is indeed not the last word (we should use SOPDT), but well, it's not completely wrong either. So, I did a simulation with Tt = 40 ms, and found T1 = 1.0 s and Kp = 10 to reproduce the recorded data, see for your self:



Wau, I think this looks quite close to the data in #4.3, doesn't it? However, one can also get equally good results with other values, e.g., Kp = 0.6 and T1 = Tt = 53 ms. This points to the fact, mentioned already in post #4.3, that with two values it's "hard" to fix three parameters. However, we should assume a large process gain Kp, and the first parameter set is "better".

The FOPDT model yields simulations close to the data, and the extracted parameters are in the right ball park, but we should not expect that they are invariant for all simulated situations as the FOPDT model is only approximate.


2. Rudder step response and disturbance response simulations

Having now estimates for the parameters in the FOPDT model I tried to simulate the step response data shown in #4.6. I found the simulation results to look a bit closer to the data with Tf = 30 ms, so I used K = 10, T1 = 1.0 s, and Tf = 30 ms. Considering the simplicity of the model, the agreement is of course not perfect, but I was pleased to see that the general trends are nicely reproduced even in a semi-quantitative manner. The main purpose of the simulations is however to show by graphs the points which I tried to work out in the above. The first picture presents the Scilab/Xcos scheme for generating the plots shown in the second figure (I show the scheme since it defines more clearly than anything else what I actually did):



Let me first tell what is displayed in the simulated graphs. In the upper row are shown as function of time the applied rudder step (blue lines), servo signal (green lines), and yaw rate (black line) for six different PI parameters. These plots should be directly compared (except of the colors) to the experimental plots in #4.6. The most left graph has been produced for the parameter P = 4.5 (and I = 0), and corresponds to rate 0%, and the second left picture is for P = 2.5 (and I = 0) and could be compared to rate 20% and/or 30%. These two plots should demonstrate that the modeling results do make sense. In the two graphs in the middle I show two attempts of an improved tuning by allowing an I term (I = 0.5 and I = 0.8). As expected, the P value has to be reduced a bit with increasing the I term. I will turn to the two right figures in a second, but they are distinguished by their rather large I term.

The graphs in the second row are most interesting, they show the angle of the tail upon a sudden disturbance of 50 ms duration. This could be a wind gust for instance, or a pitch pump. The key point to observe now is this:

The four parameter settings to the left which I marked as "rate mode" are obviously chosen such as to produce a crisp tail response upon a quick rudder stick change, as you can see from the upper figures. However, the bottom pictures show that after a 50 ms wind gust the tail does NOT return to it's position where it was before, but stays off. So, the bottom plots directly demonstrate to you that the controller is working in rate mode: the controller works to get the yaw rate to zero, but the controller does not get the tail back to its original orientation (= angle).

Clearly, with a bit of an I term the controller does slowly try to correct that, but in the middle two pictures you can see how slowly this indeed is, it hasn't found its original position even after several seconds. If you would fly a heli with such a tuning, you would get a nice bounce-less stop, but the tail would slowly within a second or so wander a bit back. It's kind of a very very slow back bounce. I tried this, and I didn't like this behavior, and I am sure you wouldn't like it either (although the stop is at first "perfect").

So, clearly, one has to increase the I term further, and in fact quite a bit further. This brings us to the pictures on the right marked by "heading hold mode". Here the parameters were chosen such as to produce a good response to a wind gust. Look at the bottom figures, how quickly and nicely the tail returns back to the orientation it had before the wind gust happened! That's what we want to have in heading hold mode, the controller should hold the tail in its orientation whatever what. However, unfortunately, the response to a quick rudder stick command has deteriorated considerably, have a look at the upper figures. Do you note something? On the right, do you see these pronounced overshoots? Well, this is what you note in flight as back bouncing . If you try to avoid this by lowering P, well, see the second right graph for what you then get. You may also note that the I term is now larger than the P term. That is, the controller is now better described as "P controller" with its gain determined by the value of I... that's what is meant by the funny statement "I is P...." .

The lesson from all this is:

If one tunes the (PID) controller such as to give a nice crisp and bounce-less stop, then the controller works as a P controller with respect to the yaw rate (which may be optimized by I and D, etc.), which is what we know as rate mode.

If one tunes the (PID) controller such as to react nicely and fast to hold the tail during disturbances, then the controller works as a P' controller with respect to the yaw angle (which may be optimized by further terms), which is what we know as heading hold mode.

Or even shorter: In rate mode the (PID) controller is tuned for best rudder stick response, in heading hold mode it is tuned for a crisp wind gust rejection.


Now, finally, the huge overshoots in heading hold mode are obviously not nice. In practice one would not choose such large I terms as in the examples above, which had been designed to showcase the point; one would aim at an compromise between heading hold performance and bouncing (that's at least what I did). They can additionally be minimized by introducing a filter, slew rate limiter or anything alike - that's at least the standard solution which is promoted in the web literature and it works. However, this filter/limiter should NOT be inserted in the feedback loop, as this would also deteriorate the wind gust rejection, which had been the only reason for going to hh mode in the first place... So, it should go to the rudder path, which results in the structure V I've shown in the above. Unfortunately, this reduces the stop speed or crispness of the tail... TINSTAAFL... but see for yourself in the next sub section:


3. Rudder step response simulations with rudder filter (structure V)

Literature suggests structure V with a rudder filter in order to avoid the overshoot in P'(I')D' controllers for intergating processes. So, let's try that. I've added such a first-order filter, whose time constant I'll call Tr, to the Scilab script and ran simulations for the heading hold parameters used before, P = 2.0 and I = 8.0. The process model was of course also the same as before. In the next three graphs are shown the results for Tr = 0.05, 0.10, and 0.11 s and compared to the above result (Tr = 0):


Looking at the red curves and comparing them to the black ones, I think the message is clear. The filter does indeed do a nice job in suppressing the bouncing, however the response becomes significantly slower. Of course, because the filter was added in the rudder path, the response to a disturbance such as a wind gust is not affected at all and is exactly as in the picture before.

To further underline the slow down, one may compare the responses of the "best" simple-P-controller rate mode setting (second graph in subsection 2) with the "best" heading-hold mode setting (right graph in the just shown picture):

Also for this picture the message I think is clear, the rate mode provides a significantly faster response. Interestingly, the response speed in rate mode is limited by the available servo travel range, which was set in all simulations so far to +-350 (which is about what it is in my test heli). If a range of +-500 would be available, the response in rate mode would speed up quite a bit, while in heading hold mode nothing would improve (since the step has been slowed down by the rudder filter), see the figure to the right.


4. Conclusions

I'd like to conclude with saying that one should not take the parameters and simulation curves too literally. I have frequently emphasized the limitations. These simulations are meant to demonstrate, in a visual manner, what I tried to say and what in my opinion makes a difference between a rate and heading hold gyro. So, it's about the general concepts and not the little details.

Improvements on the structure V suggest themselves. The D term theoretically helps, but I guess it just makes tunning more difficult (it in fact seems to me that the standard settings in FBL units have D=0). Feedforward (known by various acronyms in the FBL units) also helps, but looking at the data and simulation results it hardly can help a lot. Setpoint weighting is another idea, but for the gain part it's nothig else than feedforward, and on the D part one probably would have to use it in unusual ways. Lastly, gain scheduling (also known in FBLs and gyros as, I think, stop gains) also can help a bit. All these things hence help a bit, and together may bring about significant improvements, but to properly tune all these parameters is obviously an effort. That's probably there all the know-how of leading gyro companies goes into, through extensive tests they could develop sets of standard parameters (in case of FBLs such as VStabi one could follow this process).

This was it for the simulations part. :-)
Last edited by OlliW; Nov 16, 2011 at 02:19 AM.
Nov 12, 2011, 02:15 AM
OlliW
Thread OP

Experiments II


Having presented data for the operation in rate mode and having described the behavior in rate and hh mode theoretically, I should also present some data for the hh mode, which will come here.


1. Closed-loop step response experiments in heading hold mode (no rudder limiter)






rest will come ASAP
Last edited by OlliW; Nov 17, 2011 at 06:01 PM.
Nov 12, 2011, 02:15 AM
OlliW
Thread OP
reserved 2
Nov 12, 2011, 08:09 AM
OlliW
Thread OP
reserved 3
Nov 13, 2011, 02:18 PM
Registered User
Havent read everything yet

You have a link to explanation about the different type of systems you are talking about?
Names are new to me.
Simply put a single spring mass damper system is a second order system. But because with a rate mode heli you look at yaw rate it is only a first order system.

Your idea about putting the integrator into the plant model dont make much sense to me. If I=P and P=D then what would D be, D^2? What is that idea based on? Is the stick input then still required yaw angle?
Because I would expect them to do the integration on the error signal so you could just use PID control on the yaw angle. Like your model II
Nov 13, 2011, 03:04 PM
OlliW
Thread OP
Quote:
You have a link to explanation about the different type of systems you are talking about?
Names are new to me.
yes, I have a good link: www.google.com
(I have about 50 .pdf's in my folder on this, so I took this from many sources and I must admit I don't like to link them all here... google is really great)(PT1, PT2, FOPDT, IT1 are actually QUITE common names)

Quote:
But because with a rate mode heli you look at yaw rate it is only a first order system.
well, I don't agree... good luck with modeling it as a simple PT1
(maybe you start with trying the relay experiment)

Quote:
Your idea about putting the integrator into the plant model dont make much sense to me.
in general, what you consider as your plant is quite arbitrary (as long as you deal with equivalent structures). What to choose is largely also a question of what you find useful for understanding... so choose whatever equivalent structure you like, if you get along with it understanding the effects then it's the right one for you. I found structure IV very insightfull, but it may not be the right one for you.

Quote:
Like your model II
structures I, II, III, and IV are equivalent, so physically it doesn't matter which one you choose

Quote:
Is the stick input then still required yaw angle?
in none of the structures the rudder stick gives the yaw angle, instead, in all structures the rudder stick gives the rate of change of the yaw angle.

rudder = 0 => no change in yaw angle
rudder = 200 => yaw angle changes at a rate of ca. 232 /s
rudder = 400 => yaw angle changes at a rate of ca. 464 /s

so if you give rudd=200 for 1 sec the heli will have turned by 232, if you give rudd for 2 sec, the heli will have turned by 464, alternatively, if you give rudd=400 for 1 sec the heli will also have turned by 464
Last edited by OlliW; Nov 14, 2011 at 02:28 AM.
Nov 13, 2011, 03:17 PM
Registered User
Those names arent very common in mechanical engineering and where dead times are very very short. So thats why the names are unknown to me (seem to be used in industrial processes, heat exchangers and such) and why I would dare to say you could model the basics as a simple single-mass system where you just apply a force to rotate it. Offcourse the servo has a limited speed and force and there is some stiffness and play in the linkage and tail boom but the basics is still a single mass.

What kind of bandwidth have you found for your control loop? (and what definition of bandwidth have you used)

About the yaw angle vs yaw rate, that was typo from me. Meant to say yaw rate.
Nov 13, 2011, 03:31 PM
OlliW
Thread OP
two references (but these are the only two I will give, "pid FOPDT" in google would have done already a good job )

google "IFAC PROFESSIONAL BRIEF Hands-on PID autotuning: a guide to better utilisation"
that's actually my absolute favorite, I have not found a text which is so clear and profound as this... it's unfortunately not very useful for our heli gyros (we are doing set point changes all the time...)

google "siam Chapter 6 PID Controller Design"
that's also a good reference to some things...

but as I said, there is not a single or some few references which would tell all.

Quote:
What kind of bandwidth have you found for your control loop?
I have seen in your helifreak thread that you like to think in terms of bandwidth... that's not my way of thinking here, so, I have no answer to that

Quote:
Meant to say yaw rate.
sorry, should have realized this, , so then:

Quote:
Is the stick input then still required yaw rate?
structures I, II, III, and IV are equivalent, so, yes.
Last edited by OlliW; Nov 14, 2011 at 04:20 AM.
Nov 14, 2011, 04:38 PM
Never Go Full Retard
1Man1Mountain's Avatar
Splendid effort on research and the amount of work involved.
This is not my cup of tea so Im sorry to say I cannot contribute buts still, I hope a compliment is welcome.
Nov 14, 2011, 07:39 PM
Professional heli wrecker
Luvmyhelis's Avatar
Quote:
Originally Posted by 1Man1Mountain
Splendid effort on research and the amount of work involved.
This is not my cup of tea so Im sorry to say I cannot contribute buts still, I hope a compliment is welcome.
I agree, as a guy running one of Olli's prototype customized gyro projects, much of his engineering prowess and thinking are quite profound. But, they work.
Nov 15, 2011, 03:25 PM
OlliW
Thread OP
It's clear that this is not the thread which will get a record clicks... but it's nice to see that at least few appreciate it... thanks guys.


Quick Reply
Message:

Thread Tools

Similar Threads
Category Thread Thread Starter Forum Replies Last Post
Discussion What is Delay of a Heli-Gyro from the Controller Perspective? OlliW Mini Helis 32 Nov 18, 2011 02:31 AM
Discussion Can i Use RealFlight (RF) Interlink Controller as a buddy box / trainer? sendittokeith Simulators 2 Nov 01, 2011 04:28 PM
Question Using rc airplane controller as sim joystick mranavayaII Radios 6 Oct 01, 2011 10:36 PM
Discussion New X-rotation Heli with Seperate Gyro and Speed controller ladamich Coaxial Helicopters 2 Jan 27, 2006 08:47 AM