[1.8.x to 1.12.x] kRPC: Control the game using C#, C++, Java, Lua, Python, Ruby, Haskell, C (Arduino)... (v0.5.2, 18th March 2023)

[djungelorm]

2 hours ago, GenryRar said:

one stupid question - is it possible to control specific inactive vessel (ofcourse in physical range)?

Yep! You can get hold of the vessel object for an inactive vessel via SpaceCenter.Vessels

[GenryRar]

On 09.04.2017 at 6:57 PM, djungelorm said:

Yep! You can get hold of the vessel object for an inactive vessel via SpaceCenter.Vessels

Thx!

[Thertor]

How can I get the state of SAS, and only print something when it's true/false?

[djungelorm]

14 hours ago, Thertor said:

How can I get the state of SAS, and only print something when it's true/false?

See my answer here: 

 

[Bosun]

Is there a way to interface with external hull cameras, such as from HullCam VDS?   I am trying to figure out how to reference them as parts, and then call their modules for activation.  I figure that should be something I can do, yes?

[ColKlonk2]

Any other protocols to go by... Google is insecure 

[Bosun]

Are there any more complete libraries for kRPC?  I'm having trouble linking a lot of references because many of those in the github page are outdated or slightly different.  Specifically I want to link a resource from a specific tank to a variable, and cannot seem to get it to work.

 

resource = vessel.parts.*part-name/title/tag/number*.resources('resource') is what I kinda thought it would be.  I realize this is horridly wrong....kinda new to Python, but using this mod as a fun way to learn.  How should I call a specific part?  
Cheers,

 

 

Edited May 3, 2017 by Bosun

[djungelorm]

On 4/30/2017 at 8:58 AM, Bosun said:

Is there a way to interface with external hull cameras, such as from HullCam VDS?   I am trying to figure out how to reference them as parts, and then call their modules for activation.  I figure that should be something I can do, yes?

Do you mean control the camera, or actually get the video feed out via krpc? I'm not familiar with the mod, but if it just adds a new part with a custom partmodule, you should be able to interact with its fields/events/actions by calling part.module which returns an instance of this class: http://krpc.github.io/krpc/csharp/api/space-center/parts.html#module

On 4/30/2017 at 9:28 AM, ColKlonk2 said:

Any other protocols to go by... Google is insecure 

If you're referring to the protobuf library, it's an open source library, developed by Google. It doesn't rely on their servers or any closed source, and is actively contributed to by the open source community. So I wouldn't worry about "insecurity"!

I have added a websockets based server to the "upcoming" (been upcoming for a long time now...) release, mainly to support things like JS in the browser that can't communicate over TCP/IP. I might also add gRPC support at some point.

[djungelorm]

# Get a list of all tanks with the given title
tanks = vessel.parts.with_title('Rockomax Jumbo-64 Fuel Tank')

# Get one of the tanks from the list
tank = tanks[0]

# Get an object representing the resources of the tank
res = tank.resources

# Print out the amount of liquid fuel in the tank
print res.amount('LiquidFuel')

@Bosun The above is an example of getting the resources for a tank by title.

The examples here are up to date with the latest version: http://krpc.github.io/krpc/tutorials.html

Edited May 10, 2017 by djungelorm
Fix code

[Bosun]

Thanks!   Is the index, 0, exampled here the 'Object' number in Unity?  Or is it the number within the list? (List item 1, list item 2, etc)

More importantly though, the creation of objects was a learning step for me.  I just figured this out Monday while I was re-reading part tree traversal, and was able to use the traverse to find and object the parts I wanted.  
With this step I'll be able to separate like tanks as well.  Thanks!   
Cheers!  

[djungelorm]

It's just the position in the list (lists in python are zero-indexed). Glad to hear you are enjoying learning python  

[artwhaley]

Heya!   I've been stuck with non video game related life the last few months, but am finding some free time again and playing with KSP and KRPC again...  

