kOS Scriptable Autopilot System 0.9

[KevinLaity]

I am new with KOS, but I really like how much it promise this tool.

Right now I am looking a way to land my liquid boosters at target location (spacex style) 2 at the same time, but I dont know how :S

Kos is great becouse it allow you to have more than 1 autopilot to the same time.

But I was wonder, There is not a way to activate mechjeb programs? MechJeb already has a lot of programs who can save us.

If we can not fire programs of mechjeb, there is someone transcripting some of the mechjeb codes to KOS?

Also It will be nice to see a site with different script programs made by users.

This will be up to MechJeb to implement IF they choose. In the next version kOS will grant other mod developers the ability to add their own commands to the system.

[Dunbaratu]

This is true, but if the probe is too far away to get a signal, it's too far away to get a signal.

Which is why I'd like to see RemoteTech play with this. Setting up networks with combinations of dishes and antennas to get a signal where you need it.

Yes that would be good. I was waiting for baited breath with the promise that RT will have a computer software system when I gave up on waiting and came here to KOS instead.

[check]

For people wondering what the Q() function is and why it's better than R(), check out:

And then this:

[Secret Squirrel]

I am new with KOS, but I really like how much it promise this tool.

Right now I am looking a way to land my liquid boosters at target location (spacex style) 2 at the same time, but I dont know how :S

Kos is great becouse it allow you to have more than 1 autopilot to the same time.

But I was wonder, There is not a way to activate mechjeb programs? MechJeb already has a lot of programs who can save us.

If we can not fire programs of mechjeb, there is someone transcripting some of the mechjeb codes to KOS?

Also It will be nice to see a site with different script programs made by users.

Check this thread out not updated to kOS6 but with the fix on .61 hopefully will work, haven't tried it yet. I know from reading the have all intents to update script as needed as well.

http://forum.kerbalspaceprogram.com/showthread.php/48428-Space-Computer-Brought-to-you-by-kOS-and-hopefully-many-nerds

[Dunbaratu]

I need to beef up the range, a quick calculation shows that you'd need at least 3 comm dishes. (Each one multiplies your range by 10)

Ah I didn't know that either. There's a lot that it seems the only way to know it is to read the source code. Well, anyway multiplying the range by an exponential factor per antenna is a great idea, but 10 is probably too small of one given the distances in the solar system. If it takes 3 just to get to the Mun imagine trying to make a Voyager-like mission.

The idea of using Remote Tech to manage the ranges is great, but it has to also be balanced against the need to make KOS also be a mod that can also standalone without Remote Tech.

Anyway, thanks for the information (and the 0.61 bug fix so quickly).

[sirkut]

This will be up to MechJeb to implement IF they choose. In the next version kOS will grant other mod developers the ability to add their own commands to the system.

This is what I've been working on... Currently the hinge's range is -90 and 90 according to the cfg. Still a lot of work ahead but I wanted to show the potential in kOS for external mods.

[Camacha]

This is true, but if the probe is too far away to get a signal, it's too far away to get a signal.

Which is why I'd like to see RemoteTech play with this. Setting up networks with combinations of dishes and antennas to get a signal where you need it.

Like I already said in the Remote Tech thread, kOS fits so nicely with Remote Tech that it almost makes me cry. Having to choose at the moment actually makes me cry

[Dunbaratu]

For people wondering what the Q() function is and why it's better than R(), check out: [...]

Yeah I had an introductory computer graphics programming class back in college, back in the day, but the word "Euler angle" was never even mentioned in the class. It was all matrix multiplication and Quaternions. That's why I was so confused trying to use the rotation system in this mod. I was expecting that a thing called a rotation would only rotate space, rather than also skewing it into a non-orthogonal shape which is what a Euler rotation does, apparently.

[Camacha]

This is what I've been working on... Currently the hinge's range is -90 and 90 according to the cfg. Still a lot of work ahead but I wanted to show the potential in kOS for external mods.

This is incredible! I can see whole worlds of potential filled with actually controllable walking robots, mechanical devices and much, much more.

Building stuff like folding rovers was always perfectly doable on the hardware front, but controlling everything manually without stuff clipping was actually a bit harder. This looks like a perfect solution to those problems.

[check]

Yeah I had an introductory computer graphics programming class back in college, back in the day, but the word "Euler angle" was never even mentioned in the class. It was all matrix multiplication and Quaternions. That's why I was so confused trying to use the rotation system in this mod. I was expecting that a thing called a rotation would only rotate space, rather than also skewing it into a non-orthogonal shape which is what a Euler rotation does, apparently.

