20,741
edits
Implementing VNAV support in FlightGear: Difference between revisions
Jump to navigation
Jump to search
m
Implementing VNAV support in FlightGear (view source)
Revision as of 04:31, 7 December 2013
, 7 December 2013→Simulation within Simulation
| Line 212: | Line 212: | ||
Basically, the idea is to initialize the 2nd FDM instance with values from the first/outer FDM (position, speeds, orientation, weight & balance etc) integrate over a longer time frame (less granularity). | Basically, the idea is to initialize the 2nd FDM instance with values from the first/outer FDM (position, speeds, orientation, weight & balance etc) integrate over a longer time frame (less granularity). | ||
This will allow us to ask questions like "where am I going to be in 5 minutes if I change pitch by 1 degree and thrust by 5%". The cool thing is, there's no guesswork or fancy maths involved here, because the real FDM will be running and provide the corresponding questions to the outer FDM (or PID controller!). | This will allow us to ask questions like "where am I going to be in 5 minutes if I change pitch by 1 degree and thrust by 5%". The cool thing is, there's no guesswork or fancy maths involved here to make this work, because the real FDM will be running and provide the corresponding questions to the outer FDM (or PID controller!). | ||
Subsequently, we need a way to encode flight plans in VNAV terms, which mostly boils down to formalizing typical VNAV constraints. | Subsequently, we need a way to encode flight plans in VNAV terms, which mostly boils down to formalizing typical VNAV constraints. | ||
| Line 220: | Line 220: | ||
Thus, a basic test scenario would involve a route with various waypoints and different altitudes, so that we end up with different FPAs (gradients) to maintain on each leg. A PID controller (or FCS) could then basically use the 2nd nested/embedded FDM instance to come up with pitch/thrust settings for each leg and assemble a list of pitch/thrust settings. | Thus, a basic test scenario would involve a route with various waypoints and different altitudes, so that we end up with different FPAs (gradients) to maintain on each leg. A PID controller (or FCS) could then basically use the 2nd nested/embedded FDM instance to come up with pitch/thrust settings for each leg and assemble a list of pitch/thrust settings. | ||
Obviously, we need a way to also encode min/max speeds for different altitudes and aircraft configurations, so that the 2nd FDM doesn't come up with values that are outside safety margins. The 2nd FDM would also need a way to encode typical messages like "drag required" for | In Pseudo-Code: | ||
<syntaxhighlight lang="nasal"> | |||
foreach(var waypoint; waypoints) { | |||
# compute distance between this and the next waypoint | |||
# compute altitude difference between this and the next waypoint | |||
# turn this into a gradient (altitude vs. groundspeed) and flight path angle (min/max FPA required) for the FMS | |||
# add the FPA info to each leg of the flight plan (route manager in FG) | |||
} | |||
</syntaxhighlight> | |||
The second FDM (running as a child FDM), would then be presented with a list of waypoints and FPAs, and asked for pitch/thrust settings to make each gradient. | |||
In its first iteration, we will keep this straightforward and focus only on the current leg. | |||
However, we will also need to really solve this in reverse for the whole route (like a real flight planning tool/FMS), i.e. each leg: | |||
In Pseudo-Code: | |||
<syntaxhighlight lang="nasal"> | |||
foreach(var waypoint; reverse(waypoints) ) { | |||
# get required FPA | |||
# get relevant constraints (groundspeed, vertical speed, min/max thrust and pitch) | |||
# compute a range of usable pitch/thrust settings to satisfy the constraints | |||
# rinse & repeat | |||
} | |||
</syntaxhighlight> | |||
Obviously, we need a way to also encode min/max speeds for different altitudes and aircraft configurations, so that the 2nd FDM doesn't come up with values that are outside safety margins. The 2nd FDM would also need a way to encode typical messages like "drag required" for example. | |||
At that point it should be relatively straightforward to move some parts back into FlightGear, i.e. its AP system. | At that point it should be relatively straightforward to move some parts back into FlightGear, i.e. its AP system. | ||