#2839 Enhancement: heading_indicator_dg.cxx gyro switch vacuum driven or electrically

[Benedikt Hallinger]

Hi, digging trough the code I found that the enhanced gyro based heading indicator (heading_indicator_dg.cxx) just is electrically driven.

This patch adds optional vacuum support, so just by configuration the aircraft developer can attach a vacuum source instead of an electrical one.

This happens by supplying the standard <suction> property tag to the instrumentation.xml config:</suction>

A) Electrically driven, by standard power-supply properties:

 <heading-indicator-dg>
     <name>heading-indicator</name>
     <number>0</number>
  </heading-indicator-dg>

B) Electrically driven by custom properties:

 <heading-indicator-dg>
    <name>heading-indicator</name>
    <number>0</number>
    <power-supply>/systems/electrical/outputs/heading-indicator</power-supply>
    <minimum-supply-volts>12.0</minimum-supply-volts>
  </heading-indicator-dg>

C) Vacuum driven (NEW):

 <heading-indicator-dg>
    <name>heading-indicator</name>
    <number>0</number>
    <suction>/systems/vacuum/suction-inhg</suction>
  </heading-indicator-dg>

[Benedikt Hallinger]

(I have seen that the patch created with --format-patch does not apply cleanly.

Therefore here is gyroEnhancement1.patch, which was created by git diffand aplies cleanly using git apply gyroEnhancement_1.patch.)

[James Turner]

Normal we do electric vs vacuum as seperate instruments, or at least they appear to be (from XML side) even if it's the same C++ code internally. I think that's a bit cleaner than using the presence of absence of the <suction> property, how do you feel about it?</suction>

[Benedikt Hallinger]

I do not know of conventions, unfortunately.
The "problem" we have here is, we have already alot of heading_indicator instruments and its not obvious what kind of imlpementation it is.
Maybe the heading_indicator_dg.cxx can in the future replace the heading_indicator.cxx one (or the way around, namewise; the heading_indicator_dg.cxx looks like a vastly expanded copy of heading_indicator.cxx).

The heading_indicator_dg.cxx models a HI tied to a gyro, and I wold naively expect that gyro to be configurable on the power sources.

And then there is also already the heading_indicator_fg.cxx modelling a flux gate HI (and there the implementation really differs, and that is also always electrical).

What is the option here? Copy&Paste the code to another new instrument with the same code?
I would say, that configurable sources is easier to understand, especially since the HI-instrument) itself doesn't care what actually drives the spin of the gyro (hence swappable sources from the inst-definition).

To summarize, my feeling is, that it's better not to have too much duplicated code:

• Maybe in the future overwrite heading_indicator.cxx with the (new?) heading_indicator_dg.cxx code, so we end up with a flexible core instrument supporting different sources by configuration.
• Make heading_indicator_dg.cxx some kind of alias to heading_indicator.cxx (for downward compatibility; no idea if this works like this; c++ inheritance?)
• Alternatively making yet another copy of heading_indicator_dg.cxx to heading_indicator_dg_vaccum.cxx (and then what? leave heading_indicator_dg.cxx electrical-only? Sounds not like a god naming scheme) will clutter the code even more, so it's not a good option in my opinion.

[James Turner]

My impression is heading_indicator_dg.cxx was meant to be the configurable, fancy one, and heading_indicator.cxx was left for compat.

I'd suggest we make the gyro source in heading_indicator_dg configurable, and only do bug-fxies (no new features) in heading_indicator.cxx. Ideally we would actually see a vaccum-driven HI in instrumentation.xml but create a heading-indicator-DG witht he vaccum supply set, to avoid code duplication.

(And yeah we cannot do anything about the seperate flux-gate HI of course)

This is basically your points 1 & 2, just we need to be sure we don't break anything, which I would 99% guess is why the 'old' heading_indicator.cxx was kept when the gyro version was added.

[Benedikt Hallinger]

which I would 99% guess is why the 'old' heading_indicator.cxx was kept when the gyro version was added.

Sounds very reasonable :)
So in light of this, maybe we shuld forget about the fix fr the precession in the "old" one.
But we really should ammend the wiki to show the differences (I can do that).
And also a "deprecated" code comment in heading_indicator.cxx would really not harm :)

just we need to be sure we don't break anything

The patched heading_indicator.cxx here, I checked in the outlined configurations above and it worked like intended.

[James Turner]

Okay, made an attempt on this:

https://sourceforge.net/p/flightgear/flightgear/ci/dea806d7adc45aca5b9c87eb618203c05c1742a0/

(Either cherry-pick the patch or pull the branch to test)

We don't do the 'increase error with reducing gyro spin' which heading_indicator_dg.cxx does, but I think we should just bug-fix here and push people to swtich to the DG version if they want features.

[Benedikt Hallinger]

