kOS Scriptable Autopilot System 0.9

[drtedastro]

Is there currently any method to store larger amounts of data on the craft? For instance, if on a exploration mission and I want to log certain data, is there something like a 'tape drive' or 'disk unit' that can be logged to??? I see LOTS of way to use this and i hope that i have just missed it, or it might soon be out...

At certain times, scheduled data drops could be made to make best use of what we have.

thanks, and this is great fun.

[Camacha]

Are you sure the 6.5 change regarding the altitude is the right way to go? The sudden flip from game sea level altitude to real altitude might cause some strange problems if you do not have any way to distinguish. As already mentioned, submarines get a little hard to do too - even though that is a minority of the KSP users.

Somehow I would like to retain the capability of knowing where the reading is coming from. As mentioned before, I kind of dislike the idea of kOS doing too much thinking for us. It should be accessible, but not at the cost of being easy; that is what MechJeb is for.

[check]

Are you sure the 6.5 change regarding the altitude is the right way to go? The sudden flip from game sea level altitude to real altitude might cause some strange problems if you do not have any way to distinguish. As already mentioned, submarines get a little hard to do too - even though that is a minority of the KSP users.

Somehow I would like to retain the capability of knowing where the reading is coming from. As mentioned before, I kind of dislike the idea of kOS doing too much thinking for us. It should be accessible, but not at the cost of being easy; that is what MechJeb is for.

I'm with you on this. Having a way to distinguish from flying over water vs flying over land can be useful in many situations.

Example: auto-searching for safe landing site that's over land or mapping the terrain and being able to map the water separately from the land.

[Astral_Nomad]

for anyone that cares.. I have written out a simple c function that will determine the result of a modulo operation on a value. might not be the most efficient, but hey, it works without error. Feel free to use it in whatever mods anyone might need it in. I dont know c# or i would have written it as that.

int mod(double m_decimal, double m_mod) {

return m_decimal - (((int)(m_decimal/m_mod)) * m_mod);

}

[JewelShisen]

Already tested with my cruise missile and no errors occurred!

[Astral_Nomad]

two things i would really like to see in the future -

- The 10K barrier increased to something a bit more reasonable, or if that cant be achieved,

- A procedural/modular set up, where we can jump to subroutines and functions or even launch an entirely different script from within the current script to get around said barrier.

I would have no issues with breaking down a large script into smaller ones (for example, on a stage by stage basis) if it meant being able to still execute them all, as a complete session.

I would also like to propose that the default extension for kOS, be .kos. This would make things easier as I would like to be able to associate my kOS files to my editor but apart from standard text files.

Edited September 30, 2013 by Astral_Nomad

[Astral_Nomad]

my mod function? or was that a response to something previous? lol

[JewelShisen]

my mod function? or was that a response to something previous? lol

The post about the change in alt:radar causing possible errors

[Camacha]

The post about the change in alt:radar causing possible errors

Believe it or not, but there is more to life than cruise missiles

Edited September 30, 2013 by Camacha

[Bizz Keryear]

[...]

- The 10K barrier increased to something a bit more reasonable, or if that cant be achieved,

Is there currently any method to store larger amounts of data on the craft?

To both I can only say: Add more computers to you Vessel. You will get more disc space. It might be including a switch to <drive_name_or_number> command at the executing computer. So it means: Yes one computer can execute the files on another one (as long as they are on the "same" vessel... docked ships also count as same vessel)

A how to make all probe cores into k-OS computers can be found here.

At certain times, scheduled data drops could be made to make best use of what we have.

Dunno what that is supposed to mean, but how about to bring a probe back home then?

- A procedural/modular set up, where we can jump to subroutines and functions or even launch an entirely different script from within the current script to get around said barrier.

Read the wiki! You can use DECLARE PARAMETER <variable>[,<variable>[,...]] within a program then you can call that program with program(<variable>[,<variable>[,...]])

[...]

(Sorry for the empty quote I used it only to link the conversation ...)

NO what I really meant, if you doing it inside of the game, you depend on the game that mean all those long loading times, also if you test run your script it will affect the vessel attached to it, which usually end in lots of explosions if the script fails caused by typos. I mean the real test if the ship behaves like you thought it will is another story, but if the script just simply stops cause you have forget a dot, a bracket or a quote-mark ... unneeded loading times I am not a ten finger writer and not typing blind, but I use both hands and not searching keys. Sometimes ... well its a not so rare case.... one finger is too fast and I end up with owrds (e.g.). Having those and the previous mentioned ones is really a pain in the (lower) south end if you facing north.

[JewelShisen]

Believe it or not, but there is more to life than cruise missiles

