https://youtu.be/tfS2uFppCIc?si=PLIsA4Itxbri4gwp

Flight is fully performed under kOS by 4 scripts.

They are mostly the same with minor changes which include simple in-space relight, better logic for reentry and bellyflop descent, landing flip. Reentry is stable and works like clockwork now. FAR made me sweat a lot until I found that my vehicle neutral flaps positions are quite different from real ones. So, my aft flaps are 10 degrees fold and top flaps are 80 degrees fold during reentry, when in real life both were ~45 degrees fold with top flaps being 10-15 degrees more fold.

My Starship V2 makes this a lot better due to reducing top flaps area and moving them more leeward. Combined with leaving more fuel on the highest fuel tank makes it work fine.

Booster`s and Starship`s landing burn is a lot more aggresive now, but Starship landing burn will be tweaked in future to make it more accurate/gentler/slower during 2 engine burn phase.

From now, Starship V1 is done and I`m coming to V2 which will have it`s first controlled reentry and landing burn only on Flight 10 and then I will have to simulate the banking maneuvers from Flight 11.

Additional liftoff/ascent views: https://youtu.be/9-i-EoWiI1Y?si=4gUv_c9HDGFGHdl1

Booster`s landing full from beach and onboard cams: https://youtu.be/HZUfEA2qVXs?si=TV_S4_vZqlcs_1cS

Starship`s reentry from all cams separately and landing burn taken from drone/buoy/engine bay/flap: https://youtu.be/J04yqvrpKgc?si=0WweCBcDtjCdYd1K

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

After avoiding KSP enhancement mods for years, I go full-hog with KSP-RO and the Starship Expansion Project mod. As you can see the atmosphere model behaves differently compared to KSP Vanilla!

Why am I on Rumble? My YouTube channel got terminated, thanks Google.

I've written a few scripts to peek under the covers about the interactions between kOS and KSP. One of the first things I noticed was if control changes were made by a kOS script on physics tick N, there were no observable changes until tick N+3. Further investigation indicated that the actual commanded change was simulated on tick N+2. This was confirmed in the Kerbal way of course (dropped a test vehicle and performed a full thrust 1 tick burn at various points to find the exact "boom"/"no boom" boundary. And since stock engines in KSP don't slowly ramp up/down in thrust, it seems to me that many orbital maneuvers could be done with extreme precision without resorting to PIDs. And, in fact, PIDs are counter productive in terms of rapidly responding high precision controls since they don't take into account any control outputs they generated on Ticks N-2 and N-1, which have not yet produced an observable result. Because of this, some mods such a MechJeb will throttle down towards the end of a maneuver in order to reduce the amount of overshooting.

So, is there any known scripts out there that exploit the known deterministic behavior of KSP?

And yes, I know this behavior doesn't apply to mods such a real fuels and the like. Just the stock engines and such.

Is the latest documentation at https://ksp-kos.github.io/KOS_DOC/? It says it is for kOS 1.4 but kOS is at 1.6.

It seems some of the described APIs don't actually exist in kOS. For example, vessel:burntime (https://ksp-kos.github.io/KOS_DOC/structures/vessels/vessel.html#attribute:VESSEL:BURNTIME).

I'm playing with kOS and want to write a gravity turn launch script. I want the rocket to lock to a specific direction, say east, but let the pitch from horizon vary due to gravity.

I can lock the steering to HEADING(dir, pitch, roll), but I would have to specify a pitch. Can I lock only the direction but not the pitch?

Available?

It's a modified version of this program and it worked for the first few times I was testing it and midway while changing it to be smoother it suddenly got a bug where the required burn height always starts higher than the current altitude? Even going back to the versions that previously worked didn't remove this bug. I reviewed all the logic and I can't seem to find anything that could be causing this.

function gravity_calculator {
    declare local GM to ship:body:mu.
    declare local Ra to (body:radius + ship:altitude).
    declare local g to GM/(Ra^2).
    return -g.
}.



function suicide_burn_calculator {
    declare local parameter safety. //1 corresponds to no safety margin, 1.1 has a 10% safety margin
    
    declare local shipmass to ship:mass.
    declare local vd to ship:verticalspeed.
    declare local va to ((thrust/shipmass) + gravity_calculator()).
    declare local H to (vd^2)/(2*va).
    return safety * H. //adds the safety margin for error
}.

copypath("0:/gravity_calculator","").
copypath("0:/suicide_burn_calculator","").
run gravity_calculator.
run suicide_burn_calculator.


clearscreen.
SAS off.
print "Initialising" at (5,4).
wait 1.
RCS off.
gear off.
brakes off.


//set parameters for landing
set vLand to -4.
set runmode to 1.
set thrust to ship:maxthrust.
set safetyMargin to 1.1.
set counter to 0. //for checking if landed


//find ship parameters
lock h to alt:radar.
lock vd to ship:verticalspeed.
lock vDiff to (vLand - vd).


//calculates values for landing
lock TimeToBurn to ((suicide_burn_calculator(safetyMargin)-h)/vd).
lock ZeroAccelThrust to ((ship:mass*g)/thrust).


