kOS Scriptable Autopilot System 0.9

[John FX]

set PI to 3.1415926.

print round(PI,3). // output= 3.142

print round(PI,0). // output= 3

print round(PI,5). // output=3.14159

Ah, I have tried sig(pi,3) and some other things but didn`t think to try round

Thank you muchly.

[Camacha]

Coming back and seeing the code again with fresh eyes; That code was never correct in the first place. It's not that it broke ("I`ve noticed a change") but that you couldn't see what was was wrong with it before.

I had a beautiful example of that when working on a low altitude ascent/descent burn script. It worked pretty decently in my initial testing, but with higher or lower values it seemed to underperform. I had done quite a bit of statistical work before I found out one of the used formulae was simply the wrong one. It just returned somewhat correct values for my usual testing range, and the situation was only made worse by the other two equations being right, reducing the error in the final number.

After rebuilding the code with the correct formula and eliminating some noise, everything was spot on.

Edited December 20, 2013 by Camacha

[MaHuJa]

However, this problem got me thinking ... which is dangerous.

I'm so quoting you on that. At least for a while.

--

For rounding, you have round() as dio said, floor() which always rounds down (to nearest whole), and I don't remember if kOS provides a ceiling() or ceil() function that always rounds up (again to the nearest whole).

[AeroEngy]

So 90 or -90 degrees from up in the plane of surface travel?

Also, I have searched the WIKI and looked on the list of all commands n stuff but cannot find how. Could someone let me know how to print 3.1415926 as 3.142 or 3 or 3.14156

Yes. I don't know enough about kOS to get the appropriate angle and KSP is broken for me now I can't test anything. However it would be UP rotated +/- 90 in the crafts orbital plane. I think this should also be the same as the + or - surface velocity vector which is probably easier to get ... but I can't test anything now . The fact that you should always thrust 90 degrees from R makes a lot of sense when you consider an elliptical orbit instead of a hyperbolic one. In an elliptical orbit at apo/periapsis +/-90 from R in the orbital plane is the same as prograde/retrograde which is more easily understood as the optimal direction.

Having KSP broken since the update is killing me. I work on the Anatares rocket and the cooling loop issue on the ISS has our launch delayed. I find myself with some extra free time. I can't get my real rocket fix and I need a virtual one.

Edited December 20, 2013 by AeroEngy

[diomedea]

I'm so quoting you on that. At least for a while.

--

For rounding, you have round() as dio said, floor() which always rounds down (to nearest whole), and I don't remember if kOS provides a ceiling() or ceil() function that always rounds up (again to the nearest whole).

ceiling().

I always keep this available (but if I may suggest, those contents should all go with the Wiki).

[AeroEngy]

So we've been waiting on Kevin so as not to steal his project away from him while he's sorting other things out, but it looks as if the 0.23 KSP update may be the thing that forces the issue, since kOS 0.92 doesn't work iwth 0.23 KSP. (It's not just a matter of it not compiling the source code, even the precompiled version on Spaceport doesn't work anymore - I'm playing through a new career and the SCS part doesn't show up in the tech tree in 0.23.

MahuJa 's work to make it go in 0.23 is nice but the time may have come to make an official fork and start up a new github page. I would have otherwise preferred to give Kevin more time but the fact that 0.23 requires a recompile sort of makes that nicety impossible.

I agree for what it is worth. I would offer any help but I am by no means a software engineer.

[John FX]

ceiling().

I always keep this available (but if I may suggest, those contents should all go with the Wiki).

Very handy. I now have another bookmark. Tyvm.

Having just watched the features video for 0.9 I now know about nextnode:periapsis which will be a new direction for my brute force autopilot.

make a node, adjust a node, see if it is better or worse and use that information to govern the next node change

loop until the node is perfect and then burn it.

