Jump to content

kOS Scriptable Autopilot System 0.9


KevinLaity

Recommended Posts

Oh god, if we had a sound function it would be fantastic. My first ever program was messing around with the computer beeps on Amstrad, setting the pitch and so on. Descending too quickly? WARMP, WARMP!

You could do that. You just need different lights setup to play different sounds. HAHAH you could even make a beat machine!!! We can do this right now!!! No changes to anything are needed.

EDIT:

OK a bit of a wrench in the works. I can't get the sound to play at all. Apparently Squad broke sounds loading a while back and now you need a module to make it work. Uggghhhh.

Edited by Payload
Link to comment
Share on other sites

When a program ends, any temporal commands you've issued within the scope of that program are discarded, including ON.

I recommend putting a WAIT statement at the end of your program, and give it a criteria that matches when you want the program to end.

Thanks Kevin, that did the trick. I now have a nicely working abort sequence which will also trigger automatically if the ship is no longer climbing. This is an outstanding mod. Thanks for all the hard work involved in creating it!

Link to comment
Share on other sites

This is great news. I've been wanting this for a long time.

There doesn't seem to be any way of using radar altitude. There really should be.

Couldn't agree with you more. I'm hoping for that and some more data to come.

Link to comment
Share on other sites

Logging is a maybe, I can see the usefulness.

I'd love to interact directly with parts, including statuses, fuel levels, and even issuing commands.. (automated fuel transfer! individual engine throttles!)

Unfortunately, the road block I've hit with that is that while KSP does give a unique ID to every part, that ID gets thrown away when the ship unloads, and a new random one assigned later. Which means if you write a program for your ship that addresses an individual part, that program becomes useless later.

I have some ideas on overcoming this, but not sure when I'll get to it.

