[1.8.x to 1.12.x] kRPC: Remote Procedure Call Server (v0.5.1, 2nd March 2023)

[sashan]

Can you add aerodynamic moment simulation? I need to check AoAs I'll be able to fly at when calculating ascent trajectory. Would be best if it worked with FAR.
I must admit this mod is so amazing it made me install KSP again after 2 years without it. FInally I can unleash true power of engineering and write off that old mk2 eyeball.

Edited November 7, 2017 by sashan

[djungelorm]

On 05/11/2017 at 8:04 PM, sashan said:

Can you add aerodynamic moment simulation? I need to check AoAs I'll be able to fly at when calculating ascent trajectory. Would be best if it worked with FAR.
I must admit this mod is so amazing it made me install KSP again after 2 years without it. FInally I can unleash true power of engineering and write off that old mk2 eyeball.

Sure thing! Have added a ticket on github: https://github.com/krpc/krpc/issues/429

[sashan]

Ah, thanks. 
I have a couple more questions.

What does exactly available_torque return? It looks like this: ((5662.55247592926, 2019.308090209961, 1881.891991943121), (5946.8719363212585, 2019.308090209961, 1908.4728211164474)). Those small tuples are torques around y/p/r axes respectively, but in which units? Also, as far as I understand, first 3 values are max torques in negative directions, second ones are in positive? 

Also, I suppose available_control_surface_torque doesn't work with FAR. Thus, we get back to that simulation I've mentioned, except that it would need to work with pitch/roll/yaw control surface setting parameter. Like in FAR coefficients window but with all 3 axes.

Thing is, I'm designing a controller that would always be able to steer a rocket in stable way, and to do that I want to know a vehicle's dynamics.

[Ericwi]

Does the mechjeb addin still work under 1.3.1? Everytime I put it in Krpc does not load. No error or anything.

[djungelorm]

On 09/11/2017 at 10:46 PM, sashan said:

Ah, thanks. 
I have a couple more questions.

What does exactly available_torque return? It looks like this: ((5662.55247592926, 2019.308090209961, 1881.891991943121), (5946.8719363212585, 2019.308090209961, 1908.4728211164474)). Those small tuples are torques around y/p/r axes respectively, but in which units? Also, as far as I understand, first 3 values are max torques in negative directions, second ones are in positive? 

Also, I suppose available_control_surface_torque doesn't work with FAR. Thus, we get back to that simulation I've mentioned, except that it would need to work with pitch/roll/yaw control surface setting parameter. Like in FAR coefficients window but with all 3 axes.

Thing is, I'm designing a controller that would always be able to steer a rocket in stable way, and to do that I want to know a vehicle's dynamics.

Sorry I was a bit busy recently so slow to get back to you...

Re. available_torque sorry the docs aren't very clear. It returns two tuples - the first is for the positive control direction, and the second for the negative control direction. Each one denotes the magnitude of the available torque around the roll, pitch and yaw axes of the vessel as the three components of the vector in that order. The units are Newton meters.

I think available_control_surface_torque does work with FAR - as kRPC gets this information via ITorqueProvider which FAR should set. I haven't tested this though.

Also, there is a bug with RCS torque which makes available_rcs_torque return garbage (and would also cause available_torque to return garbage if RCS is enabled). This bug has been around for ages but the KSP devs don't seem inclined to fix it or even respond on the bug tracker....

https://bugs.kerbalspaceprogram.com/issues/13547

https://bugs.kerbalspaceprogram.com/issues/15962

On 23/11/2017 at 7:55 PM, Ericwi said:

Does the mechjeb addin still work under 1.3.1? Everytime I put it in Krpc does not load. No error or anything.

I don't think it's been updated for 1.3.1 yet.

[djungelorm]

On 23/11/2017 at 7:55 PM, Ericwi said:

Does the mechjeb addin still work under 1.3.1? Everytime I put it in Krpc does not load. No error or anything.

I recompiled krpcmj against the 1.3.1 DLLs and got loads of errors about invalid identifiers, as the naming requirements for methods are strictly enforced in kRPC 0.4.

I've made a pull request against the krpcmj project to fix this: https://github.com/artwhaley/krpcmj/pull/4 Building that against the 1.3.1 DLLs should work.

[foxtrot1911]

Is there a way i can use the 0.4.0 in ksp 1.2.2? I play with RSS/RO/RP-0, so i'm not able to use the newer ksp versions.

And thank you for putting your time into this!

[djungelorm]

On 06/12/2017 at 1:08 AM, foxtrot1911 said:

