Jump to content

[1.3] kOS Scriptable Autopilot System v1.1.3.0


erendrake

Recommended Posts

would like to report a bug.

summary: when using STAGE:RESOURCES on a specific ship setup the resources for future stages are listed.

reproduction: build the ship shown below with the staging shown below. in my example LV-909 engines are used above both stack decouplers. the fuel tank for the last stage engine was not necessary to reproduce the bug but the engine was. for staging you must set the stage to contain both the decoupler and the engine, the issue is fixed if you separate the two into different stages. on launch activate the first stage and use PRINT STAGE:RESOURCES., you will see the liquid fuel and oxidizer listed.

fCHFq1r.pngo69xwFc.png

0dj4EeX.pngmIhdzo1.png

Link to comment
Share on other sites

Hello, I made a little aeronautic attitude observation system, basically it gives you information about, ASL/AGL/Speed/Machnumber/Roll angle/Pitch/actual flightpath Pitch/Angle of Attack/G-Forces. Right now its all embedded in a UNTIL loop because I use it to visualize flight parameters with the vectordraw function. You can just delete the Loop and the vectordrawing information and just go with the attitude sensoric stuff and use that as seperate program your for example autopilot executes to determine which way the plane is heading rolling or what other flight parameters are.

SET counter TO 0.
UNTIL counter = 1500 {
SET counter TO counter + 1.

SET anArrow1 TO VECDRAW().
SET anArrow1:VEC TO SHIP:FACING:FOREVECTOR.
SET anArrow1:SHOW TO true.
SET anArrow1:START TO V(0,0,0).
SET anArrow1:COLOR TO RGB(1,0,0).
SET anArrow1:SCALE TO 20.

SET anArrow2 TO VECDRAW().
SET anArrow2:VEC TO SHIP:FACING:STARVECTOR.
SET anArrow2:SHOW TO true.
SET anArrow2:START TO V(0,0,0).
SET anArrow2:COLOR TO RGB(0,1,0).
SET anArrow2:SCALE TO 10.

SET anArrow3 TO VECDRAW().
SET anArrow3:VEC TO SHIP:UP:VECTOR.
SET anArrow3:SHOW TO true.
SET anArrow3:START TO V(0,0,0).
SET anArrow3:COLOR TO RGB(0,0,1).
SET anArrow3:SCALE TO 10.

SET anArrow4 TO VECDRAW().
SET anArrow4:VEC TO SHIP:FACING:TOPVECTOR.
SET anArrow4:SHOW TO true.
SET anArrow4:START TO V(0,0,0).
SET anArrow4:COLOR TO RGB(1,1,1).
SET anArrow4:SCALE TO 10.

SET anArrow5 TO VECDRAW().
SET anArrow5:VEC TO SHIP:VELOCITY:SURFACE.
SET anArrow5:SHOW TO true.
SET anArrow5:START TO V(0,0,0).
SET anArrow5:COLOR TO RGB(0,1,1).
SET anArrow5:SCALE TO 0.1.

SET anArrow6 TO VECDRAW().
SET anArrow6:VEC TO VCRS(-1*SHIP:FACING:FOREVECTOR,SHIP:UP:VECTOR).
SET anArrow6:SHOW TO true.
SET anArrow6:START TO V(0,0,0).
SET anArrow6:COLOR TO RGB(1,1,0).
SET anArrow6:SCALE TO 10.

// IMPORTANT PART, IF DO NOT NEED THE UNTIL LOOP OR VECTORDRAW DELETE EVERYTHING ABOVE
SET c1 TO (90 - VANG(VCRS(SHIP:FACING:FOREVECTOR,SHIP:UP:VECTOR),SHIP:FACING:TOPVECTOR)). // roll
SET d1 TO VANG(SHIP:FACING:TOPVECTOR,SHIP:UP:VECTOR). // angle between UP and TOP
SET e1 TO VANG(SHIP:FACING:FOREVECTOR,SHIP:UP:VECTOR). // pitch
SET e2 TO VANG(SHIP:VELOCITY:SURFACE,SHIP:UP:VECTOR). // flightpath pitch
SET f1 TO VANG(SHIP:FACING:FOREVECTOR,SHIP:VELOCITY:SURFACE). // angle of attack
SET g1 TO (SHIP:SENSORS:ACC:MAG / SHIP:SENSORS:GRAV:MAG). // GFORCE

IF VANG(SHIP:FACING:TOPVECTOR,SHIP:VELOCITY:SURFACE) < 90 {SET f1 TO -1*f1.}.

IF VANG(SHIP:FACING:FOREVECTOR,SHIP:UP:VECTOR) < 89 { // check nose up
IF VANG(SHIP:FACING:FOREVECTOR,SHIP:UP:VECTOR) < 5 { // check pitch limit up
SET c1 TO 0.
SET d1 TO 0.
// VERTICAL UP
} ELSE {
IF d1 < 90 {
IF c1 <= 1 AND c1 >= -1 {
// NOSE UP LEVEL
} ELSE {
IF c1 > 1 {
// left
}.
IF c1 < -1 {
// right
}.
}.
}.
IF d1 > 90 {
IF c1 <= 1 AND c1 >= -1 {
// NOSE UP UPSIDE DOWN
} ELSE {
IF c1 > 1 {
SET c1 TO (180 - c1). // left
}.
IF c1 < -1 {
SET c1 TO -1*(180 + c1). // right
}.
}.
}.
}.
} ELSE { // nose down
IF VANG(SHIP:FACING:FOREVECTOR,SHIP:UP:VECTOR) > 91 { // check pitch limit down
IF VANG(SHIP:FACING:FOREVECTOR,SHIP:UP:VECTOR) > 175 {
SET c1 TO 0.
SET d1 TO 0.
// VERTICAL DOWN
} ELSE {
IF d1 < 90 {
IF c1 <= 1 AND c1 >= -1 {
// NOSE DOWN LEVEL
} ELSE {
IF c1 > 1 {
// left
}.
IF c1 < -1 {
// right
}.
}.
}.
IF d1 > 90 {
IF c1 <= 1 AND c1 >= -1 {
// NOSE DOWN UPSIDE DOWN
} ELSE {
IF c1 > 1 {
SET c1 TO (180 - c1). // left
}.
IF c1 < -1 {
SET c1 TO -1*(180 + c1). // right
}.
}.
}.
}.
} ELSE { // nose level
IF d1 < 90 {
IF c1 <= 1 AND c1 >= -1 {
// LEVEL
} ELSE {
IF c1 > 1 {
// left
}.
IF c1 < -1 {
// right
}.
}.
}.
IF d1 > 90 {
IF c1 <= 1 AND c1 >= -1 {
// LEVEL UPSIDE DOWN
} ELSE {
IF c1 > 1 {
SET c1 TO (180 - c1). // left
}.
IF c1 < -1 {
SET c1 TO -1*(180 + c1). // right
}.
}.
}.
}.
}.

// YOU CAN DELETE ALL THIS IF YOU DO NOT USE THE UNTIL {} FUNCTION
CLEARSCREEN.
PRINT "ASL : " + ROUND(SHIP:ALTITUDE).
PRINT "AGL : " + ROUND(ALT:RADAR).
PRINT "SPEED : " + ROUND(SHIP:VELOCITY:SURFACE:MAG*3.6).
PRINT "MACH : " + ROUND(SHIP:VELOCITY:SURFACE:MAG/343,2).
PRINT "ROLL : " + ROUND(c1,1).
PRINT "PITCH : " + ROUND(90 - e1,1).
PRINT "PITCH : " + ROUND(90 - e2,1).
PRINT "AOA : " + ROUND(f1,1).
PRINT "G-FORCE : " + ROUND(g1,1).
wait 0.01.
}.

