kOS Scriptable Autopilot System 0.9

[Camacha]

Sorry if this has already been asked but what does the "^" symbol mean? I've seen it in a few example scripts and have no idea.

It is a mathematical operator, meaning the exponent or raised to the power of. See the Wikipedia article here. In normal math it would be written as a number with a superscript smaller number next to it, but as not all computers/fonts can do this, the ^ is used instead.

Normally 2^2 is written as (I hope the picture shows):

9,81^2 means 9,81 x 9,81 or 96,2361.

3^3 means 3 raised to the power of 3, which means 3 x 3 x 3, which equals 27.

2^8 = 2 x 2 x 2 x 2 x 2 x 2 x 2 x 2 = 256.

[Kass]

Thanks Camacha for the great answer, + rep for you . I'd seen the raised to the power stuff in other scripts but never realised these were one and the same. Hopefully some of these equations will make more sense to me now.

I'd never realised how maths heavy coding could be. Definitely looking at the whole area of computer coding with a new found level of respect.

[Camacha]

Thanks Camacha

You are welcome. I do my best to help people with the little knowledge I have.

I'd never realised how maths heavy coding could be. Definitely looking at the whole area of computer coding with a new found level of respect.

Yes, math and coding are interwoven, especially when you are coding for something that has to operate according to the laws of physics (which is just applied math). I have picked up my math books again too, as my math was getting a bit rusty and it is a great tool to have, both for fancy kOS projects and in real life. If you understand the fundamentals it is easily applied to pretty much every aspect of life, whether that is engineering, business, personal budgeting or anything else. And I would never have thought I would say this ten years ago, but if you truly engage in it instead of trying to understand the least necessary you can actually have quite some fun with it too.

Edited November 29, 2013 by Camacha

[goldenpeach]

Really cool plugin: I can't stop myself from making small programs(for learning the KOS language).

The best I have done yet: a rocket that goes up,full throttle, until it reach 3000 meter, after it has reached that altitude, it head to the north(45 degrees above horizon) and cut the engine after 5 seconds.

I may need to work a little before going in space

[Sma]

Really cool plugin: I can't stop myself from making small programs(for learning the KOS language).

The best I have done yet: a rocket that goes up,full throttle, until it reach 3000 meter, after it has reached that altitude, it head to the north(45 degrees above horizon) and cut the engine after 5 seconds.

I may need to work a little before going in space

It may be better(fuel wise) to wait until 10,000m to start your turn to 45. Though you could start turning in smaller amounts starting at 3000 or so, like 80, 70, 60 etc until 45.

It is pretty fun exploring the programming possibilities.

You could even write a program to track fuel use and different gravity turns. You could use the log function to record the amount of fuel left at a certain altitude, or how long the fuel lasts and at what altitude it runs out, if your rocket isn't able to reach full orbit. I forget exactly how it works, but I believe

log altitude to fueltrack.
log stage:liquidfuel to fueltrack.
log missiontime to fueltrack. //I dont think missiontime is the actual variable, I don't have KSP running atm and I haven't really checked mission time before so I don't know if that's it or not.

Best bet is to check the kOS wiki and see if you can find something there to help.

Edited November 30, 2013 by Sma

[Camacha]

It may be better to wait until 10,000m to start your turn to 45. Though you could start turning in smaller amounts starting at 3000 or so, like 80, 70, 60 etc until 45.

It is pretty fun exploring the programming possibilities.

It depends on whether you are using FAR or not However, try to make launch programs that do not so much depend on set commands at certain set points, but make them variable according to parameters. That way it is easier to adapt your script to different bodies.

[Sma]

It depends on whether you are using FAR or not However, try to make launch programs that do not so much depend on set commands at certain set points, but make them variable according to parameters. That way it is easier to adapt your script to different bodies.

That is true, about FAR I just assumed starting out and using small programs FAR might not be in play. Same with using the set amounts at certain set points, though yeah, I guess it would be better to do it as you mentioned. I was just going with whats easier for someone starting to learn the ropes so to speak.

