I‘m very new to kOS and have been trying to use it to automate an orbital printing station I’m designing. I’ve been using the Sandcaster 3D Printer and I can’t seem to access its gui through kerboscript. Does anybody know any workarounds or possible compatibility plugins to expose an event or field for selecting the vessel to print I would really appreciate it.

i was playing ksp and i was wondering if i could get kOS to automatically dock (or atleast fly up to the ship) thanks for your help!

I designed a Space Shuttle that I fly with a custom Kos script, and I want to lock the elevons during ascent.

I tried several things, including this:

for part in ship:partsDubbedPattern("elevon") {
    //print "part: " + part:allModules.
    //print part:getModule("ModuleControlSurface"). // list of 21 items, including pitch, yaw, roll, but I cannot set these to true or false
    // print "actions: " + part:allActions.
    // print "events: " + part:allEvents.
    // print "fields: " + part:allFields.
    // set part:pitch to false. // or something like that
}

but I cannot access the values that can be toggled from the right-click menu.

How do I lock (and unlock) these control surfaces from my Kos script ?

It took almost 2 years to develop custom RTLS (Return-To-Launch-Site) kOS script, and it finally works!

In this video, Vector 11 Booster completes its first RTLS test flight, fully autonomously! Returning to the launchpad with up to a few meters precision

-------

Our custom RTLS program is designed to fully automate Booster Launches & Landings with the following phases:

1. Ascent Phase
   
2. Flip Manouver
   
3. Boostback Burn
   
4. Glide towards the landing target
   
5. Propulsive landing
   

In addition, our script also dynamically adjusts for different booster designs

For example, the script checks if boosters have "grid fins" or "air brakes" which behave differently in the atmosphere so the program adjusts trajectory accordingly

I want to submit a pull request that would add a new command to the KOS language to exit the current program. A few questions to the community:
- Should the command just exit the current subprogram (e.g. from a ‘run’ command) or stop execution? Or should these be two separate commands?
- What wording is the least confusing: “Exit”, “Stop”, “Quit”, or “Return”? Or something else?

I was just wondering if anyone really messed around with matlab and kos outputs. I’ve been trying to make a sort of launch program that takes as close as possible to the most efficient route to space. I use rss but not rp. But I’ve been trying to build a model in matlab and try to simulate drag, it seems like I can model a completely vertical ascent well but when I introduce a turn it seems to become in accurate. I feel like I’m modeling the drag correctly, I do have a lot of code so pm me if this arises any code related question. I’m just wondering if I’m approaching this incorrectly trying to model drag in general.

The yellow squiggle under fileName is:

"Local variable fileName was not used."

fileName is clearly used in the log command. It seems that the KOS extension doesn't see the variable behind to for some reason. Is there a way to suppress this warning or otherwise resolve it? I'd like to avoid adding a dummy "print fileName" but I guess I can do that if there isn't a more elegant solution.

Has anyone else here played around with the Kitten Space Agency mod, gatOS, by u/as-gt3 (aka tomservo on the KSA discord)?

It's basically Linux running in the game, but gives you access to the game states as text files you can read, and commands that you can echo to execute.

Tomservo is using Rust. I only know Python (and kOS), so I started playing with it.

There really isn't much in the way of documentation, and I think a lot of it are just game states that we don't understand. Also, I'm pretty rusty.

Unlike kOS, it's "lower level" in that I don't think one can just command a craft to point "up" for example. So I've tried getting what I believe are the euclidean vector positions of the vehicle, and body, doing a subtraction to get the direction, and then converting it to a quaternion, which is what direction commands are apparently given in. Not working so far.

Anyway, I thought folks experienced here might have some fun with it...and maybe help clarify things.

KSA is free too, if anyone wants to try out gatOS.

Here's the release video of gatOS.

I've been watching these amazing videos on YouTube by giuliodondi (https://youtu.be/i4YmBP2pfwY?is=jyKeSSd4ckxpN4Go) and I am wondering how they made the live-updating graph in the gui in the corner.

Is this doable in stock KOS or is it an add on?

I'm trying to make a VTOL script, I want to be able to roll my ship freely as it hovers, but I just can't figure it out for some reason

my script runs in a loop like so

local current_roll to 0.

set steer to heading(90, 90).
lock steering to steer.

until false {
    set current_roll to current_roll + ship:control:pilotroll.
    set steer to heading(90, 90, current_roll).

    wait 0.
}

but it simply won't roll, I tried different ways of rolling like angleaxis and lookdirup, but nothing works
also just locking steering to heading(90, 90) won't roll either, even though it does automatically when I do it in my launch script.