This is how it looks in action : http://imgur.com/a/vzY2F#0

sidenote: how do I embed imgur galleries?

Edited by VentZer0
Link to comment
Share on other sites

Hi, I'm working on a program for an automatic, engine powered landing for spend stages to recover them. Now, I ran into an issue:

When the steering should be locked to the retrograde vector, the stage actually locks the steering to the Orbit-retrograde vector. And this is a big problem, because Kerbin rotates and because of Kerbin's rotation the orbit retrograde vector is always somewhere around the horizon, and the stage turns in that direction, fires up the engine, reduces the verticalspeed to about 2m/s (as planned) while the speed itself wents up to ~140m/s.

I'm pretty sure I didn't ran into that problem in previous versions.. :/ Does anyone know what to do, or how I can avoid using retrograde/prograde?

Link to comment
Share on other sites

And this is a big problem, because Kerbin rotates and because of Kerbin's rotation the orbit retrograde vector is always somewhere around the horizon, and the stage turns in that direction, fires up the engine, reduces the verticalspeed to about 2m/s (as planned) while the speed itself wents up to ~140m/s.

I'm pretty sure I didn't ran into that problem in previous versions.. :/ Does anyone know what to do, or how I can avoid using retrograde/prograde?

Use "SHIP:SRFRETROGRADE" to get the surface retrograde direction, as documented here.

