Release KontrolSystem2 (0.4.2)

[appenz]

Recently jumped back into writing code with Kontrolsystem2 and re-tested to previous bugs:

• The "stuck on rebooting" issue is fixed in 0.4.3. 
• The "invalid stack" seems to have disappeared.

I now have a fully automated Mun mission including the return to Kerbin with aerocapture working. 
Great work, thank you!

[appenz]

I wrote a KontrolSystem2 script for a fully automated mission to the Mun and back to Kerbin. Details:

• Requires a rocket with enough delta V for the trip
• Gravity turn isn't optimal, but works pretty well for most craft
• Methods to circularize and adjust inclination
• Transfer planning within the Kerbin system
• Breaking for orbital capture around the Mun
• Landing on the Mun is at a pretty steep angle, and could be more efficient
• It always uses a specific landing spot that is a flat area and usually lands with < 1m accuracy
• Takeoff from the Mun, circularize and fairly optimal ejection burn
• Uses aerocapture, if necessary with multiple orbits
• Checks parachutes for safe opening

The script uses none of the higher-level TO2 functions, it was more fun to re-implement everything myself. Coding style is a bit different from Untoldwind's. I try to be as object oriented as possible and when in doubt err on the side of readability of code, so expect code to be a lot less compact. 

Source code on GitHub here:  https://github.com/appenz/kerbal2

Critique, Enhancement, Pull-requests or any other Feedback is highly welcome.

[Soda Popinski]

Got kinda busy, but getting back into KSP2 post patch.  I fired it up, but got a bunch of errors from KS2.  I'm guessing the code has changed somewhat.

First thing I'm trying to do, is figure out how to get the type of resources in a part.  Previously, parts had parts.resources, so for example, I could determine which are the fuel tanks and could do resource transfers.

Specifically, I have a function that shifts the center of mass by pumping fuel forward or backward.  So it needs to determine which the subset of fuel tanks forward and rearward.

[Jhaxxar]

Latest Version still sav V0.4.3 not V0.4.4.  As result it does not function under KSP2 V1.5.0.

 

[Soda Popinski]

On 9/4/2023 at 11:18 PM, Soda Popinski said:

Got kinda busy, but getting back into KSP2 post patch.  I fired it up, but got a bunch of errors from KS2.  I'm guessing the code has changed somewhat.

First thing I'm trying to do, is figure out how to get the type of resources in a part.  Previously, parts had parts.resources, so for example, I could determine which are the fuel tanks and could do resource transfers.

Specifically, I have a function that shifts the center of mass by pumping fuel forward or backward.  So it needs to determine which the subset of fuel tanks forward and rearward.

Looks like it's fixed with today's update.

 

Glad to see the mod is still in active development!

[AndyMt]

On 8/19/2023 at 6:24 AM, appenz said:

wrote a KontrolSystem2 script for a fully automated mission to the Mun and back to Kerbin.

Used it the last few days, very impressive! Had to build my craft so staging didn't get in the way for landing...

I noticed the initial launch/ascent could be more efficient. So I implemented a different gravity turn function which uses the throttle to keep the apoapsis always at a certain value (50s works well). This method saves around 200m/s dv. I maintained the GravityTurn mod for KSP1 a few years back, so I didn't have to start from scratch.

I have to clean up the code and make it more robust, but then I'll create a pull request.

Edited December 27, 2023 by AndyMt

[AndyMt]

@Untoldwind

I'm trying to improve my gravity turn script I mentioned above. For this I need the current vessel pitch in degrees. Maybe I'm overlooking something, but apart from heading_roll_pitch() which returns a vector, not angels, I haven't found anything. Tried to convert that with to_direction(), but the result is totally off from what I expect. Get 288 instead of 90 degrees... Any hints?

[AndyMt]

Another one: I have difficulty to force the craft to roll to a certain angle. The parameter in  vessel.heading_direction() doesn't do anything:

vessel.autopilot.target_orientation = vessel.heading_direction(heading, -pitch, -90).vector

The craft just doesn't roll at all. Do I miss something here? I could use vessel.override_input_roll(), but then I would have to know how much the craft rolled. And I can't find anything to get that information - same with pitch and yaw. With vessel.pitch_yaw_roll() I get some vector, but when I convert this into a Direction type (with to_direction()) the values don't make sense. Well - when the navball changes to "orbit", then they make sense, but not before during a launch...

[AndyMt]

I have published my gravity turn script as part of an update to @appenzs scripts on my Github:

https://github.com/AndyMt/kerbal2/tree/master (PR crated, too)

Use the mission::gravity_turn entry point. It provides a basic UI to tweak the launch parameters. But the suggestions should work with crafts that have a twr between 1.2 and 2.0

[Soda Popinski]

15 hours ago, AndyMt said:

Another one: I have difficulty to force the craft to roll to a certain angle. The parameter in  vessel.heading_direction() doesn't do anything:

vessel.autopilot.target_orientation = vessel.heading_direction(heading, -pitch, -90).vector

The craft just doesn't roll at all. Do I miss something here? I could use vessel.override_input_roll(), but then I would have to know how much the craft rolled. And I can't find anything to get that information - same with pitch and yaw. With vessel.pitch_yaw_roll() I get some vector, but when I convert this into a Direction type (with to_direction()) the values don't make sense. Well - when the navball changes to "orbit", then they make sense, but not before during a launch...

I highly recommend posting these in the Issues section of the GitHub.  Two of the last 3 releases seemed to be fixes to bugs I found and posted there, typically within a day.

That said, I think the problem is you're giving a vector as a direction.  Vectors really only do pitch and heading, but don't include roll.  Same as in kOS.

I'm not sure the difference, but what works for me is:
vessel.autopilot.lock_direction = vessel.heading_direction(heading_SP, pitch_SP, roll_SP)

Edited December 30, 2023 by Soda Popinski

[Raabs]

Hey guys, 

I was wondering whether anyone has been able to create a code with the ability to do accurate hoverslams/suicide burns at the KSC, and would be willing to share the code for it as well? I don’t actually know how to code, which is why I ask.

[DimiBD]

Hi,

How do you use the code done by @appenz ?

Kontrol system was not able to start with ...

I'd like to try to do some scripts, but if I'm not capable to simply use one, it will be hard ^^

Thx ;)

 

[AndyMt]

My fork on Github contains some bugfixes to all scripts, so they work with the latest version of Kontrol System. Just follow the link above and download my code.

[DimiBD]

11 hours ago, AndyMt said:

My fork on Github contains some bugfixes to all scripts, so they work with the latest version of Kontrol System. Just follow the link above and download my code.

thx

I can play with now...

VScode plugin is very helpful

[AndyMt]

On 12/30/2023 at 6:29 AM, Soda Popinski said:

vessel.autopilot.lock_direction = vessel.heading_direction(heading_SP, pitch_SP, roll_SP)

This doesn't roll the craft, unfortunately. It just does nothing. I think I have to use override_roll(), but then I need a reliably way to know the current roll (and pitch). I haven't found anything for that either...

[appenz]

I fixed the exponentiation notation issue in my repo as well. Latest code on GitHub here. This is tested against 0.2.0.0 and seems to work mostly fine up to geting into orbit with all vessels that I tested. The transfer burn to Mun seems to need some tweaking for some ships. 

Thanks to @AndyMt for pointing this out and awesome to see that anyone is actually trying out this code.

I haven't tried out Andy's new gravity turn code yet, but it looks super promising.

[DimiBD]

5 hours ago, appenz said:

I fixed the exponentiation notation issue in my repo as well. Latest code on GitHub here. This is tested against 0.2.0.0 and seems to work mostly fine up to geting into orbit with all vessels that I tested. The transfer burn to Mun seems to need some tweaking for some ships. 

Thanks to @AndyMt for pointing this out and awesome to see that anyone is actually trying out this code.

I haven't tried out Andy's new gravity turn code yet, but it looks super promising.

I just change the landing site to the monument, and it's just crash on it . (just a probe ^^)

I'll try with Minmus

[appenz]

10 hours ago, DimiBD said:

I just change the landing site to the monument, and it's just crash on it . (just a probe ^^)

I'll try with Minmus

Awesome! Was it an intentional crash, or did the landing algorithm not brake correctly? If it was an unintentional crash I'd love to know to craft so I can debug. It's really hard to write code that works with any space craft.

[DimiBD]

On 1/3/2024 at 6:56 PM, appenz said:

Awesome! Was it an intentional crash, or did the landing algorithm not brake correctly? If it was an unintentional crash I'd love to know to craft so I can debug. It's really hard to write code that works with any space craft.

It was not intended ^^

I try to go to minmus (from a circular orbit in the same plan). 

For now, i have a issue with the planransfert. It's too "short". I try to compare it with the intercept from the basic .to2

I'm not used to do this sort of math so first i have to understand ... i make go and back from the docs and the scripts

[Soda Popinski]

On 12/31/2023 at 8:12 AM, AndyMt said:

This doesn't roll the craft, unfortunately. It just does nothing. I think I have to use override_roll(), but then I need a reliably way to know the current roll (and pitch). I haven't found anything for that either...

Weird.  Make sure Autopilot is enabled and Steering Manager is released.

 

As far as how to get roll, I know I got it in kOS using the vector angle function using the right vessel vector and some vector math with the North and East vectors.  It's been a while, I'll see what I did when I get home.

[AndyMt]

