search

reiszner / KAP140

The Bendix/King KAP 140 autopilot for FlightGear Flight Simulation (FGFS)
GNU General Public License v2.0
0 stars 2 forks source link

ROL NAV/REV/APR intercept issue #10

Closed hbeni closed 3 years ago

hbeni commented 3 years ago

Hello, I potentially found a minor behavioral bug. It shows most significantly when way outside an VOR.

When doing an all-angle intercept (equip just DG, fly a custom angle to the radial in ROL mode, push NAV button), the plane follows the current heading quite fine. As soon as NAV kicks in, the plane initializes its capture sequence. Far out the calculated intercept angle is 45 degrees, even if i just flown less than that.

What i would expect is, that the plane follows my heading until the calculated intercept angle is less than my manually set course. Example: Radial 0°, i fly course of 30°. i would expect the plane to fly 30° until it wants to turn left to follow the radial. Right now it turns right to 45° and then swings back left to the degressional capture track. This turning into the wrong side is what i suppose to be a bug.

grafik

I think, this one is for Josh? @Octal450

hbeni commented 3 years ago

(Made a mistake - the red dots are where currently nav kicks i ja, that is about three dots, not degree)

Octal450 commented 3 years ago

@hbeni is this what the real does?

If so I can look at integrating this. I guess we can also consider, maybe NAV activate once the demand from the system is less than current intercept? @reiszner any input?

Kind Regards, Josh

hbeni commented 3 years ago

@hbeni is this what the real does?

I honestly have no idea. But that’s what i would expect, because it does make more sense. The old implementation also did it that way.

I did not find footage of this yet, so don’t take it for granted. It’s also no big issue imho.

Octal450 commented 3 years ago

Hmm... I'll do some looking later.

Kind Regards, Josh

reiszner commented 3 years ago

I also dont know how the real KAP140 react. I have implemented it on the Citation II, but i dont know if it is compatible with the filter in KAP140. The way i have done it on the Citation II was a filter that calculate the direction of intercept. The nav-filter calculate his own direction where it want to go. If this direction is the oposite, the FD will not comand a turn. If it is in the same direction, the turn will comanded and the restriction-filter will be reseted (from now on, turn in both direction are allowed). This way, the FD can also intercept with 5° or less. The turn kicks first in, if it goes in the right direction. Maybe thats a help or idea for Josh. Anyway, we dont know what the real KAP140 does.

Octal450 commented 3 years ago

@reiszner well... if you dont know what real does... you want it added or not?

reiszner commented 3 years ago

i will search in the internet, maybe i find something.

hbeni commented 3 years ago

I would say implement it, because that's the more plausible mode of operation.

Octal450 commented 3 years ago

I thuoght about @reiszner for you to check /autopilot/internal/intercept-angle and check when its lesser than current intercept angle, then switch to NAV/APR/REV when it is, but that also brings the problem - how does it know what the angle is before the pilot sets it on the DG.. So maybe I have to do a latch, store the current intercept angle when NAV/APR/REV goes active, then clip the intercept angle to that until we have captured then reset.

I'll play around with this.

Kind Regards, Josh

hbeni commented 3 years ago

Cool! If you have something to test, I’ll be happy to do so.

In ROL intercept, the ap needs the bug set on the DG as well, so i think your idea to derive the angle from that is correct.

reiszner commented 3 years ago

Found something --> https://petitcessnavoyageur.files.wordpress.com/2018/01/afm-s3-2-bendix-king-kap140.pdf On page 33, point 4b:

If the HSI D-Bar is more than 2 to 3 dots from center, the NAVARM annunciator will be shown on the face of the autopilot. When the computed intercept point is reached, the ARM annunciator will go off and lock on (capture and track) will begin automatically. The NAV annunciator will stay on the face of the autopilot.

Looks like the KAP140 wait for the right point to turn.

BTW: i think this paper is from interest for you, Benedikt, because its for the C182T :)

hbeni commented 3 years ago

Well, that is the already known sentence from the manual. We already implemented it. Currently we interpret that "computed intercept point" to be when we are inside the three-dots range... Which is fine for the 45°-autocapture, but not for the ROL-all-angle-interecot (and thus maybe also not for when a HSI is installed).

I think all will be fine if the target-intercept-angle would be split into two filters: one constantly calculating the intercept-angle and the other using that information to: a) HSI (manual intercept angle) or ROL-all-angle-intercept: lock NAV/APR/REV when the calculated intercept angle is smaller than the currently flown angle (from HSI-radial or DG-Heading bug setting) b) in 45° DG+HDG mode: lock as now depending on the calculations done already - should be automatic but maybe has to be limited/guarded with an additional check to the CDI needle offset like now (that check should always be true in the other intercept modes because of the way the intercept angle is calculated; it's just important that the 45°-ARM annunciator does not go away prematurely)

Just an idea out of my head; Josh surely has better insights into this.

Octal450 commented 3 years ago

Honestly ---- I think what @hbeni says is correct - because before the DG is set, there is no way for the KAP to know its intercept angle (in DG mode). I would say it would make more sense to simply prevent turning farther into the turn. I will work on a latching system for this.

Kind Regards, Josh

hbeni commented 3 years ago

I would say it would make more sense to simply prevent turning farther into the turn. I will work on a latching system for this.

if it's that easy to solve, that would be entirely fine I think.

hbeni commented 3 years ago

I had time and fun today to fiddle around with it a little and found an easy fix. Details: https://github.com/HHS81/c182s/pull/403

Octal450 commented 3 years ago

@hbeni can you explain this? I don't understand how what you did fixes it.

Kind Regards, Josh

hbeni commented 3 years ago

Sure! Basicly it was Saschas approach:

The neat thing is this was simple and only uses data that is present from the DG and internal autopilot data, so it implements the „calculated capture point“ calculation which is mentioned in the manual in a possible-realistic way (but there is no public information on how the kap140 really calculates it). The result is what I would expect from such a calculation.

The new ROL intercept should only be active when not using an HSI and when coming from ROL, all other code paths are still the original ones (at least I made the conditionals so)

[edit] my change: https://github.com/HHS81/c182s/pull/403/commits/f037c8296fa3c98ebd706751aca030b70d6c69d5

[edit] oh and i forgot: this plays nicely with the display. The armed mode really stays armed till the capture point, and then the mode locks in, reverting to normal behavior (i.e. it tries to get back to the radial with 45degree if one flies fly too much away). I tested it with all modes, and everything looks good.

The only thing not there is the latest changes in Saschas code here since my quick attempt to integrate them to the c182s failed and I wanted to focus on the issue at hand. From what i have seen in the changesets, nothing functional should be missing in the c182 trough.