[1.3] kOS Scriptable Autopilot System v1.1.3.0

[Dunbaratu]

On a kOS Telnet server and security.

I'm in the middle of trying to implement the ability to remote the kOS terminals from an application outside of KSP.

Thus allowing you to, say, open Putty on Windows and connect it to the kOS computer and have your kOS script show up there. Or open an xterm on linux and connect into kOS from it.

But this raises some security concerns, so I thought I'd ask the user community what they thought of my approach, as described below:

• It works by having a telnet server inside of KSP. I wanted ssh originally but had to abandon that plan due to the dearth of opensource ssh server implementations for C#, and my unwillingness to implement one from scratch as that would be a brand new months-long project in itself. Granted there weren't any telnet server projects I could find either, but the telnet protocol is a LOT easier to implement from scratch - at least just enough of the handshaking to make it switch from the default line-at-a-time mode to the char-at-a-time mode you need for proper terminal operations.
  
• The server will refuse to ever use any address other than loopback 127.0.0.1. It will make no attempt to resolve the hostname or find the 'real' address. This should prevent remote network connections.
  
• Because it's a false sense of security to even bother sending passwords over telnet, a different approach is needed for security entirely. Thus the loopback rule instead of bothering with names and passwords.
  
• Therefore users who do want to try to connect to the system from another host will have to be tech saavy enough to know how to set up their own ssh tunnel to do it. The security will therefore be the responsibility of the person setting up the ssh tunnel and not kOS.
  
• In keeping with the rules SQUAD imposes about not having KSP mods perform network traffic without the user's express understanding and opt-in permission, the mod will ship with the telnet option turned off by default, and unless you turn it on by changing a config option, there will be no telnet server running. The first time you turn it on, there will be an explanatory popup message about what it means. I'll do this even though, *technically*, since the server only talks to loopback 127.0.0.1, it's not *really* network traffic. It's local traffic that only lives in RAM and never reaches the hardware network interface.
  

It is my hope that this will satisfy people's desire for some security. By only allowing it to be local 127.0.0.1, And being turned off until you say to turn in on, I hope to avoid the need for encryption and username/password checks.

I can still see *one* potential problem being what might happen if you're running the game on a computer with multiple users on it at the same time, and another user wants to mess with you by telnetting to your KSP game. But that's the sort of thing that I think is less likely on a gaming machine on which you would run KSP, and more likely on a server machine. To do this someone *already* needs to have an account on your gaming machine and *already* have the ability to get to the command line on it. And if someone you don't trust has managed to do that much already, you've already lost your security entirely even before kOS enters into the picture.

Edited January 15, 2015 by Steven Mading

[kcs123]

Alowing connection by default to only 127.0.0.1 is reasonably enough security feature, don't see purpose to deal with ssh connection just for making this mod running.

However, people that already use LAN to access kOS from other computer and edit script while on first run KSP game, may found that 127.0.0.1 is not enough.

There should be option to add LAN network adress in filter to alow 127.0.0.1 and 192.168.1.0 network for example. Of course 192.168.1.0 should be editable and explained in warning message where and why to edit this. This will make some simple firewall that will suffice to deal with simple security issue. Users that need more security will have to deal by themself as you already mentioned. They should know how to make ssh tunel and solve it.

Other then that I don't see why to waste time and effort to making it more secure, it is better to use that energy elswhere.

Btw, I missed earlier posts about including telnet protocol in kOS, why you want to do it ? What will be improved with kOS if telnet protocol is available ?

It is already possible for people who need it, to make shared folder and allow acess to kOS script folders to be editable over LAN from some other computer, not just account on same PC.

[Kartoffelkuchen]

Hi, I've a probably really easy question to you:

I want that my little Grasshopper keeps an altitude, so that it floats over the surface..

But I don't know to program this. I tried to let it calculate the TWR, and then lock the Throttle somehow there where the TWR is exactly 1, but that didn't really work out.

