-
-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[META] Flight Plan Management and Guidance #4028
Comments
You say "The default nav data is missing information like turn direction" but as far as I have seen, the legs are fully encoded (including turn direction when relevant). I´ve been looking into the nav data (directly in the BGL files) but haven´t found a way to access it from within the sim... |
That is precisely the issue. The navdata APIs from inside the sim are lacking and do not provide all the information stored in the bgl. |
@pareil6 The other consideration is wind. If that isn't accounted for we may end up well off track by the end of a long turn. |
I think this is no longer relevant with all of the changes that have been made to the FMS in the meantime. I will close this issue, but feel free to reopen if you feel it's justified. |
Problem
The default flight plan manager is severely limited in multiple ways:
As it uses native APIs to manage the flight plan, we cannot modify or improve it significantly.
First Approach: Working Title Flight Plan Manager
To fix that, we've been rewriting it and have started from the Working Title (WT) code (MIT-licensed) as the basis, but need to still adjust lots of parts in it and make specific to our aircraft. The WT implementation lays a lot of effort on keeping the flight plan manager API compatible with the default code, but this has various limitations.
It works like this:
While this is a significant improvement, we're still far from being able to write accurate guidance:
Next Steps
Work is happening on the
autopilot-fpm
branch and being coordinated in #ata-22-fms on Discord.Please indicate when you're starting work on a specific part here, so there is no conflicts! There could also be multiple people working on the same thing, it just needs to be coordinated.
Here's a list of specific tasks that can be picked up in the
autopilot-fpm
branch:Flight Plan
Store the flight plan as a list of waypoints with leg information. Rationale.
After the above rework: Rewrite the flight plan page, from scratch. It's a total mess and still uses many of the original concepts like a separate arrival segment. It needs to support:
Rework how waypoints are drawn on the ND (SvgWaypointElement). Right now they depend on the all-encompassing WayPoint object to hold some kind of reference to the SVG, but that isn't scalable and is broken right now. We need a different way to reliably draw a waypoint at a certain position, remove it when we no longer need it, and update e.g. it's text color.
Improve the sequencing. Whenever we sequence (either automatically through NAV or manually, by clearing the FROM waypoint in selected heading) the active waypoint needs to advance, and the previous waypoint needs to be deleted. While advancing works, deleting waypoints is prone to breaking the flight plan, especially because the flight plan page panicks when the first waypoint is no longer an airport.
Guidance
Implement turn anticipation distance for type 1 transitions. Right now, as soon as you've entered the type 1 transition segment we send a hard bank command to the autoflight systems. This is both extreme and unrealistic, as the aircraft can not go from level flight to fully. We need to start the turn earlier and rather than sending bank angle 0 -> 0 -> 25 -> 25 we need to construct a geometric path that actually turns the aircraft in (0 -> 5 -> 15 -> 25). This will make our curves smoother and more accurate.
Start implementing type 2 transitions between legs. We need someone who doesn't shy away from physics and geometry to come up an implement formulas to construct the more complicated leg geometry. We have some basic logic for type 1 transitions, but type 2 is the complicated one. This type of transition happens when you overfly a waypoint and then turn sharply towards the path to the next waypoint, and then turn back again as you approach the path so you point at the new waypoint again. This geometry needs to be constructed based on ground speed.
Implement our first flight plan solver. This is the speed/altitude/energy management part (VNAV) and the backbone of managed flight. It needs to take all kinds of inputs, and propose a plausible trajectory, which means it needs to be able to predict a certain altitude and speed at every step of the flight plan. This is the system that will be run whenever the flight plan is fully entered, and populate the flight plan page with altitude/speeds at every waypoint. It also needs to be able to tell where the pseudo-waypoints (like DECEL, SPD LIMIT are), which are then overlayed on top the flight plan.
The text was updated successfully, but these errors were encountered: