Reverse-engineer a Hockey-Stick Burn and Live To Laugh About The Exploit

[Hotel26]

I'm excited because I just discovered I can get KER to display the distance to target (inside the cockpit)!

3 hours ago, Bill Phil said:

Mass and acceleration are always changing during a burn...

That, Phil, is why you need calculus.

KER will give you the mass and max. deceleration at start and end of the deceleration burn, which will be your starting point for integration (calculus).  Good luck with that and please let me know how you get on.

(I strongly recommend you fly an approach based on the approach described herein, pinpoint landings, to get a practical feel for the objectives.)

Edited April 1, 2018 by Hotel26

[Snark]

9 hours ago, Hotel26 said:

That, Phil, is why you need calculus.

Or a mod that just solves it numerically for you.  It's a hard math problem, but not such a hard programming problem.  Somewhat tedious, yes, but it's not rocket sci-- oh.  Um.  Well, okay, yes it is, but the point is, it can be programmed. 

For example, BetterBurnTime already takes changing mass into account when determining "how long do I have to burn to get X amount of dV?", and that doesn't require calculus at all-- it's basic algebra.  However, figuring out "when do I have to burn so that I reach zero velocity at ground level-- that's something BBT doesn't do, yet.  It's been in the back of my mind as a feature to add for a very long time now, but I've just never gotten around to it.

Partly that's because it'll be a bit of a chore... but also because I've found that in practice, it's not really all that necessary.  I've found that as long as I have two accurate numbers-- the time to impact (without using engines) and the time to burn (simplistic model, just take the burn time for an amount of dV equal to impact speed), then really all I need to do is just start the burn when the time-to-impact is about 60% of the time-to-burn, and it works just fine.

 

[Zeiss Ikon]

Yep.  This kind of thing (along with its general versatility -- give countdowns for leaving and reentering atmosphere, for braking burns when making rendezvous, as well as better burn timing for common maneuver nodes) is why BBT is my one and only mod and the one I'm most likely to say "won't play without it."  Fortunately, it doesn't seem to require an update every time KSP updates, probably because it's tied into pretty mature, long-tested code inside the game, so I don't have to wait for it to be updated when there's a new KSP to download.

I don't generally fly with sufficiently close fuel margins to care about doing perfect suicide burns, so I'm not holding my breath for a BBT upgrade to cover them, and for the same reason, I usually use 70% of burn time (rather than 60%) to start my landing burn.  I'd rather reach a dead stop at some altitude, and do a "much less suicidal" burn after free falling from there, than try to save a few dozen units of Lf/O.  At this point, my landers are direct-launch with drop tanks/legs.  This also makes landing easier; I can just keep retrograde hold on, or turn it back on after dropping a bit if SAS has automatically switched to "heading hold" when velocity got too low, and then (now that I have some level 2 pilots in my career) switch to "radial out surface" when I get close to ground.

[Hotel26]

5 hours ago, Snark said:

but also because I've found that in practice, it's not really all that necessary.

I will look for BBT,

Edited April 1, 2018 by Hotel26

[Hotel26]

I gave Better Burn Time a spin.  It's an excellent KSP extension and I can measure the love that has been poured into it.  I've played most of 3 years with only 4 mods and I am now going to welcome Better Burn Time into the stable.  So that's one very good thing to come out of this topic.

I guess I have to say that suicide burns are like dinosaurs and black holes: they fascinate people because they are perceived as being deadly.  My fault for mentioning 'suicide burns' to get a catchy title for this post that it has somewhat bogged down on the idea of arriving at the surface on full throttle.  (Perhaps "hockey-stick burn" would be better terminology to use.  Nevertheless, Snark did a great job summing up the connection here to suicide burns.)  Serves me right.

I guess what I am really fanatical about is "efficient spot landings".

On 2018/04/01 at 11:51 PM, Zeiss Ikon said:

I'd rather reach a dead stop at some altitude, and do a "much less suicidal" burn after free falling from there, than try to save a few dozen units of Lf/O. 

Yes, absolutely.  So the question remains, "how do you arrive in the cone above the target sufficiently close and low so as to negotiate a safe and very close landing?"  The suggestions in this thread, as I understand them have been, draw a maneuver node and then work from there.  I think that's fine, acceptable and even clever in the case of Snark's "maneuver-node trick".  As far as it goes.  Taken alone, it does not get you a precision landing.

