Pand5461

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.

When you're doing a mod which makes their life harder, probably so. If you're making a mod which helps them, they're going to massively abuse it and blame you for it not working in edge cases (I guess, not a modder myself).

Another question - what is a "first flight" for a specific part, exactly? Does it need to be activated, then recovered? If not, then player might just rollout a rocket, recover it and put back on launchpad for the second flight.

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.

So it isn't supposed to accidentally make mod parts that have no config files failure-prone as TF usually does? Also, it would be nice if part recovery contributed more to the reliability of next generation than just plain flight. And having tweaked stats for some parts may be useful to somewhat balance the stock game (I am talking about Vectors, of course). Actually, even some automated guessing is possible, like giving parts with high performance/size ratio (e.g. thrust/attachment size for engines, EC/mass for batteries, ECpersec/mass for solar panels) lower MTBF and higher wear rates.

@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.

Is it like what TestFlight mod is doing? I love this idea but find TF too complicated with its aim to RO, lots of failure types and need for configs. Does your mod also need configs for each part or it uses reasonable defaults for each type of part (solar panel, engine, parachute etc.)?

At least Science Lab and MPL both have "lab" in them, and Seismic Accelerometer is an official name. I think I was referring to the Convert-O-Trons that are conveniently named ISRU units in contracts (and have the word "ISRU" nowhere in name or description).

Exactly. Materials bay was the old name, I guess. There was some other part which had inconsistent names in contracts and in editor, but I can't remember now.

@SpaceEnthusiast23, there is no such thing as bi-elliptic transfer orbit, at least not in Kerlerian sense. Hohman transfer is a procedure to get from one circular orbit to another one. To do that, you burn at some point of the initial orbit to get to an elliptical orbit that has the opposite apsis at the target orbit height. This elliptical orbit is the Hohmann transfer orbit. But transfer is not completed yet. To complete the transfer, you need to circularize at the target altitude bu the second burn. Bielliptic transfer is also a procedure to get from one circular orbit to another one. But first burn sends the ship to a very eccentric elliptical orbit (let's say, with Ap at the border of SOI). From there, you change the periapsis height to the target altitude and then circularize at periapsis. Therefore, bielliptic transfer involves two transfer orbit, as one may guess from its name. The idea behind it is that with a really high apoapsis, big changes of periapsis may be achieved by very small burns. This all really comes into play when you need to change the inclination. Transfer from an equatorial to a polar orbit requires Vorbital×√2 deltaV, while at the apoapsis of a higly elliptical trajectory inclination change reduces to almost nothing. Therefore, it clearly becomes more efficient to get to high elliptical orbit, change inclination at apoapsis and circularize back at periapsis than to change inclination at constant altitude (please note that bielliptical inclination change is better for big changes, small ones <20° are more efficient at constant altitude). For better explanation, read the Wiki page, it has examples with concrete figures.

You have wrong phase angle, that is, the angle between directions to the maneuver node and to the Mun from the center of Kerbin. First, you need to make a prograde node, i.e. move only prograde gizmo. Add deltaV until the apoapsis after maneuver is the same as Mun height. Then just move node around the trajectory until projected orbit gets into Mun's SOI. Good luck.

@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).

@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.

@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...

@Kobymaru Got a new idea whilst writing in Lgg's topic: what if, instead of trying to guess a perfect retrograde burn, just estimate requirements for a "gamma-burn", i.e. first purely horizontal, after killing all h-speed purely vertical. It's less efficient than a perfect suicide burn, but we may call it a built-in safety margin. Won't really work in thick atmospheres, but flies rockets sideways there anyway?

@Alshain, NavBall shows the heading as a number at the bottom (next to HDG letters), so it's entirely possible to keep that heading within 1 degree accuracy. But anyways, great tutorial, I can only explain such things with quite a bit of not-so-highschool maths.

@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.

Hitting a particular area from orbit is quite tricky, and even more so with unpowered landing and barely any control surface. I'd suggest building proper planes for "below something" and surface contracts and suborbital hops for "above something" contracts in the early career.

How exactly did you get your LAN while on launchpad? If via KER, then at launchpad it shows LAN 90 degrees from where you actually are. This is technically correct, but due to vanishingly low inclination of the "orbit" you move the LAN very quickly as you start thrusting nort- or southward. What you really need to know is where your AN would be if get a kick to orbital speed at 20 degree offset from equator. And this is conveniently more or less right where you are now. So, joining to the collective advice here - switch to map view and wait Kerbin rotates you right under the target orbit.

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.

Probably, yes, a heavy engine gave it too much weight to decelerate in time. You should've burned that dv somewhere around 20km and relieve poor kerbonaut of that burden ASAP.

Well, rotation and direction stuff is not "basic" for a total newbie. For example, which exact orientation will a rocket have after "lock steering to up."? Well, the nose will be pointing upwards, right? But then, assuming the rocket has a Mk1 capsule, which way is the hatch pointed? Another example. If we can "lock steering to up" and "lock steering to retrograde + something", then can we "lock steering to up + something"? And "lock steering to up + retrograde"? And if we can do the latter, then where will the ship point its nose after that? It's very good you are willing to help people with basics in kOS. But the thing that you've written are not explaining anything to a newbie, I'm afraid. It's just a bunch of unrelated lines of code taken from out of nowhere. Just start slower. Begin with the simplest tasks, but give more details on them. At the very beginning, I as a newbie would expect the info where to enter kOS commands. Then simplest commands. E.g., let's start with throttle. Throttle is controlled by the "THROTTLE" variable, and changing this variable has the same effect as pressing Shift and Ctrl on the keyboard. The value is a floating-point number between 0 and 1. If we execute command "LOCK THROTTLE TO 0." then we see gauge on navball moved to the shutdown, at "LOCK THROTTLE TO 0.7." gauge moves back up. "LOCK THROTTLE TO 1." is therefore has the same effect as pressing Z on the keyboard. But we have not started the engine yet. To start the engine, in normal game you press Spacebar. In kOS, this action is conveniently represented by the "STAGE" command. ... and so on and so forth ...

Maybe a combination of steep reentry, high ground at landing and high mass of reentry vehicle? From a 80km orbit, I have no problems landing a Mk1 capsule with periapsis at 20km. The capsule is light and heat-resistant, so it does not burn even without a heatshield and decelerates to terminal velocity well above the ground.

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

Well, signal seems to be blocked by the virtual sea-level surface, not visible terrain. So, given Mun radius is 200 km and typical elevation 2 km, ground stations can see each other from ~50 km apart, if you won't put them onto lowlands. Which means you need at least 25 stations to have a continuous coverage along equator. And power will be an issue since the stations on the night side are going to be in darkness for about 18 hours every Munar day/Kerbin Munth.