[1.3] kOS Scriptable Autopilot System v1.1.3.0

[kcs123]

16 hours ago, Steven Mading said:

Actually it changes the very thing you talked about earlier - power.  Now the power draw is based on how many instructions have *actually been* executed in the update, rather than how many could have been had it used the whole timeslice.  In other words if you have a loop that does one command then does a wait 0, it won't draw nearly as much power as a busy loop that calculates pi over and over and never stops.  So IPU does affect power draw that way too.  Running a program at 50 IPU uses less power than running it at 2000 IPU, unless it has lots of waits so it was never really using that full 2000 IPU anyway.

We would like to do away with IPU as a global setting across the whole mod and instead make it a feature of the "hardware".  i.e. because you are using THIS model, your IPU is only 50, but because your later design used THAT model, your IPU was raised to 2000, etc.

The only question is whether or not we'd also want to simulate the idea that older computers draw more power for the same IPU.  An old clunky model pays more power to achive 1 Mhz than a modern phone does to achieve 1 Ghz.

That is even better than I suggested. Since you have actualy use some checking what kind of commands are executed, can you also add checking if there is no programm runing at all, to consider as unit is shut off and does not consume any power.

For example, I want to include kOS CPU on each craft, even when I don't always need it, but there is a moments where manual pilot execution is much worse than something that is possible trough kOS. I wanted to try it, but I forgot to include kOS on my craft. Or, I put kOS on craft and forgot to turn it off on launching and because of that kOS drains battery.

That will make wish to inegrate kOS CPU in each cockpit/probe a thing even more. It should not be too hard to include it trough MM patches.
Check to see if player is already unlocked some kOS part and always integrate best one available. There could also be a check if cockpit have enough mass, so you don't need to add mass of kOS CPU to cockpit, but rather consider that it have enough space for kOS in it.

Very first available kOS part should not be integrated though, just fo have reminder how bulky and slow CPUs were in the past. Only new small surface attachable CPUs should be possible to integrate. But that is out of scope for kOS, I would probably do some small MM patch for personal usage when next version of kOS is released.
 

2 hours ago, hvacengi said:

KSP mentality: close enough to be realistic and challenging without being so complicated that it isn't any fun. 

Agree on that. And based on Stevens answer, I think that you are close to optimal solution on this topic. Messing with memory limits will just overcomplicated everything and draw you away from more important things to solve than this.

Different power drain based on executed commands as you are already included will bring some more interesting choices in game.
Should someone spamm more bateries and solar panels on craft to satisfy kOS CPU needs, or he will try to optimize code, to consume less power for the same thing ? That will encourage people to think more about coding, how to make cleaner, more optimized code, for better efficiency of whole craft (less mass = more dV).

Anyway, nice news on progress in development.

[Dunbaratu]

10 hours ago, kcs123 said:

For example, I want to include kOS CPU on each craft, even when I don't always need it, but there is a moments where manual pilot execution is much worse than something that is possible trough kOS. I wanted to try it, but I forgot to include kOS on my craft. Or, I put kOS on craft and forgot to turn it off on launching and because of that kOS drains battery.

It already is the case that if the kOS CPU's power is toggled off entirely it draws no power.  If it's on but not doing anything, it draws as much power as 1 IPU only (i.e. 1/200th of typical full power consumption.)  You can think of this as being in "sleep mode" with just enough running to be able to detect a command has been issued, and then wake up and go full speed so it can execute it.

Quote

Agree on that. And based on Stevens answer, I think that you are close to optimal solution on this topic. Messing with memory limits will just overcomplicated everything and draw you away from more important things to solve than this.

The challenge with the memory problem is for if people want to be able to replace programming with new versions of the file at runtime (a thing real probes do in fact do quite a lot as new software is beamed in from Earth).  The problem is we don't currently have any good way to *erase* the compiled opcodes of an existing program other than to just completely end the whole parent program and dump all the way back to the interpreter.  (Thus to get a good clean use of the new code and wipe out the old without a memory leak (a REAL one, in the actual KSP game process, as the old program is still present but nothing jumps to it anymore), you'd have to reboot and have a boot script that runs things back to the point you're at now.  "Cheers Kevin" has designed a system a bit like that specifically for that purpose that he used extensively in his kOS youtube career series.)