Oh I know that. But if a craft can fly, safely by the way, from KSC to the Island Airport using the new alt:radar function while hugging the ground at just 500m then it is safe to say that it won't have an issue.

[Camacha]

Oh I know that. But if a craft can fly, safely by the way, from KSC to the Island Airport using the new alt:radar function while hugging the ground at just 500m then it is safe to say that it won't have an issue.

That only makes it safe to say the new altitude readout method will not have an issue in that case, or similar cases As someone that is technically inclined I have a dislike of functions where the output is unpredictable (to a certain degree) as a base for technical solutions.

[JewelShisen]

That only makes it safe to say the new altitude readout method will not have an issue in that case, or similar cases As someone that is technically inclined I have a dislike of functions where the output is unpredictable (to a certain degree) as a base for technical solutions.

And I can understand that. My only observation is the fact that at 500m even a computer doesn't get much time to react if something were to go wrong. So at the moment it appears as though the new way of it working won't cause any issues. However as you pointed out my test only confirms that it will work in that case and similar ones. I will admit I would like to get the depth below the surface as well for running subs.

Also I have not seen any unpredictability in the alt:radar function. Could you explain what you mean by that?

[Kerbart]

Is there a thread for bug reporting? Right now kOS works for me but it's not able to get stable control of my craft. I'm using a smallish rocket (similar to the one used on the demo video) and instead of going straight up it seems to be going around in circles at 10° from the up vector (with steering set to lock steering to up.)

[JewelShisen]

Is there a thread for bug reporting? Right now kOS works for me but it's not able to get stable control of my craft. I'm using a smallish rocket (similar to the one used on the demo video) and instead of going straight up it seems to be going around in circles at 10° from the up vector (with steering set to lock steering to up.)

Try adding SAS to it. It seems right now to have a hard time using nothing but fins right now.

[Sma]

Oh I know that. But if a craft can fly, safely by the way, from KSC to the Island Airport using the new alt:radar function while hugging the ground at just 500m then it is safe to say that it won't have an issue.

I think part of the problem with alt:radar now switching to altitude while over water is that say you're auto landing(someone i think already mentioned this), but happen to be over water. As far as the script knows you're over land, as such it tries to land. Problem with water is it has a nasty habit of exploding and breaking things. Maybe there is a threshold where descending at a specific rate doesn't cause this though. Not sure why it was a problem before for people to automatically put in their code "if alt:radar < 0" or "if alt:radar < 3000" or whatever the altitude was at which it started causing problems. Maybe I'm missing something.

Try adding SAS to it. It seems right now to have a hard time using nothing but fins right now.

Agreed, I always put SAS/ASAS on my rockets as sometimes the built in sas on command pods just isn't enough.

Edited September 30, 2013 by Sma

[JewelShisen]

Ok going on your landing example, the radar altitude is not the issue there. It is the fact that kOS doesn't know it is over water.

Also it wasn't a 'problem' so much as a convenient thing. Now if your flight code is rather complex and depending on alt:radar you can save several lines. Take my missile code for example. It handles pitch by taking the desired cruising altitude above the ground and figuring out the error between it's current radar altitude and that. It then multiplies that by 90 to get the pitch setting. It does this with the following formula:

lock pitch to ( ( targalt - alt:radar ) / targalt ) * 90

Now without the new alt:radar i would have to add at least five more lines of code to that. And I am using a VERY simple pitch control code.

Edited September 30, 2013 by JewelShisen

[Camacha]

Also I have not seen any unpredictability in the alt:radar function. Could you explain what you mean by that?

In cases where the radar altimeter would return -1, the normal (atmosperical) altimeter is used. The discrepancy between those two (over a mountain for example) will cause the alt:radar to instantly switch from one altitude to another. This will probably disrupt any descent/ascent profile that uses this value as guidance.

Also, as mentioned before, detecting whether you are over land or water - or under water for that matter, is a useful thing for autolander scripts or other stuff. I also have a feeling this behaviour is much more like the real thing, which I like.

[JewelShisen]

In cases where the radar altimeter would return -1, the normal (atmosperical) altimeter is used. The discrepancy between those two (over a mountain for example) will cause the alt:radar to instantly switch from one altitude to another. This will probably disrupt any descent/ascent profile that uses this value as guidance.

Also, as mentioned before, detecting whether you are over land or water - or under water for that matter, is a useful thing for autolander scripts or other stuff. I also have a feeling this behaviour is much more like the real thing, which I like.

I've never had alt:radar give me issues over mountains. O.o Only over oceans and above 10000m before.

Also I would LOVE the ability to detect if you are over water. Would make landing sea bases so much safer!

