[KSP 1.12.x] kOS v1.4.0.0: kOS Scriptable Autopilot System

[Crimsyn]

On 3/22/2018 at 3:25 PM, Steven Mading said:

I was also hampered by the fact that I knew it wasn't done until Putty would work.  I was discovering ways that Putty refused to adhere to what the RFC's said it had to do, and I had to take on roles that should be done by the client side, despite being the server side.

There may also be a problem with VT100 specifically.  There's a pending PR where someone noticed the VT100 detection isn't implemented right.  As a test, see if claiming to be an XTERM terminal makes things behave better, @Crimsyn

 

 

Sorry for the late reply, but I have an update. After much head-desk, I kind of just gave up. Caught dunbaratu on twitch, and ran it past him, and found out tate KoS uses the terminal ident request as a keep-alive. I thought I could just respond once and be done with it. I trashed my old code, so I haven't tried it again yet, but I am going to try again and see what happnens

[Dunbaratu]

7 hours ago, Crimsyn said:

Sorry for the late reply, but I have an update. After much head-desk, I kind of just gave up. Caught dunbaratu on twitch, and ran it past him, and found out tate KoS uses the terminal ident request as a keep-alive. I thought I could just respond once and be done with it. I trashed my old code, so I haven't tried it again yet, but I am going to try again and see what happnens

Good luck.  I'm sorry the documentation page neglected to mention the TTY keepalive heartbeat.

For others following this forum thread who weren't there for the stream - a summary:  A telnet client being asked "what is your terminal" by the server is required to respond with the answer in a timely fashion to be in keeping with the RFCs about the terminal type protocol.  Technically this is true throughout the entire life of the connection, but in practice it usually only happens during the initial negotiations between client and server.  Then it typically never happens again.  However, the spec technically says the server can ask this question at any time whenever it feels like it and the client is meant to respond.
 

I ended up using this as a homemade keepalive heartbeat signal so I could disconnect the server if the client just outright hung.  Why such an indirect way to make a heartbeat signal?  Well, because after much searching I just couldn't figure out how to make the .NET/Mono api let me access the more low-level TCP/IP socket's settings.  It seemed that .NET was providing a bit *too much* abstraction here.  There's a keepalive feature for sockets, which is the more appropriate place to be doing that sort of thing, but I couldn't find the way to get my hands on it while still staying in the portable OS-agnostic subset of Mono that Unity allows.

So I just did the 'heartbeat' at a little bit of a higher level - using the fact that the RFCs state the server can ask for the TTY type any time it feels like and expect a timely response from the client.

The effect that @Crimsyn saw was that the server sent a TTY type request every 10 to 15 seconds or so, which he thought was the server being stuck in a broken state, and when his client didn't respond, after a little bit the connection was closed.

[www2]

Is KOS compatible with 1.4.3?

[infinite_monkey]

1 hour ago, www2 said:

Is KOS compatible with 1.4.3?

Yes it is.

[RizzoTheRat]

I'm stuck again.  I've got a vessel in orbit around the mun,  I've calculated the required dV and an ejection angle of 140 degrees before mun retrograde.  If I manually put in node about there it looks good. 

However I can't figure out to plot the ejection angle in KOS.  As I'm orbiting the Mun I can't get the Muns velocity vector relative to Kerbin, and can't target either the Mun or Minmus to measure my angle against a target vector.  So how do I measure the angle between my ships mun orbital velocity and the Muns Kerbin orbital velocity? 

[ElWanderer]

10 hours ago, RizzoTheRat said:

I can't get the Muns velocity vector relative to Kerbin,

LOCAL moon_vel IS VELOCITYAT(moon,c_time):ORBIT.

I then get my ship's position vector (from the centre of moon to where the ship will be i.e. POSITIONAT(SHIP,c_time)-BODY:POSITION, flattened into the appropriate plane with a vector exclude) and get the angle between it and -moon_vel. Then iteration/calculations (for ages I simply incremented at 15s intervals) follow to find out when we will be at the point with the right angle to retrograde.

[Omann]

