kOS Scriptable Autopilot System 0.9

[Kalista]

This isn't totally a bug report per se more like an incompatibility report. Prior to the latest update the mod would work with remote tech 2 ( it needed to have stages locked ect and it didn't work seemlessly but for using it to perform stuff when under heavy time lag or out of contact it was flawless). Now with the .50 update the mod will refuse to work at all if running from the archive folder. Infact if your antennae or comm dish changed at all either the file itself or thru module manager attempting to switch to archive will cause KoS to freeze and go unresponsive unless you kill its power and reboot it. Just posting this report since the original reason I got this program was to use in tandem with remote tech but since KevinLaity seems to be going in the direction of making his own comm code this may not be an issue in the future.

[Sma]

SMA,

You would get more accurate fuel values if you activate the asparagus stages first, check the fuel, then active the main engine - all before launch.

Assuming all asparagus stages are identical:

set acount to 3. // How many stages are asparagus.
set totalfuel to <liquidfuel>.
stage. wait 1. //all asparagus stages activated but not main engine.
set aspfuel to stage:liquidfuel. //total fuel in the 3 stages
set eachstagefuel to aspfuel /acount.

stage. //main engine start and clamp release
lock throttle to 1.
set x to acount.
set spentstages to 0.
until x = 0 {
   set currenttotal to <liquidfuel>
   if currenttotal < (totalfuel-(eachstagefuel *(spentstages+1)) { 
      stage. 
      set x to spentstages+1. 
      set spentstages to acount-x. 
   }.
}.

Obviously, you have to adjust to include launch code, like the gravity turn but it's a start!

Cool thanks. I was only working with boosters that each fed to the main tank for now, and had it staged so the boosters and clamps went at the same time, then the main engine. It works to a point except that since the boosters started and clamps released first, a tiny bit of fuel is used. Also I didn't think about not setting the throttle and holding off on clamp release lol.

I do have the gravity turn working, as well as the upper stage release (and I've got it set to deploy solar panels once in orbit). I'll try the example from your code with my non asp test launcher and see how it goes, then try asp staged. Was hoping for an all around generic launcher program, but I guess asp stage will need it's own, which could I guess work for all asp staged rockets, so long as the asp count is the same.

Wonder if there are plans in the work that take input while the program is running. Would work well in this case, the program could ask "How many asp stages?".

Edited September 10, 2013 by Sma

[Secret Squirrel]

I am by far no expert on this but I made a little selection program, I am using it to test a cruse control for my rover. Might not be the best way but I can input a number by increasing or decreasing using action groups.

clearscreen.
set x to 10.
set y to 10.
set reset to 0.
set go to 0.




until go = 1 {
clearscreen.
print "ag1 for up".
print "ag2 for down".
print "ag3 for set".
print "is set to " + y.
set reset to 0.

until reset = 1 {

on ag1 set y to x + 1.
on ag1 set reset to 1.
on ag2 set y to x - 1.
on ag2 set reset to 1.
on ag3 set go to 1.
on ag3 set reset to 1.
wait until reset = 1.
set x to y.
}.

}.

print "It works if " + x + " was my number".

[Payload]

What I don't get is how exactly are we supposed to launch into an inclined orbit? The vector control we have is just straight up inadequate. Prograde is directly towards the velocity vector. It's on the nav ball. Why is prograde not prograde until your in orbit with this plug-in? The other vector controls seems to be off as well. Say I set R(-45,-45,-90). It seems that those values are yaw pitch and roll. But they aren't. They are some kind of weird vector that doesn't take into account initial vector at all. You can do up + R(-45,-45,-90) and you would expect that to Roll your feet to the sky and point you on a vector of 45deg to the NE and pitch you down 45deg on the nav ball. It doesn't! In fact, I'm not sure what is even going on there as it just ignores whatever roll commands you set then. Why even have a roll command if what you have really given us is not (Yaw, Pitch, Roll,) but (Northing, Easting, Who Knows.)?

Edited September 10, 2013 by Payload

[Dunbaratu]

Why is prograde not prograde until your in orbit with this plug-in?

Because the plugin always is giving the orbital prograde direction, regardless of whether you're in orbit or not. The plugin doesn't have a way to give you the surface prograde vector. (It should.) The closer to the surface you are, the more and more off the orbital prograde vector will be from the surface prograde vector. On Kerbin, for example, the surface is moving at 174.53 m/s toward the east, and so when you're just standing still on the launchpad the orbital prograde vector shows you going 174.53 m/s sideways when you're just sitting there. This is why it's difficult at the moment to write autopilot scripts for landing. I've had limited success by constantly watching the change in latitude and longitude (which is accessible) and by doing a bit of arithmetic using the planetary circumference you can work out how many meters a certain change in latitude or longitude is, but it's only accurate near the equator.

[KevinLaity]

Because the plugin always is giving the orbital prograde direction, regardless of whether you're in orbit or not. The plugin doesn't have a way to give you the surface prograde vector. (It should.) The closer to the surface you are, the more and more off the orbital prograde vector will be from the surface prograde vector. On Kerbin, for example, the surface is moving at 174.53 m/s toward the east, and so when you're just standing still on the launchpad the orbital prograde vector shows you going 174.53 m/s sideways when you're just sitting there. This is why it's difficult at the moment to write autopilot scripts for landing. I've had limited success by constantly watching the change in latitude and longitude (which is accessible) and by doing a bit of arithmetic using the planetary circumference you can work out how many meters a certain change in latitude or longitude is, but it's only accurate near the equator.

Another reason for this is because during a launch the ship is going to naturally veer off. If you say "always steer in the direction you're already moving", then there will be no correction for that drift.

This is also a problem in orbit, but the problem is less pronounced because you're moving at orbital velocity and any drift will be negligible compared to that velocity.

EDIT: And yes I really should add that in.. I have a surface velocity scalar but no vector at the moment, I'll make sure it's in the next update

Edited September 10, 2013 by KevinLaity

[Payload]

Because the plugin always is giving the orbital prograde direction, regardless of whether you're in orbit or not. The plugin doesn't have a way to give you the surface prograde vector. (It should.) The closer to the surface you are, the more and more off the orbital prograde vector will be from the surface prograde vector. On Kerbin, for example, the surface is moving at 174.53 m/s toward the east, and so when you're just standing still on the launchpad the orbital prograde vector shows you going 174.53 m/s sideways when you're just sitting there. This is why it's difficult at the moment to write autopilot scripts for landing. I've had limited success by constantly watching the change in latitude and longitude (which is accessible) and by doing a bit of arithmetic using the planetary circumference you can work out how many meters a certain change in latitude or longitude is, but it's only accurate near the equator.

I know man, If we had the actual velocity vector, we could easily orient the craft and pitch anti heading until surface speed was reduced. It doesn't have to be an exact pitch either as long as it is enough to cancel the horizontal speed before you hit the ground. Preferably, a few hundred meters before you hit the ground. I have just been using horizontal speed canceling devices. AKA parachutes. I have managed to get some inclination on orbits by sort of hacking my way through it. Though it isn't ideal and it messes up your G-turn. It's just bizarre. It has you thinking that it works in some kind of absolute vector but that isn't the case either. If it was, then when you set up + R(-90,-90,0). it would put you on the horizon of the nav ball with a 45deg NE vector. Nope then it doesn't do anything. It just freaks out and sets whatever angle you set first to horizon on the nav ball.

From what I have worked out so far, this is the understanding I am getting from the system. R(Pitch North, Pitch East, Rollsometimes) Pitch North and Pitch East are not vector additive. It has no idea what to do when you tell it you want to pitch north and east at the same time.

EDIT:

Another reason for this is because during a launch the ship is going to naturally veer off. If you say "always steer in the direction you're already moving", then there will be no correction for that drift.

This is also a problem in orbit, but the problem is less pronounced because you're moving at orbital velocity and any drift will be negligible compared to that velocity.

EDIT: And yes I really should add that in.. I have a surface velocity scalar but no vector at the moment, I'll make sure it's in the next update

Why would it drift if we have a compass? I would yaw until heading was correct and then hold heading. No one says let's just always steer in the same direction. They say let's steer in the same direction on the compass. How do you do it when you manually fly a rocket in to space? You hold a cardinal line on the nav ball right? The modifiers are nice but they aren't really needed if you can only really use them to go North South East or West and nothing in between.

Edited September 10, 2013 by Payload

[KevinLaity]

Why would it drift if we have a compass? I would yaw until heading was correct and then hold heading. No one says let's just always steer in the same direction. They say let's steer in the same direction on the compass. How do you do it when you manually fly a rocket in to space? You hold a cardinal line on the nav ball right? The modifiers are nice but they aren't really needed if you can only really use them to go North South East or West and nothing in between.

Sorry, then I'm not sure what you're asking for, you talked about locking to the surface prograde vector. Now you're saying that you want to lock to a heading, which is it?

Maybe you're thinking of locking to the prograde vector for pitch only. But if that's the case your pitch will drift too.

Edit: I re-read your post, I think your confusion is that you're thinking of R() structures as being absolute. They're not, they're relative, that's why you use a + with them. It's UP + a relative rotation. That's why the numbers seem crazy to you.

Maybe what you're really looking for is something that will let you just input an absolute heading and pitch. That's something that's been asked for and may occur yes.

Edit2:

R(Pitch North, Pitch East, Rollsometimes)

It's R(Pitch, Yaw, Roll) and those are applied in the order of Roll, then Yaw, then Pitch. There is no such thing as pitching north. Pitching and yawing are relative terms, the direction they take you depend on the direction you're facing.

The 'sometimes' here makes me think you're running into a gimbal lock problem.

Edited September 10, 2013 by KevinLaity

[Payload]

Sorry, then I'm not sure what you're asking for, you talked about locking to the surface prograde vector. Now you're saying that you want to lock to a heading, which is it?

Maybe you're thinking of locking to the prograde vector for pitch only. But if that's the case your pitch will drift too.

Edit: I re-read your post, I think your confusion is that you're thinking of R() structures as being absolute. They're not, they're relative, that's why you use a + with them. It's UP + a relative rotation. That's why the numbers seem crazy to you.

Maybe what you're really looking for is something that will let you just input an absolute heading and pitch. That's something that's been asked for and may occur yes.

If I where to actually control pure yaw pitch and roll. I would need not only a horizontal heading but a vertical heading as well. Then what would I use as a roll target? What I'm saying is there is no way to launch a rocket into an inclined orbit. At some point we have to control the rocket into space. Right now I don't see a way of doing that unless you want to go in the four cardinal directions only. I'm saying that the R() structure, the way it functions, is not adequate to control a rocket. I need to be able to tell the computer I want to hold a horizontal heading, a vertical heading, and a roll target. That is what those three values should be. It appears that you are already tracking those targets in some fashion anyway. Try to launch a rocket into a 45deg NE inclination and have it stick to a proper ascent curve. You'll see what I'm talking about.

It's R(Pitch, Yaw, Roll) and those are applied in the order of Roll, then Yaw, then Pitch. There is no such thing as pitching north. Pitching and yawing are relative terms, the direction they take you depend on the direction you're facing.

The 'sometimes' here makes me think you're running into a gimbal lock problem.

Except that isn't what is happening. I can roll to any angle and change the middle value and it still pitches the rocket to the east! I'm serious. I have tried all combinations of those things. They are most certainly not roll yaw and pitch. Even if they where, they have no target for me to check against.

You seem to be straddling this line between hardcore low level programing and scripting language. If its the former, then it's much too verbose and if it's the latter, the modifiers are incorrectly envisioned because they won't allow you to actually fly the rocket correctly.

Edited September 10, 2013 by Payload

[KevinLaity]

If I where to actually control pure yaw pitch and roll. I would need not only a horizontal heading but a vertical heading as well. Then what would I use as a roll target? What I'm saying is there is no way to launch a rocket into an inclined orbit. At some point we have to control the rocket into space. Right now I don't see a way of doing that unless you want to go in the four cardinal directions only. I'm saying that the R() structure, the way it functions, is not adequate to control a rocket. I need to be able to tell the computer I want to hold a horizontal heading, a vertical heading, and a roll target. That is what those three values should be. It appears that you are already tracking those targets in some fashion anyway. Try to launch a rocket into a 45deg NE inclination and have it stick to a proper ascent curve. You'll see what I'm talking about.

Except that isn't what is happening. I can roll to any angle and change the middle value and it still pitches the rocket to the east! I'm serious. I have tried all combinations of those things. They are most certainly not roll yaw and pitch. Even if they where, they have no target for me to check against.

You seem to be straddling this line between hardcore low level programing and scripting language. If its the former, then it's much too verbose and if it's the latter, the modifiers are incorrectly envisioned because they won't allow you to actually fly the rocket correctly.

You're right, it is inadequate. Not being able to hit 45 degrees (easily) is a result of gimbal lock. The reason gimbal lock is a problem is because I knew having the user input matrices was asking way too much, yet I wanted to give them full freedom to rotate to any arbitrary direction, regardless of the planet.

In theory you could do something like UP + R(-90,0,0) + R(0,45,0) + R(30,0,0) I don't have KSP at work to test that but in theory that would start with the up vector, point it toward the horizon, yaw 45 degrees to the NE, and then pitch back up 30 degrees. If you can imagine that we're turning an imaginary vessel in those directions by those steps and then asking the real vessel to point in that final direction.

However that's WAY TOO COMPLICATED and I'm realizing more every day that people need to be able to just call out the degrees that are on the navball. Plus R(,,) is very programmerish for a language that tries to be accessible.

So now I'm thinking what should the syntax for that be? I'm thinking something like LOCK STEERING TO heading BY pitch_from_horizon.

[CaptainKipard]

What I'm saying is there is no way to launch a rocket into an inclined orbit. At some point we have to control the rocket into space. Right now I don't see a way of doing that unless you want to go in the four cardinal directions only. I'm saying that the R() structure, the way it functions, is not adequate to control a rocket. I need to be able to tell the computer I want to hold a horizontal heading, a vertical heading, and a roll target. That is what those three values should be. It appears that you are already tracking those targets in some fashion anyway. Try to launch a rocket into a 45deg NE inclination and have it stick to a proper ascent curve. You'll see what I'm talking about.

You can't launch into a precisely inclined orbit by simply following a heading. Your heading is only related to the inclination value at the ascending and descending nodes. Half way between those your heading is basically east or west ALWAYS (except when you're in a perfectly polar orbit). The farther away you move from the nodes the bigger the difference is basically until you're half way between the nodes where the difference between your heading and inclination IS the value of your inclination. You'll need to do some serious orbital maths to keep a steady inclination during your ascent.

Edited September 10, 2013 by Cpt. Kipard

[Payload]

I don't want it to seem like I'm criticizing because I actually don't know how to use this correctly I guess.

I mean I have no idea if this result is correct or not? No examples of how this works have really been given. I am just working form pure instinct here. Somebody has to do this first. How would the average person know that UP + R(-90,0,0) + R(0,45,0) + R(30,0,0) equates to pitch of 21 a heading of 338 and a roll of -131? Is that even right? And there are no control problems that is with hacked gravity on.

You can't launch into a precisely inclined orbit by simply following a heading. Your heading is only related to the inclination value at the ascending and descending nodes. Half way between those your heading is basically east or west ALWAYS (except when you're in a perfectly polar orbit). The farther away you move from the nodes the bigger the difference is basically until you're half way between the nodes where the difference between your heading and inclination IS the value of your inclination. You'll need to do some serious orbital maths to keep a steady inclination during your ascent.