[goldenpeach]

How can I make an input for the user?

Is there a way to make that the value of a variable is set by the user without having to edit the program?

[AbeS]

with declare parameter you can, but any other user input needs to be done with action groups

[goldenpeach]

What do I have to do?

declare x. ?

[Draft]

the command includes the 'parameter'. So a file named test with

DECLARE PARAMETER X.
PRINT X.

, if called with RUN test(5). would then print 5.

[goldenpeach]

Ok,tank you!

I will try that when I will be able to make code that do what I want the to do(I have done a few, but as soon as i try a more complex code(like making a code that keep a rocekt at a constant speed(assuming that the rocket stay vertical)) .

[AbeS]

constant velocity is really tricky! you need to mess with drag, gravity and thrust, and if you're using FAR it's even harder

Not sure why you would want constant vel though, unless you are in space (which means a circular orbit)

[Kass]

I've found that constant velocity can be achieved on of two ways.

Method A is quite simple and is simply based on reading a variable as being true or not then assigning an output. For example:

(Please comment if this is wrong at all. I'm literally learning coding as I go along just to play with this mod so any input will be gratefully and gracefully received)

set g to 9.81. //gravity in m/s//
set TWR to (g*mass)/maxthrust. //this should set up the throttle so that it achieves just enough force to counter gravity and scales as fuel is burnt//

until ship:liquidfuel > 15 // The stage:liquid fuel doesn't seem to work for me, don't know why.  Tried testing it with print and everything lol.//
     {
     if vertical speed < 130
         { lock throttle to 2*TWR. //for a 2g burn. change the (changing the multiplication factor should change the g at which the burn is performed)//
         }.

    if vertical speed > 150
        { lock throttle to 0.
        }.
stage.

If I'm right this means the throttle will bounce up and down within the selected speeds. It doesn't account for drag but on streamlined rockets vertical drag should be minimal anyway. There will be some overshoot but it's quick and easy to program. Should work for almost anything and takes 2 seconds to change for all ship types. However it's not good enough for what I'm trying to do so I've moved onto method B.

[Kass]

Method B is by using a PID controller type algorithm. This is a considerably more difficult and I haven't yet figured it out.

Unlike method A it allows an analogue input on the throttle that scales to the speed required as opposed to the digital input of method A, ie, instead of the throttle simply being on or off it will increase or decrease the throttle by the exact amount required (when tuned) to achieve whatever variable you set in the program.

Now I've started writing on of my own but I need a couple of pointers from those who know what they're doing (please )

Basically I've wrote a program with a section that basically says

lock throttle to P.
until ship:liquidfuel > 15

	if setpoint < alt:radar + verticalspeed {
		set error to (setpoint - alt:radar)*1.
	}.
	if setpoint > alt:radar + verticalspeed {
		set error to (setpoint - alt:radar)*-1.
	}.

	set P to error*TWR.

}.

Now my problem is I think I only half understand what I'm trying to do here and if someone could explain this to me I'd be very grateful.

Basically I'm doing P = Setpoint - error*gain. Through trial and error and debugging I realised that one of the gains needs to be a negative number to turn it back into a positive for input to the throttle while the other needs to remain as a negative as I don't need the input as it would be above the setpoint. My problems are I don't understand what the rest is trying to achieve. The gain I've set at 1 just because I don't understand it and therefore I change the input to a positive from a negative without affecting the output of setpoint - error.. I also put a gain on the other half of the algorithm just to keep things equal.

What is this number doing please and why?

Now where I've set P to error *TWR I've only done that so it scales with the vehicles mass, but I know it isn't right. What this is doing is applying way to much thrust and my debugging console is giving my a result of infinity. in the picture below you can see that the P number is infinity. Where am I going wrong here please and most importantly, why? What am I trying to achieve here?

I really want to understand this and I feel I'm almost there (otherwise I'd just use mechjeb or copy and paste someone else's script).

Thank you in advance

Edit to explain values.

vertical speed = verticalspeed

hover timer =1 cycle of the until statement +1 to a value I set to make sure it's cycling

current error = setpoint - alt:radar*1 or setpoint - alt:radar*-1 depending if if above or below the setpoint.

previous error is the error previous to this that is set to perror at the end of each cycle

error difference = error - perror

Proportional = error*TWR

Throttle = throttle

Height offset = setpoint - alt:radar

Edit 2: wtf is wrong with me? Writing scripts is fun!!

Edited November 30, 2013 by Kass

[ouch]

so I have a rover that follows another one, but whenever the rovers are not on flat land they veer wildly off course... (seems the angle of the rover running the script is the determining factor)

my steering code looks like this:

lock ts to vessel("battery").

lock wheelsteering to ts.

battery is the name of the rover I'm following. (ultimately I would to get them to dock at some point but I can't even try if they go in random directions when on a hill because wheelsteering told them too...)

also how do you get the position of an object? I was going to try to specify the of the location of the other rover directly and hope that fixes it.

[CrAzY GeNiUs]

until 0 {
     if altitude > 10000 {set p to -1.}.
     if altitude < 10000 {set p to 8.}.
     if target:distance < 300000 {run l.}.
}.

Need HELP !

[razark]

Need HELP !

A. What do you want to do?

B. What have you tried?

C. What happened?

D. What didn't happen that should have happened?

E. We don't read minds.

F. "There was an error." is a useless bug report.

Edited November 30, 2013 by razark

[Dunbaratu]

I get the feeling this naming thing is important to you, possibly too important. In itself it is no reason to remove the variable from the system.

I haven't been arguing for removing it. I've been arguing for making it correct. It is incorrect to claim it's positive when it is in fact not because the simulation doesn't match reality. In the game if your apoapsis is higher than SOI then it's not honest to report it as if it's not infinity. As far as the GAME cares, it's infinity. You're not coming back down.

[Camacha]

I haven't been arguing for removing it. I've been arguing for making it correct.

True, but in correcting it you are removing functionality. Like I said before, I feel the way things are named is important to you and while it would be nice to have things labeled correctly, functionality is more important than nomenclature. You really should not remove functionality until there is a viable alternative that does the same.

[Dunbaratu]

Yes, right. I don't see the discrepancy between two models in KSP (patched conics, Kepler orbits) as a problem but as a feature. That's why it is really hard for me to follow your reasoning. The problem does not go away as long as KSP is based on those models to build its universe. And while you are within the SOI everything matches.

I guess the reason we're arguing is that the manner in which the current system is broken is useful for you and broken for me. It is currently impossible to detect whether or not I've been captured. Getting to where it reports the bogus negative value for apoapsis does not imply I'm captured. Because of the game's SOI radius issue you can have a positive apopasis and yet still escape and not come back. That's rather important when you want your autopilot to burn retro long enough to get captured but not long enough to circularize, as that's wasteful to do. As it is I have to make a pure guess and say if I've gotten it down to about 60% of escape velocity that's probably small enough to be within the SOI of things in the KSP simulation - maybe. But those sorts of guesses often turn out to be wrong, as it's not the same for every body. the SOI radius is an arbitrary decision that doesn't seem to follow a pattern. It doesn't seem to be based on a calculatable thing but rather is an arbitrary decision SQUAD made for each body. In some cases, like Ike around Duna, the SOI is a lot smaller than you'd think, apparently because Ike's closeness to Duna would make it interfere with Duna orbits if it had too large of an SOI.

The problem is that you're basically saying your problem is important and mine is irrelevant when you qualify the current behavior as "correct" and claim it should be left in place in favor of a nebulous non-existent solution.

[Dunbaratu]

True, but in correcting it you are removing functionality. Like I said before, I feel the way things are named is important to you and while it would be nice to have things labeled correctly, functionality is more important than nomenclature. You really should not remove functionality until there is a viable alternative that does the same.

I am NOT arguing for removing functionality. Being able to detect if you're going to escape the body or not *is functionality*, and it's functionality that you're ignoring when you decide to mislabel wanting to have that functionality as "removing" functionality.

(EDIT: OR to be more generous to your position, I'm swapping one functionality for another, which is at worst a null effect on total functionality, not a drop in functionality).

And while you *can* calculate things like eccentricity from a negative apoapsis, it's not the ONLY way to do it. So the functionality you're talking about isn't gone, just more ugly to get. Compare that to the functionality you're arguing I shouldn't have. It's not derivable mathematically. There's no alternate recourse for it. Given your current position and velocity and the planet's mass is enough on its own to derive everything else. It might not be pretty but at least it's actually *possible* to calculate with what's there now, unlike the problem I'm talking about where no amount of math will help learn what SQUAD set the SOI to for each body.

So I'd be fine with restoring the broken definition of apaopsis to allow it to be negative if it coincided with also being able to get SOI data about the bodies *at the same time in the same release*. But what you and boalan have been arguing for is to fix the ability to calculate using a negative apoapsis FIRST and then eventually later on, if time permits, get around to fixing the apparently less important problem about how you can't get correct ("correct" meaning "works for the purpose of flying a craft in this simulation", meaning "takes into account the simulation's SOI feature") escape information.

And if one problem can be fixed with a workaround and the other can't, the one that can't is more important.

So to summarize my position:

Fix the SOI problem first and restore negative apaopsis later. - I'm fine with this.

Fix the SOI problem and restore negative apoapsis in the same reliease - I'm fine with this too.

Fix the SOI problem later and restore negative apoapsis now - I'm not fine with this for the reasons stated above. The SOI problem *requires* getting information from KOS as there's no alternative way to calculate escape mathematically right now. There *is no* workaround right now. There are, however, workarounds to not being able to see a negative "apoapsis".

Edited November 30, 2013 by Steven Mading

[Dunbaratu]

until 0 {
     if altitude > 10000 {set p to -1.}.
     if altitude < 10000 {set p to 8.}.
     if target:distance < 300000 {run l.}.
}.

Need HELP !

This post contains no useful information.

[goldenpeach]

constant velocity is really tricky! you need to mess with drag, gravity and thrust, and if you're using FAR it's even harder

Not sure why you would want constant vel though, unless you are in space (which means a circular orbit)

Yeah, I saw that achieving a constant velocity is harder than I though.

To answer your question: I don't to keep a constant speed, I want to make a script that will keep the rocket to a given speed(I will use that to limit the speed to terminal velocity).

For now, I try to keep a constant speed because, if I can't do that, I don't see how I could make the rocket to go at a given speed!

EDIT: for now, the way my script work, is simple: if the rocket is below the required speed, it throttle up and if it's above, it throttle down.

The problem is that the rocket will throttle up/down all the time all the time it's not at the correct speed. That mean that it will accelerate too quickly and overshoot, then it will throttle down too much and get too slow, throttle to much and do the same thing until there is no fuel left.

Will have to work on that a little!

Edited November 30, 2013 by goldenpeach

[AbeS]

A simplistic way that works is:

Set PM to 5.2915793*(10^22). // Planet Mass (Stock Kerbin)
Set PR to 600000. // Planet Radius (Stock Kerbin)

set e to 2.71828. // constant 'e'
set G to 6.67384*(10^-11). // Gravitational Constant

until altitude > 35000 {
	Set m to mass.
	Set r to PR + altitude.
	set FG to m*G*PM*(r^-2). // Gravity Force

	set p to (e^((0-altitude)/5000)).
	set rho to 1.2230948554874*p.
	set v to velocity:surface:mag.
	set FD to rho*v*v*0.0008*m. //Drag Force (without FAR!!)

	if FD > FG and t>0 {set t to t-0.05.}.
	if FD < FG and t<1 {set t to t+0.05.}.
}.

Edited November 30, 2013 by AbeS