[1.3] kOS Scriptable Autopilot System v1.1.3.0

[MrOnak]

Hey all.

I have two things:

1) out of sync errors. I found a post saying this is probably a race condition. If you're still interested in log files / craft files / scripts, let me know. It seems to be quite reproducable in the craft / script I have.

2) How the hell can I display the pitch of a target vessel over the horizon? target:bearing / target:heading is easy enough for the compass reading to the target but I've tried verious things for the better part of yesterday and every value I've tried gives me some weird number, not the 80° / 70° / ... / 20° or whatever it is that is on the navball where the red target marker is that I expected.

thanks in advance.

P.S.: oh by the way if that hover craft guy is still around, this is an accurate calculation of the g-pull experienced by your craft:

set G to 6.6738480e-11.
lock vesselMass to ship:mass * 100. 						// must be converted to kg
lock bodyMass to ship:body:mass.							// is already in kg
lock distance to ship:body:radius + ship:body:distance.		// in meters
lock bothMasses to vesselMass * bodyMass.					
lock distanceSquared to distance * distance.
lock massesByDistance to bothMasses / distanceSquared.
lock F to G * massesByDistance.
lock vesselGPull to F / vesselMass.

as you can see its broken up into many pieces for debugging purposes, you can probably condense it somewhat

Edited May 31, 2014 by MrOnak

[Dunbaratu]

lock bothMasses to vesselMass * bodyMass.	
lock distanceSquared to distance * distance.
lock massesByDistance to bothMasses / distanceSquared.
lock F to G * massesByDistance.
lock vesselGPull to F / vesselMass.

I suspect that's going to be susceptible to large floating point error because you're multiplying two things one of which is rather small compared to the other (the vessel mass being many orders of magnitude smaller than the body mass), and then in the end dividing the end result by the small thing again (the vessel mass) to get the quantity you want, the acceleration from gravity. Multiplying the scale of a number up to a huge magnitude and then trying to cancel it back out again by dividing it back down tends to be more error prone than using calculations that keep everything in the same general magnitude.

For example, if you want to calculate what is 99.99999999% of 5000, this way of doing it:

set x to 5000 * (9999999999/10000000000).

ends up being more accurate than this way:

set x to (5000 * 9999999999) / 10000000000.

even though in principle they should be mathematically identical. (assuming I typed the correct number of zeros there.)

So you're going to be better off cancelling out the mass of the vessel in paper algebra first before calculating anything on the computer. (It does cancel out - left as an exercise for the reader, if the only thing you're interested in calculating in the end is vesselGPull).

[MrOnak]

I can't seem to figure out the frame of reference (?) relative to which nearly all ship: vectors seem to be.

For example, when I read the ship:facing:roll value in level flight, the number changes depending on whether I fly north/south/west/east. The same happens with ship:facing:pitch.

ship:direction:* seems to behave identical to ship:facing:*.

To be honest I'm running out of ideas how to put the numbers in a stable frame of reference that does not change depending on the planes' attitude (thats a bad way to put it - of course they change to the ships attitude - hope you know what I mean) but that always gives me numbers identical to what indicated by the center of the navball.

Any clues? Thanks in advance.

Edited May 31, 2014 by MrOnak

[marianoapp]

All the directions when on the surface/low altitude use a frame of reference that can be considered to be at the center of the planet, and the components of it are rotations around the axes. We know that that is completely unintuitive so we're working in adding some features to convert between the different reference frames.

[MrOnak]

thanks the for explanation... I thought something like that might be the case but I must admit I hadn't thought of the center of the planet

Is there any way to convert the direction to something "sane"? I tried things like UP + R(p, y, r) or NORTH + R(p, y, r) but that doesn't seem to make any difference.

[TheClassiestMedic]

-snip-

P.S.: oh by the way if that hover craft guy is still around, this is an accurate calculation of the g-pull experienced by your craft:

set G to 6.6738480e-11.
lock vesselMass to ship:mass * 100. 						// must be converted to kg
lock bodyMass to ship:body:mass.							// is already in kg
lock distance to ship:body:radius + ship:body:distance.		// in meters
lock bothMasses to vesselMass * bodyMass.					
lock distanceSquared to distance * distance.
lock massesByDistance to bothMasses / distanceSquared.
lock F to G * massesByDistance.
lock vesselGPull to F / vesselMass.

as you can see its broken up into many pieces for debugging purposes, you can probably condense it somewhat

Hover guy here

I ended up teaching myself the basics of control theory, and making a PID control system for the craft! It's insensitive to gravity, engine type, and you could even use it for something completely different with just a little tweaking! I'd post it somewhere for others to use, but I'm not sure if this is the right place.

[MrOnak]

Yay! Progress is alway awesome

[Dunbaratu]

I can't seem to figure out the frame of reference (?) relative to which nearly all ship: vectors seem to be.

To a certain extent this isn't kOS's fault because its just exposing what's really wacky about KSP's own internal coordinate system, which is truly messy to work with.

Here's the stuff that is always true about KSP's coordinate system, and whether or not kOS does anything to try to "fix" it or not:

- The origin is always *near* the active vessel but not exactly at it. (After coming out of a timewarp it starts off being right on the vessel, but as the physics engine operates on the ship the ship drifts away from the origin.) kOS tries to fix this for you by offsetting all coordinates to give you a frame of reference relative to the ship's actual center of mass, as if the origin was there. I discovered a place where it didn't do that but I think it's fixed now in the latest release.

- The Y axis is fixed. Draw an imaginary arrow from the center of the primary body through its north pole. This is always the direction of the Y axis. The origin isn't AT the center of the body, but it's Y axis is oriented to be in line with the body's north pole axis direction. Note this is NOT the same as the "north" direction, because of curvature of the surface. i.e. if you were at latitude 45 degrees, then the Y axis would be pointing toward the north but pitched up 45 degrees above the horizon. If you were at the north pole, the Y axis would be pointing straight up.

- The X and Z axes are always perpendicular to the body's equator plane, 90 degrees apart from each other (obviously). BUT they are not fixed. This is the messy part, due to some really wacky stuff KSP does with the rotation of the planet (sometimes the planet rotates and the universe's coordinate grid stays still, while other times the universe's coordinate grid rotates and the planet stays still - it depends on what altitude you're at which method the game uses. As you get lower and closer to the terrain it becomes better to keep the planet fixed so the terrain doesn't get recalculated all the time, or so I've heard that's the explanation.) Anyway, the result of this is that it's impossible to say what the direction of the X and Z axes is because it all depends on how long you spent at low altitude and how long you spent at high altitude - how much of the time was the planet fixed and how much of the time was it rotating?

I'm trying to come up with some good tools to hide a lot of this mess from the user, but I'm waiting on feedback from the others for approval or disapproval of my proposal before I embark upon trying to implement any of it (hint, hint).

[MrOnak]

Woah! Thanks for the detailed answer, I think I begin to understand why my attempts were futile

To a certain extent this isn't kOS's fault because its just exposing what's really wacky about KSP's own internal coordinate system, which is truly messy to work with.

Here's the stuff that is always true about KSP's coordinate system, and whether or not kOS does anything to try to "fix" it or not:

Just to be sure, I wasn't implying kOS is at fault or anything . Its awesome, and it has a "0." in front of its version number. All is good

- The X and Z axes are always perpendicular to the body's equator plane, 90 degrees apart from each other (obviously). BUT they are not fixed. This is the messy part, due to some really wacky stuff KSP does with the rotation of the planet (sometimes the planet rotates and the universe's coordinate grid stays still, while other times the universe's coordinate grid rotates and the planet stays still - it depends on what altitude you're at which method the game uses. As you get lower and closer to the terrain it becomes better to keep the planet fixed so the terrain doesn't get recalculated all the time, or so I've heard that's the explanation.) Anyway, the result of this is that it's impossible to say what the direction of the X and Z axes is because it all depends on how long you spent at low altitude and how long you spent at high altitude - how much of the time was the planet fixed and how much of the time was it rotating?

