[1.3] kOS Scriptable Autopilot System v1.1.3.0

[Dunbaratu]

Other Linux users have reported success using this mod:

http://forum.kerbalspaceprogram.com/threads/108561-0-90-%28Jan25-15%29-Control-Lock-Input-text-into-text-fields-without-issuing-commands-to-your-vessel?highlight=kos

It basically lets you override how the game is delivering your keypress events to different parts of the game, and force them to go to the window you want. The likely reason you're having trouble is that the R and E keys are being consumed by some other mod or some part of the stock game before kOS is allowed to even know they exist.

[kurja]

thanks, I was able to get going with that. I don't have a lot of mods, just the kerbal engineer, planetshine & engine light, and now these (kOS and the control lock mod).

KOS look like it's going to be a lot of fun, I managed to get a rocket to orbit already and there are a lot of things that I want to try : ) On my way to ever greater adventures, I have two questions:

can I somehow query the current throttle setting like it was a variable? I couldn't figure out how to. And is there a simple way to find out twr with current throttle setting? I did a search and found methods calculating it using data from science instruments which seemed a little complicated for my math skills, so I used

set tlim to 2. //goal twr
set twr to ((maxthrust * tset) / (mass*10)). //calculating thrust to mass ratio
set tset to tset + ((tlim - twr)*0.1). //adjust tset (which adjusts throttle) 

to make a twr or rather a thrust to mass limiter, but the value doesn't really come close to what ker tells me ym twr is like I think it should.

[Dunbaratu]

re Question 1:

My suggestion:

set mythrot to 0.1.
lock throttle to mythrot.
// From now on when you want to change throttle, do it indirectly by chaning mythrot.  When you want to print the throttle, print mythrot instead.

re Question 2:

Why does your code multiply the mass by 10 when calculating TWR? Why not use 9.802?

Without quantifying "the value doesn't really come close" it's hard to say anything more than that.

[kurja]

re Question 1:

My suggestion:

set mythrot to 0.1.
lock throttle to mythrot.
// From now on when you want to change throttle, do it indirectly by chaning mythrot.  When you want to print the throttle, print mythrot instead.

re Question 2:

Why does your code multiply the mass by 10 when calculating TWR? Why not use 9.802?

Without quantifying "the value doesn't really come close" it's hard to say anything more than that.

That's what I did, "tset" in my code snippet is locked to throttle, I should have been more clear about what does what in the code I posted. That works, I just felt it would have simplified the program if I could have queried it directly.

Multiplying by ten is purely a brainfart on my behalf =D Should have used 9.8 like you said. I had the limiter set to 2 and KER told me my twr was going up to 2½ before the limiter kicked in, I don't think an error that large could be from using ten instead of 9.8 as multiplier but using the correct value certainly would be a move in the right direction! KER afaik always shows twr pertinent to weight as it changes with elevation which would also contribute to the error, I have to look into using ship:sensors:grav:mag maybe.

[Dunbaratu]

using ship:sensors:grav:mag maybe.

Do you think the difference is entirely due to not being at sea level when you calculate it? I didn't realize from your original description that you were doing this up in orbit and not down on the launchpad. Yes, that is a definite potential problem - the meaning of TWR changes depending on what W you meant - weight NOW up in orbit or weight later when down on near the ground.

Of course, you don't need to actually measure the local gravity with a sensor if you don't want to - you could just calculate it from your altitude and known data about the SOI body. Some have called this "magic data" that the craft should't have access to, but I say any space program sending a probe somewhere is already going to know the mass of the planet from orbital perturbance data observed back home, and presuming you have a means of calculating your altitude you can know your radius from the body's center. That's all you need to get a calculated estimate of the local gravity at a given spot in space above the body.

function local_g {
  parameter ves. // the vessel to calculate local g value for.

  return constant():G * (ves:body:mass/(ves:altitude+ves:body:radius)^2).
}
// Now you can replace the "9.8" or the "10" in your code with a call to local_g(ship),
// like so:
set twr to ((maxthrust * tset) / (mass* local_g(ship) )). //calculating thrust to weight ratio

[kurja]

I was doing the calculation continuously for the ascent of my rocket, so yes it did change. Reading sensors:grav seems to work well now that I tried that, the error I had is gone. although it requires that I have the instrument on board, so thanks for posting the formula for local g!

[damerell]

after issuing

edit hello.

some of the keys won't work; that is I am unable to correctly type the print hello command into the script, I get

pint "hllo".

instead. Is this a known issue?

As a workaround, I suggest never using the in-game editor; you can edit kOS scripts saved in KSC's storage with a proper text editor. This is also much easier.

