[1.8.1 - 1.12.5] RSVP - kOS library for scripted interplanetary transfers and vessel rendezvous

[Black-Two-]

On 11/25/2021 at 5:47 PM, ManEatingApe said:

That's the background...so how do we fix it?

I'm not sure yet. One solution might be to force a minimum floor on the intercept velocity. Another may be to better mirror how KSP translates velocity when transitioning SOIs.

I'll be honest, I understand what the problem is but not why it's a problem. The relative velocity is greater than the minimum possible velocity, sure, but the relative velocity only(?) matters when the craft is outside the relevant SOI while the minimum possible velocity only(?) matters when the craft is inside the SOI, so why is it a problem?

As for solutions... Changing line 407 in orbit.ks to "local sin_E is sqrt(1 - min(cos_E, 1) ^ 2)." avoids the crash, but then again it might create problems down-the-line. I'm really in over my head when it comes to this kind of stuff...

[ManEatingApe]

On 11/27/2021 at 4:15 PM, Black-Two- said:

I'll be honest, I understand what the problem is but not why it's a problem. The relative velocity is greater than the minimum possible velocity, sure, but the relative velocity only(?)

The initial predicted relative velocity is less than the minimum. Greater than the minimum is no problem, you can come shooting in as fast as you like.

On 11/27/2021 at 4:15 PM, Black-Two- said:

As for solutions... Changing line 407 in orbit.ks to "local sin_E is sqrt(1 - min(cos_E, 1) ^ 2)." avoids the crash, but then again it might create problems down-the-line.

Worst case, it would probably throw off the refinement iteration causing the transfer to be bad (i.e cost more delta-v than necessary). I had a think about the solution and decided the best course of action was to simply fail the iteration explicitly. Note this won't fail the entire search (unless by some slim chance this is the only search iteration).

There was already a check to ensure the ejection velocity was over the minimum, so I've added a similar check for the insertion velocity. There's a somewhat pleasing symmetry to this, and of course <drumroll>...

A predicted transfer for a mere 22 m/s (of course in this instance the craft will intercept Geminus before the manuever node).

On 11/27/2021 at 4:15 PM, Black-Two- said:

 I'm really in over my head when it comes to this kind of stuff...

Me too!

Edited November 28, 2021 by ManEatingApe

[ManEatingApe]

Released Version 8

Bug Fixes

• Add a safety check that the predicted insertion velocity at the boundary of the destination's SOI is above the minimum possible (based on the desired final periapsis). This is similar to the existing check that the ejection velocity from the origin is greater than the minimum possible. This prevents an error occurring during transfer refinement in some scenarios when the initial raw point-to-point Lambert solution predicts an intercept velocity less than this minimum.

[Black-Two-]

I've been using the latest for version for a little while now with great success! Now all I need is gravity assist planning but Wayfinder by @Muetdhiver seems like it is exactly that, with the caveat that I'll have to go back to stock, but I'll probably do that anyway at some point.

Two questions about RSVP have arisen though!

1) "Error 205 - Destination is not orbiting a direct common parent or grandparent of ship". If I want to go to Ike from Kerbin's orbit I get this error and I don't understand why. Isn't the sun the common grandparent of Ike and a vessel orbiting Kerbin?

2) How does the script detect whether to use ship:obt:period or body:obt:period? I'm working on a script to execute RSVP without having to edit stuff between uses and I've been stuck on this problem for a little while now. I understand when to use each (ship:obt:period when origin and destination have the same parent, orbiting Kerbin with destination Mun; body:obt:period when origin and destination have different parents, orbiting Kerbin and destination Duna, for instance). Is this the correct part?

if ship:body = destination:body {
    setting("origin_type", "vessel").
}
else if ship:body:hasbody and ship:body:body = destination:body {
    setting("origin_type", "body").
}

On 11/28/2021 at 10:49 PM, ManEatingApe said:

The initial predicted relative velocity is less than the minimum. Greater than the minimum is no problem, you can come shooting in as fast as you like.

Yeah, that's the part I understand. I suppose what I don't understand is why there's a need for a minimum velocity at all, like why would it matter if a craft enters an SOI too slowly? But I suspect I might not understand the explanation anyway...