[kcs123]

I was apsent from KSP since 1.1.x is released, have a lot to learn to catch up with every change made, not only with kOS, bit with KSP and other mods as whole. You have probably already included something similar already, but is it possible to send data from one kOS CPU to another on the same craft ?

It is better to understand it on example. Upcoming GAP will going to include cargo transport contracts. I was thinking on craft that will have one main kOS CPU on vessel and other one on payload with some probe and second kOS CPU unit. Once you deploy payload from cargo bay, CPU on probe is activated and behave on it's own, but just before separation, main CPU should send some data to probe, about target area for landing etc. Probe will then do it's own thing, deploy parachutes when needed, landing legs/gears, open cargo bay, deploy solar panels, collect science research data, etc.

Or for some more violent people, use it as guided missile/smart bomb to hit a moving target. deployed probe should act on it's own, but use info from main craft that need to remain in physical area all time for everything to work in KSP.

Coding wise, it should be something like this:

On probe we have some function running in loop:
Probe_funcion(param1,param2,param3).

On main vessel, we set param1,param2 and param3 values as some stuff in gaming world changes, target moved or whatever. But those info is actualy used in program running on probe CPU

set Probe:param1 to some_value.
set Probe:param2 to some_value2.
set Probe:param1 to some_value3.

Or even better, call whole function that is declared in Probe CPU:

Probe:Probe_funcion( some_value , some_value2, some_value3).

 

I don't know exact kOS syntax from top of my head, but something like that. "Probe" should be non active vessel name or something similar, as much as I recall info from documentation about two crafts used in docking procedure when both are in physical range.

Is something like that already possible ?

[Dunbaratu]

 

15 minutes ago, kcs123 said:

 but is it possible to send data from one kOS CPU to another on the same craft ?

 

On the development platform, we have a comms system in place for inter-CPU communication and inter-vessel communication.  But it's not in public release yet.  The next release seems like it will be rather big in scope and have lots of new stuff so it will take a bit to get it ready.

Edited May 28, 2016 by Steven Mading

[kcs123]

Thanks, take your time with this, no need to rush it. That will just give me more time to learn how to use kOS

Nice to know that it is already on "to do" list.

[-ctn-]

Hi everyone, I was hoping I could get some help with my kOS script. I'm attempting script that will perform a suicide burn / SpaceX style landing, but I'm having some trouble. The craft descends just fine, it slows, but here's my issues:
1. The velocity at touchdown is around 6-12 m/s. I would like it to be 1-2 m/s. I'm not sure what I should do to ensure that.
2. Once the craft touches down, instead of shutting off the engine or program, sometimes it will full throttle and launch back into the air. I'm not sure what is going on there, either. The script still runs, and it literally bumps the ground and flies off.
3. I'm not sure how to get the program to end. Currently, if it lands correctly, I have to CTRL+C out of it. I would like the program to end on its own after completing a landing.

Here's my script (bare in mind, I'm not a programmer so I've tried to simplify things) :
 

Spoiler

//Powered landing script by Colin Thomas Nichols.

//Clearscreen, set up.
CLEARSCREEN.
set SASMODE to "STABILITYASSIST".
RCS ON.
PRINT "SAS engaged.".
PRINT "RCS engaged.".
PRINT "Landing Gear Ready.".
PRINT "Aerobrakes Ready.".

set current_throttle to 0.0.
PRINT (SHIP:STATUS) AT (0,30).

//If you assigned aerobrakes to action group BRAKES, extend them 8km above the surface.
WHEN ALT:RADAR < 8000 THEN {
BRAKES ON.
PRINT "Aerobrakes engaged.".
}

//deploy landing gear at 2km.
WHEN ALT:RADAR < 2000 THEN {
GEAR ON.
PRINT "Landing Gear engaged.".
}

