Menu Sign In Contact FAQ
Banner
Welcome to our forums

How to make an electronic AI

The Starfighter was one of the first aircraft equipped with an INS. This was mechanical. 3 accelerometers and 2 gyros mounted on a gimbal.



Not exactly solid state The accuracy apparently was within 2 NM after an hour of flight. In an INS, the accelerometers are the main measurement. In an AI, the gyro (or rate gyros) are the main measurement. With solid state gyros, I guess there is only one way to do it regardless. There has to be a gyro in each axis. Whether or not it can be used as an INS is mostly a matter of accuracy. Above water there is GPS and stars, the sun. Below water, every vessel relies on INS. It seems that an AI is very “simple” compared with an INS when looking at that LN-3 compared with a mechanical AI.

The elephant is the circulation
ENVA ENOP ENMO, Norway

Snoopy wrote:

I reckon a certified G5 technically functions the same as the ahrs chip in a Stratux, but has fancier code?

I do not know the details but if I had to build a certified instrument I would make some important changes: A separate CPU only for the AHRS and multiple sensors for redundancy and different detection ranges. The sensors usually either work well for small accelerations or big ones so having multiple sensors would help a lot. Then the CPU would have to be a real time system. I love non certified stuff but for a PFD it makes sense…

www.ing-golze.de
EDAZ

A separate CPU only for the AHRS

If the CPU is counting the pulses from the optical encoders on the rate gyros, yes I vaguely recall the Apollo computer did all that under interrupt, however, which is admirable.

It really depends on what time-critical functions the CPU has to perform, apart from handling the inertial stuff. But on solid state parts, like those referenced further back, you aren’t counting pulses. You get the angular velocity as a straight analog output, and same for acceleration, which you just feed to an ADC, you need six ADC channels for all that, and that is read typically over SPI, and provided that you do all the reads at an accurate frequency (needed otherwise the filtering equations will not work) i.e. don’t lose ADC samples for too long, it doesn’t matter what else the CPU is doing. You read the ADC as often as necessary, say 100Hz, and since you aren’t double-integrating (because the source is too crappy for that) this is more than fine for an attitude instrument. If however you are interfacing to a mechanical INS and integrating to get velocity and then position, then you are counting pulses from the encoders and you must not lose any.

A modern 150MHz ST32F4xx ARM, €6, is easily powerful enough to do all this and run your favourite game while playing an mp3 The problem, nowadays, is that software gets written by teams, in convoluted C++, and the system architecture needs to be done so that crappy software still runs ok.

Certified-primary avionics need specific software QA processes which I know nothing about… but any half competent embedded programmer knows the basics of how to make it actually work properly.

Administrator
Shoreham EGKA, United Kingdom
53 Posts
Sign in to add your message

Back to Top