[1.3] kOS Scriptable Autopilot System v1.1.3.0

[mhoram]

I want to understand how the internal coordinate system of KSP works and since there is already a bit of documentation in the kOS Wiki

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

http://kos.wikia.com/wiki/Tutorial_with_example_-_Conversion_from_Directions_to_XYZs

I thought, this thread might be a fitting place to ask.

It would be a great help, if someone could point me to additional documentation on this subject.

Digging into the kOS source code is kind of a last resort, which I would rather avoid.

Edited October 12, 2014 by mhoram

[TDW]

Aaaarg! Now I got it working, but it ends after the first staging event! (launch event) throttle back. Here's the code:

The reason your script is ending having only done the first when trigger is because when (and on) don't need to be completed for the script to end, they are interrupts but the script finishes before they are triggered. Your script will continue indefinitely (until you press Ctrl+C) if you add a dummy wait at the end eg. WAIT UNTIL 1>2. that will prevent your script from ending and as long as it is still going then the interrupts can be triggered.

It may be better though to use something other than WHEN to throttle back your ship.

[Whirligig Girl]

It even stops after staging event when I remove the throttleback. But what would otherwise be used to throttle back?

EDIT: I tried WAIT UNTIL 1>2., and at first glance it seems to not end, but then the program does not actually continue.

Edited October 12, 2014 by GregroxMun

[Camacha]

It even stops after staging event when I remove the throttleback. But what would otherwise be used to throttle back?

That's not the issue. There is nothing to keep your script from ending, so it ends. When does something else than until and while. Those last two loop the script, the first one will only be triggered when the situation occurs but will be passed over until then. Since there is nothing more to run, the script ends.

Edited October 20, 2014 by Camacha

[Whirligig Girl]

I am feeling quite proud of myself.

print "Initiating SRB.txt Script.".
wait 2.
print "SRB AUTOPILOT LOADED!".
wait 2.
toggle SAS.
wait 1.
print "Preparations complete. Attempting to Launch.".
lock throttle to 1.0.
stage.
when ship:surfacespeed >3 then print "Launched successfully.".
when stage:solidfuel <0.01 then {print "Staging Booster.". stage.}.
when stage:solidfuel <0.001 then {print "Staging Separatron Ring.". stage.}.
when ship:verticalspeed <0 then {print "deploying parachute device.". stage.}.
wait until 1>2.

It works! It launches an SRB ship, then it stages a separatron ring, then when the ship falls it deploys the parachute.

[erendrake]

I am feeling quite proud of myself.

print "Initiating SRB.txt Script.".
wait 2.
print "SRB AUTOPILOT LOADED!".
wait 2.
toggle SAS.
wait 1.
print "Preparations complete. Attempting to Launch.".
lock throttle to 1.0.
stage.
when ship:surfacespeed >3 then print "Launched successfully.".
when stage:solidfuel <0.01 then {print "Staging Booster.". stage.}.
when stage:solidfuel <0.001 then {print "Staging Separatron Ring.". stage.}.
when ship:verticalspeed <0 then {print "deploying parachute device.". stage.}.
wait until 1>2.

It works! It launches an SRB ship, then it stages a separatron ring, then when the ship falls it deploys the parachute.

That is pretty cool! please keep us up to date on your progress and ask questions.

[erendrake]

I want to understand how the internal coordinate system of KSP works and since there is already a bit of documentation in the kOS Wiki

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

http://kos.wikia.com/wiki/Tutorial_with_example_-_Conversion_from_Directions_to_XYZs

I thought, this thread might be a fitting place to ask.

It would be a great help, if someone could point me to additional documentation on this subject.

Digging into the kOS source code is kind of a last resort, which I would rather avoid.

I think that the best way to learn about the KSP coordinate system is to play with the kOS's VECDRAW system

http://ksp-kos.github.io/KOS_DOC/structure/vecdraw/index.html

let us know if you have any questions. Here is a great place to ask.

[Whirligig Girl]

My next goal is to manuver a ship to get to orbit. Is that an overambitious goal? If so, what do you think i should try next?

[Camacha]

My next goal is to manuver a ship to get to orbit. Is that an overambitious goal? If so, what do you think i should try next?

Go for it. Getting up there should be doable, but being accurate is a bit harder.

[Lilleman]

It is doable, but be prepared to lose dozens of Kerbals during tests.

The link show an old version of my kOS autopilot script. Some tweaks have been made since, and I still have to make scripts for interplanetary transfers, rendez-vous and docking. For now it's made of 56 differents files.

The recent DeadlyReentry update broke my landing script, though. I'll have to set new values for the chutes opening.

Anyway, every maneuver can be done with kOS.

[Dunbaratu]

Is there a way of doing operations on strings? Looking for certain phrases or combinations of letters, cutting off the beginning or the end, that kind of stuff? For as far as I can tell this is only possible with numbers, not with strings. Is that right?