Among commercial pilots, everyone of them has an instrument rating and they are proficient at flying IFR in all weather.  Among GA (General Aviation) pilots, the majority do not have instrument ratings.  Furthermore, as I understand the breakdown (as related by instructors), 90% of amateur pilots detest flying in bad weather and that is why they do not pursue an instrument rating.  You guessed it: the other 10% *love* flying in IMC (Instrument Meteorological Conditions) for the mental challenge and accomplishment.  I'm one of those.

On 2018/03/28 at 5:08 PM, Hotel26 said:

touch-down 10m from the target

"You set a pretty high bar.  "

 

Seeing what BBT can do and what it is intended for has been very useful for the evolution of my quest.

Today, I realized there is a KSP niche for an aid that assists you finding your way to the "Middle Marker" on the "ILS glide slope" for landing next to your target.  Seeing BBT has given me lots of ideas about what it could do, look like and how work.  It could handle non-equatorial surface intercepts quite transparently, too.

Maybe not many people are interested in my same objectives (I'd rather expend mental energy flying a precise approach rather than spend time, say, driving a fuel truck 150 meters).  Or perhaps they'd rather just let MechJeb fly the whole shebang for them.  But this aid could be simple enough in concept for many to use.

I appreciate all contributions that have been made thus far in this thread.  Thanks.

Edited April 4, 2018 by Hotel26

[Zeiss Ikon]

I'll admit, I don't have much of a history of precision landing.  In my science game (started in 1.2.2), I once brought a Mk. 1 Command Pod back to splash down within sight (even from sea level) of the Space Center.  Once.  Normally, even from an equatorial orbit, I can't reliably get within 100 km, never mind a few tens of meters.  In the same save, I have, once, landed on Minmus within 40 m of the flag left by the previous landing -- in the dark, with no lights on the lander (didn't expect to land in the dark), the faint glow of a throttled-down Terrier my only illumination.  Haven't even attempted it again, and it involved a long hover and using RCS to push the lander around.

That said, the only reason I've had to want a precision landing, to date, has been recovery funds in career -- and my career game is going well enough I'm not that worried about a few percent one way or another on the tiny fraction of each launch that I recover.  Recovery from LKO into the atmosphere is hard to control anyway -- a few hundred meters difference in apoapsis after the deorbit burn can make hundreds of km difference in how far you traverse after interface -- and coming back from the Mun or Minmus, there's invariably some uncontrolled inclination and I'd be doing well to predict which hemisphere I'm likely to land in.

If I had reason to want/need precision landings on airless bodies, I'd consider a mod for it -- but it would need to be lightweight (i.e. not bog down my processor -- even at 4 GHz, a single core can only do so much) and not require opening a bunch of boxes that cover half the screen.  BBT has this just right -- replacing an existing element of the GUI with a much more functional and versatile tool.

The Trajectory mod may already do much/most of what you're after; I'd certainly examine it before committing to trying to write one.  I can't say if it comes close to my preferences, since I've never installed it.

[Hotel26]

@Zeiss Ikon     totally agree with you.  All bets are off when there's an atmosphere -- it's a whole new ballgame.  My thought about that is that if you want a precision landing in the atmosphere then you should use wings to fly to your target. 

The use case is mining, which is a lot better to do, in my opinion, on a lo-grav, no-air body.  Then you will be doing lots of trips up and down to transport fuel/ore to a space station.  Same lander.  Same landing configuration.  Same surface target(s).  Many, many trips.  So it seems worth some effort.

I'll take a look at the Trajectory mod; thank you for the recommendation!

So here's an Insight:

De-orbiting and landing on the surface of an airless body can and ought to be thought of and performed as a Hohmann Transfer, comprised of two burns described very simply by three numbers, and then easily performed by a human pilot.

Furthermore, landing at, or in the very near vicinity of, a specific target point on the surface of that body, can be accomplished by this Hohmann Transfer and thought of as a rendez-vous procedure that puts the craft into proximity and with very similar velocity) i.e. low target-relative speed.  Landing from there is loosely, functionally equivalent/analogous to a docking procedure, although I will happily stick to the "landing" term since it's easily and universally understood.  [Bizarrely, you could think of a moon as being one huge dock (as far as you can see!), possessing an extensive and dangerously strong "magnetic" effect (i.e. gravity)]

The Implication of this is:

From a pilot's point of view, with KSP and no mods, no BBT, no MechJeb, no Trajectory mod...  from scratch...  what one imagines and desires from the above is: to select the target on the surface.  As I approach it, a maneuver node[*] appears with a time to node.  The maneuver node is my de-orbit burn (including any final inclination change I still need and including allowance for the movement of a non-equatorial target due to the rotation of the body).  After I execute the maneuver node, I am now heading down toward (where the) the target (will be).

