20,741
edits
Line 252: | Line 252: | ||
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, whenever it cannot achieve a certain FPA without additional drag, i.e. when pitch/thrust changes alone won't suffice. | ||
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. | 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. |