Edited December 4, 2021 by Black-Two-

[ManEatingApe]

5 hours ago, Black-Two- said:

1) "Error 205 - Destination is not orbiting a direct common parent or grandparent of ship". If I want to go to Ike from Kerbin's orbit I get this error and I don't understand why. Isn't the sun the common grandparent of Ike and a vessel orbiting Kerbin?

Yeah, concise phrasing that is easily understandable is hard!

Essentially, if your ship is orbiting Kerbin, then Kerbin is the direct parent, so valid destinations are:

• Mun, Minmus
• Ship also in orbit of Kerbin

The sun is the direct grandparent of the ship, so valid destinations in addition:

• Moho, Eve, Duna, Dres, Jool, Eeloo
• Ships also in orbit of the Sun

Ike is orbiting Duna so it's not directly accessible in a single transfer, but is do-able in two.
Plot a transfer to Duna, capturing into an elliptical orbit if Ike is your first destination, then once in Duna orbit, plot a second transfer.

5 hours ago, Black-Two- said:

2) How does the script detect whether to use ship:obt:period or body:obt:period? I'm working on a script to execute RSVP without having to edit stuff between uses and I've been stuck on this problem for a little while now. I understand when to use each (ship:obt:period when origin and destination have the same parent, orbiting Kerbin with destination Mun; body:obt:period when origin and destination have different parents, orbiting Kerbin and destination Duna, for instance). Is this the correct part?

ship:obt:period is used  if the relationship between origin and destination is sibling,  for example ship in orbit of Kerbin to Mun.

ship:body:obt:period is used if the relationship between origin and destination is aunt/uncle, for example ship in orbit of Kerbin to Duna.

Edited December 4, 2021 by ManEatingApe

[acr_8133]

Is it possible to use RSVP to determine the T-0 of rockets waiting on the pad? I don't want my ships to wait 2 years in a parking orbit around Kerbin before I can proceed in the interplanetary transfer.

[ManEatingApe]

On 12/23/2021 at 3:15 PM, acr_8133 said:

Is it possible to use RSVP to determine the T-0 of rockets waiting on the pad? I don't want my ships to wait 2 years in a parking orbit around Kerbin before I can proceed in the interplanetary transfer.

Is there a reason that waiting on the pad is better than waiting in orbit?

[Stone Blue]

2 hours ago, ManEatingApe said:

Is there a reason that waiting on the pad is better than waiting in orbit?

I could be wrong, but waiting on the pad, for a *direct-to-target* launch, vs having to launch into a parking orbit for no reason.. vOv

[acr_8133]

5 hours ago, ManEatingApe said:

Is there a reason that waiting on the pad is better than waiting in orbit?

im playing with life support mods and Im trying to make the launch late as possible so I can bring less consumables

[ManEatingApe]

23 hours ago, acr_8133 said:

im playing with life support mods and Im trying to make the launch late as possible so I can bring less consumables

@acr_8133Two solutions for now:

1. Sophisticated: Send a probe into orbit, run RSVP from the probe to find dates, then use kOS communication functionality to send launch date back to mothership waiting on the pad.
2. Moar Boosters: Comment out the following lines https://github.com/maneatingape/rsvp/blob/master/src/validate.ks#L59-L61 to override the validation and run the script from the mothership.

I'm noodling on modifying the restriction. It's a little tricky as all the defaults are based on the ship's orbit. It (just about) works ok when the destination is in an aunt/uncle relationship to the ship (e.g. ship sitting on Kerbin, heading to Duna) but opens a whole can of worms when that's not the case (e.g. ship on Kerbin heading to Mun).

[acr_8133]

On 12/29/2021 at 12:25 AM, ManEatingApe said:

@acr_8133Two solutions for now:

1. Sophisticated: Send a probe into orbit, run RSVP from the probe to find dates, then use kOS communication functionality to send launch date back to mothership waiting on the pad.
2. Moar Boosters: Comment out the following lines https://github.com/maneatingape/rsvp/blob/master/src/validate.ks#L59-L61 to override the validation and run the script from the mothership.