No, but now that we have worked on making suffixes that behave like methods (you can pass them arguments) it should now be possible to open up wrappers around the standard string manipulators soon.

[S1gmoid]

Hey guys... What's up with vectors now? I've seen some mentions about breaking changes to the positioning system in the changelog...

Anyway, are there any plans (planned or finished) to introduce a "cooked" positioning system instead of just exposing the internals of KSP with regards to coordinates, as explained here?

It really doesn't sound like the sort of calculation you'd want in a scriptfile, for performance and readability reasons.

Of course, changing the way coordinates work would break old scripts, but it could be made switchable. I'm actually tempted to fiddle around the source and see if I can do something in this regard if it hasn't been done by someone else.

Stuff I think would be nice:

* Both velocity and position vectors relative to the vessel / controlling part.

* Directions always fixed to 0 longitude (as opposed to KSP internal XYZ), regardless of vessel height. EDIT: Or possibly to current vessel heading, or a fixed stellar navigational sphere as used in real life space travel, based on constellations (ie. "the firmament").

* UP to mean "direction of the normal vector of the SOI planet's surface at the longitude and latitude of the vessel, with the topside of the vessel pointing West".

* NORTH and EAST defined similarly as directions on the horizon. Maybe DOWN, WEST and SOUTH too.

Edited October 13, 2014 by S1gmoid

[Dunbaratu]

Hey guys... What's up with vectors now? I've seen some mentions about breaking changes to the positioning system in the changelog...

Anyway, are there any plans (planned or finished) to introduce a "cooked" positioning system instead of just exposing the internals of KSP with regards to coordinates, as explained here?

This URL had some ideas I had a long time ago, but there have always been bigger things to do taking up my limited time developing kOS that kept putting it off:

https://github.com/KSP-KOS/KOS/issues/106#issuecomment-43851394

If you're curious as to how to take any raw vector and get what it's 3 coord components would have been in a different basis system, remember that you can always do this with just dot products. Build the 3 basis unit vectors in raw coords, then to get a raw coords vector's component in that basis direction, just dot-product it with that basis vector.

This video describes that process in more detail starting at about 2 min, 30 seconds into the video:

It's not an ideal solution but after a few fixes to how vector rotations worked, it became a possible solution, which is why that idea in the URL I posted never got implemented yet. The severity of the problem was reduced by the existence of the workaround. Basically, when comparing two problems, making things that are impossible to do *at all* become possible ends up taking higher precedence than making something that is possible but hard into something that is easy. That sort of "triage" thinking has been dominating my contributions to the code of late due to the fact that there's so few of us making code contributions, and a way more stuff to do than people to do it.

Edited October 13, 2014 by Steven Mading

[jospanner]

Sorry if this is a stupid question, but is there a way to make the steering more smooth? I'm a set of statements like "lock steering to heading(90,85).", the problem is the steering is flipping out and oscillating like crazy. The logic that the SAS and mechjeb use is much smoother, but of course I can't use those as well as kOS.

[erendrake]

Sorry if this is a stupid question, but is there a way to make the steering more smooth? I'm a set of statements like "lock steering to heading(90,85).", the problem is the steering is flipping out and oscillating like crazy. The logic that the SAS and mechjeb use is much smoother, but of course I can't use those as well as kOS.

We currently have two ways to control the craft, the automatic "LOCK STEERING TO HEADING" and the raw controls http://ksp-kos.github.io/KOS_DOC/summary_topics/ship_control/index.html

We originally wanted to give a very basic automatic control and also have the more robust direct control scheme. That being said the automatic system could use a little refinement

[jaxsin]

Ok, so after hours of looking at this code, I give up!

I was trying to get the FAR-optimized code back in post #363??? in this thread up to date and sort of working. I figured I could try at least. The problem I am getting now is some sort of "cast from source to destination" error and Steve mentioned this was happening on the C# side. I can't find the problem, would appreciate if someone could look at this and see maybe what the problem is.

Declare parameter ap,St,inc.	// Apoapsis of orbit; stages of rocket; launch angle

clearscreen.
set Log to 2.					// Line for mission log


set Ic to 25.					// Info-column (name; e.g "Inclination.:")
set Ic2 to Ic+12.				// Info-column (value; e.g "46°")
set Il to 12.					// 1. line of info-are
set Mil to 2.					// Line for mission-name
set spl to 5.					// Line for subprogram-name
set stl to 8.					// Line for subprogram-status




print "Mission Log:" at (0,0).
print "Mission:" at (26,0).
print "Subprogram:" at (Ic-1,spl-1).
print "Status:" at (Ic-1,stl-1).
print "Info:" at (Ic-1,Il-2).


print "Launcher" at (Ic,spl).
print "Prelaunch" at (Ic,stl).


