djungelorm

[1.4.x,1.3.x,1.2.2] kRPC: Remote Procedure Call Server (v0.4.7, 27th July 2018)

Recommended Posts

Hi!

I've been trying to use the Service API to implement a simple service that would give me access to some parts of KSP API. Unfortunately, loading the service dll (dropping it in GameData) breaks kRPC for me: when connecting to the server, the client is detected and accepted in KSP/serverside, but the krpc.connect() call in Python just hangs. Stopping the server while it thinks that the client is connected (and the client thinks it's still connecting) produces this: https://gist.github.com/age/5c250a8ea497c7f779f6

The minimal example I've come down to is this: https://gist.github.com/age/e67d0fedc845bf955763 ; I've built the git version of kRPC on Windows 8 x64 using Xamarin studio (monodevelop).

Any idea why this happens and possible fix? I'm writing here an not creating an issue on github because this could be a problem on my side; please tell me if I should go ahead and create an issue.

EDIT: adding my own vector class seems to works, however: https://gist.github.com/age/7b8a8b32ec0d4101638b

Edited by age

Share this post


Link to post
Share on other sites

I've been messing about with this for a while now, it's brilliant! I've made graceful shuttle launch scripts, automated hovering scripts.....

I'm just wondering if there is much development going on with it now? The current system seems to work really well but just a few additions would allow people to attempt a much larger variety of scripts. I mean thrust/weight information, surface velocity vector (not just scalar), and RCS control.

Any plans for any of that in the future?

Thanks.

Share this post


Link to post
Share on other sites

I'm just wondering if there is much development going on with it now? The current system seems to work really well but just a few additions would allow people to attempt a much larger variety of scripts. I mean thrust/weight information, surface velocity vector (not just scalar), and RCS control.

Any plans for any of that in the future?

I hope to get back to playing KSP and working on this mod at some point. I've not had time to do so over the last few months :(

Share this post


Link to post
Share on other sites
I've been messing about with this for a while now, it's brilliant! I've made graceful shuttle launch scripts, automated hovering scripts......

in python? care to share? :D maybe there should be a repository somewhere of scripts, even if just an additional wiki page with some gist links...

I hope to get back to playing KSP and working on this mod at some point. I've not had time to do so over the last few months :(

YAY! I've been playing with integrating kRPC into a python program to serve as an OS for a ship/multiple ships, with both a web and CLI, scripting tools, multiple user login and other features (like some smoothie charts from websockets backed by krpc calls ala/to augment/to replace telemachus), but I'm running into an issue with the protobuf decoding using windows server + linux host. Wanted to speak up to make sure you saw there was definitely interest in continued development :D

Now that I've posted this, I need to go start a new thread in the add-on dev forum...

Share this post


Link to post
Share on other sites

I am just now seeing this fascinating project before I have to go to sleep! It might be a contender for Kerminal integration.

I expect I'll be reading into this more tomorrow.

Share this post


Link to post
Share on other sites
I am just now seeing this fascinating project before I have to go to sleep! It might be a contender for Kerminal integration.

I expect I'll be reading into this more tomorrow.

Kerminal definitely caught my eye, and is impressive to say the least, and a level below where I've been looking to work (and by that I mean working at that low a level would be over my head!) I had decided to use python, and from there, an existing MUD framework to supply a lot of the UI (or at least a framework for it), along with the built-in web interface. using krpc is as easy as using the existing python client and integrating the calls as interpreted MUD commands and extending from there! the existing code may be a bit bloated for what it needs to do in KSP, but otherwise useless bits could be shed off, and it seems to be under active development. I'd like to get into data visualization and logging, saving/loading of scripts/configs, calculators and helpers, external visualization, controlling multiple ships, remote tech integration, interfaces for popular mods like KAS and infernal robotics, a voice interface - but mostly heading towards a human language interface to a learning AI...

The idea has evolved a bit over time, but essentially it's to use kRPC to turn the python MUD into an AI for your ship, and when I say python MUD, I do have to remind myself of its built-in websockets and web GUI, otherwise I lose the interest of all those not interested in the CLI ;)

Share this post


Link to post
Share on other sites

