Jump to content

kOS Scriptable Autopilot System 0.9


KevinLaity

Recommended Posts

Hi kOS users! I'm not a programmer and not very interested in scripting flight profiles, but could anyone say if this mod allows tracking directions to vessels and celestial bodies for remote tech commdish auto-orientation purpose? :)

Link to comment
Share on other sites

Hi kOS users! I'm not a programmer and not very interested in scripting flight profiles, but could anyone say if this mod allows tracking directions to vessels and celestial bodies for remote tech commdish auto-orientation purpose? :)

Quite possible. There is support for 3rd party mods. I haven't used remote tech, so I'm not sure if what you're asking is doable, but it could be or perhaps might be in the near future.

Link to comment
Share on other sites

Quite possible. There is support for 3rd party mods. I haven't used remote tech, so I'm not sure if what you're asking is doable, but it could be or perhaps might be in the near future.

Well RemoteTech integration no needed actually. :) What I mean is some kind of command that returns vector parameters to chosen object or planet. So for example I can deploy stock Communotron on my probe and comand him to track Minmus for simulating datalink with expedition vessel or base on Minmus surface.

Edited by ZobrAA
Link to comment
Share on other sites

Hi kOS users! I'm not a programmer and not very interested in scripting flight profiles, but could anyone say if this mod allows tracking directions to vessels and celestial bodies for remote tech commdish auto-orientation purpose? :)

Being as that dev on remotech is, as far as I understand it, currently on a standstill, at least until 0.22, then most likely not at the moment. For the most part though I was under the impression that sort of already happens. If you have a probe and tell it to connect to KSC it should relay off different sats automatically to get to KSC. I've only messed around with RT2 though which is in playtesting so its only got 1 or 2 relay bounces I think.

Link to comment
Share on other sites

Hmm Not sure what is going on there. I was thinking about switching over but for now I've been using the V() system with R() to set roll. It's dead on every time.

EDIT: Have you tried setting the rotations first? lock steering to R(0,0,180) + heading X by Y....

Not sure you really need R() in combination with using heading, well...I guess for roll maybe, though I don't really see why, except maybe for planes. Or maybe I'm just not getting it. :) ...
I tried that just now and all it did was give me problems. Same with putting R() after heading. The problem, I think, is that R(0,0,180) on the navball is the horizon, and I would end up somewhere between 45 and 0. I tried it with "up" and my direction never changed. For now I'm ok with it rotating so that north is on the top left of the navball as opposed to the bottom left. I wouldn't be surprised if in the next update or 2 roll will be a part of heading.

Didn't try lock steering to R(0,0,180) * heading X by Y though.

Update Yeah, that didn't work out so well either lol, it flipped upside down before settling between 45 and 0, upside down too. Was interesting to watch though lol.

...

I actually use that to prevent the ship from rotating. Whenever I used the lock steering command. It rotated first and then stared to point where I wanted to.

While on small that might be not a problem one of my bigger ships (not used after 0.6 though) is rotating too slowly. It IS actually a bad designed ship, which has also falls apart if I use too much thrust below 3km, but actually that's not the point. You should be able to adapt your program even to those ships.

I consider that as broken. It worked in 0.60 and was broken with V() patch.

Please read this thread through to the end:

http://forum.kerbalspaceprogram.com/showthread.php/50274-I-can-t-understand-the-coordinate-system-why-am-I-moving-vertically-when-on-ground

I had the same problem and read the code on github and saw that all it's doing is exposing us to the native API's concept of velocity, so I figured whatever weridness was going on must be coming from the underlying mod API. So I asked over there if other mod makers could tell me how the native coordinate system is meant to work.

I think I can work out from the second number of the "UP" tuple what the REAL longitude is relative to the planetary axis and work it out from there. (Squad chose to make the reported longitude to the user not match the coordinate grid underneath for ... uh... no apparent reason. The real zero point seems to be around about 100 degrees longitude for some reason).

Great! 5 pages of content where I have understand nothing of. Basically what I had understood that it was 5 pages of wild guessing until someone wrote the solution into the wiki.

Why not link to the wiki directly? Have I missed something? (might be, I am not an English native)

Oh okay. I knew you could get a slope doing that, but it only gives you the slope in the direction of your horizontal velocity. I thought maybe you had figured out some otherway to get your absolute slope. Good job nonetheless.

That's exactly what I'm working on now. Land anywhere so long as your target latitude is within your orbital inclination. But the damn inverse trig is broken, so I've hit a roadblock for now.

