Correct interpolation for drag force

[patrick-gu]

Also "fixed" PID so it's not completely incorrect

---

This change is 

[patrick-gu]

Not sure if that fixed it, new values: 0% extension: 10265 m, 100% extension: 9720 m

[celery6]

doesn't the interpolation code also just invert the OR calculation? I don't see how the latest commit actually changes anything aside from shuffling around where the "inverted calculation" happens.

Making one of those block diagrams would be nice at this point ngl. there's a lot more computation modules now

[patrick-gu]

The inverted calculation here should exactly match what OR does now, which I believe was not the case before

[celery6]

Does this new calculation account for the fact that the ansys-provided drag values already divide out some of the factors? That's why the previous calculation in TrajectoryPrediction wasn't exactly an inversion of OR. I think there was a comment about it but I just noticed that line also got changed in this PR..?

Can we write out this calculation process in a more readable way than bashing code like this? That way other controls ppl can also double check quirks and stuff.

[patrick-gu]

Here's what's happening: 1) Given the quadratic curves, we have drag force as a function of velocity in the Z direction at extensions 0, 0.5, and 1 2) We calculate (lazily) the values of these curves at the given velocity in the Z direction, for extensions 0, 0.5, and 1 3) Now, given the extension, we use linear interpolation between the values given in (2) to calculate drag force 4) The value in (3) is divided by the air density at 1000 m, which was the reference, and multiplied by the air density at the particular altitude. Air density code is the one in Ansys. 5) We use the drag force from (4) and invert OR's drag force calculation to get the CD, which we override

I agree that it's important this should be checked, I'll send this in Slack

[celery6]

possible sus things happening with ref area ?? but this factor is insignificant in practice so lgtm

[patrick-gu]

My intention with this is that since we have drag force, the ref area is ultimately not relevant here. Whatever OR or we calculate ref area to be is not important as they are not actually inputs to calculations.

[celery6]

ok this makes sense. I forgot about the step (6.) where OR uses our Cd to calculate drag force. so cancelling out everything OR uses is logical :+1:

should note this somewhere persistent for future and other's reference