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

[SuperManitu]

6 hours ago, djungelorm said:

Have you compiled the C++ source files for the kRPC client? They are in the src folder in the archive, and need to be linked into your application.

I feel dumb now. Yeah, that was the issue, once I compiled it into a lib and linked it, everything worked. I was able to compile and try the "Hello World" example.

Thanks

[SuperManitu]

6 hours ago, djungelorm said:

Have you compiled the C++ source files for the kRPC client? They are in the src folder in the archive, and need to be linked into your application.

I feel dumb now. Yeah, that was the issue. Once I compiled it into a lib and linked against it, everything worked and I was able to compile the "Hello World" Version Check from the docs.

Thanks

[Gyrfalcon]

Hello!

I'm just starting in kRPC and I'm having trouble with a script for a first career launch. The problematic part is deploying my parachute. I want to deploy the chute when the ship stops going up, so I set up a stream to check the vertical velocity of the ship, and then when that stream value goes below 0, it will activate the chutes. However, the stream I've set up consistently returns a value of 0 no matter what I've tried. In debugging I've changed it to the more general speed stream, but this too returns 0 always. I checked if the problem was an outdated KSP version, which it is not, and I wanted to check if the problem was me but the documentation is down right now.

Here are images of my code and it's output, as well as a list of my addons if it makes a difference. 

[djungelorm]

5 hours ago, SuperManitu said:

I feel dumb now. Yeah, that was the issue. Once I compiled it into a lib and linked against it, everything worked and I was able to compile the "Hello World" Version Check from the docs.

Thanks

Glad you got it working! Also, the next release will include autotool (./configure and makefiles) and cmake scripts to build the library.

[djungelorm]

2 hours ago, Gyrfalcon said:

Hello!

I'm just starting in kRPC and I'm having trouble with a script for a first career launch. The problematic part is deploying my parachute. I want to deploy the chute when the ship stops going up, so I set up a stream to check the vertical velocity of the ship, and then when that stream value goes below 0, it will activate the chutes. However, the stream I've set up consistently returns a value of 0 no matter what I've tried. In debugging I've changed it to the more general speed stream, but this too returns 0 always. I checked if the problem was an outdated KSP version, which it is not, and I wanted to check if the problem was me but the documentation is down right now.

Here are images of my code and it's output, as well as a list of my addons if it makes a difference. 

Hello!

The documentation has actually moved... It's now at: http://krpc.github.io/krpc/

You need to use a different reference frame for vessel.flight(). By default, it uses the vessel's orbital reference frame, which moves with the vessel, hence the speed of 0. You probably want Kerbin's reference frame (fixed relative to Kerbin and rotates with it): http://krpc.github.io/krpc/python/api/space-center/celestial-body.html#SpaceCenter.CelestialBody.reference_frame

There's also a complete example in the docs here: http://krpc.github.io/krpc/tutorials/reference-frames.html#surface-speed

[Gyrfalcon]

That would definitely do it. Thanks for the help. I'm on to bigger and better things in career but I'm sure I'll be able to find a use for this in a landing program.

[Cheaterman]

Hey djungelorm,

Just wanted to thank you for the awesome mod, I made a neat little autopilot with it: http://imgur.com/a/wQC6m (source: https://github.com/Cheaterman/kautopilly )

I'll add support for orbital maneuvers and more neat stuff in the future. Stay tuned! :-)

[Jim DiGriz]

So, does the PID in the autopilot need to autotune itself a little better?  With a mainsail taking off its a bit too aggressive and when I pitch over it 10 degrees it overshoots and wobbles.  Then I was having all kinds of trouble with the rocket tumbling once I cut the throttle, and what I just discovered is that jacking the PID up to 10,0,0 seems to be necessary once I don't have the mainsail gimbal and have to control via reaction wheel and some (small) control surfaces.  It feels like the PID should tune itself based on how much torque (from all sources) was available and how much rocket mass you needed to turn?  I suspect kOS and Mechjeb already have code that does something similar because I haven't had to think about this kind of behavior before...  Feel like its a bug and not a feature, although if its a feature, it should probably be documented how to scale it yourself?  It was a bit surprising, and my initial train of thought was that something was buggy with the autopilot where it stopped working once I cut the engines...

[djungelorm]

18 minutes ago, Jim DiGriz said:

