kOS Scriptable Autopilot System 0.9

[Payload]

I agree with razark. I think you aren't being sure to focus outside the program window. I specifically run AG checks in Until loops all the time. So that isn't the issue. You also might want to check your de-bouncing. I'm not sure toggling the AG again is doing what you think it is. It's just setting up a chain and running through your program.

You also didn't post what you are doing to end the loop. I don't see where you ever set x to 1. Seems to me like you might still have some errors in there also. You really should be careful of white space problems. I see places where you don't have a space after your terminator and before brackets. That may not be a problem, but this mod is young yet. I have been just writing ugly code until I am confident there are no white space problems. I see you have lots of extra spaces there too.

I am working on a missile. It does raise up and takeoff from the vehicle but now the problem is how to lock the steering towards the target. I will have to refresh my brain a little on math and physics to figure this one out or maybe not?

I'm pretty sure there is a way to lock the steering directly to your target.

set target to "Your Target". lock steering to target.

Should get it done. I wouldn't do it immediately though. I would wait until some altitude and then arc over and set the target and lock on.

Edited September 13, 2013 by Payload

[nothke]

I don't understand.. Whenever I press enter the program runs.. How do I go to a new line without running the program?? The readme doesn't mention anything about it. (or am I just stupid?)

[Devinci]

That's what I'm doing if you look at my code. I am waiting for 10 seconds then I wait for the altitude to be greater than the distance to the target. Then I lock the target. But I tried it just know and it crashed KSP, giving me some infinite results and NAN signs all over. Maybe you can't lock steering directly to target ?

Otherwise I am thinking of using the parabolic projectile physics problems I learned a long time ago to solve this. I remember doing problems where the projectile was launched from an inclined plane (for example the rocket does not need to point straight up at first).

correction: I will try the expression you used.

[Payload]

That's what I'm doing if you look at my code. I am waiting for 10 seconds then I wait for the altitude to be greater than the distance to the target. Then I lock the target. But I tried it just know and it crashed KSP, giving me some infinite results and NAN signs all over. Maybe you can't lock steering directly to target ?

Otherwise I am thinking of using the parabolic projectile physics problems I learned a long time ago to solve this. I remember doing problems where the projectile was launched from an inclined plane (for example the rocket does not need to point straight up at first).

correction: I will try the expression you used.

Ahh I see what I did there. I missed a space. The expression is in error. I'll fix it. Also if you watch the latest video, you will see how he sets target. He uses wheelsteering but just steering should work. If your KSP crashes then you have either a missing close quotation or a missing close parenthesis. Those are the known bugs so far. Maybe more things cause it. I don't know.

I don't understand.. Whenever I press enter the program runs.. How do I go to a new line without running the program?? The readme doesn't mention anything about it. (or am I just stupid?)

I'm not sure what you mean? If you don't want to run the program don't call it with run. Sounds to me like you are just typing things into the console. That works if you are just trying something but you need to actually edit a program. With the command edit myprogram. Whatever you call your program in the edit command is what the editor will name your new program.

Once you have a program ready to test, save it. Then you will need to copy it to the archive for storage using copy myprogram to archive. You guys really should watch the videos. If you had, you would have been aware of this stuff.

Edited September 13, 2013 by Payload

[Sma]

Mine stages based on amount of fuel. With boosters/asparagus stage, you have to stage, grab how much fuel is in the boosters, stage again and grab how much total you have, then subtract booster fuel from total stage fuel. When using asparagus staging, you do the same, except IIRC divide the booster fuel by how ever many asparagus stages you have. After the asparagus stages are done, then you just check for empty stages.

In my case, I use a while loop to check if the altitude is above i think 25,000. Inside of that I'm checking for the fuel levels, as well as altitude for gravity turn and trying to keep the speed around 200m/s until a certain altitude. Then I switch to one watching out for the AP, and then obviously PE. So far it works rather well, orbit looks mostly circular on the map, though AP and PE have a difference of nearly 100,000m I think it was. Haven't tried it with asparagus staging yet though, just normal liquid fuel staging where the 4 boosters fuel the center stage.

