Replies to This Discussion

DeveloperPermalink Reply by William Premerlani on April 13, 2010 at 5:10pm

Hi Natalius,

Well done. Very good. Very impressive. Sounds like you are having lots of fun.

Regarding your question about what speed to use in the calculation of centrifugal effects...

The short answer is, you should include vertical velocity.

Now, the long answer....

FIrst, I should refer you to something I wrote a couple of months ago regarding a technique for estimating wind speed without a pitot sensor, because it is relevant to your question.

Also, a few months ago, I realized that it is 3D air speed, not 3D ground speed, that should be used in centrifugal calculations. It seems strange, but it is true, and has been independently verified. So, we have implemented a method for estimating airspeed and wind speed.

Back to your question: The correct speed to use in the centrifugal calculation is the square root of the sums of the squares of the three components of the air speed vectors.

The older versions of the UAV DevBoard firmware (MatrixNav and Aileron Assist) use speed over ground for centrifugal calculations. We ignored the vertical component of speed over ground for two reasons:

1. We intended for the planes to be flying mostly level most of the time.
2. The vertical component of ground velocity (daltitude/dtime) includes thermals and slope lift, and that does not contribute to centrifugal effects.

The latest version of the UAV DevBoard firmware (MatrixPilot), is evolving. It currently uses the air speed vector for centrifugal calculation. I am not sure whether it uses the vertical component of the air speed vector or not, but if it does not, we will eventually revise it to use all 3 components of the airspeed vector.

There have been literally 1000s of flight hours logged with the various versions of MatrixNav, Aileron Assist, and MatrixPilot, with great results, so I don't think the various approximations we have made along the way have caused any problems. Some pilots have been hovering their planes vertically with firmware that the team has been developing lately.

For more information, take a look at the uavdevboard website and discussion group.

Best regards,
Bill

• ▶ Reply

Permalink Reply by Natalius Kiedro on April 14, 2010 at 6:06am

Hi Bill,

thanks for the document - this is an ingenious way to do it (!!) - it will definitely become bascomized - may be even before next weekend! You are absolutely right, the lift component (Wz) is what a soaring afficionado is heading for. Wz should correlate with vario information (daltitude/dt) for "wind shakened" flight - and so there is a way to prove the correctness of your algorithm by independant means. I'll kix a windspeed message with 2 Hz (GPS). My "standard mistake" in vector algebra is that I tend to confuse left/right up/down - and as things like wind estimates can be tested only in the air, correlation will help to show myself a sign error in the implementation.

Concerning speed = Sqr (sog^2 + (dalte/dt)^2) I think that this is equivalent to speed = Sqr ((dx/dt)^2 + (dy/dt)^2 + (dz/dt)^2), because sog = Sqr ((dx/dt)^2 + (dy/dt)^2). I take sog from RMCspeed directly however. Maybe it is better to take it from dlate/dt * late2m and dlone/dt * lone2m to avoid "smoothing" by GPS. I'm really keen to see your algo in the air - any clever way to remove things from the surface of a soaring plane is better than to add things. The good news about software is that it has no mass and no air resistance!

The reason for my question is the absence of an airspeed sensor in the current test configuration. I have build in my pitot into another plane - the DCM testbed for next weekend is a smaller machine (Last Down XXL, just 2.8 m wingspan).

Thanks for sharing it with us!!!

Natalius

• ▶ Reply

DeveloperPermalink Reply by William Premerlani on April 13, 2010 at 5:28pm

Natalius,

Another point I forgot to cover...

Recently several people have asked if it would be possible to do the DCM computations without measuring the speed at all.

So, Paul Bizard did some simulations where the speed used in the centrifugal compensation calculations was a constant, assumed speed. It turned out that although there was some error, DCM based control was still very stable. So, obviously, the accuracy of the speed estimate in the centrifugal compensation is not all that critical.

What Paul found out was that if you want to simply assume a constant speed, it is best to err on the high side. He found that if you did that, the errors that were made as a result actually improved the stability of the controls. In the case of neutrally stable planes with ailerons, the improved stability made the aircraft much more resistant to going into a "death spiral" due to pilot error. What would happen was that the errors made in the centrifugal compensation, if you overestimate speed, tend to turn the plane out of a spiral, and back toward a straight line.

If you underestimate the speed, there is not as much resistance to the spiral, but Paul found that there was enough, in any case, to make the stabilized flight characteristics very pleasant.