Maybe have a "bus" part in the VAB/SPH? One that keeps a consistent/separate ID and that the computer can interact with(and with the part it's attached to.

Can we program in the VAB, by the way?

And have you considered using the probe parts as computers instead of being it's own part? Heck, you could make that the only way to control them if you're feeling hard-corey (and yes, that's a word now.)

Link to comment
Share on other sites

This has to be one of the coolest things i've played around with in KSP! I do have a question regarding the reaction times of control inputs though. This is what i'm trying to run:


clearscreen.
set tVar to 0.75.

print "Launch Sequence Starting".

lock steering to up + R(0,0,180).
toggle SAS.
lock throttle to tVar.
wait 1.
stage.

until altitude > 500 {
if verticalspeed < 50 {
set tVar to tVar + 0.1.
}.
if verticalspeed > 50 {
set tVar to tVar - 0.1.
}.
}.

print "Hover Sequence Starting".

until altitude < 100 {
if verticalspeed < -10 {
set tVar to tVar + 0.05.
}.
if verticalspeed > -5 {
set tVar to tVar - 0.05.
}.
}.

Upon running, it immediately sees that my vertical speed is less than 50 so it throttles up from 75% to 100%. But it won't throttle back down when the vertical speed increases above 50.

When it tries to transition into hover mode, it prints the string then continues at 100% throttle until i'm well over 1000m up. Once it starts trying to hold the -10 to -5 descent rate, it will throttle down to 0 until my vertical speed is about -30 at which point it throttles up to full until my vertical speed is around +30. This "yo-yo'ing" will continue until i end the program, it never settles down into the correct descent rate.

Is the poll rate not fast enough for these types of maneuvers or am i doing something wrong?

::edit:: Ok, it seems to be something with the custom variable rate because if i change it to:


print "Hover Sequence Starting".

until altitude < 100 {
if verticalspeed < -10 {
lock throttle to 0.5.
}.
if verticalspeed > -5 {
lock throttle to 0.
}.
}.

That works perfectly and kicks the engine on and off at precisely -10 and -5, respectively.

Edited by dave4002000
Link to comment
Share on other sites

Maybe have a "bus" part in the VAB/SPH? One that keeps a consistent/separate ID and that the computer can interact with(and with the part it's attached to.

Can we program in the VAB, by the way?

And have you considered using the probe parts as computers instead of being it's own part? Heck, you could make that the only way to control them if you're feeling hard-corey (and yes, that's a word now.)

The bus part: I'd rather not if I can avoid it. At one point I tried automatically forcing new partmodules onto all the ship's parts at launch time and assigning them id's. It worked great except they wouldn't be reloaded with the ship.

No, you can't program in the VAB. I had thought about that and having people save their programs along with their vessel prototypes. I couldn't find a way. Vessel prototypes basically just keep track of the fact that a part is there, and can't save any configuration of that part.

I prefer not to overwrite behavior of someone else's part, including stock parts. However, we may see a kOS unit that also acts as a probe part.

Link to comment
Share on other sites

And have you considered using the probe parts as computers instead of being it's own part?

You could go edit the .cfg files to add the functionality to probes (and capsules, if desired).

Edit: Would it be possible to have more than one terminal available? I can see the value of running a program on one while working on another, or using one to display flight data.

Edited by razark
Link to comment
Share on other sites

The bus part: I'd rather not if I can avoid it. At one point I tried automatically forcing new partmodules onto all the ship's parts at launch time and assigning them id's. It worked great except they wouldn't be reloaded with the ship.

No, you can't program in the VAB. I had thought about that and having people save their programs along with their vessel prototypes. I couldn't find a way. Vessel prototypes basically just keep track of the fact that a part is there, and can't save any configuration of that part.

I prefer not to overwrite behavior of someone else's part, including stock parts. However, we may see a kOS unit that also acts as a probe part.

The author can design a PartModule that are automatically inserted into all parts by using Sarbian's Module Manager's Extensions.

That way, it can allow users to specify some special flag bits (or no flag at all if you don't want to do anything with the part) for each part. And by designing some new interfaces like:

Invoke ActionName of Part(flag bits).

We can then invoke the specified actions of those parts that matches the flag bits.

Example:

we've decided to use the third bit of the flag as the flag for all solar panels on the vessel.

we then need to set all solar panels' flag bits so that their third bit is 1.

then we need to write some script like:

Invoke "Expand Panels" of Part(4). // Here 4 = 100(binary) so the third bit is 1.

Edited by HoneyFox
Link to comment
Share on other sites

I wish the terminal could be run from a separate computer....... or at a minimum, not in the ksp screen.....

That's a great idea, someone should get it to work with Telemachus – Telemetry and Flight Control. :D

Link to comment
Share on other sites

i have been looking for a way to completely setup and fly non manned missions without 'touching' the ksp screen. would be one hell of a challenge to be able to do it that way. especially when you put in the signal delay and such.... I really am looking forward to this.

great stuff....

Link to comment
Share on other sites

i have been looking for a way to completely setup and fly non manned missions without 'touching' the ksp screen. would be one hell of a challenge to be able to do it that way. especially when you put in the signal delay and such.... I really am looking forward to this.

great stuff....

I just can't wait until we get the plain text editor. Then we can go full nerd on this thing and have some amazing collaborative works. Like from reading someones script here earlier, I realized this thing has user input already in the form of action groups. I read it in the readme but it just didn't stick what could be done with it. We can make a launch computer that asks for values such as desired orbit and the like. We only need two keys for scrollable alpha numeric input.

Link to comment
Share on other sites

I'm trying to wrap my head around why "up + R(0,-70,180)" gives me 70 degrees positive pitch at 90 degrees heading. This mod definitely needs a wiki where things like this are explained.

"random jibberish".

EDIT:

Hmm I'm betting that the first number is vector N/S and the center is vector E/W and the third number is strictly roll. That is because of the modifier "up". Up is a body reference not just a gravity reference?

Edited by Payload
Link to comment
Share on other sites

I'm trying to wrap my head around why "up + R(0,-70,180)" gives me 70 degrees positive pitch at 90 degrees heading. This mod definitely needs a wiki where things like this are explained.

Let me know if this helps: Imagine laying on your back facing the sky. But you realize that, oops, your head is pointing southward so you spin yourself around 180 degrees. Since you're facing up, that's akin to an aircraft rolling 180 degrees. Now yaw yourself 70 degrees east.

That method is relative. We may need an alternate option for having a more aircraft like system where you're navigating by heading relative to north and by pitch relative to angle of the surface.

EDIT:

Come to think of it, if I were to put in an expression for NORTH, I think you could express the same direction as something like NORTH + R(20,90,0). Although not sure offhand if the pitch or yaw would be applied first.

Edited by KevinLaity
Error everywhere!
Link to comment
Share on other sites

Let me know if this helps: Imagine laying on your back facing the sky. But you realize that, oops, your head is pointing southward so you spin yourself around 180 degrees. Since you're facing up, that's akin to an aircraft rolling 180 degrees. Now yaw yourself 70 degrees east. That method is relative. We may need an alternate option for having a more aircraft like system where you're navigating by heading relative to north and by pitch relative to angle of the surface. EDIT: Come to think of it, if I were to put in an expression for NORTH, I think you could express the same direction as something like NORTH + R(20,90,0). Although not sure offhand if the pitch or yaw would be applied first.
*derp derp derp* EDIT: It's steering, not heading. I should not post on the forums without a full cup of coffee in the morning. Thanks for the clarification and the great plugin, KevinLaity, I'm looking forward to seeing it mature. Edited by norcalairman
Link to comment
Share on other sites

That's a great idea, someone should get it to work with Telemachus – Telemetry and Flight Control. :D

This is one of the things I considered, basically serving your terminal over telnet or maybe even doing an HTML page with an editor that works over websockets.

Link to comment
Share on other sites

This is one of the things I considered, basically serving your terminal over telnet or maybe even doing an HTML page with an editor that works over websockets.
This would be amazing! Being able to execute an entire mission remotely with scripted landing sequences would be great.
Link to comment
Share on other sites

Did some more testing in regards to my issue. Original post is here: http://forum.kerbalspaceprogram.com/showthread.php/47399-kOS-Scriptable-Autopilot-System-0-35?p=621892&viewfull=1#post621892

I threw a couple print commands into the loop to see what would happen. This is my testing script.


until altitude > 10000 {
if vertical speed < 100 {
print "Throttling up".
set tVar to tVar + 0.02.
}.
if vertical speed > 100 {
print "Throttling down".
set tVar to tVar - 0.02.
}.
}.

This continuously prints 'throttling up' as soon as the program runs. The second i go over 100m/s it switches to printing "throttling down" (so i know it's recognizing the speed correctly). But it still won't actually move the throttle for another 5 seconds or so, and by that time i'm already over 150m/s. So it seems that i'm having an issue with throttle response. Are other people seeing the same thing or is this just on my end?

Link to comment
Share on other sites

Did some more testing in regards to my issue. Original post is here: http://forum.kerbalspaceprogram.com/showthread.php/47399-kOS-Scriptable-Autopilot-System-0-35?p=621892&viewfull=1#post621892 I threw a couple print commands into the loop to see what would happen. This is my testing script.
 until altitude > 10000 {  if vertical speed < 100 {  print "Throttling up".  set tVar to tVar + 0.02.  }.  if vertical speed > 100 {  print "Throttling down".  set tVar to tVar - 0.02.  }. }. 

This continuously prints 'throttling up' as soon as the program runs. The second i go over 100m/s it switches to printing "throttling down" (so i know it's recognizing the speed correctly). But it still won't actually move the throttle for another 5 seconds or so, and by that time i'm already over 150m/s. So it seems that i'm having an issue with throttle response. Are other people seeing the same thing or is this just on my end?

After "set tVar to tVar - 0.02." try adding "print tVar." to make sure it's actually doing it.
Link to comment
Share on other sites

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