Doing a circle before landing? I mean that would basically cover the landing area.... But I guess that would use too much fuel. How about to pre examine the terrain while still orbiting? I mean you can get the geo position for each nonslope ... Not a good Idea for Kerbal or anything that has Mountains higher than 20km, though. But that might actually help for anything else. And since you know where you have to go, you can use that saved fuel for the mentioned circle.

Since I was working on the list of command, I haven't had much time to play with kOS either, so I actually don't know...

Btw: does someone else have now trouble with the when statement?

my code is like that:

...snip

when <solidfuel> = 0 then { stage. }.
clearscreen.

print "Altitude" at (0,0).
print "Apoasis" at (12,0).
print "Periapsis" at (24,0).
print "V-Speed" at (36,0). // Vertical Speed
print "Stage Fuel" at (0,2).
print "Distance" at (24,2). // Distance to target
print "Acceleration" at (36,2).
print "Surfacespeed" at (0,4).
print "Target" at (15,4).

until altitude > 10000 {
print "solidfuel: " at (0,7). //debug
print <solidfuel> at (12,7). //debug
print altitude at (0,1).
print ALT:APOAPSIS at (12,1).
print ALT:PERIAPSIS at (24,1).
print VERTICALSPEED at (36,1).
print STAGE:LIQUIDFUEL at (0,3).
// print target:distance at (24,3).
print SURFACESPEED at (0,5).
// print target at (15,5).
if VERTICALSPEED > 200 AND pow > 0{
set pow to pow -0.02.
}.
if VERTICALSPEED < 200 AND pow < 1{
set pow to pow +0.02.
}.
}.

snip...

Remark: The boosters lasts until 3700m

Remark2: The stage:something thing is bugged... in KSP not in kOS, though. Since sometimes (meaning on some ships on some stages) I get a reading and sometimes not. If I am not getting one its most likely that I changed something in the order of the attached stages in the editor. A test has shown rebuilding the ship from scratch helps.

I also tried "when <solidfuel> < 0.01 then { stage. }."

then I added the debug parameter. The 1st time it stopped (printing) at 0.03....., I was wondering about that but I set "when <solidfuel> < 0.04 then { stage. }."

The next run it stopped at 0.44 which is way too high, but I set "when <solidfuel> < 0.45 then { stage. }." anyway.

Still no staging.

I have to mention if I interrupt the program (with contr-C) and I enter "print <solidfuel>." It says "0" as well as "print <solidfuel> = 0" which says "True".

Well if I do that prelaunch it says 866 / False.

So I assume that when is (at least partly) broken.

My code brings me to anther topic.

print target[:whatever] locks the loop if the target is not set. I mean nothing within the loop will be processed but the rest of the code (before and after the loop) will. And the loop also ends correctly.

That should be fixed, too.

Edit: is lock target actually implemented for anything else than vehicles? I mean I got an freeze when I set a celestial body as target (in map view) and then typed in "lock steering to target.".

Edited by Bizz Keryear
no doubble post
Link to comment
Share on other sites

Did a search in this tread and can't find anybody with same trouble: I just update to 0.65 and now when I type into console window, the KSP also obey the keystrokes. For instance, if I press t the SAS will turn on and when I press spacebar the staging will stage. Can't use kOS anymore.

Link to comment
Share on other sites

Did a search in this tread and can't find anybody with same trouble: I just update to 0.65 and now when I type into console window, the KSP also obey the keystrokes. For instance, if I press t the SAS will turn on and when I press spacebar the staging will stage. Can't use kOS anymore.

On map view, though, it reacts to the arrow keys. But that is all for me.

Tried a clean install? I mean deleting the mod first and the copying the update. Are you running any other mods?

Link to comment
Share on other sites

Thanks again Steve. I'll give that a go. I just need it to hold the craft steady until after I make the circularization node. Then ill just kill the program. But its at that point I want the craft to lock onto the node with a separate script after MECO. ( separate because I have to make the node ) Now the reason I'm doing this is because its a fairly large craft that needs to start burning 20 seconds before the node and stop 20 seconds after. Now I can have kOS circularize for me easily, but if I have to burn at t-20 with the craft locked to prograde I cannot achieve my target apoapsis. It needs to burn facing the node. Not prograde. It's fine for a small craft that only needs to burn at t-5 to circularize, buts its null for large ones.

Any tips?

Link to comment
Share on other sites

On map view, though, it reacts to the arrow keys. But that is all for me.

Tried a clean install? I mean deleting the mod first and the copying the update. Are you running any other mods?