//start loop. If you are 2m or more above the surface:
UNTIL ALT:RADAR < 2 {

	//if you are falling faster than 1 m/s:
	if -verticalspeed > 1 {
	
		//retrograde so you can kill horizontal velocity...
		lock steering to SRFRETROGRADE.
		
		//time to calculate parameters and variables!
		//calculate current gravity felt by craft.
		set gravity to (BODY:MU / (BODY:RADIUS + altitude)^2).
		PRINT "Gravity:" AT (0,15).
		PRINT ROUND (gravity,3) AT (25,15).
		
		//Calculate how long it will take to crash.
		set Ti to (ALT:RADAR/(-verticalspeed+gravity)).
		PRINT "Time until Impact:" AT (0,16).
		PRINT ROUND (Ti,3) AT (25,16).
		
		//set the throttle to our target TWR.
		set TWR to 1.8.
		set current_throttle to (TWR / (ship:availablethrust/(ship:mass*gravity))).
		PRINT "Throttle:" AT (0,18).
		PRINT ROUND (current_throttle,2) AT (25,18).
		
		//using throttle position, what's our new TWR? +0.01 to keep kOS from erroring.
		set target_TWR to (ship:maxthrust * current_throttle + 0.01) / (ship:mass * gravity).
		PRINT "Target TWR:" AT (0,19).
		PRINT ROUND (target_TWR,3) AT (25,19).
		
		set accel to (target_TWR*gravity).
		PRINT "Acceleration:" AT (0,20).
		PRINT ROUND (accel,3) AT (25,20).
		
		//Calculate how long it will take to burn.
		set Tb to (-verticalspeed/accel).
		PRINT "Burn Duration:" AT (0,17).
		PRINT ROUND (Tb,3) AT (25,17).
		
  		//Calculate the height at which to start the burn.
		set Db to (-verticalspeed*Tb)+(0.5*accel*Tb^2).
		PRINT "Burn Altitude:" AT (0,21).
		PRINT ROUND (Db,3) AT (25,21).
		
		PRINT "Current Altitude:" AT (0,22).
		PRINT ROUND (ALT:RADAR,3) AT (25,22).

			//Actual landing code. If time to impact is less than the burn time and current altitude is less
  			//than the burn altitude, lock throttle to 1.8 TWR. If under 40m, increase throttle to 2 TWR.
			//If under 20m, decrease throttle to 1.4 TWR. If under 5m, decrease throttle to 1.1 TWR. 
			//Otherwise, turn the throttle off.
			IF ALT:RADAR <= (Db*1.1) AND Ti <= Tb {
			lock throttle to current_throttle.
			} ELSE IF ALT:RADAR <= 40 {
			set TWR to 2.
			} ELSE IF ALT:RADAR <= 20 {
			set TWR to 1.4.
			} ELSE IF ALT:RADAR <= 5
			set TWR to 1.1.
			} ELSE {
			lock throttle to 0.0.}
			
		//wait for KSP to complete a physics tick.
		wait 0.001.
			IF SHIP:STATUS = "LANDED" {
			CLEARSCREEN.
			PRINT "Landing executed.".
			wait 2.0.
			SAS OFF.
			RCS OFF.
			wait 2.0.
			BRAKES OFF.
			CLEARSCREEN.
			BREAK.
			}
	}

 

Any help is appreciated, thank you. 

[drhay53]

I've never used KoS, but on the landing speed issue, have you tried increasing the TWR at your altitude boundaries?

[-ctn-]

3 minutes ago, drhay53 said:

I've never used KoS, but on the landing speed issue, have you tried increasing the TWR at your altitude boundaries?

I did, but if the TWR is too high, it seems to spin out of control when it reaches lower speeds (under 10m/s) because it's adding so much velocity.

 

[drhay53]

7 minutes ago, -ctn- said:

I did, but if the TWR is too high, it seems to spin out of control when it reaches lower speeds (under 10m/s) because it's adding so much velocity.

 

Yeah that'll happen. The two ways to control that are to lower the TWR or to have more control... how much RCS and/or reaction wheels does it have?

[-ctn-]

Sorry, I don't have a picture at the moment. It's two of the long 1.25m fuel tanks, the "Reliant" engine, landing legs, vernier RCS, 1.25m reaction wheels, air brakes, 1.25m battery and the 1.25m kOS module. I would think it would be plenty of control? I'll try different TWR values but I fear if I lower them more, it will just land/crash at higher than 12 m/s. And still do the bouncing-after-touchdown thing. 

[kcs123]

I didn't checked all of math equations, but on the first look it seems that you have miscalculated Time to impact.
I have similar working script, that is meant tu use along with SAS set to radial, to keep craft in vertical pitching, but you can easy adjust it for your personal needs.