[kurja]

As a workaround, I suggest never using the in-game editor; you can edit kOS scripts saved in KSC's storage with a proper text editor. This is also much easier.

Sure, that's what I do. Being new and figuring out what's what the in-game editor is an obvious thing to start with but it's not really useful for anything larger than a couple lines.

[kurja]

oops, double

[Dunbaratu]

Livestream announcement

Another episode tonight: UTC-5 (U.S. CDT time), Tuesday 7pm-9pm.

I'm hoping to make this a weekly thing, but I haven't committed to it yet because I haven't picked a good day of the week that I can always keep reliably free and available:

Let's k-OS with a kOS dev. This episode will be: Trying to make landing autopilots, part 2.

[Lookerksy]

How can I get terminal velocity of the vessel in air?

I find "SHIP:TERMVELOCITY" at http://ksp-kos.github.io/KOS_DOC/.

But it seems to not work in least version.

Thanks.

[kurja]

How can I get terminal velocity of the vessel in air?

I find "SHIP:TERMVELOCITY" at http://ksp-kos.github.io/KOS_DOC/.

But it seems to not work in least version.

Thanks.

it returns "as of kos 17.2 termvelocity is obsolete" so I guess it has been.. obsolited? Can't it be calculated with available information if you need it?

edit - here's a post about it, the "ksp constants" probably aren't valid anymore since recent aero overhauls but it's a starting point...? http://forum.kerbalspaceprogram.com/threads/98184-Wrong-results-calculating-terminal-velocity

Edited August 5, 2015 by kurja

[Dunbaratu]

it returns "as of kos 17.2 termvelocity is obsolete" so I guess it has been.. obsolited? Can't it be calculated with available information if you need it?

What makes it exceptionally hard to return a simple single number for it is that with the KSP 1.0 aero model, terminal speed is shape and rotation dependant. If your rocket is aimed nose-first like an arrow, it has much higher terminal speed than if it's pushing sideways through the air. If the rocket is tumbling and rotating, this means it's going to have a constantly changing terminal speed from one instant to the next depending on its orientation.

That's why it became obsolete in kOS 0.17.2 - because the stock game changed in such a fashion that it's no longer a simple universal value.

[Ralathon]

Is there some way to determine the total torque a reaction wheel provides, the maximum thrust of an RCS thruster, the maximum gimbal of an engine and the total moment of inertia of the vessel?

My steering script in RSS currently needs custom PID parameters per vessel. So I'm trying to build something that automatically tunes the PID. I could probably approximate the moment of inertia in the yaw and pitch direction by playing with the mass and position of each part, but that leaves the roll and it's not very elegant...

[Qigon]

it returns "as of kos 17.2 termvelocity is obsolete" so I guess it has been.. obsolited? Can't it be calculated with available information if you need it?

edit - here's a post about it, the "ksp constants" probably aren't valid anymore since recent aero overhauls but it's a starting point...? http://forum.kerbalspaceprogram.com/threads/98184-Wrong-results-calculating-terminal-velocity

I'm slowly working on a script that calculates drag online, which should be enough to compute terminal velocity then. But it's still an approximation since it depends on a gravity sensor and doesn't account for motor gimbal (anyone knows how to do that?)

It goes slowly because I only work on it when flying my Zz SSTO, and that doesn't happen often.

Credit goes to another poster who wrote most of it, and that other guy who put together the math.

I'd like to have it published on the examples repo, if they agree and still didn't publish it.

[TDW]

I'm slowly working on a script that calculates drag online,

I'd like to have it published on the examples repo, if they agree and still didn't publish it.

Please do submit it. You can create a pull request for it on the ksLib before it's finished (it can be labelled as "don't merge yet" until you are happy with it).

Edit:

what does fuel_flow * vxcl(ship:up:vector,ship:velocity:surface) mean? Should I ditch it considering the last posts? I'll try plotting it separately anyway.

Sorry I missed this a while back. Yes you should remove that part of the equation.

Also worth pointing out that using the accelerometer experiment readings for this means that any unaccounted for forces will be considered to be part of the lift/drag (this includes RCS, Reaction wheels, engine gambol and any phantom forces) which will give odd readings in space. The further the accelerometer is placed from the centre of rotation the larger the false reading will be.

Edited August 6, 2015 by TDW

[Qigon]

Please do submit it. You can create a pull request for it on the ksLib before it's finished (it can be labelled as "don't merge yet" until you are happy with it).

Edit:

Sorry I missed this a while back. Yes you should remove that part of the equation.