Hmmm.... X/Z are not fixed to a point on the surface, that is to GeoCoordinates? That'd imply that Kerbin doesn't have a Greenwich?

If so, how do GeoCoordinates work, where is the 0° longitude?

One thought crossed my mind last night. When I lock steering to HEADING(90, 20). I go indeed go due east, 20° up and with 0° roll. Is there a way to read my current heading / pitch /roll similar to setting it in that way? Maybe a picture of what I'm trying to do (one of many things) will help.

I present, my Kerbal Defense SAM launcher:

It is already a working system which tracks a target automatically, launches when target is within range and the missile actually intercepts the target (with a margin for error due to framerate & the physics range load hiccup). Problem is, I'm not happy with it .

The parts of relevance here are the washer (to point to the right heading) and the hinge (to adjust pitch toward the target). Both are bound to action groups for easy manipulation in kOS.

Since the launcher itself actually doesn't move I can't simply lock steering to VESSEL("target"):direction., obviously. What I do is to move the washer until abs(target:bearing) < 1 and keep adjusting. Easy enough. The hinge currently just moves up for a fixed amount of time to point about 60° up. There is nothing smart involving the hinge.

Now, what I'd like to do programatically is two things:

- query the angle over the horizon of the target, a.k.a. the pitch I need to point at. Which I think I know how, but there is no point in trying before part two works, which is

- query my own current pitch. The missile does have a probe core, so after "control from here" the navball shows the correct pitch.

Once I have those two I can very easily move the hinge accordingly until my own pitch matches the targets angle over the horizon.

I guess whats screwing with my head is that the navball is showing the information (hence KSP knows my pitch?) I want and that kOS in fact allows me to set my direction with HEADING(h, p) which seems to imply that kOS also knows how to "get" there? Is there a way to query that information? If pitch could be read, how about roll? In an unrelated project I'm trying to develop an autopilot .

Sorry that I keep you people, this is driving me mad

Thanks a ton again for kOS. It has already become my physics programming environment of choice

[Dunbaratu]

Sorry that I keep you people, this is driving me mad

Don't be sorry. You're using it to do something cool, and that's always good - the more people do that the better the advertising for it is.

And yes, I understand why it drives you mad. It drove me mad to the point where back in 2013 I worked it out from experiments and pencil and paper without even being able to read the C# code under the hood yet. (What I did was I put an object into orbit and had a program just printing out data to the screen so I could compare longitude/latitude and the UP rotation tuple to my XYZ coordinates to try to work out by inductive reasoning what the actual system was.)

There is a way to work out what the current offset is between longitude and the actual Z axis by reading the rotations inside the UP rotation tuple and working out from that what the relationship between the original axias and the rotation that was needed to turn it into an upward direction. (i.e. if Up:yaw is 30, then that means the Z axis (if you moved the origin to the center of the planet) would be poking out of the surface 30 degrees longitude away from where you are right now, or something like that. It's been a while since I worked it out. Here's the page I wrote about it back then, but it's getting a bit dated and I don't make any promises that it's still true:

http://kos.wikia.com/wiki/XYZ_system_of_KSP

)

It's not entirely right, I now realize (for example it assumed the world grid was right-handed but it's actually left-handed.)

Also because of the constantly rotating frame of reference, you'll need to make sure you keep re-updating your vector calculations otherwise sometimes they become off over time as the universe's coordinate grid rotated the axes and thus altered the meaning of your vector's x, y, and z components.

We all do want this messy reference frame problem dealt with, but it's not a quick fix. It affects a lot of things and has to be thought through carefully.

Edited June 1, 2014 by Steven Mading

[Entropius]

