Kobymaru

Suicide Burn Code

66 posts in this topic

1 hour ago, Kobymaru said:

Very interested! Where can I find it?

The model is here. Please note I'm still testing, debugging and improving it, can't yet tell it works correctly everytime. The math in the model works, but I have yet to consider all possible situations and apply the correct implementation for the case (e.g. have yet to change the way one of the procedures to determine the orbital change works, for the case of an initial hyperbolic orbit and angle η < 0° (the angle between main axes of the initial and following orbits), though I rely on another more compact procedure in such cases). Please note, the model provided is alike a demonstrator of feasibility, of course repetitive equations fill some of the sheets. I'm already at work coding the equations in C#, though it may take time for me to complete an add-on based on the model.

Should there be interest, I would consider a cooperation to port the model to a proper add-on, of course will then provide plenty of details about all this math stuff. Would be nicer to have this model extend the features with an already existing add-on rather than having to create a new one just for it (what I started doing in the meantime). That's also the reason I didn't want to talk about this project before having something working and now for keeping the model under a limited license, it will be reconsidered to adapt with the add-on(s) going to implement it.

 

Share this post


Link to post
Share on other sites
22 minutes ago, diomedea said:

Should there be interest, I would consider a cooperation to port the model to a proper add-on, of course will then provide plenty of details about all this math stuff.

Well my idea was to integrate it into KerbalEngineer because that provides a nice Framework and already takes care of some of the calculations. Since I don't know your math, I don't know how well the fit would be. Also, I don't know if it's ever gonna get merged, so we might have to consider writing an own plugin for that.

Also, I believe @linuxgurugamer might be interested because he's writing an autopilot for suicide burns and has been having trouble with the math.

Unfortunately, I can't promise to have a whole lot of time for coding in the near future :/

 

Share this post


Link to post
Share on other sites
2 minutes ago, Kobymaru said:

Well my idea was to integrate it into KerbalEngineer because that provides a nice Framework and already takes care of some of the calculations. Since I don't know your math, I don't know how well the fit would be. Also, I don't know if it's ever gonna get merged, so we might have to consider writing an own plugin for that.

Also, I believe @linuxgurugamer might be interested because he's writing an autopilot for suicide burns and has been having trouble with the math.

Unfortunately, I can't promise to have a whole lot of time for coding in the near future :/

 

I've been getting some good help regarding the math, and am in the process now of fine tuning.

I still need to go through and optimize, there are a lot of unnecessary calculations going on for debugging purposes.

But, pop over to my thread here:  

A user, @Pand5461 has been very helpful with the math

Share this post


Link to post
Share on other sites
2 minutes ago, Kobymaru said:

Well my idea was to integrate it into KerbalEngineer because that provides a nice Framework and already takes care of some of the calculations. Since I don't know your math, I don't know how well the fit would be. Also, I don't know if it's ever gonna get merged, so we might have to consider writing an own plugin for that.

Also, I believe @linuxgurugamer might be interested because he's writing an autopilot for suicide burns and has been having trouble with the math.

Unfortunately, I can't promise to have a whole lot of time for coding in the near future :/

 