I've been looking for a way to implement an error handler in a script.

Specifically, I have a script that accepts site names as arguments and displays heading and distance information. These are stored in a list. When a contract requirement is completed, KSP removes the site from the game. Which quickly clobbers my script trying to access a no longer existing object.

What I'm wondering, is there a common method for identifying such an object within the script and removing it or skipping over it in my list.

In other languages I would probably use a, "try" block.

[kcs123]

2 hours ago, Omann said:

In other languages I would probably use a, "try" block.

Unfortunately, not possible, or at least not in convinient way. Asked about it some time ago. KOS mod/plugin already use main try-catch block code to handle exceptions, to rather give you error message on KOS terminal screen than to crash whole game due to user mistakes. So, you need to assume KOS as old/limited language from 60's (sort of) and create your own workarounds for this. Before you pass something as parameter for further calculations, you need to put additional piece of code to check out if those values would crash your script or not.

Try-catch usage have probably spoiled us all in mothern languages, now you need to re-learn how to do it in old fashion way.

[Omann]

That pretty much confirms what I thought.

I think I'll try using two KOS processors. One running my navigation. It will crash and need to be restarted. One running my autopilot. It being a separate process should continue running. Or not...

[Proply]

Hi all, I am having a problem where throttle control is not being returned to the user after the program has ended. It stays stuck at 0 no matter what I try (shift, ctrl, z, x, "unlock throttle."). Any idea what I might be doing wrong or how to force kOS to return throttle control to the user?

[infinite_monkey]

41 minutes ago, Proply said:

Hi all, I am having a problem where throttle control is not being returned to the user after the program has ended. It stays stuck at 0 no matter what I try (shift, ctrl, z, x, "unlock throttle."). Any idea what I might be doing wrong or how to force kOS to return throttle control to the user?

I had throttle control problems when MechJeb was running alongside kOS.

[ElWanderer]

2 hours ago, Proply said:

Hi all, I am having a problem where throttle control is not being returned to the user after the program has ended. It stays stuck at 0 no matter what I try (shift, ctrl, z, x, "unlock throttle."). Any idea what I might be doing wrong or how to force kOS to return throttle control to the user?

Have you used SET THROTTLE TO X anywhere in your script (as opposed to LOCK THROTTLE TO X)? I think I've heard other people report that behaviour, though I've not done a search yet to check that.

I assume you've not lost connection or anything...

Edit - I did a search:

Erm, didn't really want that embedded, as you can't see the replies without going to the link itself. https://www.reddit.com/r/Kos/comments/7q6oia/control_throttle_after_program_ends/

 

Edited May 13, 2018 by ElWanderer

[RizzoTheRat]

I have a "Closedown" function I run at the end of my scripts that includes

LOCK THROTTLE TO 0.

UNLOCK THROTTLE. 

This ensures any existing SET or LOCK is cleared and I have manual control. I do the same with STEERING as I've found this can get stuck too.

Edited May 13, 2018 by RizzoTheRat

[RizzoTheRat]

On 5/12/2018 at 7:12 PM, ElWanderer said:

LOCAL moon_vel IS VELOCITYAT(moon,c_time):ORBIT.

I then get my ship's position vector (from the centre of moon to where the ship will be i.e. POSITIONAT(SHIP,c_time)-BODY:POSITION, flattened into the appropriate plane with a vector exclude) and get the angle between it and -moon_vel. Then iteration/calculations (for ages I simply incremented at 15s intervals) follow to find out when we will be at the point with the right angle to retrograde.

Thanks, that's done the trick.  I've offset the lead angle from the  mun velocity and burn when that matches the ship velocity

set shipheading to velocityat (ship:body,time:seconds):orbit:normalized +R(0,-leadangle,0).

My lead angle seem's be slightly out though so I need to try and work out why, but it only makes about 6m/s difference.

[ElWanderer]

17 hours ago, RizzoTheRat said:

My lead angle seem's be slightly out though so I need to try and work out why, but it only makes about 6m/s difference. 