So I tried upgrading to v0.12.1 today and upon loading a ship already in orbit, my ship appeared to be missing everything except the command module. It's like the rest of it was deleted.

And then I tried launching a new ship, and the first one launched okay but the 2nd one after revert to launch caused me to have another command-module-only ship.

Anyone know what's going on?

EDIT 1: Nevermind, the zipped download says 12.1 but in the terminal it says the version is 12.0. Maybe this is the older broken version still. I need to sort out what version this really is.

EDIT 2: I tried downloading 12.1 from GitHub instead of Curse and the same bad results happened. Ships missing everything but their module. Even worse, this time I would click the launchpad/runways/VAB buildings and it wouldn't let me actually do anything with them. Until I know what's going on I'll roll back to 0.11.

EDIT 3: Okay, I tried 12.2 prerelease, and the same bug with ships missing everything but a command module occurs here too.

Edited June 1, 2014 by Entropius

[Entropius]

Okay I think I found the root of the problem, 12.2-prerelease stopped erasing my ships parts and horribly glitching things out after I removed my old module-manager config. The removed module-manager code is as follows:

@PART[*]:HAS[@MODULE[ModuleCommand]:HAS[!MODULE[kOSProcessor]]]
{
    MODULE
	{
		name = kOSProcessor
	}
}

I'm guessing that while this worked in 0.11, it breaks stuff in 0.12 or newer.

So does anybody know how to add kOS processor functions to all command modules in 0.12.x without breaking them?? (Preferably for sandbox mode, in case it matters)

[Dunbaratu]

So I tried upgrading to v0.12.1 today and upon loading a ship already in orbit, my ship appeared to be missing everything except the command module. It's like the rest of it was deleted.

And then I tried launching a new ship, and the first one launched okay but the 2nd one after revert to launch caused me to have another command-module-only ship.

Anyone know what's going on?

EDIT 1: Nevermind, the zipped download says 12.1 but in the terminal it says the version is 12.0. Maybe this is the older broken version still. I need to sort out what version this really is.

EDIT 2: I tried downloading 12.1 from GitHub instead of Curse and the same bad results happened. Ships missing everything but their module. Even worse, this time I would click the launchpad/runways/VAB buildings and it wouldn't let me actually do anything with them. Until I know what's going on I'll roll back to 0.11.

EDIT 3: Okay, I tried 12.2 prerelease, and the same bug with ships missing everything but a command module occurs here too.

How did you exit the game the first time the error happened? Because I've seen this ages ago back in the old 0.9 version, and once it happens it will permanently STORE the vessel in the campaign save file with the parts gone from it unless you hurry up and force-quit KOS without letting it checkpoint the save file. Once it happens the first time, then subsequent reloads won't bring the missing parts back again, even if the actual bug that caused it is no longer there, because the bug deleted the parts from the saved game the first time.

I have never seen this problem happen in versions higher than 0.10 anymore, and you're the first to report it with any new versions. Can you try it with a *new* vessel, save and restore the game, and the very first moment a part of the vessel is missing upon loading, ALT-TAB out of the game while it's still running and save a copy of the file KSP_Data/output_log.txt somewhere and then go back into the game and quit out of it? (You have to save the output.txt file to a new name because it overwrites the file each time you run KSP so the evidence will be gone if you run again after the bug happened.)

The bug happens when something throws an error during the process of reloading the vessel from on-rails into full-blown-physics. It goes through each of the vessel's parts one by one and puts them on the ship. If any part along the way generates an error, the act of loading the parts quits and the rest of the vessel's parts don't get loaded. (Then if it saves the game at that point it saves this new missing-parts version of the vessel and you'll never get the parts back again after that.)

Seeing the output_log.txt file will let us see what the actual error was that was generated, and let us see which mod was responsible.

More than one mod has had this effect before because pretty much any error during the loading process will do it. KSP is designed to quit loading and not continue with the rest of the parts of the ship once any single error happens.

