Implementing VNAV support in FlightGear: Difference between revisions

Jump to navigation Jump to search
m
Line 175: Line 175:
* an interface for flightgear to query the data file through the DBMS (FlightGear's scripting language Nasal does have SQLite bindings, another option would be a flat text/XML file)
* an interface for flightgear to query the data file through the DBMS (FlightGear's scripting language Nasal does have SQLite bindings, another option would be a flat text/XML file)
* a way of implementing this data into the aircraft's model(usually xml file)
* a way of implementing this data into the aircraft's model(usually xml file)


== JSBSim ==
== JSBSim ==
Line 200: Line 201:


It is foreseeable that we may need to modify and extend JSBSim, i.e. to add new components - unfortunately, the "Extending JSBSim" chapter in the JSBSim reference manual is still just a placeholder without any content, so here are some stubs to help lower the barrier to entry when extending JSBSim.
It is foreseeable that we may need to modify and extend JSBSim, i.e. to add new components - unfortunately, the "Extending JSBSim" chapter in the JSBSim reference manual is still just a placeholder without any content, so here are some stubs to help lower the barrier to entry when extending JSBSim.
=== Simulation within Simulation ===
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.
Obviously, this bit could have also been accomplished with existing Autopilot components in FlightGear or JSBSim, with much less work.
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!).
Subsequently, we need a way to encode flight plans in VNAV terms, which mostly boils down to formalizing typical VNAV constraints.
For starters, we can focus on flight path angles (FPAs), because that's what all VNAV/FMS internally work with. Computing the FPA between two waypoints and altitudes is also straightforward to do, i.e. just a matter of calculating the great circle distance (via Haversine, already supported by both, JSBSim and FG), and the altitude difference, i.e. groundspeed vs. altitude gradient required to maintain the FPA.
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.
At that point it should be relatively straightforward to move some parts back into FlightGear, i.e. its AP system.


=== Standalone JSBSim ===
=== Standalone JSBSim ===

Navigation menu