Any tips maybe?

[Diazo]

Hi, I've a probably really easy question to you:

I want that my little Grasshopper keeps an altitude, so that it floats over the surface..

But I don't know to program this. I tried to let it calculate the TWR, and then lock the Throttle somehow there where the TWR is exactly 1, but that didn't really work out.

Any tips maybe?

Hovering, meaning your vertical velocity is zero, is a two step process as you have to first cancel your current vertical movement and then lock the throttle at TWR of 1 to cancel gravity.

All setting the throttle to TWR of 1 does is keep your current vertical speed, regardless if that speed is 100m/s or 0m/s.

And this ignores terrain, if you want to keep a constant height above terrain, that's a 3rd step in the process as you have to now include how far away you are from your target altitude in the calculations.

I've written the Vertical Velocity mod to control all this stuff so I've never considered what a kOS script would look like.

The first step would be can you make a script that sets your throttle to a TWR1 of 1? The next step would be can you cancel your vertical speed? Then chain those two scripts together to do what you are trying to do.

Hope that helps,

D.

[Camacha]

Zero your speed, lock TWR to one and design a mechanism to deal with the very slight altitude creep that typically shows in such a setup in kOS and KSP. That is all you need to do (and can be very simple, or get very complicated, depending on your choices).

In my experience, dealing with the creep/drift is actually the most subtle, but also the hardest problem. PI/PD/PID is an easy solution, while more involved model based business does it too in more contrived but elegant way. Mind you, I last did this a couple of versions ago, to double check to make sure that just locking TWR to 1 is not enough in itself.

Hover scripts are a lot of fun to do

Edited January 15, 2015 by Camacha

[Diazo]

The creep is mostly due to fuel mass burning off so your craft gets lighter, although lift from wings does apply even at very low horizontal velocities, even when it shouldn't. Notably the tail fins on a Kerbal2 will generate lift as you drift sideways. (...?)

Anyways, set throttle to TWR 1:

AllEnginesMaxThrust = Sum of all engines Max Thrust, assuming all engines point straight down, in Newtons (or maybe KiloNewtons?)

VesselMass = Vessel's total mass, including fuel onboard

GravityForce, in m/s = 9.8 at Kerbin sea level

Throttle%ForTWR1 = (GravityForce * VesselMass) / (AllEngineMaxThrust)

As you have to thrust down at exactly the force of gravity to cancel it, the equation is a straight ratio. I have a downwards thrust acceleration of 30m/s^2, gravity is 9.8m^2, my throttle needs to be set just under 1/3rd to have a TWR of 1.

D.

Edited January 15, 2015 by Diazo

[RadarManFromTheMoon]

On a kOS Telnet server and security.

I'm in the middle of trying to implement the ability to remote the kOS terminals from an application outside of KSP.

Thus allowing you to, say, open Putty on Windows and connect it to the kOS computer and have your kOS script show up there. Or open an xterm on linux and connect into kOS from it.

But this raises some security concerns, so I thought I'd ask the user community what they thought of my approach, as described below:

• It works by having a telnet server inside of KSP. I wanted ssh originally but had to abandon that plan due to the dearth of opensource ssh server implementations for C#, and my unwillingness to implement one from scratch as that would be a brand new months-long project in itself. Granted there weren't any telnet server projects I could find either, but the telnet protocol is a LOT easier to implement from scratch - at least just enough of the handshaking to make it switch from the default line-at-a-time mode to the char-at-a-time mode you need for proper terminal operations.
  
• The server will refuse to ever use any address other than loopback 127.0.0.1. It will make no attempt to resolve the hostname or find the 'real' address. This should prevent remote network connections.
  
• Because it's a false sense of security to even bother sending passwords over telnet, a different approach is needed for security entirely. Thus the loopback rule instead of bothering with names and passwords.
  
• Therefore users who do want to try to connect to the system from another host will have to be tech saavy enough to know how to set up their own ssh tunnel to do it. The security will therefore be the responsibility of the person setting up the ssh tunnel and not kOS.
  