I'm hoping at some point we get input statements, then I could have my program ask for number of asparagus stages, desired AP/PE, and whatever else may be helpful.

I just got my launch program in a state I'm reasonably happy with. It controls pitch and throttle with a PID watching eta:apoapsis, and stages based on discontinuities in acceleration.

set targetapo to 90000.
set atmo_top to 68000.
set limitG to 1.5.

mode_pad on.
mode_stage off.
mode_launch off.
mode_limitG off.
mode_turn off.
mode_coast off.
mode_raise_ap off.
mode_raise_pe off.
mode_finish off.

set roll to 0-90.
set yaw to 0.
set pitch to 0.
set pitchmaxlimit to 0.1.

set tlimit to 1.
set Pthrottle to 0.01.
set Dthrottle to 0.
set errorT to 0.
set errorTD to 0.

set bstartalt to 1000.
set bendalt to 9000.
set bendpitch to (0-bendalt)/atmo_top.

set P to 0.01.
set I to 0.001.
set D to 0.1.

set error to 0.
set errorprev to 0.
set errorI to 0.
set errorD to 0.

set scalarvelocity to 0.
set prevV to 0.
set accel to 0.
set prevAccel to 0.
set jerk to 0.
set prev_throttle to 1.
set prev_epsilon to 0.

print "Liftoff".
set clock to 0.
lock steering to up.
sas on.
lock throttle to 1.
stage.
mode_pad off.
mode_launch on.
mode_limitG on.
wait until missiontime > 0.

until mode_finish {
	set deltatime to missiontime - clock.
	set clock to missiontime.
	set prevV to scalarvelocity.
	set prevAccel to accel.
	set scalarvelocity to (surfacespeed^2 + verticalspeed^2)^(0.5).
	set accel to (scalarvelocity - prevV) / deltatime.
	set jerk to (accel - prevAccel) / deltatime.
	set pitchlimit to (0-1) * (altitude/atmo_top).
	if pitchlimit < (0-1) { set pitchlimit to (0-1). }.

	if mode_launch {
		mode_stage on.
		if altitude > bstartalt {
			print "Static turn".
			mode_launch off.
			mode_turn on.
			sas off.
		}.
	}.

	if mode_stage {
		set accel_theoretical to ((maxthrust/mass)*throttle).
		set epsilon to accel_theoretical - accel.
		set throttlechange to accel * (throttle - prev_throttle).
		if (missiontime > 10) and (throttle > 0) and (throttlechange > -3) and (epsilon - prev_epsilon > 2.5) {
			print "Staging".
			stage.
		}.
		set prev_epsilon to epsilon.
		set prev_throttle to throttle.
	}.

	if mode_turn {
		set pitch to bendpitch * ((altitude-bstartalt)/(bendalt-bstartalt)).
		lock steering to up + r(yaw, 90*pitch, roll).
		if altitude > bendalt {
			print "Dynamic turn".
			mode_turn off.
			mode_coast on.
			mode_raise_ap on.
			mode_limitG off.
			lock throttle to 1.
			set startapo to apoapsis.
			set starteta to eta:apoapsis.
		}.
	}.

	if mode_limitG {
		set errorTprev to errorT.
		set errorT to (limitG*9.8) - (tlimit*accel).
		set errorTD to (errorT - errorTprev) / deltatime.
		set tlimit to tlimit + (Pthrottle*errorT) + (Dthrottle * errorTD).
		if tlimit > 1 { set tlimit to 1. }.
		lock throttle to tlimit.
	}.

	if mode_raise_ap {
		set etamargin to 15.
		set minthrust to 0.5.
		set tfudge to 0.1.
		if apoapsis > targetapo {
			print "Circularizing".
			mode_raise_ap off.
			mode_raise_pe on.
		}.
	}.

	if mode_raise_pe {
		set etamargin to 10.
		set minthrust to 0.
		set pitchmaxlimit to -1.
		set tfudge to 0.
		set I to 0.
		if periapsis > targetapo {
			mode_raise_pe off.
			mode_coast off.
			mode_finish on.
		}.
	}.

	if mode_coast {
		set targeteta to ((targetapo-apoapsis)/(targetapo-startapo)) * starteta.
		if targeteta < etamargin { set targeteta to etamargin. }.
		set eta to eta:apoapsis.
		if eta:periapsis < eta:apoapsis { set eta to 0. }.
		set errorprev to error.
		set error to targeteta - eta.
		set errorD to (error - errorprev) / deltatime.
		set errorI to errorI + (error * deltatime).
		if errorI > error { set errorI to error. }.
		set adjustment to (P*error) + (I*errorI) + (D*errorD).

		if (adjustment < 0) or (tlimit = 1) {
			set pitch to pitch + adjustment.
			if pitch < pitchlimit { set pitch to pitchlimit.  }.
			if pitch > pitchmaxlimit { set pitch to pitchmaxlimit. }.
			lock steering to up + r(yaw, 90*pitch, roll).
		}.
		if (pitch - pitchlimit < .03) or (adjustment > 0) {
			set tlimit to tlimit + adjustment.
		}.
		if (pitchlimit > 0-1) { set tlimit to tlimit + tfudge. }.
		if tlimit < minthrust { set tlimit to minthrust. }.
		if tlimit > 1 { set tlimit to 1. }.
		set tfinal to tlimit.
		lock throttle to tfinal.
	}.
}.

