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

[sylink]

I am familiar with Python but have no idea how to use your mechjeb project, can you point me to some direction how to add it to the existing lib with Python 2.7?

 

Also I've been trying out krpc but cannot get the sas to work correctly. It never triggers and every rocket seems to fall over and never turn on the sas. Is there an example of this somehow? Setting to true does nothing as far as I can tell.

[artwhaley]

My mechjeb piece isn't ready for public consumption...  I'm hoping for a bit of guidance on how to work it into the larger project before I clean it up for public use.  

But...  the sas modes SHOULD be working?  I just did a quick test - 

import krpc
conn=krpc.connect()
v=conn.space_center.active_vessel
v.control.sas=True                                                                                         #turns on SAS
v.control.sas_mode= conn.space_center.SASMode.prograde                     #Sets SAS to prograde

Now, it will throw an exception if you try to set an invalid mode... for example, if you're still on the ground and order it to go prograde, that's not a valid instruction, so it will throw an error back at you.

But once I was in flight that example I just pasted in set the SAS to on and pointed the rocket prograde just fine?  If that doesn't help, please post your python script and I'll take a look!

edit : space_center.SASMode. is the enum that contains all the possible SAS modes!  I should have pointed that out in case you hadn't found it.  IDLE, at least, gets the ENUM values at runtime, so it will auto-complete the valid settings once you know where to start.

Edited January 13, 2016 by artwhaley

[sylink]

If I run this it works:

Quote

import krpc
import time

conn = krpc.connect(name='Hello World')
vessel = conn.space_center.active_vessel
print(vessel.name)

vessel.auto_pilot.target_pitch_and_heading(90,90)
vessel.auto_pilot.engage()
vessel.control.throttle = 1
vessel.control.sas=True 
vessel.control.sas_mode= conn.space_center.SASMode.stability_assist
time.sleep(1)
print vessel.control.sas
print('Launch!')
vessel.control.activate_next_stage()

while vessel.resources.amount('LiquidFuel'):
    flight_data=vessel.flight()
    print vessel.control.sas
    vessel.control.sas=True
       

 

 

But if I cut the script off and take out the final loop and leave the last command to set SAS to true it turns it off and stays set to false. It seems it has to be set in every loop or something? 

 

Setting the mode works but the status True/False seems to get turned off by something.

[artwhaley]

The problem seems to be that you're engaging the autopilot, and then trying to use SAS.  Like with mechjeb, the kRPC autopilot disengages SAS so that it can give commands to the rocket instead!

This works to engage SAS, but doesn't use the autopilot to hold any particular course:

import krpc
import time


conn = krpc.connect(name='Hello World')
vessel = conn.space_center.active_vessel
print(vessel.name)


vessel.control.throttle = 1
vessel.control.sas=True 
vessel.control.sas_mode= conn.space_center.SASMode.stability_assist
time.sleep(1)
print vessel.control.sas
print('Launch!')
vessel.control.activate_next_stage()

And THIS works to have the autopilot try to keep the rocket pointed straight up no matter what: 

import krpc
import time


conn = krpc.connect(name='Hello World')
vessel = conn.space_center.active_vessel
print(vessel.name)


vessel.auto_pilot.target_pitch_and_heading(90,90)
vessel.auto_pilot.engage()
vessel.control.throttle = 1
time.sleep(1)
print vessel.control.sas
print('Launch!')
vessel.control.activate_next_stage()

It's an either or situation.   

[sylink]

Ok, I see how that works now.  But for me if I use that code on a rocket it launches etc then at about 1000m it always wobbles and tips over.  Is the auto pilot particularly slow/overreactive? 

 

If I use the launch to orbit example and craft file it works perfectly but I think this is because it fits the rocket very well.

[artwhaley]

I haven't used it enough to know for sure.  I WOULD check first the usual cause for a rocket flipping over as it gathers speed-  make sure your rocket is aerodynamically stable to start with and that your TWR isn't too high to launch at full throttle without extreme aerodynamic forces.

 

The auto pilot has a lot of tunable parameters that I haven't played with so I can't give specific guidance, but if your rocket can launch by hand but not krpc, the answer is probably in some setting of the max correction forces and pid parameters:

http://djungelorm.github.io/krpc/docs/python/api/space-center/auto-pilot.html

[Kerbart]

2 hours ago, sylink said:

Ok, I see how that works now.  But for me if I use that code on a rocket it launches etc then at about 1000m it always wobbles and tips over.  Is the auto pilot particularly slow/overreactive?

