Deceleration Readouts (New Pull)

[harryyoung]

Added deceleration readouts for landing burn
This method includes horizontal velocity as opposed to only vertical velocity with the current suicide burn.

Video Demonstrations:
https://youtu.be/6Rb1LDvKdok
https://youtu.be/Q0ZK6VkDYRE

Closes #93 and #39

Previous Pull Request: #95

[fat-lobyte]

Thanks for opening the new pull request :)
I suggest to not commit any more .dll/.pdb/.htm files to avoid conflicts.

So just for clarification, to be sure that I understand all the values correctly, I have a few questions:

A "deceleration burn" is when I burn in the opposite of my velocity vector, with full thrust?
Deceleration Longitude/Latitude is the Longitude/Latitude the vessel will have after I cancel out my velocity?
Deceleration Biome is the Biome under me, after I cancel out my velocity?
Deceleration Remaining Altitude is the altitude after I cancel out my velocity?

Assuming the answers are yes, may I suggest the following some name changes?
Following the naming convention

Eventually, the old "Suicide Burn" should be replaced by the Deceleration readouts, because they are the real deceleration readouts.

Deceleration Altitude -> Deceleration Burn (Alt.)
Deceleration Remaining Altitude -> Deceleration Burn (Dist.)
Deceleration DeltaV -> Deceleration Burn (dV)
Horizontal Deceleration Distance -> Deceleration Distance (horiz.)
Total Deceleration Distance -> Deceleration Distance (total.)
Vertical Deceleration Distance -> Deceleration Distance (vert.)

This would make the readouts more compact and easy to read.

[harryyoung]

Yes, altough the Lat/long/Biome/alt are rather rough as they get updated in real time.

Replacement would be up to Cybutek, tho it would make sense, this system is more versatile.

I will take a look at the naming conventions, Maybe get them a little more inline

Thanks foor Your Help

[fat-lobyte]

So I have done some testing, and I discovered a few Issues.

First, download this file: https://dl.dropboxusercontent.com/u/1414175/ksp/quicksave-minmus-plains-landing.sfs

The Quicksave is a stock craft descending onto the plains of minmus. I did that, because they are completely flat and eliminates terrain altitude as a source of problems.

I noticed a few things:

Incorrect terrain Biome and altitude

Even when I fly over the edge of the plain and the flat (0m) terrain of the Greater Flats is directly under me, "Deceleration Biome" varies - but does not show the correct "Greater Flats". The same thing with Deceleration Terrain Altitude, which should read 0m - but it does not, see this screenshot:

It only shows Greater Flats after I am a few kilometers inwards.

Increasing "Deceleration Remaining Altitude" during burn

When I wait until I Deceleration Remaining Altitude is 0m (or very low), and then start the burn, shouldn't I stop right above the surface? However, what I am seeing is that after I start the burn - the number goes up again! If I start with Deceleration Remaining Altitude at 0m, by the time the velocity reaches 0 m/s relative to the surface, I am 218m above the surface.

Drifting Latitude/Longitude

While I am burning, shouldn't "Deceleration Longitude/Latitude" remain constant? For me, it constantly drifts east.

Also I just noticed that the further away I am from the ground, the more "wrong" the Latitude/Longitude are.

Watching your video, it seems that those problems are not there in the version you had when you made the video. Perhaps there have been some more changes in KSP 1.2 that you missed?

[harryyoung]

will have to take a look at this tomorrow.

[harryyoung]

that save drops me to low kerbin orbit, so i cannot reproduce it using that save. I did send a probe to minmus myself and it worked as expected.

Be aware that if you burned under the condtions in the screenshot you'd still spend some time in free fall while minmus rotates under you. That rotation is included into the calculations, giving you a landing position in the hills you just passed. A bit counter intuitive, but once you tought it trough or just sit and do nothing until impact it makes sense.

I also picked up your suggestion and changed the readout's name and info text. They now all start with Decel. Burn: X or Decel Point: X

[fat-lobyte]

that save drops me to low kerbin orbit, so i cannot reproduce it using that save.

Ooops, that's my bad. Download again from the same link.

Be aware that if you burned under the condtions in the screenshot you'd still spend some time in free fall while minmus rotates under you. That rotation is included into the calculations, giving you a landing position in the hills you just passed.

So first of all, I just tried it out and that's not the case. If I retro-burn at the time when at a time when I am over the Lowlands, but deceleration Biome says Greater Flats, then at the end of the burn I am in Greater Flats, although I should have been in Lowlands.

Second, that still does not solve the drifting issue. When I am already doing the burn, how can the position after burn and the altitude still drift? They have to be fixed for the duration of the burn, unless I completely misunderstood something.