[Camacha]

I've never had alt:radar give me issues over mountains. O.o Only over oceans and above 10000m before.

I believe we are miscommunicating a little bit. I did not mean to say that the new altitude readings will cause problems over mountains, but that they might cause problems when it switches from atmospheric readings (like when over a certain altitude or over water) to radar altitude. When you are - for example - over a moutain these two are quite different and that might cause problems.

Check the devblog videos for an explanation what the difference between the old and the new system is.

Also I would LOVE the ability to detect if you are over water. Would make landing sea bases so much safer!

The old readings provided a way to do this

[drtedastro]

Dunno what that is supposed to mean, but how about to bring a probe back home then?

If i have a probe doing a one way mission, and i want to send logged data, stats, etc home, this is what i was talking about. I have no intention to bring the entire probe 'home'. That is why it is a probe... I just want to gather data, bundle it up, and blast it back via communications link... Not a sample return, just a probe gathering data....

[check]

My two latest inventions: A countdown clock and an instrument landing system. All stock built, but controlled by kOS.

[cfds]

kOS seems to have some really weird problems with LOCK ... TO. The following code is a first step to an autolauncher with thrust adaption against drag losses.

set lsPitch to 90.
lock steering to heading 90 by lsPitch.
lock throttle to 1.
stage .


lock lsVel to velocity:surface .
//lock lsSpeedSq to ( lsVel:x*lsVel:x + lsVel:y*lsVel:y + lsVel:z*lsVel:z ) .
//lock lsSpeedSq to ( verticalspeed*verticalspeed + surfacespeed*surfacespeed ) .
lock lsSpeedSq to verticalspeed .
print lsSpeedSq .
lock lsAngle to verticalspeed / (lsSpeedSq^0.5) .

//local gravity, will be more dynamic later
lock lsGrav to 9.81 .

set lsDragConst to (204.4 / 0.2 ) .

lock lsPress to 2.71828 ^ (altitude / 5000) .
lock lsTermSpeedSq to lsDragConst *lsGrav * lsPress .
lock lsTermThrottle to 2 * lsGrav * mass / maxthrust.

print lsSpeedSq .

when altitude > 9500 then lock lsPitch to 83 - (0.5 * ((altitude - 9500)^0.5)).
when altitude > 25000 then lock lsPitch to 20.


when (verticalspeed*verticalspeed + surfacespeed*surfacespeed) > lsTermSpeedSq then {
lock throttle to lsTermThrottle.
print "Too fast!" .
}.

when altitude > 1000 then { print altitude. print lsSpeedSq. print verticalspeed*verticalspeed + surfacespeed*surfacespeed. print lsTermSpeedSq.}.

print lsSpeedSq .

wait until altitude > 50000.

toggle sas.

The problem is that the lock on lsSpeedSq, based on verticalspeed (or velocity:surface), stops working as soon as the WAIT UNTIL statement starts. The lock in lsTermSpeedSq (and by extension that on lsPress) works perfectly, as can be seen with the debug at 1000 altitude: lsTermSpeedSq has the actual value, lsSpeedSq has the same as in the debug PRINT right before the WAIT statement.

[Camacha]

My two latest inventions: A countdown clock and an instrument landing system. All stock built, but controlled by kOS.

That counter is delightfully useless yet awesome. But just one thing: would you leave some awesome stuff for the others to build?

[Sma]

kOS seems to have some really weird problems with LOCK ... TO. The following code is a first step to an autolauncher with thrust adaption against drag losses.

...

The problem is that the lock on lsSpeedSq, based on verticalspeed (or velocity:surface), stops working as soon as the WAIT UNTIL statement starts. The lock in lsTermSpeedSq (and by extension that on lsPress) works perfectly, as can be seen with the debug at 1000 altitude: lsTermSpeedSq has the actual value, lsSpeedSq has the same as in the debug PRINT right before the WAIT statement.

I just use the "keep speed around 200m/s" mentality. Maybe not as accurate or efficient as what you're trying to do but it works for me and isn't "too complicated".

set sspeed to (verticalspeed^2 + surfacespeed^2)^0.5.
if sspeed > 200 and altitude < 12000 {lock throttle to throttle - 0.005.}.
if sspeed < 200 and throttle < 1 {lock throttle to throttle + 0.005.}.

I tried it using

set sspeed to ( velSurf:x^2 + velSurf:y^2 + velSurf:z^2 ) ^ 0.5 .

but for some reason changed it to the other one. I'll have to try it again and see if there was a problem or not.

Pretty sure I got the formula for that from someone else, possibly Steve, don't remember now, but adapted it for my "understanding" lol.