I suspect that the autopilot uses a PID controller (and perhaps you can even set the process variables but I haven't dug into that). It tends to react slow when your flight direction is close to what you want the autopilot to do, and more aggressively when the difference increases.

So, let's say you pitch over 5° for every km of altitude and you have a constant climb rate (I know, I know... but just to keep things simple!). In the beginning your're going straight up, now you're telling your autopilot "pitch over 5°" at 1000m. Not a lot will happen. At 2000m you tell the autopilot "pitch over 10°" and now the autopilot will steer a bit more aggressively, as your flight path has pitched, say, only 2°. By the time you've pitched over 5° you reach 3000m and you tell the autopilot "Pitch 15°". By now it starts to turn rapidly, and you flip.

Thinking about that, maybe I should alter my script with simply telling the autopilot to push a couple of degrees beyond the flight path, instead of sticking to fixed values.

 

 

 

[Antipaten]

I don't know if I'm doing something wrong, but when I started testing my control panel for real gaming I noticed that I had severe lag problems even with small rockets and it quickly became unplayable even at a modest part count.

The problem becomes less pronounced if I request less data from the game but it isn't until I disconnect completely from the RPC server that it becomes a noticable difference, even when I set delay between reads as high as 200ms. There is still some lag even if there are no connections at all to kRPC that is enough to make big ships unflyable.

This leads me to assume that something in the mod causes a delay in Unity and as it is single threaded it causes the entire game to stutter.

Does anyone else have the same problem?

[artwhaley]

Have you experimented with the advanced options in the control panel? I don't have it open right now but there's an option to only allow it to pass so many RPCs per game physics frame that might help you out?  Of course any code you execute in the game thread is going to slow the game thread a little, but I have found kRPC to be pretty solid even under some pretty intense load?  Way better than the other methods I've played with to get data out.  What's your definition of a 'large rocket?'   

[Kerbart]

I agree with @artwhaley, I've not experienced (significant) delays through kRPC. You can delete the mod and see if that makes a difference, to eliminate or confirm that it's kRPC that is causing the lag.

Running KerboKatz, by any chance? I did when I ran KSP on my laptop as it really pushed the hardware to it's limit, and reducing framerates when KRPC is not active really helped keeping the temperature down. But at that point I did notice that, when switching to IDLE to run a launch script, KSP would run incredibly laggy... for the (once you realize it) obvious reason that the FSP limit kicks in once KSP is no longer active.

[Kobymaru]

Hey guys, I need a "telemetry" logger, and I found kRPC which seems like it would do what I need.

I wanna script a simple Python logger, but the question is: has anybody done that already? I don't want to duplicate efforts.

[edit]

Ooookk, so here is a small script that can be used for logging a few values.
I used some values that are useful for "reentry-debugging". I hope it's gonna be useful for someone:

https://gist.github.com/fat-lobyte/4326afa551fa04dd028f

Edited January 25, 2016 by Kobymaru

[Kobymaru]

Hi, I'm trying to read a flights "sideslip" angle, but weirdly I get a value of about 57 (degrees?) when it has clearly no sideslip. This is more or less consistent.

Is this the correct value to read for sideslip? Are there any calculations to transform it into a "real" value?

Edited January 25, 2016 by Kobymaru

[Kerbart]

11 minutes ago, Kobymaru said:

Ooookk, so here is a small script that can be used for logging a few values.
I used some values that are useful for "reentry-debugging". I hope it's gonna be useful for someone:

https://gist.github.com/fat-lobyte/4326afa551fa04dd028f

Do you mind if, at one point, I take a stab at it? A lot of code is spent on writing the output, where utilizing the csv library would be a good opportunity to cut some lines and get cleaner code.

[Kobymaru]

15 minutes ago, Kerbart said:

Do you mind if, at one point, I take a stab at it? A lot of code is spent on writing the output, where utilizing the csv library would be a good opportunity to cut some lines and get cleaner code.

Sure, go ahead! 

Note that if you take a closer look, "a lot of code" is actually a single str.format() statement. But if there's a better way, that would be perfect.

What would be nice is "user-configurable" columns, but the problem is that the values are split into vessel/flight/orbit parameters.

[artwhaley]

11 hours ago, Kobymaru said:

Hi, I'm trying to read a flights "sideslip" angle, but weirdly I get a value of about 57 (degrees?) when it has clearly no sideslip. This is more or less consistent.

Is this the correct value to read for sideslip? Are there any calculations to transform it into a "real" value?

I think you found a minor bug!  I just submitted a pull request that I THINK fixes it.  

I'll PM you a temporarily fixed krpcspacecenter.dll to drop into your gamedata/krpc directory and overwrite the existing one there, in case you need it before the next release and don't have a build environment setup yourself!  Of course djungleorm is smarter than me, so he may point out that mix fix isn't as clever as I think it is and come up with a better one... so...  don't shoot me if it's not brilliant, but it passed my quick test.
 

[djungelorm]

Yep you found a bug! I've merged the fix, and will release it with 0.2.0 very very very soon....

[djungelorm]

Version 0.2.0 has been released!

The changes are:

• A C# client. Read more here
• Updated the server and client libraries to use protobuf version 3
• Licensing changes:
  • All the client libraries are now LGPLv3
  • The server plugins are also LGPLv3, except KRPC.SpaceCenter.dll which is GPL (as it contains GPL'd code from other mods)
  • The .proto definition files are MIT licensed, so you can use them to communicate from your own code without being forced to use a particular license
• Support for resource harvesters and converters (thanks @artwhaley!!)
• Fixed bugs with:
  • Vessel.HorizontalSpeed
  • Flight.SideslipAngle

Also, this version is not backwards compatible with 0.1.* due to the update to use protobuf version 3, hence the bump to version 0.2.

The build system has also been completely rewritten to use Bazel - the Makefiles were getting too hard to maintain with the sheer number of different languages needing to be compiled and packages built (protoc, C#, C++, Python, Lua, sphinx, pypi, nuget, luarocks ... the list goes on). The build instructions have been updated accordingly in the docs: http://djungelorm.github.io/krpc/docs/compiling.html

Edited January 26, 2016 by djungelorm
comment on build system

[djungelorm]

I've added a thread to the add-on release forum, here: http://forum.kerbalspaceprogram.com/index.php?/topic/130742-105-krpc-remote-control-your-ships-using-python-c-c-lua-v020-25th-jan-2016/

[artwhaley]

Awesome progress!  If there's anything else I can help with, don't hesitate to ask! 

[artwhaley]

I'm having trouble with the new version?  I've tried with both c# and then with Python.... so it's probably something I'm doing wrong.   on C# I tried the code:

using KRPC.Client.Services.SpaceCenter;

namespace ConsoleApplication1
{
    class Program
    {
        static void Main()
        {
            var connection = new KRPC.Client.Connection(name: "Vessel Name");
            var sc = connection.SpaceCenter();
            var vessel = sc.ActiveVessel;
            System.Console.WriteLine(vessel.Name);

        }
    }
}

I loaded KSP, started the server and configured for auto accept connections, launched a vessel, then ran my code (attempted both with and without debugging) And got the error:

 

Unhandled Exception: KRPC.Client.RPCException: Could not load file or assembly 'kRPCSpaceCenter, Version=0.1.12.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies.
   at KRPC.Client.Connection.Invoke(String service, String procedure, IList`1 arguments)
   at KRPC.Client.Services.SpaceCenter.Service.get_ActiveVessel()
   at ConsoleApplication1.Program.Main() in C:\Users\art\Documents\GitHubVisualStudio\ksptesting\ConsoleApplication1\ConsoleApplication1\Program.cs:line 16
Press any key to continue . . .

So I thought I'd switch to Python and double check myself, and then...  

When I run the python setup script...  I get an error on line 7 about 

Traceback (most recent call last):
  File "C:\krpc-0.2.0\setup.py", line 7, in <module>
    del os.link
AttributeError: link
>>> 

If I comment that line out, the script runs without further error, but the first time I try to import krpc in idle I get this :

Traceback (most recent call last):
  File "<pyshell#0>", line 1, in <module>
    import krpc
  File "C:\Python27\lib\site-packages\krpc\__init__.py", line 3, in <module>
    from krpc.client import Client
  File "C:\Python27\lib\site-packages\krpc\client.py", line 8, in <module>
    import krpc.schema.KRPC
  File "C:\Python27\lib\site-packages\krpc\schema\KRPC.py", line 22, in <module>
    serialized_pb=_b('\n\x13protobuf/krpc.proto\x12\x0bkrpc.schema\"W\n\x07Request\x12\x0f\n\x07service\x18\x01 \x01(\t\x12\x11\n\tprocedure\x18\x02 \x01(\t\x12(\n\targuments\x18\x03 \x03(\x0b\x32\x15.krpc.schema.Argument\"+\n\x08\x41rgument\x12\x10\n\x08position\x18\x01 \x01(\r\x12\r\n\x05value\x18\x02 \x01(\x0c\"j\n\x08Response\x12\x0c\n\x04time\x18\x01 \x01(\x01\x12\x11\n\thas_error\x18\x02 \x01(\x08\x12\r\n\x05\x65rror\x18\x03 \x01(\t\x12\x18\n\x10has_return_value\x18\x04 \x01(\x08\x12\x14\n\x0creturn_value\x18\x05 \x01(\x0c\"?\n\rStreamMessage\x12.\n\tresponses\x18\x01 \x03(\x0b\x32\x1b.krpc.schema.StreamResponse\"E\n\x0eStreamResponse\x12\n\n\x02id\x18\x01 \x01(\r\x12\'\n\x08response\x18\x02 \x01(\x0b\x32\x15.krpc.schema.Response\"2\n\x08Services\x12&\n\x08services\x18\x01 \x03(\x0b\x32\x14.krpc.schema.Service\"\xaf\x01\n\x07Service\x12\x0c\n\x04name\x18\x01 \x01(\t\x12*\n\nprocedures\x18\x02 \x03(\x0b\x32\x16.krpc.schema.Procedure\x12#\n\x07\x63lasses\x18\x03 \x03(\x0b\x32\x12.krpc.schema.Class\x12.\n\x0c\x65numerations\x18\x04 \x03(\x0b\x32\x18.krpc.schema.Enumeration\x12\x15\n\rdocumentation\x18\x05 \x01(\t\"\x9e\x01\n\tProcedure\x12\x0c\n\x04name\x18\x01 \x01(\t\x12*\n\nparameters\x18\x02 \x03(\x0b\x32\x16.krpc.schema.Parameter\x12\x17\n\x0fhas_return_type\x18\x03 \x01(\x08\x12\x13\n\x0breturn_type\x18\x04 \x01(\t\x12\x12\n\nattributes\x18\x05 \x03(\t\x12\x15\n\rdocumentation\x18\x06 \x01(\t\"_\n\tParameter\x12\x0c\n\x04name\x18\x01 \x01(\t\x12\x0c\n\x04type\x18\x02 \x01(\t\x12\x1c\n\x14has_default_argument\x18\x03 \x01(\x08\x12\x18\n\x10\x64\x65\x66\x61ult_argument\x18\x04 \x01(\x0c\",\n\x05\x43lass\x12\x0c\n\x04name\x18\x01 \x01(\t\x12\x15\n\rdocumentation\x18\x02 \x01(\t\"a\n\x0b\x45numeration\x12\x0c\n\x04name\x18\x01 \x01(\t\x12-\n\x06values\x18\x02 \x03(\x0b\x32\x1d.krpc.schema.EnumerationValue\x12\x15\n\rdocumentation\x18\x03 \x01(\t\"F\n\x10\x45numerationValue\x12\x0c\n\x04name\x18\x01 \x01(\t\x12\r\n\x05value\x18\x02 \x01(\x05\x12\x15\n\rdocumentation\x18\x03 \x01(\t\"\x15\n\x04List\x12\r\n\x05items\x18\x01 \x03(\x0c\";\n\nDictionary\x12-\n\x07\x65ntries\x18\x01 \x03(\x0b\x32\x1c.krpc.schema.DictionaryEntry\"-\n\x0f\x44ictionaryEntry\x12\x0b\n\x03key\x18\x01 \x01(\x0c\x12\r\n\x05value\x18\x02 \x01(\x0c\"\x14\n\x03Set\x12\r\n\x05items\x18\x01 \x03(\x0c\"\x16\n\x05Tuple\x12\r\n\x05items\x18\x01 \x03(\x0c\"\xf4\x03\n\x06Status\x12\x0f\n\x07version\x18\x01 \x01(\t\x12\x12\n\nbytes_read\x18\x02 \x01(\x04\x12\x15\n\rbytes_written\x18\x03 \x01(\x04\x12\x17\n\x0f\x62ytes_read_rate\x18\x04 \x01(\x02\x12\x1a\n\x12\x62ytes_written_rate\x18\x05 \x01(\x02\x12\x15\n\rrpcs_executed\x18\x06 \x01(\x04\x12\x10\n\x08rpc_rate\x18\x07 \x01(\x02\x12\x1a\n\x12one_rpc_per_update\x18\x08 \x01(\x08\x12\x1b\n\x13max_time_per_update\x18\t \x01(\r\x12\x1d\n\x15\x61\x64\x61ptive_rate_control\x18\n \x01(\x08\x12\x15\n\rblocking_recv\x18\x0b \x01(\x08\x12\x14\n\x0crecv_timeout\x18\x0c \x01(\r\x12\x1b\n\x13time_per_rpc_update\x18\r \x01(\x02\x12 \n\x18poll_time_per_rpc_update\x18\x0e \x01(\x02\x12 \n\x18\x65xec_time_per_rpc_update\x18\x0f \x01(\x02\x12\x13\n\x0bstream_rpcs\x18\x10 \x01(\r\x12\x1c\n\x14stream_rpcs_executed\x18\x11 \x01(\x04\x12\x17\n\x0fstream_rpc_rate\x18\x12 \x01(\x02\x12\x1e\n\x16time_per_stream_update\x18\x13 \x01(\x02\x42\x13\xaa\x02\x10KRPC.Schema.KRPCb\x06proto3')
TypeError: __init__() got an unexpected keyword argument 'syntax'

I'm running KSP 1.0.5 on Windows 10 64 bit with Python 2.7 and Visual Studio 2015.  I linked the c# library in via Visual Studio's 'manage Nuget Packages' feature, if any of that is relevant.

[djungelorm]

Are you sure you've updated the server to 0.2.0? The error message from the C# client mentions kRPCSpaceCenter version 0.1.12.

For python, what version of protobuf do you have installed? I think that is caused by using protobuf 2. You need protobuf 3.0.0-beta2

Edited January 26, 2016 by djungelorm

[Antipaten]

On 2016-01-23 at 8:07 AM, artwhaley said:

Have you experimented with the advanced options in the control panel? I don't have it open right now but there's an option to only allow it to pass so many RPCs per game physics frame that might help you out?  Of course any code you execute in the game thread is going to slow the game thread a little, but I have found kRPC to be pretty solid even under some pretty intense load?  Way better than the other methods I've played with to get data out.  What's your definition of a 'large rocket?'   

A small rocket is around 30 parts and a large is around 100. I get short "red lag" even without clients connected and no phys acceleration. Without the mod i can use 2x phys acceleration with green figures for the same (low part count) ship.

Hopefully this will sort itself out when KSP 1.1 is released and we get the multihreading Unity5. Single threading is a real P.I.T.A as it is virtually impossible to throw better hardware on performance problems. I just wondered if anyone had encountered it and knew if I've done something silly in the settings. They are pretty much vanilla except for starting the server automatically and auto accepting clients. I didn't notice the lag until I really tried running the game for real using my control panel. The panel emulates joysticks for input to the game and only uses kRPC for reading fuel levels, acceleration, atmospheric density and mach number from the game every 200 ms.

Edited January 26, 2016 by Antipaten

[artwhaley]

I think the problem with c# might have been that I didn't delete my krpc-mechjeb dll that was in the folder, and it was compiled against the old version?  I don't KNOW that this was the problem, but deleting the directory and then unpacking it freshly from the 2.0 .zip file DID fix my c# problem!  So, I'm going to be playing with that a lot the next couple of days!   Reinstalling the server did NOT fix my python problem?  I still have to comment out the del os.link line to make the setup script run at all, and then afterwards 'import krpc' throws that same massive error from before.  Is it compatible with python 2.7?  Anything you'd like me to test?  Other versions of python?  Alternative install methods?  I'll download it on my linux box later tonight and see if I have the same problems there....

[djungelorm]

Glad to hear you got C# working!

I must admit I didn't try the python client on windows. The os.link thing sounds like a windows only problem with the installer. I added it to get the Bazel build system to work, it isn't needed otherwise so is safe to comment out.

It is compatible with python 2.7 (and 3). I think the issue is the version of protobuf you have installed. The installer should update this when you use pip or setup.py but maybe it didn't... Can you post the output of the following to check?

 

import google.protobuf

print google.protobuf.__version__

 

You should see 3.0.0b2

[artwhaley]

You called it -  it reports  "3.0.0-alpha-1".    Do you want me to go ahead and try to update it manually and see if that fixes it, or leave it out of date so I can help test a new version of the setup script if you think it's something that needs fiddled with?