linuxgurugamer 5925 Posted May 17 (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 May 17 by linuxgurugamer Share this post Link to post Share on other sites

linuxgurugamer 5925 Posted May 17 (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) = K_{P}*( x(t) - x_{0}(t) ) + K_{D}* d( x(t) - x_{0}(t) )/dt, where x is the actual value of signal, x_{0} 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_{0}(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_{0} 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 by linuxgurugamer Share this post Link to post Share on other sites

linuxgurugamer 5925 Posted May 17 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

Kartoffelkuchen 879 Posted May 17 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

linuxgurugamer 5925 Posted May 17 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

Pand5461 116 Posted May 17 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? Share this post Link to post Share on other sites

linuxgurugamer 5925 Posted May 17 (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, 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} - 2*V*a_{dry}^{2}/(Isp*g_{0}) ) ) * (Isp*g_{0})/a_{dry}^{2} 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 by linuxgurugamer Share this post Link to post Share on other sites

Pand5461 116 Posted May 17 (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 May 17 by Pand5461 Share this post Link to post Share on other sites

linuxgurugamer 5925 Posted May 17 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

Pand5461 116 Posted May 17 Okay, correction for atmospheric planets: t_{s} = (g - (T + F_{d}/3) / m + sqrt{ [g - (T + F_{d}/3) / m]^{2} - 2*V*(T/m)^{2}/(Isp*g_{0}) } ) * (Isp*g_{0})/(T/m)^{2} 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_{0} = T/fuel_consumption = effective exhaust speed h_{s} = -V*t_{s} - [(T + F_{d}/4) / m - g]*t_{s}^{2}/2 - (T/m)^{2}/(Isp*g_{0})*t_{s}^{3} / 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_{0})*(m - f*t_{s}) / f * ln[ m / (m - f*t_{s}) ] - (V + Isp*g_{0})*t_{s} + ( g - F_{d}/(4*m) )*t_{s}^{2}/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

Kartoffelkuchen 879 Posted May 17 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} - 2*V*(T/m)^{2}/(Isp*g_{0}) } ) * (Isp*g_{0})/(T/m)^{2} 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_{0} = T/fuel_consumption = effective exhaust speed h_{s} = -V*t_{s} - [(T + F_{d}/4) / m - g]*t_{s}^{2}/2 - (T/m)^{2}/(Isp*g_{0})*t_{s}^{3} / 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_{0})*(m - f*t_{s}) / f * ln[ m / (m - f*t_{s}) ] - (V + Isp*g_{0})*t_{s} + ( g - F_{d}/(4*m) )*t_{s}^{2}/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

Pand5461 116 Posted May 17 @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

captinjoehenry 49 Posted May 17 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. Share this post Link to post Share on other sites

Vanamonde 6424 Posted May 17 Overlapping threads have been merged. Share this post Link to post Share on other sites

captinjoehenry 49 Posted May 17 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

linuxgurugamer 5925 Posted May 18 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} - 2*V*(T/m)^{2}/(Isp*g_{0}) } ) * (Isp*g_{0})/(T/m)^{2} 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_{0} = T/fuel_consumption = effective exhaust speed h_{s} = -V*t_{s} - [(T + F_{d}/4) / m - g]*t_{s}^{2}/2 - (T/m)^{2}/(Isp*g_{0})*t_{s}^{3} / 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_{0})*(m - f*t_{s}) / f * ln[ m / (m - f*t_{s}) ] - (V + Isp*g_{0})*t_{s} + ( g - F_{d}/(4*m) )*t_{s}^{2}/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

linuxgurugamer 5925 Posted May 18 (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 May 18 by linuxgurugamer Share this post Link to post Share on other sites

Pand5461 116 Posted May 18 (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 - 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^{2}, 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 by Pand5461 Share this post Link to post Share on other sites

linuxgurugamer 5925 Posted May 18 (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 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} - 2*V*a_{dry}^{2}/(Isp*g_{0}) ) ) * (Isp*g_{0})/a_{dry}^{2} 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} - 2*V*(T/m)^{2}/(Isp*g_{0}) } ) * (Isp*g_{0})/(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 = 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 by linuxgurugamer Share this post Link to post Share on other sites

Pand5461 116 Posted May 18 @linuxgurugamer, there is the issue in programming physical problems - programming language isn't giving a warning when you add m/s^{2} to kilonewtons. Now tried to calculate the distance with your settings (mass, thrust, Isp) with and without drag. AeroGUI gives Cd*S ~ 9 m^{2} for the heavy lander, and I used Cd*S*atm_dens*V^{2}/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

linuxgurugamer 5925 Posted May 18 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

linuxgurugamer 5925 Posted May 18 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_{0})*(m - f*t_{s}) / f * ln[ m / (m - f*t_{s}) ] - (V + Isp*g_{0})*t_{s} + ( g - F_{d}/(4*m) )*t_{s}^{2}/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

linuxgurugamer 5925 Posted May 18 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^{2} to kilonewtons. Now tried to calculate the distance with your settings (mass, thrust, Isp) with and without drag. AeroGUI gives Cd*S ~ 9 m^{2} for the heavy lander, and I used Cd*S*atm_dens*V^{2}/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

linuxgurugamer 5925 Posted May 19 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