[Devinci]

I think the problem is that we don't have a Vector Target as we do for Prograde, Retrograde and UP when I looked on the manual.

Edited September 13, 2013 by Devinci

[aNewHope]

I have a problem with the coordinate system you are using. I am trying to program a cruise missile system, that can hit targets tens and hundreds of km away. The altitude control already works very well, but only either in the east-west or in the south-north direction.

lock throttle to 1.
set a to 20000.
set r to a*0.5.
stage.
until target:distance < 1.5 * a {
  set h to alt:radar.
  if h = -1 {set h to altitude.}.
  if h < (a-r) {set s to 0.}.
  if h > (a+r) {set s to 180.}.
  if h > (a-r) and h < (a+r) {
    set s to (h - a)/(r/90)+90.
  }.
lock steering to up+r(0,s,180).
}. 

(a: flight altitude; r: flight corridor width; h: real height; s: angle from up-direction)

But due to the fact, that both, the pitch and the yaw coordinate, are measuring a vertical angle, it is impossible to hold the altitude while flying in the target's direction. Unlike ordinary coordinate systems, which provide a horizontal angle and a vertical direction angle, your system doesn't allow easy height control.

I really like your mod and it opens up a lot of cool opportunities, but this really bugs me.

Edited September 13, 2013 by aNewHope

[Dunbaratu]

I think the problem is that we don't have a Vector Target as we do for Prograde, Retrograde and UP when who I looked on the manual.

That's correct. What the current "TARGET" direction means is basically the "purple" marker on the navball.

[Dunbaratu]

I have a problem with the coordinate system you are using. I am trying to program a cruise missile system, that can hit targets tens and hundreds of km away. The altitude control already works very well, but only either in the east-west or in the south-north direction.

lock throttle to 1.
set a to 20000.
set r to a*0.5.
stage.
until target:distance < 1.5 * a {
  set h to alt:radar.
  if h = -1 {set h to altitude.}.
  if h < (a-r) {set s to 0.}.
  if h > (a+r) {set s to 180.}.
  if h > (a-r) and h < (a+r) {
    set s to (h - a)/(r/90)+90.
  }.
lock steering to up+r(0,s,180).
}. 

(a: flight altitude; r: flight corridor width; h: real height; s: angle from up-direction)

But due to the fact, that both, the pitch and the yaw coordinate, are measuring a vertical angle, it is impossible to hold the altitude while flying in the target's direction. Unlike ordinary coordinate systems, which provide a horizontal angle and a vertical direction angle, your system doesn't allow easy height control.

