Suicide Burn mod Development - Updated 5/12 - Almost BETA time

[linuxgurugamer]

Ok, thanks.

I wasn't really worrying about the change in mass, have been adjusting the throttle on the way down.

I've fixed the formula, it's now providing good data.  I'll be using it moving forward.

It doesn't account for throttle time on engines, but that's easy enough to estimate.  Since I have an internal setting of 1/4 second to go from 0 to full throttle, I'm just adding 1/4 second of vertical speed to the decel distance

Edited May 17, 2017 by linuxgurugamer

[linuxgurugamer]

On 5/15/2017 at 4:01 PM, Pand5461 said:

Proportional-Integral-Derivative control.

In this case, Integral part won't be needed, I think, so it will be just PD-controller

So, PD(x) = K_P*( x(t) - x₀(t) ) + K_D* d( x(t) - x₀(t) )/dt,

where x is the actual value of signal, x₀ is what you wanted the signal to be.

For those who lives in a discrete time (hint: kerbals do) that changes to

PD(x) = K_P*Δ(t_now) + K_D* (Δ(t_now) - Δ(t_prev) ) / ( t_now - t_prev),

where Δ(t) is short for ( x(t) - x₀(t) ), t_now is current time, t_prev is the time of previous calculation of Δ(t).

So, in the above case X is height, X₀ is calculated h_s, and K_P and K_D must be negative numbers (need to throttle up when ship is too low, and throttle up even harder if it goes increasingly below the right height).

So, I assume the K_p and K_d are constants which are used to tune this?

Edit:  from the Wikipedia:

K_P = accounts for present values of the error. For example, if the error is large and positive, the control output will also be large and positive.

K_D = accounts for possible future trends of the error, based on its current rate of change

Edited May 17, 2017 by linuxgurugamer

[linuxgurugamer]

Ok, I now have the PID controller working.

The given formula above still sometimes slows down the vessel too much, but the PID controller is now compensating for that.

Still having an issue with KW Rocketyr engines, their spooltime is 2 seconds, which is (so far) not compensatable for yet.

[Kartoffelkuchen]

49 minutes ago, linuxgurugamer said:

Ok, I now have the PID controller working.

The given formula above still sometimes slows down the vessel too much, but the PID controller is now compensating for that.

Still having an issue with KW Rocketyr engines, their spooltime is 2 seconds, which is (so far) not compensatable for yet.

Since this is an actual plugin and not a kOS script I think it should be fairly easy to access the spool up time for each engine used for the landing and include that in the equations..

[linuxgurugamer]

36 minutes ago, Kartoffelkuchen said:

Since this is an actual plugin and not a kOS script I think it should be fairly easy to access the spool up time for each engine used for the landing and include that in the equations..

The problem is for the KW engines, it's a 2 second spoolup and 2.3 second spooldown.  

Frankly, I'm not going to worry about this, I will add some code to warn about engines which have too long a spool time.  When doing a Suicide burn, you need fast response anyway.

[Pand5461]

3 hours ago, linuxgurugamer said:

Ok, thanks.

I wasn't really worrying about the change in mass, have been adjusting the throttle on the way down.

I've fixed the formula, it's now providing good data.  I'll be using it moving forward.

It doesn't account for throttle time on engines, but that's easy enough to estimate.  Since I have an internal setting of 1/4 second to go from 0 to full throttle, I'm just adding 1/4 second of vertical speed to the decel distance

This formula was derived for conditions quite a bit different from what your test case is. And AAARRGH, I've written the wrong explanation for the formula. Now I've redone all the steps to derive it, a_dry is in fact the

Thrust / mass_at_start_of_burn . "Dry" is because it was initially a part of a big landing script, and suicide burn was using the last liters of propellant.

