Wednesday, April 18, 2018

Aircraft diving before climbing or NMP zero in load factor response


Source: pixabay

Imagine a conventional aircraft, like the ones which are flying across the world carrying passengers, for example. There is a very subtle and intriguing fact (at least for flight mechanics geeks) when the aircraft is commanded “to climb up”: the very first response of the aircraft body, for a short time period, is in the other way round, i.e., it dives a very little bit before climbing up. This fact is well explained by the aeronautical engineering experts and I’ll try to build up this explanation throughout the following lines. I’m assuming the reader has only some Mechanics background in the beginning, but the last section will require some Control Theory background, once that we will try to illustrate this puzzling concept called Non-Minimum-Phase (NMP) zero.


What actually happens


Let us start picking up some facts very well explained by the giants (Stevens And Lewis, John Anderson, Robert Nelson, etc). A conventional aircraft, flying straight with no changes in its altitude, has wings with this magical shape such that, roughly speaking, the greater the angle between a centerline through the wing section and the wind direction (called angle-of-attack), the greater the magnitude of the supernatural force upwards, called lift (Figure 1). The basics of the aircraft longitudinal commands (upwards and downwards) will be provided by the balance of the forces generated by the main wing and the horizontal stabilizer (little wing at the rear of the fuselage). More specifically, the longitudinal dynamics of the aircraft will be performed by the elevators, the small moving surfaces at the rear of the horizontal stabilizer. Moving up or down (both left and right simultaneously), the elevators are able to vary the vertical forces on the horizontal stabilizer making the aircraft climb or dive in a short term (assuming constant the other aircraft commands inputs) (Figure 2). 

Figure 1. Angle-of-attack and lift force, assuming straight level flight.


Figure 2. Elevator commands and longitudinal dynamics. Left sketch: elevators up, force in horizontal stabilizer downwards, counter-clockwise momentum, nose-up movement; right sketch: elevators down, force in horizontal stabilizer upwards, clockwise momentum, nose-down movement.
Considering our aircraft, flying straight and steadily with constant speed and altitude, if the elevators are moved upwards, we have the following sequence of events:

  1. The final elevators position causes a decrease in the lift force on the horizontal stabilizer. The force vector can even possibly turn to downward sense;
  2. The overall lift force acting in the aircraft decreases and the weight now is greater than the lift force, making the whole body accelerate downwards;
  3. The variation of the force in the tail generates an angular momentum, resulting in a pitching up movement (aircraft nose up);
  4. The nose up movement increases the angle-of-attack of the wing and therefore the lift on the wing;
  5. The angular momentum variation due to the new angle-of-attack of the wing counteracts the momentum variation due to the vertical force on the stabilizer, eventually breaking the pitching up movement;
  6. The increase in the lift on the wing is greater than the decrease in the lift on the horizontal stabilizer such that the overall lift force results greater than the weight, making the whole body finally accelerate upwards.

This sequence of events is assuming a time frame of few seconds after the elevators command, because in a long term, the aircraft will decelerate and require other input commands to restore the equilibrium condition or to settle in a new one.

But notice that the very first dynamic response of the aircraft (described by item 2) is in the opposite sense of the intended response, which is increasing the overall lift force of the aircraft. And so far we have a hypothesis. We need a model to confirm our suspicion and to dig into the details a bit deeper.

We need a model


Making science is not an easy job, neither is it cheap. So let’s trust the giants Stevens and Lewis and borrow their F-16 model. Just considering the hours of wind tunnel tests, the hours of engineering work compiling the aerodynamic data and the hours of real flight to validate the data make the costs go beyond the hundreds of thousands of US dollars (the hourly operating costs of the F-16 is around US$ 8,000). Luckily to me it only costs few days translating the Fortran code to Scilab and typing the aerodynamic data to the computer. I made the code available at GitHub, named mcflight.

Our model is a dynamic representation of an aircraft able to move in so-called 6 degrees of freedom (shortly 6 DOF): roughly speaking, 3 translational and 3 rotational movement possibilities (Figure 3). Although, for the simulation we are interested in, we only need 3 degrees of freedom, once that we are dealing only with longitudinal axis (i.e., translational movements upward/downward and backward/forward, and rotational movement of aircraft nose up/down).


