[1.3] kOS Scriptable Autopilot System v1.1.3.0

[kaesekuchen]

I have opened up a new issue called "Steering Discussion" on the github here.

This discussion is related to some of the observations and "research" i have done on orientation/steering.

Initially inspired to do so by the request of retrieving the current "roll" value of the ship's facing.

Comments are as always appreciated

regards,

kaesekuchen

[Logris]

I switched to the ship that detached and tried entering some commands manually. It seems "stage." and "sas off." and simple toggles like those work, but locking steering or throttle has no effect.

How do I get this working?

The locks only last as long as the program is running.

Unless you have a loop to stop your program ending, then it will stop after the last line and the locks will reset.

[togfox]

I installed 0.11 to test it out, but it seems that it's not working properly for mr

Did your script stop straight after that? Is that all your script does? Ive found that kos returns throttle to 0 when the script naturally ends. Probably a bug.

[CaptainKipard]

how do i get the dv of a node that was created manually? node:deltav:mag doesn't work for me.

EDIT

Nevermind, it's nextnode. All the documentation says "node". Terrible.

Edited February 19, 2014 by Cpt. Kipard

[BahamutoD]

Did your script stop straight after that? Is that all your script does? Ive found that kos returns throttle to 0 when the script naturally ends. Probably a bug.

The locks only last as long as the program is running.

Unless you have a loop to stop your program ending, then it will stop after the last line and the locks will reset.

I see, I'll try setting up a loop. However, when it was still attached to the mothership, just typing 'lock throttle to 1.' worked and it stayed locked until i unlocked it.

Thanks

[togfox]

Nevermind, it's nextnode. All the documentation says "node". Terrible.

If you find a gap in the documentation then feel free to help us all out by updating the documentation.

[BahamutoD]

I see, I'll try setting up a loop. However, when it was still attached to the mothership, just typing 'lock throttle to 1.' worked and it stayed locked until i unlocked it.

Thanks

I did

until 0{
   lock throttle to 1.
   lock steering to up.
}.

and neither the steering nor the throttle were locked on the decoupled ship.

It works (even without a loop) when the ship is still attached to the mothership, but after decoupling, all locks are broken and cannot be locked again. I'm sure this worked in at least v0.7... Has anyone else had trouble controlling ships/stages that have decoupled?

[togfox]

Haven't tried what you're trying, but have you tried setting throttle and steering BEFORE you decouple? It might make a difference somehow.

You'll probably want to deactivate the engine with an action group, set throttle and steering, then use an AG to activate the engine and decouple at the same time. Might work.

[BahamutoD]

Yeah, I tried that and the locks became unlocked after decoupling.

[CaptainKipard]

Has anyone noticed that if you manually create a node with only a prograde increase and print nextnode:deltav:mag and nextnode:prograde, those two show lightly different results?

If you find a gap in the documentation then feel free to help us all out by updating the documentation.

Well I could but I'm not really in a position to know what's right and what's not without playing with it first. It begins with me reading something and then getting frustrated because it doesn't work as advertised. The best I can do is report bugs, which might turn out to not be bugs at all but obsolete code.

Edited February 19, 2014 by Cpt. Kipard

[Logris]

and neither the steering nor the throttle were locked on the decoupled ship.

Where is the kOS part? Is it on the decoupled ship or on the mothership?

If it's on the mothership then this would make sense as there is no link once they are decoupled.

[BahamutoD]

Its on the decoupled ship. I've done this before in 0.7. I had a Falcon9R replica where the first stage returned while the second stage continued. I know each part that is running a program needs its own kOS part, but its just not working in 0.11.

[Dunbaratu]

I have had problems in the past where a decoupled SCS part was still able to activate stages on the detached parent ship. When I typed "stage" on the bit that was decoupled, the next stage of the ship it was no longer attached to was activated. I'm not sure this is kOS's fault however, because KSP itself has a lot of buggy broken behavior when it comes to staging lists with docking and undocking, so it may be KSP's fault that the staging list included parts from the detached craft.

[togfox]

... When I typed "stage" on the bit that was decoupled, the next stage of the ship it was no longer attached to was activated...