If the Deceleration remaining altitude is a promise "burn now, then you will be at that altitude", the I constantly get the promise violated, because I start the burn at dec. alt. 0 and at the end of the burn, I end up somewhere from 80m to 200m above the surface.

[fat-lobyte]

I used the Stock "Super-Heavy Lander" with reduced thrust for testing, which has offset thrust. (KER's "Vectored Thrust" was enabled), there the altitude was wrong.

With the Kerbal 2 Stock craft, which has only one inline-engine, the altitude prediction was almost correct, but the terrain altitude/lat/lon is still wrong.

In fact, I managed to crash into a mountain at the end of the Greater Flats while KER was happily telling me that "deceleration altitude 300m" and "deceleration biome greater flats". I'm pretty convinced there is some more funk going on.

I can provide more saves or create a video if you want.

[harryyoung]

I see: you are taking a rather shallow approach. I've mostly been doing medium steep aproaches to aim more aggressivelöy for a landing point. Might have to take a closer look at this, see if I missed something.

The Idea of getting you to land if you burn at 0 remaining altitude is more an ideal than a promise. It will get you to a hover close to the surface. That is also why I chose Deceleration burn instead of landing burn as a name

The drift is a phenomenon of the calculation process. Every frame the game recalculates the burn, however all the information I have to begin with is my current position and my current velocity vectors. I also know that i will gain velocity trough free fall, however I need to calculate that using either one of two methods:

1: Use my current radar altitude as freefall distance. This is currently implemented and gives a rater rough landing point in one step. If the terrain under your flight path generally sloped down or stays flat it will get you to a hover over the landing point, the actual remaining altitude depending on the burn power and the difference in altitude. So it is a conservative approach in this regard. It won't save you tho if you fly into a hill side. That requires pilot awareness to do an early burn and then a landing.

2: Get the point using an iterative process. Calculate how long it takes to kill your current surface velocity, from that get the added velocity trough gravity, add that in and repeat multiple times. This will give you an end point with a little more presision, however it will require some more prossessing time.

I've been giving the second option some thought. wil try to see if I can find a god dynamic iteration limit with good accuracy.

[harryyoung]

Gnah, Lat/lon calc are messed up again. That is why the biome info is off.

[fat-lobyte]

What I don't get is: why do I need the radar altitude at all? A retro burn to kill current velocity will take almost the same time if I do it at 1km, 10km or 50km, and therefor the horizontal distance and vertical distance will be the same too (except for tiny deviations due to decreased gravity at higher altitudes).

So why not just go the horizontal distance forward, check the terrain altitude at that position, then subtract (current sea-level altitude + vertical deceleration distance) from the terrain altitude at that position to get the deceleration remaining altitude?

Note to self: check out MechJeb, because last time I checked, their Suicide Burns were rock solid.

I've been giving the second option some thought. wil try to see if I can find a god dynamic iteration limit with good accuracy.

In case you go with option 2, there is some code in ImpactProcessor that does... something. (I noticed the impact time being wrong too, btw - but that's not related to your pull request).

[fat-lobyte]

Here is MechJebs version of the Suicide Burn countdown, and it works without any simulations and is still pretty accurate:

public static double SuicideBurnCountdown(Orbit orbit, VesselState vesselState, Vessel vessel)
{
	if (vesselState.mainBody == null) return 0;
	if (orbit.PeA > 0) return Double.PositiveInfinity;

	double angleFromHorizontal = 90 - Vector3d.Angle(-vessel.srf_velocity, vesselState.up);
	angleFromHorizontal = MuUtils.Clamp(angleFromHorizontal, 0, 90);
	double sine = Math.Sin(angleFromHorizontal * UtilMath.Deg2Rad);
	double g = vesselState.localg;
	double T = vesselState.limitedMaxThrustAccel;

	double effectiveDecel = 0.5 * (-2 * g * sine + Math.Sqrt((2 * g * sine) * (2 * g * sine) + 4 * (T * T - g * g)));
	double decelTime = vesselState.speedSurface / effectiveDecel;

	Vector3d estimatedLandingSite = vesselState.CoM + 0.5 * decelTime * vessel.srf_velocity;
	double terrainRadius = vesselState.mainBody.Radius + vesselState.mainBody.TerrainAltitude(estimatedLandingSite);
	double impactTime = 0;
	try
	{
		impactTime = orbit.NextTimeOfRadius(vesselState.time, terrainRadius);
	}
	catch (ArgumentException)
	{
		return 0;
	}
	return impactTime - decelTime / 2 - vesselState.time;
}

Could you maybe use this code?