Yeah, I don't recall learning that either. Seems bizarre to me the way it does it.

Unrelated, any way to pull the current attitude of the spacecraft? The manual is in sore need of an update. lol.

[Kalista]

Like I already said in the Remote Tech thread, kOS fits so nicely with Remote Tech that it almost makes me cry. Having to choose at the moment actually makes me cry

Your not the only one I originally got this mod so I could perform under heavy signal lag or on the far side of planets where I have no signal. Here's to hoping they make it compatible soon ( on a side note I hope telemachus also adds this in so someone can upload a program remotely from a completely different pc).

[Dunbaratu]

This is what I've been working on... Currently the hinge's range is -90 and 90 according to the cfg. Still a lot of work ahead but I wanted to show the potential in kOS for external mods.

That CALL system has potential. I like it. I assume the CALL command is what was being talked about with hooking to other mods? I assume it's a way to call functions written outside of KOS?

[Payload]

For people wondering what the Q() function is and why it's better than R(), check out:

I understand what you mean but the R() system never had to be this way. All he had to do was extract the values he called pitch and yaw and run it through the trig functions and use it to set the vector and use absolute roll to set roll. The problem was those weren't pitch and yaw.

For instance, this works.

 set yaw to 90.
 set pitch to 90.
 set x to cos(yaw) * cos(pitch).
 set y to sin(yaw) * cos(pitch).
 set z to sin(pitch).

lock steering to up + R(0,0,180) + V(x,y,z).

There is no reason why those first two numbers couldn't have really been pitch and yaw and the trig done on them. (pitch,yaw,roll). Indeed I thought that was happening by looking at his code on Github. I think maybe he is using some other method to set z that causes gimbal lock. Either way, you only need pitch and yaw to set the correct vector. The gimbal lock is artificial in this case. That doesn't mean we don't need the V() structure because it is useful for other things, and the code above is effectively the same as the Q() system anyway.

Edited September 17, 2013 by Payload

[sirkut]

That CALL system has potential. I like it. I assume the CALL command is what was being talked about with hooking to other mods? I assume it's a way to call functions written outside of KOS?

Yup on both questions. Modders simply just register whatever methods they want kOS to have access to and that's it.

[KevinLaity]

This is what I've been working on... Currently the hinge's range is -90 and 90 according to the cfg. Still a lot of work ahead but I wanted to show the potential in kOS for external mods.

Great stuff!

[rhoark]

Thinking about how many antennas I'd have to festoon an eeloo mission with, I think multiplying comm distance according to number of antennas is not the right strategy.

Best case: communications pass through a sequence of relays, a la remotetech. Selection of antennae imported from RT and/or AIES have ranges varying from 16's to low orbit up to 2.5m dishes that reach anywhere.

Good enough: communicotron 16 works within minmus distance, and 88-88 anywhere in the solar system.

[dlrk]

Is there any complete non-video documentation for this? I've tried the wiki, it has little info.

Also, a question. How is roll specified in the new steering method?

[Dunbaratu]

With 0.61 my 0.5-made script now works again. The command "lock steering to up * V(x,y,z). " now works again! Yay.

But I just can't wrap my head around the VELOCITY:SURFACE vector. I'm still having to use my old method of deriving it from the latitude and longitude and vertical velocity. And I think the reason is that the frame of reference for the vector is NOT based on the surface of the planet but based on something in space that I don't know what it is.

What is the frame of reference for the vector VELOCITY:SURFACE ? In other words, which direction is X, which is Y and which is Z, and where is (0,0,0) located in that coordinate system?

Edited September 17, 2013 by Steven Mading

[Gaius]

This is what I've been working on... Currently the hinge's range is -90 and 90 according to the cfg. Still a lot of work ahead but I wanted to show the potential in kOS for external mods.

Awesome! Suggestion: add a way to hide the usual Infernal Robotics interface. If I have a way to control the groups programatically, I really don't need or want the usual control window cluttering up my screen...

[Bizz Keryear]

->Short notice I am still on 0.6 and since I have read all the posts along the way this post has taken quite a while....<-

1. This is mostly fixed in 0.6. I've been working on this mod since 0.18, which is why it started out in that structure.
   I hadn't realized by the time I released the mod that the official structure had changed, and afterward it seemed like there were a lot more important things to take care of.

   It seems I posted it only short before the release of 0.6.
   