[EDIT: your second post ninja'd in while I was writing this]

[marianoapp]

@MrOnak: Nice to see my missile inspired someone

There's no simple way to convert a direction to heading and elevation, but can be done with some vector math:

// this only change when you move on the surface
set targetVector to targetVessel:direction:vector:normalized.
set upVector to ship:up:vector:normalized.

set shipFacing to ship:facing.
set sinYawF to sin(shipFacing:yaw).
set cosYawF to cos(shipFacing:yaw).
set sinPitchF to sin(shipFacing:pitch).
set cosPitchF to cos(shipFacing:pitch).
set facingVector to V(sinYawF*cosPitchF, -sinPitchF, cosYawF*cosPitchF).

set diffVector to facingVector - targetVector.

// this returns a value where 0 is the horizon and 1 is looking directly up
// can be multiplied by 90 to get degrees from the horizon
set diffUp to vdot(diffVector, upVector)

@Entropius: ModuleManager support is broken, but we accidentally left the patch in the download. We're working to fix it.

[MrOnak]

@Mariano: Oh yeah, that vid started quite something in my head In fact I ended up copying your code for the missile-in-flight part and tweaked it a bit to my needs. I'll put the whole kOS script up once I'm happy with it, with credits to you of course .

I'll definitely check your code of calculating the elevation over the horizon, that should be helpful

@Steven: Thanks for the link to the coordinate system page. I read it twice by now but that topic needs more time than I currently have Anyway, thanks a bunch, it will be helpful.

What I noticed while writing my plane autopilot: As soon as I start setting any of the ship:control:* values, manual steering and manual throttle is completely disabled. Is that a known issue?

I.e. with my "altitude hold" program in the autopilot being active (it manipulates ship:control:pitch) it immediately slams the throttle to 0 without an option for manually control the throttle any further until the script is stopped.

Similarily when I enable my cruise control (manipulates ship:control:mainthrottle) I'm unable to steer with any of w/a/s/d/q/e. Using ship:control:mainthrottle was necessary in the first place because the "altitude hold" aspect makes using lock throttle to myThrottleVal impossible.

[MrOnak]

I just thought I'd share a first glimpse of my autopilot

(edited for embedding the video)

Edited June 3, 2014 by MrOnak

[erendrake]

I just thought I'd share this

Good Show Chap!

That was a fun video to watch. Thank you for sharing!

[marianoapp]

Nice! (although I kept waiting for the SAM to appear behind a hill and blow the plane to pieces )

[DocBear]

Hi I do not speak English. I use Google translator.

Please help me. In the video http://youtu.be/uzdizR6bJiM?t=5m41s with 5:41. Section "synchronezed orbiters".

Shows how to launch two missiles at one time. kOS version 0.2.

But in version 0.12.1 by using the command "on ag1 run programName" and use the "1" key. Triggered all script steps immediately. rocket crashing.

how to replicate this training video?

[Dunbaratu]

I just thought I'd share this

That's pretty good! I'm impressed. I've done a lot with space maneuvering but nothing with flying in atmo yet (other than calculating terminal velocity for rocket throttle purposes.)

As to your comment about the inability to control the ship while the autopilot is doing things, I too think it would be great if that could be dealt with but I don't know how hard that would be. In the real world most autopilots are there to supplement pilot's inputs rather than override them utterly. (As least they were until Airbus changed all that ... grumble). So, for example, you can tell the autopilot things like "please adjust my throttles as needed to maintain my speed at a constant while I make this turning maneuver..."

Many autopilots also have an emergency dis-engage where they "let go" if the pilot moves the controls manually. (I'm not sure we necessarily want *that*).

Does kOS actually *need* to lock out user input on WASDQE/Shift/Ctrl? Can that lockout be disabled? And if it is, and the autopilot is trying to, say, pitch down while the player is trying to pitch up, who will win? A solution in which flybywire releases control of a particular control axis (one axis at a time, rather than all controls globally) when it notices the user pressing the appropriate control for that axis, and then grabs it back again after that control hasn't been pushed for a second or so, would be great.

[MrOnak]

Haha! I'm glad you all like it. As I said in the video description the source will be available in a short while, when its a bit more useful.

@Mariano: I was actually thinking about that but I can't figure out how to have two scripts run on two different vessels at the same time... as soon as I switch vessels the one I just left seems to stop processing and gets out of control. (BTW your pitch script works like a charm, thanks again!)

Steven: I must say I was surprised myself how well the terrain follow mode works. Given that the KSP ground radar points straight down and not forward as any sane terrain following radar would. (Yes yes, its useful for rockets, I know ) That means that I can't do calculations based on "hill coming up in 20 seconds" but have to resort to "HILL! NOOOOOW!". Hence the 9-10 g pulls. Aside from that, the PID controllers do a rather good job. The coding part was easy enough (getting to know kOS aside). The only time consuming part was the PID-Tuning but it always is a PITA, not only in KSP

Obviously if you follow the terrain at a radar altitude of 2km rather than 400m the upper/lower bounds for the pitch can be much less, resulting in slower response and less accurate altitude over changing terrain but smooooother flight. If anyone is interested, I did a datalogging run on another flight while I was tuning the gain parameters. It was a terrain following flight with much smoother pitch bounds and a radar altitude of 894m: image here. For a quick glimpse: Light green is the required altitude over terrain, red is the actual altitude over terrain.

Regarding those locked controls: Obviously I don't know why they're locked in the first place but assuming there's a good reason for that I believe there is still an option for a more controlled handing-over-controls:

One way would be to have the script to lock/unlock controls explicitly, on a per axis basis. set ship:control:mainthrottlelock to true or something like that. That would allow i.e. my autopilot to take control over the throttle but leave pitch/yaw/roll untouched. Or lock only pitch for terrain following but allow me to handle throttle/roll/yaw. I believe that is transparent enough for the programmer to handle and it would avoid fighting-over-control issues which would probably lead to increasing oscillation.

Another way would be a "last input wins" approach. Not sure how feasible that is to implement in kOS as that depends largely on how the ship:control section is structured in the first place.

Concerning flight performance I don't see any benefit of the "last input wins" approach. kOS trying to achieve (A) while your inputs are trying ( on the same control axis doesn't seem like something that would work in many scenarios.

Emergency disengage? Nah... switching off kOS is easy enough and its not like a crash actually matters.

Annnnnyway. Back to me figuring out heading and roll *sigh* heheh

[edit]@Steven Oh my god I just found the VecDraw video on youtube. I'm so excited now [/edit]

Edited June 3, 2014 by MrOnak

[MrOnak]

On a different note I think my SAM-Launcher is ready for the public. https://www.dropbox.com/s/q259owv1o3ubj1l/kOS%20SAMLauncher.zip

Thanks to Mariano and Steven once more, the whole thing would have taken a lot longer without your help .

[marianoapp]

@MrOnak: I used the Skillful plugin (just the dll) that automatically expand the loading range of the vessels, that way you can switch between the plane and the launcher and have scripts running in different vessels at the same time.

[MrOnak]

Actually range isn't my problem at the moment. It will be later I'm sure, so thanks for the hint .

One of the cores simply will stop processing the script when I switch to the other one, even with a simple two-rocket system on the launchpad.

Edit: Scratch that, freshly infused with coffee I just managed to launch both... some more investigation is required

Erm.... one other thing I noticed last night: There is no pow(double x, double y) function in kOS? At first I thought oh well I just use exp(y * ln(x)) but exp() is also not available. Am I missing something? I'm trying to implement atmospheric pressure at current altitude for a terminal velocity calculation. Back to spreadsheets, wikipedia and the ksp-wiki it seems...

[Joe32320]

You can just type x^y for powers (the power sign appears as an upwards arrow in the terminal though).

Also just for reference, the constant e can be got using "constant():e" should you ever need it