Anyone know how to read (like nextnode:periapsis) the inclination of the munar exit after making a node to burn to the mun? (It would be the inclination of the orbit after leaving munar SOI) A lot of my nodes end up almost polar after munar interaction and I`d like to check for that happening if the data is there.

Edited December 20, 2013 by John FX

[Sma]

It's not just a matter of it not compiling the source code, even the precompiled version on Spaceport doesn't work anymore - I'm playing through a new career and the SCS part doesn't show up in the tech tree in 0.23.

I'm pretty sure on mine it's in the tech tree. Think I unlocked it last night, or it may be one that I need to unlock next. I'll check next time I get on KSP.

[erendrake]

I have not release any KSP Plugins but I am a C# developer by trade so i would be happy to take on maintaining the mod until Kevin comes back or the group looses interest.

Ill put it up on spaceport but just to be sure my build process is working i have a dropbox link for anyone to try and let me know if something is busted

0.23 Hotfix build

[Camacha]

I have not release any KSP Plugins but I am a C# developer by trade so i would be happy to take on maintaining the mod until Kevin comes back or the group looses interest.

I think there are more interested parties when it comes to taking over or reworking the mod, although I see no harm in what you are doing and personally I welcome it. I feel it would be prudent to contact Kevin again to see what he thinks about his role in the process, now and in the future. That should make it clear whether Kevin wants to pick development up again, what the timespan for that would be or that someone else is free* to pursue fresh development.

I will try to contact him with this question and report back.

*License wise there are no obstacles to forking or independent development, but it only polite to involve the original author. It would also benefit the community if there is some kind of centralized development instead of a couple of concurrent forks all doing the same in slightly different ways.

[erendrake]

I think there are more interested parties when it comes to taking over or reworking the mod, although I see no harm in what you are doing and personally I welcome it. I feel it would be prudent to contact Kevin again to see what he thinks about his role in the process, now and in the future. That should make it clear whether Kevin wants to pick development up again, what the timespan for that would be or that someone else is free* to pursue fresh development.

I will try to contact him with this question and report back.

*License wise there are no obstacles to forking or independent development, but it only polite to involve the original author. It would also benefit the community if there is some kind of centralized development instead of a couple of concurrent forks all doing the same in slightly different ways.

Im sure there are other people who would be interested in adding features and helping improve the project, I am happy to help out any way the group needs me to. I am stepping up simply because no one else has yet and we have an addon that is effectively dead for 0.23.

If you hear from Kevin please let is know.

[diomedea]

Given the presence on this thread of many who may be able to further develop kOS, I have a question for them:

would it be possible, at least in theory, to develop a sort of "compiler" running in kOS, so to achieve very fast execution of the kOS code?

Many thanks for any answer.

[Rosco P. Coltrane]

I don't think so, no, kOS is an interpreter, not a compiler. It processes code "as it goes" so to speak. A compiler is a completely different beast.

In other words, its kind of a proxy between your code, and the "real executable code". If it sees something like "set x to 4." it goes and creates an internal variable named x with value 4. It doesn't even generate any kind of compiled code as a JIT compiler would do (they compile and run the code as they go).

EDIT: Ok, I reckon I suck at explaining this, but it's not easy to explain!

[diomedea]

@ Rosco: well, I know what an interpreter is, thanks for trying to explain. And I know what a compiler is, too. Therefore, no doubt kOS is an interpreter for the kerboscript language. I probably wasn't clear enough. Starting from kOS, so possibly keeping the same parts and interface, would it be possible to build a compiler for kerboscript? Of course, then the compiled code would be used at runtime instead of the script, therefore such a compiler must code in a way that the code can be used by a runtime engine working within KSP (UnityEngine ?).

[Sma]

@ Rosco: well, I know what an interpreter is, thanks for trying to explain. And I know what a compiler is, too. Therefore, no doubt kOS is an interpreter for the kerboscript language. I probably wasn't clear enough. Starting from kOS, so possibly keeping the same parts and interface, would it be possible to build a compiler for kerboscript? Of course, then the compiled code would be used at runtime instead of the script, therefore such a compiler must code in a way that the code can be used by a runtime engine working within KSP (UnityEngine ?).

I'm not an expert, but at that point you might as well just write a new KSP plugin. I imagine anything is possible though, with the right amount of effort and time put into it.

[diomedea]

I'm not an expert, but at that point you might as well just write a new KSP plugin. I imagine anything is possible though, with the right amount of effort and time put into it.

That would be a solution for people who know how to build plugins. But kerboscript is not confined to be used only by those who already are fluent in C#.

[Camacha]

I think that is much more the approach of ProgCom, which is basically an emulated CPU running assembly with some C-compilers added to the mix. The problem with that was the erratic and decentralized development, combined with a lack of direction and high level of complexity. Fun for some people that really want to dive into it, but not really viable as a kOS replacement. It could pose as a bit of inspiration for a leaner and meaner version of kOS though, as long as you recognize the reasons kOS did catch on.

Edited December 20, 2013 by Camacha

[diomedea]

@ Camacha: yes, I heard of Progcom and totally concur with what you said.

My idea is different mainly because the user will still use kerboscript, and I believe this language is, even as it is now, much friendlier than any low level language like ASM or even simulated machine opcode. Somebody may like using opcodes, but I believe most users would find kerboscript much easier.

Sure, Progcom is proof that a similar approach may work.

[Dunbaratu]

@ Camacha: yes, I heard of Progcom and totally concur with what you said.

My idea is different mainly because the user will still use kerboscript, and I believe this language is, even as it is now, much friendlier than any low level language like ASM or even simulated machine opcode. Somebody may like using opcodes, but I believe most users would find kerboscript much easier.

Sure, Progcom is proof that a similar approach may work.

I suspect the intent of Progcom was that if you emulate the low level machine you should be able to run compiled code on it. The idea being that you could write in a higher level language and cross-compile it targeting the progcom CPU. But it never really got that far.

[Dunbaratu]

I don't think so, no, kOS is an interpreter, not a compiler. It processes code "as it goes" so to speak. A compiler is a completely different beast.

In other words, its kind of a proxy between your code, and the "real executable code". If it sees something like "set x to 4." it goes and creates an internal variable named x with value 4. It doesn't even generate any kind of compiled code as a JIT compiler would do (they compile and run the code as they go).

EDIT: Ok, I reckon I suck at explaining this, but it's not easy to explain!

For people more familiar with C# than I am, can you confirm what I'm saying here? I think in kOS that when you use a lock expression, the system stores the parsed expression data structure for re-execution later rather than re-parsing the actual raw ascii text of the expression each time.

If that's true then there sort of is a bit of precedent for this. Maybe that system could be expanded to the entire program.

[Dunbaratu]

I'm pretty sure on mine it's in the tech tree. Think I unlocked it last night, or it may be one that I need to unlock next. I'll check next time I get on KSP.

After reading your post I tried wiping kOS and re-installing it. Now the SCS part is there and it works. It seems that if you do it in this order:

Step 1. Have kOS already installed.

Step 2. Upgrade KSP from 0.22 to 0.23

Then the kOS part won't appear.

But if you do it in this order:

Step 1. Upgrade KSP from 0.22 to 0.23

Step 2. Install kOS after that.

Then it works.

EDIT: No it doesn't. I spoke too soon. I just tried it and it won't let me click on the terminal window to focus keyboard input onto it. When I try I get this in KSP's debug log:

"[Exception]: MissingMethodException: Method not found: 'EditorLogic.Lock'."

Edited December 20, 2013 by Steven Mading

[togfox]

I've been watching this thread since the start and I'm not sure what you guys use his for. I get that it can progamatically change a craft direction and thrust and all that but what are the pracrical applications you've found for this?

[diomedea]

@ togfox: here some applications of kOS. But those are just to give an idea. Imagine that any sequence of commands, whatever complex, you will be giving to a craft, you run a program in kOS instead.

[Sma]

After reading your post I tried wiping kOS and re-installing it. Now the SCS part is there and it works. It seems that if you do it in this order:

Step 1. Have kOS already installed.

Step 2. Upgrade KSP from 0.22 to 0.23

Then the kOS part won't appear.

But if you do it in this order:

Step 1. Upgrade KSP from 0.22 to 0.23

Step 2. Install kOS after that.

Then it works.

EDIT: No it doesn't. I spoke too soon. I just tried it and it won't let me click on the terminal window to focus keyboard input onto it. When I try I get this in KSP's debug log:

"[Exception]: MissingMethodException: Method not found: 'EditorLogic.Lock'."

Ahh ok. Yeh now that I think about it I likely deleted it when checking plugins to get RT2 to work without "crashing/launching" automatically on launchpad load. This was before I had gotten to the point of unlocking the SCS unit. By the time I unlocked it I had reinstalled kOS. As I think I mentioned in my previous post, I hadn't gotten around yet to testing it, but I'll do that. I suspect though that I'll get the same error.

I've been watching this thread since the start and I'm not sure what you guys use his for. I get that it can progamatically change a craft direction and thrust and all that but what are the pracrical applications you've found for this?

So far I've used it to launch craft into a nearly exact orbit. Planning on using it for automatic deployment of a kommsat network, where in the rocket carries up 3 (for "kerbosync") and 4 (for lower, Likely around 300km) komm sats. So far I've gotten for the kerbosync one I've gotten it to get to 2,686km, then automatically adjust its Pe to put the parent vessel into a 4hr orbital period. I think I have it set now to deploy (each sat will have its own deploy action group) a komm sat every time the vehicle gets comes around to the Ap. Though I'll have to switch to that sat and run the program that raises the Pe to kerbosync altitude manually, and wait until it's done before switching back to the parent craft again. I don't think kOS currently has the ability for the parent vessel to run a program on a "child" vessel, unless it's just a matter of setting everything up just right.

Edited December 21, 2013 by Sma

[Camacha]

I've been watching this thread since the start and I'm not sure what you guys use his for. I get that it can progamatically change a craft direction and thrust and all that but what are the pracrical applications you've found for this?

Just to name a few: data logging, getting readouts of very specific variables, autohovering, auto-ascent, auto-descent, sky crane operations, station keeping, attitude and altitude control in aircraft, homing vehicles, all sorts of robotics and much more.

The point for me is that it can reliably and efficiently do operations that are hard to do consistently by hand. Pretty much why NASA does them by computer too. The price you pay is first figuring out exactly what goes into doing those things and then coding an efficient way to do it consistently right. When you get everything right it is really easy, but to get there you usually have to get a firm grasp on the subject through a lot of coding, cursing and crashing

Personally I like to develop a couple of competing solutions to test and understand what is the best and most efficient one. For me a large part of the fun is that you can get very theoretical with your math and physics, yet are able to apply it practically and see the results right away.