At that point, a "time to burn SFC Retrograde" count-down comes up. [No maneuver node necessary as I simply turn to SFC Retrograde.]  At T=0, I burn full-throttle and enter the hockey-stick curve.  The de-orbit trajectory was computed with this hockey-stick deceleration in mind such that the combination not only sends me through the target's vertical Approach Cone but will bring me to a stop, or more preferably, to a velocity (speed and direction) that is entirely manageable (and configurable) by me to then transition to the landing phase.

Something like this could be done on a very simple interface (button "I intend to land and am ready to land") or even compatibly with the (no control interface) paradigm in Better Burn Time, in which it would intuit from: a) target selected, b) close approach/landing possible and c) no maneuver node already in effect (e.g. manual selection or MechJeb's Maneuver Planner), that the initial de-orbit procedure should be computed and displayed on offer.  If the user declines the offer by overshooting the maneuver node (by some margin), it is withdrawn.

Finally, maybe it's true most people don't care how far from the target they land.  But they do some work to land.  What I present above is probably LESS work than what they usually do and would put them on the glide slope to land such that they could not help but land very close to the target -- for FREE.

So, @Zeiss Ikon, since you are already a BBT user, if your next version of BBT included something similar to that described above (take this as entirely hypothetical because it's not my software, of course) -- would you use it?  And if you liked it, would you use it routinely?  Also, do you already have mining sites, e.g. on the Mun?  Do you arrive and depart, a) sometimes, b) regularly, c) frequently? 

 

* a maneuver node is only necessary if this landing aid is to present an inclination change incorporated within the de-orbit burn.  For equatorial targets, with inclination aligned, the whole Hohmann Transfer can be expressed as 3 informational numbers presented in sequence:

1. distance from target to commence a SFC Retrograde de-orbit burn
2. once initiated, the speed desired at completion of this de-orbit burn
3. once completed, the distance to target for the final SFC Retrograde hockey-stick deceleration burn

Example:  1) Start the de-orbit at 40km from target (or use a count-down).  2) reduce speed to 338m/s.  3) commence deceleration burn at 5.6 km from target (or use a count-down)

But the interface should be chosen to be one way or the other, as a design decision.

Edited April 5, 2018 by Hotel26

[Hotel26]

Simple enough also to handle inclination correction as a previous, initial step.

When a landing is possible, the aid displays target-relative inclination (+ Normal, - Anti-normal; probably in terms of "dV remaining").  When and if the pilot maneuvers to get this inclination close enough (within the cone) and the throttle is cut, the maneuver is complete.  The tolerance for this gets bigger as the target gets closer.  No maneuver node is necessary.  [This may be important because there is no precedent in KSP for maneuver nodes popping up unbidden.]

Then do the de-orbit.  Then the hockey-stick deceleration.  Then the landing.  Q.E.D. 

It's more efficient to do the inclination change earlier than the de-orbit burn anyway; as early as possible within 90 deg of the target.

Edited April 5, 2018 by Hotel26

[RizzoTheRat]

14 hours ago, Zeiss Ikon said:

I'll admit, I don't have much of a history of precision landing.  In my science game (started in 1.2.2), I once brought a Mk. 1 Command Pod back to splash down within sight (even from sea level) of the Space Center.  Once.  Normally, even from an equatorial orbit, I can't reliably get within 100 km, never mind a few tens of meters. 

I started using SSTO's in my last career game and by being careful where I place my de-orbiting node (200m/s retrograde from 80km orbit and set the impact point in line with the island East-North-East of KSC) and can drop them all within about 10km of the KSC, I always aim to land short though as they don't survive landing in the sea if they overshoot.

I'm now experimenting with kOS and using on repeat flights with an identical craft and ship they're currently landing (unpowered) over about a 1km area, with only some pretty basic use of the airbrake to shorten the range a bit. I'm current working on in flight steering to try and reduce that a bit more.  But if identical repeats are that spread out it's no wonder it's tricky to do manually.

kOS makes suicide burns easy though, just calculate the acceleration needed to counter the current velocity and the acceleration due to gravity, and switch the engine on when it approaches the max acceleration the craft can manage.   I'm not taking reduction in mass from burning fuel, or atmospheric drag in to account though so it's not a true suicide burn however it's pretty close as with airbrakes deployed and a high TWR the burn is pretty short.  I've found a the tighter you push it towards a true suicide burn though the more issue you have with turn rate, it's a hockey stick approach and the final change in angle is very sudden, meaning you can easily reverse the horizontal direction without killing enough vertical so you smack one side down and tip over. 