Indeed KER is one of the add-ons I consider about finding how to properly manage some of the side problems (e.g. about determining the maxThrust and DV available with the current stage) for the porting (not with the model itself, those quantities can just be user inputs for the model). But KER isn't an autopilot and many users wouldn't want it to become one. Trajectories certainly would fit the purpose better, same for the new add-on LGG is making (though it seems aimed for atmospheric bodies, therefore exactly what my model won't help with), or even MechJeb.

Share this post


Link to post
Share on other sites

@diomedea,

Looking at your model...

Are you integrating all the way down to a stop, and doing that in a few iterations until it converges to a suicide burn?

That's the most accurate solution possible, I think. Although I hoped you've managed to derive/find a simpler method...

Share this post


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

@diomedea,

Looking at your model...

Are you integrating all the way down to a stop, and doing that in a few iterations until it converges to a suicide burn?

That's the most accurate solution possible, I think. Although I hoped you've managed to derive/find a simpler method...

Yes, I use integration. I tried other solutions, to derive an analytical equation. Under specific circumstances it was possible (any straight trajectory bringing to the landing site could be, in particular a vertical descent, as the math you showed proves) but couldn't find an equation valid in general with curved trajectories. Therefore am using an integration (or, simulating the powered descent under strict gravity turn) handling change in pitch, mass of the vessel, gravity, curvature of the body surface, surface speed at the given latitude, to integrate speed and position of the vessel. The "stop" occurs when the vessel is at its minimum speed, there the integration provides the final altitude (plus horizontal distance moved, DV expended, final pitch and mass of the vessel). The final altitude difference in relation to the ground altitude is then used to correct the initial (entry) altitude and the procedure is repeated until the final altitude matches the ground. Plus a selectable height (have still to create a routine to define such final height based on the vessel size) to allow a final attitude correction once the vessel is practically hovering the site: the suicide burn starting from a horizontal velocity vector, in particular with very high TWR, ends with a final pitch very far from vertical. I've examined a few programs used or proposed for landing guidance with real space agencies, all use the integration method both to predict the maneuver and to control its correct execution. Though CPU intensive, each suicide burn simulation should be doable within 2-3 frames from my estimates (which would be unacceptable if conducted within the same thread KSP runs, but I'm coding that to occur in a separate thread).

Share this post


Link to post
Share on other sites

@diomedea,

from my experience, RK4 integrator of powered ascent in atmosphere (tried to optimize launch profile, hehe) gave almost identical result with 1s timestep as with 0.01s timestep. The only trouble with longer timesteps was to handle engine cutoff. So, maybe you may have a coarse-timestep integration until v-speed changes sign, then redo final step with a finer timestep to get touchdown more accurately? RK4 requires 4 force evaluations per timestep but 1 second is 50 times longer than 0.02 s, so the net gain in speed is immense.

Some cases in which your approach isn't going to work:

1) If there's a mountain or crater rim on the descent trajectory between ship and landing site. Can be dealt with by calculating geocoordinates every integration step and checking trajectory height vs ground elevation at those coordinates. This will make some points inaccessible for suicide-burn landing, but that's physically correct.

2) With h-speed = 0, given enough delta-V, you either have the time to stop by suicide burn or no chance to land softly no matter what you do. With some h-speed, there are two cases of missed suicide burn opportunity: a) not enough time to bleed off v-speed even burning directly upwards; b) not enough time to bleed off h-speed by touchdown. In the former case, vessel is still doomed. The latter case, however, doesn't mean there's absolutely no way of soft landing in this vessel, you just need to burn a bit upwards from retrograde to buy more descent time. At this point, I'm not sure what is cheaper in terms of dV - burning with offset from retrograde or raising orbit to a safe altitude prior to burn.

Share this post


Link to post
Share on other sites

@Pand5461: interestingly, I also went with a project to optimize launch profile before this one (optimal gravity turn ascent). Can agree timestep isn't critical doing an ascent profile, allowing to solve in less cycles still with an acceptable accuracy. I preferred the "simulation" approach for the powered descent (timestep should actually be set identical to frame interval in KSP) to make no compromise on accuracy: unlike with an ascent, integrating precisely the position of the vessel is very important to land exactly where planned. The final resulting horizontal distance moved during the simulation is fed backwards to modify the argument of periapsis (and thence the earlier maneuvers planned to meet the periapsis at the correct time).

Have to say, duration of the simulation isn't a constraint for the purposes of my model. Unlike what LGG is coding (with your help), that requires to reevaluate the descent in real time to modify thrust, my model solves the landing with a true suicide burn: throttle is at a fixed level (currently 100%, could become a setting later) until speed is totally depleted. The accuracy of the simulation totally depends on the correct knowledge of the ground altitude ASL at the landing site (which KSP provides, or a previous landing in the same spot would allow a player to know); a vessel using the computed approach would then stop at the final altitude with the last simulation (bar navigation errors or floating point inaccuracies during execution). That all allows to completely compute the maneuver long before its execution and not having to do in real time. What I have planned for the execution part (and is shaping in code) is instead to check every 1 second the difference of actual positional and speed data of the vessel against data recorded with the last simulation. This is similar to an approach I found applied with a landing guidance program from NASA: using "gates" to check how the maneuver proceeds. Still have to consider how the autopilot will then apply corrections to bring the lander back within the planned descent path (but errors should be low enough to be correctable by RCS). Not having to do in real time, have no constraints about how long it takes to compute a simulation, and that's why the model goes to repeat it (each time correcting initial altitude by the error found in the previous) until final error is within bounds. Most often testing the model, found it takes no more then 3 passes with the simulation alone to achieve an error lower < 0.5 meters, but having the model recompute periapsis speed after each pass (due to periapsis altitude being changed) requires 4-5 passes.

