I am following the ongoing discussion on automatic speed controllers with great interest and have great respect for the quality of the arguments put forward by the experts. It is this kind of objective discussion which maintains and promotes our common cause. Many thanks to the participants and to Stunthangar for maintaining the website.
According to what has been published here so far, it could be that after a complex development process we will see e a rather complex and not cheap system. I therefore take the liberty of proposing a first step to gain knowledge first:
A prerequisite for further steps should be that in order to design an automatic speed control system, the term speed should be defined. Whether the purpose of the controller should be to keep constant a given value for the airspeed, the angular speed or the groundspeed remains to be determined.
In order to support the opinion making on which speed to aim for, I believe that it would be useful to allow experiments on as broad a possible basis. This could be done by an adjustment of the making legal manual in-flight speed control by the pilot. For electric drives (and possibly IC motors, too) the current technology available would make it possible to make such systems available to a wide range of pilots at low cost.
I am positive that wide spread experience gained from manual in-flight speed control would be helpful defining requirements for the development of automatic speed controllers.
Actually Peter what I am doing can be accomplished with an Arduino based board. There's zero automation. Basically the output can be tuned to match what the airplane is required to do. I published my thoughts quite a bit prematurely and this precipitated something much more complex than is necessary. My original purpose of asking the question was to gain insight on what I need to present in terms of performance prediction. As it is, a simple input from a potentiometer can be read and used to create the command. I use gain as the control would have a base level output for level flight. Then any needs of the airplane would commanded by the 1 - Cos X gain which, as can be seen, is a function of drag and can be made to fit quite well. This means that the control can output the thrust as required for the airplane to not loose energy from the turning. This gain could be adapted to a feedback controller but my experience as a powerplant engineer tells me it's not necessary for what we are doing. This same architecture is what wee use in helicopter engine control as failure mode accommodation which works nearly as well or as good as the hydro mechanical control systems.
What this means is that, if the system is trimmed correctly, the exit of the turns will only decay in velocity by the change in gravitational potential energy. I did not present this quite yet as this is the portion of my article I am working on. I am working through the mathematic derivation and the illustrations to demonstrate. Basically, once we can match the drag, the analysis becomes similar to a frictionless change in total energy. The question becomes one of were does the work come from which is obviously the powerplant. It is extremely hard to describe in words and requires the illustrations and mathematic derivation. If you haven't read my thread on motor Control, please have a read there.
My initial Energy conversion yielded some 28 ish fps velocity delta. The only computation I have worked through is simple, frictionless change in altitude where the change in kinetic energy from the change in potential energy drives the velocity change. Offhand that seems like allot but I have no real intuitive feel for it initially. I know the airplane slows down allot from watching the videos now, but I never really perceived that deceleration until I went looking for it and it verifiable in my videos. This is what begets the thread title question. The following use 65' base circle.
For instance, in level flight the airplane is going 78 fps which translate to about 69 Deg/s (Dps). The delta V of 28 fps means the airplane would be flying at about 50 fps on the 45 degree azimuth. This then translate to 289/360 = 0.8, and 50 fps / 0.8 D/ft = 62.5 Dps. Our perception of velocity is a function of the characteristic length of the thing we're watching and perceive the airplane as flying at a near constant velocity. So what I think we like is that the airplane crosses the high leg at near the same angular rate. I.e. we'd like to see i flying at a near constant 69 Dps in this case. I'm not so sure and that is the foundation of my question, because the small change I've derived is consistent with my observation, although not extensive.
In the simple version of my control, there is no need for any attitude information. However, in order to compensate for the mgh term in the energy a means of doing work to mitigate the loss is necessary. Basically we need to add or decrease thrust as a function of the pitch attitude as a function of the angle between the airplane and the gravity vector. This again doesn't need to be a complicated computation other than filtering the input from the IMU.
Take a square non tethered loop as an example. When we are in level flight we make the assumption Thrust equals Drag, T=D. In order to transit the corner we add thrust to compensate drag and maintain T=D. That compensation is the 1-cos X term. If that term is exactly correct, it won't be, then the exit would be slower by the change in altitude 1/2mV^2 = mgh leads to dV =sqrt(2*g*dh). For the non tether case during the turn the g vector changes as Sin X. It's not so simple in 3 space. In order to mitigate the gh term we simply need to add a trimming function to the gain computation Kg*Sin X so that the power gain would now be K1*(1-K2*Cos(K3*X)) + Kg*Sin X. With this we can now fine trim the airplanes velocity to suit what our perception wishes.
The need to know the g vector is only necessary to make the small improvement. In upset training I teach my student the importance of drag in the recovery and I demonstrate the difference between pulling 2 G's from vertically nose down and 4 G's nose down. In the first case we increase velocity tremendously while in the second case we actually slow down.
I my perspective, the impact of the IMU is mostly detrimental. This is due to two things. First is the amount of filtering required to get a good signal which creates a lag in response. Second is the encroachment in the processor timing margin which also leads to increased lag. Actually those two combined are the source of the lag. What I am finding on the Arduino products is that the smaller ones won't load and run the calibration libraries. I'm a total amateur when it comes to code and electronic hardware and have always relied on the others in my team for that.
Thanks for brining this up and letting me have the floor to present more of this effort. After I manage to update my article with this portion, I'll present the end game concept which incudes the variable pitch propeller.