kOS Scriptable Autopilot System 0.9

[TelluriumCrystal]

This is it. This is what autopilot in KSP should be. I have finally found the mod that implements the fairest and funnest method possible of performing an automated mission!

Thank you for creating what is, in my opinion, the greatest mod in KSP. Good day.

[ANWRocketMan]

@Sma: Ah, ok. I haven't seen it save new volumes., So I guess it's not so much to load the programs from Archive at launch.

On another point: WHat function/variable should I call to get the current pitch and heading values? For example, if I have set my steering to an R(0,70,180) degrees, how can I check whether the rocket is now pointing in that direction? I want to halt the execution of my programme until that is met. I'm using FAR and Real Size Kerbin so I have to do a very gradual gravity turn or I will flip out.

in addition, i'm writing a launch programme that has the inputs of what inclination and orbital altitude you want to launch to. It limits your acceleration to a value you want and starts the gravity turn at a specified altitude. I'm busy writing the method to also check that the TWR is high enough to sustain the current pitch, and adjust the thrust and/or pitch to compensate for it. I will let you know how that goes.

@ThrFoot: I absolutely agree! It's amazing!

[Dunbaratu]

On another point: WHat function/variable should I call to get the current pitch and heading values? For example, if I have set my steering to an R(0,70,180) degrees, how can I check whether the rocket is now pointing in that direction?

STEERING is an R() tuple that defines the direction you are telling the ship to point, and

FACING is an R() tuple that shows the direction the ship is currently pointing.

So, after setting STEERING to R(a,b,c), then you can test for how much FACING:yaw differs from a, and FACING:pitch from b, and FACING:roll from c to see if they're getting close to lined up yet or not.

One warning, the rotations are not reliably always mapped down to numbers between 0 and 360. In other words, sometimes a rotation that's really 15 degrees will be reported as 375 instead, which is the same compass point, but if you just compare the raw numbers it looks like it's really far off. So remember to take the values MOD 360. Also, remember that values that are, say, different by 350 are really different by only 10 (i.e. 355 degrees versus 5 degrees).

What I've resorted to now to cover all those cases is to just take the sin and cosine of the angles and compare that instead of the angles themselves. That way, for example, if sin(theta) and sin(gamma) are close to each other, and cos(theta) and cos(gamma) are close to each other, then that tells you that angles theta and gamma are close to each other, no mater how they're expressed. That way you get the same result if an angle is expressed as -5, or 355, or 715, and so on, all of which are really the same thing.

[ANWRocketMan]

Hmm, yes. Should work. Thank you.

Does MaxThrust return a value in kN or N? Or is there another method to retrieve the current thrust besides (MAXTHRUST * THROTTLE)?

I'm using this check to see if my effective vertical thrust exceeds the gravitational pull on the rocket:

IF MAXTHRUST*THROTTLE*SIN(FACING:PITCH) > (MASS*gravitational acceleration)/1000 AND
{
//Decrease pitch(must not exceed 4 degree change as this will cause the rocket to flip out)/thrust(if thrust exceeds MaxG) so that you have a ratio of horizontal to vertical thrust of at least 1.5.
}