In all cases, the pitch accuracy is rather good, since it does not depend much on the centrifugal effects.

Best regards,
Bill

• ▶ Reply

Permalink Reply by Nima K on April 13, 2010 at 5:37pm

Is it possible to clarify why it is 3D air speed, not 3D ground speed that needs to be used in centrifugal correction? I was under the impression that the speed would need to be relative to the inertial reference?

• ▶ Reply

DeveloperPermalink Reply by William Premerlani on April 13, 2010 at 6:39pm

Hi Nima,

Good question, it gets asked often.

We do indeed want to compute the acceleration in an inertial reference, but that does not necessarily mean we should use the ground velocity to do it.

Computing the centrifugal acceleration is basically focused on a problem in geometry: what is the curvature of the track of the trajectory? For a car tracking on the ground, we would want to use the ground velocity, because the car ignores the wind and tracks the ground. But a plane in the air ignores the ground, and tracks the air. Since the plane tracks through the air, it is the air velocity that is important.

There is a simple example that might help you see it.

Suppose that the plane was making a steady level turn, constant turning rate, with constant bank angle, in a steady wind.

With respect to the air, the plane would see a constant air velocity. Because the bank angle is constant, the plane would track a perfect circle with respect to the air. Also, the centrifugal acceleration would be constant.

But the track over the ground would not be a circle, it would be a very strange shape. And the velocity over the ground would be changing, it would be large going downwind, and small going upwind.

The gyros in the plane would report a constant turning rate.

If we multiply the constant turning rate of the plane times the constant airspeed, we will get the correct inertial reference constant acceleration experienced by the plane.

If we multiply the constant turning rate of the plane times the varying ground speed, we will get the wrong answer, and the answer will not be constant. Since the answer must be constant, we know that the ground speed is the wrong one to use in the calculation.

It is also possible to prove it mathematically, but many people are not convinced by a mathematical prove, so I am hoping the example will help you see it.

Best regards,
Bill

• ▶ Reply

Permalink Reply by Nima K on April 13, 2010 at 7:12pm

Thank you for the detailed explanation. I can visualize your explanation with relation to the constant airspeed and I think it would look something like this:

Sorry for my poor man's impression. The diagram tries to depict the ground track of an aircraft performing a constant airspeed turn in constant wind. The two radii are for the turn into the wind and out of the wind respectively. So centripetal acceleration is:

a = V^2/r

I'll write omega as w (angular rate)

w = v/r => a = w^2r

Obviously for use in an autopilot, we don't have r so we substitute it out of the equation using

r = v/w

and the centrifugal acceleration becomes:

a = v^2/r = v^2/(v/w) = vw

I understand that you know all this but I just wrote it for the clarification of my point. Since the radius of the turn in the inertial frame of reference is not constant in the turn in question, I have difficulty visualising how the centrifugal component of acceleration will be constant? The only way it could be, is if the combination of angular velocity and ground speed remain constant? Which could be a possibility, but I can't quite see how to prove it mathematically.

If I were to explain it in terms of the visualisation: if you hold a constant bank angle, as you cut into the wind and approach a 90 degree angle to it, it pushes the aircraft at a higher angle of incidence to the bottom of the wing causing greater lift and therefore a greater acceleration vector pointing to the center of the turn circle than a case where the wind was in the direction of travel.

Now I know you will point out the flaw in my logic, but I'm just trying to explain it how I see it, which is stopping me from understanding your point above.

• ▶ Reply

Permalink Reply by Natalius Kiedro on April 14, 2010 at 6:22am

Hi Bill,

"He found that if you did that, the errors that were made as a result actually improved the stability of the controls."

Hey - if this is true - one may actually benefit from noise correction:

Something like: Speed = Normspeed (1 + 0.5 RND(1)) to keep DCM "vibrantly adopting". Question is then the frequency of distortion. Did you test noise already?

Although this approach seems counterintuitive - filtering means noise removal - why to add it later - it may help at the low frequency edge.

Best regards,
Natalius

• ▶ Reply

Permalink Reply by Andrew Dunlop on April 13, 2010 at 7:34pm

A volume of air moving at a constant velocity is an inertial frame of reference.

Perhaps it is easier to imagine one's aircraft flying within a stationary volume of air, with the ground moving at a constant velocity below.

Andrew.

• ▶ Reply

