kOS Scriptable Autopilot System 0.9

[Camacha]

I don't understand why it "breaks the intention of the mod". [...] . You can get Kerbin mass. [...]

I guess that should also not be in there. kOS has always been about simulating a computer in the KSP world. This is the reason for some of the choices that make life harder, but also more realistic. Think of things like the difference between saving locally and saving to archive. That was done with a very specific intention - and one I dig, I might add. Kevin even went as far as to implement a way of saving data to the drive in a way old computers used to do, but that turned out to be a bridge too far for most, as it did not allow for easy external editing. It does show the chosen path though.

If you want a prebuilt, ready and easy autopilot, I think MechJeb is your choice. It the real world nothing comes for free and kOS reflects that. You might consider that annoying, but hey, that is how the universe works

[adammada]

>If you want a prebuilt, ready and easy autopilot, I think MechJeb is your choice.

There is big difference between giving user active autopilot and giving basic informations.

[Camacha]

There is big difference between giving user active autopilot and giving basic informations.

I understand that there is some difference, but their is also a similarity in that MechJeb performs actions without user input, as kOS would provide these values magically without user input. They both provide a shortcut that makes life easier and not always in a realistic way. The same goes for the lock steering to command, by the way. If you want things solved for you, kOS is probably not the mod of choice.

Although I would not call these values basic, even though they are the basis for further calculations.

[adammada]

> as kOS would provide these values magically without user input.

No. "Magically" would be when user could ask for height of terrain basing on "lat,lng", because that is not something that is doable even in real world.

Storing 5 or 10 parameters of orbital body in computer ROM is no magic at all. Its just basics for rocket computer, like providing basic i/o functions.

[Camacha]

No. "Magically" would be when user could ask for height of terrain basing on "lat,lng", because that is not something that is doable even in real world.

Storing 5 or 10 parameters of orbital body in computer ROM is no magic at all. Its just basics for rocket computer, like providing basic i/o functions.

Yes. It simply is magic if you did not go out to discover these values. Is it not magic to know the weigth of water without someone measuring it? Is it not magic to know the local pressure if you did not measure it somehow? For the same reason it is magic to know a SOI you never measured.

Getting a height based on latitude and longitude is perfectly possible in the real world. After you created a height map by measuring all the variables. Without measuring, it is magic. With measuring, it is called science. We might disagree on what you want the user to do himself (measuring or not measuring), but we should not disagree on the facts. Getting unknown variables without measuring is getting them magically.

[Garek]

As far as I know, you can actually make reasonable assumptions about the gravity of the planet (remember, SOIs are a simplification of a multi-body system) without sending a probe, just from the interaction with other planets. Especially if your not concerned about local gravity (e.g. for landing), but on it's range of influence into interplanetary space (aka SOI). Also, I can get the SOI range from KSP without any additional tools because the maneuver planning shows a trajectory projection including SOI changes. Adjust a trajectory until it barely hits the target SOI and read the projected Apoapsis. This value is a reasonably good approximation, especially given that the only way to truly measure it with a probe would be to fly across the boundary and read the height at the moment of change...

