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

[sviridovt]

5 hours ago, djungelorm said:

You were very very close with that first command in the image. If you replace gcc with g++ it should work! (GCC compiles C code by default, but this is C++...)

However, if you installed all the libraries correctly the following simpler command should work:

g++ main.cpp -std=c++11 -lkrpc -lprotobuf

I've written a short guide below that might help, and which I'll put on the docs site if it's useful.

----

Firstly, you need to install the ASIO and protobuf v3 libraries.

ASIO is a "headers only" library. It can be installed from apt using:

sudo apt-get install libasio-dev

protobuf v3 is not available via apt, so you need to install it manually. Instructions can be found here: https://github.com/google/protobuf/blob/master/src/README.md

Then install the kRPC client library. Download and extract the archive, then run:

./configure
make
sudo make install
sudo ldconfig

You should now have all the libraries you need installed in the system-wide locations. To verify this, check that the following exist:

/usr/local/asio.hpp
/usr/local/include/google/protobuf/...
/usr/local/include/krpc.hpp
/usr/local/include/krpc/...
/usr/local/lib/libprotobuf.so
/usr/local/lib/libkrpc.so

You can then compile your kRPC programs using the following command:

g++ main.cpp -std=c++11 -lkrpc -lprotobuf

Here's an example main.cpp file:

#include <krpc.hpp>
#include <krpc/services/krpc.hpp>
#include <iostream>

int main() {
   auto conn = krpc::connect();
   auto krpc = krpc::services::KRPC (&conn);
   std::cout << "Successfully connected to kRPC version " << krpc.get_status().version() << std::endl;
}

Followed instructions to the letter, still have these errors when I try to compile:

 

Could it be because I am on Ubuntu 15?

 

Sorry for the issues, I am very new to Linux and am still getting used to it

Edited March 2, 2016 by sviridovt

[djungelorm]

Use g++ not gcc.

[sviridovt]

9 minutes ago, djungelorm said:

Use g++ not gcc.

Wrong screenshot:

[djungelorm]

Haha! I did wonder!

It can't find libprotobuf.so Try running:

find / -name libprotobuf.so 2>/dev/null

That should tell us where it is on your system.

[sviridovt]

 

Its in the right location (in the same location as libkrpc) so I have no idea why it cant find it. Also, when I remove -lprotobuf there are quite a few more errors so I imagine it finds it but is missing certain parts

Edited March 2, 2016 by sviridovt

[djungelorm]

Ah OK, I'm slightly mistaken. It is finding libprotobuf, but it's probably the wrong version. I suspect it is picking up the one in /usr/lib/x86_64-linux-gnu

Try putting this flag before -lprotobuf to force it to use the correct one:

-L/usr/local/lib

[sviridovt]

Yep, that did the trick! Thanks a lot!

[djungelorm]

Wahoo excellent!

A slightly better way of forcing it to use the correct version is to change -lprotobuf to -l:protobuf.so.10 Then you don't need to give it the full path.

I just managed to reproduce your issue by installing libprotobuf8 via apt. So it was indeed picking up a protobuf2 lib.

[sviridovt]

Good to know.

BTW, something I noticed setting it up with Eclipse is that eclipse puts a full path with -l if you add it as a library, which then causes errors with compilation, so anyone that wants to set it up you have to manually go into Properties>C/C++ Build>Settings>Cross G++ Linker>Libraries and change the Libraries entries to read 'krpc' and 'protobuf' and then it compiles perfectly

Edited March 2, 2016 by sviridovt

[sviridovt]

Hate to be that guy, but another issue that I have. It seems like my AutoPilot functions aren't working, from what I read on this thread it seems like its FAR thats causing issue and that PID parameters, did anyone ever find what the optimum values are for FAR/Realism Overhaul?

[djungelorm]

11 hours ago, sviridovt said:

Hate to be that guy, but another issue that I have. It seems like my AutoPilot functions aren't working, from what I read on this thread it seems like its FAR thats causing issue and that PID parameters, did anyone ever find what the optimum values are for FAR/Realism Overhaul?

Tuning the PID parameters might help. Try increasing the P value if it's being sluggish. In my experience, the current autopilot copes ok if the rocket has plenty of reaction wheel torque, even with FAR installed.

Also note that the autopilot will disable itself when your script disconnects.

[djungelorm]

