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

[artwhaley]

The more i think on autotuning the PID...  the more I realize how complicated it is to do the way I was thinking...  

To start with, to get MOI, I'd have to compare each part's mass and position with the bounding box to generate a number that is essentially a percentage that tells you where the center of mass distribution is in relationship to the bounding box?

But...  it gets worse when trying to figure out the center and scale of effort that the control systems can generate?  It's easy enough to find the center of effort of all the reaction wheels, and their strength in each adjusted axis...  but then for RCS you have to do the same thing if it's enabled...  which I think first involves summing all the thrust transforms, multiplied by their distance to the COM to find the center of effort, and then summing the x,y and z components of each vector (again multiplied by distance to COM) to figure out how much authority the vessel has on each axis?   Then you have to do the same thing on the control surfaces... but they don't have a thrust transform, so you just have to sum their pitch roll and yaw magnitudes and multiply each of those by the distance to the COM?  This...  seems like a lot of computation to add to the autopilot update method...  so you'd probably want to do it periodically.  

What about adding a function that executes an "Autotune" on command, instead of running in continuously in the background?  

I sort of feel like in that case something simpler can be done...  like 'automated manual' tuning...  essentially the function would look at rate of change in the axis it was analyzing and induce change if there isn't sufficient movement already for the analysis, set all three PID parameters to zero, then ramp up P until it crosses the target heading, then back it off by some fixed amount (determined experimentally in development)...  then ramping up I until oscillation is within 1% and simply setting D to be some percentage of P (also determined experimentally in development.)

Is there a simpler approximation you can think of?  Am I nuts!?

[Kerbart]

13 hours ago, artwhaley said:

(...)

But...  it gets worse when trying to figure out the center and scale of effort that the control systems can generate?  It's easy enough to find the center of effort of all the reaction wheels, and their strength in each adjusted axis...  but then for RCS you have to do the same thing if it's enabled...  which I think first involves summing all the thrust transforms, multiplied by their distance to the COM to find the center of effort, and then summing the x,y and z components of each vector (again multiplied by distance to COM) to figure out how much authority the vessel has on each axis?   Then you have to do the same thing on the control surfaces... but they don't have a thrust transform, so you just have to sum their pitch roll and yaw magnitudes and multiply each of those by the distance to the COM?  This...  seems like a lot of computation to add to the autopilot update method...  so you'd probably want to do it periodically. 

 

Actually you don't have to find the center of the reaction wheels. They deliver pure torque and that is quantity that works regardless to where it's delivered in relation to the COM. It's hard to wrap your head around it because it's counter-intuitive but that's how torque works. In general though we get confronted with off-center forces which results in torque, and to calculate that torque the distance to COM does matter. So yes, the calculation work does remain for RCS and control surfaces.

A simplified approach though would be to use only the mass as a parameter for auto-tuning. It's not perfect, but assuming  sane builders will add more control authority (be it bigger/more reaction wheels, larger control surfaces, more RCS ports) to heavy vehicles.