print "Orbit alt.:" at (Ic,Il).
print round(ap/1000,3) + " km" at (Ic2,Il).


print "L. angle:" at (Ic,Il+2).
print 90-inc + " deg" at (Ic2,Il+2).


print "Stage:" at (Ic,Il+4).
print St at (Ic2,Il+4).


lock acc to maxthrust/mass.			// acceleration of vehicle


set v0 to 1800.		// v0 & psi0 = at v0 your rocket will fly at angle psi0
set psi0 to 70.		// ! measured from the vertical !


set twrmult to 1.5.	// factor to cancel out increasing twr over time
			// 1 = twr stays constant, etc.


set wtwr to 2.5.	// limit on your twr
set pitch to 90.
set Inc to 90-Inc.
lock steering to heading(pitch,inc,360-inc).
lock surfspeed to velocity:surface:mag.
lock twr to (body:radius^2*acc)/(body:mu).	// twr of craft






Sas off.
print "Prelaunch" at (Ic,stl).
print "Use SAS to launch ! " at (Ic,Il+10).
wait until SAS.					// use the SAS to launch
print "                   " at (Ic,Il+10).
sas off.


if maxthrust = 0 {stage.}
wait 1.
set twr2 to twr.
If twr > wtwr{set twr2 to wtwr.}
set t to twr2/twr.
lock throttle to t.


print "Gravity Turn  " at (Ic,stl).
print round(Missiontime) + "s Takeoff" at (1,Log).
set Log to Log+1.




set twr2 to twr2*twrmult.	// added multiplier to cancel out rising twr


	// Big script for gravity turn trajectory 
	// (assumes no atmospheric drag and constant TWR)
	// formulas are from here: 
// https://globaljournals.org/GJSFR_Volume12/6-Computational-Algorithm-for-Gravity.pdf


set z0 to tan(0.5*psi0).
set c to v0/(z0^(twr2-1)+z0^(twr2+1)).
set gt to list().


set n to 0.
set n2 to 1.
set nmax to sqrt(0.2*v0+28.25)-5.5.


lock v to 5*n^2+55*n+10.
lock v2 to 5*n2^2+55*n2+10.
lock vm to c*zm^(twr2-1)*(1+zm^2).
lock gt1 to gt#n.
lock gt2 to gt#n2.


set zmin to 0.
set zm to 0.5.
set zmax to 1.
until round(vm,0) = v{			// algorythm to find the solution
	if vm>v {set zmax to zm.}
	if vm<v {set zmin to zm.}
	set zm to (zmin+zmax)/2.
	wait 0.001.
}
set gt:add to 90-2*arctan(zm).


print "Iteration:" at (Ic,Il+6).


until n = floor(nmax) or ap-apoapsis < ap/10{


	set zmin to 0.
	set zm to 0.5.
	set zmax to 1.
	until round(vm,0) = v2{		// same algorythm
		if vm>v2 {set zmax to zm.}
		if vm<v2 {set zmin to zm.}
		set zm to (zmin+zmax)/2.
		wait 0.001.
	}
	set gt:add to 90-2*arctan(zm).
	until surfspeed > v or ap-apoapsis < ap/10 {wait 0.001.}	// autostaging - uncomment(testing script failures)
	print n at (Ic2,Il+6).
	set m to (gt2 - gt1)/(v2-v).
	set o to gt1 - m * v.
	lock pitch to m * surfspeed + o.
	set n to n+1. set n2 to n2+1.
}


lock steering to prograde + r(0,0,(-1)*inc).


lock throttle to 0.05/twr+(ap-apoapsis)/(1000*twr).	
// throttles down as you get closer to your wanted Ap
// Still needs some polish


//until apoapsis > (ap){
//	run stage(1).
//	wait 0.001.
//}
lock throttle to (ap-apoapsis)/(500*twr).	// also could get improved


print "                       " at (Ic,Il+10).     
print "Coasting to Ap" at (Ic,stl).
print round(Missiontime) + "s Coast start" at (1,Log).
set Log to Log+1.


set warp to 1.


set atmh to body:atm:height.
Until 0{			// until atmh < altitude somehow doesn't work
	//run stage(1).
	if altitude > atmh{break.}
	wait 0.001.
}
set warp to 0.
//run clearinfo.

[Camacha]

I have decided to give Notepad++ a try. Steven, did I hear you mention that there is a syntax file of some sort for that?

[Dunbaratu]

Ok, so after hours of looking at this code, I give up!

I was trying to get the FAR-optimized code back in post #363??? in this thread up to date and sort of working. I figured I could try at least. The problem I am getting now is some sort of "cast from source to destination" error

Can you show us where within the code the complaint occurs (what line does it highlight and say is the problem? Or does it not say?)

- - - Updated - - -

I have decided to give Notepad++ a try. Steven, did I hear you mention that there is a syntax file of some sort for that?