Figure 3. Six degrees of freedom. The straight lines mean translational movements of back and forth following the arrows directions; the arches mean rotational movements clockwise and counter-clockwise around the center of gravity of the aircraft (assumed to be in the circle with the cross in the pictures). (Embraer super-tucano three views were found here).
By dynamic representation we mean a set of differential equations whose solution will provide us with the description of the aircraft movement throughout the time (for a very detailed explanation about the equations please check chapter 2 of Stevens and Lewis). In order to validate our hypothesis, we will need to “make” the aircraft fly steadily (wings level, straight flight) and then apply a small deflection on elevators to make the nose up. If we are right, we will observe a small decrease in lift force before building up.

To observe the lift force, in flight mechanics we use a physical quantity called load factor which is simply the ratio between the Lift force and the Weight (Figure 4). Although it is dimensionless, we express the load factor in g (referring to acceleration of gravity) and it can be positive, when Lift is in upward sense, or negative, otherwise. A very good g-meter is our stomach and you probably have experienced some g’s (positive) when riding a roller coaster. When an aircraft is flying straight and you are indulging yourself with a hot beverage served by the flight attendant, the load factor is 1 g (i.e. weight equals to lift) at that moment. During a normal airline flight you will experience slight variations around 1g, but the load factor will always be greater than 0. The negative g’s are experienced in aerobatic flights, for example, and notice that it is not only a simply free fall (which would be 0 g) but an acceleration downwards.

Figure 4. Load factor. Ratio between Lift Force and Weight.

Finally simulating


We are going to run a set of scilab scripts, analyze the time history of some variables (such as load factor) and use a lot of imagination to see an F-16 flying around.

The first step is to put our aircraft in a steady flight condition, which in our case means finding the elevator deflection and throttle setting (i.e., thrust provided by the engines) to allow a flight at constant speed, constant altitude, constant angle-of-attack. In other words, this is an equilibrium condition. The translation of this problem to our physical model is finding the solution of the differential equation using the proper set of constraints. In Aeronautics this is called trimming the aircraft. So let’s trim the aircraft in straight flight with wings level at sea level (altitude 0 ft) and with a speed of 200 ft/s. Asking scilab to solve it for us, we find the condition shown in Figure 5.

Altitude (h): 0 ft (sea level)
Speed (V): 200 ft/s
Throttle setting (engine): 0.287 (from 0 to 1)
Elevator deflection: 0.72° (-25.00° to 25.00°)
Angle-of-attack (alpha): 19.70º

Figure 5. Trim condition.

Let’s then apply the elevator deflection. In a time history simulation, we can say that it is a good practice to leave the aircraft fly steadily for a fraction of second (at least) just to check if there is an equilibrium point, before applying the input change. The following curves will show a time frame of 3 seconds of flight simulation with an elevator deflection of -1°, applied from 0.50s to 0.53s.

Figure 6. Load factor (Nz) and elevator deflection curves.
As we expected, the first dynamic response of the elevator deflection is a decrease in Nz. Then (after 0.53s) there is a monotonic increase in Nz until the end of the simulation. The Figure 7 shows the correspondence of the explained items in the previous section and the moments in the simulation zoomed in the first second of simulation.

Figure 7. Nz response right after elevator deflection. The numbers in parentheses indicate the corresponding item of explanation in the first section.
Notice that the amount of variation of Nz is around 0.004g, decreasing from 1.000g to 0.996g and increasing back in less 0.2s. This would be probable unperceivable by someone in the aircraft. A fighter like the F-16 is designed to be agile, to have a very fast dynamic response. If we had a model of a bigger guy (a cargo aircraft, for instance), the variation of Nz certainly would be slower and with a bigger magnitude (hopefully we will have another aircraft model available at mcflight soon). Figure 8 shows an illustrative animation of the F-16 flight.


Figure 8. Simulation F-16 model. Notice that the animation illustrates the drop in altitude, which is not coincident with the drop in Nz in the events timeline. Also the drop in altitude was (very) exaggerated for matters of illustration.

We could play with some parameters of our aircraft model to artificially make it have a behaviour similar to the bigger aircrafts. For example, we could change its ability to spin around the axis of the wings, i.e., the ability to nose up or down. Physically this means changing the moment of inertia around this axis. Try this out with mcflight code, varying the value of AYY.