I'm noodling on modifying the restriction. It's a little tricky as all the defaults are based on the ship's orbit. It (just about) works ok when the destination is in an aunt/uncle relationship to the ship (e.g. ship sitting on Kerbin, heading to Duna) but opens a whole can of worms when that's not the case (e.g. ship on Kerbin heading to Mun).

I tried the second solution and it is able to find a time for launch. When finally in orbit, I made the search duration 2x the ship's orbital period and the launch cost went from 3500m/s to 5500m/s when finally creating the maneuver node. If I didn't limit the search duration, the waiting time increases again by multiple years.

Any suggestions?

 

edit: I had a node created just 50 days away, only happened once though after many attempts

edit2: I'm just dumb and mixed up the times, it now works much better. However, while in orbit, it has a weird tendency to put the maneuver node behind the ship (including the time).  Options code is below: 

        local options is lexicon(
            "create_maneuver_nodes", "first", 
            "verbose", true,
            "final_orbit_type", "none"
            ,"search_duration", (ship:orbit:period * 2)
            ,"search_interval", (min(ship:body:orbit:period, target:orbit:period) / 16)
            ,"earliest_departure", time:seconds + (60 * 5)
            ).

I added the earliest departure to maybe fix it but it still put the node behind.

Edited January 1, 2022 by acr_8133

[capybara]

Nice mod!!

is RSS supported?

 

[ManEatingApe]

On 1/1/2022 at 8:33 AM, capybara said:

Nice mod!!

is RSS supported?

 

Yes! RSVP reads orbital info from the game itself, so any planets packs that modify the stock planets are supported.

[acr_8133]

Hi its me again, I'm having some problems with the node creation. I'm using Mechjeb's porkchop plotter as reference for the most efficient transfer. For the current situation, Mechjeb plots a 2km/s dV node, while RSVP plots a 5km/s dV one.

Here's a link for an idea of what the orbits look like: https://imgur.com/a/i00qrTG

The RSVP node has higher inclination than the Mechjeb node. Mechjeb also has its intercept close to the ascending node. I tried making the search interval 10 second for a greater chance of finding the most efficient node. The search duration also is not very far (ship:orbit:period * 2, still higher than the Mechjeb plot).  Just hit me up in case you need more info.
 

Edited January 27, 2022 by acr_8133

[ManEatingApe]

1 hour ago, acr_8133 said:

Hi its me again, I'm having some problems with the node creation. I'm using Mechjeb's porkchop plotter as reference for the most efficient transfer. For the current situation, Mechjeb plots a 2km/s dV node, while RSVP plots a 5km/s dV one.

Here's a link for an idea of what the orbits look like: https://imgur.com/a/i00qrTG

The RSVP node has higher inclination than the Mechjeb node. Mechjeb also has its intercept close to the ascending node. I tried making the search interval 10 second for a greater chance of finding the most efficient node. The search duration also is not very far (ship:orbit:period * 2, still higher than the Mechjeb plot).  Just hit me up in case you need more info.
 

Hey, if you upload the save file somewhere, I can take a look!

[acr_8133]

On 1/28/2022 at 4:44 AM, ManEatingApe said:

Hey, if you upload the save file somewhere, I can take a look!

I'm on a modded save, and there are quite a lot of part mods. The only relevant mods I guess are the latest release of Kopernicus from the stable branch, Didymos mod (for the DART mission), and a 2.5x Rescale. I also edited the configs(below) for Didymos in \Rescale 2.5x\PlanetSpecificConfigs.cfg\ so it won't be rescaled.