So, does the PID in the autopilot need to autotune itself a little better?  With a mainsail taking off its a bit too aggressive and when I pitch over it 10 degrees it overshoots and wobbles.  Then I was having all kinds of trouble with the rocket tumbling once I cut the throttle, and what I just discovered is that jacking the PID up to 10,0,0 seems to be necessary once I don't have the mainsail gimbal and have to control via reaction wheel and some (small) control surfaces.  It feels like the PID should tune itself based on how much torque (from all sources) was available and how much rocket mass you needed to turn?  I suspect kOS and Mechjeb already have code that does something similar because I haven't had to think about this kind of behavior before...  Feel like its a bug and not a feature, although if its a feature, it should probably be documented how to scale it yourself?  It was a bit surprising, and my initial train of thought was that something was buggy with the autopilot where it stopped working once I cut the engines...

The PID currently does no auto-tuning - but I agree it is something that needs to be added. I had a look at the MechJeb/kOS/RemoteTech autopilot code a while ago (more than a year I think!) but couldn't wrap my head around how they do their PID tuning. The code seems rather obfuscated... There was also some discussion back on pages 13/14 about add auto-tuning. @artwhaley came up with the following heuristic that works well for the stock craft: mass/10 for P, mass/35 for I and mass/ 20 for D

[Jim DiGriz]

20 minutes ago, djungelorm said:

The PID currently does no auto-tuning - but I agree it is something that needs to be added. I had a look at the MechJeb/kOS/RemoteTech autopilot code a while ago (more than a year I think!) but couldn't wrap my head around how they do their PID tuning. The code seems rather obfuscated... There was also some discussion back on pages 13/14 about add auto-tuning. @artwhaley came up with the following heuristic that works well for the stock craft: mass/10 for P, mass/35 for I and mass/ 20 for D

Yeah I'm just drinking some coffee and surfing through the kOS code, and I don't quite grok it either.  I still don't know what they're using Quaternions for, which I think might be related?  I had enough QM to understand quaternions as math, but I don't understand quaternions as control theory...

That PID tuning looks interesting, but I think it also needs to scale based on the torque you've got available.  P at least has to get jacked up if your reaction-wheel-to-mass ratio is low.  I'd think you'd also want to use moment of inertia rather than mass, although for space stations that were very long and thin, maybe not since it would tend to rip them apart...

[Jim DiGriz]

So I think here is where the pitch value is getting set and the important bit here is that its trying to achieve a "target torque" based on the "control torque":

https://github.com/KSP-KOS/KOS/blob/4bcdb9604f8c575e43935c2e54953ec090be2f0a/src/kOS/Binding/SteeringManager.cs#L962

The PID controller output for the target pitch torque is here:

https://github.com/KSP-KOS/KOS/blob/4bcdb9604f8c575e43935c2e54953ec090be2f0a/src/kOS/Binding/SteeringManager.cs#L933

But there's also a PID controller for the pitch angular velocity:

https://github.com/KSP-KOS/KOS/blob/4bcdb9604f8c575e43935c2e54953ec090be2f0a/src/kOS/Binding/SteeringManager.cs#L920

This block just calculates the angular error:

https://github.com/KSP-KOS/KOS/blob/4bcdb9604f8c575e43935c2e54953ec090be2f0a/src/kOS/Binding/SteeringManager.cs#L899-L911

Then as input to the above there's this ugly-ass torque calculation method which is just Reaction Wheels + RCS + Gimballing Engines + Static Engines:

https://github.com/KSP-KOS/KOS/blob/4bcdb9604f8c575e43935c2e54953ec090be2f0a/src/kOS/Binding/SteeringManager.cs#L636-L645

There's some "torque adjustment stuff" but that looks like its only enabled in debug mode:

https://github.com/KSP-KOS/KOS/blob/4bcdb9604f8c575e43935c2e54953ec090be2f0a/src/kOS/Binding/SteeringManager.cs#L355

User tweakables are applied here as as pitchTorqueAdjust (0.0) and pitchTorqueFactor (1.0)

https://github.com/KSP-KOS/KOS/blob/4bcdb9604f8c575e43935c2e54953ec090be2f0a/src/kOS/Binding/SteeringManager.cs#L874

And I think to start with you could simply use vessel.findLocalMOI (which I think is baked into the game?), there's a bunch of code here which seems to try to work around deficiencies in it:

https://github.com/KSP-KOS/KOS/blob/4bcdb9604f8c575e43935c2e54953ec090be2f0a/src/kOS/Binding/SteeringManager.cs#L536

I think all the adjustMomentOfInertia and adjustTorque code wouldn't be necessary for a minimum viable PID tuning product...

It looks like updateTorque() and specifically that awful calculation of all the torque from the engines is the worst bit.  If you omit the adjustTorque/MOI code then the rest of the calculations look reasonably straightforwards, although I have to admit I have no idea why there's two different PID controllers for each axis...

[artwhaley]

Welcome to the rabbit hole.  

 

You're absolutely correct that the right way to do it is to figure up the MOI, mass, torque, and then center of action and relative torque of RCS and aero surfaces... and relate all of that to each other in a mathematical way...  I drove myself nuts trying to wrap my head around all of that and make it into an algorithm that wouldn't use all the cpu cycles.  I don't believe there's a baked in way to gather MOI...  I suspect that's an extension method somewhere in KOS maybe?  I was pondering trying to relate COM to the bounding box dimensions to get at it...  

 

So I went the opposite way and started trying to come up with a simple algorithm that got a 'close enough.' The theory being that if a vessel is basically stable enough to fly by hand, that means that all the important parameters - mass, moi, control systems and their arrangement are basically in balance 'enough', that is, the relationships are within a range of values that makes the vessel controllable and so we don't have to concern ourselves with detailed analysis...   thus the mass-only equation.  It's not right, but one can assume that for any reasonably designed craft, as MOI went up, the designer did something to give it more control authority.  If not...  doing math to tell us how screwed we are doesn't really help.  

I built this app in C# to let me tweak values by hand and watch a graph of heading error, so I could try to get a rough 'sense' of what values worked.

Do you see any practical need for more features than:

function to manually set PID... so someone with a special use case can do all the math they want (in their external app -outside KSP's thread) and then set the values by hand.

Turn rate and roll rate modifiers that specifically address the space station scenario - allowing a user to say "it's not essential that this vessel gets oriented quickly...  take your time and be careful..."

An autotune function that can be fired once when called that uses Mass alone to make a best guess about what sort of control inputs this vessel needs...

An autotune feature that can be togged on or off by setting a boolean, that does the calculations every cycle...

And maybe a tweakable "agression" setting for the autotune feature that would let you further scale the P values it generates, for times when simple mass isn't enough information to go on?

 

[Jim DiGriz]

So, kOS uses "findLocalMOI", but I can't see that offered anywhere in kOS when I search the repo, there's just that one hit on that one line.

Google search turns it up here:  https://anatid.github.io/XML-Documentation-for-the-KSP-API/class_vessel.html

That looks like its just the KSP internal API?  https://anatid.github.io/XML-Documentation-for-the-KSP-API/index.html

Anyway, I'd think that off of the vessel you could hang some methods something like:

- MOI (just that thing presuming it really is in KSP base)

- adjustedMOI (reserved; unimplemented for now)

- torqueRCS (the RCS bit of updateTorque)

- torqueReaction (the Reaction Wheel part)

- torqueEngine (the awfully complicated bit)

And maybe you could break torqueEngine up into torqueGimbal and torqueStatic, but maybe YAGNI...

With those exported as streams, then you could prototype your own PID controllers that used them.

torqueEngine looks like the only really ugly bit to implement as long as we don't bother with adjustedMOI -- and assuming we can get MOI out of the base game and google isn't wrong there...

[djungelorm]

Agreed that these should be added to the vessel class. For now lets just go with the 5 RPCs you suggest. I've added a github issue for this here: https://github.com/krpc/krpc/issues/212

We could also expose some more "low level" properties, so that people can compute these quantities themselves. For example, you can currently get the thrust and gimbal range of an engine. If we also add a thrust vector, you could compute the engine torque in the client. And then separate out torqueGimbal and torqueStatic if you need it.

[djungelorm]

I've released v0.2.2. Here are the highlights:

• Java client
• C++ client now supports streams and includes autotools and cmake build scripts
• Lots of bug fixes

A full changelog can be found here: https://github.com/krpc/krpc/releases/tag/v0.2.2

[Rodhern]

This is mentioned in the change log: "Remove support for blizzy's toolbar, in favour of using the stock applauncher".

Is there a particular reason for that?

[djungelorm]

I thought it was unnecessary, as there are the stock applauncher buttons.

[hvacengi]

Hi there.  Some one over in the kOS chat mentioned seeing this pop up in the thread.  I'm the dev who contributed the current steering manager in kOS and would be happy to discuss how it came to be, as well as ways that we can make it better!

My code isn't well documented at this point as released, but I have a development copy that is progressively getting better documentation (and fixing a few nagging bugs).  I can also point you to the source for the math we used in the torque tuning, which I will take no credit for since that was with the help of another contributor with a much better understanding of control theory than I have 

The rational for the two controllers per axis is mostly an attempt to improve predictability.  We were able to relatively "easily" create a auto-tuned PID for torque based on angular velocity, but it was more difficult to go straight from angular error to torque.  So, we created an intermediate step.  It's actually how most of my controllers in kOS itself are implemented as well.

The MoI adjustment stuff was an attempt at improving the "learning" of the code.  There seems to be some value I cannot account for that reduces the effect that torque has on the vessel in low MoI applications.  So there were two theories, that the MoI needed to be tweaked, or that the Torque needed to be tweaked.  It turned out that tweaking the "available" torque was more stable than the MoI, but I didn't want to remove it completely so I just disabled it.  When compiled in Debug mode you can turn torque and MoI adjustment on or off (both are independent settings) to toy with it.  I've since found an additional equation which accounts for angular velocity about the other two axes which may explain the observed difference in resultant torque.

You can see our "basic" explanation of the steering manager's logic here: http://ksp-kos.github.io/KOS_DOC/commands/flight/cooked.html#cooked-steering-s-use-of-pid-controllers  This section wasn't really written to explain the underlying code to another programmer, but it at least will help you with some of our logic.  I'm also planning on writing a documentation page that includes the math and logic in a more in-depth manor (if for no other reason than for me to not be the only dev writing steering code in the future).

The ` findLocalMOI` method is indeed exposed by KSP.

Sorry for the "uglyness" of the available torque calculation.  There's a lot that goes into that calc, and a lot of checking to see if things are turned on.  As near as I can tell, there is no way to get the total information out of KSP itself.  When they go through the physics update, it iterates through each part and adds the appropriate force/torque based on the control ratio, but the "available" total isn't stored anywhere that I could see.

Please feel free to reach out if you have any questions.  I'm not on the forums very often (I'll try to check in for the next couple of days at least) but you can always reach out via github, the kOS reddit, and I have started lurking in the #kspmodders IRC channel on esper.

