Razno

We are getting questions about our AHRS module working principle and quality of indication in sustained turns. This short article is intended to give some simple answers without complex equations. But before we go into more details, we can give a short answer: Our AHRS module has no problems in sustained turns.

In fact, it does not make difference between a straight flight and a turn.

 

AHRS sensors involved

Each serious AHRS module, which is used in a real aircraft and where realistic performance is expected, must have the following sensors.

• angular rate sensor (aka gyros), three axis,
• accelerometers, three axis.

When MEMS sensors are used, the quality of the sensors is not good enough and additional sensors must be used for the long term stabilization of the solution. At least one of the following sensors must be used:

• GPS receiver,
• differential pressure – for the indicated airspeed.

When both of them are used more stable and better solution can be obtained, of course. For even better solution additional sensors are recommended.

• absolute pressure – to obtain geo-potential altitude used to get true airspeed from IAS,
• outside air temperature – also to get TAS from IAS,
• three axis magnetometer – to get true heading and use it instread of GPS tracking.

More sensors are used, more independent equations can be applied in the model and more reliable the solution will be.

 

Short term, long term solutions and Kalman filtering

 

Practically any serious AHRS solution is based on “short term” and “long term” independent solutions, which are then combined into one solution using some kind of filtering algorithm. In vast majority of cases (just like in our module) a form of Kalman filtering is used. Each module producer have its own solution here and most of the “trade secrets” are hidden in the software implementation of the Kalman filtering and not in sensors.

Short term solutions are mostly based on gyros and accelerometers. Assuming some known existing position and orientation, contribution from accelerometers and gyros are integrated in time. If sensors are perfect and a perfect mathematical model is used, then such time integration also yields a good long term solution. Unfortunately, MEMS sensors have significant drift and long term solution based only on the integration will be completely wrong after some time. This is a fact. In order to correct the solution on a long term, an alternative set of solutions must be provided.

Such solutions are “long term” solutions - we can also name them as “independent measurements”. Key word here is independent. They must not rely on the same mathematical model as short term solution. As far as position is concerned, there is no other practical way but to use GPS position. For the orientation, it would be the best when two independent vectors are known in global and airplane coordinates. In space this is not so difficult to obtain, but on the Earth we are stuck to gravity and magnetic field vectors. Unfortunately, magnetic field is difficult to measure (local errors due to construction and equipment) and local magnetic anomalies of the Earth magnetic fields make this theoretically perfect solution not very useful. So, we are forced to use some assumptions and other independent measurements, to compensate for this shortcomings.

In our case we assume coordinated flight and gravity measurements. These are used to stabilize roll and pitch solutions and GPS track (or magnetic heading, when available) is used to stabilize yaw. Well this is not completely true, because roll, pitch and yaw are coupled together and things are a bit more complex in reality, especially during a turn.

When aircraft is turning, accelerometers are measuring apparent gravity. Using coordinated flight assumption together with standard flight mechanics theory allows us to calculate true gravity vector and then use this solution for a long term stabilization of gyros. Although gravity vector has three components, they are linked together and only two are independent. Hence GPS track (or magnetic heading, which is better) is also needed. TAS (true air speed) is required in these equations, hence good AHRS devices also have differential and absolute pressure sensor as well as OAT sensor.

Alternatively, GPS ground speed can be used, but error may be significant for slow flying aircraft in windy atmosphere (a turning glider, for example). Also, when GPS ground speed is used and GPS signal is lost, long term stability is compromised. With pressure sensors, this shortcoming is avoided.

These long term independent solution is then compared with the short term solution and both solutions are then coupled together. The process of coupling is pretty complex and is based on Kalman filtering theory. Since all equations and models are non-linear, one of non-linear versions must be used. The result of such coupling is a fast response (short term solutions) and long term stability (long term solution).

The beauty of Kalman filtering can be seen in fact that long term solutions, which seem uncoupled to the short term solutions also contribute to stability. For example, pure GPS position measurement also affects roll, pitch and yaw values, although there is no direct link between them on the first glance.

 

Sustained turn stability

Since straight flight is nothing but a turn with a zero bank, our solution does not distinguish between them and corrections are applied always when coordinated flight assumption are fulfilled. Thus long term stability is not compromised during a sustained turn.

 

Real life experience

 

Our AHRS modules were tested in our motor-glider (used almost exclusively for testing) and almost infinite number of turns were made. No performance degradation was ever noticed during turns.

Slight degradation was noticed, when coordinated flight assumptions were not fulfilled for a long period of time. We made several tests, where coordinated flight was constantly violated. (I must say, it was quite difficult to fly that way.) A small difference on AHRS indication was detected when turns were made with two or three balls offset form the ideal position for a long period of time. The difference was constant in time (it was not drifting), which is in concordance with the theory. When a coordinated flight was resumed for a couple of seconds, the difference was not notable anymore. AHRS indication was fully useful and AHRS responded normally and predictably all the time.

This is last nesis update available. It is meant only for advanced users.