@Kopernicus:BEFORE[SigDim2]:NEEDS[SigDim]
{
	@Body:HAS[#name[Didymos]]
	{
		@SigmaDimensions
		{
			@Resize = 1
			@landscape = 1
			@scanAltitude = 1
		}
	}
}

Background to what I have now: 

I am currently trying this method you sent. Because I still see the first one unreliable for giving out dates.

Quote

Sophisticated: Send a probe into orbit, run RSVP from the probe to find dates, then use kOS communication functionality to send launch date back to mothership waiting on the pad.

On a random date. The orbiting probe sends a launch date, and on the pad, the mothership reads the sent date and warps half of a day before it. The mothership then launches and tries to go to an orbit very close to the probe (difference is <100m Ap and Pe, <0.1 deg inclination). After entering a stable orbit, RSVP will be run from the mothership to find a good maneuver.

The options are (search_interval = 1), (search_duration = ship:orbit:period), (create_maneuver_nodes = first), (final_orbit_type = none). Everything else is left on default. The maneuver created by RSVP for the mothership is very far from what Mechjeb outputs. 5km/s dV for RSVP and 2km/s dV for Mechjeb. I know the date sent is a good window because Mechjeb's porkchop plotter show good values. What I also find is that RSVP's maneuver node is much more inclined than Mechjeb's, and the Mechjeb node intercepts Didymos near its AN/DN.

Edited January 29, 2022 by acr_8133

[ManEatingApe]

On 1/29/2022 at 6:55 PM, acr_8133 said:

I'm on a modded save, and there are quite a lot of part mods. The only relevant mods I guess are the latest release of Kopernicus from the stable branch, Didymos mod (for the DART mission), and a 2.5x Rescale. I also edited the configs(below) for Didymos in \Rescale 2.5x\PlanetSpecificConfigs.cfg\ so it won't be rescaled.

Part mods won't affect RSVP, only planet packs (such as Rescale). Without a save it's going to be tricky to pinpoint the issue.

I can offer some general suggestions:

• Is the target planet heavily inclined? Large SOI to orbit ratio? If so try tweaking the "final_orbit_orientation". to "polar. Sometimes this can improve the transfer.
• What about other broadening the search window? Are all transfers 5m/s? It might be that particular window for some reason. Perhaps the next transfer window a couple of years later might provide better values.

Edited January 31, 2022 by ManEatingApe

[Jasseji]

Nice one, could this in theory be also used for Interstellar transfers ? I am looking for some solution to properly calculate a transfer with an acceleration to 0.01c and then slow down at target (with a Daedalus Engine). For the moment i am doing it by hand, which means always course corrections and wasting Fuel, looking for a way to optimise this.

[ManEatingApe]

On 2/4/2022 at 7:01 AM, Jasseji said:

Nice one, could this in theory be also used for Interstellar transfers ? I am looking for some solution to properly calculate a transfer with an acceleration to 0.01c and then slow down at target (with a Daedalus Engine). For the moment i am doing it by hand, which means always course corrections and wasting Fuel, looking for a way to optimise this.

Possibly - if the interstellar expansion models the suns as orbiting a common point, then in theory it's possible to plot an intercept from Kerbol orbit to orbit of the destination star.

Why not give it a try...I'd be curious to see if it works!

[Jasseji]

11 hours ago, ManEatingApe said:

Possibly - if the interstellar expansion models the suns as orbiting a common point, then in theory it's possible to plot an intercept from Kerbol orbit to orbit of the destination star.

Why not give it a try...I'd be curious to see if it works!

yes, i will try it 

Is there a way to actually set a scpeific DV in the config ?

i.e. i want a burn of 0.01c, i do not care about lowest DV possible, only for some tool to calculate the maneuver nodes given that i have a spceific Dv i want to use for the transfer

Edited February 7, 2022 by Jasseji

[Jasseji]

Ok, i tried something like this (from Kerbin SOI):

set config:ipu to 2000.
runoncepath("0:/rsvp/main").
local options is lexicon("create_maneuver_nodes", "both", "verbose", true, "max_time_of_flight", 150000000, "earliest_departure", 1000000, "search_duration", 5000).
rsvp:goto(AlphaCentauriBarycenter, options).

it gives me this:

Best Result
  Departure: Year 1 Day 10 00:04:06
  Arrival: Year 17 Day 138 02:44:06
  Delta-v: 5449389
LEXICON of 2 items:
[
  ["value"] = "success"] =
  ["value"] = False
[
  ["value"] = "problems"] = LEXICON of 1 items:
  [
    ["value"] = 401] =
    ["value"] = "Unexpected encounter 'Kerbin => Sun', expected 'Kerbin => Sun =
> AlphaCentauriBarycenter'"

 

If i try to do it from Sun Soi:

Search offset: Year 1 Day 47 01:46:40
  Departure: Year 1 Day 47 02:51:11
  Arrival: Year 17 Day 175 05:31:11
  Delta-v: 5459850
Invocations: 33
Best Result
  Departure: Year 1 Day 47 02:51:11
  Arrival: Year 17 Day 175 05:31:11
  Delta-v: 5459850
LEXICON of 2 items:
[
  ["value"] = "success"] =
  ["value"] = False
[
  ["value"] = "problems"] = LEXICON of 1 items:
  [
    ["value"] = 401] =
    ["value"] = "Unexpected encounter 'Sun', expected 'Sun => AlphaCentauriBaryc
enter'"
Program ended.

 

[ManEatingApe]

Released Version 9

Bug Fixes

• Support kOS 1.4.0.0 by renaming local variables to avoid conflict with built-in names.

New Features

• The restriction on running the script when the craft is not in a stable orbit has been relaxed, so that finding future transfer times can happen when on the ground. Maneuver nodes can still only be created when the craft is in a stable orbit.

 

[Kurld]

I've been playing with this the past few days.  I want to calculate a burn to go from Kerbin orbit to Mun.  I'm in a circular/equatorial orbit ~200km in a 2.5x system and generally a transfer from there costs < 1450 dV with the hill-climbing alogrithm I've been using so far.  I was intrigued by the possibility of using RSVP to find retrograde solutions and more or less nail the desired PE at Mun.  I does this part  perfectly.   But...

First problem I ran into is that, with the default settings for search duration, etc. it takes a LONG time to find such a solution.  Several minutes.  The solution it finds for a retro-orbit at 50km seems to be somewhat reasonable, but the ETA is days into the future. The CPU in my S-IV analog only has so much battery power available...

And this seems unreasonable, both from the sense of waiting around for it to finally do its thing and also . . . I can, by hand, find an intercept within one orbital period that is roughly "good enough" in terms of dV required.  And I can do it a lot faster than the solver.  Then I noticed it seems to be searching the entire synodic period, so I decided to limit it to searching only within the next orbital period and things go pear-shaped. 

The nodes presented by RSVP in this case are generally more expensive (1750 to 1800 dV and up).  I've noticed that if I wait a moment and try for another solution, it tends to find something entirely different.  Sometimes a little better, but sometimes much worse.  A few times it presented nodes that were over 2500m/s and included me burning a lot of radial-in... taking me through Kerbin itself.  At this point, I tried adjusting the search_interval to give it more chances to find better solutions and it didn't seem to improve things very much, tbh, and it takes an extremely long time if you go very thin with the slices.

Most (all?) of the solutions presented include some significant radial component to the burn (usually radial-out), which I don't understand the need for in this case. 

Is there any way to help it out with some better initial guessing?  The phase angle for intercept should be calculable, which should give it a good idea of where to start looking for ETA to burn.  The prograde deltaV estimate for a burn from a circular, equatorial parking orbit to the eventual apoapsis near Mun's altitude also seems easy to obtain.  Or, is there any way to warn it away from including any radial component in the burn?  I think the fact that it is including any at all is skewing the rest of its calculations towards being sub-optimal in the final application.

As always, I have to ask, "what am I missing?" because the answer is usually "something I didn't imagine."

 

[Kurld]

I think maybe I found the problem. In your documentation you mention that max_time_of_flight defaults to 2* the ideal Hohmann transfer time.  This does not appear to be true in the code, rather it just uses the transfer time (not doubled).  I think this is why it's trying to use so much radial out.. to keep the transfer times down.

When I passed it  rsvp:ideal_hohmann_transfer_period(SHIP, Mun) * 2 for the max_time_of_flight and it started giving me very good transfers.

[ManEatingApe]

6 hours ago, Kurld said:

I think maybe I found the problem. In your documentation you mention that max_time_of_flight defaults to 2* the ideal Hohmann transfer time.  This does not appear to be true in the code, rather it just uses the transfer time (not doubled).  I think this is why it's trying to use so much radial out.. to keep the transfer times down.

When I passed it  rsvp:ideal_hohmann_transfer_period(SHIP, Mun) * 2 for the max_time_of_flight and it started giving me very good transfers.

Thanks for the detailed description, investigation and GitHub bug report!

I should be able to take a look in the next few days. Out of curiosity what is the 2.5x mod that you're using?