• In keeping with the rules SQUAD imposes about not having KSP mods perform network traffic without the user's express understanding and opt-in permission, the mod will ship with the telnet option turned off by default, and unless you turn it on by changing a config option, there will be no telnet server running. The first time you turn it on, there will be an explanatory popup message about what it means. I'll do this even though, *technically*, since the server only talks to loopback 127.0.0.1, it's not *really* network traffic. It's local traffic that only lives in RAM and never reaches the hardware network interface.
  

It is my hope that this will satisfy people's desire for some security. By only allowing it to be local 127.0.0.1, And being turned off until you say to turn in on, I hope to avoid the need for encryption and username/password checks.

I can still see *one* potential problem being what might happen if you're running the game on a computer with multiple users on it at the same time, and another user wants to mess with you by telnetting to your KSP game. But that's the sort of thing that I think is less likely on a gaming machine on which you would run KSP, and more likely on a server machine. To do this someone *already* needs to have an account on your gaming machine and *already* have the ability to get to the command line on it. And if someone you don't trust has managed to do that much already, you've already lost your security entirely even before kOS enters into the picture.

Hmmm.. I understand your concerns regarding security, but IMHO limiting connections to the loopback is overkill. What about a whitelist which, by default, only contains 172.0.0.1? This way everyone could define explicitly which connections are trustworthy.

[Camacha]

The creep is mostly due to fuel mass burning off so your craft gets lighter

It happens when you use the exact mass of the craft and update continuously too, even when you turn on infinite fuel so that mass does not change, so it does not appear to be mass burning off. I spent quite a bit of time trying to work out where the drift comes from, but for as far as I could tell it is some kind of inherent KSP/kOS thing, or has to do with internal updates that are slightly out of sync.

assuming all engines point straight down

That is not a bad addition to the list: adjusting the throttle setting to compensate for how far the thrust vector is off the gravity vector. If your craft is upright the difference should be small (but not entirely negligible), but with larger angles (meaning vehicle rotation) the effect becomes rather profound, up to the point where full thrust is still going to lose you altitude.

It is cool to implement some sort of lock to prevent the vehicle from turning any further, especially with the new pilot inputs. I calculated the maximum safe angle when I was doing my scripts, but hard a hard time intervening in a proper way because kOS could not really do that back then. Locking the craft to some angle was a rather crude way to do that, but now you actually have a lot of fine control and can even lock the player out and override his actions. Airbus style fly-by-wire

Edited January 15, 2015 by Camacha

[Diazo]

Hmmm.. I understand your concerns regarding security, but IMHO limiting connections to the loopback is overkill. What about a whitelist which, by default, only contains 172.0.0.1? This way everyone could define explicitly which connections are trustworthy.

First, for the telnet thing to be really worth it, you need to allow access from other computers. Limiting it to just 120.0.0.1 is overkill though I think, KSP is not being run on top-secret level information servers. (At least, I hope it isn't.)

To satisfy me, accepting connections on 127.0.0.1:23 (port 23 being the default telnet port I believe) works. For remote addresses though, I would want to see the ports for remote IPs forced to use a port in the range of, say, 16000 to 19000. So 192.168.0.5:23 would not be valid, but 192.168.0.5:16000 would be.

My rationale for this is two fold:

1) It prevents kOS from falling into any established telnet rules someone might have already setup.

2) By forcing the non-standard port, if a player does wish to telnet in from another computer, it establishes a minimum knowledge required level where presumably the player knows what they are doing to their network. Not 100% effective of course, but no strategy of implementing this will be.

Note that I do not count changing the port itself as any sort of security, the security comes from the fact that changing the port is a way of making sure the player knows enough about networking that they are not opening up their security more then intended to make this work.