Download updates here: nesis-2.0-b7.zip

A pure windows Nesis version is available. This version is based on the same very code that runs in Nesis, but compiled for Windows. Due to lack of the obvious hardware, it is not fully functional, of course. However, it will give you a chance to get familiar with most Nesis functions.

Please note, that this code is pretty obsolete (it is more than two years old) and that much new has been introduced into Nesis after the code was published. As soon as time permits, we will prepare a better and more functional simulator.

Installation instruction

• Donwload the NesisWin.zip [61 MB] file and extract it into the C:\. After the extraction you should get a path to the executable file C:\Nesis\nesis.exe. Note: The zip file containes some chart samples, hence the large file.
• Using Explorer, locate the executable and double click the nesis.exe file. This should do the trik - run the Nesis application.
• If you installed nesis.exe elsewhere, you need to modify the Nesis.ini file. Open it with Notepad and modify the following lines. The first line points to the location of the Nesis base folder (directory). The second line points to the location of the maps (files with the kam extenstion).
  Home_Folder=/Nesis/
Map_Folder=/Nesis/kam/

Keys

Keys F1-F5 simulate the bottom Nesis buttons, F6 and F7 are Ok/Menu and Cancel buttons, F9 and F10 are used to simulate the knob and F12 is used to shut Nesis down (Exit).

The complete source code used in Nesis is available. Majority of the code is released under GNU GPL license. Minor portions are delivered under so called MIT license.

Here is the link to the 16 Dec 2011 source code [about 84 MB, zip]. It includes (head) Nesis version 2.0 beta together with some maps, airspaces, etc. Maps, which are included are enough for test. If you need more maps, please contact us.

Prerequisites

 you would like to download and compile the code, the following prerequisites must be met:

• For time being, you still need a Linux based computer. We will prepare a Windows sources soon.
• Make sure you have a C++ compiler at hand. (We are using GCC). The code should work with other compilers as well, but minor changes in the code may be necessary.
• Install and compile the latest version of Qt programming library (4.6.0 or above, most recent is recommended). If you are able to compile the Qt, you will be most probably able to compile our sources as well.
• You may give a try to the Qt Creator software, which may help you a lot. This is THE tool, which we are using for the Nesis development.

Installation instructions

• Extract the code into a local folder. Say, that you extracted it at user folder and the path to the code is /home/your_user_name/Nesis-2.0/
• Open the command line shell (konsole) and enter:cd /home/your_user_name/Nesis-2.0/Nesis/ to move to correct folder.
• Enter: qmake nesis.pro
• Enter: make to build the binaries. The compilation may take few minutes. The result is stored in /home/your_user_name/Nesis-2.0/Nesis/bin/nesis executable file.
• Finally, you need to edit the /home/your_user_name/Nesis-2.0/Nesis/bin/Nesis.ini text file. Open the file with a text editor (kwrite, kate) and change the akrajnc part in the path to your_user_name for the Home_Folder and Map_Folder entries. Save the file.
• Enter: ./nesis
• Depending on your system, you may need to install certain software tools. Compilation errors will tell you what seems to be missing.

Final note: Keys F1-F5 simulate the bottom Nesis buttons, F6 and F7 are Ok/Menu and Cancel buttons, F9 and F10 are used to simulate the knob and F12 is used to shut Nesis down (Exit).

One of the most important decision factors during the Senap development was to follow as many open standards as possible. We found the CANaerospace interface specification as a complete, relatively simple and open standard. Hence, all our modules communicate using the CANaerospace protocol.

The magnetic field model around our planet is based on data and software from World Magnetic Model from National Geophysical Data Center. This model is used to calculate magnetic compass declination depending on current geographical position.

Charts are composed from several different sources. Most of the raster information comes from the SRTM (Shuttle Radar Topography Mission) data. The data was collected, processed and published by NASA.

Due to specific SRTM technology some parts in the original SRTM data have "holes". Jonathan de Ferranti has patched many of the holes and published the enhanced data on his web site.

Vector information on our charts (roads, rivers, lakes, ...) comes from VMAP0 composed by NGA. This information was optimized for the scale 1:1 000 000. Although we appreciate all the effort needed to compose such a chart, we would like to have slightly better vector charts. In fact, better vector charts exists, but they were not released into public. The following link gives more details.

Spot information in the vmap0 is a bit sparse. To make it more dense we included the information from Geographic Names server. We applied special filters to prevent spots becoming to dense.

The NASA GSFC and NIMA Joint Geopotential Model was used to correct SRTM altitudes from WGS84 system into better and more precise EGM96 system.

If you are interested in the open source development, you may want to visit the Open Source Initiative link.

We are using Linux operating system. In particular openSUSE and Ubuntu represent our working environment. Linux is also used in the Nesis. In Senap we are using our own operating system.

The majority of the code is written in C++. Whereever it was practical, we leaned on the marvelous Qt library from Trolltech. In particular Qt and Qt for Embedded Linux (former Qtopia core) libraries are used.