Or maybe leave it to the user to set the P-factor for the autopilot (I use a PID controller for ascent velocity and I don't have to bother with the i and d parameters) with some guidelines on how to tune it in.

Edited February 12, 2016 by Kerbart

[artwhaley]

I was starting to think the same thing @Kerbart...  I think if Mass alone isn't enough, mass and the bounding box dimensions should be for sure...  as that lets you make a guess as to how far that mass might be from the COM?  To try to get a feel for what sorts of values work with different types of vessel, I've built this little testing app in c#:  

It exposes all the autopilot parameters and graphs the current error so you can visually get a feel for how it's doing.  If any other nerds are amused by PID tuning...  shout at me and I'll share it...

[djungelorm]

I think some basic auto-tuning that works in most cases is the way to go. I think we should keep the autopilot built into kRPC as simple as possible. If people need more complex autopiloting then this can be done in the client. I had doubts about adding a built-in autopilot initially, as the whole idea of this mod is to write your own scripts! But I quickly realised that at least a basic autopilot is required for people to get started with the mod. It would suck if you needed to figure out how to code an autopilot and write a load of code just to get your first ship into orbit!

I like @Kerbart's idea of basing the autotuning on mass. In terms of when to do the tuning, I think it should suffice to tune the PID when the autopilot is first engaged, and also provide a retune() method so that the user can retune it if necessary. We should also expose all the tunable parameters so they can be tweaked by the client, and let people do their own tuning if they like. To this end, I'm making some changes to the existing autopilot to expose all the tunable parameters so that we can play around with tuning it.

Edit: and I'm looking into adding separate P/I/D gains for pitch/yaw/roll.

Edited February 16, 2016 by djungelorm

[djungelorm]

I've ported the autopilot to a python script. This should allow us to tweak things more easily without needing to reload KSP. https://gist.github.com/djungelorm/8e7faa1a3a9e4f0b09ef

[Benji]

Has someone tried to use krpc via arduino?

[artwhaley]

5 hours ago, djungelorm said:

I've ported the autopilot to a python script. This should allow us to tweak things more easily without needing to reload KSP. https://gist.github.com/djungelorm/8e7faa1a3a9e4f0b09ef

I'll play with it tomorrow!  For all but really low mass ships I'd sort of settled experimentally on mass/10 for P, mass/35 for I and mass/ 20 for D.  These aren't magical values...  but they got close for a wide variety of ships in testing -rockets both during launch and orbital maneuvers, and I tried them on all the stock vertical launch spaceplanes and a couple of the purely atmospheric SPH stock craft.  If it's that simple it could be calculated more frequently by the autopilot without much penalty.  In my test I was recalculating them in a 10hz loop.  I wasn't using the turn rate modifiers...  but I've added them to my testing app and will play with them, after I look at the code and understand more about what they're doing.  

 

1 hour ago, Benji said:

Has someone tried to use krpc via arduino?

I haven't, but it's one of the things on my todo list!  It would be VERY easy to use python to bridge between KSP and Arduino...  with a lot more flexibility than even the dedicated Arduino plugin offers... as you could do some processing in between the micro controller and the plugin... and maybe a more efficient architecture since the com port stuff wouldn't be happening inside the KSP program?  I've also looked at some of the protobufs on micro controller libraries...  thinking about the possibility of using some of the TI connected launchpads, arduino with ethernet shield or esp8266 controllers would be for making network connected peripherals!  

 

Edited February 16, 2016 by artwhaley

[djungelorm]

2 minutes ago, artwhaley said:

For all but really low mass ships I'd sort of settled experimentally on mass/10 for P, mass/35 for I and mass/ 20 for D.

Awesome thanks I'll have a go with those values. Did you just leave the max speeds/multipliers with the default values?

1 hour ago, Benji said:

Has someone tried to use krpc via arduino?

I think @Antipaten was using krpc from an arduino.

[artwhaley]

3 minutes ago, djungelorm said:

Awesome thanks I'll have a go with those values. Did you just leave the max speeds/multipliers with the default values?

 

Yes, I left them at the default.

[langabi]

@artwhaley, I for one am super excited for the release of your kRPC/Mechjeb module -- I really want to be able to focus on putting together interesting automated mission profiles, so having Mechjeb as a "library" of high level ship commands would be fantastic!

[Antipaten]

On 2/16/2016 at 9:13 AM, djungelorm said:

I think @Antipaten was using krpc from an arduino.

I haven't used Arduino to connect dirctly to kRPC. I use a Python script for the RPC calls and relay the data to Arduino using serial.

Edited February 17, 2016 by Antipaten

[Kerbart]

On 2/16/2016 at 1:53 AM, Benji said:

Has someone tried to use krpc via arduino?

That might actually be better discussed in the release thread. I have no experience with it, but why not hook up the Arduino to a Raspberry Pi? RP comes with Python already, and interfacing to an Arduino is easy, or so I'm told.

[Rodhern]

On 1/28/2016 at 2:10 PM, Kerbart said:

...

Better but now I have the dreaded Protobuf problems...

EDIT AGAIN:
After downloading the Protobuf 3.0 b2 wheel file and "manually" installing it with pip, things work fine!

Hey Kerbart.

Could you explain in a little more detail how to download and install the Protobuf.

From Visual Studio 2013 FSI (F-Sharp Interactive) I get this error: "Could not load file or assembly 'Google.Protobuf, Version=3.0.0.0, Culture=neutral, PublicKeyToken=a7d26565bac4d604' or one of its dependencies.". I don't know if it is related to your problem, but it might be (?).

Thanks in advance

Rodhern

Edit: I see the dll file is in the GameData folder. But the error message says "A strongly-named assembly is required.". Do you know how I get past that?

Edited February 20, 2016 by Rodhern
added info

[Kerbart]

1 hour ago, Rodhern said:

Hey Kerbart.

Could you explain in a little more detail how to download and install the Protobuf.

(...)

Edit: I see the dll file is in the GameData folder. But the error message says "A strongly-named assembly is required.". Do you know how I get past that?

It took me some googling to locate a Protobuf 3.0 whl file somewhere. I forgot where, but if I found it once, I can find it again. I then removed the existing protobuf from my python site packages folder (C:\Python27\Lib\site-packages but yours may vary of course) and installed the wheel file through pip.

Let me see if I can locate the protobuf file.

Well, that was easy, you can find it here: https://pypi.python.org/pypi/protobuf/3.0.0b2

What I noticed was that I had to install it with the wheel file, a regular pip install (with auto download) didn't do it.

 

Let me know if you run into any challenges

 

Edited February 20, 2016 by Kerbart

[Rodhern]

Ahh, yes, good trick, do googling; and if it doesn't work the first time do it again :-)

I found the Dot Net equivalent ("Google.Protobuf.dll") here: Google Protobuf at Nuget

Thanks!

[Kerbart]

4 minutes ago, Rodhern said:

Ahh, yes, good trick, do googling; and if it doesn't work the first time do it again :-)

I found the Dot Net equivalent ("Google.Protobuf.dll") here: Google Protobuf at Nuget

Thanks!

Ooh, you're not connecting through the Python client? I didn't figure that out.

[djungelorm]

1 hour ago, Rodhern said:

Ahh, yes, good trick, do googling; and if it doesn't work the first time do it again :-)

I found the Dot Net equivalent ("Google.Protobuf.dll") here: Google Protobuf at Nuget

Thanks!

FYI: don't use the protobuf DLL from GameData. I had to modify it to work with KSP and Unity's runtime requirements. (More info here: https://github.com/google/protobuf/issues/644 and here: https://github.com/djungelorm/protobuf/commit/c724f048b85fe83df24f39b326555e6369b08e97)

The one on nuget is the one you want.

[artwhaley]

I think my Mechjeb service addon is ready for people to play with if they want to.  

The .dll is at https://github.com/artwhaley/krpcmj/blob/master/krpcmj.dll and just needs to go into your gamedata directory...  I've been tossing it in the krpc directory to keep up with it.

You, of course, have to have the current version of kRPC and Mechjeb installed for this plugin, that connects the two, to work.  I'm using dev build #563 of mechjeb.    Something I hadn't know going into this - Mechjeb actually changes frequently in ways that don't affect the casual user that much, but do affect the api from time to time -  so I'll mostly be keeping in step with the dev builds when I can.

The source is at : https://github.com/artwhaley/krpcmj

And the documentation is at https://github.com/artwhaley/krpcmj/wiki

Of Particular note are the example scripts: https://github.com/artwhaley/krpcmj/wiki/Example-Scripts  I wanted to show off some of the power of using kRPC with Mechjeb available as a library of prewired functions.  The examples range from simple 15 line scripts for launch or dock with a nearby craft, on up through a 50 line script that does an ascent, plane change, transmunar injection, course correction on Munar approach, circularization at Mun, and then a landing, all with no user intervention after you hit go.

I'm certain there are functions that still aren't working as designed... there's a lot of Mechjeb to wrap my head around.   If anyone fiddles with it, let me know what you think and what seems broken or more complicated than it should be.

Also, the documentation is all aimed at Python at the moment, as i'm using that for testing.  It should work fine with the other libraries as well.  I'll generate c# and c++ client stubs soon and get them uploaded too.

@djungelorm, if I eventually figure out how to use reflection so Mechjeb doesn't remain a compile time requirement...  would you like this contributed like the IR and KAC services?  Or would you rather me keep it separate so people can grab it if they want it?  

[Rodhern]

Hi djungelorm

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

The practical advantage of F# over C# in this case is that you can issue F# commands directly from F-Sharp Interactive (the FSI window in Visual Studio).

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

You are welcome to copy useful parts to the kRPC documentation if you like.

Best regards
Robert

Edit: The snippet address changed.

Edited April 16, 2016 by Rodhern
updated link

[djungelorm]

On 2/20/2016 at 1:47 PM, artwhaley said:

 

@djungelorm, if I eventually figure out how to use reflection so Mechjeb doesn't remain a compile time requirement...  would you like this contributed like the IR and KAC services?  Or would you rather me keep it separate so people can grab it if they want it?

Nice work Yes I think including it in the main repo in the same manner as IR and KAC would be good. I'll pm you about doing this.

3 hours ago, Rodhern said:

Hi djungelorm

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

The practical advantage of F# over C# in this case is that you can issue F# commands directly from F-Sharp Interactive (the FSI window in Visual Studio).

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

You are welcome to copy useful parts to the kRPC documentation if you like.

Best regards
Robert

Cool! I'll add a page to the docs with links to "third party clients and scripts". Would be a good place to keep pointers to things like this, and also to point to TeWu's ruby client.

[Kerbart]

Kudos to @djungelorm and @artwhaley for all the hard work that's being done! Without you guys we'd be stuck with alternatives that don't use languages like Python or C#!

[SuperManitu]

I'm not sure how this works:

In combination with RemoteTech, do you have some sort of mode where programs execute if they had a Computer on Board or does this mod only "play" ground station?

EDIT: As I try to get the C++ client working, how do I include/link to the C++ client? After including Asio and Protobuf and building the protobuf lib and linking against it, I still get nasty LNK2001 unresolved symbol errors

Edited February 24, 2016 by SuperManitu

[djungelorm]

On 2/24/2016 at 10:08 AM, SuperManitu said:

I'm not sure how this works:

In combination with RemoteTech, do you have some sort of mode where programs execute if they had a Computer on Board or does this mod only "play" ground station?

EDIT: As I try to get the C++ client working, how do I include/link to the C++ client? After including Asio and Protobuf and building the protobuf lib and linking against it, I still get nasty LNK2001 unresolved symbol errors

RemoteTech functionality is all in the Comms class: http://krpc.github.io/krpc/python/api/space-center/comms.html kRPC is added to RemoteTech as a "sanctioned pilot", so kRPC controls vessels independently from RemoteTech and its signal delay etc.

Sorry to hear you're having problems getting the C++ client to compile. If you post an error log I can take a look?

[SuperManitu]

6 hours ago, djungelorm said:

Sorry to hear you're having problems getting the C++ client to compile. If you post an error log I can take a look?

Sure, errors are here: http://qs.lc/bjp4k
This is my include folder: http://qs.lc/loto0
And the lib of the google protobuf that I compiled is included in the linker as well.

[djungelorm]

2 hours ago, SuperManitu said:

Sure, errors are here: http://qs.lc/bjp4k
This is my include folder: http://qs.lc/loto0
And the lib of the google protobuf that I compiled is included in the linker as well.

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.