This is run within an additional loop that checks every 0.1 seconds and does certain things to prevent the exceeding of MaxG and checks whether apoapsis is reached. It also stages the rocket(problem: I'm using MFT and Realistic Fuels). I want to add code to check for launch irregularities(too large facing change since last tick or loss of thrust[unless while staging]) and activate the abort sequence. NOTE: I haven't tested it yet!

BTW, how do get the return value for the current gravitational acceleration? Can I get this from an Accelerometer?

Edited November 7, 2013 by ANWRocketMan

[Sacred Aardvark]

When KOS tells you there's an error on a line number, the line number it reports to you is often utterly wrong, especially if it's saying line number 0. Just because it says line 0 doesn't mean it really is line 0. It could be anywhere in the program.

Based on my experience, not anywhere. If it says error on line 1 for example, the error can be on the second line of the program OR the second line of Any Loop in the program.

In the case in question it's probably referring to the line 0 of this loop which is missing a THEN on the initialization of the loop:

when altitude > 500 { // <-line 0, lack of then
  lock pVal to -1*(1.25*(altitude/1000)+(45*(apoapsis/Final)^2)).  // <- line 1, etc
  lock steering to up + R(0,0,180) + R(0,pVal,0). 
}.

In 0.7 I believe an error inside a loop gave the line number of the closing brace of the lowest(highest?) level loop in which the error occurred, which was nice, unless you had the entire program in an until loop and it said the error was on the last line of the program, when it really could be -anywhere-, at least these days we have somewhat clearer picture, instead of "it's somewhere in -this- loop" we get "it's on -this line- in *some* loop". Hardly specific, but it does point you in a vaguely right way, usually. /shrug

Edited November 7, 2013 by Sacred Aardvark
formatting, typos and grammar and bleep

[Dunbaratu]

In 0.7 I believe an error inside a loop gave the line number of the closing brace of the lowest(highest?) level loop in which the error occurred, which was nice, unless you had the entire program in an until loop and it said the error was on the last line of the program, when it really could be -anywhere-, at least these days we have somewhat clearer picture, instead of "it's somewhere in -this- loop" we get "it's on -this line- in *some* loop". Hardly specific, but it does point you in a vaguely right way, usually. /shrug

I have yet to see the line number reported as anything other than zero. Ever.

[ANWRocketMan]

I've noticed several non-zero line numbers so far. But only when using a loop. It seems to reset the line counter with every execution of the loop, so as @SacredAarvark said, it gives the line of the error WITHIN a loop, not within the program. It seems that if the error is not in a loop: Line 0. Every time.

[AbeS]

When I had that missing 'then' problem, because it said Error on line 0 y wrote a comment on line 0 and the first code moved to line 2, and the Error started saying on line 2.

[Sacred Aardvark]

I have yet to see the line number reported as anything other than zero. Ever.

Mine tend to be on line 2, occasionally 0, have had couple others at times, but mostly 2 or 0.

When I had that missing 'then' problem, because it said Error on line 0 y wrote a comment on line 0 and the first code moved to line 2, and the Error started saying on line 2.

Yeah, it does that, not a damn clue why though(okay it's bugged but still), but that result doesn't make any sense under my current theory (well, hypothesis, it's hardly verified), even though I can replicate it (sometimes) :|

[Dunbaratu]

What I would find really helpful, and it really seems quite realistic to me to enable it, would be a variant of ALT:RADAR that tells you the distance from your craft to the ground in the direction your craft is pointed rather than straight down. In other words, if you are aimed 45 degrees off from "up", then don't report the altitude below the craft, but rather report the distance to the ground in that 45 degree angle. The diagram below shows what I'm talking about. Getting the radar distance along that blue line in my picture is what I'm talking about.

It makes sense that the radar distance measuring equipment would actually rotate with the craft and give the blue result rather than the green one. And that data is crucial to making a working landing script that can react to unknown landing sites at unknown locations.

Because of the inability to read the terrain, I can't really do a "suicide burn" efficient landing because of the case illustrated in that picture. I end up having to guess what the highest ground MIGHT be based on the wiki entry for the body (all the bodies tell you the max elevation of the highest mountain on that body), and design the suicide burn to "land" at that height first, and then descend from there down to the ground. On rocky bumpy bodies like The Mun, that's an enormous amount of error I have to account for.

[Eadrom]

how well does kOS play with MechJeb? I'm not looking to actively use both at the same time, obviously. Just wanted to know if anyone has had any problems with both of them installed at the same time. I'd like to be able to play around with kOS in my current save. The mod looks awesome!

[FellipeC]

how well does kOS play with MechJeb? I'm not looking to actively use both at the same time, obviously. Just wanted to know if anyone has had any problems with both of them installed at the same time. I'd like to be able to play around with kOS in my current save. The mod looks awesome!

I had no problems

[aNewHope]

What I would find really helpful, and it really seems quite realistic to me to enable it, would be a variant of ALT:RADAR that tells you the distance from your craft to the ground in the direction your craft is pointed rather than straight down. In other words, if you are aimed 45 degrees off from "up", then don't report the altitude below the craft, but rather report the distance to the ground in that 45 degree angle. The diagram below shows what I'm talking about. Getting the radar distance along that blue line in my picture is what I'm talking about.

That's an awesome picture and your idea is very good as well. If that would get implemented (maybe along with ordinary alt:radar) it would solve most of my automated landing problems.

But I guess that the issue with this feature is, that the current alt:radar is simply putting out the radar altitude that is provided by KSP itself (you can see it in IVA). Probably it's way harder to get the radar distance you are talking about.

[ANWRocketMan]

It might be possible to do a raycast straight out the back and use that to determine the distance.

[Camacha]

That's an awesome picture and your idea is very good as well. If that would get implemented (maybe along with ordinary alt:radar) it would solve most of my automated landing problems.

Without the ordinart alt:radar you would still have a lot of trouble. Landing properly on the purple line where the mountain starts is not going to end well - for obvious reasons. Unless we develop some gecko like landing feet of course.

[Dunbaratu]

Without the ordinart alt:radar you would still have a lot of trouble. Landing properly on the purple line where the mountain starts is not going to end well - for obvious reasons. Unless we develop some gecko like landing feet of course.

Too many people have already written scripts expecting alt:radar to work like it does now, so I don't think changing it is a good idea at this stage. But I do advocate making a second type of radar altimeter for this purpose.

I've been thinking more and more about this and what would provide a good solution without just having the mod hand us all the terrain information on a silver platter (after all KOS is NOT meant to be mechjeb - we're supposed to do a portion of the autopilot logic ourselves and that means only being able to "know" what the vessel knows). I first described the idea of the craft having a radar altimeter that's fixed in place on the craft itself and thus it rotates with the craft's facing. If we want to aim it in a different direction we have to rotate the craft to do it. I'm not so sure now that this is the right answer because of spaceplanes.

With a retro-rocket lander, the engineers would have installed the radar altimeter hardcoded to aim 180 degrees off from the facing (When landing, the craft's facing points at the sky). But for a space plane, they would have installed the radar altimeter hardcoded to aim 90 degrees off from the facing (when landing the craft's facing is horizontal, not toward the sky). That one problem means it would be unfair for the KOS mod to pick one hardcoded direction relative to the facing and call that the direction of this altimeter's aim. That hardcoded direction would either favor spaceplanes and not work for landers, or favor landers and not work for spaceplanes. It can't be made to be correct for both if it's hardcoded.

If the altimeter were a new kind of vessel part, then the player could pick its direction when attaching it to the craft and the mod could read the part's orientation to decide which way its radar is aiming. But I have no idea how to make a part and add it to the game.

So maybe the only real workable solution would be to let the player pick the direction of this radar in the script.

I propose something like this:

lock radardirect to (whatever).
print "directional radar altitude is " + alt:direct.

where "(whatever)" is any of the of usual ways to aim things in KOS script, an R(), a Q(), a vector, etc.

i.e. To make it behave like the blue line in my diagram:

lock mybottom to facing + R(0,180,0).

lock radardirect to mybottom.

or, to make it behave like the a clone of the normal old-school alt:radar:

lock down to up + R(0,180,0).

lock radardirect to down.

A clever script writer could actually implement a radar "sweep" this way by successively moving the radar direction, and get an idea of the terrain in a patch of the ground.

As far as implementing it, I believe ANWRocketMan is right - Presumably the KSP API knows where the ground terrain is and provides a way for a mod writer to find it, and getting the intersect of a ray and the ground should be doable.

Edited November 7, 2013 by Steven Mading

[balu0]

I might have found a nasty bug or I'm just missing something :

her is a code:

blah blah...

until x = 0 {

	clearscreen.

	//real time controls
	on ag1 set Setpoint to 100.
	on ag2 set Setpoint to 200.
	on ag3 set kp to kp + 1.
	on ag4 set kp to kp - 1.
	on ag5 set ki to ki + 1.
	on ag6 set ki to ki - 1.
	on ag7 set kd to kd + 1.
	on ag8 set kd to kd - 1.

	print "Setpoint:" + Setpoint + "   " at (10,4).
	print "kp:" + kp + "   " at (10,5).
	print "ki:" + ki + "   " at (20,5).
	print "kd:" + kd + "   " at (30,5).
}

blah balh..

now what happens is strange. ag1 and ag2 works just fine, but ag3 and 4 for example gives back stupid numbers, like -11 then 64 and other random numbers.

what I want to do here is simple increment a variable with pushing a action group button.

Bug or Im missing something ?

Edit: what I think is happening is that the action group command gets sent several times with only 1 key press.

Edited November 7, 2013 by balu0

[Dunbaratu]

Edit: what I think is happening is that the action group command gets sent several times with only 1 key press.

Correct.

Let me describe it for just the case of ag3 - the same thing happens with all the other action groups ones too:

Each time the statement "on ag3 set kp to kp + 1." runs, it inserts a NEW event hook into the list of things the KOS computer watches for and it doesn't clear out the old one. So the first time the UNTIL loops runs, there's one instance of looking for ag3 to happen and if it happens to run 'set kp to kp + 1." The second time, there's now two of them, then three, then four, and so on.

iF the loop has run 30 times before you press ag3, then all 30 of those hooks get fired off at once, and then kp has been incremented 30 times.

If you want to use "on" like this, you have to protect it with a check to see if it's really necessary to insert yet another hook. Basically, only run the "on' command if it got triggered last time. If it hasn't been triggered yet, then just rely on the previous one that's still there.

needAg3Hook on.
until ... etc ... {
  if needAg3Hook {
    needAg3Hook off.
    on ag3 {
      ... do your normal thing here (i.e. "set kp to kp + 1.") ...
      needAg3Hook on.
  }.
}.

Each time it runs through the loop, if only inserts a new "on ag3" command if needAg3Hook is true, which it only will be if the previous "on ag3" has been executed after it was set up.

You basically need to do that thing for all the "on" commands you're using (not just ag3) , if you're going to do it this way.

KOS script could really use some other form of input besides this. The need to protect the hook insertions like this makes it impractical, and using action groups for this gets in the way of using them for what they're meant for.

Just a simple "readline" would be a handy addition, even if it's blocking and line-at-a-time.

[balu0]

Thank you for confirming it. I come up with this workaround:

until x = 0 {

	//real time controls
	on ag1 set agHook to 1.
	on ag2 set agHook to 2.
	on ag3 set agHook to 3.
	on ag4 set agHook to 4.
	on ag5 set agHook to 5.
	on ag6 set agHook to 6.
	on ag7 set agHook to 7.
	on ag8 set agHook to 8.

	if agHook = 1 {set Setpoint to 100. set agHook to 0.}.
	if agHook = 2 {set Setpoint to 200. set agHook to 0.}.
	if agHook = 3 {set kp to kp + 0.1. set agHook to 0.}.
	if agHook = 4 {set kp to kp - 0.1. set agHook to 0.}.
	if agHook = 5 {set ki to ki + 0.1. set agHook to 0.}.
	if agHook = 6 {set ki to ki - 0.1. set agHook to 0.}.
	if agHook = 7 {set kd to kd + 0.1. set agHook to 0.}.
	if agHook = 8 {set kd to kd - 0.1. set agHook to 0.}.

	print "Setpoint:" + Setpoint + "   " at (10,4).
	print "kp:" + kp + "   " at (10,5).
	print "ki:" + ki + "   " at (20,5).
	print "kd:" + kd + "   " at (30,5).
}.

Works perfectly

ty

Edit : not that perfect its killing my fps, but it is only for testing some formulas, it will do ...

Edited November 7, 2013 by balu0

[Dunbaratu]

Thank you for confirming it. I come up with this workaround:

until x = 0 {

	//real time controls
	on ag1 set agHook to 1.
	on ag2 set agHook to 2.
	on ag3 set agHook to 3.
	on ag4 set agHook to 4.
	on ag5 set agHook to 5.
	on ag6 set agHook to 6.
	on ag7 set agHook to 7.
	on ag8 set agHook to 8.

	if agHook = 1 {set Setpoint to 100. set agHook to 0.}.
	if agHook = 2 {set Setpoint to 200. set agHook to 0.}.
	if agHook = 3 {set kp to kp + 0.1. set agHook to 0.}.
	if agHook = 4 {set kp to kp - 0.1. set agHook to 0.}.
	if agHook = 5 {set ki to ki + 0.1. set agHook to 0.}.
	if agHook = 6 {set ki to ki - 0.1. set agHook to 0.}.
	if agHook = 7 {set kd to kd + 0.1. set agHook to 0.}.
	if agHook = 8 {set kd to kd - 0.1. set agHook to 0.}.

	print "Setpoint:" + Setpoint + "   " at (10,4).
	print "kp:" + kp + "   " at (10,5).
	print "ki:" + ki + "   " at (20,5).
	print "kd:" + kd + "   " at (30,5).
}.

Works perfectly

ty

Edit : not that perfect its killing my fps, but it is only for testing some formulas, it will do ...

You're still inserting the hooks, even though they all do the same thing. Now instead of saying "set kp to kp + 1" 30 times, for example, you're now saying "set agHook to 3." 30 times.

That fixes the logic problem of doing the thing many times, but not the performance problem of doing it many times.

[Camacha]

I've been thinking more and more about this and what would provide a good solution without just having the mod hand us all the terrain information on a silver platter (after all KOS is NOT meant to be mechjeb - we're supposed to do a portion of the autopilot logic ourselves and that means only being able to "know" what the vessel knows). I first described the idea of the craft having a radar altimeter that's fixed in place on the craft itself and thus it rotates with the craft's facing. If we want to aim it in a different direction we have to rotate the craft to do it. I'm not so sure now that this is the right answer because of spaceplanes.

I would love separate sensors, that can be added and removed in the VAB. As parts. This would feel a lot like proper engineering (determining data required and equipping the spacecraft accordingly) and would open up the game to a whole series of new sensors. RADAR, LIDAR, SONAR, weight detection et cetera.

[Kethevin]

Hi. I have a couple questions I hope I can get help with.

1) Around the time of the new update, I've noticed keystrokes aren't confined to kOS. For instance, when I type inside the terminal, if I hit space a stage happens, if I use the letter "b" breaks come on/off. I'm not sure if I need to adjust a setting or of there is a command that corrects that.

2) I asked this earlier, but didn't see an answer. I'm sincerely curious what the difference is between "lock steering to up + R(0,0,180) + R(0,-60,0)" and "lock steering to up + R(0,-60,180)"

Thank you in advance for your answers. :-)

[a1270]

@Kethevin Are you using RemoteTech2 or Kerbal multiplayer? Both of those are known to mess with input locks kOS sets.

[Kethevin]

RemoteTech2, yep. I didn't notice it before but I did have kOS longer than RemoteTech2, so that must be it! :-(

Sorry about that, I didn't think of a mod conflict, I figured I accidently changed a setting or something.

[Kethevin]

Another quick question along with the unanswered one above if I might.

I'm trying to set up a rover program. I've watched the videos, but I cannot get steering commands to work. The probe is facing up, the video said up or forward work. I've tried "lock steering to heading 100 by 90.", "lock steering to heading 100 by 0.", I repeated those with "lock wheelsteering" and just "lock heading" type commands.

It DOES work if I face the probe forward so the navball shows a horizon rather than all blue sky, so I'm wondering if it requires a different format in the command line.