20,741
edits
Implementing VNAV support in FlightGear: Difference between revisions
Jump to navigation
Jump to search
Implementing VNAV support in FlightGear (view source)
Revision as of 04:00, 7 December 2013
, 7 December 2013→Simulation within Simulation
m (→JSBSim) |
|||
| Line 210: | Line 210: | ||
However, the next step will involve exposing FDM parameters to the outer FDM/FCS, so that pitch and thrust settings can be modified via properties. | However, the next step will involve exposing FDM parameters to the outer FDM/FCS, so that pitch and thrust settings can be modified via properties. | ||
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 involved here, because the real FDM will be running and provide the corresponding questions to the outer FDM (or PID controller!). | 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!). | |||
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 217: | Line 219: | ||
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 certain legs. | |||
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. | ||
=== Standalone JSBSim === | === Standalone JSBSim === | ||