A/C struggle to join the localizer

[n8rzz]

https://github.com/zlsa/atc/issues/711

[n8rzz]

[n8rzz]

hmm, I thought we'd addressed this issue with #2. At a very brief first glance this looks like it may be a difference issue, it's certainly drawing the course differently.

[n8rzz]

@erikquinn I'm going to need your eyes on this one. I'm still digging but so far I have not been able to find any major differences in the logic between v2 and v3. The logic is very similar and nothing has jumped out at me yet.

[n8rzz]

@erikquinn I'm completely stumped on this one. Could you take a peak at this when you have some time?

This bug is reproducible on KSFO with an aircraft arriving on the BRS2 arrival and intercepting the localizer somewhere north or west of SWELS. For aircraft arriving from the east to north east, they seem to be able to intercept just fine and have correctly drawn paths.

I'm sure I'm just missing something simple. I know I'm not getting _clamped again, cause those are all gone. I'll bet is a math thing somewhere, though.

[erikquinn]

I think it's the projection only that is messed up (which needs other fixes anyway). I'll have a look when I get home.

[n8rzz]

Sounds good. I was looking at it again this morning and I think I did get clamped again. There are two spots in the AircraftInstanceModel where it looks like the arguments are in the wrong order.

[erikquinn]

Reproduced.

Sounds good. I was looking at it again this morning and I think I did get clamped again. There are two spots in the AircraftInstanceModel where it looks like the arguments are in the wrong order.

That might make sense; one would be from the code section below. But reordering them properly doesn't really seem to fix it.

---

Truth time-- I've made countless failed attempts over the last 6 months to figure out this section has been a nightmare that has consumed about half the time I spend working on the project. I have been staring at the same problem for way too long, and don't think I will be able to come up with a good resolution. It doesn't seem like it should be that hard, but I can't come up with a way to make it work. I dumped another three hours at the problem, and still have nothing. Maybe I'm just a bufoon, I don't know, all I know is I'm sick of trying to figure this one out.

This is the section that's screwing it all up, from AircraftInstanceModel.js:2088:

                if (should_attempt_intercept || in_the_window) {  // time to begin turn
                    const severity_of_correction = 50;  // controls steepness of heading adjustments during localizer tracking
                    const tgtHdg = angle + (offset_angle * -severity_of_correction);
                    const minHdg = angle - degreesToRadians(30);
                    const maxHdg = angle + degreesToRadians(30);
                    this.target.heading = clamp(tgtHdg, minHdg, maxHdg);
                }

It needs to be able to target headings such that the aircraft makes a SINGLE, SMOOTH turn from any angle onto the localizer. Currently it works alright, but doesn't work well in very high angle intercepts, and often overcompensates from localizer overshoots. The problem is more severe the shorter the distance from the runway during turn-on.

[n8rzz]

we must be missing something because under the same circumstances in the current version, we don't have this problem. It's got to be something simple, these types of things usually are. I'm going to try and figure out what differs between the versions.

[n8rzz]

there is some definite math differences, the first spot is in the result of angle_offset. Seems like a good time to start adding tests to some of these math functions.

[n8rzz]

that seems to steam from the radians_normalize method that was added to Runway.angle which is getting run again when that property gets reassigned to angle (AircraftInstanceModel ln: 1983). reverting that change still doesn't solve the problem, though.

[erikquinn]

Covered by openscope/openscope#38. Closing.