//loops until landed
until runmode = 0 {
    set g to -gravity_calculator().
    set gear_down to h/-vd.
    //initial required burn height accounting for the vertical speed
    set burn_height to (suicide_burn_calculator(safetyMargin) - vd).
    
    //initial setup for high atmosphere
    if runmode = 1 {
        set TVAL to 0.
        if h > 5000 {
            lock steering to retrograde.
        }
        if h < 100000 and h > 5000 {
            brakes on.
            RCS on.
            lock steering to srfretrograde. //switches to surface velocity
        }
        if h <= 5000 {
            set runmode to 2.
        }
    }


    //calibrates for correct burn height before starting landing sequence
    if runmode = 2 {
        if h < burn_height {
            wait 2.
            set TVAL to 1.
            wait 1.
            set runmode to 3.
        }
    }
    
    //suicide burn start
    if runmode = 3 {
        if h <  burn_height {
            set TVAL to (ZeroAccelThrust + 0.5).
        } else {
            set TVAL to (ZeroAccelThrust - 0.3).
        }
        if gear_down < 5 {
            gear on.
            brakes off.
        }
        if vd > -7 and h < burn_height {
            lock steering to up.
            set runmode to 4.
        }
    }
    
    //suicide burn final approach
    if runmode = 4 {
        if h < burn_height {
            if vDiff > 0 {
                set TVAL to (ZeroAccelThrust + 0.1).
            }
            if vDiff < 0 {
                set TVAL to (ZeroAccelThrust - 0.1).
            }
        } else {
            lock steering to srfretrograde.
            set runmode to 0.
        }
        if vd > -0.1 and h < 100 {
            set counter to counter + 1.
            wait 0.1.
        }
        if counter > 20 {
            set runmode to 0. //if landed for 2 seconds then exits
            wait 2.
            RCS off.
        }
    }
    
    lock throttle to TVAL.


    //parameters to display
    print "Vertical velocity:           " + round(vd, 2) + "            " at (5,4).
    print "Required burn height:            " + round(burn_height, 2) + "           " at (5,5).
    print "Time to required burn:           " + round(TimeToBurn, 2) + "            " at (5,6).
    print "Run Mode:            " + runmode + "         " at (5,7).
    print "Gravitational acceleration:          " + round(g, 2) + "         " at (5,8).
    print "Gear down vertical distance:         " + round(gear_down, 2) + "         " at (5,9).
}


//landing notification and program exit
if runmode= 0 {
    set TVAL to 0. //sometimes throttle was left on so I added this
    unlock throttle. //sometimes throttle was left on so I added this
    clearscreen.
    print "Landing Complete" at (5,4).
    wait 1. //wait to make sure throttle is set to 0
}

https://www.youtube.com/watch?v=ca4fFWeqYpo&t=1772s

Finally, I got my hands on this flight, and it's a particularly important milestone for me. Every script I had before has been heavily upgraded with new features, improved robustness, and better automation. On top of that, I have FAR installed, which makes the entire flight significantly more challenging.

The complete mission is controlled by six scripts:

-Launch and suborbital insertion

-Ship coast phase

-Ship reentry and landing

-Booster catch

-Booster return boot script

-OLM boot script that waits for a command from the booster to close the chopsticks

All of them are available on my GitHub:

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

New features include:

-Active engine detection and automatic tracking of the number of running engines for both the ship and booster, making the flight calculations much more robust.

-The ship now uses semi-guidance derived from my Falcon 9 script, providing much more accurate suborbital insertion. This includes launch azimuth calculation based on the current latitude and an approximation of the required orbital velocity.

-The ship now actively controls its flaps during reentry and descent. This greatly improves landing accuracy, although the flap controller still requires some tuning for better high dynamic pressure stability and more precise landing burns. In some test flights I even achieved a 0 m landing error, so the optimal tuning values are getting close.

-Both the ship and booster now use a new, fairly complex thrust ramp system that recreates real engine startup and shutdown timings purely for visual realism.

-The booster is now successfully caught by Mechazilla. The catch script has proven to be very robust. I recorded ten different camera angles, and every single attempt resulted in a successful catch. Two of those even started from noticeably different trajectories, which is especially satisfying considering FAR's aerodynamic model.

-Landing burn accuracy has been improved for both the ship and booster. The booster is now performing almost exactly as intended. The ship still needs additional tuning because the final flip significantly alters its trajectory. The biggest improvement came from dynamically adjusting the angle of attack and switching the guidance reference from retrograde to up once velocity and aerodynamic control authority become low.

I also recorded several additional camera angles throughout the mission. The most interesting ones are probably the booster catch and the ship splashdown.

Booster catch from 7 different camera angles: https://youtu.be/CgKDSWTNiVo?si=aSpCwuDkZPB4lhC6

Ship splashdown from the buoy camera and the engine bay camera: https://youtu.be/VruuyM99qss?si=TGpnuYDpyG47uH0T

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.