Link to comment
Share on other sites

I haven't used any previous versions of kOS, and I'm pretty new to KSP, but I have a few bugs to report:

  1. The zip file on github for the 0.15.5 release may not be correct. The version file in the git tag for that release 0.15.5, but the file that comes in the zip says 0.15.4.
  2. Accessing list elements seems to be broken. This test case gives error "Can't iterate on an object of type kOS.Safe.Encapsulation.ListValue". From the documentation, I'm pretty sure that test should work.
  3. I'm not sure it's a "bug", exactly, but in the design patterns and PID loops sections of the documentation, there seems to be one more integration than intended, because of the "set thrott to thrott + dthrott.", and dthrott being the actual output of the control loop. So the "proportional" controller is actually an integral controller, the "PI" controller is actually an II² controller, and the PID controller is actually a PII² controller.

Link to comment
Share on other sites

I haven't used any previous versions of kOS, and I'm pretty new to KSP, but I have a few bugs to report:

[...]

  • Accessing list elements seems to be broken. This test case gives error "Can't iterate on an object of type kOS.Safe.Encapsulation.ListValue". From the documentation, I'm pretty sure that test should work.

Can you quote the exact code you are using?

Link to comment
Share on other sites

Hi everybody.

I have a question on KOS interaction with RemoteTech as I started a new playthrough with a lot of new mods.

I wrote a program that automates launch of a probe to an LKO (80km) and then creates and executes 2 nodes at next peri and then apo to bring an orbit to desired altitude. It worked perfectly without RemoteTech installed, but now, when I need the KOS autopiloting features the most it refuses to work (at least as I expected it to).

The launch script works nicely because there is still connection to KSP and I get the probe to LKO, but problem is that as soon as I loose connection to KSP I cannot execute any nodes that are in the darkside due to being unable to steer in the right direction via lock sttering to xxx.

Basically this code from my exenode.ks script just hangs until I get the connection to KSC back, because the ship is unable to steer.


...
set np to nextnode:deltav:direction.
lock steering to np.


wait until abs(np:pitch - facing:pitch) < 0.15 and abs(np:yaw - facing:yaw) < 0.15.
...

Am I missing something? Is this behavior normal?

EDIT: Seems like known thing, need to modify KOS config, should have googled better before posting.

Edited by Ziw
Link to comment
Share on other sites

Can you quote the exact code you are using?

The linked pastebin is the exact code. I haven't used lists for anything yet, but I was thinking about upgrading my ascent program's staging logic to look for empty boosters and empty tanks connected to fuel lines instead of just looking at MAXTHRUST, so that it can handle asparagus staging and vessels that mix liquid and solid motors (for partial throttle control and/or thrust vectoring). I was trying to poke at the result of "list engines in foo." in the terminal when I ran into that error.

The zip file from Curse says it's 0.15.5 in kOS.version, so I'll try that one. If that doesn't fix it, I can try to figure out how to build kOS. I don't see a Makefile or any artifacts of cmake or GNU autotools, so the build system is unfamiliar. It could get a bit hairy.

Link to comment
Share on other sites

The linked pastebin is the exact code. I haven't used lists for anything yet, but I was thinking about upgrading my ascent program's staging logic to look for empty boosters and empty tanks connected to fuel lines instead of just looking at MAXTHRUST, so that it can handle asparagus staging and vessels that mix liquid and solid motors (for partial throttle control and/or thrust vectoring). I was trying to poke at the result of "list engines in foo." in the terminal when I ran into that error.

The zip file from Curse says it's 0.15.5 in kOS.version, so I'll try that one. If that doesn't fix it, I can try to figure out how to build kOS. I don't see a Makefile or any artifacts of cmake or GNU autotools, so the build system is unfamiliar. It could get a bit hairy.

I'll double check the list code when making a new list, but I know that the current version is able to iterate over a list without throwing an error (the first thing my boot script does is look for kOS processors and toggle their display).

As for the build environment, I think that the primary devs just use Visual Studio on windows to build the files. I think that mono will compile the solution as well.

Link to comment
Share on other sites

As for the build environment, I think that the primary devs just use Visual Studio on windows to build the files. I think that mono will compile the solution as well.

I used SharpDevelop on Windows, and I think others have had success with Monodevelop on unix.

C# is like Java in that it tries to avoid the need for a makefile by tracking dependencies for you. Unlike java though it doesn't do the simple thing of just enforcing that you have to use the same name for the files as for the classes or the same name for the directories as for the namespaces, which means it has to keep track of that mapping in a separate XML file. That XML file holds the dependencies info.