From a Control Theory Point of View


From now on, it will be necessary some Control Theory background to fully understand it. A brave reader can keep going without this.

Considering the trim condition described in the previous section, we performed a linearization in order to find the state-space representation (Figure 9). In our Scilab scripts, this means using the command lin to find the matrices A, B, C and D and syslin to build a Scilab state-space representation. Mathematically we are reducing our flight dynamics to a first-order linear system representation of the equations. This will allow us to use the very well established theory of linear systems but the drawback is that this simplification is only compatible with the original (non-linear) model in the surroundings of the trim condition. So, before doing anything, we have to check the matching between our linear and non-linear models.

Figure 9. State-space representation, where x is the state variables vector, u is the control variables vector and y is the output variables vector.

Our linear representation is assuming the following variables:

  • Control variables (u): throttle setting (engines) and elevator deflection;
  • State variables (x): air-speed (assume that this equals to aircraft speed), angle-of-attack (alpha), attitude angle (theta, angle related to the horizon, initially equals to alpha), altitude, engine power setting.
  • Output variables (y): load factor (Nz). 
We can now simulate our linear model (in Scilab we can use csim command) with the same input we used in the previous section, using as input only elevator deflection and watching only the Nz as output. Figure 10 shows an overplot of linear and non-linear responses of Nz. Notice that after 1.4s our linear model starts drifting away from the non-linear model. However, the time frame from 0.0s to 1.4s is enough for our purposes.

Figure 10. Comparison between linear and non-linear simulations.

We are now ready to take a look on the poles and zeros of the transfer function of the system elevator-to-nz (Figure 10). Notice that we have a zero in the right-half-plane, also known as non-minimum-phase (NMP) zero (actually, we have three positive zeros, but the ones nearby the origin are due to the fact we inserted altitude and engine power as states, you can check this, eliminating them as state variables). And this guy is the guilty of the phenomenon we are describing here as stated by Stevens and Lewis (again): “these types of zeros occur when there are two or more different paths to the system output, or two or more different physical mechanisms, producing competing output components”. Yes, we have horizontal stabilizer and wings producing lift and affecting the load factor.

Figure 11. Poles and zeros of linear system elevator-to-nz.

Well, next time you are in a straight level flight of an airliner and all of a sudden you feel a quick and slight “floating” out of your seat (Nz less than 1g) before “sticking” to it (Nz greater than 1g) when the aircraft starts climbing, you can tell the passenger at your side that such sequence of events was caused by an NMP zero in the plant. Actually this is very unlikely, unless you have a g-meter with you. Anyway, at least the explanation you know ;-)

Why should I learn programming?


During every aircraft development, in order to assure that the flying machine behaves exactly as it was designed for, the flight test is performed by the manufacturer, also to prove to the competent authorities that the aircraft is able to fly safely. For the flight test purposes, the aircraft is equipped with all sorted of sensors (let’s say around 100,000 parameters), whose measured data we could assume recorded each 10 milisseconds. Doing a rough calculation we conclude that a single hour of flight test produces around 270 Gigabytes of data (in real life is actually much more than that).

The main point here is that for a single flight, there is a huge amount of data available to the aeronautical engineers validate and improve their design. But this only can happen in a phase of data analysis, which comes after few steps of processing the raw data, obviously unthinkable without some programming work. In a worst case scenario, the aeronautical engineers with their skills provided by a semester-long course of structured programming will struggle to write a little script from scratch to process the data and to allow them to check (for the thousandth time) if the aircraft behaved as expected.

This is not an isolated case of aeronautical engineering. Nowadays, in any field of science or engineering, our capacity to generate data has increased dramatically. For instance, the European Organization of Nuclear Research (CERN) announced (already in 2013) that their data centre had 100 petabytes of stored data, “equivalent 700 years of full HD-quality movies”. And the amount of general data produced daily is even more impressive. In every minute YouTube users share 400 hours of new videos, Facebook users share 216,302 photos, Instagram users like 2,430,555 posts.

