AP2 reference model discussion

[jdeschut]

@rcleuthold

• What are the sources of the aero_validity constraints? In Licitra2019a, we find for alpha: [-6.0, 9.0] deg, and beta: [-20.0, 20.0] deg, whereas in ampyx_data.py it is implemented as:

aero_validity['alpha_max_deg'] = 10.
aero_validity['alpha_min_deg'] = -5.
aero_validity['beta_max_deg'] = 3.
aero_validity['beta_min_deg'] = -3.

• Why is the angular velocity inequality implemented as a norm inequality? To me, it seems as though in Licitra2019a, they are intended as simple variable bounds.

Maybe we can bundle our experiences with the AP2 reference model in this thread?

[rcleuthold]

Yeah. That's a good question. The current (new) ampyx AP2 coefficients come from the validation paper of Elena Malz, et al. # A reference model for airborne wind energy systems for optimization and control # Article # March 2019 Renewable Energy # Elena Malz Jonas Koenemann S. Sieberling Sebastien Gros And, in this paper there are no bounds explicitly listed. However, there are plots of the various inputs, as they were measured during the generation of the data that was used for the curve-fitting. Since this model has a number of higher order terms, if the limits are not cropped, I had some trouble with convergence. (On this same vane, I also put in an additional inequality constraint into aero-validity, saying that CD > 0.) If you "find" better bounds, you're welcome to switch them. But, these values are the ones that I think correspond to the stability-derivative-fit given in Malz2019. (Remember, that prior to using the Malz2019 model, we had an aero-stability-fit from the internal Ampyx document from Giani, where the bounds were wider, but which was a) not peer-reviewed, and b) was more likely to need the unfortunately-messy effective-to-apparent reference velocity conversion. I'm necessarily convinced then, that the previous bounds were any more realistic than the current ones.) My thoughts, anyways...

…

On Mon, Feb 15, 2021 at 12:55 PM Jochem De Schutter < ***@***.***> wrote: @rcleuthold <https://github.com/rcleuthold> - What are the sources of the aero_validity constraints? In Licitra2019a <https://cdn.syscop.de/publications/Licitra2019a.pdf>, we find for alpha: [-6.0, 9.0] deg, and beta: [-20.0, 20.0] deg, whereas in ampyx_data.py it is implemented as: aero_validity['alpha_max_deg'] = 10. aero_validity['alpha_min_deg'] = -5. aero_validity['beta_max_deg'] = 3. aero_validity['beta_min_deg'] = -3. - Why is the angular velocity inequality implemented as a norm inequality? To me, it seems as though in Licitra2019a, they are intended as simple variable bounds. Maybe we can bundle our experiences with the AP2 reference model in this thread? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#65>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEBDMZNNF74PP3Y7F4C5PJLS7EDT7ANCNFSM4XUR3UIQ> .

[jdeschut]

So if I understand correctly, the CD_min-constraint is a practical substitute for the case when the correct aero-validity bounds are not known? I guess we can work with that: if the aero-validity bounds are correct, it will never be active.

What about the angular velocity inequality?

[rcleuthold]

Yes, exactly. The point is the same: we've semi-arbitrarily Chosen the omega bounds... So, they're still necessary, but we can't guarantee that they're sufficient...

…

On Thu, Feb 18, 2021, 16:43 Jochem De Schutter ***@***.***> wrote: So if I understand correctly, the CD_min-constraint is a practical substitute for the case when the correct aero-validity bounds are not known? I guess we can work with that: if the aero-validity bounds are correct, it will never be active. What about the angular velocity inequality? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#65 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEBDMZIPCMSQTA74T6ZIG23S7UYSXANCNFSM4XUR3UIQ> .

[jdeschut]

Yes, I meant why not just put simple bounds instead of a norm inequality? (In Licitra2019a, also peer-reviewed) they seem to be simple bounds).

I checked and compared the stability derivatives in Malz2019 and Licitra2019a in more detail, and they are more or less the same. In this sense I think it reasonable to take the flight envelope (alpha, beta, airspeed, omega, surface deflections an their rates) from Licitra2019a.

The only weird thing is that the static coefficients of Licitra2019a are completely, inexplicably off (I sent a figure via e-mail, where I chross-checked with another AP2-look-up table). It's very strange that it is only the static coefficient polynomials which are wrong. The coefficients are defined in exactly the same way as in Malz2019 (body frame with NED convention).

[rcleuthold]

Yes, ok. I'm in favor of simple [vector] bounds, since the various roll/pitch/yaw rates are all treated differently wrt the aero. stability derivatives.

…

On Fri, Feb 19, 2021 at 12:06 PM Jochem De Schutter < ***@***.***> wrote: Yes, I meant why not just put simple bounds instead of a norm inequality? (In Licitra2019a <https://cdn.syscop.de/publications/Licitra2019a.pdf>, also peer-reviewed) they seem to be simple bounds). I checked and compared the stability derivatives in Malz2019 and Licitra2019a in more detail, and they are more or less the same. In this sense I think it reasonable to take the flight envelope (alpha, beta, airspeed, omega, surface deflections an their rates) from Licitra2019a. The only weird thing is that the static coefficients of Licitra2019a are completely, inexplicably off (I sent a figure via e-mail, where I chross-checked with another AP2-look-up table). It's very strange that it is only the static coefficient polynomials which are wrong. The coefficients are defined in exactly the same way as in Malz2019 (body frame with NED convention). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#65 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEBDMZLRJC7U3Y4UECAGIG3S7ZA4BANCNFSM4XUR3UIQ> .