The other alternative is to limit outgoing address to the same subnet as the computer KSP is running on. So if KSP is running on 192.168.0.50, outgoing packets could have an IP of 192.168.0.xxx, but anything else would not send. That allows computers on the same local network access but anyone outside the router (the ADSL/Cable modem for a typical player) will fail as the destination IP will be a public internet IP. Then if a player really wants external access, they are responsible themselves for security when they setup a VPN/SSH tunnel connection of some sort.

D.

- - - Updated - - -

It happens when you use the exact mass of the craft and update continuously too, even when you turn on infinite fuel so that mass does not change, so it does not appear to be mass burning off. I spent quite a bit of time trying to work out where the drift comes from, but for as far as I could tell it is some kind of inherent KSP/kOS thing, or has to do with internal updates that are slightly out of sync.

Really? I do exactly this for my Vertical Velocity mod and I can lock vertical velocity to a set number to an accuracy of 4 or 5 decimal places reliably.

My code's on my Git if you want to take a look at it.

Nevermind, just re-read and you are talking about directly setting the throttle based on mass, I don't do it that way. I set the throttle based on your current speed difference. So if/when this drift happens, I interpret that as "speed too high" and throttle down below the calculated TWR 1 throttle to compensate.

D.

Edited January 15, 2015 by Diazo

[Camacha]

Nevermind, just re-read and you are talking about directly setting the throttle based on mass, I don't do it that way. I set the throttle based on your current speed difference. So if/when this drift happens, I interpret that as "speed too high" and throttle down below the calculated TWR 1 throttle to compensate.

I calculated the ideal throttle setting for TWR 1 and modulated that depending on whether the altitude was above or below the setpoint. Speed difference was not factored in, though a more advanced version of the script would also allow to set a desired rate of ascent/descent. I never got around to fully finishing that.

Though I do not know whether the drift I was talking about is also present when writing a direct plugin for KSP - it might very well be an emergent phenomena because of how kOS works. If that is the case, you would not encounter it when you write a plugin. In theory zeroing your speed at a certain altitude and setting TWR to 1 should be enough, but in practice it was not. There was a slight deviation that would add up over time.

Edited January 15, 2015 by Camacha

[Kartoffelkuchen]

Thanks for your tips guys! I'll see how far I will get with it.

[Ziw]

Guys, I really find the 10000 bytes storage on cores insufficient. I am not a fan of creating unreadable code with short named variables and such, I propose to set this number as a config option.

I really like KOS and it is challenging enough to have RemoteTech and KOS at the same time but this limitation of 10k code is quite silly IMO.

//rant off

- - - Updated - - -

BTW it seems that version 1.6 of RemoteTech broke the RT2 integration in KOS. At least none of my scripts loaded into probe's memory work properly now when it comes to steering/throttle.

[Dunbaratu]

Guys, I really find the 10000 bytes storage on cores insufficient. I am not a fan of creating unreadable code with short named variables and such, I propose to set this number as a config option.

I really like KOS and it is challenging enough to have RemoteTech and KOS at the same time but this limitation of 10k code is quite silly IMO.

//rant off

- - - Updated - - -

BTW it seems that version 1.6 of RemoteTech broke the RT2 integration in KOS. At least none of my scripts loaded into probe's memory work properly now when it comes to steering/throttle.

I agree that it's ridiculous. It's been largely left alone for now because a future goal is to make multiple sized storage units and until that infrastrucure is in place any changes made now would just have to be changed again later.

In the meantime you should be able to change it yourself by manually editing the Part.cfg file for the kOS part.

Look at GameData/kOS/Parts/kOSMachine0m/ or GameData/kOS/Parts/kOSMachine1m/, depending on which part you want to change it for, and look for a file called Part.cfg in those folders.

It should have a section like so:

MODULE
{
	name = kOSProcessor
	diskSpace = 5000
}

Change the number for diskSpace, save the file, and re-run KSP.

Be aware that your change will be reset each time you install an update of kOS and you'll have to edit it again.

- - - Updated - - -