There might be, but I don't know of it if there is.

I did make a highlight file for VIM a long while ago, but it needs to be updated once some of the newer syntax gets shaked out. But at any rate, it was for Vim, not Notepad++.

[Camacha]

I see what you meant by the standard throttle setting being annoying. It even resets to 0,5 when reloading a quick save with a different setting.

I did make a highlight file for VIM a long while ago, but it needs to be updated once some of the newer syntax gets shaked out. But at any rate, it was for Vim, not Notepad++.

If/when you have an up to date file and are willing to share it, I don't mind giving Vim a go

[S1gmoid]

It's not an ideal solution but after a few fixes to how vector rotations worked, it became a possible solution, which is why that idea in the URL I posted never got implemented yet. The severity of the problem was reduced by the existence of the workaround. Basically, when comparing two problems, making things that are impossible to do *at all* become possible ends up taking higher precedence than making something that is possible but hard into something that is easy. That sort of "triage" thinking has been dominating my contributions to the code of late due to the fact that there's so few of us making code contributions, and a way more stuff to do than people to do it.

I can definitely relate to that.

Anyway, I'll have a look at the source, and if it seems feasible, I'll try to implement some of the vision you've described. What's your policy for source code contributions?

By the way... I'm not fully familiar with the internals of KSP yet, and I'm wondering if it might be possible to have am active physics simulation in the background (a separate thread with its own active vessel), like a probe "waking up" on autopilot at a predetermined time to make course corrections.

Edited October 14, 2014 by S1gmoid

[Laie]

It's not an ideal solution but after a few fixes to how vector rotations worked, it became a possible solution, [...] making things that are impossible to do *at all* become possible ends up taking higher precedence

The cooked controls can't handle many of my vessels. LOCK STEERING TO SOMETHING will send them into an erratic spin, I don't know why. (Interesting enough, it can handle my oversized spaceplane that is very difficult to control by hand -- riddle me this.) Writing a PID controller is a bit of a mouthful. I tried a few times already, but never got more than an headache out of it.

EDIT: it seem as if it matters which part you're controlling from. I just put three pods on a tri-coupler. The one that was placed first works. but when controlling from any of the other two, kOS' cooked controls go totally bonkers.

Edited October 14, 2014 by Laie

[jaxsin]

Can you show us where within the code the complaint occurs (what line does it highlight and say is the problem? Or does it not say?)

the error it doesn't say much. you can see it here http://imgur.com/FgPhB6M

I am pretty sure I have tracked down the error to the until {} block of code at line 102. I just don't understand enough about kOS to figure out why it is happening.

UPDATE: I figured it out, the error was being thrown by line 43. I wasn't getting the ship to steer correctly so when I started to debug the steering issues, I noticed the parameters where wrong. adjusting this fixes everything. A good nights sleep seemed to fix my problem.

Edited October 14, 2014 by jaxsin

[Dunbaratu]

the error it doesn't say much. you can see it here http://imgur.com/FgPhB6M

Actually seeing the string "((System Built-in flight control updater))" says a LOT. It says it happened while calculating the lock expression used by either LOCK STEERING or LOCK THROTTLE, which happens asynchronously in the background all the time and therefore isn't *directly* from where the current executing code happens to be. That's why it doesn't give the current line number.

[madlemur]

The cooked controls can't handle many of my vessels. LOCK STEERING TO SOMETHING will send them into an erratic spin, I don't know why. (Interesting enough, it can handle my oversized spaceplane that is very difficult to control by hand -- riddle me this.) Writing a PID controller is a bit of a mouthful. I tried a few times already, but never got more than an headache out of it.

EDIT: it seem as if it matters which part you're controlling from. I just put three pods on a tri-coupler. The one that was placed first works. but when controlling from any of the other two, kOS' cooked controls go totally bonkers.

edit: Duh, just read your post after a sudden burst of useful energy to my brain...

Yes, I would suspect that the part you're controlling from would make a huge difference. Especially if it doesn't jibe with the "facing" of the kOS core. And goodness only knows what happens to the part facings/controlfrom hijinks if the pods were placed via symmetry.

Have you tried printing out the facings of the parts as you go through and set the controlfrom value to true? Just to check what the system thinks is going on. You may also need to reset some of your cooked variable locks, if they are still tied to the old part, you're going to confoozle them...

Edited October 14, 2014 by madlemur

[jaxsin]

Actually seeing the string "((System Built-in flight control updater))" says a LOT. It says it happened while calculating the lock expression used by either LOCK STEERING or LOCK THROTTLE, which happens asynchronously in the background all the time and therefore isn't *directly* from where the current executing code happens to be. That's why it doesn't give the current line number.

Thanks for the help. Just glad I got it worked out. Makes a little more sense to me now. Never easy for a novice.