I know about the limitations with my approach, but thanks for examining them:

1) The starting altitude with the suicide burn (that is the periapsis with the approach orbit) is very low, in particular when TWR is high. In practice, is best to land on highlands and to check the approach orbit doesn't cross mountain ranges; also, if landing in a crater, always better to do at a location on the far side from the direction of approach. Indeed that's all physically correct, but a refined version of the add-on could have to perform a check about the feasibility of the plan against features standing in the way, in particular when the trajectory is lowest. Can see three different approaches to be used to modify the plan: a) raise apoapsis with the approach orbit (works better the more orbits to be travelled before the landing site comes aligned, keeping the same total time by increasing orbital period while reducing number of orbits); 2) lower TWR (e.g. by changing maxThrottle applied during the suicide burn), that results in a steeper final trajectory starting at a higher altitude; 3) instead of performing a continuous gravity turn, split the suicide burn in a early half meant to deplete most of horizontal speed but not vertical speed in the same proportion, ending in a pitch a lot higher; and a second half (now gravity turn) that starts with a velocity vector now pitched enough to be free of ground features.

2) The simulation actually takes care of allowing exactly the time required to come to a stop at the desired final altitude. Wouldn't be a suicide burn otherwise! Besides, when constraining vessel to a retrograde attitude at all times during the burn, it follows a gravity turn (reversed), which means the horizontal and vertical components of speed change by the ratio of horizontal and vertical accelerations which are kept (apart for gravity) in the same ratio as speeds because of that retrograde attitude. The result is, always, that both horizontal and vertical components of speed are depleted in the same time (apart computing inaccuracies) by using the retrograde attitude (and, as the trajectory tangent is the ratio of those speeds, its rate of change (derivative) is = (gravity+ thrust/mass*sin(pitch))/(thrust/mass*cos(pitch)). The case of horizontal sliding occurs when time to deplete vertical speed is lower then time to deplete H speed (as done when landing an aircraft on a runway); the reverse occurs for vertical landings, when all horizontal speed is depleted earlier than vertical.

 

 

Share this post


Link to post
Share on other sites

@diomedea, I love your reasoning :)

Still, I insist that I'm correct on the second issue.

It is true that v-speed and h-speed come to exact zero at the same moment, yet, usually final part of the descent can safely be assumed just vertical without any hspeed.

Yet, given low starting altitude and very high h-speed (what exactly "low" and "high" mean here depends on TWR and engine efficiency, of course), you may be unable to do a proper suicide burn despite having enough TWR to slowly kill h-speed while hovering. Imagine going at near-orbital speed just above the ground to get the idea.

There is also a third situation I encountered trying to land a ship which had 1.3 m/s2 max acceleration in Mun orbit. In a suicide burn, it killed most of h-speed before reaching TWR = 1, and without centrifugal force it couldn't stop from falling. However, landing still was possible (you can watch here, starting mass 3 tons and landing on 2 linear RCS motors, 2 kN each).

Share this post


Link to post
Share on other sites

@Pand5461. I know my model appears counterintuitive because we are so used to land vertically. In fact, KSP tutorials covering landing (e.g. To the Mun part2) all have excess altitude, and that's how we generally plan our own landings too. Any excess altitude means the vessel could stop completely mid-air, and then the gravity alone has to be countered, resulting in a vertical landing (as written, time to deplete H speed is shorter than time to deplete V speed in this case).

Gravity turn suicide burns are different, horizontal speed is depleted together with vertical speed. Though curved, the trajectory never reaches a pitch = 90° (vertical); the larger the TWR, the less the pitch at landing. The only way to get a final vertical landing is to deplete H speed before landing on purpose, meaning the trajectory is no more a gravity turn.