This tells us that a problem-solving in this world overwhelmed by data is more and more walking towards formulate the problem for the computer helping us to solve it, no matter the field of knowledge we are talking about. This requires knowing how to ask the machine to solve our problem. As stated by an important Brazilian researcher, “every science is a computer science”.


Computer Science gap in other Sciences/Engineerings


If we compare a programming course in a standard engineering graduation today and 30 years ago, we would be impressed how topics are pretty much the same, sometimes only replacing Fortran by C, Python or even Matlab. Of course the basics of algorithms and problem-solving is very important to be kept, but the new engineers should at least be aware of the newest capabilities of programming and even the tools and techniques supporting the programming activity.

Resuming our example in the beginning of this text, aeronautical engineers 20 years ago could handle well (or, let’s say, using cutting edge technology by that time) the data available with their piece of Fortran code. Today, after getting (with a couple of clicks) the hundreds of gigabytes of data to analyze, they write a piece of code not that different than the one 20 years ago (in a different language, hopefully), but that runs in a hardware brutally faster and eventually achieve the expected results. Certainly, their job could be done faster by improving the code or by some different problem-solving technique; or perhaps many small repetitive tasks in the middle could be automated.

We could summarize this scenario as follows: in one hand we have engineers that eventually can make their job done, but is not fully aware that it could be improved by the latest programming capabilities available; on the other hand, we have computer engineers able to apply the best techniques but not required to help the other (non-computer) engineers.

Here we plotted the issue in the engineering field that is certainly far from being the worst case scenario, once that, at least, they have a programming course as part of their graduation. If we think about Human and Health sciences, the computer science gap may be much bigger.


Coding at School


Some people believe that in order to get over the aforementioned gap, we should go further and teach programming and related computer science topics earlier, at basic school. Hadi Partovi, the CEO of Code.org (a non-profit organization that aims expanding the access to computer science) said that “we don’t teach biology or chemistry to kids because they’re going to become surgeons or chemists, we teach them about photosynthesis and that water is H2O, or how lightbulbs work, just to understand the world around us. You don’t use any of it, but you do on a day-to-day basis use public-key encryption, and the average American has absolutely no idea what that is” (full text).

Besides initiatives as Code.org, programming contests worldwide has been becoming popular among youngsters before grad schools. The Brazilian Computer Society, for example, since 2002, offers modalities even for students under high school. The students shall solve computing and logical reasoning problems using just pencil and paper and, according to the Society, the goal is “to awaken the interest in computing problems and discover potential talents to programming”. The students with the best results in Brazilian Olympiad in Informatics will represent the country in the International Olympiad in Informatics which started at 1989 with 46 contestants from 13 countries and in its latest edition (2016) had 308 contestants from 80 countries.

Many countries have already included programming or “computational thinking” in their elementary school curricula. At European Union, 15 countries made it. And, at least in Brazil, where programming is not yet at the young students curriculum, private schools for “programming and robotics for teens” are rising in great cities like São Paulo, picturing a similar phenomenon which happened many years ago with the english private schools created all over the country. Sounds like the world is requiring the kids to learn a new language.


What about the future?


Studies published at the World Economic Forum Annual Meeting last year (2016) pointed some interesting facts about the jobs of the future: "The study shows that workers who successfully combine mathematical and interpersonal skills in the knowledge-based economies of the future should find many rewarding and lucrative opportunities."

If you realise that you can describe the routine of your day-to-day job in repetitive and well defined steps to execute some task, trust me, a computer program can do it way better than you can. This may sound alarming, but I can assure you that a significant percentage of a standard day at work of even very specialized science/engineering fields are covered by very repetitive tasks.

If at this point you are not convinced that you should improve your computational thinking skills, I quote the disturbing statement of this Brazilian researcher: “at this very moment, someone in the world is programming your job”.

Pragmatism doesn't mean reckless trial-and-error


When I finished my studies at university, I was eager to apply my technical knowledge in a real life context. And I confess that the very first contact with the crazy pace of job market was a bit shocking. At the time, as a purist, I incorrectly thought that using a pragmatic approach to solve a problem was akin to being reckless or irresponsible, which could only result in providing a sub-optimal solution. Later with experience it was eventually discovered that by wisely discarding parts of my theoretical knowledge it was possible to arrive more quickly at simpler solutions, without necessarily losing robustness.