Is there a way i can use the 0.4.0 in ksp 1.2.2? I play with RSS/RO/RP-0, so i'm not able to use the newer ksp versions.

And thank you for putting your time into this!

Looks like the only thing preventing this is an incompatible change made to the KSP API for spawning popup dialogs. I could change the kRPC plugin code to use reflection to create popups, so that the plugin can work with both KSP 1.2.2 and 1.3.1. kRPC doesn't spawn popups very often so using reflection would not affect performance etc etc. I'll try and get this into the next release hopefully in the next week or so.

[djungelorm]

In case you can't wait for a fully tested version - you can try this: https://www.dropbox.com/s/ey9nq2hxxgg2v60/krpc-0.4.2-KSP-1.2.2.zip?dl=0

I changed the popup dialog calls to fix the API incompatibility, and recompiled against the 1.2.2 dlls.

[foxtrot1911]

9 hours ago, djungelorm said:

In case you can't wait for a fully tested version - you can try this: https://www.dropbox.com/s/ey9nq2hxxgg2v60/krpc-0.4.2-KSP-1.2.2.zip?dl=0

I changed the popup dialog calls to fix the API incompatibility, and recompiled against the 1.2.2 dlls.

Everything working fine for the tests i've made. Thank you! I'll share with RSS/RO players in case anyone want to use too.

[sashan]

Would that 1.2.2 version also work on 1.3? I am sticking with 1.3 because a bunch of mods are still not updated.
Latest release doesn't work. Pops up an "incompatible" message. And those changes like ray cast are really important for me.

Also, is there some way to interface with mods like Trajectories? I need to predict my landing (or crash?) location but code like that isn't easy to implement myself.

Edited December 9, 2017 by sashan

[djungelorm]

The zip I posted only works in KSP 1.2.2 but it is functionally equivalent to the latest version released through github, can etc, which should work with KSP 1.3.0 or 1.3.1

I don't think the trajectories mod can currently be accessed through kRPC as it's a partless mod. I'll have a look into exposing it's functionality through the server.

[sashan]

Latest doesn't work in 1.3.0. "Incompatible" message and either CTD or nothing happening when trying to enable server. I don't remember exactly.

[blakemw]

I'm a new user to kRPC with KSP 1.3.1, using python client (0.4.2), I got the Launch to Orbit script from the tutorial working except for one part:

# Orientate ship
print('Orientating ship for circularization burn')
vessel.auto_pilot.reference_frame = node.reference_frame
vessel.auto_pilot.target_direction = (0, 1, 0)
vessel.auto_pilot.wait()

The autopilot fails to point the ship at the node. It just does nothing.

 

I decided to try it the naive way I'd normally do it in-game and replaced it with this code which did work:

vessel.auto_pilot.disengage()
vessel.auto_pilot.sas = True
time.sleep(0.1)
vessel.auto_pilot.sas_mode = vessel.auto_pilot.sas_mode.maneuver
vessel.auto_pilot.wait()

I'm not sure why I had to disengage the autopilot, but as long as it was engaged then SAS would refuse to stay on. Also the documentation says auto_pilot.wait() will throw an exception if used while the auto_pilot is disengaged, but it does work if SAS has a target.

Anyway I'm very happy with my script and don't need help per-se, I'm just puzzled that the tutorial code doesn't work.

Edited December 11, 2017 by blakemw

[djungelorm]

On 09/12/2017 at 11:07 PM, sashan said:

Latest doesn't work in 1.3.0. "Incompatible" message and either CTD or nothing happening when trying to enable server. I don't remember exactly.

The incompatible message was due to the comptibility checker not knowing any better. Apart from that it should work. I just released v0.4.3 which should work in KSP versions 1.2.2, 1.3.0 and 1.3.1

[djungelorm]

On 11/12/2017 at 8:29 PM, blakemw said:

I'm a new user to kRPC with KSP 1.3.1, using python client (0.4.2), I got the Launch to Orbit script from the tutorial working except for one part:

# Orientate ship
print('Orientating ship for circularization burn')
vessel.auto_pilot.reference_frame = node.reference_frame
vessel.auto_pilot.target_direction = (0, 1, 0)
vessel.auto_pilot.wait()

The autopilot fails to point the ship at the node. It just does nothing.

 

I decided to try it the naive way I'd normally do it in-game and replaced it with this code which did work:

vessel.auto_pilot.disengage()
vessel.auto_pilot.sas = True
time.sleep(0.1)
vessel.auto_pilot.sas_mode = vessel.auto_pilot.sas_mode.maneuver
vessel.auto_pilot.wait()