For remote addresses though, I would want to see the ports for remote IPs forced to use a port in the range of, say, 16000 to 19000.

I already was planning on not using port 23. This could be running on a computer that already has a real telnet server on it, and besides, the OS *should* be preventing a normal level user from running code that opens up a server on ports less than 1024. That's supposed to require root/admin privileges, which is another reason I'm not using 23. It would necessitate running KSP as root/admin.

I may consider allowing the user to open it to known ranges, but that makes me a bit nervous. It would be easy for a kOS user to hear advice from someone saying "hey, doood, all you have to do is just type these numbers in there and it works everywhere - I know because I did it myself." I want a certain level of expertise on the part of the person opening this up so it puts the onus on them to know what they're doing and why.

I may provide step by step instructions on how to set up an ssh tunnel. But the point is that an ssh tunnel then requires that there be some sort of existing means of logging in to the host machine already, thus the better security.

- - - Updated - - -

Btw, I missed earlier posts about including telnet protocol in kOS, why you want to do it ? What will be improved with kOS if telnet protocol is available ?

It opens up all the following use cases:

• Other mods, like telemachus, remotely hosting kOS terminals inside them.
  
• Support for the people who like to build funky hardware dashboards for KSP.
  
• Let's face it, we'll never end up making the in-game terminal as nice to look at as something like xterm or putty. In an external window, you can overlap the windows nicer, tile them, do what you want, without them getting in the way of the main game window.
  
• Supports people running the game on multi-headed monitor setups. They can put their kOS terminals on another screen away from their game screen.
  
• Multi-player coop Artemis-style missions such as envisioned by the Go At Throttle Up mod.
  

[Ziw]

snip...

In the meantime you should be able to change it yourself by manually editing the Part.cfg file for the kOS part.

Look at GameData/kOS/Parts/kOSMachine0m/ or GameData/kOS/Parts/kOSMachine1m/, depending on which part you want to change it for, and look for a file called Part.cfg in those folders.

It should have a section like so:

MODULE
{
    name = kOSProcessor
    diskSpace = 5000
}

Change the number for diskSpace, save the file, and re-run KSP.

Be aware that your change will be reset each time you install an update of kOS and you'll have to edit it again.

- - -

• 
  

i tried it just an hour ago, but for some reason it didnt work. Maybe there are some more hidden checks in the code? Or maybe I did something wrong, I'll try tomorrow one more time on a different install.

[Dr_Goddard]

A little clip to show today's progress.

Using multiple cores is a powerful tool.

A little more clean-up and I'm going to start on coordinated individual leg movements.

[Ziw]

i tried it just an hour ago, but for some reason it didnt work. Maybe there are some more hidden checks in the code? Or maybe I did something wrong, I'll try tomorrow one more time on a different install.

Tried it on my laptop install, same result, maybe there are some caches I need to clean after changing part.cfg file?

[Dunbaratu]

Tried it on my laptop install, same result, maybe there are some caches I need to clean after changing part.cfg file?

You're probably trying to load a Vessel or a Craft file that you saved earlier before you made the change.

When you save a ship design in the VAB, it saves a copy of the vessel that holds all vessel's settings for all the vessel's parts (so it can remember how you had your tweakables set.) When you launch the vessel on the launchpad, it clones that saved copy and all its saved part values.

The part.cfg file affects the settings that are applied to *new* instances of the part that are created. It doesn't affect old instances of the part that already existed before you made the change.

Try going into the VAB, pulling the ship apart and removing the SCS computer part and throwing it away, and then attaching a new copy of the SCS computer part to the vessel and reattaching the pieces as they were. Save that and it should now have the new setting.

[Ziw]

Yes, now it works. Thanks a lot! Now I can continue on with my modded career mode 8)

- - - Updated - - -

A little clip to show today's progress.

Using multiple cores is a powerful tool.

A little more clean-up and I'm going to start on coordinated individual leg movements.

http://youtu.be/iAfYi4srj64