Script is available along with other craft files, written a lot of coments inside to help somene to start using kOS. Have also few safe checks, so it can be use with high TWR crafts on any celestial body. Here is download link.

I wanted to explain it a bit more, why I did it like it is, but I didn't found time for it. Hopefully, comments inside will be enough, no need to bloat this thread with it.

[Cairol]

Be aware that the ALT:RADAR value is measured from the control part (or the instruments position?) and not from the lowest point of your craft.
So you should offset accordingly to make sure your script will terminate upon touchdown or slightly before touchdown.
This must be set for every craft individually.
So best would be to measure this offset on the ground in a test flight, or otherwise you have to estimate the distance
and feed it to your script as a parameter.

Don't use SAS in RETROGRADE mode and don't lock the steering to RETROGRADE on the last view meters,
because the retrograde marker will start to wander when you are about to coming to a stop.
Only use SAS STABILITYASSIST in the final phase.

[-ctn-]

Well, that makes a lot of sense. I'm guessing my craft is 12 meters high, because the control point is at the top and I keep landing around 12m/s. 

I'll try locking steering to UP or SAS stability assist and see what works best. 

I was hoping it could be a script that can be used globally with crafts, but I guess I should fine tune it for the particular rocket at the time? Hmm. 

EDIT:
Still having issues. Lands at about 10-15 m/s, bounces back up with engine full throttle and just flies straight up.
New code:
 

Spoiler

//Powered landing script by Colin Thomas Nichols.

//Cleearscreen, set up.
CLEARSCREEN.
set SASMODE to "STABILITYASSIST".
RCS ON.
PRINT "SAS engaged.".
PRINT "RCS engaged.".
PRINT "Landing Gear Ready.".
PRINT "Aerobrakes Ready.".

set current_throttle to 0.0.
PRINT (SHIP:STATUS) AT (0,30).

//If you assigned aerobrakes to action group BRAKES, extend them 1km above the surface.
WHEN ALT:RADAR < 8000 THEN {
BRAKES ON.
PRINT "Aerobrakes engaged.".
}

//deploy landing gear at 500m.
WHEN ALT:RADAR < 2000 THEN {
GEAR ON.
PRINT "Landing Gear engaged.".
}

//start loop. If you are 1m or more above the surface:
UNTIL ALT:RADAR < 7 {

	//if you are falling faster than 1 m/s:
	if -verticalspeed > 1 {
	
		//retrograde so you can kill horizontal velocity...
		lock steering to SRFRETROGRADE.
		
		//time to calculate parameters and variables!
		//calculate current gravity felt by craft.
		set gravity to (BODY:MU / (BODY:RADIUS + altitude)^2).
		PRINT "Gravity:" AT (0,15).
		PRINT ROUND (gravity,3) AT (25,15).
		
		//Calculate how long it will take to crash.
		set Ti to SQRT(2*(ALT:RADAR+6)/(-verticalspeed+gravity)).
		PRINT "Time until Impact:" AT (0,16).
		PRINT ROUND (Ti,3) AT (25,16).
		
		//set the throttle to our target TWR.
		set TWR to 1.8.
		set current_throttle to (TWR / (ship:availablethrust/(ship:mass*gravity))).
		PRINT "Throttle:" AT (0,18).
		PRINT ROUND (current_throttle,2) AT (25,18).
		
		//using throttle position, what's our new TWR? +0.01 to keep kOS from erroring.
		set target_TWR to (ship:maxthrust * current_throttle + 0.01) / (ship:mass * gravity).
		PRINT "Target TWR:" AT (0,19).
		PRINT ROUND (target_TWR,3) AT (25,19).
		
		set accel to (target_TWR*gravity).
		PRINT "Acceleration:" AT (0,20).
		PRINT ROUND (accel,3) AT (25,20).
		
		//Calculate how long it will take to burn.
		set Tb to (-verticalspeed/accel).
		PRINT "Burn Duration:" AT (0,17).
		PRINT ROUND (Tb,3) AT (25,17).
		
		set Db to (-verticalspeed*Tb)+(0.5*accel*Tb^2).
		PRINT "Burn Altitude:" AT (0,21).
		PRINT ROUND (Db,3) AT (25,21).
		
		PRINT "Current Altitude:" AT (0,22).
		PRINT ROUND (ALT:RADAR,3) AT (25,22).

			//Actual landing code.
			IF ALT:RADAR <= (Db*1.1) AND Ti <= Tb {
			lock throttle to current_throttle.
			} ELSE IF -verticalspeed < 20 {
			UNLOCK STEERING.
			} ELSE {
			lock throttle to 0.0.}
			
		//wait for KSP to complete a physics tick.
		wait 0.001.
	}
}

 

 