[Kerbart]

1 hour ago, hvacengi said:

Hi there.  Some one over in the kOS chat mentioned seeing this pop up in the thread.  I'm the dev who contributed the current steering manager in kOS and would be happy to discuss how it came to be, as well as ways that we can make it better!

My code isn't well documented at this point as released, but I have a development copy that is progressively getting better documentation (and fixing a few nagging bugs).  I can also point you to the source for the math we used in the torque tuning, which I will take no credit for since that was with the help of another contributor with a much better understanding of control theory than I have 

The rational for the two controllers per axis is mostly an attempt to improve predictability.  We were able to relatively "easily" create a auto-tuned PID for torque based on angular velocity, but it was more difficult to go straight from angular error to torque.  So, we created an intermediate step.  It's actually how most of my controllers in kOS itself are implemented as well.

The MoI adjustment stuff was an attempt at improving the "learning" of the code.  There seems to be some value I cannot account for that reduces the effect that torque has on the vessel in low MoI applications.  So there were two theories, that the MoI needed to be tweaked, or that the Torque needed to be tweaked.  It turned out that tweaking the "available" torque was more stable than the MoI, but I didn't want to remove it completely so I just disabled it.  When compiled in Debug mode you can turn torque and MoI adjustment on or off (both are independent settings) to toy with it.  I've since found an additional equation which accounts for angular velocity about the other two axes which may explain the observed difference in resultant torque.

You can see our "basic" explanation of the steering manager's logic here: http://ksp-kos.github.io/KOS_DOC/commands/flight/cooked.html#cooked-steering-s-use-of-pid-controllers  This section wasn't really written to explain the underlying code to another programmer, but it at least will help you with some of our logic.  I'm also planning on writing a documentation page that includes the math and logic in a more in-depth manor (if for no other reason than for me to not be the only dev writing steering code in the future).

The ` findLocalMOI` method is indeed exposed by KSP.

