Open alexandruast opened 6 years ago
The thing that bothers me most is the final uncontrolled burn. This smells NRE to me.
dV calculation: did you have the Use Breaks enabled in landing options? If not, have you engaged the brakes before the calculation or after?
As for the steepness, it is chosen by a complex heuristic that includes overheating predictions and tries to be on the safe side of it. So if it decided to deorbit like this, it has the reason to. May not be optimal for particular rocket, but is safe. Than again, it's like with all autopilots: human could do better, but human is lazy :)
I am experimenting with different rocket designs.
Let's keep the final uncontrolled burn aside, since I might probably triggered it by accident. I still want to investigate this properly.
I used AIRBRAKES triggered manually, before landing calculation, and also triggered automatically by TCA. There is a large dV difference, like 1400 dV with airbrakes triggered manually while in orbit and ~ 900dV with airbrakes retracted and managed by TCA, which makes sense now :)
The issue that really remains is why is TCA triggering an emergency landing, considering that the rocket is using airbrakes and has 1800dV left (KER reads a terminal velocity of 479m/s)
It seems to me that the reason it does trigger the emergency landing is because it somehow miscalculates the terminal velocity, because it ends up short of the landing site, with and without airbrakes, and with more than enough fuel left.
Well, I've figured this out, but don't yet know how to improve things robustly. There are indeed some errors in drag prediction algorithm that account for the effect you see. But the problem is deeper: KSP aerodynamic model is quite complex and cannot be approximated well enough while still allowing for in-frame evaluation of complete landing trajectory. So if I increase drag contribution to better approximate things, this would still be a miss, always. So, 1) we need to be on the safe side and prefer false negatives (like the one this issue is about) and 2) the landing algorithm should be prepared that landing site predictions are unreliable. And the best way to do the latter is to make predictions biased instead of randomly inaccurate. Say, always predict LS to be closer than it will be; but this would also affect overheating predictions, giving more false positives... So, all in all, things are complicated here.
I know that there were many hours involved in this, but I would completely ditch out the overheating stuff if I were you, and let the user decide how to protect the vessel (changing orbit, using ablators etc...), given the circumstances.
With teh thermal stuff out of the equation, you can just postpone any suicide burn on bodies with atmosphere until your impact_eta starts to increase (which signals entering the atmosphere), after that the atmosphere will push the impact_eta further enough to not warrant any modifications on the hoverslam equation.
This should be considerably improved in the latest versions. Need to retest it.
Edit: I think there are two separate issues, or I am not using TCA properly :)
Steps to reproduce: Create a rocket equipped with Twin Boar, HECS2, and 4 x A.I.R.B.R.A.K.E.S. (KER reports ~ 4000 dV) In Orbital Autopilots, set surface target to current launchpad. Place the vessel in Kerbin orbit using the debug menu -> cheats -> set orbit. From Orbital Autopilots, select Land.
It will complain with WARNING: fuel is 100% below safe margin for powered landing. Push to proceed.
First deorbit burn is way too much at ~ 1500 dV, basically killing the horizontal speed while out in space.
Atmosphere burn at 40k, dropping vertical speed to about 240m/s, too much, again TCA switches to emergency landing because not enough dV (1327 dV left at this point)
Because of airbrakes, the vertical speed drops to ~ 250m/s without thrust assist, but TCA still reports impact at ~ 450m/s
After briefly touching down with more than 1000dV left, the rocket is sent again up in the sky, burning the remaining fuel