Here is the thing. You can postulate all you like. But I wrote a heading hold script yesterday that got me into a perfect 45deg Inclined orbit. Heading is a variable that we have access too. The problem is you can't control both pitch and heading at the same time in practice.

Edited September 10, 2013 by Payload

[KevinLaity]

How would the average person know that UP + R(-90,0,0) + R(0,45,0) + R(30,0,0)...

You're right, which is why I said it's way too complicated and a solution is needed. See my blog post.

...equates to pitch of 21 a heading of 338 and a roll of -131? Is that even right? And there are no control problems that is with hacked gravity on.

The example I gave you should equate to a heading of 45 and a pitch of 30. Although I may have some of the dimensions wrong, again I can't test right now.

[CaptainKipard]

Here is the thing. You can postulate all you like. But I wrote a heading hold script yesterday that got me into a perfect 45deg Inclined orbit. Heading is a variable that we have access too.

If that's true then whatever variable you're using is not actually a heading. Maybe Kevin made a mistake, or maybe you're confusing concepts, but a heading is your compass direction, and compass directions aren't useful for holding an inclination during orbital insertions for the reasons I've stated.

[asmi]

Why don't you use quaternions to avoid gimbal lock? They're seems to be quite easy to use once you figure out what they actually are.

[Payload]

Why don't you use quaternions to avoid gimbal lock? They're seems to be quite easy to use once you figure out what they actually are.