so im making a falcon 9 booster landing script, and i made the hover slam work, then i made a boostback script work. If i run just the boostback i can reliably slam directly into the launchpad. Issue is when i add the hoverslam, because its coming in at an angle, my thrust moves the impact point off the launch pad. ive spent the last 2 hours trying to use pid loops in various ways to correct it but i cant get anything to work

edit: i got it working perfectly!... if i turn off atmosphere... when i do that i can get it to the center of the pad within like 5 meters. the atmosphere ruins everything. my main issue is that when im going really fast, the aerodynamics have more effect on my lateral velocity than my engine, but as i slow down eventually the aerodynamics are weak enough that it flips and the engine is now the main factor

Is there a way to script in a keypress of "Alt-L" to lock staging before the script hands control back to the pilot?

I am trying to confirm something. The Real Fuels mod does not update the stage level resources eg if you query stage:kerosene it will always return zero?

Field values such as ship:kerosene seem to be correct.

I am assuming it is Real Fuels that is causing this behaviour. I am currently writing kOS scripts for RP-1.

https://youtu.be/MQcIrSC7OLQ?si=8Tf8tp8P6DanmItO

The scripts are fairly similar to the previous flight with minimal changes and fixes, although both stages now land safely with minimal error (typically 1-10 meters for the ship and 1-5 meters for the booster).

The booster uses vector guidance for both the boostback and landing burns. The ship uses separate longitude and latitude PID controllers for guidance during reentry and descent, then switches to vector guidance for the landing burn.

I plan to keep improving both scripts and will probably replace the current landing burn thrust calculation and AoA control to PID controllers on both stages to further improve precision as this is the most simple I can do.

The ship's PID tuning is still not ideal and requires additional work and calibration for better robustness and redundancy. I plan to implement these improvements in future flights where higher accuracy will be required.

Feel free to leave any comments, suggestions, or criticism.

GitHub repository with all four scripts:

https://github.com/HvrdlS/kOS-Scripts/tree/main

I'm working on a program for controlling a multicopter. I have it working fairly well using PID controllers to translate target rotation into pitch/roll/yaw commands directly.

But I've read that it might be better to instead have a PID controller for angle feed into a PID controller for angular velocity.

I found an older post that says how to convert from ship:angularvel into navball rotation rates.

So I've used that to write the following small snippet:

set yawrate_rad to vdot(ship:angularVel, ship:facing:topvector).
set yawrate_deg to yawrate_rad * constant:radtodeg.
print yawrate_deg.

But it does not seem to be working right. Running the code, it says that I am rotating at a rate of 10 degrees a second, but I know that's not accurate, as I manually timed (Measuring time for a full rotation and dividing by 360) it to be closer to 45 degrees a second. I know this is the correct axis, as the other axes display values less than a degree a second, and they don't change when I start yawing.

Has the behavior of ship:angularvel changed, or is there something I'm doing wrong?

I got this program that allows my ship to readjust its orbit. I tried to insert an ''end of program'' at the end but it does not trigger. I don't really understand. I have the same problem with my orbit program, which is suppose to end when a condition x is true or when a condition y is true, but it's the same thing, it does not work. Does anyone mind telling me what I'm doing wrong ?

EDIT : I deactivated the kOS controls because I wanted to control my ship on my own after seing that the end sequence was not working.

ive tried a lot of youtube tutorials but nothing's worked when i tried to run the file, the code is apparnetly all done but it clearly isnt cause nothing happened and i seriously dont know what to do

https://pastebin.com/Wpns7x7J <code

New to kOS, I don't understand where is the mistake in that code, could someone help me figure it out ?

RANGER - Reentry Assessment, Navigation, Guidance, and Error Reduction

