[1.3] kOS Scriptable Autopilot System v1.1.3.0

Recommended Posts

VFB1210 said:
It should be taken into account whenever you are calculating the net force on the vessel. But the v(dm/dt) term only emerges when you are burning because dm/dt is zero when you aren't.

In that case would this

`F3 = M * a + v(dm/dt)   - F1   - M * grav - v(dm/dt)`

be correct and in fact the v(dm/dt) cancels leaving you with just

`F3 =   M * a - F1 - M * grav`

and you never need to calculate v(dm/dt) for the purposes of this?

Edited by TDW
forum change messing with formatting

Share on other sites

I'm dumb and I've been over complicating everything this whole time.

The v in v(dm/dt) is supposed to be the exhaust velocity.

Exhaust velocity multiplied by mass flow rate also has its own name: THRUST.

So according to the article, we get ÃŽÂ£F + thrust = ma.

ÃŽÂ£F is all of the external forces.

Gravity. Drag. Lift.

So: Gravity + Drag + Lift + Thrust = ma.

TDW was literally right THE ENTIRE TIME. My apologies for misleading everyone.

Let this be a lesson: don't blindly apply formulas without thinking about them, and don't ever be too proud to look something up.

Edited by VFB1210

Share on other sites
When I crate a maneuvernode to enter a circle orbit during launch, I think I shall get Velocity at Apoapsis firstly.

So I code VelocityAt(Ship,Time:Seconds+ETA:Apoapsis):Orbit:Mag,

but its value is different from real velocity. So new orbit's Apoapsis will be different from I expect.

like following:

set EtaTime to ETA:Apoapsis.

set V1 to VelocityAt(Ship,Time:Seconds+EtaTime):Orbit:Mag. //get V1 -> Velocity at Apoapsis according to current orbit. BUT IT RETURN A WRONG VALUE

set V2 to Sqrt (Constant():G*Kerbin:Mass/Kerbin:Radius). //get V2 -> Velocity shall be after node, I want to get a circle orbit. calculate from GM=V2R

set MyNode to Node (Time:Seconds+EtaTime,0,0,V2-V1). //get deltaV=V2-V1

Thanks.

Can you write this up on Github? I think I have seen a similar problem before but it's been hard to reproduce - if you have a set of circumstances that reliably recreates it that would be useful for getting it fixed.

Share on other sites

Can anyone point me to any information on using kOS with Realism Overhaul?

I want to know if there are any issues to watch for when using the two together.

I also have a problem with kOS. I am attempting to write a script that executes a maneuver node (for circularisation) but when I use "LOCK STEERING TO ..." the ship spins out of control. This happens whatever direction I try to steer to.

Share on other sites
Can anyone point me to any information on using kOS with Realism Overhaul?

I want to know if there are any issues to watch for when using the two together.

I also have a problem with kOS. I am attempting to write a script that executes a maneuver node (for circularisation) but when I use "LOCK STEERING TO ..." the ship spins out of control. This happens whatever direction I try to steer to.

The cooked steering in kOS currently is broken for dealing with the case of a ship that gets all its control authority from engine gimbals and rcs. The fact that RO nerfs the torque wheels messes it up. While it doesn't exclusively use the torque wheels to move, it uses them to do some math to *decide* how to move things and that math comes out wrong. I don't understand the details, but it's a part of the system that hasn't been touched in ages since the early days. We're considering gutting the whole thing and doing it over from scratch rather than trying to debug what's there.

Share on other sites
The cooked steering in kOS currently is broken for dealing with the case of a ship that gets all its control authority from engine gimbals and rcs. The fact that RO nerfs the torque wheels messes it up. While it doesn't exclusively use the torque wheels to move, it uses them to do some math to *decide* how to move things and that math comes out wrong. I don't understand the details, but it's a part of the system that hasn't been touched in ages since the early days. We're considering gutting the whole thing and doing it over from scratch rather than trying to debug what's there.

That's a shame. I can probably help out with some of that (and would love to). Where do I go to help out? I only have a moderate amount of programming experience, but I am well versed in the mathematics and control systems.

Share on other sites
That's a shame. I can probably help out with some of that (and would love to). Where do I go to help out? I only have a moderate amount of programming experience, but I am well versed in the mathematics and control systems.