According to Oxford dictionary, a purist is “a person who insists on absolute adherence to traditional rules or structures”. Also, it defines pragmatist as “a person who is guided more by practical considerations than by ideals”. This text intends to show that a purist approach can be relaxed and “more practically guided” still delivering successful solutions. This will be illustrated by a few examples in software and engineering contexts, but the technical details will be presented as lightly as possible so the reader from other fields can apply the examples to their own situations.

Would Physics equations from 1687 to 1905 be wrong?


In 1905, Albert Einstein proposed the ideas of his Special Theory of Relativity by the paper “On the Electrodynamics of Moving Bodies”, which pointed out some inconsistencies in Newtonian mechanics (1687) when speed approaches a significant fraction of the speed of light. Again, when the speed of the moving body is a significant fraction of the speed of light. Aircraft, for example, were (and still are) built using pure Newtonian physics with a successful history that speaks by itself. And how come, if these equations are not with the best precision? Well, Special Theory of Relativity adds a precision that is not required whatsoever by the models used for flying machines design. To give us an idea, the fastest speed ever attained by humans (11,1 km/s by Apollo 10 astronauts) will make Newtonian equations differ from Einstein equations by a factor of 0.9999999993 (being 1.0 corresponding to an identical result from both theories).

This bit of history helps us to illustrate how science works or more specifically how the scientific method works. When observing the problem we are interested to solve, we develop mathematical models, which are approximations of the natural phenomenon we are studying. The quality of a model in guiding us towards a solution will be determined by the degree of precision required in our solution. In other words, if our moving body speed is an insignificant fraction of the speed of light, we don’t need the degree of correctness provided by the Special Relativity Theory.

On the other hand our well-known Global Positioning System (also known as GPS) makes an elegant and crucial use of relativity theories to guarantee its very accurate precision, showing that each context dictates the required level of detail in the theoretical model.

What if aircraft were designed by the best purists in each discipline?


The concept and development of these amazing machines, weighing sometimes hundreds of tons, flying away from the ground and crossing oceans in a few hours, is the result of the hard work of thousands of people in several different disciplines. To enumerate just a part of them: aerodynamics, structures, flight controls, propulsion, electrical systems, hydraulic systems, etc.
If each of these disciplines worked strictly to attain their own requirements, we would have aircraft like the ones shown in the picture below, and none of them would fulfil all the requirements of the product at the same time.

As you can imagine, aircraft design is a huge effort of tuning the needs of all the disciplines together in one single product. And this has been working successfully for more than a century now.

Source: The Aerospace Design Process. A note from a reviewer friend: "I would prefer to see the glider associated with the aerodynamics and a parachute associated with noise" (Cap. Kev)

A bright tool called Object Oriented Programming (OOP)


The Object Oriented Programming (or shortly OOP), roughly speaking, is a way of programming such that the world is modelled by the concept of “objects”. An object encapsulates data (through the “attributes” concept) and the operations allowed over this data (through the “methods” concept). This paradigm, among many other features, allows the program to evolve and to be maintained more smoothly, using concepts like data encapsulation and code re-use, for example.

As far as I know, there is no hard, formal, mathematical definition for OOP (or any other programming paradigm), such that we say a programming language has more or less OOP features. Once I heard from a co-worker “if there is no explicit private/public keywords in Python, then it is not an object-oriented language”. By then, I started to think how an extreme purist view can make one blind. What are the questions we are really interested in answering? (1) Do we need an object-oriented language? or (2) do we need a software easy to be maintained and to evolve? I can assure you that is perfectly acceptable to use a multi-paradigm language that is not fully object-oriented but fulfil nicely your requirements. On the contrary, doing so, means studying carefully all the extent of your problem and then proposing a solution and not the other way round, i.e., picking up one solution and trying to make it fit to your problem.

For instance, if you have assessed all the main risks of your project, all the main test case scenarios (including the very critical ones) and mapped them in your development process, it really doesn’t matter what language or paradigm you are supposed to use. Unless your customer has a weird requirement that says you have to use a language with an explicit private/public keyword, you can use whatever your team is comfortable with. I would not be impressed with a very well written pure C code, implementing objects (yes, try to use function pointers into your structs and have fun).

