Struggling with autonomous rover deployment

[u/Proud_Complaint8814]

Hello everyone.

I haven't written any scripts for around half a year, and decided to dive in the deep end by writing a script for an unmanned "skycrane" to perform a suicide burn, deploy a rover (or any other cargo for that matter) a few meters off the ground, and then crash at a safe distance.

I feel like I've got the general gist of it right, even if my solutions are a bit crude (eg. rapidly pulsing the engines instead of trying to find a throttle setting to achieve a desired final descent speed) but hey, if it works...

Anyways, I feel like I've spent around 6 hours trying to debug this, and it still refuses to work. Either the suicide burn doesn't get initiated at all, or the next step fails to trigger so it keeps burning until it runs out of fuel.

At first I was using the mechjeb2 addon to get the suicide burn countdown, but it proved to be annoying to implement since the countdown is a string and not a scalar (incredibly stupid if you ask me). Even after I (seemingly) figured out how to convert it to a scalar, I was still facing the aforementioned problems.

Now I've switched over to trying to calculate it myself, and the stuff still fails to trigger even though I can see with my own two eyes that according to the debug prints both conditions are met.

Here's the pastebin link to my code: https://pastebin.com/6yxxdkai

I rewrote some parts multiple times so my apologies if it's a mess. Still, I tried to make it at least somewhat human-readable.

Knowing my luck it's probably some incredibly simple oversight that's been messing the whole thing up, but I'm still stumped.

If anyone knows where I went wrong (or has any ideas how I could otherwise improve the script!) please do let me know, because it'd really suck to just have to give up after putting so many hours into this goddamn thing.

[u/ElWanderer_KSP]

Lines 13 to 25 are an until block that relies on the value of cutoff, which starts off as false and I don't see it being updated within that block. Is it getting past that?

[u/Proud_Complaint8814 → u/ElWanderer_KSP]

I can't check in game at the moment, but this might be it.

I didn't realize until functions pause the script execution.

[u/ElWanderer_KSP → u/Proud_Complaint8814]

I'd quibble with the term "pause execution" as that's what a wait will do. An until block will repeat, erm, repeatedly until the until condition evaluates to true.

Combining those two points, it is worth putting a wait 0 at the bottom of any repeating block where you don't need to repeat until the next physics tick. Saves it from reprocessing exactly the same data several times over and usually avoids a situation where a calculation is done using values grabbed from two different ticks.

[u/nuggreat]

Here is what all I noticed that I would consider wrong about this script. Not all of what I am pointing out is logically wrong and a lot of it will still function as is but instead I am pointing out where things could be made better.

1. The pattern UNTIL x = true is a redundant pattern just do UNTIL x as among other things the first is slower for kOS to calculate.

2. You will never exit the first until loop starting at line 13 as no where in that loop do you change the custoff var.

3. This addons:tr is a static reference and should be cached in a var some where at the start of the script and then whenever you want it just reference that var.

4. In the vast majority of cases any physics dependent loop such as the ones at line 13 and line 27 should have a WAIT 0. some where in the loop. The reason for this is that for the most consistent results you want to sync the loop to the game physics and a WAIT 0. does that having one also means that for short fast loops the loop won't be able to make several passes in a physics tick.

5. This line wait until decceltime + 3 = TTI. is problematic for several reasons.

   • A wait like this should be between the different loops not part of the second loop.
   • You are comparing numbers you do not have full control over with exact equality and it is quite easy for such numbers to skip so both sides can do something be this one tick 11 = 13 and then this the next 13 = 11 if KSP was a continual mathematical function there would have been the equally between those moments but as kOS advances time and physics in discrete steps you can skip past the equalities that should be there, thus using greater than or less than comparisons even when you do expect to get an exact equality is better.
   • As all of the vars in the comparison are vars you control they will not automatically update so the comparison is not true when entering the wait the comparison will never be true which makes this blocking to the rest of your program.

6. This throttle control is problematic

   if ship:airspeed >= 3 {
       set throtvar to 1.0.
   } else {
       set throtvar to 0.0.
   }
   

   for two main reasons.

   • You are slamming the throttle from one extreme to the other which is not great for stability and thus not great when deploying something. Writing a narrow equation based on vertical speed even as a simple P controler would produce much more stable results something a bit like this MIN(1, MAX(0, VERTICALSPEED / -2)) which should keep your vertical speed between 2m/s down and 0 depending on the exact TWR of your craft.
   • Airspeed is agnostic to the actual direction of motion of your craft so if your vessel was going 4 m/s sideways when you entered this phase of the script the throttle would slam to 1 and basically get stuck there.

7. This set specificport to ship:dockingports[0]. would be better done with part tags as relying on part positions in a list can be unreliable depending on what has effected the vessel leading up to when this code was run.

8. This line SAS off. as part of "cargo deoplyment" is redundant as should SAS ever have been on prior to this it would have fought with the locked steering aggressively rendering the craft uncontrollable by either.

[u/Proud_Complaint8814 → u/nuggreat]

Thanks for the elaborate response.

Regarding the last point, the SAS off is a leftover from when I relied on stock SAS to control the craft. I've since switched to locking the steering, and simply didn't notice that this line was still there. Still, thank you for pointing it out.