I'm not sure why I had to disengage the autopilot, but as long as it was engaged then SAS would refuse to stay on. Also the documentation says auto_pilot.wait() will throw an exception if used while the auto_pilot is disengaged, but it does work if SAS has a target.

Anyway I'm very happy with my script and don't need help per-se, I'm just puzzled that the tutorial code doesn't work.

kRPC's autopilot overrides SAS - it will forcibly turn it off if enabled. This is because SAS would interfere with the autopilots operation - it doesn't really make sense to have both of them turned on.

The documentation isn't quite correct about ap.wait(), sorry! It will work when either SAS is enabled or the autopilot is engaged. With SAS in stability mode I think wait() will just return immediately as SAS doesn't have a target direction, so the "error" is zero.

I just ran the tutorial code myself and it worked fine - so not sure what's up there! Potentially just KSP being buggy as usual...

[blakemw]

I think I actually just figured it out. I wasn't running the tutorial with the provided craft and instead with one of my own vessels. This vessel is a fairly  bog-standard SSTO Twin-Boar rocket with 2 orange tanks and some stuff on top and a 1.25m reaction wheel. What I think is happening is the Autopilot thinks there isn't enough reaction control and simply refuses to even try to rotate the vessel, possibly running into the "When the available angular acceleration is zero" corner case but I'm not sure about that I guess it could also be the calculations just work out to zero. This vessel takes around 20s to rotate 90 degrees under the stock SAS so I wouldn't consider it chronically under-torqued, but by adding more reaction wheels the autopilot will rotate it.

It also turns out I can make the autopilot rotate the vessel by raising "stopping_time", set to a higher value and the auto_pilot will apply the full power of the reaction wheels and successfully rotate the vessel.

It seems on the whole the autopilot defaults work well for atmospheric use but poorly in microgravity - particularly when compared with the stock SAS direction holds that rotate the vessel using full power as optimal. While in the original case I was using a large vessel, the autopilot also just seems very sluggish when rotating normal vessels, altough as I gradually make more sense of the tuning parameters I can make it work better.

It seems to me it should be possible to autotune the autotune based on the vessels moment_of_inertia and available_torque, the defaults seem to assume a high torque as is the case when thrust vectoring and control surfaces are available and that's why they work poorly when only the low torque of reaction wheels is available.

Edited December 13, 2017 by blakemw

[Shimuuar]

I wonder do any client make use of new ability to batch independent requests which appeared in 0.4 versions of KRPC? Quick inspection of C++ and python clients suggests that they don't do this.

[mcortez]

I know this isn't strictly kRPC related, but more orbital mechanics - but was hoping someone would take pity on someone that hasn't dealt with spherical math in 22 years.  I'm using kRPC, C# client, and am working on a program to change my LAN and Inclination to match that of a Targeted Celestial Body that's orbiting the same Celestial Body as my Active Vessel.  As a warm up, I worked on zero'ing out my ships inclination in preparation for changing my orbit to match my target's.  And I was able to get that working with something along the lines of:

var ksc = conn.SpaceCenter();
var vessel = ksc.ActiveVessel;
var orb = vessel.Orbit;

// Calculate the True Anomoly of AN and DN
double taAN = (2*Math.PI) - orb.ArgumentOfPeriapsis;

// Inclination change needed
double incChange = -orb.Inclination;

// Calculate node values
double eta = orb.UTAtTrueAnomaly(taAN);
double dv = (2 * orb.OrbitalSpeedAt(eta)) * Math.Sin(incChange / 2);

// Split the DV change across normal and prograde
double normalDV = Math.Cos(incChange / 2) * dv;
double progradDV = -Math.Abs((Math.Sin(incChange / 2) * dv));

vessel.Control.AddNode(eta, (float)progradDV, (float)normalDV, 0);

 

