linuxgurugamer

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

Recommended Posts

Posted (edited)

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 by linuxgurugamer

Share this post


Link to post
Share on other sites
Posted (edited)
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) = KP*( x(t) - x0(t) ) + KD* d( x(t) - x0(t) )/dt,

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

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

PD(x) = KP*Δ(tnow) + KD* (Δ(tnow) - Δ(tprev) ) / ( tnow - tprev),

where Δ(t) is short for ( x(t) - x0(t) ), tnow is current time, tprev is the time of previous calculation of Δ(t).

So, in the above case X is height, X0 is calculated hs, and KP and KD 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 Kp and Kd are constants which are used to tune this?

Edit:  from the Wikipedia:

KP = 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.

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

Edited by linuxgurugamer

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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.. :)

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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, adry 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?

 

Share this post


Link to post
Share on other sites
Posted (edited)
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, adry 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:  ts = (g - adry + sqrt( (g - adry)2 - 2*V*adry2/(Isp*g0) ) ) * (Isp*g0)/adry2

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 by linuxgurugamer

Share this post


Link to post
Share on other sites
Posted (edited)

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 by Pand5461

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

Okay, correction for atmospheric planets:

 ts = (g - (T + Fd/3) / m + sqrt{ [g - (T + Fd/3) / m]2 - 2*V*(T/m)2/(Isp*g0) } ) * (Isp*g0)/(T/m)2

where T is total thrust (projection onto vertical axis), m is vessel mass, Fd 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*g0 = T/fuel_consumption = effective exhaust speed

hs = -V*ts - [(T + Fd/4) / m - g]*ts2/2 - (T/m)2/(Isp*g0)*ts3 / 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:

hs = (Isp*g0)*(m - f*ts) / f * ln[ m / (m - f*ts) ] - (V + Isp*g0)*ts + ( g - Fd/(4*m) )*ts2/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.

Share this post


Link to post
Share on other sites
50 minutes ago, Pand5461 said:

Okay, correction for atmospheric planets:

 ts = (g - (T + Fd/3) / m + sqrt{ [g - (T + Fd/3) / m]2 - 2*V*(T/m)2/(Isp*g0) } ) * (Isp*g0)/(T/m)2

where T is total thrust (projection onto vertical axis), m is vessel mass, Fd 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*g0 = T/fuel_consumption = effective exhaust speed

hs = -V*ts - [(T + Fd/4) / m - g]*ts2/2 - (T/m)2/(Isp*g0)*ts3 / 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:

hs = (Isp*g0)*(m - f*ts) / f * ln[ m / (m - f*ts) ] - (V + Isp*g0)*ts + ( g - Fd/(4*m) )*ts2/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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

sN7bJDc.png

Share this post


Link to post
Share on other sites

Overlapping threads have been merged. 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
6 hours ago, Pand5461 said:

Okay, correction for atmospheric planets:

 ts = (g - (T + Fd/3) / m + sqrt{ [g - (T + Fd/3) / m]2 - 2*V*(T/m)2/(Isp*g0) } ) * (Isp*g0)/(T/m)2

where T is total thrust (projection onto vertical axis), m is vessel mass, Fd 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*g0 = T/fuel_consumption = effective exhaust speed

hs = -V*ts - [(T + Fd/4) / m - g]*ts2/2 - (T/m)2/(Isp*g0)*ts3 / 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:

hs = (Isp*g0)*(m - f*ts) / f * ln[ m / (m - f*ts) ] - (V + Isp*g0)*ts + ( g - Fd/(4*m) )*ts2/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?

Share this post


Link to post
Share on other sites
Posted (edited)

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 by linuxgurugamer

Share this post


Link to post
Share on other sites
Posted (edited)
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 - Fd/(3*m) in the new one for time, and to g - Fd/(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/s2, so valid combinations are:

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

Fd 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 by Pand5461

Share this post


Link to post
Share on other sites
Posted (edited)

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 ts calculation.  Here are the formulas, with the C# code implementing them:

First one (which work, mostly):

ts = (g - adry + sqrt( (g - adry)2 - 2*V*adry2/(Isp*g0) ) ) * (Isp*g0)/adry2

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:

 ts = (g - (T + Fd/3) / m + sqrt{ [g - (T + Fd/3) / m]2 - 2*V*(T/m)2/(Isp*g0) } ) * (Isp*g0)/(T/m)2

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 = adry
Fd = 0

Values from KSP are:

adry = 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 Fd 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 ts: -5.74832571919834 

Bad ts: 100544.838732141

This is the part which I'm puzzled about:

(g - (T + Fd/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 by linuxgurugamer

Share this post


Link to post
Share on other sites

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

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

AeroGUI gives Cd*S ~ 9 m2 for the heavy lander, and I used Cd*S*atm_dens*V2/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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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:

hs = (Isp*g0)*(m - f*ts) / f * ln[ m / (m - f*ts) ] - (V + Isp*g0)*ts + ( g - Fd/(4*m) )*ts2/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.

 

Share this post


Link to post
Share on other sites
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/s2 to kilonewtons.

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

AeroGUI gives Cd*S ~ 9 m2 for the heavy lander, and I used Cd*S*atm_dens*V2/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.

 

Share this post


Link to post
Share on other sites
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)

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now