Edited by Steven Mading
Link to comment
Share on other sites

Hello,

Anyone know if there is a way to call a KOS script or method from another part? I'm thinking of creating a prop that could run a set script or command at its activation, think a switch of some sort would set throttle to 10% or similar behavior like that.

Appreciate any help or input.

Link to comment
Share on other sites

Sadly, no it isn't. The :PITCH suffix doesn't really mean "pitch". It's a badly named suffix dating back to the original mod author that we're now sort of stuck with for backward compatibility. What it *actually* does is rotate around the X axis of the universe, wherever that X axis happens to currently be pointed.

To get what you want I recommend this:


lock proPitchOrb to 90 - VANG(SHIP:VELOCITY:ORBIT,SHIP:UP:VECTOR).
lock proPitchSrf to 90 - VANG(SHIP:VELOCITY:SURFACE,SHIP:UP:VECTOR).

.

I don't know your purpose, so it's up to you which kind of prograde you want - the orbital or the surface.

Both of them work by using the up vector as the normal to the horizon, and comparing the angle between that and your movement vector.

In general, that's the solution to the problem "what is the angle between vector V and plane P" - it's (90 - (angle between V and P's normal)).

Thanks, I will try this out. It's for an RSS rocket launch-orbit autopilot.

Link to comment
Share on other sites

Using the zip from Curse fixed the list access problem, so it looks like the one on Github is an older prerelease version. Heh, kind of reminds me of that incident with Ariane 5.

In any case, thanks everyone who gave advice on building C#.

Link to comment
Share on other sites

Whats the deal with SHIP:HEADING ? I not get any degrees instead I get numbers in the area of X*10^-6 or smaller. SHIP:BEARING gives me degrees however.

The heading suffix gives the direction from the cpu vessel to the selected vessel. So if you target another vessel and then use target:heading it will give you the absolute direction to that vessel: http://ksp-kos.github.io/KOS_DOC/structures/vessels/vessel.html#VESSEL:HEADING

Link to comment
Share on other sites

The code in this post might be useful. You will need to change the module to the appropriate Infernal Robotics one (DTMagnetometer to MuMechToggle) and change the |b| to whatever field you want to get from the right click menu. Do not forget to name your part and to apply the name to the code.

Should be easy breezy ;)

Before I start the painful and slow process of learning this language, I've discovered it won't work. The parts I use are free runners (like the docking washer free), and IR's library doesn't give a readout on the rotation values. Too bad.

Hopefully one day there will be a solution so I can give my engine(s) a proper ignition system. Until then, I'm going to shelve the project again.

Thanks anyway!

Edit: Okay I was a bit quick because of disappointment.

There is a different approach, it seems it's possible to read the rotational value of any part, compared with KSP's coordinates system. If kOS can read the angle of two parts and compares them, I'd have the amount of degrees I need.

Actually the structure would be very simple: imagine a single cylinder two stroke engine. The crankshaft starts turning at 180 degrees, piston is at bottom dead center. Once it has turned exactly 185 degrees, then the piston is 5 degrees past top dead center. At that moment the program starts action group 1, which fires a jet, pushing the piston down. when the piston is 5 degrees in front of bottom dead center, the program stops action group 1. Repeat from start.

Two-Stroke_Engine.gif

If someone could help me, that would be very much appreciated. My brain works primarily with images, movies and sound. I was good at physics as long as I could visualize the stuff.

But ...

I've always been a disaster at mathematics and programming because I just can't visualize these things. I once tried learning a simple language and I found it easier to learn Klingon.

Edited by Azimech
Link to comment
Share on other sites

Before I start the painful and slow process of learning this language, I've discovered it won't work. The parts I use are free runners (like the docking washer free), and IR's library doesn't give a readout on the rotation values. Too bad.

Hopefully one day there will be a solution so I can give my engine(s) a proper ignition system. Until then, I'm going to shelve the project again.

http://youtu.be/RLuHFSExlcA

Thanks anyway!

kOS does allow you to read the position and orientation of a whole part. While you can't read the sub-positions and sub-orientations of parts within parts (the sliding piece within an IR part), you can read the positions of whole parts. So whatever whole part is attached to your rotating IR part might be queryable for its PART:FACING, to get an idea. I can't tell from the video exactly how your parts are attached so I don't know for sure if this would work.

I've just verified this is true, and passed it on to erendrake. A fix is coming soon.

Edited by Steven Mading
Link to comment
Share on other sites

"PART:FACING" sounds like a good idea. Here's an example setup:

JqN7Z6M.png

gla3CGI.png

This would be complicated enough. For the far future I have lots of ideas but I'm happy when I don't have to tap my keyboard like with this one:

Link to comment
Share on other sites

In your example I imagine you should be able to get the vector cross product of the facing:vector of the crankshaft and the facing:vector of one of the piston housings to work out the crankshaft position.

Something a bit like this might work:

Assume PIST is the Part of one of the pistons, and it's oriented such that its STARBOARD facing is out the side of the engine (you may have to change STARVECTOR for TOPVECTOR in my example below if it's not):