The emerging agile philosophy all around


In this very well-written comparison between purists and pragmatist approaches, the BreakingSmart makes an enlightening statement about the agile philosophy: “today, the then-minority tradition of pragmatic hacking has matured into agile development, the dominant modern approach for making software. But the significance of this bit of history goes beyond the Internet. Increasingly, the pragmatic, agile approach to building things has spread to other kinds of engineering and beyond, to business and politics” (learn more).

Once the trial-and-error approach got the cost of a click on a computer, followed by results a few seconds later on the screen, hands-on creativity could walk along with productivity. But this triggers the uncle Ben’s warning: “with great power there must also come great responsibility”. It hasn’t been rare to hear that the agile methodologies are these magical tools which will make any development fit on any schedule. This is tricky and may possibly drive to an erratic trial-and-error approach without a minimal of planning or modeling to support it. As the examples above could make clear (hopefully) a successful pragmatic approach comes with sufficient background knowledge to assure which pieces of information can be discarded without compromising the final solution.

How to draw CATIA with MATLAB?

This post intends to show how it is possible a communication between CATIA and MATLAB. Whatever motivation you have to do with that. The software technology we're going to use for this communication (COM Objects) is straightforward to make it possible interoperability between many Windows Applications.

How two different softwares can talk?

By using filesystem is the simplest way to make possible the communication between softwares. For example, suppose one program calculates aerodynamic parameters (says AVL) and you need these parameters for flight performance calculations through a MATLAB code. AVL software is a command line program that can receive a text file as input and return another text file as output. Then, the easiest (maybe the only) way to make this communication is making use of files: MATLAB builds an input text file, calls AVL and reads text file returned by AVL.

Writing files on disk is a bottleneck for computational performance. When you are using optimization algorithms, for example, this is going to demand calling your little flight performance MATLAB code many times. Filesystem readings can mean a high execution time cost in this case.

When using command line programs, a little bit faster approach could be using the direct return of the program, without a bridging file. For example, in MATLAB, over Windows platform, we could get the current directory through the system program cd, using the command:

[resultstatus, currentdir] = system('cd');

Although, a most elegant and standardized way to connect to a compiled software (source code not available) is through a public Application Programming Interface (API), i.e., roughly speaking, an interface to call compiled software functionalities. In Microsoft Windows, an interesting standard for exposing API is Component Object Model (COM).

Using Windows Component Object Model (COM) to make your dreams come true

COM is an interface that enables interprocess communication and dynamic object creation in a large range of programming languages (Wikipedia). This standard allows the creation of a set of entities called objects, which are composed by properties and methods (these terms will be explained better later). For example, Microsoft Excel (as all the other programs from Microsoft Office Suite) has COM Objects, whose properties and methods allows to create and change spreadsheets from a code in any language implementing COM interface. The xlsread MATLAB command, which read an Excel spreadsheet, makes use of Excel COM object (see the code at [MATLAB PATH]\toolbox\matlab\iofun\xlsread.m).

In MATLAB we use actxserver command to handle a COM Object. Let's make a little bit of magic! In the code below, we are going to get a COM interface with CATIA and make its window appear (if CATIA is not openned before), changing the property Visible of CATIA COM object (this was tested with the very old 7.9.0, R2009b, but it works with the newer ones).

>> catia_com = actxserver('CATIA.Application')

catia_com =
COM.CATIA_Application

>> set(catia_com,'Visible',true)


ans =
NaN


Then you're going to see CATIA window in your task bar.

(If you do not have CATIA, you can test actxserver with other COM Object as Excel.Application.)

In software engineering, catia_com variable in the code above is called object. This is an entity composed by properties and methods. Property is a changeable characteristic of the entity: catia COM object can be visible or not, for example. Method is a function which changes object behaviour. As we can see with the code below, we can add a new document CATIA Part through method Add of property Documents. To obtain the value of a property, we use MATLAB get command; to change the value of a property, we use set; to call a method, we use invoke.

catia = actxserver('CATIA.Application');

set(catia,'Visible',1);
docs = get(catia,'Documents');

doc = invoke(docs,'Add','Part');

From now on, you can draw an entire aircraft from your Matlab script. Enjoy it!