Edited May 28, 2016 by -ctn-

[hvacengi]

3 hours ago, Cairol said:

Be aware that the ALT:RADAR value is measured from the control part (or the instruments position?) and not from the lowest point of your craft.

This is incorrect.  `alt:radar` and `altitude` are both measured to the center of mass for the vessel.  I have gotten around this in my scripts by finding the location of the "lowest" part, and then decreasing the height by the dot product between the part's position and `ship:facing:vector`.  An additional offset is still needed to account for the size of the part itself.  This adjustment was the single biggest improvement I made to my landing scripts.

3 hours ago, Cairol said:

Don't use SAS in RETROGRADE mode and don't lock the steering to RETROGRADE on the last view meters,
because the retrograde marker will start to wander when you are about to coming to a stop.
Only use SAS STABILITYASSIST in the final phase.

I never use the built in SAS for landings, only cooked, but I've had no issues locking steering to `-ship:velocity:surface` on landing, at least not after I got throttle control figured out better.  I actually usually double the horizontal component to help with landing stability.  So long as you have a steady throttle and steering control, it is usually pretty clean.

3 hours ago, -ctn- said:

Still having issues. Lands at about 10-15 m/s, bounces back up with engine full throttle and just flies straight up.

In addition to the above changes, you may want to change your throttle calculation to be based entirely off of height, local gravity, and speed.  The iterative nature of KSP means that it will still be slightly off, but I regularly land around 1.5m/s with this throttle function:

function getThrottleForHeightVf
{
	parameter vel, acc, g, h, velFinal.
	// vel is the current vertical velocity
	// acc is the current available vertical acceleration based on current pitch
	// g is the local acceleration due to gravity
	// h is the height, it is very important that this is calibrated to
	// velFinal is the desired final velocity.
	// account for the offset of the bottom of the vessel from the CoM
	// negative values of tgtacc mean accelerating towards the body (down),
	// positive values mean accelerating away from the body (up).
	local tgtacc is 0.
	local thrtl is 0.
	set tgtacc to -1 * (velFinal ^ 2 - vel ^ 2) / 2 / max(h, 0.01).
	set thrtl to (tgtacc + g) / max(acc, 0.01).
	return thrtl.
}

Edited May 29, 2016 by hvacengi

[Cairol]

6 hours ago, hvacengi said:

This is incorrect.  `alt:radar` and `altitude` are both measured to the center of mass for the vessel.

Thanks for the clarification. The documentation says nothing about this.

BTW, I like to use the "lock" mechanism of kOS for such things as keeping the optimal throttle throughout the landing or whatever other value
is needed during the landing loop.
It makes the code cleaner.

Edited May 29, 2016 by Cairol

[ColKlonk]

Scenes from our next attraction:-

https://www.dropbox.com/s/v6ec9xoila6sw6z/ISS1_A.mp4?dl=0 (65MB)

A revamped and refined software version of an earlier video... but now 'we're' ready to test rendezvous and docking procedures.

:-)

[c_space]

Is it intentional that the KR 2042 b does not fit exactly to 0.625m parts? It seems to have a diameter of 0.5m or something.

Would I get side effects if I changed the rescale factor in the part cfg?

Edit:

 I changed the rescale factor in the part.cfg to 1.25 and now it fits perfectly to mk0 parts. I played for a couple of days now and have not noticed any side effects.

Edited June 3, 2016 by c_space
Added response.

[MAFman]

I'm trying to think of/design a rover driver script that senses terrain slope in all directions 10m away and continuously navigates to a goal LATLNG() while avoiding steep slopes. Can someone help me with this?

[RocketSquid]

10 hours ago, MAFman said:

I'm trying to think of/design a rover driver script that senses terrain slope in all directions 10m away and continuously navigates to a goal LATLNG() while avoiding steep slopes. Can someone help me with this?