I would love to. Why don't you give me an example of how you would do that in kerboscript. Keep in mind, loop time is about one cycle a second.

[KevinLaity]

Why don't you use quaternions to avoid gimbal lock? They're seems to be quite easy to use once you figure out what they actually are.

The system uses quaternions internally but I have to build those quaternions somehow. Putting in pitch, yaw and roll is the only reasonable way I could think of for a user to input that rotation.

Inputting the quaternion directly would require users to input a certain number of degrees around a vector... it might be easier for some but not for everybody. Maybe this can be an optional Q(x,y,z,w) thing.

For the people who are having a tough time with R() though, I think having a statement that works on a simple heading & pitch is what's needed, and Q() might just confuse them more.

[Sma]

This bit is all over my head, for now. I'm just happy I was able to do a gravity turn and get into orbit. Though now I guess I have to work on something else, that or trying to get my orbit more circular. Guess I should also try a few different rockets with the same launch program and see how they do.

As for new direction thing, maybe have one like N(0,0,0) or nav(0,0,0). Imagine someone was launching a rocket, the initial orientation on the launch pad (with north being down on the nav ball) would be

lock steering to up + N(0,0,0)

. It could also work for down, as well as forward and backward (for rovers). If you did something like

lock steering to up + N(0,45,0)

that would be for a 45 degree gravity turn (assuming the 45 is in the right place). Conversely if you did