My problem now is that I need to know the True Anomaly along my orbit for the Ascending Node for my Target (or more specifically, just the UT of when I'll reach the AN.)  If my target was a vessel, I could just use the following and call it a day:

taAN = orb.TrueAnomalyAtAN(targetVessel);
incChange = orb.RelativeInclination(targetVessel);

 

But after several hours banging my head against the kRPC API docs for Orbit, and Robert Braeunig's orbital mechanics pages, and trying to convert some old kOS code I had that did the same thing ( originally based on the code from here ) - I've found a very large number of ways to not find my the needed values.

At this point I suspect I'm missing something simple.

 

[artwhaley]

2 hours ago, mcortez said:

I know this isn't strictly kRPC related, but more orbital mechanics - but was hoping someone would take pity on someone that hasn't dealt with spherical math in 22 years.  I'm using kRPC, C# client, and am working on a program to change my LAN and Inclination to match that of a Targeted Celestial Body that's orbiting the same Celestial Body as my Active Vessel.  As a warm up, I worked on zero'ing out my ships inclination in preparation for changing my orbit to match my target's.  And I was able to get that working with something along the lines of:

var ksc = conn.SpaceCenter();
var vessel = ksc.ActiveVessel;
var orb = vessel.Orbit;

// Calculate the True Anomoly of AN and DN
double taAN = (2*Math.PI) - orb.ArgumentOfPeriapsis;

// Inclination change needed
double incChange = -orb.Inclination;

// Calculate node values
double eta = orb.UTAtTrueAnomaly(taAN);
double dv = (2 * orb.OrbitalSpeedAt(eta)) * Math.Sin(incChange / 2);

// Split the DV change across normal and prograde
double normalDV = Math.Cos(incChange / 2) * dv;
double progradDV = -Math.Abs((Math.Sin(incChange / 2) * dv));

vessel.Control.AddNode(eta, (float)progradDV, (float)normalDV, 0);

 

My problem now is that I need to know the True Anomaly along my orbit for the Ascending Node for my Target (or more specifically, just the UT of when I'll reach the AN.)  If my target was a vessel, I could just use the following and call it a day:

taAN = orb.TrueAnomalyAtAN(targetVessel);
incChange = orb.RelativeInclination(targetVessel);

 

But after several hours banging my head against the kRPC API docs for Orbit, and Robert Braeunig's orbital mechanics pages, and trying to convert some old kOS code I had that did the same thing ( originally based on the code from here ) - I've found a very large number of ways to not find my the needed values.

At this point I suspect I'm missing something simple.

 

Crap.  This might be me.  I think I added those bits to the orbit class, and I wasn't being imaginative enough to come up situations where it wouldn't be a vessel.  Unfortunately, I think I cheated and used an API shortcut to get those numbers, so even looking at the C# code for those methods in the orbit class won't help you figure out how to derive it by hand.   And off the top of my head I can't remember whether anything in that shortcut would make it possible or impossible to adapt the same method to celestial objects...   

I'm buried in RL and never find time to play at the moment, and barely follow this thread, but if I get a chance I'll take a look to at least see how hard it is to add this function to the orbit or celestial body class...  or if I can come up with a smarter way to help.  

I tried to brainstorm a stupider way to help too...  something like spawning a vessel and giving it an identical orbit...  but those functions don't really exist either!   Hmmm.  

Edited December 26, 2017 by artwhaley

[mcortez]

3 hours ago, artwhaley said:

I tried to brainstorm a stupider way to help too...  something like spawning a vessel and giving it an identical orbit...  but those functions don't really exist either!   Hmmm.  

lol, I called it quits and decided to post for help when I started playing with the idea of trying to brute force a solution -- basically creating a node with the correct Dv (which I can calculate knowing just the inclination change needed), and then moving the UT of the node until the Node's orbit had the correct Longitudinal Ascending Node...  I figured dragons, demons and all manor of bad things were hiding along that path.

 

The old kOS code that I copied from someone else, somehow takes the LAN and Inclination of the target, and the LAN and inclination of the active vessel and "converts it from spherical to cubic coordinates", throws in a vector cross-product, sprinkles a little arctan2()'s on top, and finishes it off with the active vessel's LAN and Argument of Periapsis to somehow come up with the appropriate True Anomaly of the appropriate place to do the inclination burn.  But when I tried to convert the code from kOS, it didn't work.  I'm not sure if it's because I messed up somewhere, or if it's a "right handed vs left handed coordinate issue" or what.  Seeing as the last time I used sin/cos/tan and radians to solve a problem was more than two decades ago, I'm not really even sure what the Va, Vb and Vc are doing in this code snippet:

// incl_i & lan_i - are the current inclination & LAN of the active vessel
// incl_t & lan_t - are the desired, new inclination & LAN, which can be taken from Target's Orbit information

// setup the vectors to highest latitude; Transform spherical to cubic coordinates.
    local Va to V(sin(incl_i)*cos(lan_i+90),sin(incl_i)*sin(lan_i+90),cos(incl_i)).
    local Vb to V(sin(incl_t)*cos(lan_t+90),sin(incl_t)*sin(lan_t+90),cos(incl_t)).
// important to use the reverse order
    local Vc to VCRS(Vb,Va).

    //compute burn_point and set to the range of [0,360]
    local node_lng to mod(arctan2(Vc:Y,Vc:X)+360,360).
   
    local node_true_anom to 360- mod(720 + (obt:lan + obt:argumentofperiapsis) - node_lng , 360 ).
      

I'll try and do another conversion tomorrow.  I *think* all I should have to do is replace the 90's with (Math.PI/2), the 360's with (Math.PI*2), and the one 720 with (Math.PI*4).  I couldn't remember how to do the Vector Cross-Product, and one google result said to use the following:

 double x, y, z;
 x = v1.Y * v2.Z - v2.Y * v1.Z;
 y = (v1.X * v2.Z - v2.X * v1.Z) * -1;
 z = v1.X * v2.Y - v2.X * v1.Y;

Which honestly, I have no idea if that's correct and if it matters if it's supposed to be a "right handed" or "left handed" coordinate set.

[mcortez]

I haven't done any comprehensive testing, but my re-implementation today worked on the first test - which is a lot better than I had yesterday.  For anyone else trying to accomplish the same thing, here's my current code:

 

// Create a note for the Active Vessel, which currently has an inclination of 0, to match the inclination of target body
//
// Adapted from G_Space's code at https://www.reddit.com/r/Kos/comments/3r5pbj/set_inclination_from_orbit_script/cwnhg5f/
// Also using System.Numerics.Vector3

var vessel = ksc.ActiveVessel;
var orb = vessel.Orbit;
var targetBody = ksc.TargetBody;

Vector3 Va = new Vector3((float)(Math.Sin(orb.Inclination) * Math.Cos(orb.LongitudeOfAscendingNode + (Math.PI / 2))), (float)(Math.Sin(orb.Inclination) * Math.Sin(orb.LongitudeOfAscendingNode + (Math.PI / 2))), (float)(Math.Cos(orb.Inclination)));

Vector3 Vb = new Vector3((float)(Math.Sin(targetBody.Orbit.Inclination) * Math.Cos(targetBody.Orbit.LongitudeOfAscendingNode + (Math.PI / 2))), (float)(Math.Sin(targetBody.Orbit.Inclination) * Math.Sin(targetBody.Orbit.LongitudeOfAscendingNode + (Math.PI / 2))), (float)(Math.Cos(targetBody.Orbit.Inclination)));

Vector3 Vc = Vector3.Cross(Vb, Va);

double node_lng = (Math.Atan2(Vc.Y, Vc.X) + (2 * Math.PI)) % (2 * Math.PI);
double node_true_anom = (2 * Math.PI) - (((4 * Math.PI) + (orb.LongitudeOfAscendingNode + orb.ArgumentOfPeriapsis) - node_lng) % (2 * Math.PI));

double incChange = targetBody.Orbit.Inclination;

// Calculate node values
double eta = orb.UTAtTrueAnomaly(burnTA);
double dv = burnDirection * ((2 * orb.OrbitalSpeedAt(eta)) * Math.Sin(incChange / 2));

// Split the DV change across normal and prograde
double normalDV = Math.Cos(incChange / 2) * dv;
double progradDV = -Math.Abs((Math.Sin(incChange / 2) * dv));

vessel.Control.AddNode(eta, (float)progradDV, (float)normalDV, 0);

 

Edited December 27, 2017 by mcortez
Added note about System.Numerics.Vector3

[RaGe2244]

Hello

How to use set_stream_rate() method, that the first argument(id)?

[djungelorm]

On 10/01/2018 at 9:26 PM, RaGe2244 said:

Hello

How to use set_stream_rate() method, that the first argument(id)?

Sorry for the slow reply... You shouldn't call set_stream_rate() directly. Instead, use the rate property of a stream object (documented here)

The following example shows how to use this to print out the vessels surface speed twice per second:

import krpc
import time

conn = krpc.connect()
vessel = conn.space_center.active_vessel
srf_frame = vessel.orbit.body.reference_frame
srf_flight = vessel.flight(srf_frame)

def print_speed(x):
    print('speed =', x)

speed = conn.add_stream(getattr, flight, 'speed')
speed.rate = 2  # set the rate to number of Hz
speed.add_callback(print_speed)
speed.start()

# Keep the program running...
while True:
    time.sleep(3)

 

[djungelorm]

v0.4.4 has been released!

• You can now write much more complex server side expressions, such as extract the values from a tuple or sum a list. Docs here: http://krpc.github.io/krpc/python/api/krpc/expressions.html
• Added temperature and efficiency RPCs to the ResourceConverter class

The full changelog is available here: https://github.com/krpc/krpc/releases/tag/v0.4.4