I'm still working on a script to get to the mun but once that's sorted I am pretty confident that in a vacuum I can get a ship to land on a bases docking ring, which I'm already able to do from a hover transition on Kerbin.

[i_like_kerbals]

why dont you take your delta v and figure out how many seconds prior it will take to dump before your elevation is 0 at current v... [snip]

[Zeiss Ikon]

14 hours ago, Hotel26 said:

So, @Zeiss Ikon, since you are already a BBT user, if your next version of BBT included something similar to that described above (take this as entirely hypothetical because it's not my software, of course) -- would you use it?  And if you liked it, would you use it routinely?  Also, do you already have mining sites, e.g. on the Mun?  Do you arrive and depart, a) sometimes, b) regularly, c) frequently? 

I haven't tested it, but I suspect BBT can already do approximately this, if your orbit already passes over your target and it's set as "target" in the game (which you can do with debris, or even flags).  Use a node for your deorbit burn (including a final plane change if needed to put the orbit directly over the target), just as when setting up a rendezvous.  What I'm not sure of is whether BBT will correct prioritize between "impact in xx seconds" and "target within 0.1 km in xx seconds" -- either way, you should get a usable countdown, and in either case you 'll get a burn time to zero velocity.  The difficulty is mainly that you won't get the intersect markers if your target isn't in orbit; I suspect this will cause BBT to do the "suicide burn" display rather than the "rendezvous burn".

[Hotel26]

On 2018/04/06 at 6:07 AM, Zeiss Ikon said:

Use a node for your deorbit burn

All right.  This turns out to be the weak link.  It's like using a slide rule to plan a mid-course correction for a gravity assist...

Setting up the node in Map View is difficult enough and will necessarily be different on every approach due to the inherent inaccuracy of gauging the trajectory.

Secondly, everything said above about not taking changing mass into account applies very heavily to maneuver nodes.

I wound up 2.0 km and then 1.5 km short.  I'm sure I could jockey this closer, but the routine pilot would end up taking my 3 numbers and simply honing them on every descent until it was repeatedly accurate, like a homing pigeon.

Thank you for all the suggestions!

 

 

Edited April 7, 2018 by Hotel26

[MR L A]

Has this thread been renamed or am I imagining things?

[pandaman]

38 minutes ago, MR L A said:

Has this thread been renamed or am I imagining things?

Yes, it has been renamed...

...But that doesn't mean you are not imagining other things. 

[Snark]

19 hours ago, Zeiss Ikon said:

I haven't tested it, but I suspect BBT can already do approximately this, if your orbit already passes over your target and it's set as "target" in the game (which you can do with debris, or even flags).  Use a node for your deorbit burn (including a final plane change if needed to put the orbit directly over the target), just as when setting up a rendezvous.  What I'm not sure of is whether BBT will correct prioritize between "impact in xx seconds" and "target within 0.1 km in xx seconds" -- either way, you should get a usable countdown, and in either case you 'll get a burn time to zero velocity.  The difficulty is mainly that you won't get the intersect markers if your target isn't in orbit; I suspect this will cause BBT to do the "suicide burn" display rather than the "rendezvous burn".

Sorry-- not a bad idea, but it doesn't work that way.

Details in spoiler.

Spoiler

First, the "target rendezvous" indicator in BBT explicitly checks to ensure that the target isn't landed, and is disabled if it is.  So you'll never see a target indicator in BBT for a landed target.  (That's because the rendezvous tracker bases all of its calculations on the orbit of the target.  A landed target isn't moving orbitally, so it would need an entirely separate body of code to be handled, and that code does not exist in BBT.)

Second, BBT has several built-in indicator types (maneuver node, target rendezvous, surface impact, atmosphere entry/exit).  Since there's only one UI spot to put the information (the navball's burn indicator), that means that only one of them at a time can be displayed-- otherwise, they'd be arm-wrestling over trying to show their info, and hilarity would ensue.  Therefore, when I coded it, I had to pick a "priority"-- i.e. if the ship's in a situation where multiple trackers want to be active, which one should win?  I had to pick something, so I did it by putting myself in the player's shoes (not hard, since I'm a player myself), and put the most important/vital information first.  It goes like this:

1. Maneuver burn
2. Impact
3. Target rendezvous
4. Atmosphere entry/exit.

Rationale for the above:  Maneuver node goes on top, because if a player has chosen to place a maneuver node, that's a pretty darn explicit statement of user intent, and the mod should respect that, so it takes priority over everything else.  Atmosphere entry/exit goes on the bottom, because it's just a convenient bit of information that's not really directly vital to anything.  Impact takes priority over target rendezvous, because missing the former will kill you but missing the latter is merely inconvenient.

