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:35, 7 December 2013
, 7 December 2013→Simulation within Simulation
| Line 206: | Line 206: | ||
This turned out to be pretty straightforward to play with in JSBSim so far. | This turned out to be pretty straightforward to play with in JSBSim so far. | ||
Obviously, this bit could have also been accomplished with existing Autopilot components in FlightGear or JSBSim, with much less work. | Obviously, this bit could have also been accomplished with existing Autopilot components in FlightGear or JSBSim, with much less work, because it just involves a extrapolation/prediction. | ||
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. | ||
| Line 213: | Line 213: | ||
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!). | 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!). | ||
Which will also allow us to determine how much fuel will be left at certain points along the route. | |||
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 249: | Line 250: | ||
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. | 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, which could have a new component that runs another FDM instance as part of a PID controller cascade to come up with pitch/thrust settings for each VNAV constraint. | ||
Aircraft developers would then be required to encode aircraft-specific constraints that can be used by the system (such as min/max pitch, configuration speeds etc). | |||
Runtime-specific constraints would need to be set up via the property tree, so that they can be entered via the CDU/FMC (or route manager). This would typically involve different ECON profiles etc. | |||
=== Standalone JSBSim === | === Standalone JSBSim === | ||