In that case, throttling down was not a good option because every extra second of burning devours delta-V, and the lander had barely enough to casually spend few tens of m/s for no good reason. And, although change of TWR from 1.05 to 1.1 during the suicide burn might not seem that big, the actual deceleration changes twofold (because it's TWR-1 that defines deceleration) and the real suicide burn is significantly shorter than constant-TWR one. These are two main reasons I bothered to find a more accurate approximation than simply  t = speed / (total thrust / mass - g).

Quote

The given formula above still sometimes slows down the vessel too much, but the PID controller is now compensating for that.

The big formula or the short one?

 

[linuxgurugamer]

4 minutes ago, Pand5461 said:

This formula was derived for conditions quite a bit different from what your test case is. And AAARRGH, I've written the wrong explanation for the formula. Now I've redone all the steps to derive it, a_dry is in fact the

Thrust / mass_at_start_of_burn . "Dry" is because it was initially a part of a big landing script, and suicide burn was using the last liters of propellant.

In that case, throttling down was not a good option because every extra second of burning devours delta-V, and the lander had barely enough to casually spend few tens of m/s for no good reason. And, although change of TWR from 1.05 to 1.1 during the suicide burn might not seem that big, the actual deceleration changes twofold (because it's TWR-1 that defines deceleration) and the real suicide burn is significantly shorter than constant-TWR one. These are two main reasons I bothered to find a more accurate approximation than simply  t = speed / (total thrust / mass - g).

The big formula or the short one?

 

The big one:  t_s = (g - a_dry + sqrt( (g - a_dry)² - 2*V*a_dry²/(Isp*g₀) ) ) * (Isp*g₀)/a_dry²

I'm targeting a throttle of 95% and a target altitude of 2 m agl, what's been happening is that if I left it at 95%, some vessels are ready to hover at 150-200m high

My PID controller is now controlling it, I see the throttle drop down to about 50-70% at times because it is too high.  Not a big deal, would be nice to fix if possible

Edited May 17, 2017 by linuxgurugamer

[Pand5461]

When it fails, what are initial height, vspeed, twr and planet?

EDIT: if it's Kerbin and starting vspeed is near or above terminal velocity, then formula is expected to fail

Edited May 17, 2017 by Pand5461

[linuxgurugamer]

11 minutes ago, Pand5461 said:

When it fails, what are initial height, vspeed, twr and planet?

EDIT: if it's Kerbin and starting vspeed is near or above terminal velocity, then formula is expected to fail

These tests are as follows (I'll do more intensive testing this evening):

• Took the stock heavy lander, replaced the engines with the LV45
• Boosted straight up to about 1000-2000m
• Shut down engines, enabled Suicide Burn mod
• Lander coasted and then started to fall
• Engines started appropriately, lander came to a hover at about 150 m

I don't remember all the details right now, I'll do more this evening.

 

But, it's definitely not at terminal velocity when I enable it.

[Pand5461]

Okay, correction for atmospheric planets:

 t_s = (g - (T + F_d/3) / m + sqrt{ [g - (T + F_d/3) / m]² - 2*V*(T/m)²/(Isp*g₀) } ) * (Isp*g₀)/(T/m)²

where T is total thrust (projection onto vertical axis), m is vessel mass, F_d is drag force (projection onto vertical axis, positive number if going down), V is vertical speed (projection onto vertical axis, negative number if going down), Isp*g₀ = T/fuel_consumption = effective exhaust speed

h_s = -V*t_s - [(T + F_d/4) / m - g]*t_s²/2 - (T/m)²/(Isp*g₀)*t_s³ / 6

I hope it is possible to get drag value from the API because it's available in-game in Aero GUI.

Also, this expression for the burn distance may give better results:

h_s = (Isp*g₀)*(m - f*t_s) / f * ln[ m / (m - f*t_s) ] - (V + Isp*g₀)*t_s + ( g - F_d/(4*m) )*t_s²/2

where f is propellant consumption rate in kg/s or ton/s.

The latter is the proper integration of rocket equation at vertical descent with gravity and (quite simplified) drag, the previous one is the Taylor expansion of the same expression up to the cubic term.

[Kartoffelkuchen]

50 minutes ago, Pand5461 said:

Okay, correction for atmospheric planets:

 t_s = (g - (T + F_d/3) / m + sqrt{ [g - (T + F_d/3) / m]² - 2*V*(T/m)²/(Isp*g₀) } ) * (Isp*g₀)/(T/m)²

where T is total thrust (projection onto vertical axis), m is vessel mass, F_d is drag force (projection onto vertical axis, positive number if going down), V is vertical speed (projection onto vertical axis, negative number if going down), Isp*g₀ = T/fuel_consumption = effective exhaust speed

h_s = -V*t_s - [(T + F_d/4) / m - g]*t_s²/2 - (T/m)²/(Isp*g₀)*t_s³ / 6

I hope it is possible to get drag value from the API because it's available in-game in Aero GUI.

Also, this expression for the burn distance may give better results:

h_s = (Isp*g₀)*(m - f*t_s) / f * ln[ m / (m - f*t_s) ] - (V + Isp*g₀)*t_s + ( g - F_d/(4*m) )*t_s²/2

where f is propellant consumption rate in kg/s or ton/s.

The latter is the proper integration of rocket equation at vertical descent with gravity and (quite simplified) drag, the previous one is the Taylor expansion of the same expression up to the cubic term.

Dem you seem to know your stuff

[Pand5461]

@Kartoffelkuchen, just do not tell them that in fact I randomly combined some variables to make a formula that looks smart.

[captinjoehenry]

Will this support engines angled off the center line?  I have a few really big capsules that make use or radial mounted and angled capsules which throws off the suicide burn calculator for mechanic.  Here is an image to be clear what I mean.

[linuxgurugamer]

Yes

[Vanamonde]

Overlapping threads have been merged. 

[captinjoehenry]

If you can set it up like mechjeb where you need the part but it is a toolbar button that would be ideal!

[linuxgurugamer]

6 hours ago, Pand5461 said:

Okay, correction for atmospheric planets:

 t_s = (g - (T + F_d/3) / m + sqrt{ [g - (T + F_d/3) / m]² - 2*V*(T/m)²/(Isp*g₀) } ) * (Isp*g₀)/(T/m)²

where T is total thrust (projection onto vertical axis), m is vessel mass, F_d is drag force (projection onto vertical axis, positive number if going down), V is vertical speed (projection onto vertical axis, negative number if going down), Isp*g₀ = T/fuel_consumption = effective exhaust speed

h_s = -V*t_s - [(T + F_d/4) / m - g]*t_s²/2 - (T/m)²/(Isp*g₀)*t_s³ / 6

I hope it is possible to get drag value from the API because it's available in-game in Aero GUI.

Also, this expression for the burn distance may give better results:

h_s = (Isp*g₀)*(m - f*t_s) / f * ln[ m / (m - f*t_s) ] - (V + Isp*g₀)*t_s + ( g - F_d/(4*m) )*t_s²/2

where f is propellant consumption rate in kg/s or ton/s.

The latter is the proper integration of rocket equation at vertical descent with gravity and (quite simplified) drag, the previous one is the Taylor expansion of the same expression up to the cubic term.

ok, so you say to use these on a planet with an atmosphere, and the one posted earlier in non-atmosphere?

[linuxgurugamer]

I would have expected the new formula to be about the same as the old one if drag was = 0 (as a test), but it isn't.  The new formulas causes crashes

It could be the distance formula, I'm using that number to both determine when to start firing, and comparing it to the actual with the PID controller.

Edited May 18, 2017 by linuxgurugamer

[Pand5461]

43 minutes ago, linuxgurugamer said:

I would have expected the new formula to be about the same as the old one if drag was = 0 (as a test), but it isn't.  The new formulas causes crashes

It could be the distance formula, I'm using that number to both determine when to start firing, and comparing it to the actual with the PID controller.

Well that's strange. The only difference is that g in the old formula changed to g - F_d/(3*m) in the new one for time, and to g - F_d/(4*m) for distance.

The only possible reason of crashes may be unit inconsistency, especially with logarithm formula for distance. Other formulae should not cause crashes because the number under sqrt() is always positive as long as vspeed is directed down, and all the denominators are certainly non-zero.

g is in m/s², so valid combinations are:

F_d in kiloNewtons, m in tons, f in tons/s

F_d in Newtons, m in kilograms, f in kilograms/s.

So the only reason for crash is if mass was in tons and consumption in kg/s that caused negative number under logarithm.

EDIT: And, of course, drag must be in the same units as thrust, so either both in Newtons of both in kiloNewtons.

Edited May 18, 2017 by Pand5461

[linuxgurugamer]

Oh, you changed things.

first formula used Adry, 2nd used T

Should the two of them be somewhat close?  They are way different

I did find one mistake, on the first one I had adjusted the Adry to 95%, forgot to do that to T

 

So, right now my issues are with the t_s calculation.  Here are the formulas, with the C# code implementing them:

First one (which work, mostly):

t_s = (g - a_dry + sqrt( (g - a_dry)² - 2*V*a_dry²/(Isp*g₀) ) ) * (Isp*g₀)/a_dry²

C# code:  Ts = (g - Adry + Math.Sqrt(Math.Pow(g - Adry, 2) - 2 * V * Adry * Adry / (realIsp * g0))) * (realIsp * g0) / (Adry * Adry);

2nd one with problems:

 t_s = (g - (T + F_d/3) / m + sqrt{ [g - (T + F_d/3) / m]² - 2*V*(T/m)²/(Isp*g₀) } ) * (Isp*g₀)/(T/m)²

C# code: Ts = (g - (T + Fd / 3) / m + Math.Sqrt(Math.Pow(g - (T + Fd / 3) / m, 2) - 2 * V * Math.Pow(T / m, 2) / (realIsp * g0))) * (realIsp*g0) / Math.Pow(T / m, 2);

 

For a test I did:

T = a_dry
F_d = 0

Values from KSP are:

a_dry = 14.87
Isp = 300
g = 9.8
m = 20.657
 

Given these values, I would expect the two formula to be close, but nope.

Maybe it's F_d which is wrong.  I thought that this was Drag, which, at 29 velocity, is close to 0, so I set it to 0 for this test.  But maybe you are referring to something else?  Because when it is 0, then there is nothing subtracted from g.  The numbers I'm getting out are:

good t_s: -5.74832571919834 

Bad t_s: 100544.838732141

This is the part which I'm puzzled about:

(g - (T + F_d/3) / m 

If drag is 0, then you are essentially dividing the T by m, which is now throwing everything off

And that was the problem.  I multipled T by M, and got the results I expected.

Edited May 18, 2017 by linuxgurugamer

[Pand5461]

@linuxgurugamer, there is the issue in programming physical problems - programming language isn't giving a warning when you add m/s² to kilonewtons.

Now tried to calculate the distance with your settings (mass, thrust, Isp) with and without drag.

AeroGUI gives Cd*S ~ 9 m² for the heavy lander, and I used Cd*S*atm_dens*V²/2 for drag, air_dens being the air density which is 0.001 ton/m3 at Kerbin SL, I believe.

The drag correction to the distance grow up fairly quickly:

~0.7 m at -30 m/s

~10 m at -60 m/s

~70 m at -100 m/s

~100 m at -110 m/s

No wonder the initial formula made the ship stop so high above the ground.

The cubic and log formulas give increasingly different predictions as well, but their difference is within 10m up to the terminal velocity.

[linuxgurugamer]

I realized that a few minutes ago, and am now working to use the AeroGUI calculations so I don't have to redo it.

Thanks, will update this evening when I get back home.

 

6 minutes ago, Pand5461 said:

The cubic and log formulas give increasingly different predictions as well, but their difference is within 10m up to the terminal v

Which is fine for this mod.

Thanks

[linuxgurugamer]

11 hours ago, linuxgurugamer said:

I hope it is possible to get drag value from the API because it's available in-game in Aero GUI

Wasn't easy to do, it doesn't do those calculations unless it is displayed, I had to play a game with it to get it to calculate

11 hours ago, linuxgurugamer said:

Also, this expression for the burn distance may give better results:

h_s = (Isp*g₀)*(m - f*t_s) / f * ln[ m / (m - f*t_s) ] - (V + Isp*g₀)*t_s + ( g - F_d/(4*m) )*t_s²/2

Trying this calculation is next.  On a single test with the corrections, it landed, but just a little long (ie:  target altitude was 2m agl, it impacted at about 4m/s on the ground, so it was a bit off.

 

[linuxgurugamer]

2 hours ago, Pand5461 said:

@linuxgurugamer, there is the issue in programming physical problems - programming language isn't giving a warning when you add m/s² to kilonewtons.

Now tried to calculate the distance with your settings (mass, thrust, Isp) with and without drag.

AeroGUI gives Cd*S ~ 9 m² for the heavy lander, and I used Cd*S*atm_dens*V²/2 for drag, air_dens being the air density which is 0.001 ton/m3 at Kerbin SL, I believe.

The drag correction to the distance grow up fairly quickly:

~0.7 m at -30 m/s

~10 m at -60 m/s

~70 m at -100 m/s

~100 m at -110 m/s

No wonder the initial formula made the ship stop so high above the ground.

The cubic and log formulas give increasingly different predictions as well, but their difference is within 10m up to the terminal velocity.

Part of my issue is a lack of time, and very incomplete documentation on what the internals from KSP are, so it makes sense that I was mixing the units.

 

[linuxgurugamer]

12 hours ago, captinjoehenry said:

If you can set it up like mechjeb where you need the part but it is a toolbar button that would be ideal!

It can be done either way, right now I just have minimum requirements (ie:  pilot level or autopilot level)