Cool!

So each core runs a sub-process for corresponding leg or what?

[Positr0n]

I can't wait to try out this mod with RemoteTech. Hopefully nothing breaks.

[Ziw]

I can't wait to try out this mod with RemoteTech. Hopefully nothing breaks.

I had to install older version of RT (1.5.2), the newest one (1.6) broke the integration with KOS (at least for me).

[Dr_Goddard]

So each core runs a sub-process for corresponding leg or what?

Two cores running in the demo.

The main one runs a routine that allows me to send positions to pre-selected groups of servos.

I load a big list of pre-selections before the routine to establish variable names.

The second core sits and watches for a position change in the first leg segment, and positions the second leg segment.

Right now I'm cheating a bit by making the first and second leg segment angles match (their angles cancel each other out), that way the third which is set at 180º is always vertical.

I'm working on making the second leg segment proportion adjustable (how to make that into a command parameter?). This will require a third core to monitor the first and second servos and add their angles to determine what angle the third leg segment needs to take to remain vertical.

Making individual legs work independently will be an easy step, because it just requires I add new pre-selections to the device list.

WHEN I get all this working properly, I will add a script to monitor the vertical angle of the rover, and have the legs respond to maintain vertical on uneven terrain.

Finally, I want the device to be able to walk on uneven ground like a bug, while maintaining vertical.

In addition there are a number of canned routines, such as stow and deploy, dismount the lander, jump.

Like somebody said before, kOS and robotics are like a challenging game within the game.

- - - Updated - - -

Question for the authors

It would be useful to have a way to check if a variable exists. Maybe there is and I'm missing it.

Right now, I'm running a script to load a mess of part module names to control various aspects of my robot.

Because the list is huge, I load it as a separate script before running my action scripts.

This is very useful because otherwise the delay induced by loading the big script causes long pauses in a series of actions called with parameters.

Right now I am doing this in devices.ks:

if AG10 = true {print "servos ready".}

if AG10 = false {...

(bunch of part lists)

...SET AG10 to true.

}

The action scripts then:

IF AG10 = false {RUN DEVICES.}

What would be really handy is a command to check if a variable name exists.