I bet that caused a few WTF moments. The worst part about things like this is it can take quite some time to work out what exactly is going on because it can be difficult to logically connect the two events sometimes.

[Dunbaratu]

I bet that caused a few WTF moments. The worst part about things like this is it can take quite some time to work out what exactly is going on because it can be difficult to logically connect the two events sometimes.

It's one of the main reasons I gave up on my attempt to build a kOS orbital missile platform. (The other was the bug, now finally squashed, where half the ship gets deleted when coming back off of rails. That bug made anything in which I intended to run software on the base platform and also on the missile rather impossible to implement. I'd shoot the missile off, have the camera follow it, and then switch focus back to the missle platform and the platform would be mostly missing.)

[erendrake]

The problem with the word "velocity" isn't frame of reference (which direction the XYZ axes point and where the origin is).

Im sorry i might have been unclear, right now.

PRINT SHIP:VELOCITY.

returns the string representation of the orbitalvelocity vector, what i was considering removing was the string that you cannot use as a vector because it is a string, I was thinking instead for structures to return.

PRINT SHIP:VELOCITY.

Type: VesselVelocity. Members: ORBIT, SURFACE.

so everyone doesnt have to run to the web every time they cannot remember the manyfold members of VesselTarget.

The problem is that there's two types of Vector in the underlying engine, and Velocity isn't the right datatype (which is why you can't use the X,Y,Z, or MAG suffixes on it), combined with the fact that this datatype discrepency is 100% masked and hidden from the kos script writer because both types of Vector get printed out the same way and both look like the same datatype to the kos script writer. They are both printed as "V(...,...,...,)" but one is not the kOS Vector type, but an internal Unity Vector3D type which is missing a lot of the kOS script langauge support to use it properly.

I just want to say that if/when scripters are confronted with the other vector type, that is a bug. I would love for you guys to let me know when that happens because like you say, it is useless for you.

[Dunbaratu]

Ah, that's what got me confused. If you type `print velocity.`, you will get only the first vector as output (in form of V(double,double,double), it seems), and you won't be able to do anything with it. velocity:{orbit,surface}:{x,y,z,mag} works, thanks.

This definitely needs fixing. It's misleading to the script programmer, as it is essentially "lying" about what the datatype of "Velocity" really is. Either have it print both the vectors that are inside it, like so:

Orbit: V(...,...,...) Surface: V(...,...,...)"

Or have it just print a crpytic "Velocity Object".

But making it look like it's a vector when it's not is going to confuse.

And actually, that brings to mind an interesting question:

Should there be a generic toString() for all structure objects like Velocity, that always does something like what I suggested above? Just make it so that all structure objects always will, when converted to a string, dump their component parts recursively.

For any such structure object, have it do this as it's toString:

For each component inside me, do:

append the name of the component, then a " : ", then append that component's toString.

Thus a Velocity prints as:

"ORBIT: V(..., ..., ...) SURFACE: V(...,...,...)"

while a SENSORS prints as:

"ACC: V(..., ..., ...) PRES 99.9999 TEMP 99.999 GRAV V(..., ..., ...)"

And so on.

It's not pretty and you probably wouldn't want to use these strings for much of anything to display to the user, but the point it it's VERY instructive to the script writer what's really going on, and besides these are cases where you probably shouldn't be writing script code that prints these things direct to the user anyway. (So there's no harm in making the toString more instructive for debugging and learning purposes.)

Edited February 20, 2014 by Steven Mading

[Dunbaratu]

I tried looking at how I'd make a docking program using the new release and the first thing I came up with as a potential snag is this:

Is there support yet for selecting a certain part on the other vessel as your target, rather than targeting just its center of mass? I refer of course to the way you can, when manually playing KSP, rightclick a docking port of the other vessel and pick that docking port as your target rather than the center of the vessel as your target. Without that I can still make a docking script provided I'm docking to a port that is lined up with the vessel's center of mass, and I stipulate that the docking script must make sure it gets lined up more than N meters away from the target, where N is the distance from the center of the ship to its docking port.

Otherwise the deflection in angle between the center of the target vessel and its docking port becomes too large once you get close to it. If you try to line up by sliding sideways while too close to it, that difference in angle will mess the script up. But if you get lined up while still far away from it so the center of the vessel and it's docking port are in line with each other, then that difference won't be relevant.