I couldn't understand this either and finally wrapped my head around it with a lot of time on Wikipedia and a little peeking at the GitHub code. What it boils down to is that the rotations with R() aren't really rotations in this language. They're "Euler rotations" which aren't anything like what the English word "rotation" means. And the fact that they're "Euler rotations" was not documented in the readme, and it's NOT what a person would assume when told they're doing a "rotation".

Doing R(n,0,0) or R(0,n,0) or R(0,0,n) all work sensibly, but once you have two axes in there and try something like R(n,r,0) (which is identical to saying R(n,0,0) + R(0,r,0) ) it goes all wonky. And this is because it's not REALLY rotating space but rather is skewing space. Euler rotations are very much NOT rotations, by the normal English meaning of the word "rotate". If you draw a cube in orthogonal space, and then apply a 45 degree Euler "rotation" to that space, you don't end up with a cube rotated 45 degrees which is obviously what you'd picture in your head when you hear the word "rotate". Instead you end up with a cube that got warped into a skewed shape with stretched parallelogram-shaped sides instead of square-shaped sides. Euler "rotations" don't rotate space, they skew it. They end up only rotating only one axis at a time while leaving the other two axes fixed where they were, resulting in a non-orthogonal coordinate system.

This is what the R() system is doing to the coordinate axes, and this is why the rotations don't make any sense once you try to do more than one of the three axes. The second "rotation" ends up happening in that skewed coordinate space that the first "rotation" set up.