(I think you would have wanted to put that comment to the other ticket: https://sourceforge.net/p/flightgear/codetickets/2838/ ; also, the branch name has a number mismatch (2828 instead of 2838)

[James Turner]

Ooops, too many tickets

[Edward kowalski]

The airport model does not load
Airport:Rjtt
Version:2020.3.19
the scenery loads only the terminal Model Not loading

[Benedikt Hallinger]

Hi,
I spent the evenening coding this all here.
You can fetch my private git clone here: https://beni.hallinger.org/git/flightgear.git
The branch is named gyroEnhancement.

I greatly expanded the proposed patch-implementation (which adds optional vaccum support) by making the errors and limits configurable at runtime (see Instruments limitssubtree) as well as configurable by the instrumentation.xml.
Available keys are described in the cxx-headerfile.

A full example is (beware, values totally mad for testing):

<heading-indicator-dg>
    <name>heading-indicator</name>
    <number>0</number>
    <suction>/systems/vacuum/suction-inhg</suction>
    <minimum-vacuum>4.5</minimum-vacuum>        <!-- At this vaccuum the spin will reach 1.0 (ignored with elec gyro) -->
    <minimum-spin-norm>0.8</minimum-spin-norm>  <!-- min. spin to not let the gyro lag -->
    <yaw-limit-rate>3</yaw-limit-rate>          <!-- +- this yaw rate (deg/s) and the gyro will accumulate errors -->
    <g-limit-lower>-0.4</g-limit-lower>         <!-- exceeding lower G limit makes gyro drag -->
    <g-limit-upper>0.4</g-limit-upper>          <!-- exceeding upper G limit makes gyro drag -->
    <yaw-error-factor>0.5</yaw-error-factor>    <!-- how much error out-of-limits yaw-rate (deg/s) will add -->
    <g-error-factor>0.5</g-error-factor>        <!-- how much error out-of-limits G-forces will add -->
</heading-indicator-dg>

Leaving the definitions out will initialize the props in the limits subtree of the instrument at default values (which I have taken from the code, so its 100% downward compatible)

[Benedikt Hallinger]

I did some further reading, and regarding some sources the drift is not modelled correctly:
https://forum.flightgear.org/viewtopic.php?p=366368#p366368 (referencing kcs55.nas which is to be found here)
https://en.wikipedia.org/wiki/Heading_indicator

The drift should be:

• sin(lat), not fixed to 15°/hr
• countered by a latitude compensation mechanism

I think, the branch is a good spot to work on this, so I try to get my hands wet on this too.

kcs55.nas has this( where D2R is pi/180.0 #define D2R (3.14159 / 180.0))

# calculate the gyrocompass
      # time based precession, 360deg per day at the poles
      me.offset -= dt / 360 * math.sin(me.positionLatitude.getValue()*D2R);

[Benedikt Hallinger]

Just pushed commit 81fb5c8a009 to my repo (tested it).

This implements correct gyro drift per latitude (15°/hr at the poles, 0° at equator).
And it introduces a latitude-nut-setting-property at which the gyro can be calibrated to the latitude the plane will be at. This cancels that error for the most part.
It defaults to 0, which let it exhibit the drift seen before (however note: the "old" drift was errornous always 15°/hour assuming northern hemisphere, which was wrong in sign and magnitude!)

[Benedikt Hallinger]

I also detected that transport wander error is not modelled yet.
I think I give that a go too. I currently have a run here :)

[Benedikt Hallinger]

Just pushed commit 24baf7063.
We have transport error now, and that means that all errors are simulated as far as my knowlede goes :)

You can fetch my private git clone here: https://beni.hallinger.org/git/flightgear.git
The branch is named gyroEnhancement.

[Benedikt Hallinger]

Yes that was fun.
Added tumbling induced by excess G-Forces and caging of the gyro to prevent it.
The new prop limits/g-limit-tumble-factor (same name for the instrumentation.xml config) allows tuning when the tumbling should start (it is signified in the new tumble-flag) and caged-flag can be set from instrument models to allow caging (C182s has a branch for the new features here)

[Benedikt Hallinger]

Just had a test flight in the GA Wednesday group and it looks good.
Should be ready for review. :)

[James Turner]

This weekend is crazy but will try to review soon!

[Benedikt Hallinger]

(Note: Merging this will also fix #2840)

[Benedikt Hallinger]

Just stumbled over this.
I think the gyro spins up way too fast, manufacturer (kellys), spin up starts at 2.5inHg and will be able to reach 100% at 4.5inHg.
We should make spinup (and spin down) time also configurable.

https://www.kellymfg.com/faqs.html#:~:text=It%20requires%20approximately%203%20minutes,the%20rotor%20reaches%20full%20speed.

[Benedikt Hallinger]

OK; just pushed to my repo.
I made the gyro configurable in commit 48f1587232b58fcae14e.
The change is twofold:

(1) The base is at the C++ level; so there are just two new methods that can optionally be called to adjust the gyros speeds (Gyro::set_spin_up and Gyro::set_spin_down).
So in the future, any instrument that wants values different from the previously hard coded defaults (4 and 180 seconds) are now able to call the methods to adjust it.
Probably in the future it would be a good thing, if other instruments would follow the approach taken in (2) by heading_indicator_dg:

(2) This is then used by heading_indicator_dg onward from commit 77380212f3113f4, which introduces two new config properties for instrumentation.xml:
<gyro-spin-up-sec> and/or <gyro-spin-down-sec>. These are again also exposed to the instrument tree to be changed at runtime.</gyro-spin-down-sec></gyro-spin-up-sec>

I just had extensive testing with the updated Issue525_saveDG_offset branch from the C182.

[Benedikt Hallinger]

(And again; I still think this is ready to be merged)