My model really goes to find the perfect altitude for the suicide burn, the one that will take the least time to come to a landing (therefore less gravity effects and less DV spent to fight gravity losses). Meaning, both H speed and V speed come to zero at the same time, and that time is when the vessel touches ground (or almost, if we add some altitude for safety margin or correcting attitude). Exactly what you wrote may be impossible to achieve, is the object of the simulation with the suicide burn: to find that perfect starting altitude at which, keeping the vessel in a gravity turn at all times while burning with full throttle, the moment its speed (relative to the surface) comes to zero has the vessel at exactly the ground altitude (plus safety margin). Which always finds a solution for TWR > 1 (and enough DV); but the solution could be unfeasible with atmospheric bodies (e.g., my model computes for landing at KSC, for a trajectory at an Apoapsis altitude = 70 Km, a starting altitude for the suicide burn (at Periapsis) = 4634.5 meters, resulting in a speed = 2486.68 m/s and a dynamic air pressure (at 0°C) = 1.886 Mega pascal !! meaning it would require a drag coefficient unrealistically close to zero to avoid all that pressure to slow the vessel and convert its kinetic energy in heat).

Interesting situation when the starting TWR is < 1, thanks for sharing. Yes, provided TWR increases beyond 1 before the fall makes increasing gravity (therefore reducing TWR), a landing has to be possible.  But it would require engines with very low Isp (therefore burning more fuel) to reduce vessel mass at a rate greater than the raise with gravity due to falling. This doesn't generally happen with any gravity turn, not even with the (relatively inefficient) RCS thrusters: indeed my model couldn't but show TWR going further down instead of increasing with time. That video shows the vessel being pitched to keep it from falling (though it couldn't stop it still reduced vertical speed consistently) therefore TWR ended being large enough. Of course my model only considers gravity turns, so can't pitch that way, but it wouldn't be consistent with its purpose (that still is to achieve the most efficient landing) if it burned DV that way.

Share this post


Link to post
Share on other sites

@diomedea, so is your model going to handle the case in video? As I said, a suicide burn from that particular orbit wouldn't stop the lander before touching the ground, therefore the need to pitch up. But with high enough apoapsis, a proper suicide burn must be possible, it's just much easier to calculate the descent which just keeps constant horizontal acceleration and acceleration of descent speed until it kills all horizontal speed, and then just do good old vertical suicide burn.

Share this post


Link to post
Share on other sites

@Pand5461, no, my model isn't meant to handle the case you showed. You're right, a suicide burn wouldn't stop the lander, not until TWR is > 1 at the very minimum. But the idea of doing a double burn to achieve landing (first burn to kill most of H speed, followed by a suicide burn to kill all speed remaining) works, could have to be implemented at least for increasing final pitch (so to not slam in ground features on the way), at the price of resulting less efficient.

Willing, I could easily modify the simulation to achieve the "constant horizontal deceleration" or "to kill all horizontal speed before doing with vertical speed". Wouldn't say is much easier to do that way: all I need is to change how pitch is updated, instead of going by the tangent of the trajectory (which  is, atan(Vspeed/Hspeed), it can be set fixed (until Hspeed gets lower than a set threshold) or proportional (e.g., = atan(k*Vspeed/Hspeed), where k is the proportional factor). The latter would actually be my choice, with a low value of k the trajectory would end very vertical but still ensure the correct burntime. As you may notice, the true gravity turn case (= atan(Vspeed/Hspeed)) is in reality the simplest to compute, but not by much.

Share this post


Link to post
Share on other sites
2 minutes ago, diomedea said:

Willing, I could easily modify the simulation to achieve the "constant horizontal deceleration" or "to kill all horizontal speed before doing with vertical speed". Wouldn't say is much easier to do that way

As you may notice, I did not only steer, but throttle as well, so the "vertical acceleration" d2h/dt2 was also constant, making trajectory prediction very simple. Doing the same for a constant thrust is an entirely different and, I agree, a more complex problem.

Share this post


Link to post
Share on other sites

Yes, did notice about throttling. If I may, that is a good example of a working autopilot able to perform landings; but when throttling we aren't any more in the case of "Suicide burns" (as this thread implies). Sure, a maneuver can be planned to first stop on the vertical of the designed landing site (kill all Hspeed relative to the surface) and then perform a suicide burn for just the vertical part. Works, but isn't as efficient as I would like: the time it takes for the vessel to fall in any suborbital trajectory (a vertical descent being an extreme suborbital trajectory at Pe = 0 (from bodycenter) and SMA = distance(vessel, bodycenter)/2)) before starting the suicide burn, is all time when gravity builds up extra V speed (all going in extra kinetic energy to be than depleted); therefore best if that time is reduced to zero, by having the altitude at which the suicide burn is started being the Apoapsis with our final descent, vertical or not).

Also, when a pure vertical landing (or, any straight trajectory landing) is the case, my preference still goes with computing the suicide burn altitude using Energy equations rather than speed.

