I've been experimenting with a 3 axis gyroscope and an Arduino microcontroller in hopes of learning more about what is involved in regulating the rotation rate of a control line stunter.  I am using only the Z axis from the gyro.  I've attached a few graphs of two test flights from yesterday afternoon.  Both flights were flown within 30 minutes of one another, so the flight conditions were similar.

The first spreadsheet was from a test flight with the ESC in set rpm mode.  The rotation rate fluctuations due to wind speed are clearly visible.  The rotation rate in degrees per second varies between about 55 and 85.  The spikes in the middle of the graph were during a loop.

The second spreadsheet is from a test flight where the speed of the motor is controlled using a PID loop with the PID input coming from the gyro.  The output of the PID is fed to the ESC to control the speed of the motor.  The graph displays the rotation rate (blue), the throttle output from the PID (red), and the target rotation rate (green).  The rotation rate is held fairly close to a constant rate with the PID controller.  This flight had two loops and a wingover as can be seen in the graph.  I still have some tuning to do on the PID, but I'm fairly happy with the results from this test flight.   I am using a new verson of the Castle Creations firmware that supports 400 hz output rate changes.  The software mode is called Multi Rotor and was developed for use in multi rotor copters.  Without this firmware the Castle ESC's will not work as the thottle output rate does not update fast enough to react to the needs of the PID output.

As I progress foward I will continue to update this thread.  I still have a lot of work ahead of me, but I was excited after yesterday's testing.

Jason 

An alternative thing to measure is the acceleration in the port/starboard direction.  This gives you a pretty good indication of line tension, but it would tend to make the plane speed up in the overheads (which, maybe, isn't a bad thing).  I think this is what Igor Burger uses in his fancy inertial-feedback timer.

Differential action can be difficult to tame.  It aids stability in a lot of systems, yet it can make it worse on quite a few, too.  And when it does make things worse, it generally does so at high frequencies (often one half the sampling rate) where the direct problem may not be noticeable, but instead causes secondary problems.  (The most dramatic of these that I've experienced was on a system that used a so-called "torquer" motor, which is a motor that's designed to exert a controlled torque while moving slowly.  When you use a torque you drive an axis that's as free-moving as possible, so when the motor is off the axis is limp.  In this case, we were getting a strong oscillation at 1/2 the sampling rate that wasn't making any noise.  So the first symptom that you noticed was the axis going limp.  Much later, you noticed the motors burning up.)

In addition to it being a toss-up whether your differential action will help or hurt stability, it also can make your control system much more sensitive to noise.  In fact, without having your plane in front of me I would be hard pressed to fully believe that what you're interpreting as oscillation isn't just noise that's getting into the gyro and is turning into wild command swings, without having "real" oscillation (I'm not going to disbelieve it, either -- it's just that differential action can be tricky, and you sound like a beginner).

If you get a copy of my book there's a chapter in there on building the data-collection half of a control systems analyzer into your code.  If you take the trouble to do that and if you have enough memory on board (you'll have to do it in flight), then you can collect detailed information on how your aircraft responds to input, post a Bode plot, and then all the engineers here who do closed-loop control can give you conflicting advice on how to tune your PID.  If you have or get my book, and you want to go that route, let me know and I'll send you some supplementary material that may be helpful.

From a post awhile back where somebody recorded gyro data, I concluded that using yaw rate as a surrogate for inertial speed would be difficult, because it would always get some pitch rate in it from maneuvers.  On the other hand, you could use a 3-DOF gyro as a trimming tool.  

As far as control stuff goes, you do have an analog filter on the gyro before you sample it for a digital input, don't you?  Also, it may be prudent to leave out the integral path for stunt. 

From a post awhile back where somebody recorded gyro data, I concluded that using yaw rate as a surrogate for inertial speed would be difficult, because it would always get some pitch rate in it from maneuvers.  On the other hand, you could use a 3-DOF gyro as a trimming tool.  

And possibly a varying amount of pitch rate, if your yaw vs. elevator is affected by where you are with respect to the wind.

As far as control stuff goes, you do have an analog filter on the gyro before you sample it for a digital input, don't you?  Also, it may be prudent to leave out the integral path for stunt. 

Eh?  Whazzat?  Anti-aliasing filters on sensor data in a close-loop system isn't always a good idea, and is often bad.  The best gyros are designed to be sampled at a specific rate, and cough up a reading that's the integral of the rate since the last output (or, more properly, it's the measured angular offset since the last output).  Analog anti-aliasing may possibly make sense if you had reason to believe that vibration noise was getting into your gyro reading -- but doing the "integrate to angle" thing is better (sampling the gyro as fast as it'll go and properly integrating the rotations is even better, as it keeps you from having problems with coning ((Jason -- don't worry about coning; I'm talking in the larger sense of possible problems one may have with gyros in general, not with something that may happen to you specifically))).

Besides, a lot of silicon MEMS gyros these days are digital output.

That having been said, many of those digital-output silicon MEMS gyros have a selectable analog lowpass filter available.

