Comet 4c - New Stall Tests

Last year, my work as a photographer caused caused the Comet project to suffer a nine month hiatus. It's a joy to report that I am back on it again.

It took half a day just to work out where I had got to last and what I needed to do next. I had made a lot of changes to the flight model (see May 2015) and my next step was to check and re-calibrate the performance against figures for the real aircraft. This is a hugely time consuming process to perform manually.

Another issue with performance testing is consistency. I find it difficult to perform stall tests or take-off tests with any consistency at all. I have to take the average of 10-20 tests, which I have never really been happy with because the statistical scatter is so great.

In May last year, I started writing a plug-in to automate it. I had already automated climb and descent tests, because they each take half an hour, when I could be doing something more useful. Cruise tests were also straight forward; again, it doesn’t really take any less time for the plug-in to carry them out, but I can be doing something else for the 4-5 hours it takes to go through the permutations of weight, altitude and speed in the de Havilland performance tables.

For stall tests, I used the dataref: “override_control_surfaces”. This is an all-or-nothing control, disconnecting them from the simulator, so that the plug-in had to be responsible for all three axes: pitch, roll and yaw. To do this, I used three proportional, integral, derivative (P.I.D.) controllers.

P.I.D. controllers work by evaluating the displacement (the error) between a desired value (the set value) and the actual value, and applying appropriate correction. They have far-reaching application, from maintaining temperature of a volume of liquid, to the speed of an engine, or the heading of a ship.

Proportional Control

At first glance, this is all any control system appears to need. It was the basis of the earliest experiments on auto-helms for ships. In theory, if a ship is displaced off course, the controller turns the helm in proportion to that displacement, and the ship comes back on course. As the displacement gets smaller, the steering is paid off, until everything zeroes out and the ship is back on course.

However, proportional control makes no allowance for the delay in applying the correction, between helm and rudder, or the inertia of the ship before it begins to turn. This results in over-correction, so that when the ship does begin to turn, it’s too much, and the ship overshoots the original heading.

This is exactly what happened during the first sea trials of an auto-helm in Britain, by A.B. Brown in 1870. The ship’s mean heading was on-course, but it did so in a series of zig-zags, or oscillations.

One simple way to reduce oscillation is to tune the controller, reducing the output so that the helm is only turned in proportion to half, or a tenth, or a hundredth of the displacement. This also seems fine in theory, except that, if the output is too small, the system would take too long for the error to reach zero. In fact, any proportional controller that is tuned to a point where it does not oscillate will also fail to zero-out (at least, not in any useful time-frame).

Derivative Control

This applies corrections in proportion to the rate-of-change of displacement. The significance of this was realised by Nicholas Minorsky, in Russia, who noticed that a real helmsman in a rolling sea did not turn the wheel in response to displacement, but to the rate of change of displacement, or acceleration, which he sensed through the deck as much as watched on the compass. Minorsky emigrated to America in 1918, and his work became the basis of the rate:rate principle for auto-pilots.

Derivative control has the advantage of sensing rapidly changing situations. It is effective as a stabiliser, reducing roll in ships or yaw in aircraft; it is not effective at keeping a ship on course, because there is no comparison between the set course and the actual heading.

Integral Control

This evaluates the sum of displacement over a period of time. Used in conjunction with a proportional controller that never reaches zero, or a derivative controller that doesn’t know where zero is, it can be used to detect an overall bias in the system (i.e., to bring the ship back on course).

P.I.D. controllers encompass all three methods of closed-loop control, which is what makes them so useful. The challenge for any control systems engineer, or programmer, is to tune the controller to respond quickly and accurately, without oscillation, surge or noise.

One of the difficulties when tuning P.I.D. controllers is that they are only good for steady conditions, with a fixed set point, and consistent system performance. That’s not the case with aircraft, because the responsiveness of the controls changes with airspeed.

The developer’s solution is either to tune the system for a narrow band of operating conditions (and to instruct the user only to operate it in those circumstances) or to adapt the tuning of the system while it is running.

Stall Testing

Tuning the P.I.D. controllers for wing-levelling and yaw damping was easy, because the systems were symmetrical. The Comet responded to left and right ailerons equally, and it didn’t really matter that the system was slower to respond at slower speeds; it still worked well enough for the purposes of the test.

Pitch up and pitch down was much harder to tune, because it was not symmetrical. Tuned conservatively, it did not respond quickly enough to “catch” a stall. The wings did not achieve maximum angle-of-attack before the aircraft began to loose height. Tuned aggressively, it oscillated.

My solution was to make the P.I.D. controller parameters variables, and to tune the system for a range of airspeeds. This established a ramp to change the variables as the airspeed dropped. This approach is known as “feed-forward”. A more sophisticated approach is to “cascade” two or more P.I.D. controllers, but I found this even harder to tune, and I achieved better results sooner using feed forward.

At this moment, I have just finished programming the flight test plug-in, and I am ready to try it out. Results will follow ...

blog comments powered by Disqus