...Which means that even if target rendezvous were shown for landed targets (which it isn't), it would get trumped by the impact tracker anyway.

So... nice idea, but I regret to inform you that it won't work. 

[Gordon Fecyk]

On ‎4‎/‎4‎/‎2018 at 4:23 AM, Hotel26 said:

Perhaps "hockey-stick burn" would be better terminology to use.

And just in time for the Stanley Cup Playoffs... Now you have my mind in the wrong place; Way to go, hoser. :-)

Go Jets! (and have a +1 on me.)

[Johnny Wishbone]

I know this is one of the most G-rated forums on the Internet, but seriously; its a “Hockey stick” burn now? 

[pandaman]

4 minutes ago, Johnny Wishbone said:

I know this is one of the most G-rated forums on the Internet, but seriously; its a “Hockey stick” burn now? 

 

I think that describes the shape of the optomum flight path much better though.

[Zeiss Ikon]

3 hours ago, Snark said:

Sorry-- not a bad idea, but it doesn't work that way.

Well, I did say I didn't expect to see both impact and rendezvous indicators -- but I completely agree with your priority list, too.  Not considering a landed object a target makes perfect sense, too.  I'm just brainstorming ways to 'abuse" BBT to do something it's not designed to do.

I probably get that at work; I repair power tools for a living, and I'm well known in my shop for fixing things with a hammer -- things you wouldn't expect to be fixed by whacking them with a lump of metal on a handle.  When you don't have the "special tool" the machine manufacturer recommends, and your boss won't buy it because it's hundreds of dollars and you might never need it again (or only need it once a year or so), you improvise.  It gets to be a habit.

[Snark]

9 minutes ago, Zeiss Ikon said:

Not considering a landed object a target makes perfect sense, too.

Oh, it's a perfectly reasonable thing to have-- it's just that it requires a considerably different body of code to process than going after an orbital target, and I just haven't instrumented BBT to do that.  (It's not simply a coding problem-- it's also a user-interaction-design problem, because there would be the need to juggle "target" with "impact".)

[Hotel26]

5 hours ago, Johnny Wishbone said:

I know this is one of the most G-rated forums on the Internet, but seriously; its a “Hockey stick” burn now? 

"I went to a championship fight night -- and a hockey game broke out"...  as the saying goes.    (Go Bruins!)

Seriously -- semi-seriously -- I'm lumping "suicide burn" in now with "Jurassic age" and black holes.  People are fascinated with (fixated on) them because they are perceived as so deadly.  But they are all so useless. 

Here's an example.  "Gee.  I wonder what it would be like to go see a black hole!?"  Well, I rather think there'd be so much hot radiation in orbit around one that you'd not get anywhere near it.

[Now there's going to be a long discussion about the 115K different ways a black hole will kill you.]

Edited April 7, 2018 by Hotel26

[Archgeek]

On 4/6/2018 at 8:24 PM, Hotel26 said:

"I went to a championship fight night -- and a hockey game broke out"...  as the saying goes.    (Go Bruins!)

Seriously -- semi-seriously -- I'm lumping "suicide burn" in now with "Jurassic age" and black holes.  People are fascinated with (fixated on) them because they are perceived as so deadly.  But they are all so useless. 

Here's an example.  "Gee.  I wonder what it would be like to go see a black hole!?"  Well, I rather think there'd be so much hot radiation in orbit around one that you'd not get anywhere near it.

[Now there's going to be a long discussion about the 115K different ways a black hole will kill you.]

I'm more interested in what we can make black holes do for us, like storing energy by forcing spin or charge into them, or building Dyson spheres around small ones and harvesting the Hawking radiation for purposes, feeding a steady stream of matter in to keep the output from getting too high as the hole gets smaller.

[Hotel26]

On 2018/04/12 at 6:03 AM, Archgeek said:

I'm more interested in what we can make black holes do for us, like storing energy

When you consider the age of the universe and that Homo sapiens has only been around for 300Ka tops...  and then that, as smart as we are(*), progress/population has shot forward only in the last couple of centuries, you have to figure that a plentiful supply of energy has been a key factor.  And as wise as it might be to try now to conserve energy and/or find other, existing sources of it...  well, I have to think that we need to find a new and copious source rather soon.  E.g. fusion energy within 50 years presents a kind of make/break point for us vis-a-vis continued progress.  We have a lot riding on this and a strong focus.

Edited April 14, 2018 by Hotel26