[erendrake]

It's not pretty and you probably wouldn't want to use these strings for much of anything to display to the user, but the point it it's VERY instructive to the script writer what's really going on, and besides these are cases where you probably shouldn't be writing script code that prints these things direct to the user anyway. (So there's no harm in making the toString more instructive for debugging and learning purposes.)

I agree, lets make a ticket and figure out exactly what we want.

https://github.com/erendrake/KOS/issues/44

[erendrake]

I tried looking at how I'd make a docking program using the new release and the first thing I came up with as a potential snag is this:

Is there support yet for selecting a certain part on the other vessel as your target, rather than targeting just its center of mass? I refer of course to the way you can, when manually playing KSP, rightclick a docking port of the other vessel and pick that docking port as your target rather than the center of the vessel as your target. Without that I can still make a docking script provided I'm docking to a port that is lined up with the vessel's center of mass, and I stipulate that the docking script must make sure it gets lined up more than N meters away from the target, where N is the distance from the center of the ship to its docking port.

Otherwise the deflection in angle between the center of the target vessel and its docking port becomes too large once you get close to it. If you try to line up by sliding sideways while too close to it, that difference in angle will mess the script up. But if you get lined up while still far away from it so the center of the vessel and it's docking port are in line with each other, then that difference won't be relevant.

It isnt in yet, if you look at the Docking milestone there are quite a few things i wanted for this release that i havent finished yet, and this is one of them. I am pretty tempted to release this direct flight part and let everyone find bugs while i work on the rest of the docking features. What do you think?

[unWinged]

I have problem with setting node to apoapsis. I try to do it with code below:

set Ncirc to node(time + eta:apoapsis, 0, 0, 400).
add Ncirc.

IIRC it worked in 0.10, but now it returns error saying that time + eta:apoapsis is not a number. I narrowed it down to time being not a number, although when I try to print it it shows a number...

Can someone help me how to do this?

[Agathorn]

Try time:seconds

[unWinged]

Try time:seconds

That works :-) thanks!

[Dunbaratu]

Does anyone know a good resource for solving this messy math problem?

Givens:

1. All the shape parameters of your current orbit, which in turn tells you how fast you'd be going at periapsis were it not for the atmosphere.

2. The mass and radius of the body, and all its atmospheric qualities.

3. A desired amount of speed I'd like to lose at periapsis.

Find:

"What altitude should I dip my periapsis to so that when I dip into the atmosphere I will lose the desired amount of speed, no more, no less."

I already know how to calculate the amount of force caused by drag, given the altitude (which determines air density), the craft's drag numbers (usually 0.2), and the current speed.

The really hairy part is that all of those things are constantly changing during the aerobraking maneuver and they depend on each other. The drag force is constantly changing as you change altitude, and as you slow down the drag force lessens. Because of the slowing down even the shape itself of the path through the air is not simply straddling the periapsis symmetrically, as you will spend more time in air after periapsis than before it because the slowing down altered your path during the aerobraking.

The math has a messy amount of self-affecting feedback loops in it. Presumably I could work out the integral of the deceleration the air causes throughout the breaking maneuver, to get the total change in velocity, but the velocity itself changes the amount of deceleration the air provides, and it's that feedback into the equation that I can't quite figure out how to work out.

My math coursework in college went through calculus and just into the very beginnings of differential equations before I stopped (because I decided to pursue compsci instead of physics). I get the strong impression that this messy situation is exactly the sort of thing that differential equations would do.

I don't need the math to be calculated on the fly by the vessel's kOS code. Precalcuating something in a lookup table and having the code interpolate from the lookup table is fine. I just need to be careful to always brake enough to be captured, but not so much as to kill the orbit and fall in, and then I can adjust from there to the specific orbit I want after the first pass through the atmosphere.

[ElasticRaven]

Drag is nonlinear, so I think you'll have to solve it numerically. There are calculators online for it, like http://alterbaron.github.io/ksp_aerocalc.

If we could get a closed form solution, KSP might be able to handle ships in an atmosphere while keeping them on rails