Wondering if I can get help building your project. I managed to get the .proto files built correctly, but for somereason, git is failing to apply the .patch file. Im not an expert on .patch files, but when I run "git apply krpc-proto.patch", it complains about trailing whitespace on line 9. Then I get a patch failed error for KRPC.cs:861. Finally, i get an error that src/kRPC/Schema/KRPC.cs: patch does not apply.

Any idea what my next step should be?

--Edit--

My goal is to create a java api since it seems the .proto file can generate java code. This would allow users to program their rockets with a scripting language called Scala as well.

--Edit 2-- Full error when running git apply with the 'v' switch

$ git apply -v krpc-proto.patch
krpc-proto.patch:9: trailing whitespace.
foreach (global::KRPC.Schema.KRPC.Service element in Services_List) {
Checking patch src/kRPC/Schema/KRPC.cs...
error: while searching for:

public override bool IsInitialized {
get {
foreach (global::KRPC.Schema.KRPC.Service element in ServicesList) {
if (!element.IsInitialized) return false;
}
return true;

error: patch failed: src/kRPC/Schema/KRPC.cs:861
error: src/kRPC/Schema/KRPC.cs: patch does not apply

Edited by Fred4106

Share this post


Link to post
Share on other sites

I know that Djungelorm has to put his attention to other things... but can anyone tell me how I can figure out the lattitude/longitude of a craft? I think I looked everywhere but couldn't find it.

Share this post


Link to post
Share on other sites

It’s been a while, but I now have a lot more free time and am keen to continue developing this :) So without further ado, I've released version 0.1.4 with lots of improvements - hoorah! Kerbalstuff link (and opening post has been updated)

The list of changes is rather long, but the highlights are improved reference frames and "streams" (no more sluggish polling loops!).

Two RPCs called "AddStream" and "RemoveStream" have been added. These are used to instruct the server to send the result of a procedure call on every frame update. This means polling loops are far more efficient - the client sets up the stream, then just continuously receives data from the server (without the need to repeatedly run an RPC - with all of the latency that that involves). For example, here's a python snippet that will loop until the altitude exceeds 70km.


import krpc
conn = krpc.connect(...)
vessel = krpc.space_center.active_vessel
flight = vessel.flight
altitude = conn.add_stream(getattr, flight, ‘true_altitude’)
while altitude() < 70000:
continue
conn.remove_stream(altitude)
print 'Vessel reached 70km'

It also supports python's "with" syntax:


import krpc
conn = krpc.connect(...)
vessel = krpc.space_center.active_vessel
flight = vessel.flight
with conn.stream(getattr, flight, ‘true_altitude’) as altitude:
while altitude() < 70000:
continue
print 'Vessel reached 70km'

- - - Updated - - -

Now to answer your long outstanding queries...

I've been trying to use the Service API to implement a simple service that would give me access to some parts of KSP API. Unfortunately, loading the service dll (dropping it in GameData) breaks kRPC for me...

Looks like the bug you are experiencing was a known bug in 0.1.3 (which has now been fixed). I tried your minimal code example with 0.1.4 and it worked fine.

Kerminal definitely caught my eye...

The idea has evolved a bit over time, but essentially it's to use kRPC to turn the python MUD into an AI for your ship, and when I say python MUD, I do have to remind myself of its built-in websockets and web GUI, otherwise I lose the interest of all those not interested in the CLI ;)

Wow! That sounds awesome. Very interested to see how it turns out.

Wondering if I can get help building your project….

I think git apply is reporting that error because the patch has already been applied, in which case you can safely ignore the error. When successfully applied, the patch should replace 'ServicesList' with 'Services_List' in src/kRPC/Schema/KRPC.cs (which is generated by the C# protobuf compiler). Are you trying to compile the project using the makefile?

I know that Djungelorm has to put his attention to other things... but can anyone tell me how I can figure out the lattitude/longitude of a craft? I think I looked everywhere but couldn't find it.

Not any more ;) Lat/long hasn’t been added yet - but it’s on the todo list!

This project is amazing, the possibilities are endless!

Congrats Djungelorm, I'm having lots of fun with it

Great to hear - thanks!

Share this post


Link to post
Share on other sites

Hello,

While the level of programming is a tad beyond me I am checking this out; I am looking for outside monitoring of all vessel resources (not all really just specific but I can live with all); not sure if there is a way to code a button for this in the Toolbar; also looking for the data to be available as a data output in game; I am slow and maybe there are programs out there that can already do this without the need for automatic control.

This is also similar to Ardinuo; not sure of the code as I havnt looked at that yet.

Cmdr Zeta

Share this post


Link to post
Share on other sites

Cool, getting this sort of information from outside of KSP is exactly the sort of thing kRPC is designed for!

For example, you could do something like the following to output the amount of LiquidFuel in the vessel once per second:


import krpc, time
conn = krpc.connect()
resources = conn.space_center.active_vessel.resources
while True:
print resources.amount("LiquidFuel")
time.sleep(1)

The API for getting resources is documented here: https://github.com/djungelorm/krpc/wiki/SpaceCenter-Service#resources-objects

(Although the documentation is rather lacking at the moment, I'm currently working on making it a lot better)

The arduino project does indeed do something similar, but as far as I understand it can only send the telemetry out via your computers serial port.

Share this post


Link to post
Share on other sites

As a heads up, it looks like you just moved where you host your docs, and the generation for the docs gives incorrect method names. Like the reference frames are all CamelCase, like vessel.SurfaceReferenceFrame, but in actuality they are snake_case vessel.surface_reference_frame. Poking at your code it looks like you have a method to change from CamelCase to snake_case, so your docs generator is pulling out unusable method names.

Share this post


Link to post
Share on other sites
It’s been a while, but I now have a lot more free time and am keen to continue developing this :) So without further ado, I've released version 0.1.4 with lots of improvements - hoorah!

Best KSP news in a long while! This makes me really happy!!

Share this post


Link to post
Share on other sites

Also, question. I think I am misunderstanding the unit vectors from the reference frames. I am trying to find the angle of pitch and yaw of a vessel from it's prograde vector. I am using vessel.direction(vessel.orbital_reference_frame) and vessel.flight(vessel.orbital_reference_frame).prograde. If a vessel is pointing prograde, I would expect the values of vessel.direction and flight.prograde to be nearly identical if in the same reference frame, but they are not.

Share this post


Link to post
Share on other sites

Your reasoning is sound - the two vectors should be identical. What values are you getting?

It worked when I tried it for a vessel in a 100km orbit around kerbin with SAS set to point the vessel prograde. Both vessel.flight(...).prograde and vessel.direction(...) returned vectors close to [0,0,1]


>>> import krpc
>>> conn = krpc.connect()
>>> v = conn.space_center.active_vessel
>>> f = v.flight(v.orbital_reference_frame)
>>> print f.prograde
(0.00014644889887349688, 1.2992696712065975e-07, 0.9999999892763523)
>>> print v.direction(v.orbital_reference_frame)
(0.0034958138000326655, 0.0005408300926894418, 0.9999937288501615)
>>>

Edit:

Also, if you want an easy way to get the pitch/heading/roll angles check out Flight.pitch, Flight.heading and Flight.roll: http://djungelorm.github.io/krpc/docs/python-api/flight.html#Flight.pitch

Edited by djungelorm

Share this post


Link to post
Share on other sites

Yeah, the numbers do work out when when in a complete orbit. I also want to be able to calculate my attitude against prograde during ascent and descent, and I get numbers that don't match when in the atmosphere/suborbital:

prograde:

(0.6492723060508789, -0.00322239392899013, 0.7605492020722537)

direction:

(0.8629220494448264, -0.004159275196002663, 0.5053202365175846)

I also tried that with surface reference frame, and similar results. I thought flight().velocity might be a solution for this suborbital problem, but all I can ever get that method to return is (0.0, 0.0, 0.0)

What I am trying to do is have a 2D display of the vessel's attitude, one relative to the surface (where flight().pitch, .heading etc will work out-of-the-box) and then another that is relative to the vessels trajectory, so you can see a capsules orientation during reentry, for example.

Share this post


Link to post
Share on other sites

Sorry I confused myself earlier... vessel.flight(vessel.orbital_reference_frame).prograde and vessel.direction(vessel.orbital_reference_frame) are not equivalent - they just happen to be close when the vessel's orbital speed is much larger than the rotational speed of kerbin.

What you want to compute is the angle between the vessels direction vector and its velocity vector, relative to the surface of kerbin (i.e. in reference frame vessel.orbit.body.reference_frame, whose origin is at the center of kerbin and which rotates with the planet.

The following code code outputs the two directions, and the angle between them:


import krpc, math
conn = krpc.connect()
vessel = conn.space_center.active_vessel
frame = vessel.orbit.body.reference_frame

while True:
# Get direction vector of vessel
d0 = vessel.direction(frame)

# Compute direction vector of motion
v = vessel.velocity(frame)
size = math.sqrt(v[0]*v[0]+v[1]*v[1]+v[2]*v[2])
d1 = (v[0]/size,v[1]/size,v[2]/size)

# Compute angle (in degrees) between vectors
try:
angle = abs(math.acos(d0[0]*d1[0]+d0[1]*d1[1]+d0[2]*d1[2])) * (180/3.14159)
except ValueError:
angle = 0

# Output it
print '(%5.1f,%5.1f,%5.1f)' % d0, '(%5.1f,%5.1f,%5.1f)' % d1, '%.2f' % angle

My guess is you were using a reference frame that is fixed relative to the vessel, so flight().velocity would indeed just return (0,0,0)

I think the term prograde is confusing when used to refer to direction vectors relative to the surface. 'prograde' is an orbital direction, so should only really be used to refer to orbits. I really need to document this with some pretty diagrams...

Edited by djungelorm

Share this post


Link to post
Share on other sites

Awesome, that did it. Thanks a bunch for the help!

Here is my code snippet for finding pitch and yaw relative to the vessels velocity vector, in case anyone else wants this down the road. Save them the headache of flipping triangles and axes like I did all day. :D


import krpc, math
conn = krpc.connect(name='Pitch/Yaw')
vessel = conn.space_center.active_vessel

while True:

# x north
# y normal to surface
# z forward

direction = vessel.direction(vessel.orbit.body.reference_frame)
velocity = vessel.velocity(vessel.orbit.body.reference_frame)

# x yaw
# y pitch
# z roll

# direction unit vector, with corrected axes
x0 = direction[1]
y0 = direction[0]
z0 = direction[2]

# calculate unit vector of velocity
magnitude = math.sqrt( velocity[0]**2 + velocity[1]**2 + velocity[2]**2 )
v = (velocity[0]/ magnitude, velocity[1]/ magnitude, velocity[2]/ magnitude)

# velocity unit vector, with corrected axes
x1 = v[1]
y1 = v[0]
z1 = v[2]

# calculate pitch
pitch = math.acos((x0*x1 + y0*y1 ) / (math.sqrt(x0**2 + y0**2) * math.sqrt(x1**2 + y1 **2))) * (180 / math.pi)
# pitch is positive if velocity is below attitude, negative if above (this is arbitrary)
if x0 > x1:
pitch = -pitch

# calculate yaw
yaw = math.acos((y0*y1 + z0*z1 ) / (math.sqrt(y0**2 + z0**2) * math.sqrt(y1**2 + z1 **2))) * (180 / math.pi)
# yaw is positive if velocity is left of attitude, negative if right (this is arbitrary)
if y0 < y1:
yaw = -yaw

print "pitch: {:+07.2f} yaw: {:+07.2f}".format(pitch, yaw)

I think the term prograde is confusing when used to refer to direction vectors relative to the surface. 'prograde' is an orbital direction, so should only really be used to refer to orbits. I really need to document this with some pretty diagrams...
Spacial reasoning is the hardest thing I encountered working on this so far, understanding which axis was the one I wanted to work with, etc, and especially knowing which reference frame I required.

Share this post


Link to post
Share on other sites

Glad it will be useful. Your documentation has been coming along nicely, which has been super helpful. :)

Share this post


Link to post
Share on other sites

Can anyone clarify the differences between the various frames of reference, and when you might want to use each of them? I am confusing myself all over the place.

Edited by Borogove

Share this post


Link to post
Share on other sites

So I have been working on a mission control-esque display using kRPC. Shows the vessels pitch, yaw and overall displacement relative to the velocity or prograde vector. Also can rotate the vector to match in game, give or take (some math is definitely a bit broken)

It's coming along quite nicely so far. kRPC has proven to be easy to code with.

rDG1DMm.png

Share this post


Link to post
Share on other sites
Can anyone clarify the differences between the various frames of reference, and when you might want to use each of them? I am confusing myself all over the place.

I'm currently writing a tutorial for the documentation site that does exactly this - so watch this space!

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.