kOS Scriptable Autopilot System 0.9

[AbeS]

to get my surface prograde in a way that can be used with 'lock steering to heading azimuth by inclination.' I use the following code: (most of it was copied from the wiki)

lock tfv to velocity:surface.

lock tfA to latitude.

lock tfB to 0 - up:yaw.

lock tfE to -1*tfv:x*cos(tfB) + 0 + -1*tfv:z*sin(tfB).
lock tfN to tfv:x*sin(tfA)*sin(tfB) + tfv:y*cos(tfA) + tfv:z*(0-sin(tfA)*cos(tfB)).
lock tfU to tfv:x*(0-cos(tfA)*sin(tfB)) + tfv:y*sin(tfA) + tfv:z*cos(tfA)*cos(tfB).

lock tfR to (tfe^2 + tfn^2 + tfu^2)^0.5.

lock incl to arcsin(tfu/tfR).

//set azi to arctan(tfe/tfn). // I can only make azimuth work in loops because of how arctan works, and I don't use it very much

//if tfn>0 and tfe<0 {set azi to 360 + azi.}.

//if tfn<0 {set azi to 180 + azi.}.

You could put everything in a loop and use the 'set' command instead of locking, or just use 'unlock all.' after using it

[ravis788]

Well, I'm new to this wonderful mod, and needed to know why isn't "lock throttle to 1." working in any of my tiny test programs? All the test consists of is 2 lines, "stage." and "lock throttle to 1." some insight would be nice.

[Camacha]

Well, I'm new to this wonderful mod, and needed to know why isn't "lock throttle to 1." working in any of my tiny test programs? All the test consists of is 2 lines, "stage." and "lock throttle to 1." some insight would be nice.

You might want to read the Wiki FAQ as your question is in there, along with some common problems you might encounter Cheers!

Edited December 2, 2013 by Camacha

[Dunbaratu]

I meant that until false and until true should both be conditions that are never met, as there is nothing specified to compare the condition to. kOS seems to assume that comparing to nothing means comparing with some built in boolean that it not 0. Or am I confused here?

Oh that. It basically works like this:

Every expression is a thing that returns another variable. When you say "5 + 4 * 2", for example, the "4 * 2" is an expression that gets evaluated, and then removed and replaced with a number in its place (8), and then you now have "2 + 8", which gets evaluated and removed and replaced with the result, "10".

Boolean comparators do the same exact thing. "x < y" is an expression just like any other. It gets evaluated and then replaced with the result, which in this case is a Boolean value. So for example, "x < y + 2" does this:

Step 1: evalutate "y + 2" and replace it with the result (let's say y was 3, so the result is a 5).

You now have the expression "x < 5".

Step 2: evaluate the expression "X < 5' and replace it with the result (let's say X was 7 so the result is "false").

Now you've reduced the entire expression "x < y + 2" down to one single value - the boolean value False.

So when you have code like this:

if x < y + 2 ... stuff ...

or code like this:

if false .... stuff ....

They're both sort of operating the same way. The first one is evaluating the entire expression "x < y + 2" and calculating that it's value is "false" and then it's acting upon that boolean value of "false", just as it would have had you hardcoded it to the value "false".

That being said, some programming compilers will notice things like this and issue warnings about it, just in case you did it by mistake. after all, "if false do-something" seems like a stupid mistake, as it means the code never gets executed so why is it even there. But it can be a very handy way when debugging code to temporarily disable a section of code - just put a chunk of code inside an "if false" block and it's as good as commenting it out.

[Dunbaratu]

to get my surface prograde in a way that can be used with 'lock steering to heading azimuth by inclination.' I use the following code: (most of it was copied from the wiki)

lock tfv to velocity:surface.

lock tfA to latitude.

lock tfB to 0 - up:yaw.

lock tfE to -1*tfv:x*cos(tfB) + 0 + -1*tfv:z*sin(tfB).
lock tfN to tfv:x*sin(tfA)*sin(tfB) + tfv:y*cos(tfA) + tfv:z*(0-sin(tfA)*cos(tfB)).
lock tfU to tfv:x*(0-cos(tfA)*sin(tfB)) + tfv:y*sin(tfA) + tfv:z*cos(tfA)*cos(tfB).

lock tfR to (tfe^2 + tfn^2 + tfu^2)^0.5.

lock incl to arcsin(tfu/tfR).

//set azi to arctan(tfe/tfn). // I can only make azimuth work in loops because of how arctan works, and I don't use it very much

//if tfn>0 and tfe<0 {set azi to 360 + azi.}.

//if tfn<0 {set azi to 180 + azi.}.

You could put everything in a loop and use the 'set' command instead of locking, or just use 'unlock all.' after using it

Does that work for you? Using variables in "lock" that have capital letters in them like "tfE", "tfN", and "tfU"? I thought that bug wasn't fixed in public release yet. (The bug being that "lock variable to (expression)" only works right when the name of the variable is in all lower-case letters.)

[Dunbaratu]

lock td to target:distance.

wait until td < 150.

Works but:

wait until target:distance < 150.

Gives the notorious "can't compare number to number" error.

Hmmm. Interesting. It still gives an error when you use "set" instead of "lock". Something specific to how the "lock" code evaluates expressions (where it stores the expression parse tree and re-evaluates it on the fly each time it's used) seems to be getting around the number type problem.

I realize the logic of using 'set' isn't appropriate to what you're trying to do, but what I mean is that as a way to work around the number type problem, setting a variable does NOT work. It's only LOCKING one that seems to perform an end-run around the problem.

Edited December 2, 2013 by Steven Mading

[Dunbaratu]

lock ts to vessel("battery").

lock wheelsteering to ts.

I've never been able to understand wheelsteering. I wish I could just control rovers the same way I control flight - by just picking a direction and an amount of thrust, rather than having to aim at target vessels. But every time I try that it behaves really weirdly.

[sierra_seven_]

Many thanks Sma. Finally, time to start designing programs!

[AbeS]

Does that work for you? Using variables in "lock" that have capital letters in them like "tfE", "tfN", and "tfU"? I thought that bug wasn't fixed in public release yet. (The bug being that "lock variable to (expression)" only works right when the name of the variable is in all lower-case letters.)

It worked on 0.9.0. After that, I read your warning about it not working in 0.9.2, so when I tested I changed everything to lower-case. But I forgot to modify the file

[goldenpeach]

Is there a way to make the engines have different thrust?

I could use that instead of RCS for my grasshopper like rocket

[Camacha]

Is there a way to make the engines have different thrust?

I could use that instead of RCS for my grasshopper like rocket

Unfortunately the answer is also no. I would really love that as a feature, as in some cases it would enable you to write your own attitude control software. I do not really like how simplistic the lock steering to is currently.

Many thanks Sma. Finally, time to start designing programs!

No problem

Edited December 3, 2013 by Camacha

[goldenpeach]

It seem that the only solution would be to use 4 more rocket for that: one for each axis.

The rocket would push the grasshopper in the wanted direction.

Theoretically possible,but it would required a little more coding

[Camacha]

It seem that the only solution would be to use 4 more rocket for that: one for each axis.

Three engines would be enough; just look at tricopters, they work on the same principle. Any higher number of engines would also work.

Theoretically possible,but it would required a little more coding

Yes, we are coding for fun, so you might as well code this too

Edited December 3, 2013 by Camacha

[goldenpeach]

I can't even make two of my "grasshopper" to execute nicely the program at the same time, I doubt I could make it with five rocket and two different design!

Maybe if I make the "grasshopper" pitch/yaw a little to compensate?(note:it's just an idea I've got while writing this, I didn't tested it and I will probably think about that later(laziness ))

EDIT: It's true that I code just for the fun: I have made a code that make an sub-orbital flight(didn't want to code the circularization part).

It have an auto-abort function:if the engine stop working(or if it's disconnected from the craft),it fire the LES.

Sometime, I do some useful codes:the last one I did was a (very) simple one that jettisoned the LES once I reach 25 000 meters(I like to be able to do something else while mechjeb launch my rocket into orbit). By simple, I mean 2 lines of codes.

Edited December 3, 2013 by goldenpeach

[Dunbaratu]

I've tried using action groups to activate RCS ports but that doesn't work. The only thing you can get an RCS thruster to do via an action group is to engable/disable it. But you can't tell it to actually thrust.

[Camacha]

Maybe if I make the "grasshopper" pitch/yaw a little to compensate?(note:it's just an idea I've got while writing this, I didn't tested it and I will probably think about that later(laziness ))

This is, among other things, pretty much exactly what have been working on the past few days. The concept is easy, but the execution is not so trivial, although it also depends on whether you are taking shortcuts, are using a PID-controller or opt for the full mathmatical model.

Edited December 3, 2013 by Camacha

[Sacred Aardvark]

I've never been able to understand wheelsteering. I wish I could just control rovers the same way I control flight - by just picking a direction and an amount of thrust, rather than having to aim at target vessels. But every time I try that it behaves really weirdly.

I've noted an issue with mechjebs rover autopilot as well (and I understand that kOS autopilot was at least partially cannibalized from MJ), where a probe core on top of the rover works fine while on flat ground, but goes loopy on angled terrain (my Mun rover flash backed to it's gymnast days and did a 180 half flip with tuck). Reason being that for the probe core "forward" is in fact "up", meaning if you drive to heading 90 and go from flat ground to a hill, your up vector is now pointing slightly back so your heading "is" 180, autopilot goes "EEP! Where am I going?" and turns the wheels, when in reality you were still traveling in the right direction.

Easily fixed (probably) by turning your rovers probe core 90 degrees, so that top of the probe core points towards the front of the rover.

edit: Goes without saying but I'll say it anyway: Obviously said angled probe core shouldn't then be used for flying, it Will crash.

Edited December 3, 2013 by Sacred Aardvark

[goldenpeach]

[..] Obviously said angled probe core shouldn't then be used for flying, it Will crash.

I don't see how it can be a problem

Why did I read that post?! Now I will be obsessed with making a code that compensate form angled probe core at launch!

[Dunbaratu]

I've noted an issue with mechjebs rover autopilot as well (and I understand that kOS autopilot was at least partially cannibalized from MJ), where a probe core on top of the rover works fine while on flat ground, but goes loopy on angled terrain (my Mun rover flash backed to it's gymnast days and did a 180 half flip with tuck). Reason being that for the probe core "forward" is in fact "up", meaning if you drive to heading 90 and go from flat ground to a hill, your up vector is now pointing slightly back so your heading "is" 180, autopilot goes "EEP! Where am I going?" and turns the wheels, when in reality you were still traveling in the right direction.

That isn't the problem. Even with a sideways turned probe core I still get it going in odd directions when I try to steer by "lock steering to heading 45 by 0" - it doesn't go anywhere near the 45 degree mark on the compass, and when I try using WHEELSTEERING I have to set it by a target vessel rather than a direction.

[goldenpeach]

I had the same problem.

In fact, when if you use heading(45,0) it will make you fly with heading 0 degrees(a.k.a north) 45 degrees above horizon.

The if you want to go toward the 45 degree mark(0 degree above horizon) you have to use heading(0,45)

[Mulbin]

Ok... this mod is amazing! I've been learning the basics and have managed to write a passable autopilot for the update I am currently working on to my stock Mercury Redstone replica.

One thing that I have never previously been able to do is recreate the correct cyclling on the posigrade and retro rockets (which fired in succession on mercury capsules).. now the autopilot can control them!

Here is a video of my complete freedom 7 program, it has a short window in which the pilot is given control of the rcs system to test it (as with the real mission), otherwise all actions are performed by the autopilot.

Key events are at these times...

0:00

3:50

5:30

6:00

10:50

Edited December 3, 2013 by Mulbin

[sunrakhan]

Hi !

Mulbin, your video is tagged private so we cannot watch it.

[Mulbin]

Hi !

Mulbin, your video is tagged private so we cannot watch it.

Whoops! fixed

[drtedastro]

Hello, At one point in time there was talk about setting up a repository of code for the users to view / share / learn from. Was that done?

Thanks for any info / help. Looks like I am finally going to have time to properly play / test this mod.

Again, thanks.

[Dunbaratu]

I had the same problem.

In fact, when if you use heading(45,0) it will make you fly with heading 0 degrees(a.k.a north) 45 degrees above horizon.

The if you want to go toward the 45 degree mark(0 degree above horizon) you have to use heading(0,45)

No, not with parentheses.

HEADING 45 BY 0 is what I said, not HEADING(45,0). When using parens the numbers flip position for some bizarre reason. so if you got that to work the way you describe you got it to work more than I did.