#2840 heading_indicator_dg.cxx: Error code modelling

[Benedikt Hallinger]

Based on investigations of the heading_indicator_dg.cxx code in ticket #2839 I have further questions.

(1) Line heading = fgGetLowPass(_last_indicated_heading_dg, heading, dt * 100);
This is inconsistent with the other implementations.
However, I think, it should read:
heading = fgGetLowPass(_last_indicated_heading_dg, heading, dt * 100 * factor);, so not a fixed factor 100, but 100 depending on the actual spin.

(2) Around lines 130 the movement induced error is calculated:

double yaw_rate = _yaw_rate_node->getDoubleValue();
    double error = _error_node->getDoubleValue();
    double g = _g_node->getDoubleValue();
    if ( fabs ( yaw_rate ) > 5 ) {
        error += 0.033 * -yaw_rate * dt * factor;
    }

    if ( g > 1.5 || g < -0.5){
        error += 0.033 * g * dt * factor;
    }
    _error_node->setDoubleValue(error);

My understanding from watching some videos ([1], [2], [3]) is, that the gyro moves freely and such should be no significant movement induced errors from the pane (unless out of limits).
The mechanical limits to this about +-55° pitch or bank.
Nowhere is 'yaw' or 'g-forces' mentioned.

What are the actual physical sources for the currently coded errors, and why is bank and pitch not handled in the code?

(3) Also, I think it would be great if we could parameterize that limits to be optionally overwritten by aircraft.

---

To Test:
Edit instrumentation.xml of c172p and add a test heading indicator:

~~~
<heading-indicator-dg>
<name>heading-indicator</name>
<number>1</number>
<power-supply>/sim/time/elapsed-sec</power-supply>
</heading-indicator-dg>
~~~

---

Ref:
[1] https://www.youtube.com/watch?v=hVsx4XWafXg Gyroscopic Instruments
[2] https://m.youtube.com/watch?v=9EZ9ZI8kAWM Operation And Errors Of Directional Gyro Indicator | Lecture 27
[3] https://www.youtube.com/watch?v=q1TVR9xdl64 The Heading Indicator (Directional Gyro)

[Benedikt Hallinger]

Regardig:

(1) Line heading = fgGetLowPass(_last_indicated_heading_dg, heading, dt * 100);

Tested this and it makes the compass card move smoother; looks like it just was something which was overlooked then or so.

[James Turner]

Reviewing this now, some points:
- we should parameterise the 'error due to yaw' for sure, I don't know if we need params for both the 'safe' yaw rate (5 deg/sec) and the error constant (0.0333)
My understanding from David Megginson's reply on the mailing list is that at least a somewhat strong turn will cause an offset, do you agree?
But, if we make it a param we can set the default rates higher to disable this term if you think it's not appreciable
- The G force error is similar, we would need to config both the threshold to apply the error (+/- 0.5G) and the coefficient (0.03333 again, hmmm)

We could say that if these values are not configured in instrumentation.xml, they default to 0.0, i.e both errors are disabled; this would be a compatability change of course.

for 1) you are probably correct but I must say the way 'factor' is calculated is confusing me generally; can you walk me through your understanding of how spin -> factor is working to adjust the low-pass filter?

[Benedikt Hallinger]

Hi there,

My understanding from David Megginson's reply on the mailing list is that at least a somewhat strong turn will cause an offset, do you agree?

I agree. However, the question is how much of Gs are not knocking it off. I found it very hard to find information on the net about this.

• we should parameterise the 'error due to yaw' for sure, I don't know if we need params for both the 'safe' yaw rate (5 deg/sec) and the error constant (0.0333)
• The G force error is similar, we would need to config both the threshold to apply the error (+/- 0.5G) and the coefficient (0.03333 again, hmmm)

I would make the lower and the upper limit configurable individually. So we can (for whatever yet unknown reason) fine tune later on if needed. there is no harm in making things accessible.
I have no idea how the initial author of the file had chosen 0.0333 as coefficient. It looks like the "magnitude" of the calcuclated error/offsets effects. i think it is a good think to expose this to configuration too.
Btw. when implementing configurability, it is in my view always a good thing to make it also use property nodes, so the values can be changed at runtime. Especially on the coefficient this would probably be very handy in order to for example making it possible to disable/tune it at runtime.

We could say that if these values are not configured in instrumentation.xml, they default to 0.0, i.e both errors are disabled; this would be a compatability change of course.

I feel there is no need for this. We can just make the defaults like they are now, which preserves downward compatibility. If one wants to diverge from that standards, he can freely in the future.

for 1) you are probably correct but I must say the way 'factor' is calculated is confusing me generally; can you walk me through your understanding of how spin -> factor is working to adjust the low-pass filter?

I don't know for sure, however looking at the chart of f(x)=x⁶ and apply to the code; the spin⁶ factor makes the factor "start" at roughly 0.5 spin and gain nonlinearly until it reaches 1.0 for spin=1.0. This has the effect that for example factor=0.7 for spin=0.95; which makes calibration only effective when the gyro was spun up fully (like in engine runup; calibrating with engine off will make no sense).

[Benedikt Hallinger]

Note:
ThegyroEnhancement-branch of my private git clone here: https://beni.hallinger.org/git/flightgear.git will also fix the lowpass filter (1) thingy as well as configurable limits; so when merging #2839 this Ticket here can be closed as fixed.

[Benedikt Hallinger]

so when merging #2839 this Ticket here can be closed as fixed.

It is fixed, closing this one.