I've been learning control theory, and have come up with an auto-tuned roll controller that works pretty well. It uses a PD controller to orientate the vessel at a target roll angle. The P and D gains are chosen automatically based on the available reaction wheel torque and moment of inertia.

Here's the math: https://docs.google.com/document/d/1glHxqjsmae3Tep-oFe8f5QYs6BUrc5dKkSrVJMopw_c/edit?usp=sharing

And here's an implementation in python: https://gist.github.com/djungelorm/98b59370a1d171817edb

In order to run it you'll need a copy of KRPC.SpaceCenter.dll with some new RPCs for moment of inertia and torque. It can be downloaded from here: https://krpc.s3.amazonaws.com/deploy/feature/autopilot-rpcs/249.1/GameData/kRPC/KRPC.SpaceCenter.dll

My next step is to try extending this to the pitch and yaw axes. Not sure if this is best done by using an additional PD controller for each axis, or somehow getting the controller to work with vectors. It will also need to be extended to consider the torque from engine gimbals, RCS thrusters and aero control surface. Should just be a case of including these into the torque value that is input into the PD controller.

(pinging potentially interested people: @hvacengi @artwhaley @Jim DiGriz )

[komodo]

Spiffy! I hate to admit it, but I suppose my physics courses actually did something, as all of that made sense. (I couldn't derive it off the top of my head, but hey...  )

kudos to you for the framework as well, as the python is incredibly readable. 

I don't know about the path forward; vectors are "simple", mathematically, but a pain to work with at times. (Other times they're the best/only way forward, and I don't know if this is one of them.)

My end user and innate programming thoughts yell out for the simplest version in terms of implementation. That would be the "one for each axis" model, I suppose. 

Km_gimbal is a commonly found plugin that extends roll control to engines with grt 1 gimbaling nozzle, but I have no idea if it's reported back to the game in terms of torque. I just throw that out there as roll gimbal isn't always thought of. (Or, just make the roll controller deal with it through error terms  )

[Keith Young]

I am definitely seeing a need for PID on Yaw and Pitch, where the user can decide on coefficients. I'm trying to set a target_pitch_and_heading and the rocket oscillates back and forth. It seems like it is all Proportional control and is lacking Derivative.

[Jim DiGriz]

On 3/19/2016 at 9:27 AM, Keith Young said:

I am definitely seeing a need for PID on Yaw and Pitch, where the user can decide on coefficients. I'm trying to set a target_pitch_and_heading and the rocket oscillates back and forth. It seems like it is all Proportional control and is lacking Derivative.

That is the lack of angular momentum and inertia compensation.

[Gyrfalcon]

Not sure if this is the right place to post because this is more wrangling Python than anything else. I want to start building a docking program piece by piece, starting with nulling relative velocity at the closest point to the target craft. I want to do this by stealing code from the docking guidance tutorial. They use numpy there, and I have a feeling that I will need to use numpy no matter my implementation. However, I can't figure out a good way to install numpy. There are scripts available, but I don't believe they will work because they look for Python on the C drive, while I have it installed on the D drive. I will look around more in the morning, but just wanted to know if any Python pros here had a pro tip.

 

EDIT: Apparently I installed Python in a way that makes what I want to do very difficult, so I will be installing again with an installer that packages Numpy.

Edited March 27, 2016 by Gyrfalcon

[djungelorm]

In case anyone is itching to try kRPC with the KSP 1.1 pre-release, a compatible version is available here:

http://krpc.s3-website-us-east-1.amazonaws.com/deploy/feature/ksp-1.1-pre/287.1/

I've not thoroughly tested it, but the basics appear to work.

Edited April 4, 2016 by djungelorm
Update link

[Illation]

So, I am currently struggling with the following problem:

I created myself a library function to check for engines that have a flameout, which looks like this (c#):

public static bool ActiveEngineFlameout(Vessel vessel)
{
    return vessel.Parts.Engines.Where(e => (e.Active && !e.HasFuel)).Count() > 0;
}

Now, since I am running on rss, I have to have ullage motors on my rockets to get stable fuel flow, and that makes it really hard to use this logic to check if staging is necessary, since I dont want to stage when there is an active ullage motor without fuel.
Now I could simply check if the Engine happens to be a "baby sergeant rocket motor", which I use for ullage in this case, but then the function will be defunctional if I use said engines in an actual stage, eg a satellite. I could also write a specific version for this function for every stage, but that would not result in very nice code. 

Does anyone have a suggestion on how to make a nice implementation for this? I was thinking of something along the lines of giving parts the ability to have a custom tag, flag or name (as in KOS), and being able to check for that in the part api, so that in this case I could say something along the lines of: 

(e.Active && !e.HasFuel && !e.HasTag("NoFlameoutCheck"))

Any other suggestions on how I can nicely implement this?

[djungelorm]

kRPC 0.2.3 has been released! Here are the highlights:

• Support for engines with multiple modes
• Support for cargo bays, fairings and air intakes
• Fixes for 1.0.5 landing gear and radiators
• All the client libraries are now thread safe
• Improved MSVC support in the C++ client
• Java client now supports JDK 1.7 (as well as 1.8)

A full change log can be found here: https://github.com/krpc/krpc/releases/tag/v0.2.3

This release is for KSP 1.0.5. A version compatible with the KSP 1.1 pre-release can be downloaded from here: https://krpc.s3.amazonaws.com/deploy/feature/ksp-1.1-pre/302.1/krpc-0.2.3-18-g0eb3274.zip

On 4/5/2016 at 1:34 PM, Illation said:

So, I am currently struggling with the following problem:

I created myself a library function to check for engines that have a flameout, which looks like this (c#):

public static bool ActiveEngineFlameout(Vessel vessel)
{
    return vessel.Parts.Engines.Where(e => (e.Active && !e.HasFuel)).Count() > 0;
}

Now, since I am running on rss, I have to have ullage motors on my rockets to get stable fuel flow, and that makes it really hard to use this logic to check if staging is necessary, since I dont want to stage when there is an active ullage motor without fuel.
Now I could simply check if the Engine happens to be a "baby sergeant rocket motor", which I use for ullage in this case, but then the function will be defunctional if I use said engines in an actual stage, eg a satellite. I could also write a specific version for this function for every stage, but that would not result in very nice code. 

Does anyone have a suggestion on how to make a nice implementation for this? I was thinking of something along the lines of giving parts the ability to have a custom tag, flag or name (as in KOS), and being able to check for that in the part api, so that in this case I could say something along the lines of: 

(e.Active && !e.HasFuel && !e.HasTag("NoFlameoutCheck"))

Any other suggestions on how I can nicely implement this?

There is no way to set a 'tag' on a part object in kRPC - but you could do something similar within your C# program. You could have maintain a set containing the part objects that should be ignored in the flameout check. kRPC part objects are equality comparable so this should work (and internally they are tied to part.flightID so should even persist when switching vessels!)

[Ghosty141]

I love your mod, huge thanks for the 1.1 update

Edited April 9, 2016 by Ghosty141

[Rodhern]

On 2/21/2016 at 4:10 AM, Rodhern said:

...

I have taken your documentation C# Client example code and written (sort of) an equivalent example as F# script code.

...

My F# script snippet can be found here:
http://fssnip.net/8qR http://fssnip.net/7Pi

...

Just wanted to tell you that the original snippet was lost (a fssnip clean up mishap). I have reuploaded to the above mentioned link address.

[djungelorm]

0.3.0 has been released

Here are the highlights:

• Support for KSP 1.1
• Get the MoI and inertia tensors of vessels and individual parts
• Thruster objects - for the individual nozzels on an engine or in an RCS block. Gives you the thrust positions and directions.
• Objects for RCS and control surface parts
• Camera controls - rotate, zoom and switch modes (although rotation and zooming in IVA doesn't work yet)
• Save and load the game
• Resource transfers
• And various bug fixes

See the full list of changes for more details

[djungelorm]

kRPC 0.3.2 has been released, with support for KSP 1.1.2 and some bug fixes (full changelog can be found here).

Enjoy!

[djungelorm]

v0.3.3 has been released Here are the highlights:

• Fixed a bug with dialog windows not appearing
• Add "AvailableTorque" properties to engines, RCS thrusters, reaction wheels and aerodynamic control surfaces
• Add support for RemoteTech 1.7 - you can now target your dishes using RPCs!

The full changelog can be found here

[Vikins]

I need your help!

I can't install krps in Python 2.7.11

I have already downloaded an zip archive with krpc0.3.3 version, but I don't understand where i have to unzip this file?

 

I need more detailed instruction.

Could you help me?