Edit:  I realized my first idea was dumb.  I was thinking about building a maneuver planning service for KRPC that would.... essentially...  just copy half of mechjeb into itself and then require me to maintain it in parallel to mechjeb.  See: dumb.

I'm back working on converting my mechjeb integration service to use reflection so that it doesn't crash if mechjeb isn't available.   @djungelorm , are you interested in me submitting a pull request to add it to the other mod wrapper services when I get it sorted?   

Also, on a totally separate note - anyone having problems setting targets?  I think Squad changed the 'input lock' code in a way that makes it easy for modders... and squad itself for that matter... to get in each other's ways?   I reported that one on the issues page.  

Edited May 21, 2017 by artwhaley

[Bosun]

Another puzzler! 

I'm wanting to feed the 'prograde' vector from the conn.stream into the guidance for the target-pitch-heading function. 

Currently, I've created two functions, pitch and heading, to parse out the individual parts of the 3-float tuple that prograde stream spits out.  

My question - which of those three tuples is the heading, the pitch, and what is the 3rd value in that tuple?   Also - printing these off, they are in decimal.  What kind of conversion should I use to translate them into 0-90 ranges?  

I'm using RSS, btw.  Not sure if that matters.
Thanks for any help!

[artwhaley]

Firstly...  is there a reason you're not using the KRPC autopilot to help?  

To point towards surface prograde all you have to do is - 

ap = vessel.auto_pilot
ap.reference_frame = vessel.surface_velocity_reference_frame
ap.target_direction = (0, 1, 0)
ap.engage()

changing the second line above to get this would give you prograde in orbit- 

ap.reference_frame = vessel.orbital_reference_frame

 

https://krpc.github.io/krpc/tutorials/reference-frames.html   <<  This page might help!  if I'm not answering your question or there's a reason you're trying to do it a more low level way, if you explain it we can take a stab at figuring it out!  

[Bosun]

Thanks Art! 

Yes, I was actually attempting to build rockets that would follow a natural gravity curve without the need for steerage on the pitch.  

After looking through several equations for gravity turns that have been written, I finally had the thought about trying to just build rockets that have dV staged well enough to turn on their own, as in, a real, actual, gravity turn.  

At a certain altitude, I'll pitch the engines to tilt the rocket to a pre-determined pitch, and once at that pitch, release the rocket from corrective steering to simply point prograde.  At first, I attempted to use the game's own SAS control through kRPC to keep the rocket toward prograde, but I'm curious if the kRPC command without SAS engaged might be a little more stable, as the SAS tends to give most of my vessels horrible waggle, so we'll see.  

Once I get decent at building the rockets, I can begin to actually work through the math of the build to design a rocket on the ground, write the code without flying it first, and know exactly what it's going to do. 

Finally - thanks for giving me insight into pointing prograde!  I am still curious to know about the numbers that the conn.flight().prograde spits out, because I also want to know when my prograde surface flight path has reached a certain pitch, upon which I would release the rocket to prograde direction instead of forced pitching.

Cheers!

Edited May 26, 2017 by Bosun

[artwhaley]

Cheers back!   Why didn't you SAY you wanted to do things the hard way!?      Though, to be fair - KRPC sort of is the kind of thing that attracts those of us that are thrilled to waste 8 hours trying to save 5 minutes, isn't it?   I've been working 3 days on automatic space plane glideslopes and I don't even like space planes. 

 

But enough of my lunacy and on to yours - firstly... remember that the vessel.flight() telemetry requires a reference frame!  I don't know what it uses for a default when you don't provide one, but you should provide one!   f=v.flight(v.surface_reference_frame), for example - to get these surface referencing.   The .prograde tuples are a combination of the orbital vector components -  radial, normal, and prograde.   They relate to the flight.direction value so by comparing them you can find your deviation from them on a scale of -1 to 1.  Suppose if my 4AM brain is working right... multiplying the .direction by 90 will give you the degrees of deviation from each of those pointings?

 

Perhaps what you want is the autopilot.target_direction parameter?   For setting the autopilot to point towards prograde?   Maybe:

 v.auto_pilot.reference_frame=v.orbital_reference_frame