Also worth pointing out that using the accelerometer experiment readings for this means that any unaccounted for forces will be considered to be part of the lift/drag (this includes RCS, Reaction wheels, engine gambol and any phantom forces) which will give odd readings in space. The further the accelerometer is placed from the centre of rotation the larger the false reading will be.

Good to know on the don't merge thing

My plan is not relying on the accelerometer, so torque/vibrations won't play at all. As a plus, you can have it on any ship. The idea is having a global var to hold last velocity and time. Is there something like a namespace for libs, or any global naming conventions if that's missing? I'm not well versed in kOS.

Anyway, globals are like kids/f*rts: you can only stand your own.

I'd also like to integrate drag over time. It can be interesting for checking out the plane 's envelope and climbing rates.

BTW it's been fun using it on reentries, you can see lift go around as you roll unbalanced crafts.

[damerell]

That's why it became obsolete in kOS 0.17.2 - because the stock game changed in such a fashion that it's no longer a simple universal value.

Stupid question, perhaps, but it still seems a meaningful concept; NanoGauges can display it, for example (perhaps only in a FAR world?), and it seems it could be derived from dynamic pressure, surface velocity, mass, and gravity.

[TDW]

Good to know on the don't merge thing

My plan is not relying on the accelerometer, so torque/vibrations won't play at all. As a plus, you can have it on any ship. The idea is having a global var to hold last velocity and time. Is there something like a namespace for libs, or any global naming conventions if that's missing? I'm not well versed in kOS.

Anyway, globals are like kids/f*rts: you can only stand your own.

I'd also like to integrate drag over time. It can be interesting for checking out the plane 's envelope and climbing rates.

BTW it's been fun using it on reentries, you can see lift go around as you roll unbalanced crafts.

You might like to take a look at how lib_pid.ks works. It handles both looking at data change over time and preserving the old info between function calls.

Lists and other complex variables are treated as pointers so if you [set foo to list().] then [set bar to foo.] foo and bar are just 2 ways of calling the same object so changes made to the list by [bar:add( ).] will be seen when you call foo.

This lets you create an init function that returns a list and have the parent script decide the variable name. Then when you pass the list name to the running function it can make changes to the list held by the script above it.

Since the variable name is set by the parent script naming conflicts can be avoided without needing to dig into the function and change every use of the variable name to something else.

Edited August 6, 2015 by TDW

[falken]

How possible would it be for KoS to sort out some sort of gimbal trim with standard gimbal engines? My shuttle is able to get to the SRB cutoff stage, but it's unable to adjust the shuttle engines for center of mass after SRB sep.

I miss Gimbal Auto Trim so much!

[saabstory88]

Greetings,

I am having trouble finding the answer to this. I am working in a Realism Overhaul environment, and do not care to be bothered by disk mass, which is becoming an issue. Is this baked into the code, or is it configurable? If it is baked, how hard would it be to recompile without disk mass?

Answer: Hard, but I got it done

Edited August 8, 2015 by saabstory88

[Chickenkeeper]

I seem to be having problems with throttle commands, all the throttle commands work in the terminal (except for LOCK MAINTHROTTLE etc. which never seems to work at all) but do nothing when running from a script. It's definitely nothing to do with the script not being updated or saved as I've tried making other changes to the script such as modifications to PRINT and STAGE commands, and they work fine. The throttle however remains completely unresponsive. Has anyone else experienced this?

[Chickenkeeper]

Never mind, I was just being a dumb dumb. The throttle wasn't working because the program was ending as the throttle was being set, so the throttle ended up resetting back to its previous state instantly. I've made some modifications and everything works fine now.

[falken]

What is the command to unlock the steering? I'm finding that mechjeb's smart ASS SURF is better for a particular maneuver later on in the ascent profile. What I am doing right now is having my KOS program launch my shuttle, do the roll program and the gravity turn, as well as staging the SRBs. When a certain altitude is reached, the program ends and SURF takes over immediately, putting the shuttle into the non-inverted stage of the ascent.

What I'm wanting to do instead is have the program unlock the steering at this point but maintain control of the throttle so that when 35km Periapsis is achieved, MECO happens.

e: Actually, is there a wait until speed command? So I can have the steering unlock at say 2500m/s surface speed?

Edited August 9, 2015 by falken

[Dunbaratu]

What is the command to unlock the steering?

uhh... it's UNLOCK STEERING.

Actually, is there a wait until speed command?

The command's pattern is WAIT UNTIL whatever.

Where whatever is any sort of expression that results in a Boolean true or false.

So you could do:

WAIT UNTIL ship:velocity:surface:mag >= 2500.

In that case the whatever ended up being ship:velocity:surface:mag >= 2500.