landvac not working

[hany]

Hi there,

Been using your library for a few days and I find it one of the most complete set of scripts out there! However, I’m having problems getting landvac.ks to work. When attempting to (using any method), my ships get to the stage of the final descent, however, my ships seem to be oriented horizontally (or close to), and therefore the suicide burn is not oriented correctly and my ships crash land (again, horizontally). I’ve mostly attempted this around Minmus. I can’t for the life of me figure out what I’m doing wrong.

Any help would be appreciated.

[astappiev]

Hi, can you provide a savegame (before landing)?

[hany]

Certainly can. See attached! savegame.zip

[hany]

OK, after many many repeated crashes, it appears to be this line here:

https://github.com/xeger/kos-ramp/blob/b25f112c550a89c96cafce1236664b935bc79229/ramp/landvac.ks#L165

The only way to land safely on Minmus is to set this to 0. Tried with values as low as 0.01 and still would land (mostly) horizontally with very high horizontal speed.

Not sure where the original value of 0.08 came from? Is this calculated?

[astappiev]

Not sure where the original value of 0.08 came from? Is this calculated?

I have no idea. I'm just a user like you.

Tried to dig into the problem, but faced with another error where I spent a few hours with no results :/ Don't you get an error "Tried to push NaN into the stack"?

When you set the value of DFactor = 0 you ignore the landing point and instead just land whenever. I will continue tomorrow.

[hany]

I’m running into the exact same issue! It works 50% of the time. I have a save point right before I run landvac, and the results vary widely.

Anyways, regarding this issue, I believe I found the problem. Setting a low DFactor (usually 0), works as mentioned, but like the comment mentions a low value results in horribly inaccurate landing coordinates. The real problem comes further up in the script here:

https://github.com/xeger/kos-ramp/blob/master/ramp/landvac.ks#L88

It appears the calculation is not taking into account the terrainheight for the “default” max of (5000+ ship:body:radius). For a location on Minmus where the terrain is ~2.5km up, the second argument (2% above radius) wins and the radar altitude before the final descent is ~1.5km, which is not enough time to make adjustments and end up crashing sideways.

I believe the intention of that line is to say the absolute minimum altitude for the final descent should start at 5km up. In this case, I believe the line should read:

    local DeorbitRad to max(5000 + (ship:body:radius + LandingSite:terrainheight), (ship:body:radius * 1.02 + LandingSite:terrainheight)).

The LandingSite:terrainheight should be accounted for in all cases. I’m able to get way fewer crashes with this, and often end up landing within 10m of the location. It’s not perfect however. Sometimes the location of the periapsis is way too far off and I still end up sideways.

[astappiev]

Yes, that makes sense.

Also a few more changes:

1. Replace landRadarAltimeter() with abs(ship:bounds:bottomaltradar) it changes the length between land and ship used to calculate throttle, instead of using the center of the ship using bottom-most part.
2. Change TouchdownSpeed to 1 or 0. Should lower speed on touchdown.

Further possible improvements:

1. The pidloop values can be adjusted. When I point a ship on crash speed to ground, the maximum value I of throttle I have seen is ~0.5, but I expect to use 1 (full throttle) in the case. This is somehow controlled by values in constructor of pidloop, I don't have time to read about them.
2. This is not really most efficient was to land max(TouchdownSpeed, sqrt(abs(ship:bounds:bottomaltradar))). In the ideal case, we should calculate the values based on the available max throttle, speed and height of the ship to perform brake burn only right before the ground (like Falcon 9 landing).

[nuggreat]

If you do change out things to use the ship's bounding box be aware that you don't want to use SHIP:BOUNDS in a loop as calling SHIP:BOUNDS is so intensive on the C# side of kOS that kOS will stop executing for the rest of that physics tick (same as a wait 0.). You should instead get SHIP:BOUNDS once and store the result in a var and simply call the relevant suffixes on the stored var and only get it again if the ship's shape changes.

[astappiev]

Thank for the hint @nuggreat!

@hany can you try the latest version? I have improved throttling value for your case (when lander has small engines, now they should be working 100% of power if required).

[hany]

Amazing! Thanks for the updates. I’ve just pulled the latest and performed some tests. The updates definitely help (in particular, touch down speed is accurate now).

Few other things I’ve come across. When landing at a location along the equator (or close to), the landings are fairly spot on. However, if you try to land at a higher latitude, the landings are quite far off and lead to more crashes. I’ve noticed the following:

1. At higher latitudes, the lowering of the orbit for the breaking burn seems to position the periapsis too far off the target (always overshooting). By the time this ship begins its breaking burn, it overshoots the target and has to backtrack on the final descent. This does not occur at the equator.
2. At higher latitudes, after the breaking burn and before the final descent, there is too much horizontal velocity left, typically in the opposite direction to the landing location (combined with the overshooting from the first point). The result is as the ship free falls, it gets further and further away from the target. Nothing is done until the engines fire, but it’s usually too late at this point. On Minmus at a latitude of about 45°, I’m usually about 400m off the target (overshoot). On the Mun, I’m more like 900m-1km off.

For the second point, I believe the issue is the target velocity varies by latitude (slower than the equator) and needs to be subtracted from the delta-v. This is what I have:

// Brake the ship to finally deorbit.
set BreakingDeltaV to velocityAt(ship, time:seconds + eta:periapsis):orbit:mag.
// Need to cancel out the rotational velocity of the site for the braking burn.
// This helps ensure the horizontal velocity is cancelled as much as possible for the free fall.
local TargetHSpeed is (2 * constant:pi * (ship:body:radius + LandingSite:terrainheight) * cos(LandingSite:lat)) / ship:body:rotationperiod.
set BreakingDeltaV to BreakingDeltaV - TargetHSpeed.

For the first point, I believe the issue is related to the above, but not sure how to handle it yet. Here are some screenshots showing the first issue at higher latitudes:

This is right after the lowering of the orbit:

This is prior to the breaking burn (notice how the Pe is way ahead of the target):

This is after the burn has begun, already overshooting the target:

This situation almost always leads to crashes as it has to backtrack quite a bit.

Any thoughts on this?

[astappiev]

The script is not counting rotating of the body (planet) by its own axis. At the moment it performs calculating all fine, but then...

I have no idea how to easily improve that, I have minim background in math and algorithms used there. As a lazy workaround, you can navigate by our own using GUI and then when you are on a suborbital trajectory (after a break) use the script to land.

Alternatively, you can google for other landing scripts, if you find a better one, we can try to merge it into the collection.

Sorry.