v.auto_pilot.target_direction =0,1,0

 

[tho5is]

[deleted]

Edited May 30, 2017 by tho5is
realized probable answer from other sources.

[lushr]

I'm working on a control system that needs a not-insignificant amount of time (about 0.5s) to precompute before it can begin guidance. To minimize error, I would like to do this precomputation while the game is paused/locked up, but haven't found a good way to accomplish this. Approaches I've looked at include:

• Kerbal Alarm Clock pause events, which don't seem to be working anymore...
• RPC floods, which are limited to take about 0.1ms by the maximum value in the time per update field

I don't really see any other way to stop or slow down the game from kRPC. Are there any suggested ways to accomplish this?

[artwhaley]

On 5/29/2017 at 7:42 PM, tho5is said:

[deleted]

It's always good to leave the question and just post what you figured out!   It might help someone else in the future!  The forum is full of posts where I have to admit my mistakes of varying degrees of dumbditude!  

1 hour ago, lushr said:

I'm working on a control system that needs a not-insignificant amount of time (about 0.5s) to precompute before it can begin guidance. To minimize error, I would like to do this precomputation while the game is paused/locked up, but haven't found a good way to accomplish this. Approaches I've looked at include:

• Kerbal Alarm Clock pause events, which don't seem to be working anymore...
• RPC floods, which are limited to take about 0.1ms by the maximum value in the time per update field

I don't really see any other way to stop or slow down the game from kRPC. Are there any suggested ways to accomplish this?

Maybe Djungleorm can help with telling you what if any parts of KRPC function during a game pause when he's got more time...  are you really worried about the conditions changing so much during that .5s that you need to lock them down so you start control in the same state you calculated from?  Or is there some other reason I'm missing?  Perhaps if you explain your use case more we can come up with an alternative together?   I think it would be possible for KRPC to add a method to execute a game pause, but perhaps not an unpause if there's no way update RPC's during the pause to see the command.  If so you could grab the game state then pause... and just have to manually unpause when your program reported calculations complete?   

[lushr]

1 hour ago, artwhaley said:

Maybe Djungleorm can help with telling you what if any parts of KRPC function during a game pause when he's got more time...  are you really worried about the conditions changing so much during that .5s that you need to lock them down so you start control in the same state you calculated from?  Or is there some other reason I'm missing?  Perhaps if you explain your use case more we can come up with an alternative together?   I think it would be possible for KRPC to add a method to execute a game pause, but perhaps not an unpause if there's no way update RPC's during the pause to see the command.  If so you could grab the game state then pause... and just have to manually unpause when your program reported calculations complete?   

I'm working on doing hoverslam-style landing using a convex optimization trajectory generation approach, based on Blackmore and Szmuk et al's work. In this approach, a solver is used to compute the optimal trajectory from the initial position to the landing site (which is what takes the 0.5s), and then the autopilot just follows the precomputed thrust level and direction, at least in an ideal system. This is quite sensitive to where it's started up, because uncertainties in the initial state will cause the final landing site to be off by that same amount.

In vacuum, just waiting for the solver is fine, because it's easy to project the state of the vehicle. Right now, I'm working on a Mun lander, which uses RK4 integration forward 4 seconds to the beginning of the optimized trajectory, which also accounts for the time needed to reorient and ullage. However, this approach breaks down in two scenarios:

• I eventually want to do SpaceX style landings with this script - which means that the system needs to work inside the atmosphere. I can't numerically integrate with sufficient accuracy atmospherically.
• Ideally, I would be able to re-run the optimizer as the vehicle is flying the old trajectory, further reducing final dispersion. However, again, numerically integrating this is quite tricky in this scenario.

For this application, either manually unpausing or waiting for kRPC to get back to it would be fine, as long as game time isn't passing while the solver is running. Thank you very much for the help!

Edited June 6, 2017 by lushr

[artwhaley]