I would love it if the R() system used proper ordinary rotation of all the axes as an orthogonal set (Intrinsic rotation). (You can't get gimbal lock if you keep the axes orthogonal by rotating the entire grid.)

I really like your mod and it opens up a lot of cool opportunities, but this really bugs me.

I agree. If the goal was to make the language accessible to the everyman, then the decision to use Euler rotations was definitely not the way to go. Most people are going to have a picture in their head that looks nothing like what a Euler rotation does when they hear the word "rotation". It's not intuitive.

[Dunbaratu]

Has anyone else seen this problem?

It has to do with the COPY command.

Some of my programs can be copied in the "to" direction but not the "from" direction (making updating them on a remote probe impossible).

Here's an example:

This fails:

switch to 1.
copy hover from archive.
File copy failed

When at the VERY same time, this works:

switch to archive.
copy hover to 1.
switch to 1.

And it's not consistent. Its only some files that fail. Some files work so I know the probe can get to the archive to copy. In fact, this problem happens even when sitting on the launchpad at Kerbin so it's not a range issue. It's making it impossible to update the software on my remote probes because they can only copy software by issuing a COPY ... FROM command while in their local volume, and can't do a COPY...TO it while in the archive because they can't switch to archive.

[Gaius]

I'd be happy with a simple heading, attitude, bank rotation (aka "yaw, pitch, roll"). I guess the technical term for this is Tait-Bryan rotation? Anyhow, that's always seemed intuitive to me.

[Apollo13]

This is from Kevin's 10 Sept Dev Blog:

The current system of steering craft sucks.

But I did have the best of intentions. My thinking in the beginning was "somebody is going to want to move around with respect to a target, such as when docking, or transiting to another planet". In other words, the user should be able to set the reference with which they are describing a rotation in respect to. That's why you use UP, because that's a reference that's in respect to your body of influence.

However when people first pick up the mod, they're expecting to punch in coordinates right off the navball, and rightly so. 99% of the time you are going to be interacting with reference to your body of influence. And more and more I'm thinking this is one of the last barriers to having a really accessible system.

But my above concerns may still prove valid later on. So should I have two syntaxes?

Well R(,,) is horrendous as an english-readable syntax so yes, this is the perfect opportunity to introduce a second syntax that takes in:

•A simple heading with North being zero and South being 180, just like on the navball

•A pitch where zero is the horizon, 90 is straight up and -90 is straight down, just like on the navball

•An optional roll that is applied last instead of first

... all while being more english-like than R(), which can be left for advanced users (or for more complicated situations).

Edited September 13, 2013 by Apollo13

[Dunbaratu]

I'd be happy with a simple heading, attitude, bank rotation (aka "yaw, pitch, roll"). I guess the technical term for this is Tait-Bryan rotation? Anyhow, that's always seemed intuitive to me.

Yeah. Although the components of the R() vectors are NAMED "yaw", "pitch", and "roll", once you combine more than one of them together they're not QUITE the same thing as aircraft yaw, pitch, and roll.

[Dunbaratu]

This is from Kevin's 10 Sept Dev Blog:

While this does SORT of address the problem by giving people a way to avoid using the current R() system, the real problem isn't that rotations are confusing. They're not. The problem is that EULER rotations are confusing. Intuitively you'd expect the R() tuple to give you an orthogonal rotation, not a Euler one. It's the TYPE of rotation it gives you that's confusing, not that rotations in general are confusing.

[Dunbaratu]

Has anyone else seen this problem?

It has to do with the COPY command.

[ ... ]

I figured it out, again by reading the GitHub code because the error message itself wasn't describing the problem, and the problem was a completely undocumented (as far as I can tell) fact that's REALLY important for the end user to know about:

That undocumented fact is:

* The archive has unlimited capacity, but any volumes other than the archive have only a limited capacity of 10,000 bytes per volume.

If you try to copy a file FROM archive to the current volume it will check against this capacity and refuse the copy (without explaining why) if it would exceed the limit of 10,000.

Weirdly it's only checked in the FROM direction and not the TO direction. So it's possible to overload a probe with more than 10000 bytes of code on the launchpad by copying from the archive to the volume and not realize you'd filled it beyond capacity. Then later after it's launched and you're far enough away that you have to copy FROM the archive rather than copy TO the volume, you can't alter any of the software with a new update because THEN the check is being done when it wasn't before.

[BGog42]

Kevin, Did you see the pull request I sent on github. I added a logging feature and have been using it to generate realtime graphs etc, very useful.

Take it or leave it. I just want to make sure you saw it was there.

[MorroW]

How to write programs outside KSP?

And how to figure out where I have to make/keep current programs so I don't loose them during "Revert to lauch" etc?

I seems to missing some very basic know-how about that mod...can someone direct me to some wiki/readme besides https://github.com/Nivekk/KOS/blob/master/README.md

[Dunbaratu]

How to write programs outside KSP?

And how to figure out where I have to make/keep current programs so I don't loose them during "Revert to lauch" etc?

I seems to missing some very basic know-how about that mod...can someone direct me to some wiki/readme besides https://github.com/Nivekk/KOS/blob/master/README.md

There's two different questions here - I'll address them seperately:

1 - How to edit programs outside of KSP:

The plugin stores the master archive programs outside the saved game files. They're stored in the plugin's directory, here:

Kerbal Space Program/Plugins/PluginData/Archive/

If you have a program called 'myprog" in the archive, there will be a text file for it called:

Kerbal Space Program/Plugins/PluginData/Archive/myprog.txt

There is a one-to-one mapping between files in that folder and files in the in-game archive, so you can edit a file in a separate text editor and store it there, and it will appear in kOS right away in its archive volume.

2 - How to keep programs saved when reverting the flight:

Anything in the volumes that are NOT called "archive" exist only on the vessel itself. (They're stored inside the persistent file in the save folder). Only the things in the archive folder exist outside of any specific vessel. To save a program between flights, just make sure you've put it into the archive volume.

They way you're meant to use it is that you build up a library of several little programs and store them in the archive volume, and then when launching a ship you first copy the ones that ship will need to its own volume before launching it. The archive is the master copy of the program in the mission control's mainframe.

There's a wiki about them here - this page was just written earlier this afternoon: http://kos.wikia.com/wiki/Archives_and_Volumes

Edited September 14, 2013 by Steven Mading

[CoriW]

Just to be sure, do you have the terminal window in focus when testing this?

I did not have the terminal window in focus, I can confirm that the actiongroup was being fired every time.

However if the ON AGX statement was inside the UNTIL loop it would not trigger within the script, I believe that this is being caused by the UNTIL loop "missing" the actiongroup triggering. Since an UNTIL loop seems to only go through about once per second, if the actiongroup is triggered before or after the loop reads the ON AGX statement it seems that it will not actually recognize that it has been triggered. That all being said I have still not been able to successfully use ON AGX within an UNTIL loop. (Even if I spam the actiongroup.)

And of course, if the ON AGX statement came before the UNTIL loop, it would read that the actiongroup was triggered, but seems to immediately cancel the UNTIL loop.

Then finally, if the ON AGX statement came after the UNTIL loop, the ON AGX statement would never even be read because of the UNTIL loop.

Edited September 14, 2013 by CoriW

[Payload]

It works just fine on my end.

set selection to 0.
set flagup to 0.
set flagdown to 0.
set confirm to 0.

until selection = 1
 {
on ag9 set flagup to 1.
on ag8 set flagdown to 1.
on ag7 set confirm to 1.

 if flagup = 1
 {
 clearscreen.
 print "Flagup!".
 toggle ag9.
 set flagup to 0.
 }.

 if flagdown = 1
 {
 clearscreen.
 print "Flagdown!".
 toggle ag8.
 set flagdown to 0.
 }.

 if confirm = 1
 {
 clearscreen.
 print "Exit Success!".
 toggle ag7.
 set confirm to 0.
 wait 2.
 set selection to 1.
 }.
 }.

[GavinZac]

Is anyone else having issues with "break." causing code error?

I am, strangely after quite a while:

UNTIL APOAPSIS > tApoapsis {
  SET gtPitch TO gtPitch-5.

  //bit that works, gently tilting the craft towards horizon.

  PRINT "stability check".

  // syntax error after this somewhere, as it prints the stability check line.

  IF horizon > gtpitch-1 {
    PRINT "Horizon Reached!".
    BREAK.
  }.

  SET lastAlt TO lastAlt+1000.
}.

[Dunbaratu]

I too had a syntax error on "break." start happening where it was fine before. But luckily its at a spot in the code where the loop in question happened to be the last thing in the program so the break was there to end the program anyway, so it didn't harm the logic. BUT, if it happened on any loop that wasn't the last thing in the program, and there were important statements that came after that loop, then it would be fatal to that program's logic that "break." started causing syntax error.

[MorroW]

1)

Is there a way to limit character count on flight statistics results?

For example I get speed reading as "24.69483", but it would be enough to get just "24".

Altitude, target distance etc have same "issue".

print surfacespeed at (30,6). Print "Km/h:" at (25,6).

2)