lock steering to up + N(0,-45,0)

you would get a 45 degree turn to the west. Though I guess when you tried doing other angles it would get complicated. Like I said, this part is over my head for the moment LOL

On a different topic, would it be possible to have input into our programs, other than by action groups? I was talking to someone else here in this thread about asparagus staging, they posted an example program where they assigned the number of asparagus stages to a variable. I was thinking it might be a little more helpful in this case while running the launch program it could ask us "How many asparagus stages?" and we could input the number. This way we could have, in theory, one launch program for all asparagus staged rockets. Also along the same lines we could have another one asking what we want the final AP/PE to be. It wouldn't be 100% accurate due to delays in the program actually recognizing where the rocket is, though I guess the delays could depend on how many if statements there are, and if you have any print statements running as well.

Edited September 10, 2013 by Sma

[ahappydude]

More programing to ksp Thank you

edit

time to push the limits

[Dunbaratu]

I know man, If we had the actual velocity vector, we could easily orient the craft and pitch anti heading until surface speed was reduced..

The problem with this is that the term "actual" implies there is such a thing as THE one and only correct velocity vector. That's just not true. Physics needs to specify the frame of reference for coordinate systems. Right now I'm sitting still in a chair not moving as I type. But then again that's not really true because I'm not really sitting still because I'm on the Earth and it's rotating. But I'm not really just rotating on the surface of the Earth, I'm also orbiting the Sun along with the Earth. But I'm not just orbiting the sun because the sun is orbiting the center of the Milky Way, ... and so on and so forth.

