Adding throttle control to GASP 2DOF missions

[EdoAlvarezR]

Hi guys!

I am running FwGm missions (GASP 2DOF) and noticed that throttle is fixed at each phase according to what I set as initial guess. I see in the TwoDOFODE class that the add_throttle_control method is defined, but it is never called by any of the phase builders. I tried calling that method while adding throttle either as a control or a state (see fork), but there seems to be something that I'm missing.

Could you provide some guidance on how to add throttle control, or even better, look at the fork and see if you spot something obvious that I'm missing?

Thanks for you help! =]

[jkirk5]

I think the context you are missing is that for 2DOF throttle is already a control, so dymos has the ability to set its value. However, when that control is added (two_dof_problem_configurator.py line 361) it is specified as opt=False, so it isn't allowed to change. So the initial guess becomes the final value used. The solution is probably to incorporate the throttle enforcement methodology used in height energy, which includes control as an option (as well as supports multiple unique engine types, which 2dof currently doesn't play nicely with.

As a quick hack setting that opt to True and changing nothing else might actually work. The "right" answer is to rewrite the problem configurator to handle throttle better, which I'm interested in doing in the near term but will take me at least a couple weeks to do

[EdoAlvarezR]

Sharing my learnings: the GASP-based mission is much more robust when the optimizer is allowed to optimize the throttle. Here is what I did. That being said, groundroll and rotation struggle with throttle control, so it's better to prescribe throttle for those phases (at least for a conventional aircraft).

[jkirk5]

Thanks for investigating Ed! Would you like to submit those changes as a PR? It would require running the test suite and identifying and updating any changes in values due to the throttle behavior change - basically for benchmark tests we just want to make sure the values "make sense", there are no truth values for the trajectories other than what Aviary can consistently reproduce.