Sorry for the "uglyness" of the available torque calculation.  There's a lot that goes into that calc, and a lot of checking to see if things are turned on.  As near as I can tell, there is no way to get the total information out of KSP itself.  When they go through the physics update, it iterates through each part and adds the appropriate force/torque based on the control ratio, but the "available" total isn't stored anywhere that I could see.

Please feel free to reach out if you have any questions.  I'm not on the forums very often (I'll try to check in for the next couple of days at least) but you can always reach out via github, the kOS reddit, and I have started lurking in the #kspmodders IRC channel on esper.

Thank you @hvacengi! That is amazingly helpful... I think. The little schematic on github makes it very easy to understand how the two PID controllers work, in two stages, so to say. *Checks watch* @djungelorm; since this was posted an hour ago I assume you've implemented it? Where's the update?   More seriously, that will still be quite the effort to get it done. This kind of coding is way beyond my paygrade, but by all means let me know if and where I can help out (I do control the velocity of my kRPC launches with a self-made PID controller, for what it's worth).

 

[djungelorm]

8 hours ago, hvacengi said:

You can see our "basic" explanation of the steering manager's logic here...

Thanks for the pointers I've had a quick read and the high level overview makes sense. Time to go read in some more detail.

6 hours ago, Kerbart said:

*Checks watch*

This autopilot overhaul might take a bit longer than usual Going to need to learn a bit more physics...

[sviridovt]

I need some help, I've been trying to figure this out for a better part of 3 hours. I've compiled everything correctly and have the libkrpc.so file now. This is where the issue comes in, I can't for the live of me get it to work in Eclipse on Ubuntu.

Here are the images from my attempts: http://imgur.com/a/NIdOr

I have tried just importing the .hpp files which allows it to find krpc.hpp (and the other files) but leads to a bunch of asio errors (mostly reference stuff).

Thanks! Really want to set this up

[djungelorm]

Looks like you need to set the include path to the directory containing krpc.hpp so that the compiler can find it.

E.g. with g++ you want to pass this path to the -I flag. And use -lkrpc to link against the .so file, and pass the path to the directory containing it as the -L flag:

g++ main.cpp -I/path/to/krpc/headers -L/path/to/krpc/library -lkrpc

In eclipse I'm guessing there is some place in the project settings to set the include path to the directory containing krpc.hpp, although I'm not familiar with eclipse.

Edit: you also need to install and link against the ASIO and protobuf (version 3.0.0-beta2) libraries, as kRPC depends on these. Links below. Looks like I forgot to mention this in the docs, sorry!

http://think-async.com/

https://github.com/google/protobuf/releases

Edited March 1, 2016 by djungelorm

[sviridovt]

7 hours ago, djungelorm said:

Looks like you need to set the include path to the directory containing krpc.hpp so that the compiler can find it.

E.g. with g++ you want to pass this path to the -I flag. And use -lkrpc to link against the .so file, and pass the path to the directory containing it as the -L flag:

g++ main.cpp -I/path/to/krpc/headers -L/path/to/krpc/library -lkrpc

In eclipse I'm guessing there is some place in the project settings to set the include path to the directory containing krpc.hpp, although I'm not familiar with eclipse.

Edit: you also need to install and link against the ASIO and protobuf (version 3.0.0-beta2) libraries, as kRPC depends on these. Links below. Looks like I forgot to mention this in the docs, sorry!

http://think-async.com/

https://github.com/google/protobuf/releases

I added all of the libraries correctly (I think), but now I am stuck on this: http://imgur.com/cQk9UCi

 

Thanks for helping!

[hvacengi]

12 hours ago, djungelorm said:

Thanks for the pointers I've had a quick read and the high level overview makes sense. Time to go read in some more detail.

This autopilot overhaul might take a bit longer than usual Going to need to learn a bit more physics...

My first commit for the steering revamp was August 8, 2015.  My final non-review commit (so my last major change that wasn't doing house keeping) was October 13, 2015.  But I didn't have a working deterministic version to work from, I was adapting generic PID's instead.  Oh, and that was my busiest stretch of the year at work 

If you're interested in the math behind the pitch rate controller (which I really need to get into our documentation) check out this imgur album with notes from Matt that were the basis of our tuning: http://imgur.com/a/UScQf

[djungelorm]

1 hour ago, sviridovt said:

I added all of the libraries correctly (I think), but now I am stuck on this: http://imgur.com/cQk9UCi

 

Thanks for helping!

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;
}