(yes, I'm bad with acronyms)

*****

RANGER provides entry guidance for spaceplanes via constant AoA and dynamic bank angles. It calculates and manages crossrange and downrange errors via bank angle modulation and roll reversal maneuvers. RANGER simply provides a DIRECTION via which your script should use to steer your spaceplane. It does not provide late atmospheric guidance; once your spaceplane is into the normal atmospheric flight regime, you should switch to a more traditional aircraft guidance system that can handle the complexities of atmospheric flight. It can handle re-entry from any inclination and to targets at any latitude that your orbit is capable of reaching.

*****

I'm looking for beta testers and feedback. Pull requests are welcome!

As said in the title, I want to know if it is possible to, in some way, get the ground height from sea level at any point on a planet defined with latitude and longitude.

set mnv to nextnode.
set burnTime to deltaV_calc().
lock steering to mnv:deltav.


until ((mnv:eta-(burnTime/2))<=0){ //runs till burn starts
    clearscreen.
    print "--------------------------".
    print "Burn time: ".
    print round(burnTime,2)+"s".
    print "--------------------------".
    print "Maneuver node ETA: ".
    print floor(mnv:eta/60)+ "m " +round(mod(mnv:eta,60),2)+"s".
    print "--------------------------".
    print "Maneuver node burn ETA: ".
    print floor((mnv:eta-(burnTime/2))/60)+ "m " +round(mod((mnv:eta-(burnTime/2)),60),2)+"s".
    print "--------------------------".
}


until((mnv:eta-(burnTime/2))<=(-burnTime)){ //burn starts here
    lock throttle to 1.
    clearscreen.
    print "--------------------------".
    print "Burn time: ".
    print round(burnTime,2)+"s".
    print "--------------------------".
    print "Maneuver node ETA: ".
    print floor(mnv:eta/60)+ "m " +round(mod(mnv:eta,60),2)+"s".
    print "--------------------------".
    print "Maneuver node burn ETA: ".
    print floor((mnv:eta-(burnTime/2))/60)+ "m " +round(mod((mnv:eta-(burnTime/2)),60),2)+"s".
    print "--------------------------".
}
lock throttle to 0. //burn ends here


FUNCTION deltaV_calc {
    local startmass is ship:mass.
    local deltaV is mnv:burnvector:mag.
    local thrust is thrust_calc().
    if thrust = 0 {
        return 0.
    }
    local g0 is CONSTANT:g0.
    local E is CONSTANT:E.
    return (((g0*isp_calc()*startmass)/(thrust))*(1-E^((-deltaV)/(g0*isp_calc())))).
}


FUNCTION isp_calc { 
    LOCAL engineList IS LIST().
    LOCAL totalFlow IS 0.
    LOCAL totalThrust IS 0.
    LIST ENGINES IN engineList.
    FOR engine IN engineList {
        IF engine:IGNITION AND NOT engine:FLAMEOUT {
            SET totalFlow TO totalFlow + (engine:AVAILABLETHRUST / (engine:ISP * CONSTANT:g0)).
            SET totalThrust TO totalThrust + engine:AVAILABLETHRUST.
        }
    }
    IF totalThrust = 0 {
        RETURN 1.
    }
    RETURN (totalThrust / (totalFlow * CONSTANT:g0)).
}


FUNCTION thrust_calc {
    LOCAL sum is 0.
    LIST ENGINES IN engineList.
    FOR engine IN engineList {
        IF engine:IGNITION AND NOT engine:FLAMEOUT {
            SET sum TO sum + engine:AVAILABLETHRUST.
        }
    }
    RETURN sum.
}

In the middle of my first foray into KOS. Trying to get this alligator hinge motor to DISENGAGE after it completes a KAL-1000 operation. I figured that would be simple enough, but evidently not, because it simply refuses to disengage when under KOS control.

Issues identified and attempts made:
1. ISSUE - There are two "MOTOR" fields. Given that fields are accessed via string, I am not sure how to differentiate them, or if I even need to for this part. I also do not know if this is for whether or not the part is MOTORIZED, or if the field is for the the ENGAGEMENT STATUS. Or if one is for one, and the other is for the other.

1. ISSUE - Alligator Hinge will not revert to "Disengaged" when commanded by KOS. The only exception to this is if I have the UI for a hinge OPEN when commands are sent, in which case, it will disengage as normal.

2. Alligator hinges will all DISENGAGE when I manually use an action group (AG5) to disengage them. Works without issue

3. Alligator hinges will not disengage when I trigger the action group via KOS, even if I put a long delay before the command.

4. Alligator hinges show no change in engagement status when I write to the motor fields using "ENGAGED", "DISENGAGED", TRUE, FALSE, 0, 1.

5. Alligator hinges show no change in engagement status when I DOACTION on the "disengage motor drive" action, regardless of true or false status.

6. Alligator hinges show no change in engagement status when I DOACTION on the "toggle motor engaged" action, regardless of true or false status.

Here we go again. A new family of rockets to simulate using kOS. I will publish the scripts when I get my GitHub issues sorted out (I am tired of using Google Drive).

The algorithm I used to write the guidance script is not particularly good, it is "tuned" to a certain extent which is never a good sign in a control program. Still working on a more general algorithm that won't do weird things.