Yes, I deleted the old mod files. I run mechjeb, remotetech, kethane, B9, Proc. Fairings and KW.

Link to comment
Share on other sites

Yes, I deleted the old mod files. I run mechjeb, remotetech, kethane, B9, Proc. Fairings and KW.

WHen I read your first post I was going to say your problem is remotech. I too was using it and had that problem but after removing it (RT2 to be exact) it was fine. Still does it on occasion like Bizz said mostly on the map, after leaving the initial kOS window, but other than that it's fine.

Link to comment
Share on other sites

WHen I read your first post I was going to say your problem is remotech. I too was using it and had that problem but after removing it (RT2 to be exact) it was fine. Still does it on occasion like Bizz said mostly on the map, after leaving the initial kOS window, but other than that it's fine.

Ouch. I'm using the first version of remotech here. I'll try without it.

Link to comment
Share on other sites

Btw: does someone else have now trouble with the when statement?

my code is like that:

...snip

when <solidfuel> = 0 then { stage. }.

snip...

As you likely know <solidfuel> is for all solids in the rocket. If you have all solids on the same stage, then thats fine, but if you have some on another stage, or even sepratrons it wont stage until all solid is burned.

Remark2: The stage:something thing is bugged... in KSP not in kOS, though. Since sometimes (meaning on some ships on some stages) I get a reading and sometimes not. If I am not getting one its most likely that I changed something in the order of the attached stages in the editor. A test has shown rebuilding the ship from scratch helps.

I also tried "when <solidfuel> < 0.01 then { stage. }."

then I added the debug parameter. The 1st time it stopped (printing) at 0.03....., I was wondering about that but I set "when <solidfuel> < 0.04 then { stage. }."

The next run it stopped at 0.44 which is way too high, but I set "when <solidfuel> < 0.45 then { stage. }." anyway.

Still no staging.

I did a test using stage:solidfuel < 0.05 for a stack of 7 boosters (5 large on stage 1, 1 large on stage 2, and 1 small on stage 3) and it worked every time. As you said it seems to be different for different rockets, though I only tested it for one, so it could be broken still.

print target[:whatever] locks the loop if the target is not set. I mean nothing within the loop will be processed but the rest of the code (before and after the loop) will. And the loop also ends correctly.

That should be fixed, too.

I know if something from the code is missing, like a full stop at the end of the line or a missing close bracket or parenthesis, that'll sometime cause the same problem. Not saying that is whats happening in your case, but something to look out for. I've spent 5 minutes or more before trying to figure out why something isn't happening that should when stuff before/after it works only to find out thats what the problem was. :)

Link to comment
Share on other sites

Ouch. I'm using the first version of remotech here. I'll try without it.

What I've been doing is going into the mod for the folder and putting it all in a zip file and removing the actual files. That way I can just unzip it later, like in the case of the docking alignment tool, and participating in reddit challenges. Keep in mind though, with out part files, any craft that uses that mod will be deleted, especially if you go to it, so make a backup of your persistent and quicksave files just in case, unless of course it doesn't matter.

Link to comment
Share on other sites

As you likely know <solidfuel> is for all solids in the rocket. If you have all solids on the same stage, then thats fine, but if you have some on another stage, or even sepratrons it wont stage until all solid is burned.
Not needed. It is only one stage that contains 866 solidfuel .. only those two small boosters. As I said If I interrupt the program afterwards (after they are burned out) and do a
print <solidfuel>.
[B]0[/B]

and if i do

print <solidfuel> = 0.
[B]True[/B]

I did a test using stage:solidfuel < 0.05 for a stack of 7 boosters (5 large on stage 1, 1 large on stage 2, and 1 small on stage 3) and it worked every time. As you said it seems to be different for different rockets, though I only tested it for one, so it could be broken still.

I didn't done that for solidfuel, though. I just seen it for Electricalenergy and liquidfuel. Even if kOS is better. it is almost the same as hitting the stage only button on the resources. And not one of those I had in mind had a asparagus design.

I know if something from the code is missing, like a full stop at the end of the line or a missing close bracket or parenthesis, that'll sometime cause the same problem. Not saying that is whats happening in your case, but something to look out for. I've spent 5 minutes or more before trying to figure out why something isn't happening that should when stuff before/after it works only to find out thats what the problem was. :)

My code is exactly like I posted it. I did copy paste it. And it is working is it is, but if I remove the comments it is not. everything in the loop freezes until the loop ends.

However only if a target is not set.

when <solidfuel> = 0 then { stage. }.
clearscreen.