2. One word between friends: This Mod is great by the documentary sucks. Half of the functions aren't documented right now. Or not completely.
   I think it sucks (for people like me which instead of memorizing things, constantly looking into the manual) to get informations of some of the features only from the documentary videos.
   both https://github.com/Nivekk/KOS/blob/master/README.md and http://kos.wikia.com/wiki/KerboScript are incomplete. IMHO is having a redundant documentary counterproductive. Better keep in one place only, but complete instead.
   
3. And my five cents to the steering. It wobbles like hell. Most likely (IMHO) its caused by handling the floats wrong. Even if the if in the program is an exact value is given, the interface should add an tolerance (or so)
   Lets assume a ship in space. Its currently stable (not rotating) and needs to turn somewhere. Lets also assume it has not enough torque (to make decent turns). First it has to know how much energy it needs to change the rotating speed since it has to slow down before reaching the desired destination to prevent it from overshooting too much.
   While generally you want to apply less steering force as closer as you are to the desired destination, it can make sense to apply more force to overcome influences from the outside.
   Wha! I have a picture in mind but its so hard to explain especially since English is a foreign language to me.
   Overshooting could be prevented if the amount of motion energy is known.
   E.g: [highlight]---motion energy---> + ---external force* x time---> <---available force (aka. torque) x time ---[/highlight]
   desired outcome: it should come to stand still at time it reaches the destination.
   When you wanting to move towards a desired destination its reasonable to accelerate only the half of the distance towards it. (for simplifying purposes I left out external forces)
   When spinning uncontrollable (which means that the craft is spinning with more energy that it can afford before "flipping over" [passing the point which is the furthest away form the destination) has a problem in the traditional handling since (like the sas e.g.) it will accelerate the craft again towards the destination once it "flips over". Like in the highlighted example above a overshooting prevention could slow it down instead.
   Its a complicated matter and I myself am only just to grasp it. (And put my ideas into words)
   
4. Funny thing: I've just read the wiki article about volumes for the 1st time. I've always wondered why the volume one is only 10Kib big when you have an infinite big Archive. Since I have switched to archive in the prelaunch phase I haven't figured out that its not meant as accessible as soon you are further away.
   My suggestion are: 1. only fully accessible (and that includes that you are kicked out as soon you not matching those conditions) in close range to KSP in landed or prelaunch phase. That also means executing files.
   If you are off the ground then the comm range kicks in which kicks you out of the archive volume as soon as you leave the range (currently one of my crafts is executing files from archive and its in a about 200km orbit and has no antennas)
   Also a low baud rate (copying files will take time) which gets even lower as closer you get to the max antenna range (noise).
   Also add an exception for a file named "nextVessel.txt" folder in archive. This is for the reason that you don't always have the time to prepare the vessel manually. The file "nextVessel.txt" should automatically executed the next time a new vessel will be at start. (for copying files in prelaunch and set things up). Like any other file in the archive the execution should be interrupted as soon as the vessel launches. which actually shouldn't affect any files which this program has launched from volumes on the actual vessel.
   
5. And at last but not at least a question: Was there a possibility to control the KSP timewarp with the script or have I only dreamed it? (could swear I have heard it in one of the videos but can't find it anymore anywhere) And if it is, whats the command?
   

6. ... So you can use [...] the kOS IDE someone has created (that does syntax highlighting based on kerboscript), ...

   Would be nice to have that linked somewhere central. I am actual too lazy (right now) to do it (set up the highlight) in Notepad++.
   

7. ...Meaning ones out in space not ones on the launchpad. Once you're far enough away from home, the command "switch to archive" fails.

   Like said above I don't see the reason as long as you can stay in archive.
   

8. Relaying is something I've thought of. I'd like to be able to COPY TO target, but not sure yet how doable that is, since I have to save persistence data from the part and parts don't operate outside of physics range.

   Well somehow it has to be possible. The changed positions of not active crafts are also be saved / calculated in background. I actually know that other mods, like the life support ones, also doing their stuff in the background. I don't think that its possible to actually execute control commands outside the physical range. But that could be realized with a auto vessel change. (If a vessel has to execute things like burns, rcs translations and stuff you switch [temporally perhaps] to the vessel in case. See "Kerbal Alarm Clock". It could also, like KAC, remember any navigation nodes) Perhaps it may a good idea to have a part-less button in KSP (like KAC, Chatterer, or Steam Gauges) to turn that feature on and off.
   You could it make generally a part-less plugin which only checks for the part on a vessel and creates virtual instances for them... or so. Which also would make it possible to "remember" the com distance of a vehicle since it doesn't change once it is inactive.
   

9. Like I already said in the Remote Tech thread, kOS fits so nicely with Remote Tech that it almost makes me cry. Having to choose at the moment actually makes me cry

   I don't really like RT, because usually you are the computer on board of the probe / vessel so why should there a delay in the execution of the commands...
   But I have to admit it would actually make sense with this...at least in some ways**.... so while kOS is the computer on the vessel which executes the commands directly, your inputs are the remote commands from the control center.

---------------------------------------------

*= like when the center of thrust is off or something alike.

**= doesn't takes Astronauts in account...

This is all only my opinion. I wouldn't bother (or give a f**k) if i won't see any potential or think of it as good in first place.

I tend to piss off people sometimes with the way I phrase things, I usually don't mean it that intense. I hope to be helpful. So please no hard feelings, ok?

[sirkut]

Awesome! Suggestion: add a way to hide the usual Infernal Robotics interface. If I have a way to control the groups programatically, I really don't need or want the usual control window cluttering up my screen...

There is. Right click infernal part and select hide GUI.

[TheGreatFez]

Hello all, just joined the forums cause I have been working on this launch program and it has been finished! Thanks to the new update I was able to create the best criteria that I can think of for getting a rocket to the correct (and nearly perfect) circular orbit! Here is a list of the implementations I have added to my launcher that I set out to accomplish:

During the vertical ascent and beginning the gravity turn: I created a loop between ground and 25,000m that adjusts the throttle so the craft is always flying at terminal velocity. This from what I have read is the most optimal solution.

Once desired circular orbit altitude has been reached: I created a control logic that keeps slightly adjusting the apogee during atmospheric ascent. This produces consistent results of the apogee being within 10m of desired circular orbit altitude. Example: if I set my desired circular orbit to 100km the biggest difference I have seen is 100,010m.

Upon reaching apoapsis and beginning burn to circularize orbit: I created a control logic that adjust the angle of the burn so the craft is always behind or at the apoapsis until the vehicle reaches the appropriate orbital velocity. With arcsin arccos and arctan functions (which I hope will be implemented! ) I can make the logic more concrete and physics based.

I am really proud of it and I wanted to show it off for people to see and comment on it. If you have any questions, comments, or what to know more feel free to ask. Also if you have any other challenges you think I can take up please let me know! I am excited to use this mod more!

// Set FINAL to your desired circular orbit.
set FINAL to 100,000.
stage.
set thrust to 0.
lock throttle to thrust.
lock steering to heading 90 by 90.

set m to mass.
set D to (mass*9.81)/6500.
set Qmax to (mass*9.81)/D. 

clearscreen.
print "T-minus 5". wait 1.
print "4". wait 1.
print "3". wait 1.
print "2". wait 1.
print "1". wait 1.
print "Launch".
set thrust to 1.
stage.
wait 1.
clearscreen.
set Cd to .2.
set p0 to 1.223125.
set e to 2.71828.
set q to 0.
print "Vertical Ascent" at (0,0).
print "Q-Max" at (0,1).
print "Dynamic Pressure" at (0,2).
until q > Qmax*.9 {
	set H to altitude/(-5000).
	set p to p0*(e^H).
	set q to (.5*(verticalspeed^2)*p).
	set Qmax to (mass*9.81)/D. 
	print Qmax at (20,1).
	print q at (20,2).
	}.
// Throttle is reduced to maintain a constant terminal velocity.
clearscreen.
print "Throttle down to reduce drag losses" at (0,0).
wait 1.	 
clearscreen.
print "Throttle" at (0,1).
print "Speed" at (0,2).
print "Density" at (0,3).
print "Dynamic Pressure" at (0,4).
print "Q-Max" at (0,5).
set x to .5.

until altitude > 25000 {
	set H to altitude/(-5000).
	set p to p0*(e^H).
	set q to (.5*(verticalspeed^2)*p).
	set Qmax to (mass*9.81)/D.
	if altitude > 10000 AND x < 1 {
		lock steering to heading 90 by 60.
		print "Begin gravity turn" at (0,7).
		set x to x+1.
		}.
	if altitude > 15000 and x < 2 {
		lock steering to heading 90 by 30.
		set x to x+1.
		}.
	if q < Qmax AND thrust < 1 {
		set thrust to thrust + .05.
		}.
	if q > Qmax {
		set thrust to (((q*Cd*m*.008)/maxthrust)+thrust*1.25)/2.
		}.
	print thrust*100+"%" at (20,1).
	print verticalspeed at (20,2).
	print p at (20,3).
	print q at (20,4).
	print Qmax at (20,5).
	if stage:liquidfuel = 0 {
		stage.
		}.
	}.

// After 25,000m the effects of drag are minimal so thrust is set to 100%.
// Burn to desired circular orbit altitude.

clearscreen.
print "Burn to " + FINAL*.001 + "Km apogee".
lock steering to heading 90 by 30.
set thrust to 1.
until apoapsis > FINAL*.9 {
	if stage:liquidfuel = 0 {
		stage.
		}.
	}.
set thrust to 0.
lock steering to prograde.
clearscreen.

// Adjust final apoapsis until out of drag effects.
print "Coast to Space".
set x to 2.5.
until altitude > 70000  {
	if apoapsis < FINAL {
		set thrust to .1*x.
		}.
	if apoapsis >.99*FINAL {
		set x to .1.
		}.
	if apoapsis > FINAL {
		set thrust to 0.
		}.
	}.

// For extremely high altitudes (such as geosynchronous) this is needed-.
// since burn will continue out of atmosphere.
if apoapsis < FINAL {
	set thrust to .1.
	wait until apoapsis >.999*FINAL.
	set thrust to .01.
	wait until apoapsis > FINAL.
	set thrust to 0.
	}.
clearscreen.

//Calculate circular velocity at apoapsis altitude
set x to 1.
set theta to (5*100000)/FINAL.
set GM to 3.5316*(10^12).
set r to apoapsis+600,000.
set vcir to (GM/r)^.5.
set v to 0.

// Warp!
print "Warp to Apogee".
set warp to 4.
wait until eta:apoapsis < 1000.
set warp to 3.
wait until eta:apoapsis < 50.
set warp to 0.
lock steering to heading 90 by 0.
clearscreen.

// Waiting on apoapsis arrival.
print "Vertical Speed" at (0,1).
until verticalspeed < 3 {
	print verticalspeed at (20,1).
	print "T-minus " + eta:apoapsis + " to Apoapsis" at (0,0).
	}.
clearscreen.

// Burn to circularize, theta is used to maintain the apogee infront of the craft
print "Burn to Circularize Orbit" at (0,0).
print "Vertical Speed" at (0,1).
print "Orbital Speed" at (0,2).
print "Vcir" at (0,3).
print vcir at (20,3).
print "Theta" at (0,4).
print theta at (20,4).
set par to altitude/(-10000000).
set tval to .75*(e^par).
set y to .5.
until v > vcir*.9995 {
	set thrust to 1*x.
	set vec to velocity:orbit.
	set vx to vec:x.
	set vy to vec:y.
	set vz to vec:z.
	set v to ((vx^2)+(vy^2)+(vz^2))^.5.

	if stage:liquidfuel = 0 {
		stage.
		}.
	if v > vcir*.9 AND y < 1{
		set x to tval.
		set y to y+1.
		}.
	if v > vcir*.99 AND y < 2{
		set x to .1.
		set y to y+1.
		}.
	if verticalspeed < 0 {
		lock steering to heading 90 by theta.
		}.
	if verticalspeed > 0 {
		lock steering to heading 90 by 0.
		}.
	print verticalspeed at (20,1).
	print v at (20,2).
	}.
lock throttle to 0.
clearscreen.
// DONE!

set e to (apoapsis-periapsis)/(apoapsis+periapsis).
print "Eccentricity" at (0,0). print e at (20,0).
set avg to (apoapsis+periapsis)/2-FINAL.
set error to avg/FINAL*100.
print "Error " + error + "%" at (0,1).
wait 10.

[GavinZac]

This is very exciting! One important thing for robotics I think, though, is array handling. It would make for much cleaner code if we can iterate through legs or arm parts as an array, or use them to select one with the most extreme position or something (e.g. selecting the arm that is closest to an object, controlling that one and not the others)

[Payload]

Haha, if we get array handling who is going to be the first to make Pong? Tetris might fit nicely too. Why warp to that transfer orbit when you can play Tetris while you wait?

There is. Right click infernal part and select hide GUI.

I saw that video. Dude, that is all kinds of rad. I am already picturing a kerbal on a command chair perched on top of about four reaction wheels, running around on chicken walker legs. Automatic targeting of the chain gun.. No debris will survive.

Edited September 17, 2013 by Payload

[Gaius]

There is. Right click infernal part and select hide GUI.

Sorry, clarification: add a CALL that hides/shows the interface, so the program can hide/show the controls (without resorting to actiongroups).

Come to think of it, is this necessary for mod authors to do? Can't kOS simply access anything that shows up in right-click menus and give programs the ability to "right click" items, virtually speaking?

Edited September 17, 2013 by Gaius