Well that IS a difficult case if you want the margins to be really as tight as SpaceX's....  If I were trying to do it without adding my own service to KRPC to get a pause function...  I would use the fact that KRPC can save and load save files!    You could grab the parameters you need and trigger a quicksave... calculate and then reload the quicksaved state?  

 

Though really if I was doing this in KSP where the margins don't HAVE to be so tight on using up the last drop of fuel, I'd probably redefine the problem slightly to make it less computationally intense.   For example - without looking up your references there it seems to me that only the last bit of such a landing has to be perfect.   I might try to execute a series of less precise calculations diminishing the error each time.   Initially course correct to get within 500m of the target location, inside a velocity range, at a given altitude, and then from THERE you go to the next waypoint, this time within 100m and with tighter velocity constraints. The landing could be totally prescripted, and precalculated then -  for the last 500m, starting from a given location in space and velocity.  This seems to me that it has to be what SpaceX is actually doing too...  rather than doing all the math at once and just flying it from there, because they're able to adjust for wind and unexpected deviations from perfect conditions.

I know it's not exactly what you're trying to do, and kudos to you if you figure out how to do it!   Just sharing my thoughts on how I'd get a virtual rocket on my virtual barge.

[lushr]

6 hours ago, artwhaley said:

 I would use the fact that KRPC can save and load save files!    You could grab the parameters you need and trigger a quicksave... calculate and then reload the quicksaved state?  

That's a really good idea - I'll give it a shot.

Quote

Though really if I was doing this in KSP where the margins don't HAVE to be so tight on using up the last drop of fuel, I'd probably redefine the problem slightly to make it less computationally intense.   For example - without looking up your references there it seems to me that only the last bit of such a landing has to be perfect.   I might try to execute a series of less precise calculations diminishing the error each time.   Initially course correct to get within 500m of the target location, inside a velocity range, at a given altitude, and then from THERE you go to the next waypoint, this time within 100m and with tighter velocity constraints. The landing could be totally prescripted, and precalculated then -  for the last 500m, starting from a given location in space and velocity.  This seems to me that it has to be what SpaceX is actually doing too...  rather than doing all the math at once and just flying it from there, because they're able to adjust for wind and unexpected deviations from perfect conditions.

Unfortunately, the optimization approaches don't really let you specify uncertainty - it's an all-or-nothing job. So far, I've been working on a solution based on what was flown on Masten Aerospace's Xombie back when they were validating it for Mars EDL, which is to have a simple P controller working to restore the pre-planned trajectory. The Xombie system also used a different terminal descent controller, that I haven't duplicated (though flying the last few meters manually is quite easy, at least when the system errors high and doesn't smash into the ground first).

So far, my approach works well enough to crash within 50-100m of the desired landing site, and my main hope is that by tuning a PD/PID makeup controller I can hold the trajectory to within the landing leg's tolerances. I may also try to build the terminal descent autopilot that just cancels horizontal velocity and pulls the vertical velocity to within reasonable tolerances, which should at the very least reduce the number of explosions.

Edited June 6, 2017 by lushr

[Ramh5]

Is there a way to have the Javadoc and/or link source code in eclipse, I spent way more time than I thought on this already and can't figure it out myself unfortunately.

Edit: Ok I figured out how to get some of the source code under \krpc-0.3.8\client\java\src\krpc\client but I can't find any source code on krpc.client.services in which I am supposed to find the SpaceCenter Class for example. 

Edited June 6, 2017 by Ramh5

[djungelorm]

Been a bit busy recently so not kept up with the discussion on here...

however I am happy to announce I've released v0.3.9, with support for KSP 1.3 and a few bug fixes

Full change log is available here: https://github.com/krpc/krpc/releases/tag/v0.3.9

[lushr]

As a quick follow up to my earlier post, I'm now having some issues with the AutoPilot attitude controller. It seems to get "stuck" pointing straight up, despite the direction being properly set (as indicated by the angular error, which can exceed 90 degrees). I'm feeding it with a guidance loop running at 30Hz, with a unit vector that's relatively well behaved.

Any ideas what I'm doing wrong?