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.
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…
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.
Yes absolutely, sorry, it’s been years since I checked on that project. At some point (2016) I was trying to build a portable autopilot using their dev branch.
Snoopy wrote:
What’s the difference compared to the built in AHRS for Stratux?
I believe this has been pulled back into Stratux and is the basis of the native AHRS solution, where all active development is happening.
I don’t think laser gyro INS is mandatory in CS25. It certainly wasn’t some years ago; for example airliners flying only intra-US routes didn’t have to install it. Whether you can buy a B737 without it, I doubt. @Antonio may know.
AFAICT all solid state “gyro” products use the same principle as was used since for ever, in Polaris, Gemini, Apollo, etc: three yaw rate gyros at 90 deg to each other, and three accelerometers at 90 deg to each other. There must be some dead common set of equations for processing this into a “navigation solution”, or – as a subset of that, and all you can do if the gyros are solid state i.e. relatively crap – into an attitude reference solution.
The solid state devices range from crappy ones for maybe $1, all the way to $100s for a complete AHRS module. I last looked at this some years ago and Honeywell were a big player in the latter end. But now you get some impressive stuff like Vectornav which seamlessly integrates GPS with inertial, but is still no good for “navigation” without GPS. Well, not for more than minutes. Then for some $20k+ you get fibre based products like the KVH CNS-5000 which has a G antenna one end and outputs NMEA (or some such) at the other end, and if the GPS fix is lost the output just carries on… Airliner INS is another level above that; whether it is more accurate I don’t know.
Am I right that CS25 aircraft use RLG hardware whereas the Garmin stuff is more consumer level using chips? Where can I read up more on this?
I reckon a certified G5 technically functions the same as the ahrs chip in a Stratux, but has fancier code?
wleferrand wrote:
Checkout https://westphae.github.io/stratux/ – he has an open-source ahrs that plugs back on the stratux
What’s the difference compared to the built in AHRS for Stratux?
Well, I can see that a mechanical rate gyro would have zero temperature drift. Expansion would just change the moment of inertia of the flywheel, which will do precisely nothing. And if you make the bearings frictionless (which is almost possible, using magnetics) then it will have “zero” drift.
What I don’t get is how you make a really precise mechanical accelerometer. This is because you can’t let the reference mass move relative to its mounting (it would “escape” ). It must be kept centred, and you use a magnetic field to hold it in the central position, and the current required for this magnetic field gives you the G. Now, this isn’t going to be linear… any magnetics employing anything other than vacuum have a nonlinear B-H curve, but perhaps this comes out in the wash, mathematically. This problem must have been solved in weighing machines, however, which are pretty accurate and cheap. Some use the obvious strain gauge method while others use electromagnetic force restoration e.g. these and those must be linear enough too. This suggests that nonlinearity is compensated in software. But none of this will be good for double integration…
Peter wrote:
More amazing is that mechanical gyros outperform the laser ones.
Indeed. And who would have thought. I mean, nothing is more accurate than a laser – NOTHING They are completely different principles though. Both FOG and RLG measures rate, while a mechanical gyro doesn’t measure anything in the correct sense of the word. It just is. In a practical application with vibrations, temperature variations and maintenance requirements and so on I would still think a FOG/RLG would be a better solution.