DeveloperPermalink Reply by William Premerlani on April 13, 2010 at 7:47pm

Andrew,

That is a wonderful way of looking at it. Thank you.

Best regards,
Bill

• ▶ Reply

Permalink Reply by Natalius Kiedro on April 19, 2010 at 4:22pm

Hi all,

the configuration crashed last weekend - the sausage is gone. While on Saturday we tested the basic AR7212 functionality - and it worked even forgetting about a range test - just perfectly - on Sunday we tested the DCM-autopiloting with the Kixrazor. The sad part is that I lost an LDXXL - the good part is that I know the kixline documented reason why.

It was a death spiral - faster and and more rapid you can imagine on an MPX EZ* - the LDXXL is not a performance glider, just a glider for the average pilot. I don't consider myself as an average pilot - well some say in my club that my flying style is like paying mortgage;-) - but nevertheless I was able to rescue things in an experimental emergency in many cases.

Not in this case. So what was the reason? Kixed flight log revealed that Bill Premerlanis's DCM was working perfectly fine but that I myself had build the most idiotic way to do autotrim in the air. The last one (in the panic) just "stabilized" death spiralling.

Cest la vie,

Natalius

• ▶ Reply

DeveloperPermalink Reply by William Premerlani on April 19, 2010 at 6:57pm

Natalius,

Regarding your crash, you have my sympathies.

Believe it or not, I would be interested in how you were doing your autotrim. I believe we should always learn by our mistakes.

I have not yet tried to do an autotrim. Simply using the direction cosine values in the feedback loop for roll and pitch seems to work really well without it. We have been able to do hands-off stabilized launches of neutrally stable, high performance, airframes, for example. The climb out straight as an arrow, with wings level.

Best regards,
Bill

• ▶ Reply

Permalink Reply by Natalius Kiedro on April 26, 2010 at 9:23am

Hi Bill,

sorry for the delay. Good news is that the sausage filling did not suffer from the crash.

Concerning your question: I think the the term autotrim is a kind of misplacement - a better term were calibrate/normalize/set to straight level flight. It is meant as a "trim to the autopilot" while in the air. What I do is a regular trim on my DX7, and then use - both the neutral stick readings and the actual roll and pitch angles to define offsets for neutral flight. The AR7212 autopilot does not primarily synthesize the servo signals but the stick settings. Servo moves and their flighmode-dependant couplings are done in the mixer part. In order to transfer pilot's trim to become autopilot's trim, one needs to switch from flightmode 1 to 2 to 1 within one second.

A more extensive analysis of the kixfile and the rest of the story revealed the following "concatenation" for the crash:
(1) The Last Down XXL was reassembled for the sausage in a hurry. On friday before a collegue called "We are all at the field - superb weather - where a you?". Let's call it "induced" lack of care.
(2) A good center trim on a DX7 means a value around 500 (512 opt, DX7 units). Rudder center was at 600, elevator was 400 - both at the edge of stick trim range.
(3) CG was correct for performance flight but definetely not for experimental flight. The plane was a tic more at the "inherently unstable" than at the "neutrally stable" side.
(4) One wing was "soft" with respect to a stable angle of attack. A collegue who helped me on Saturday had unintentionally pressed the steel pin behind the wing connector into the wing - I was not able to get it out anymore. Only the front pin kept the wing in its position - AND - the LDXXL has a "swimming connector".
(5) The normspeed of this plane is around 45 km/h. Kixlog showed 80 km/h in the moment when "uncontrollability" escalated. Although the plane was too far away to let me see the flutter - I bet - that wing flutter was an issue here.
(6) The rest is panic. This thing was in the spiral already when I asked the autopilot to bring me out of this situation. Before I invoke the autopilot I usually do the above "autotrim" - perhaps this is a bad habit from thermopile days. Here it was fatal. Kixfile says that the last autotrim "fixed" a roll of 85 deg and a pitch of -71 deg. I kept the autopilot for 2 seconds. When I saw that auto was not anymore able to rescue the plane I switched back - indeed the plane did not react anymore - but I know that the DX7 signal was received till the very last moment.

I will do the next experiments with my Alpina 4001 and the usual care.BTW: The issue of a self-stabilized launch is especially attractive for this class of planes (> 5kg). A start waggon is too jumpy on our field, a bungee start not very convenient and so one usually needs a helper to throw or to steer.

Best regards,

Natalius

• ▶ Reply