Also, when talking about 'data files' we need to remember that kOS doesn't actually support file IO yet, so what we're using as database files are actually scripts setting variables, which is a waste of memory compared to actual data file formats. I would like to be able to store a certain part of a map whenever I get around to actually writing that super-awesome-landing-program (I'm waiting for RT2 integration, amongst other things), but because kOS supports neither arrays nor efficient data storage, it's impossible.

[adammada]

Getting a height based on latitude and longitude is perfectly possible in the real world.

No it isn't. KSP generates terrain height by function, so you can ask it to give you height with milimiter precision, and it will be correct. Even if this function uses interpolation, the same interpolation will be used for calculating when your ship will hit the ground.

You dont have height map of Earth or any other body with milimiter precision, so you cant give the same data in real world.

Insisting on hiding from kOS values which are avaiable in game for player in body informations is just annoying.

If you want, you can try to fly your rocket without any information (like ship position - it isn't realistic) , but its your choice.

[woodywood245]

I understand that there is some difference, but their is also a similarity in that MechJeb performs actions without user input, as kOS would provide these values magically without user input. They both provide a shortcut that makes life easier and not always in a realistic way. The same goes for the lock steering to command, by the way. If you want things solved for you, kOS is probably not the mod of choice.

Although I would not call these values basic, even though they are the basis for further calculations.

I tend to agree with you. Even "basic values" such as mass and radius of a body are things I don't look up in the wiki because I have techniques of acquiring them in game, and kOS gives me the opportunity to retrieve the variable values with much greater accuracy than other methods. All I need are a few numbers (one of them from a sensor, which is why I wrote Sensor Reporter), and I can calculate approximate body mass, radius, volume, and surface gravity. I can usually get values with less than 5% error for the large numbers. The way I look at the KSP solar system is what's the point of exploring if you already know everything? I like exploring the system and learning the physics and applying the math.

At heart, I'm an engineer and a scientist. I design meticulously based upon a set of requirements. Before I land on the Mun, I need to send an orbital probe to determine the surface gravity, which I can do from orbit with a little math. I take pictures of the surface and map out the different areas to determine a good location to set down. I can then create a set of requirements to build my spacecraft based upon what I learned the last time. That's one reason why I haven't gotten very far in exploring the solar system. I do it meticulously, and while I might be using "seat-of-your-pants technology," I'm not using seat-of-your-pants techniques.

As far as LOCK STEERING TO goes, that only points me in one direction, and that's pretty useless to me during takeoff. I use it during other maneuvers, but during takeoff, I use the derivative of a function to determine what direction I need to be pointed, and then use that information to calculate a vector that I apply to the east and north directions, with a separate vector determining how much to apply in each direction. I can shave off an awful lot of delta-v that way. The current rocket I'm working with can get into orbit with around 3100 m/s deltav.

However, one problem I constantly encounter is the "MechJeb wobble." I'm working on something for kOS that will hopefully eliminate that from my rockets, but you essentially have to build your own guidance system from scratch to even know what direction you're pointed.

[woodywood245]

Okay, I've got one: why am I unable to get the bearing or heading to a body target? Am I losing it, or is this another kOS quirk?

set target to mun.
print target:heading.
Suffix "target" not found on object.
print target:bearing.
Suffix "target" not found on object.

[Dunbaratu]

I do not think this would be a good thing. In general, it seems fair to only include things that could be queried in real life. If you want to have the SOI radius, there is no way a program could know, other than humans telling it that information. That is perfectly feasible right now, as you can make data files to access when needed.

Do you know how NASA deals with SOI radius? They don't because it DOESN"T EXIST. It's an artifact of how KSP's simulation works that does not have a counterpart in the real universe. In the real universe you CAN tell if you're on an escape path or not by performing the physics calculations that tell you the escape velocity. But that DOES NOT WORK IN KSP. The reason it doesn't work is that in KSP the laws of physics can be telling you you're captured when in fact you're not, because of SOI radius. If your apoapsis exists as a real sane positive number (meaning you are captured) but it is higher that SOI radius, then the laws of physics tell you you are not going to escape and fly past, but the SIMULATION says you will. You cannot make the realism argument when talking about SOI radius because it ONLY exists as an artifact of how KSP runs the simulation and therefore CANNOT BE CALCULATED IN ANY WAY other than by querying it from KSP itself.

It is NOT feasible right now because the data does not exist anywhere I can look it up. It ONLY exists in the API. Other things I've been able to get by copying down numbers from the KSP wiki pages about the various planets, but the SOI radius isn't one of them.

[Dunbaratu]

There is diffecence between making things too easy and making them just annoying. As you just laid out - player just needs to write script with values from KSP wiki.Its not an achievment to do such script. Its just plain annoying that it has to be done.

If we want realism there should not be "lock steering to..." function, because that makes everything too easy, and writing own good "autopilot" would be achievment.

The argument about what information would be realistically available is moot when talking about SOI. It's entirely an artifact of KSP's simulation. It doesn't HAVE an analogous counterpart in the real universe.

[Dunbaratu]

Okay, I've got one: why am I unable to get the bearing or heading to a body target? Am I losing it, or is this another kOS quirk?

set target to mun.
print target:heading.
Suffix "target" not found on object.
print target:bearing.
Suffix "target" not found on object.

The fact that ship targets and body targets have different data, and different names for the same data, is an annoyance. The algorithm for "how do I intercept a planet" and "how do I intercept a target ship for docking" really are the exact same mathematical problem, but because the variables for them have different names you have to make the code unnecessarily complex if you want it to be generically applicable to both.

Speaking as a programmer, in the object hierarchy it would make a lot more sense if planetary bodies and ships were both subclasses of the same parent class. Things like how you steer and thrust are unique to ships and belong in that class, but things like position, velocity, periapsis, apoapsis, and so on are applicable to any orbiting object of any kind and therefore make more sense to have up in a common parent class of both planets and spaceships.

Edited December 11, 2013 by Steven Mading

[woodywood245]

The fact that ship targets and body targets have different data, and different names for the same data, is an annoyance. The algorithm for "how do I intercept a planet" and "how do I intercept a target ship for docking" really are the exact same mathematical problem, but because the variables for them have different names you have to make the code unnecessarily complex if you want it to be generically applicable to both.

Speaking as a programmer, in the object hierarchy it would make a lot more sense if planetary bodies and ships were both subclasses of the same parent class. Things like how you steer and thrust are unique to ships and belong in that class, but things like position, velocity, periapsis, apoapsis, and so on are applicable to any orbiting object of any kind and therefore make more sense to have up in a common parent class of both planets and spaceships.

The thing that bothers me is that in the KSP API, there's a interface called ITargetable that represents objects that are targetable. The classes CelestialBody and Vessel both inherit from ITargetable, and as a result, they each have an OrbitDriver object, with which you can calculate headings, bearings, positions, phase angles, etc. Simply having a heading or bearing is enough to do the rest. So in the API itself, there's a common system for targetable objects, but kOS doesn't take advantage of that. I'm not sure why.

[Camacha]

At heart, I'm an engineer and a scientist. I design meticulously based upon a set of requirements. Before I land on the Mun, I need to send an orbital probe to determine the surface gravity, which I can do from orbit with a little math. I take pictures of the surface and map out the different areas to determine a good location to set down. I can then create a set of requirements to build my spacecraft based upon what I learned the last time. That's one reason why I haven't gotten very far in exploring the solar system.

I pretty much do the same thing. Expendable probes and mapping satellites go in to determine what I need and is going on. Then a proper rover gets built to verify all that and evaluate landing techniques. After that, a manned mission might be planned. On Kerbin I even started off with sounding rockets, just to get data on what I would encounter on going up.

To be honest, in my current game I have not gotten past the Mun yet and the past few weeks I have barely made it out of Kerbin atmosphere. I rather develop technology that is good, robust and solid than work out a couple of ideas that are okay enough to function but that is it. Space technology and engineering in general is not about doing it well enough, it is about doing the best you can.

I am considering writing some launch window planning software myself, but I will see. I am enjoying what I am doing at the moment already a lot too.

Do you know how NASA deals with SOI radius? They don't because it DOESN"T EXIST. [...] You cannot make the realism argument when talking about SOI radius because it ONLY exists as an artifact of how KSP runs the simulation and therefore CANNOT BE CALCULATED IN ANY WAY other than by querying it from KSP itself.

I know this is a pet peeve you have, but what you are saying is not fully true. Although you are right about the SOI being part of the simulation and not having a real counterpart, you are not right in saying you can not obtain it in any other way. Remember that you are in an alternative universe and you will have to deal with it. You can simply test where the SOI is by going there. Pure empirical evidence is good evidence and a good sauce for SOI.

You dont have height map of Earth or any other body with milimiter precision, so you cant give the same data in real world.

Yes, in reality you will have an error in your measurements, but that does not fundamentally change the facts. You could artificially add it, but Squad has always said they do not want to add things users have no control over and this would be one of those. Nevertheless, it is only an minor margin of error; the location in both cases is measured and not magically obtained.

Insisting on hiding from kOS values which are available in game for player in body informations is just annoying.

Let us be clear that you consider it annoying, which is substantially different from it factually being annoying. I do see that KSP provides these values in the map view but yes, those are magic numbers. No empirical evidence gathered to get it. It is just provided out of thin air.

[woodywood245]

I pretty much do the same thing. Expendable probes and mapping satellites go in to determine what I need and is going on. Then a proper rover gets built to verify all that and evaluate landing techniques. After that, a manned mission might be planned. On Kerbin I even started off with sounding rockets, just to get data on what I would encounter on going up.

To be honest, in my current game I have not gotten past the Mun yet and the past few weeks I have barely made it out of Kerbin atmosphere. I rather develop technology that is good, robust and solid than work out a couple of ideas that are okay enough to function but that is it. Space technology and engineering in general is not about doing it well enough, it is about doing the best you can.

I am considering writing some launch window planning software myself, but I will see. I am enjoying what I am doing at the moment already a lot too.

Exactly. I have two games running, one is my "real world" game, and the other is a "simulator" where I test and debug my kOS code. I also use the simulator game to test my mods so I don't accidentally mess something up.

I've been writing a large, generalized, modular flight control system that will work for all of my rockets over the last few weeks, so I haven't even touched my "real world" game in a while. But I'm learning a lot about the kOS system.

I want to write an interplanetary guidance system, but even though the equations are readily available on another thread, the lack of explanation for the variables doesn't help me understand what's going on.

[Dunbaratu]

I know this is a pet peeve you have, but what you are saying is not fully true. Although you are right about the SOI being part of the simulation and not having a real counterpart, you are not right in saying you can not obtain it in any other way. Remember that you are in an alternative universe and you will have to deal with it. You can simply test where the SOI is by going there. Pure empirical evidence is good evidence and a good sauce for SOI.

You are incorrect. Here is why. In the real world you can find out all you need to discover the relevant numbers for escape calculations using remotely obtainable data. You can work out the mass of a planet by observing its motion and the motion of other bodies to derive what the mass has to be to give the gravity effects its giving. You don't actually have to go there to find it out. You can work out the position of a planet with telescopes. If you didn't have that data ahead of time prior to launch you couldn't even design a probe to get THERE in the first place. The SOI data is in the exact same class of information as that. It's part of what you'd know before you got there and it's part of what you have to know TO get there successfully. You cannot work out the SOI any other way other than either:

1 - sensibly accepting that as an artificial artifact of the simulation, it's acceptable to obtain it directly from the simulation.

2 - pretending that it's reasonable to throw probes away on finding what it is, and accepting that you have to do so again and again and again once for each world because it's not based on a consistent formula either that remains the same per body. It's based on SQUAD making an arbitrary decision depending on what seems to work for each body.

It sounds like the mod you'd like to have is one that's even LESS helpful to the user than the base game is. IN which case, you should be complaining about being able to lock steering to a heading instead of having to write code to individually control each engine's thrust vectoring.

Edited December 12, 2013 by Steven Mading

[Camacha]

1 - sensibly accepting that as an artificial artifact of the simulation, it's acceptable to obtain it directly from the simulation.

The one does not follow from the other. If I remember correctly, you did not like the idea of kOS timewarping the vessle, as it broke the fourth wall. That is something that purely stems from the simulation and is also artificial. Yet your position is a complete opposite. I do not understand that, as the SOI is something you can actually emperically establish. It does not matter how the value is established, as long as you can go and get it somehow.

2 - pretending that it's reasonable to throw probes away on finding what it is, and accepting that you have to do so again and again and again once for each world because it's not based on a consistent formula either that remains the same per body. It's based on SQUAD making an arbitrary decision depending on what seems to work for each body.

Exactly, and that is why you need a probe instead of calculating it. One probe is not that much to ask to do vital reconnaissance work, I would think. Even in our very real universe there are a lot of things we need to observe and measure. No need sending billion dollar craft to Mars if we could give Matlab a whirl and knew everything

IN which case, you should be complaining about being able to lock steering to a heading instead of having to write code to individually control each engine's thrust vectoring.

I probably did not express myself explicit enough before, but I am. Lock steering is a semi magic command. Unfortunately, we do not have anything better, although with some trickery some fun stuff can be done.

[Dunbaratu]

The one does not follow from the other. If I remember correctly, you did not like the idea of kOS timewarping the vessle, as it broke the fourth wall.

The difference you are pretending doesn't exist between the two situations is that timewarping is not needed within the universe of the simulation to make the script work. knowing the SOI is. SOI exists in the universe of the game, timewarping exists in the universe of the player. In other words if you removed timewarp from the game, nothing would change about how the mission works, but it would just be impractical for the player to sit and watch it. Contrast this with removing SOI from the game. If you remove that it would alter the actual behavior of the game universe.

And you ignored the strongest point I made, which is that in our real universe you can calculate things like mass and even planet radius and all sorts of other values PRIOR to the launch. You don't have to GO to Jupiter to get a good estimate of its mass. You can know that ahead of time, and in fact you HAVE to to calculate things like that correctly ahead of time for something like a Voyager probe to be a doable mission. SOI belongs in that same category of data.

[Camacha]

And you ignored the strongest point I made, which is that in our real universe you can calculate things like mass and even planet radius and all sorts of other values PRIOR to the launch. You don't have to GO to Jupiter to get a good estimate of its mass. You can know that ahead of time, and in fact you HAVE to to calculate things like that correctly ahead of time for something like a Voyager probe to be a doable mission. SOI belongs in that same category of data.

So you are saying SOI belongs to the same category as things like radius, mass et cetera? The things Squad made up as they liked them, without much possibility of detecting them at a distance, but actually quite measurable when you go there? Missions that are actually doable in KSP?

[Sma]

Just been getting interested in picking up kOS and checking it out, I have one question about how it plays with remote tech currently before I get too involved. Does the signal have any effect on this at the current moment or is it something you more or less have to pretend.

I didn't read all the other pages, but I use kOS and Remote Tech 2 as well as other mods, together and it works....fine. Sometimes when typing in kOS certain things aren't captured only by kOS. For example, if you type a number any action groups you have assigned will fire, as does the space bar. ALthough I haven't noticed the problem lately.

As far as signal goes, I haven't tried connecting to the archive once im out far enough. I'm pretty certain once you pass the limit coded for KSC it'll lose signal. Also currently when you go out of comms (or is it komms) range your kOS program won't run any more. Eventually there may be a fix so your program still runs when the vessel is out of range but not at the moment.

[Dunbaratu]

So you are saying SOI belongs to the same category as things like radius, mass et cetera?

Yes. The data that you can't get in game, like the body radius.

The things Squad made up as they liked them, without much possibility of detecting them at a distance, but actually quite measurable when you go there?

Your claim that radius is detectable in the game is false. Besides, if you weren't just being argumentative for the heck of it and actually believed what you're saying you'd be complaining far more about the fact that we can get magic data like position vectors, rather than having to triangulate it out from angles like they did on Apollo. SOI is far less "magic" than getting your position and velocity handed to you. Either that's acceptable to you or it's not. If it's not, then there's a lot more about the kOS mod you should be complaining about than SOI. Getting SOI from kOS is absolutely in line with the design since the design also lets you get other data about the body, like its mass, without having to derive it.

You are being inconsistent when you complain more about my proposal to have SOI body data available than you do about those other things.

[Camacha]

Your claim that radius is detectable in the game is false.

This is evidently not true, as it has an influence and thus can be detected. The first can not go without the second. Maybe not in the way you would like, but that is another matter.

Anyway, I think it is time to agree that we do not see eye to eye on this one. We gummed up the thread enough, I would say.

Besides, if you weren't just being argumentative for the heck of it and actually believed what you're saying you'd be complaining far more about the fact that we can get magic data like position vectors, rather than having to triangulate it out from angles like they did on Apollo. SOI is far less "magic" than getting your position and velocity handed to you. Either that's acceptable to you or it's not.

I think you underestimate a bit what I try to do in what way. It is, in any case, a matter of finding a balance between what kOS and KSP magically give you and what can be done in real life but not in KSP. Things like spectroscopy and monitoring variations in the position of planets are simply not feasible in KSP, as the simulation is not advanced enough to take care of those things. However, I am not taking KSP and kOS variables for granted. If the magic numbers I get do not comply with reason, chances are I will not use them, or try to eliminate them later by developing more sophisticated methods. I tend to develop multiple methods to get somewhere anyway, so the more suitable ones will eventually show themselves.

You are being inconsistent when you complain more about my proposal to have SOI body data available than you do about those other things.

I think nobody wants to hear me whine about every little detail, not even me. Better just pick a poster item and show what is wrong with that, so that the relevant people can run with it.

Edited December 13, 2013 by Camacha

[Amazingteknique]

I didn't read all the other pages, but I use kOS and Remote Tech 2 as well as other mods, together and it works....fine. Sometimes when typing in kOS certain things aren't captured only by kOS. For example, if you type a number any action groups you have assigned will fire, as does the space bar. ALthough I haven't noticed the problem lately.

As far as signal goes, I haven't tried connecting to the archive once im out far enough. I'm pretty certain once you pass the limit coded for KSC it'll lose signal. Also currently when you go out of comms (or is it komms) range your kOS program won't run any more. Eventually there may be a fix so your program still runs when the vessel is out of range but not at the moment.

Thank you, this was more or less what I was wondering. Guess I'll be waiting patiently until some sort of integration is worked out.

[Dunbaratu]

Anyway, I think it is time to agree that we do not see eye to eye on this one. We gummed up the thread enough, I would say.

That's the only thing you've said about this which sounds even remotely rational to me, so yes, let's let it drop.

[adammada]

That's the only thing you've said about this which sounds even remotely rational to me, so yes, let's let it drop.

There is pretty simple solution for players which do not allow:

SET body_soi TO ship:parent:soi.

but would allow

SET body_soi TO 23784927983472. (got from wiki).

And that solotion is:

- do not use ship:parent:soi if you don't like it.

Also, woodywood245 - if you would create mod similar to kOS i would advise not to design it to be that hard/annoying. You could make few levels of it, like:

1. Normal (you can get those basic body data).

2. Annoying (you cant get basic body data like mass etc)

3. Nightmare (you can't get body data, you cant get position, all you can do is triangulate and even that not too fast).

4. Sadistic ( Nightmare + lack of more advanced math functions).