print "Altitude" at (0,0).
print "Apoasis" at (12,0).
print "Periapsis" at (24,0).
print "V-Speed" at (36,0). // Vertical Speed
print "Stage Fuel" at (0,2).
print "Distance" at (24,2). // Distance to target
print "Acceleration" at (36,2).
print "Surfacespeed" at (0,4).
print "Target" at (15,4).

until altitude > 10000 {
print "solidfuel: " at (0,7).
print <solidfuel> at (12,7).
print altitude at (0,1).
print ALT:APOAPSIS at (12,1).
print ALT:PERIAPSIS at (24,1).
print VERTICALSPEED at (36,1).
print STAGE:LIQUIDFUEL at (0,3).
// print target:distance at (24,3).
print SURFACESPEED at (0,5).
// print target at (15,5).
if VERTICALSPEED > 200 AND pow > 0{
set pow to pow -0.02.
}.
if VERTICALSPEED < 200 AND pow < 1{
set pow to pow +0.02.
}.
}.

Link to comment
Share on other sites

Hi ,

I have a problem with the trigonometric functions.

It seems that it is not possible to use them for further calculations.

print 0-arcsin(0.3).

Isn't working. Not sure whether I'm doing something wrong or whether kOS has some problems with the digits?

I tested following (the numbers are just random to show the problem):

set a to arcsin(0.3).

print a.

17.7894561231232

but

set a to 17.789456123123.

print a.

17.789456

print 0-a.

-17.789456

Please help, I just wanted to invert an angle... ^^

Link to comment
Share on other sites

Great! 5 pages of content where I have understand nothing of. Basically what I had understood that it was 5 pages of wild guessing until someone wrote the solution into the wiki.

Why not link to the wiki directly? Have I missed something? (might be, I am not an English native)

Why not just link to that last URL? Because I can't see into the future that's why. Check the dates on the posts.

Link to comment
Share on other sites

Take the data that you have gathered from your ISAMAP Sat survey. The whole idea of the pre-survey mapping is to have the body or at a minimum your landing site properly mapped. Then as you are making your approach, you can use the raw map data as a lookup.

Well, that's what i am doing.... I use the data from the mapsat surveys to check and plan for landing site survey, slope verification, and terrain avoidance (on Minmus it is required when coming in low and hot..) Found too many mountains that were just a little bit higher than i thought....

Cheers.

I've seen such horror stories on mapsat being such a mess right now spiking CPU usage that I'm not installing it until it gets an update. But otherwise that seems like the right approach which is why I gave up on trying to detect slope in both directions as a solution. (Also, trying to store a field of data points from which to build an idea of ground slope is a bit of a pain when the language doesn't have arrays or sets or any sort of aggregate data type at all.)

Link to comment
Share on other sites

No spiking for me, but i am using 3.3.4....... The new one uses the large format image files and while it is nice and cute to be able to zoom in on the little screen, it is hardly worth the overhead. The "unofficial" version on SpacePort works great. just make sure to load it the old way, under plugins, parts and not GameData..... I also wrote a small piece of code to take all of the .csv files and build a master .csv that i then feed to the MapGen.exe routine... And then the defaulted maps for use in the ISAMapSat .dll for viewing in game, and the full images (3600 pix wide) to load into whatever mapping routine i want to use, and the .csv to have as a dBase for the surface lookup routines. I really hope that the owner comes back and works with it again, as i enjoy this form of mapping.... If he does not, i will look into taking it,or starting over scratch. Make a new version, but based on the idea of the more resolution that you want, will require more effort to get it....

Good luck, have fun

Link to comment
Share on other sites

"It allows you write small programs that automate specific tasks." I guess this depends on the definition of small. ;)

Well, launch one vessel into Orbit.

Then launch another one. Autodock. Slingshoot at moon. Flight to Jool. Atmosphere break to Bop. Into a stable Orbit. Landing there, but while at it finding a non slope landing space. Drive a rover probe around, getting it back to the lander and dock with it. Docking at Orbit. Fly back. And safely landing at Kerbin.

Manned of course. (at least to Bob)

All in one shot and one program (except the very first vessel, and Jeb who missed, of course, the departure from Bob.)

That all should all fit in a small program, or not?

(At least if you call Windows 7 a small program)

Link to comment
Share on other sites

Nice mod! Have started testing building my own launch to orbit script in hope to maximize fuel efficiency and are now trying to figure what all these rotations and vectors really are.