There is no such thing as "the actual" velocity vector. What there is is different velocity vectors depending on where the center of your coordinate system is for reference. We don't need "the actual" velocity vector. We just need the ability to choose depending on context which one we want. Neither the orbital nor the surface velocity vectors can be rightly called "the" actual velocity. Which is correct depends on what we're using it for. I wouldn't want to use the orbital vector to land and I wouldn't want to use the surface vector to rendezvous with a target in space.

The only problem is that as of right now we don't have that choice. We only get to have the orbital one.

[Astral_Nomad]

Is it just me or does K-OS look very COBOL-ish in its english like statements and statement delimiter? now we just need some DIVISIONs for effect.. lol (I joke......... kinda)

[Dunbaratu]

Another reason for this is because during a launch the ship is going to naturally veer off. If you say "always steer in the direction you're already moving", then there will be no correction for that drift.

This is also a problem in orbit, but the problem is less pronounced because you're moving at orbital velocity and any drift will be negligible compared to that velocity.

EDIT: And yes I really should add that in.. I have a surface velocity scalar but no vector at the moment, I'll make sure it's in the next update

You should be aware that there is a slight difference between what your surfacespeed gives versus the thing I'm talking about.

To illustrate the difference. Say I'm falling at a 45 degree angle toward a spot on the ground, moving along with the planetary rotation. My navball tells me that my surface speed is 10 m/s. Your surfacespeed variable will only say the speed is about 7.07 m/s because it's only showing the speed of the ground projection of that vector ( 10*cos(45) ).