I would expect small discrepancies unless your orbit has very low eccentricity and inclination. Try using the orbit editor to put those values at something tiny (or even zero, though I find 0 ECC can cause problems) and see if it is more accurate.

Also, I think R(0,angle,0) would only be 100% correct for 0-inclination orbits around bodies whose own inclination is 0.

If you have a polar orbit around Minmus, for example, you need to bear in mind that neither ship nor planet velocity is in the plane defined by the universe's Y-axis.

[RizzoTheRat]

I  had completely forgotten about eccentricity impacting it, D'Oh.  My test craft was Alt-F12'd in to orbit though so should be perfectly circular orbit, but I'll need to modify it to cope with eccentric orbits.  If I move my dV and angle calculation in to the loop it should sort that out though as it'll be doing the calculation based on the current orbital velocity vector.

The current setup only works for an equatorial orbit at the moment, but one step at a time.  Presumably the hyperbolic excess velocity will still be retrograde to the Mun whatever the inclination, so the dV calculation will still work, I'll just need to work out the angle differently.  I'm not entirely sure what axes the R(x,y,z) work on but I can test that by drawing some vectors on screen.  I guess I could just have upper and lower bounds on the angle between the muns orbit and the ships orbit, but it doesn't feel as neat.  I'm also burning prograde at the moment rather than tangential as I still haven't implemented the Solar Prime Vector stuff Panda put me on to a couple of pages back to keep things pointing the same way.  I'm getting around that on the burn to the Mun by plotting a node with more dV than it needs, but that's very untidy

 

[Kartoffelkuchen]

Automated airplane landing

 

Sorry for the potato quality...

Whatever, the script is not done yet, but it's getting better and better! Just thought I'd share

[ElWanderer]

21 hours ago, RizzoTheRat said:

Presumably the hyperbolic excess velocity will still be retrograde to the Mun whatever the inclination, so the dV calculation will still work, I'll just need to work out the angle differently.  I'm not entirely sure what axes the R(x,y,z) work on but I can test that by drawing some vectors on screen.

Yes, to the first part, though with high inclination orbits the plane of your orbit won't be aligned nicely with the prograde/retrograde motion of the body you're orbiting most of the time. Whereas an equatorial orbit has an escape burn position every orbit, you could have to wait days to get an efficient return from a polar orbit.

There is a good video Steven Mading / Dunbaratu put together about the axes on YouTube somewhere. The short version is that the Y axis always points to the universe's up direction, but the X and Z axes are constantly rotating around it and so can't be trusted to be pointing in any particular direction, except that they'll be orthogonal to the Y axis and to eachother. As such, I'm always very wary of solutions with R() rotations in them and prefer to have things rotated relative to other tangible things rather than the raw axes.

Edited May 16, 2018 by ElWanderer

[RizzoTheRat]

2 hours ago, ElWanderer said:

Yes, to the first part, though with high inclination orbits the plane of your orbit won't be aligned nicely with the prograde/retrograde motion of the body you're orbiting most of the time. Whereas an equatorial orbit has an escape burn position every orbit, you could have to wait days to get an efficient return from a polar orbit.

I had a quick fiddle with it last night and was surprised to find it's only about an extra 100m/s for a polar orbit at about 45 degrees to the Muns orbital direction.  Fairly easy to set it up to wait for a better alignment, but I'm using USI Life support so don't want to hang around too long.  I've not figured out how to calculate the dv for a non-retrograde exit from the mun yet, but it mght make sens to do that and compare it the available dV...  It's amazing how every task seems to generate a load o new ones isn't it

I had fun last night realising that my power landing script for Kerbin doesn't work too well when the terrain is as varied as the Mun  It now kills it's horizontal velocity at around 2km altitude and then drops to a suicide burn, which stops it from crashing in to inconveniently positioned mountains that don't tend to be an issue when landing in atmosphere.  

Is there a way to mark a waypoint on the ground so I target a specific landing point?  Otherwise I guess I'm going to need to work out the geoposition of my projected landing point and then iterate up and down the slope to find a flat bit. 

 

[ElWanderer]

3 hours ago, RizzoTheRat said:

Is there a way to mark a waypoint on the ground so I target a specific landing point?

My (work in progress) precision landing script requires the target latitude and longitude (plus a maximum allowed slope angle, if the slope at the target point is higher, it goes looking for somewhere flatter) to be edited into the boot script before launch.

You can get the latitude and longitude of contract waypoints. I believe KerbNet allows you to drop a new waypoint, which you could then use as an aiming point, but I've not tried that. Or you could ask for the target coordinates to be typed into the terminal, or even set-up a GUI to get this. Of course most of these methods are somewhat blind unless you have a good map of the area!

[RizzoTheRat]

I use ScanSat so will have a good map at some point (although I need a Mun landing to get the science to get the high res scanner...), but I'm not sure if I can extract info from that other than by eye.  Although thinking about it there are loads of maps people have created from ScanSat data so maybe I could extract it and do something in Excel to identify suitable landing sites in each biome...

ETA:  Oooo, SCANSat can export to CSV file.

 

Edited May 16, 2018 by RizzoTheRat

[Black-Two-]

4 hours ago, ElWanderer said:

My (work in progress) precision landing script requires ... allowed slope angle, if the slope at the target point is higher, it goes looking for somewhere flatter) to be edited into the boot script before launch.

How do I get the slope angle from above? Do you compare the target site with the surrounding area or something?

[ElWanderer]

46 minutes ago, Black-Two- said:

How do I get the slope angle from above? Do you compare the target site with the surrounding area or something?

Yes, I use something based on what (Cheers) Kevin Gisi did in Kerbal Space Programming episode 42 or 43:

Calculate three points on the ground (A, B, C) a couple of metres away from the target site, in different directions (forming an equilateral triangle in my case). I then take vectors A->B and A->C and cross them, to get a new vector that will point at 90 degrees to the apparent slope of the ground i.e. if the ground is flat, it'll point straight up. The vector angle between that resultant vector and the up vector at the target point gives you the slope angle. Excluding the up vector from the resultant vector gives you a horizontal vector that points down the slope, which is probably the best direction to go in to look for somewhere flatter. That said, I have some breakout code that jumps half a kilometre away if it looks like we've got stuck in a hole or something!

Though a work in progress generally, I do seem to have the slope code in a finished (i.e. documented state!)

https://github.com/ElWanderer/kOS_scripts/blob/v1.1_draft_changes/documentation/lib_slope_readme.md

https://github.com/ElWanderer/kOS_scripts/blob/v1.1_draft_changes/scripts/lib_slope.ks

Edited May 16, 2018 by ElWanderer

[Black-Two-]

On 5/16/2018 at 9:31 PM, ElWanderer said:

Yes, I use something based on what (Cheers) Kevin Gisi did in Kerbal Space Programming episode 42 or 43:

Calculate three points on the ground (A, B, C) a couple of metres away from the target site, in different directions (forming an equilateral triangle in my case). I then take vectors A->B and A->C and cross them, to get a new vector that will point at 90 degrees to the apparent slope of the ground i.e. if the ground is flat, it'll point straight up. The vector angle between that resultant vector and the up vector at the target point gives you the slope angle. Excluding the up vector from the resultant vector gives you a horizontal vector that points down the slope, which is probably the best direction to go in to look for somewhere flatter. That said, I have some breakout code that jumps half a kilometre away if it looks like we've got stuck in a hole or something!

Though a work in progress generally, I do seem to have the slope code in a finished (i.e. documented state!)

https://github.com/ElWanderer/kOS_scripts/blob/v1.1_draft_changes/documentation/lib_slope_readme.md

https://github.com/ElWanderer/kOS_scripts/blob/v1.1_draft_changes/scripts/lib_slope.ks

That's genius!

I have a deorbit script that I use for (some) boosters in career but a lot (most) of the time the damn things always seem to hit the slopiest terrain possible, so adding this functionality would be awesome.

[Drew Kerman]

does the code example for CHUTESAFE work with RealChute? I started doing some testing tonight but I couldn't tell if it was not meant to work or I was doing it wrong.