Assume CRANK is the Part of the crankshaft, and that its TOP vector is pointing radially outward while its FORE direction is along the shaft axis.


LOCK cosValue to VDOT(PIST:FACING:FOREVECTOR,CRANK:FACING:TOPVECTOR).
LOCK sinValue to VDOT(PIST:FACING:STARVECTOR,CRANK:FACING:TOPVECTOR).
LOCK crankAngle to ATAN2( sinValue, cosValue ).

You may have to try it with different variations of FOREVECTOR, STARVECTOR, and TOPVECTOR depending on how the orientation of your parts is defined. I'm just guessing from the image one way they *might* have been defined. Basically, FORE is the Z axis of the part's local transform, STAR is it's X axis and TOP is its Y axis.

Edited by Steven Mading
I had the arguments to ATAN2 swapped
Link to comment
Share on other sites

How do I convert these values into degrees? And what is this ATAN2?

Moreover, how do I tell kOS to act on that value. If I want to build an engine with multiple cylinders, I need to program in a lot of angles.

Something else ... I've been busy for an hour and a half, trying to find kerboscript for enabling and disabling an action group. Can't find it. It's not in the new manual and can't find it using google. Is it even possible?

Edited by Azimech
Link to comment
Share on other sites

How do I convert these values into degrees? And what is this ATAN2?

The problem with normal arctan is that when you divide Y by X to get the tangent, you lose some of the sign information. The fraction (-1/-1) and the fraction (1/1) both result in 1. The fraction (-1/1) and (1/-1) both result in -1. So you can't quite narrow down which quadrant of the 360 degree circle you're in. A tangent of 1.0 MIGHT be 45 degrees or it might be in the opposite quadrant, at 225 degrees.

Atan2 (a second variant of arctan) is a thing computer math libraries added to allow you to get the full quadrant information by having you pass in both the numerator and denominator components of the tangent separately so it knows what the sign of each are. (ATAN2 *can* tell the difference between 45 degrees and 225 degrees because it knows if that 1.0 value was the result of dividing two positive numbers or two negative numbers).

Moreover, how do I tell kOS to act on that value. If I want to build an engine with multiple cylinders, I need to program in a lot of angles.

No idea. That's too open-ended of a question, with multiple possible approaches.

Something else ... I've been busy for an hour and a half, trying to find kerboscript for enabling and disabling an action group. Can't find it. It's not in the new manual and can't find it using google. Is it even possible?

 AG1 on.  AG1 off.  AG2 on. AG2 off. // etc...

Link to comment
Share on other sites

Well ... I'd like to start with displaying crankangle value on the screen. I'll rotate the crankshaft to the right angle, read the crankangle value and then it's a simple act of

WHEN crankangle=185 THEN

AG1 on.

WHEN crankangle= 355 THEN

AG1 off.

or when having multiple cylinders, values like 45/215, 90/260, 120/290 etc.

I tried this code but I don't understand the basics. At all.

KRaiSVc.png

Link to comment
Share on other sites

Well ... I'd like to start with displaying crankangle value on the screen. I'll rotate the crankshaft to the right angle, read the crankangle value and then it's a simple act of

WHEN crankangle=185 THEN

AG1 on.

WHEN crankangle= 355 THEN

AG1 off.

or when having multiple cylinders, values like 45/215, 90/260, 120/290 etc.

I tried this code but I don't understand the basics. At all.

http://i.imgur.com/KRaiSVc.png

Too complicated. Why don't you use the laser distance mod to check for a nub on your flywheel? Far simpler, and true to the way ignition really works.

- - - Updated - - -

- - - Updated - - -

- - - Updated - - -

I have a new problem.

Boot files.

First of all, the new documentation makes no mention of boot files at all.

When trying to implement three cores, I cannot select the boot file in the VAB. The slider appears, and it counts the correct number of files beginning with "boot" (boot1.ks, boot2.ks, boot3.ks

or alternately booted.ks, bootgrn.ks, bootblu.ks)

Only one shows up. So I get three slider options, but they are all for the same file name.

Edited by Dr_Goddard
i'm a dope
Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...