Now, if all I want is the scalar, I can take your surfacespeed and your verticalspeed and use them to derive the navbal's idea of what "surface" speed means by the Pythagorean formula.

Of course if you do implement a vector that corresponds to your surfacespeed scalar, from that plus the verticalspeed I could derive the navball's idea of what is the surface prograde direction with some trig... but if your goal was to make this accessible and easy for people to use it might not be a good idea to be using terminology that's at odds with what the navball says. The navball already has an idea of what a "surface speed" is and it's different from what your mod uses the term for.

Edited September 10, 2013 by Steven Mading

[Sma]

SMA,

You would get more accurate fuel values if you activate the asparagus stages first, check the fuel, then active the main engine - all before launch.

Assuming all asparagus stages are identical:

set acount to 3. // How many stages are asparagus.
set totalfuel to <liquidfuel>.
stage. wait 1. //all asparagus stages activated but not main engine.
set aspfuel to stage:liquidfuel. //total fuel in the 3 stages
set eachstagefuel to aspfuel /acount.

stage. //main engine start and clamp release
lock throttle to 1.
set x to acount.
set spentstages to 0.
until x = 0 {
   set currenttotal to <liquidfuel>
   if currenttotal < (totalfuel-(eachstagefuel *(spentstages+1)) { 
      stage. 
      set x to spentstages+1. 
      set spentstages to acount-x. 
   }.
}.

Obviously, you have to adjust to include launch code, like the gravity turn but it's a start!

I was having problems with this for a while last night. It kept freezing KSP and couldn't figure out why. I thought it was something I added, which there was line I think where i left off a period. I eventually found it was missing the end ) on the if statement. It's always the little things, I'm always forgetting to end statements here or there in my program .

I also changed it so that it worked if you were using non asparagus staging.

   if currenttotal < (totalfuel - (eachstagefuel * (spentstages + 1))) and spentstages < aspCount { 
      stage. print "Staged.                            " at (8,2).
      set spentstages to spentstages + 1.
   }.

I haven't checked it yet to see if it still works with asparagus staged rockets, but I don't see why it wouldn't. Although I have mine running in a while loop related to altitude, so I guess once it exited that loop, if all the boosters haven't dropped they'll stay attached. Though it should be simple enough to copy that if statement to my next altitude block, so long as I don't get to orbit with boosters still attached. I guess that would be ok, extra fuel lol. Which, might be cool if we could disable certain engines using the program, though I guess that would require parts to have individual ids, like engine 1, engine 2, engine 3 etc, which unless I'm wrong is something that would have to be in the game engine.

Oh, btw, my print statement prints to a "Status:" line in the console window if anyone was wondering.

[Payload]

When I say actual, I mean the one on the nav bal. What I want to know is if this is so simple that everyone seems to know how to do it, no one has offered one single example of working kerboscript. Just saying "why don't you do this" is not very informative. I understand the differences between orbital and surface. Just so happens KSP does too and even switches it automatically at some time that seems to be appropriate. If it wasn't, I would be on poor Jeb Clone #2533 or some crap. Just make it so I can communicate to the computer where I want to be on the nav ball and I'll be fine. I flew to the mun and back when all there was was a mun. All from the nav ball.

Edited September 10, 2013 by Payload

[Dunbaratu]

When I say actual, I mean the one on the nav bal. What I want to know is if this is so simple that everyone seems to know how to do it, no one has offered one single example of working kerboscript. Just saying "why don't you do this" is not very informative. I understand the differences between orbital and surface. Just so happens KSP does too and even switches it automatically at some time that seems to be appropriate. If it wasn't, I would be on poor Jeb Clone #2533 or some crap. Just make it so I can communicate to the computer where I want to be on the nav ball and I'll be fine. I flew to the mun and back when all there was was a mun. All from the nav ball.

The point is that I don't want to have the mod second guess which one I wanted, which is what the term "the" implies - that there's only one velocity vector. There isn't. There's 3 different ones the navball could give. I don't want the mod to give me "the" vector. I want it to provide all 3 of them and let me pick which one I'm trying to use.