Yes please! Any help you can provide on it would be awesome. We've had lots of discussions internally, but we haven't been able to move beyond the brainstorming phase. The quick and dirty way to help out is to clone the source on github ( https://github.com/KSP-KOS/KOS ) and then submit a PR.

The current steering implementation can be found in this file: https://github.com/KSP-KOS/KOS/blob/develop/src/kOS/Utilities/SteeringHelper.cs but in our last discussion we thought it might be messed up and confusing enough that it could warrant starting from scratch. If you're willing/able to fix the current version though, I don't think any one would turn you down. (I can already tell you that each reference to `vessel.transform` needs to be replaced with `vessel.ReferenceTransform`, but I haven't dug in much more than that).

Let us know if you need any help getting the development environment setup.

The stars must have aligned just right. It was yesterday afternoon that we were talking about not being sure how to go about fixing the steering, and today you offer to help!

Share on other sites
Yes please! Any help you can provide on it would be awesome. We've had lots of discussions internally, but we haven't been able to move beyond the brainstorming phase. The quick and dirty way to help out is to clone the source on github ( https://github.com/KSP-KOS/KOS ) and then submit a PR.

The current steering implementation can be found in this file: https://github.com/KSP-KOS/KOS/blob/develop/src/kOS/Utilities/SteeringHelper.cs but in our last discussion we thought it might be messed up and confusing enough that it could warrant starting from scratch. If you're willing/able to fix the current version though, I don't think any one would turn you down. (I can already tell you that each reference to `vessel.transform` needs to be replaced with `vessel.ReferenceTransform`, but I haven't dug in much more than that).

Let us know if you need any help getting the development environment setup.

The stars must have aligned just right. It was yesterday afternoon that we were talking about not being sure how to go about fixing the steering, and today you offer to help!

Don't get too excited, I may not be any real use! I've been meaning to put some work back into some of the awesome mods I use and an internship I recently did greatly improved my coding and pushed me to give it a go. As of now though I don't even know any C#, although hopefully this will be a good way to learn. Where do people working on KOS normally communicate?

Share on other sites

You should be getting a PM to coordinate contact info.

As for C#, we can help with that. It's probably not to hard to pick up. It isn't that far off from Java, or C++, but it has it's fair share of unique elements. If you're coming from a language like python, it can seem restricting.

Share on other sites
You should be getting a PM to coordinate contact info.

As for C#, we can help with that. It's probably not to hard to pick up. It isn't that far off from Java, or C++, but it has it's fair share of unique elements. If you're coming from a language like python, it can seem restricting.

Thanks a lot I look forward to it. Unfortunately I'm coming from Python/Matlab/Mathematica but I'm keen to learn. Looking at SteeringHelper, it looks like there's a lot to learn before I can begin trying to do anything.

Share on other sites
if @VFB1210 or anyone else wants to give these a go and fly around with lift and drag arrows coming out their vessel here is my lift/drag script.

you will need to stick an accelerometer (the science experiment) on the vessel and the script still produces the occasional spike in lift or drag.

feedback with any improvements or fixes would be greatly appreciated.

I'm flying this thing today.

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.

I hope to win the K prize as well as fullfiling a tourist contract while doing this kOS experiment in the first "commercial" flight of my SSTO. Wish me luck, I'm foreseeing a RUD on my future.

Share on other sites

I had some quirks reading acceleration from the sensor when raising apo but still within "dense" air, at some 30km I guess. I'm not really sure what was happening, KER and a direct sensor read some 0.9 g while kos said such sensor showed about 0.2. I'll compute acceleration out of velocity readings, that should give better results.

Also when in orbit, if I time warped suddenly there was a lift component that cancelled out gravity. At 1x speed lift, drag and thrust went back to 0, while gravity was still as expected.

That plane is still in orbit, apart from these glitches every measurement was sound. Tomorrow: reentry and landing.

Share on other sites

When using kOS in combination with an engine with alternative resource requirements, for example the LV-N or some mod, is it possible for kOS to figure out what resource the engine is using without actually activating the engine?

For an autopilot I want the program to figure out how much dV the vehicle has. This means I need to figure out how much fuel each stage has and what the engines use. The first part works great, but I have no idea how to do the second.

Edited by Ralathon

Share on other sites

So I've fallen in love with this mod lately! Great job guys! I have no idea how to program, so this has been a huge challenge for me!

Ive been writing programs lately to launch rockets using the Realism Overhaul mod. I think that I've come very close to getting a launch script fo work well. THere is one part that I am stuck on, getting my second stage into a circular orbit. I Can't figure out how to get my second stages to go smoothly into orbit. Specifically I can't figue out how to actually to pitch my craft upwards enough to cancel out Gravity losses.

`		ELSE IF runmode = 6 {		IF VERTICALSPEED > 0 {Lock STEERING TO  PROGRADE.		} ELSE IF VERTICALSPEED <-90 {SET PitchUp TO -45.		} ELSE SET PitchUp TO ((-1)().25)VERTICALSPEED).		LOCK STEERING TO ANGLEAXIS(PitchUp,PROGRADE:STARVECTOR)*PROGRADE.	}`

EDIT:

`	ELSE IF runmode = 6 {		IF SHIP:PERIAPSIS > 200000 {		SET THROTTLE TO 0.0.		RCS OFF.		SET runmode TO 0.		} ELSE IF VERTICALSPEED > 0 {			LOCK STEERING TO PROGRADE.		} ELSE IF VERTICALSPEED < 0 {			LOCK STEERING TO ANGLEAXIS(PitchUp,PROGRADE:STARVECTOR)*PROGRADE.			IF VERTICALSPEED < -140 {				SET PitchUp TO ( -45 ).			}			ELSE IF VERTICALSPEED < -10 {				SET PitchUp TO ( -10 + ( .25 * VERTICALSPEED ) ).			}			ELSE IF VERTICALSPEED < 0 {				SET PitchUp TO ( VERTICALSPEED ).			}		}	}	WAIT .001.`

(This is all inside an UNTIL Loop.)

Share on other sites

Thanks TDW and VFB1210 for the math and scripts. I tuned them a little to show drag+thrust+lift+gravity to the side of the plane.

Javascript is disabled. View full album

Share on other sites

Could someone help me with a problem?

When i use code like that:

Clearscreen.

Print "START".

RCS on.

SAS off.

LIGHTS off.

GEAR off.

SET throtlle to 0.

WAIT 2.

PRINT "NORMALIZED".

WAIT 2.

SET TargetApoapsis to 80000.

Print "Setting Target Apoapsis to 80000".

WAIT 2.

SET TargetPeriapsis to 80000.

PRINT "Setting Target Periapsis to 80000".

WAIT 2.

PRINT "SETTING MODE TO 1".

SET mode to 1.

WAIT 2.

UNTIL mode = 0 {

IF mode = 1 {

PRINT "LIFTOFF!".

PRINT "MODE I".

LOCK Throttle to 1.

LOCK steering to heading ( 90 , 90 ).

STAGE.

Wait until altitude > 9000.

SET mode to 2.

}

else If mode = 2 {

PRINT "MODE II".

WAIT 1.

PRINT "STARTING GRAVITY TURN".

WAIT 1.

SET TargetPitch to (90 - (1 + (90/41000) * (SHIP:Altitude-8000))).

LOCK steering to heading( 90, TargetPitch).

Set Z to (TargetApoapsis-1000).

If Apoapsis > Z set mode to 3.

}

else If mode = 3 {

LOCK THrottle to 0.

PRINT "MODE III".

WAIT 1.

PRINT "WAITING FOR APOAPSIS...".

WAIT UNTIL ALTITUDE = 70000.

SET WARP to 4.

WAIT UNTIL ETA:Apoapsis < 30.

SET WARP to 1.

WAIT UNTIL ETA:Apoapsis < 8.

PRINT "APOAPSIS!".

SET THROTTLE TO 1.

WAIT UNTIL PERIAPSIS > TargetPeriapsis.

SET throttle to 0.

SET mode to 0.

}

if STAGE:LIQUIDFUEL < 1 {

PRINT "FUEL CHECK".

WAIT 1.

PRINT "Atempting to Stage".

LOCK Throttle to 0.

WAIT 1.

STAGE.

WAIT 1.

STAGE.

WAIT 1.

LOCK THROTTLE to 1.

}

}

I got en error about heading being unrecognized/undefined but when i use part of code like that:

SET MODE to 1.

IF mode = 1 {

PRINT "LIFTOFF!".

PRINT "MODE I".

LOCK Throttle to 1.

LOCK steering to heading ( 90 , 90 ).

STAGE.

Wait until altitude > 9000.

SET mode to 2.

}

IT works perfectly fine.

Share on other sites

I'm not well versed in headings, but it's too suspicious having a heading function at the same time you're doing a lock on it:

LOCK steering to heading ( 90 , 90 ).

...

Not related to the issue, but you may want to move your staging into a WHEN clause at some point for making it more generic.

Share on other sites

hello all

I'm trying to make a "from the kerbin to the mun"-sort of script, and while the takeoff _will_ probably create some problems, I started on the part where I've just entered the MUN SOI, and esablish a low mun orbit.

Currently my script just point retrograde and fire until it have a suitable periapsis, timewarp until its at that periapsis, and then fire until it got a suitable apoapsis.

However, I want my initial pointing to be at 0 pitch (the horizon), and with whatever compass direction im currently heading. This is to make sure that if I come into the muns SOI in either direction, and even with an inclination, the rocket points in a 'better' vector then just retrograde, you know, efficiency and stuffs

If that made any sense at all.

I tried:

`	SET DIR TO SHIP:RETROGRADE * R(0,1,1)	LOCK STEERING TO DIR.`

Where my assumtion were that it would set the steering to <whatever pitch * 0> (=0), <whatever diredtion * 1> (i.e. that direction), <whatever roll * 1> (the roll it already has)

Tips and/or tricks anyone?

Share on other sites

However, I want my initial pointing to be at 0 pitch (the horizon), and with whatever compass direction im currently heading. This is to make sure that if I come into the muns SOI in either direction, and even with an inclination, the rocket points in a 'better' vector then just retrograde, you know, efficiency and stuffs

At periapsis, you will have a retrograde direction lined up with the horizon. Presumably what you would like to do is start firing in that direction just a bit before you get there.

So try

`velocityat(ship,eta:periapsis):orbit`

to get what your orbital velocity WILL be at periapsis, then aim in the negative of that vector to get the retrograde version of it.

Warning: Because KSP's coordinate system is slippery and likes to change without warning, be sure to take that prediction reading with velocityAt fairly soon before you do the burn. Don't take the reading from the other side of the moon while eta:periapsis is still like 10 minutes into the future, and lock steering to that. Instead take the reading just a few seconds before you're planning to start your burn - just enough time to get your ship rotated to the right heading before the burn.

Share on other sites

hmm, at the point where entering the MUN's SOI, you are usually 2-3 hours from the PE... Would that work in that case then?

Share on other sites
Could someone help me with a problem?

PRINT "SETTING MODE TO 1".

SET mode to 1.

WAIT 2.

IF mode = 1 {

PRINT "LIFTOFF!".

PRINT "MODE I".

LOCK Throttle to 1.

LOCK steering to heading ( 90 , 90 ).

STAGE.

Wait until altitude > 9000.

...

}

The bold type will fire every stage of your rocket before it gets 1m off the ground.

All you'll hear is .. bang.. bang.. bang.. as the stages go off

You should set your stage 'firing' with respect to 'current stage fuel' conditions

IF STAGE:LQDHYDROGEN < 0.1 // LqdOxy tanks on first two stages

{

STAGE.

SET Throttle TO 1.

}

Edited by ColKlonk

Share on other sites
hmm, at the point where entering the MUN's SOI, you are usually 2-3 hours from the PE... Would that work in that case then?

I'd recommend that you get an initial guess on the vector at that point, get started aiming toward it, but then recalc it with another reading just a few seconds before you burn, as it may have moved by a few degrees since then (or more accurately, the universe axes may have rotated since then, making the previous X,Y,Z components incorrect under the new rotated universe.)

Share on other sites

Hi, first time trying kos here, and already a problem. I can

`print "hello".`

in the terminal and it gives the expected result, but 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?

Share on other sites
Hi, first time trying kos here, and already a problem. I can
`print "hello".`

in the terminal and it gives the expected result, but 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?

Linux? I ask because Unity stupidly made some differences between how keycodes are dealt with on different OS ports. These are differences that the actual host OS does not require them to make, but they did anyway. (i.e. Unity's fault, not Linux's fault). This has bit us before in kOS in regards to Linux. I've never ever heard of this one before, of specifically the "R" and "E" keys not working when everything else does work.