Have figured out that surface speed in the gui seems to be the same as VERTICALSPEED + SURFACESPEED, which is confusing. Not only because of the name but since SURFACESPEED is declared as the horizontal speed in kOS, which would make this relation violate Pythagoras. Have been trying to create an accelerometer using the change in speed, so that I could determine the drag loss.

Here is my current code for the accelerometer implemented in a "when" thread. It is somewhat shaky. Publishing it here in hope someone might be able to help me improve it. Although I think kOS should have an accelerometer and a gyro builtin, as that is what you probably have to do with in real life.

{"Accelerometer thread. Calculates velocity change in horizontal and vertical direction. Not a true accelerometer as G-force is lacking."}.
set a_vertical to 0.
set a_horizontal to 0.
set accelerometerThread to 1.
when accelerometerThread = 1 then {
print "Initializing accelerometer.".
set accelerometerThreadPrevTime to MISSIONTIME.
set accelerometerThreadPrevVerticalSpeed to 0.
set accelerometerThreadPrevHorizontalSpeed to 0.
print "Accelerometer started.".
until accelerometerThread = 0 {
set accelerometerThreadTime to MISSIONTIME.
set accelerometerThreadVerticalSpeed to VERTICALSPEED.
set accelerometerThreadHorizontalSpeed to (((SURFACESPEED + ABS(VERTICALSPEED))^2 - (VERTICALSPEED)^2)^0.5).

if (accelerometerThreadTime - accelerometerThreadPrevTime) > 0.0 {
set a_vertical to (accelerometerThreadVerticalSpeed - accelerometerThreadPrevVerticalSpeed) / (accelerometerThreadTime - accelerometerThreadPrevTime).
set a_horizontal to (accelerometerThreadHorizontalSpeed - accelerometerThreadPrevHorizontalSpeed) / (accelerometerThreadTime - accelerometerThreadPrevTime).
}.

set accelerometerThreadPrevTime to accelerometerThreadTime.
set accelerometerThreadPrevVerticalSpeed to accelerometerThreadVerticalSpeed.
set accelerometerThreadPrevHorizontalSpeed to accelerometerThreadHorizontalSpeed.
}.
print "Accelerometer ended.".
}.

Thanks again for a great mod, will now go back to scripting.

By the, way does anyone else feel like the yaw and pitch have got swapped somehow when reading out rotations?

Link to comment
Share on other sites

Okay.. I tried to ask in pm, but apparently the forums dont want me to send one, so im forced to ask in here..

Kevin, I am a programmer myself, and have wanted to build an APS myself for some other games for a while. Im missing knowledge on how to properly implement parsers and lexers. Any recommendations? I would really like some input on this. I have basic knowledge, but not enough to actually get a functioning system with.

Link to comment
Share on other sites

What I've been doing is going into the mod for the folder and putting it all in a zip file and removing the actual files. That way I can just unzip it later, like in the case of the docking alignment tool, and participating in reddit challenges. Keep in mind though, with out part files, any craft that uses that mod will be deleted, especially if you go to it, so make a backup of your persistent and quicksave files just in case, unless of course it doesn't matter.

Did not need to do that indeed. Just build a rocket without the remote tech part and voilá, it works. I know you have nothing to do with RT, but can this be fixable in kOS so in future another plugin don't mess with this again?

Another question. I heard in 0.65 video in youtube that you need to be in 100km range (i believe from KSP Base) to archieve volume works. More distance antennas are needed. How this works? Maybe with functionality of antennas and relays to be able to control my probes I can ditch remote tech and stay only with kOS, that is possible?

Link to comment
Share on other sites

Well, launch one vessel into Orbit.

Then launch another one. Autodock. Slingshoot at moon. Flight to Jool. Atmosphere break to Bop. Into a stable Orbit. Landing there, but while at it finding a non slope landing space. Drive a rover probe around, getting it back to the lander and dock with it. Docking at Orbit. Fly back. And safely landing at Kerbin.

Manned of course. (at least to Bob)

All in one shot and one program (except the very first vessel, and Jeb who missed, of course, the departure from Bob.)

That all should all fit in a small program, or not?

(At least if you call Windows 7 a small program)

If you are programming for each ship you fly you can take a lot of shortcuts. I don't know why you would want to get all of that into a single file anyway. I'd say that might be possible but not sane.

If you want something more agnostic then you will quickly find that you wont be able to fit everything in to the 10k limit. Launch to orbit script from space computer is over 7k with comments. I really don't think the limit serves any purpose. Since comments count, nearly a third of the space is consumed by them alone. The language is also extremely verbose. That doesn't help. The limit needs to be more like 64k.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...