I have been trying to do something like this for a while. I think the best way would probably be to have the rover look for slopes between it and the destination and:

• If there is a slope ahead of it, check for slopes to the left and right to find the shortest path and take it.
• If there is not a slope ahead of it, move forward until it reaches an unsafe slope or its target.

Also, is it possible to GET the current WHEELTHROTTLE value?

Another question: Can kOS get resource concentrations from scanners?

[Dunbaratu]

11 hours ago, MAFman said:

I'm trying to think of/design a rover driver script that senses terrain slope in all directions 10m away and continuously navigates to a goal LATLNG() while avoiding steep slopes. Can someone help me with this?

To obtain the slope of an area, you first obtain the normal vector to the "terrain plane" of that area.

To get the normal vector to the terrain plane, take 3 sample 3-D positions nearby each other (that aren't all in a straight line), labelled in clockwise order, A, B, and C.  The normal of the terrain plane at A is:

local norm is VCRS( (B - A, (C - A) ).

The angle between that normal and straight up at position A is the slope angle of the terrain there.
 

local terrain_bank_angle is VANG(norm, (A - the_body:position) ).

 

[dewin]

I'm working on a library (lib_orbit.ks and family here) to handle a bunch of orbital match.  It currently can convert either an Orbit/Orbitable or a set of position and velocity vectors into a rather lengthy Lexicon of orbital parameters (I'd love proper classes or a way to construct my own Orbits!... someday), intended uses being to predict a series of maneuvers without needing to create nodes and so forth.

I've noticed a surprisingly large amount of what I assume is floating point error in a few cases -- basically small* differences in what the game reports vs. what my calculations show.  (This is especially prevalent in cases like ... attempting to calculate position from an orbit rather than using obt:position-obt:body:position).  I know that sometimes the order of operations or whatnot can be changed to reduce floating-point error, so I'd be interested in seeing if that's the case for me or not.

But more interestingly, I've noticed a discrepancy between some parameters of obt and corresponding parameters of ship:

print obt:velocity:orbit - ship:velocity:orbit.
V(-0.00268574888173134, -0.00161378149967106, -0.00374235661232092)
print obt:velocity:orbit - orbitat(ship, time:seconds):velocity:orbit.
V(0, 0, 0)
print obt:position - ship:position.
V(2.98667690483853, 4.64475975453388, 13.1080628449563)

The magnitude of these errors increases at higher factors of timewarp, which leads me to believe it's not just floating point error due to something being calculated two different ways.

What exactly is going on here?  I suspect that kOS's update tick is happening in between one of those values changing and the other.  So, for giggles, I ran:

on time { print "o: " + obt:velocity:orbit:mag + "; v: " + ship:velocity:orbit:mag. preserve. }
o: 671.817348836739; v: 671.820151951602
o: 671.814845544989; v: 671.817648632772
o: 671.811414942815; v: 671.81421800491
o: 671.808185942693; v: 671.81098897715
[...]

(Again, differences magnified under timewarp).  So, if I want the most accurate calculations, should I be going off the values of obt or ship?  The former seems to be slightly ahead of the latter.

[ColKlonk]

10 hours ago, dewin said:

What exactly is going on here?  I suspect that kOS's update tick is happening in between one of those values changing and the other.

Most likely the case.

I read a KOS vector/variable to my own variables, then use these across time ticks as these don't change.

[dewin]

Just now, ColKlonk said:

Most likely the case.

I read a KOS vector/variable to my own variables, then use these across time ticks as these don't change.

That's not what I meant; the comparison here is happening in a single update tick.

What I think is happening is something like:

1. KSP updates orbital position.

2. KOS does its update tick.

3. KSP updates physics position.

hence the desync between obt and ship.  (Note that the every line of the ON TIME loop corresponds to a single KOS update).

[ColKlonk]

I saw it in here somewhere...

http://ksp-kos.github.io/KOS_DOC/general/cpu_hardware.html?highlight=tick

[ColKlonk]

Would it be possible sometime, in future versions, to make the terminal background transparent, or give the ability to switch the terminal graphics off completely, but leave the text.

Here I'm fiddling with the terminal textures, but cannot seem to get the alpha channel nailed