At the risk of overloading the group with way-overly technical stuff: http://www.wescottdesign.com/articles/Sampling/sampling.pdf.  While I did write the paper, it doesn't just reflect my opinion: you'll find agreement by a large number of engineers that work in discrete-time control on the issues revolving around sampling and anti-aliasing filters.

Jason,
Interesting stuff!  Merry Christmas!

I am worried that yaw changes during maneuvers will affect the output and I don't know if there is a solution that will solve that problem.  I started this project knowing that I would make mistakes, but thats OK.  I may never get to the point of having a viable working solution, but I'm still having fun experimenting.

I haven't done the ciphering, but I'd guess that the yaw oscillations you get in maneuvering are fast enough that they can be filtered out without messing up the control loop.  Recordings of them, too, could be useful in trimming.

An alternative thing to measure is the acceleration in the port/starboard direction.  This gives you a pretty good indication of line tension, but it would tend to make the plane speed up in the overheads (which, maybe, isn't a bad thing).  I think this is what Igor Burger uses in his fancy inertial-feedback timer.

Actualy my lates solution is not inetrial and not feedback :- )))) ... but yes, works better.

here is my latest solotion with gyroscope:



it is on edge of hunting so sometimes it makes that "uuuiiiiuuiiiiuiiiiiuuuuiiii" :-)))) ... later (after 2 years of messing) I decided it is not way and used G sensor  

http://www.embedded.com/design/prototyping-and-development/4211211/PID-without-a-PhD

perfect article for this forum Tim :- )))

NOOO :-)) .. I did not want to discourage yo, do not expect to get solution without finding what is good and what is not, may be you will find better way than I did ...  :- ))))

I stopped, because I simply did not see way how to improve it anymore, and that solution which I had, was simply not enough for me. I saw it on World championship in Gyula 2010. Some guys from forum were there, it worked, but simply it was suboptimal in bad conditions. Then I simply changed mind, worked another 2 years and now I have solution which works also in hard wind and turbulence. You cannot have solution in few weeks, so do not stop if first try is not the best, I worked over 5 years, now we have much better components, we know what to expect from such device, so it will be much easier.

BTW I remember that Spain guys wanted to do it also ... Alberto are you reading? I did not hear about it long time.

You mean right now? Reading forum, eating cakes and building "tummy muscles" :- )))))))))

You mean right now? Reading forum, eating cakes and building "tummy muscles" :- )))))))))

I'm copying Igor.  Merry Christmas.

Alberto, 

Thanks for joining in the discussion.  It was your project that turned me on to the Arduino and gyroscope.  It's good to hear that you are still having success! 

Thanks,
Jason 

Actualy my lates solution is not inetrial and not feedback :- )))) ... but yes, works better.

here is my latest solotion with gyroscope:



it is on edge of hunting so sometimes it makes that "uuuiiiiuuiiiiuiiiiiuuuuiiii" :-)))) ... later (after 2 years of messing) I decided it is not way and used G sensor  

Heh.  I just noticed.

A gyroscope is inertial.  And since the motor affects the speed, the speed affects the gyro, and the gyro affects the motor setting -- that's a feedback loop.

I missed his wording: "my latest is not...", then "here is my latest with gyroscope".

Oh, if only I could learn how to read...

Sorry for the long delay between updates.  The holidays and weather have prevented any testing since my last update. 

Today proved to be a fairly decent day.  The winds were a little gusty at times, but I was able to make some progress.  Under Tim's advice I sought a new filtering method.  The new method seems to produce more acceptable output from the gyro.  After multiple tests I was able to achieve a smooth power increase and decrease where desired with minimal noise in level flight due to wind gusts.  I am using two sets of PID values, one set of conservative values for when the error is minimal and a more aggressive set for large errors. 

The attached graph shows the best results of todays testing.  I still have a little more tuning, but I feel pretty good with todays progress.

Thanks to everyone that has provided advice!  I greatly appreciate it. 

Jason

Thanks Igor.  I forgot to label my graph.  Sorry about that!  The green line is my PID set point, the blue line represents the gyro rotation rate in degrees per second, and the red line is the output from my PID feedback loop.  The red line is the esc signal divided by 10.  For example, 144 on the chart represents a 1440 millisecond signal. 

In my previous post I should have said that it reponds mostly correctly.  I still need to work on the timing of the response.  It's far from perfect! 

Hopefully on my next outing I will be able to get some in flight video.  Up to this point I would be embarrassed to post a video!!

Thanks again,
Jason

The output seems to be hitting limits at 131 and 149.  Why's that?

The problem that I see with any inertial speed measurement is that at the very best you will achieve a constant speed with respect to the pilot.  This should be grand under normal flight conditions, but is it going to be best in the wind?

I think it is impossible with power train and system of measuring which we have available.

Having done some work with compact six-axis IMU's and Kalman filtering I'm not so sure.  I do think that anything you do that depends on just one or two axes is doomed to failure, as you'll either have to low-pass filter the heck out of everything or put up with the airplane constantly zinging faster and slower as it rocks and rolls around the correct speed.  (Not to mention that if you don't do the low-pass thing, and lower overall loop gain, that you may find some rather interesting oscillatory modes).