I figured it out meanwhile: the autopilot has to be set to stability assist and not to autopilot or prograde. Not sure about the directions and reference coordinate system. There as you pointed out some vector math is required. But as I roll during the upright phase before pitching over, it's not really relevant.

[appenz]

On 1/5/2024 at 12:28 AM, DimiBD said:

It was not intended ^^

I try to go to minmus (from a circular orbit in the same plan). 

For now, i have a issue with the planransfert. It's too "short". I try to compare it with the intercept from the basic .to2

I'm not used to do this sort of math so first i have to understand ... i make go and back from the docs and the scripts

I am also seeing the interplanetary transfer coming up short. In the past this was necessary in order to not overshoot, but it looks like something changed. There is a parameter to adjust this, so it should be easy to fix. In the file go-mun.to2, change the parameter from 0.6 to something bigger. See the t.planTransfer() line below:

// We made it to Orbit, are we still around Kerbin
    if (vessel.orbit.reference_body.name == "Kerbin" && vessel.orbit.apoapsis.defined && vessel.orbit.apoapsis.value < 5000000) {
        const t = Transfer()
        t.planTransfer(mission,"Mun", 0.6)   // <-- Edit this parameter
        const n = t.getTransferNode()
        mission.addManeuver(n)
        mission.burnNextNode()
        con.log("  ejection burn complete.")
    }

Now @Untoldwind just dropped code that can gives access to the trajectory after the maneuver node (see here). Haven't tried it out yet, but this should allow us to do a gradient-descent type calculation for the entire trajectory. That will be much more reliable.

On 1/5/2024 at 1:34 PM, AndyMt said:

I figured it out meanwhile: the autopilot has to be set to stability assist and not to autopilot or prograde. Not sure about the directions and reference coordinate system. There as you pointed out some vector math is required. But as I roll during the upright phase before pitching over, it's not really relevant.

Yes, I found this out the hard way as well.

[DimiBD]

15 minutes ago, appenz said:

I am also seeing the interplanetary transfer coming up short. In the past this was necessary in order to not overshoot, but it looks like something changed. There is a parameter to adjust this, so it should be easy to fix. In the file go-mun.to2, change the parameter from 0.6 to something bigger. See the t.planTransfer() line below:

// We made it to Orbit, are we still around Kerbin
    if (vessel.orbit.reference_body.name == "Kerbin" && vessel.orbit.apoapsis.defined && vessel.orbit.apoapsis.value < 5000000) {
        const t = Transfer()
        t.planTransfer(mission,"Mun", 0.6)   // <-- Edit this parameter
        const n = t.getTransferNode()
        mission.addManeuver(n)
        mission.burnNextNode()
        con.log("  ejection burn complete.")
    }

Now @Untoldwind just dropped code that can gives access to the trajectory after the maneuver node (see here). Haven't tried it out yet, but this should allow us to do a gradient-descent type calculation for the entire trajectory. That will be much more reliable.

Yes, I found this out the hard way as well.

yep, i see the soi_adjust, but even at 1, I do not see anything better

 

        const t = Transfer()

        t.planTransfer(mission,"Minmus", 1)

        const n = t.getTransferNode()

        mission.addManeuver(n)

        mission.burnNextNode()

[appenz]

2 hours ago, DimiBD said:

yep, i see the soi_adjust, but even at 1, I do not see anything better

Alright, I'll try to fix this week. Tracking it as a bug on GitHub here.

[appenz]

On 1/8/2024 at 11:22 AM, appenz said:

Alright, I'll try to fix this week. Tracking it as a bug on GitHub here.

@DimiBD I think I fixed it, at least for a Mun transfer it works again. There were basically two issues:

1. Bugs in how I calculate the transfer altitude (i.e. the highest point of the new orbit that should be inside the Sphere of influence of the target body.
2. My maneuver node burn isn't nearly as precise as I want it to be.

I fixed (1) but (2) may still be an issue if you have a craft that stages during the transfer burn. The planTransfer() function no directly takes a target altitude. I would set it to something that's high, but not close to the SOI. So maybe 10% of the SOI is safe.

Let me know if this gets you to Minimums. I didn't test that

 

On 12/30/2023 at 1:01 AM, Raabs said:

Hey guys, 

I was wondering whether anyone has been able to create a code with the ability to do accurate hoverslams/suicide burns at the KSC, and would be willing to share the code for it as well? I don’t actually know how to code, which is why I ask.

I know this is a bit late, but I code for this here on GitHub. The basic idea is:

1. Check if we are landed at KSP, if yes fly up 2,000m
2. Land on one of the landing pads

Basic logic of the code is that it constantly calculates the dV between the desired trajectory and the actual one and tries to correct it. While we are well ahead of time when we'd have to start a suicide burn it corrects only horizontally. As it gets close to the suicide burn time we add vertical breaking. Works for a decent variety of vessels for me.