If exists("partmod"){...

[asmi]

Tried the mod yesterday, and found new features missing (or I don't know they exist) which I would really like to have:

1. user-defined functions. Any more-or-less complex program quickly turns into unmaintanable mess of code (tried to create a program for automatic powered lander that uses suicide-burn while keeping in mind the presence of atmosphere (I play with RealFuels, which fixes engine behaviour in atmosphere, but also complicates landing because actual thrust is less than in vacuum and not constant)- 3-way PID for orientation, plus additional one for throttle (for the very last stage of landing sequence, program times suicide burn such that it would bring vertical speed to 0.5m/s at 3 meters above the ground, and after it adjusts throttle to keep that speed until touchdown).

2. connected to previous one - ability to include other files (c-like #include would do). It would allow to reuse code without copy-paste.

3. Ability to control engine's gimbal (for those engine which can gimbal of course). Keep in mind that the engine can have several thrustTransforms for multi-nozzle engines - for example RD-180 has two, while RD-171M has four, and it would be best to have ability to control them independently (for example RD-180 provides roll control by vectoring nozzles in opposite directions).

4. I would like ability to control other CPUs on the same vessel (simplest example - having secondary CPUs on boosters, and start avoidance program (gimbal booster engine away from the core like Shuttle SRBs do) on them just after separation.

Is any of that in plans?

Thanks!

[kcs123]

It opens up all the following use cases:

• Other mods, like telemachus, remotely hosting kOS terminals inside them.
  
• Support for the people who like to build funky hardware dashboards for KSP.
  
• Let's face it, we'll never end up making the in-game terminal as nice to look at as something like xterm or putty. In an external window, you can overlap the windows nicer, tile them, do what you want, without them getting in the way of the main game window.
  
• Supports people running the game on multi-headed monitor setups. They can put their kOS terminals on another screen away from their game screen.
  
• Multi-player coop Artemis-style missions such as envisioned by the Go At Throttle Up mod.
  

Thanks for clarification, thinking about it, I find by myself that it could be usefull for people with 2 monitors or extra PC just for kOS terminal.

Specialy for people that want to make nice videos, kOS terminal would not use screen space, so craft can be shown with more zoom, etc.

Missed other possible usage, don't know if I would go for it, but it is good to know that can be used for that.

[Dr_Goddard]

Much better servo routine. This code is used to control groups of devices, rotatrons, extendatrons, etc., by a simple command giving device and angle.

//KOS
//A DEVICE LIST MUST BE LOADED TO SUPPLY THE DEVICE MOD
//TAKES COMMANDS IN THE FORM OF "RUN SEEK(X,Y)." WHERE X IS AN ANGLE OR TRANSLATION AND Y IS THE DEVICE.
declare parameter angle.
declare parameter sel.
SET HALTLIST TO LIST().//SETS UP A LIST TO CHECK IF ALL SERVOS HAVE REACHED THEIR SETPOINT
SET FVAL TO "ROTATION:".
//CHOOSING DEVICE
If sel = 0 {SET refmod to ROTMODS1.} ELSE IF sel = 1 {SET refmod to FOLDMODS1.} ELSE IF sel = 2 {SET refmod to FOLDMODS2.}ELSE IF sel = 3 {SET refmod to FOLDMODS3.} ELSE IF sel = 4 {SET refmod to ROTMODS2.} ELSE IF sel = 5 {SET refmod to ROTMODS3.} ELSE IF sel = 6 {SET refmod to EXTMODS2.}

IF SEL = 6 {SET FVAL TO "TRANSLATION:".} //CHANGES FROM ROTATION TO TRANSLATION AS REQUIRED. ADD MORE OF THESE IF MULTIPLE TRANSLATION DEVICES ARE USED.

SET x to 0.
SET BYE to 0.
	UNTIL x =1{
	SET INDEX to 0.
	HALTLIST:CLEAR().

UNTIL INDEX >= refmod:LENGTH{

			SET TIMECHECK TO TIME:SECONDS.
  			WAIT UNTIL TIME:SECONDS > TIMECHECK. 	

				//SETTING UP ANGLE DETECTION AND ACCELERATION
				SET RMOD TO refmod[INDEX].
				SET CURRENTPOS TO RMOD:GETFIELD(FVAL). 
				SET DELTA TO round(ABS(CURRENTPOS - ANGLE ),2).	
				RMOD:SETFIELD("fine speed", -0.08).    
				RMOD:SETFIELD("coarse speed", MIN(1,DELTA*.12)).
				IF SEL = 6 {RMOD:SETFIELD("coarse speed",2).}//NO ACCELERATION FOR EXTENDATRONS

					IF DELTA <=0.1 { //IF WE HAVE REACH SETPOINT THEN STOP
      					RMOD:DOACTION("MOVE -",false).
      					RMOD:DOACTION("MOVE +",false).
					HALTLIST:ADD(INDEX). //ADD THE INDEX NUMBER OF THE STOPPED DEVICE TO A LIST
										}		

    						ELSE IF CURRENTPOS < ANGLE { //MOVE +
      						RMOD:DOACTION("MOVE -",false).
      						RMOD:DOACTION("MOVE +",true).}

							ELSE IF CURRENTPOS > ANGLE {  //MOVE -
      							RMOD:DOACTION("MOVE -",true).
      							RMOD:DOACTION("MOVE +",false).}     

SET INDEX TO INDEX + 1.
					     }
IF HALTLIST:LENGTH >= REFMOD:LENGTH {SET X TO X+1.} //IF ALL THE SERVOS HAVE REACHED THE SETPOINT THEN BREAK.


		    }

[CorBlimey]

is kOS based on a particular language and syntax?