Share this post


Link to post
Share on other sites
34 minutes ago, diomedea said:

when throttling we aren't any more in the case of "Suicide burns"

Totally agree. The point was to show that many people think of suicide burn as the perfect solution. And it in many cases is, but in the example shown suicide burn is perfect and most efficient in every way except it won't actually land ship safely. The next point is that many people also think that if a suicide burn is not going to lead to a safe landing, then no landing algorithm is. And that is not true in general for any given initial conditions. Maybe the potential users should be told about that. Maybe curious ones are going to find this themselves, and not curious aren't worth the efforts of explanation.

Speaking about efficiency, I'd say every method solving the problem within the given constraints is equally efficient. And here comes one undeniable and really huge advantage of proper suicide burn vs my landing approach: portability. First, my script uses ad-hoc parameter found for a specific ship by trial-and error. Second, it requires throttlable engines. Third, it doesn't tell you how much deltaV the landing is going to take. To address these problems and make a mod which works with arbitrary craft, one needs to code a built-in integrator which eliminates the initial advantage of simplicity. Executing such landing with simple autopilot is not feasible either, while suicide burn is just pointing retrograde and running engines at full throttle, which can be accomplished with nothing but in-game autopilot functions.

That said, even if the mod doing non-vertical suicide burns at precisely 100% throttle comes to life, I am not going to use it. Such maneuver is just too highly unrealistic to my taste. IRL slight deviations in actual engine stats from nominal, fluctuations in fuel consumption, atmospheric conditions and probably myriads of other factors make throttling and steering essential for rocket-powered landings.

Share this post


Link to post
Share on other sites

Yes, lots of good points. To start with the suicide burn been considered as the perfect solution to every case (which really isn't). My own solution shows that: it won't be feasible to land in deep spots with other features around. Even more, though it should allow a perfect landing at a spot already visited, the maneuver may interfere with already existing structures at the site.

The efficiency I'm talking about is being able to perform the landing with the minimum possible DV. Mathematically, there is no doubt about that (one approach to demonstrate that is with the energy equations). The simulation itself isn't the most efficient method of computing, some RK integrators may be tested to find faster convergence; but the real breakthrough would come finding an analytical equation to the problem. Which seems to be where nobody could come with good enough suggestions, not even examining different sources. My own attempts at an analytical equation were met by overcomplicated results for even very simplified problems (e.g., this is the result for integrating pitch (φ) over time: φ(t)-φ(t0) = - ((2*M^2*g^2+2*T^2)*(t-t0) * arctan(M*g*(t-t0)/(T*(t-t0) - M*s)) + M^2*g*s*log((M^2*g^2+T^2)*(t-t0)^2 - 2*M*T*s*(t-t0)+M^2*s^2)+2*M*T*s*arctan(((M^2*g^2+T^2)*(t-t0) - T*M*s)/(M^2*g*s))) / (2*M^2*g^2 + 2*T^2); where g = gravity (simplified), T = thrust, M = vessel mass (simplified), s = initial H speed), therefore such approaches had to be discarded. But indeed, the simulation method is equally usable with any vessel, doesn't depend on an autopilot optimization given e.g. size or moment of inertia of the vessel or control authority.

All that said, I'm not pretending anybody have to use my method. IRL, landings are conducted with adequate safety margins; and IRL nobody does a suicide burn, this concept is more known to us in the KSP community than elsewhere. To tell the whole of it, before coming to this method, I started testing with another that would put the vessel on a suborbital trajectory (optimized to "impact" ground at the landing site) and the suicide burn done to stop the vessel just there just in time: no margins for error at all, if an engine didn't start at the correct time or could not reach 100% thrust, the vessel was doomed (method was discarded not because unsafe, but less efficient than my current one). This method has at least this failsafe (which is one of those used in reality too), if something goes wrong, the suicide burn can be aborted before execution. Then, in the first part of the suicide burn when still with a high Hspeed, if a problem develops, all required is just to turn to pitch up and raise speed to orbital again. During the whole descent, corrections will be made to keep the vessel within the programmed descent path. In the end, the safety margin is with programming a end altitude not at 0 AGL, but some meters up. Last, though would make for a fake of a suicide burn, safety may drive to program a maxThrottle < 100% with the simulation, so to always have some spare (costing more DV than needed, but safety is paramount); this maxThrottle setting is in my plans to make anyway.

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