Any way to drive rovers via coordinates? For example if I want to visit -0.6402 : -80.7668 anomaly.

If not, any samples how to set up bearing/heading for it?

[nothke]

I'm not sure what you mean? If you don't want to run the program don't call it with run. Sounds to me like you are just typing things into the console. That works if you are just trying something but you need to actually edit a program. With the command edit myprogram. Whatever you call your program in the edit command is what the editor will name your new program.

Once you have a program ready to test, save it. Then you will need to copy it to the archive for storage using copy myprogram to archive. You guys really should watch the videos. If you had, you would have been aware of this stuff.

Ahaha lol. This was such a stupid mistake. When I watched the introduction videos I missed the beginning where you actually write like "edit program1", so I didn't know that the "console" and "edit script" windows are actually 2 different things xD ok... and I didn't see this mentioned in the readme.

OK now, I don't get this.. I am trying to make my space station always face UP and if I make a program with "lock steering to UP." the station starts constantly spinning indefinitely.. Adding R(...) or V(0,1,0) doesn't do anything either...

also, is there a way to check if SAS or RCS are on?

[razark]

also, is there a way to check if SAS or RCS are on?

until 0 {
  if RCS { print "RCS on." }.
  if SAS { print "SAS on." }.
  wait 1.
  clearscreen.
}.

This works, so yes.