Didn't you try servoing on airspeed at one point?  Did it work?

I don't think the complementary filter is going to cut it, in this case.  Where I see the term used (and it's a new one to me -- it seems to have been invented by the smart-phone software community) it's assuming that the phone is being accelerated mildly and rotated wildly.  The airplane case is almost, but not quite, opposite.

You'll need to know a lot more than just linear algebra to get your head wrapped around Kalman filtering, and then, to confuse things further, this problem actually demands an extended Kalman filter.  Trust me, the math will get wacky, and demanding, and a lot of other things only some of which can be stated in a family-friendly forum.

The way that a Kalman filter works is that it sorts out redundant data.  This means that in order for a Kalman filter to do you any good, you have to have redundant data to feed it.  If you just have a free body moving in space (like an RC plane), then a six-axis IMU (accelerometer and gyro) does not give you redundant information: the plane can move in six axes, you have six axes, too bad.  You can use a six-axis IMU plus some absolute position reference (like GPS) to get your redundancy, but in our case you'd need to add a GPS to your plane. 

What saves us here is that you do have redundant information, but it is indirect and screwy: the pilot constrains the airplane to operate in a hemispherical shell with a radius that's more or less limited to the line length, and the acceleration of gravity is a constant vector of known magnitude.  With that information I think that there's enough to get the airplane's position, velocity and attitude with respect to the pilot and to ground, but with a North reference that's "unpinned" and will spin around the circle at some rate that's (hopefully!) much less than the speed of flight.

This "pilot pins the center of the circle" is what you're already using to deduce speed from rotation rate, by the way.  What a Kalman filter will do for you is to take into account all of the rotations and accelerations of the airplane such that (for instance) any rocking of the airplane in yaw, or any coupling between the gyro's yaw axis and the airframe's pitch axis, will be washed out of the final velocity estimate.  In addition, I think (everything I say about this subject at this point should be prefaced with "I think" or "if I'm right") that as a bonus you'll know when the airplane is pointed up and when it's pointed down, and be able to add that to the motor speed as a feed-forward, to get a quicker reaction than you could from the loop.

Sorry for the break in updates on this project.  Between wind, rain, ice, and me having the flu I just haven't felt like working on this project.  The last two days were beautiful so I went out and tested a few more ideas, but the timer just isn't working like I'd hoped for.  I now have a digital 9 DOF IMU to experiment with, but it is going to take a lot of time and research before I attempt a solution using that sensor.

The one major drawback I noticed the last two days with the PID implementation (at least my implementation) is that it is very difficult to anticipate when the system is going to add or remove power.  This makes it difficult to fly with any precision or repeatablity.  In practice it is not consistent even under farily calm conditions. 

Thanks again to everyone for your input on this project.

Jason

   The reason they are "designed to be sampled as a specific rate" is primarily based on the anti-aliasing properties. There are very few applications where you actually want an aliased signal. It can certainly be dealt with downstream if necessary but you almost always want to do something about it somewhere. An analog pre-filter is a good way to do it.

The ones that I've worked with are sampled at some fixed relationship to the wheel rotation rate (if it's a spinning gyro), vibratory rate (if it's a tuning-fork gyro), or dither frequency (if it's a laser gyro).  Anti-aliasing, per se, is not the motivation for the chosen sampling rate out of the gyro.

Many control systems (including the vast majority of the ones that I've worked with) have little spectral content in the sensor signals at those frequencies that may be aliased down to where they might cause problems.  However, they have, largely, been limited in the ultimate sampling rate that could be achieved, either because of processor limitations or because the nature of the sensor itself limited the sampling rate.

In such cases the only thing that an analog pre-filter is good for is for taking up space on a board, using power, and, if it has any significant anti-aliasing properties, limiting the ultimate bandwidth that could be achieved.  Such filters in such systems do all of that while filtering out no significant amount of energy at all; the only impact they have on performance is to contribute phase lag to a loop that already came equipped with plenty, without any need for human intervention.

Granted, I've dealt with systems that did have spectral content that needed to be filtered, and in those cases I have specified anti-alias filters in loops that I've designed -- but they've been few and far between, and in general the knee-jerk inclusion of anti-alias filters in a control loop is both naive and wrong.

Here's a screed, written after an unusually dense cluster of posts on various USENET newsgroups that included statements that started with "Nyquist says" followed by some glaringly wrong "fact"; it explains the reasoning more fully: http://www.wescottdesign.com/articles/Sampling/sampling.pdf

Is the purpose of this experiment to build a "Point & Shoot" Stunter?
Perfect corners (exits) every time, or are trying to smooth out the flight?

Jason's aiming for speed regulation only, not pitch.  Have faith: perfect speed regulation + crappy piloting = crappy pattern.

Besides ... anything that controlled pitch would rightfully be illegal.

take care, Friends
           Dean P.