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:39, 7 December 2013
, 7 December 2013→Simulation within Simulation
| Line 203: | Line 203: | ||
=== Simulation within Simulation === | === Simulation within Simulation === | ||
'''Update: 12/2013''' | |||
Due to the lack of a real performance DB, one of the earliest attempts related to this was running a 2nd (nested) FDM instance next to the main FDM (i.e. in parallel) with a greater time step (dT) when integrating, in order to gather values from it about the future state of the simulation, such as e.g. position in 10 seconds, 30 seconds or 10 minutes. | Due to the lack of a real performance DB, one of the earliest attempts related to this was running a 2nd (nested) FDM instance next to the main FDM (i.e. in parallel) with a greater time step (dT) when integrating, in order to gather values from it about the future state of the simulation, such as e.g. position in 10 seconds, 30 seconds or 10 minutes. | ||
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, because it just involves | Obviously, this bit could have also been accomplished with existing Autopilot components in FlightGear or JSBSim, with much less work, because it just involves an 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 212: | Line 214: | ||
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 to make this work, because the real FDM will be running and provide the corresponding | 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%", i.e. stuff that cannot be easily solved by extrapolation, because it involves the whole world model, such as different altitude (air density), fuel consumption, temperature, winds etc. | ||
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 answers 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. | Which will also allow us to determine how much fuel will be left at certain points along the route. | ||
| Line 233: | Line 237: | ||
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. | 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. | In its first iteration, we will keep this straightforward and focus only on the current leg, without applying any restrictions (such as 250 kts below FL100). | ||
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: | 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: | ||