ManEatingApe
-
Posts
520 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by 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? -
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.
-
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! -
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.
-
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!
-
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.
-
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:
- 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.
- 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).
-
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?
-
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.
-
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.
-
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!
-
Released Version 7
New Features
This release increases the speed of the hill climbing algorithm when searching the pork chop plot in certain scenarios. The larger the relative difference between the origin and destination orbits, the more benefit this provides. The eventual transfer found and delta-v needed is the same as before but takes less time to find.
For example a transfer search from Kerbin to Duna takes the same time. A transfer search from Moho to Eeloo takes 15% of the previous time.
Technical Improvements
- When verbose mode is enabled, print details if a problem occurs during a transfer search.
- Add CPU speed boost to quickstart code snippet
-
On 11/23/2021 at 6:27 PM, Black-Two- said:
Hey there, I ran into a different problem.
I have a craft in a very eccentric orbit of Gratian, wanting to get to Geminus, Gratian's moon. Ten days (day 78 is today) into a search I get the error above. It looks like cos_E is greater than 1 and sin_E then tries to get the square root of a negative number. Here's a save: https://www.dropbox.com/s/8x14sqaz1ug8t7n/GPPrsvpgratian.zip?dl=0
Update on what's going wrong...
I originally thought it was due to the fact that the craft intercepts Geminus (no fewer than 3 times in a row!) within the search period, but after some investigation kOS doesn't track future intercepts until the game shows them in the UI so that was ruled out.
This extremely polished graphic will help illustrate:
KSP uses patched conics, where each body has a finite SOI (sphere of influence). Within each SOI only the central body gravity is considered, reducing orbital equation to readily solvable 2 body forms. This means that at the boundary of the SOI there is a minimum possible velocity. This is given by the vis-viva equation and is 83 m/s for Geminus with a PE of 100km and AP at SOI boundary.
RSVP uses a spherical cow approximation for the initial transfer returned by the Lambert solver. This assumes the origin, destination and craft are all zero dimensional points. RSVP then refines this raw initial transfer, using an iterative process that takes into account the finite SOIs of the origin and destination when applicable:
https://github.com/maneatingape/rsvp/blob/master/src/refine.ks#L203For one particular iteration the intercept is returning 28 m/s as the relative velocity of the craft and Geminus. As this is below the minimum possible, it mucks up the math and results in the stack trace you reported.
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. -
2 hours ago, Black-Two- said:
That's really weird. Pod-R at the bottom of the list in the tracking station shows up for me. When or where are you getting these part errors? I'm asking because the only part mod I use is kOS which presumably you also use.
It was missing Breaking Ground/Making History DLCs. When I added them, then restored a fresh copy of the save file I could see the craft and reproduce the error successfully.
Previously I was getting a popup dialog error about unknown parts and it looks like KSP deletes a craft from the save if it has parts it can't load.2 hours ago, Black-Two- said:Let me try to understand this. "Circular" means that RSVP really, really wants the final orbit to have 0° inclination, but "polar" means inclination it isn't particularly concerned with inclination, is that right?
Depending of the value of the "final_orbit_orientation"
https://github.com/maneatingape/rsvp/#final-orbit-orientationRSVP tries to achieve a destination orbit of:
"prograde" => 0°
"polar" => 90°
"retrograde" => 180°In this case the polar orbit was a closer match to the craft's existing orbit.
("circular" is an option for the eccentricity of the final orbit, which is a different unrelated option "final_orbit_type" https://github.com/maneatingape/rsvp/#final-orbit-type ) -
5 hours ago, Black-Two- said:
Hey there, I ran into a different problem.
I have a craft in a very eccentric orbit of Gratian, wanting to get to Geminus, Gratian's moon. Ten days (day 78 is today) into a search I get the error above. It looks like cos_E is greater than 1 and sin_E then tries to get the square root of a negative number. Here's a save: https://www.dropbox.com/s/8x14sqaz1ug8t7n/GPPrsvpgratian.zip?dl=0
Ah, that's a good one!
I tried the save file but could find no craft in orbit of Gratian. There's also a bunch of missing part errors (I don't have the same mods)
Would you mind uploading the save again - with only the craft in question, with only stock parts (you can use the debug menu to rendezvous a dummy craft to the same orbit). -
@Black-Two- Let's take a look at the next two issues.
On 11/18/2021 at 9:46 PM, ManEatingApe said:3. Bad transfer from Test-1 to Iota
Test-1 is in an inclined orbit around Gael. By default RVSP assumes that you want to inject into a prograde orbit at 0° inclination.
This is causing it to "force" the 1st node at the cost of extra delta-v, essentially trying to hammer a square peg into a round hole.The tweak is to change the desired final orbit type to polar. Relaxing this constraint allows RSVP to find a much better transfer. Here's a table of results:
Settings Delta-V Manual testing (not using RSVP) 888 m/s Default RSVP settings 1184 m/s "final_orbit_orientation", "polar" 902 m/s On 11/18/2021 at 9:46 PM, ManEatingApe said:4. Higher delta-v from Test-1 to Niven/Tellumo than with Test-0
In general, transferring from an inclined orbit around one planet to another is going to cost more delta-v than launching from an equatorial orbit at 0° inclination.
RSVP usually finds the transfer that intersects the destination planet at its ascending/descending node which tends to be optimal.
Using the velocity in the inclined orbit required precise timing on the maneuver node to depart at exactly the right time. Any offset from this time is harmful, as the manuever node delta-v is fighting against the inclination velocity.
That said, RSVP doesn't blindly create maneuver nodes at the exact time returned by the hill climb search. It adjusts them based on the ship's orbit to find the very best time possible. You can see the implementation in the "create_maneuver_node_in_correct_location" function (no prizes for guessing what that does)
https://github.com/maneatingape/rsvp/blob/master/src/transfer.ks#L285(Interesting implementation detail: This uses the same code as the 2 dimensional pork chop hill climb, but restricted to 1 dimenstion).
-
On 11/18/2021 at 9:46 PM, ManEatingApe said:
2. Long pause between starting script and seeing any output.
@Black-Two- Nice find, this was an interesting issue to investigate! The long pause was caused by the very first pork chop search taking many more iterations than subsequent searches. The root cause was that the search period was very much less than the time of flight. RSVP uses the search period to determine the size of the "step" used when searching.
A visual example should help. The search period is on the x-axis and the time of flight is on the y-axis. A planet to planet transfer (for example Gael to Niven) has a reasonably square aspect ratio. As width and height are matched, the step size is a good choice for both horizontal and vertical steps.
Here's an example with a more skewed 1:3 ratio. (the actual ratio of Test-0 to Iota was even more extreme at 103). We can see that the step size is still fine in the horizontal direction but too small in the vertical direction, resulting in extra steps.
Now that the problem is clear the fix is straightforward - scale the horizontal and vertical steps independently. With a larger vertical step the ratio is effectively square once again and the search time improves.
Here's the details from your provided save:
The Test-0/Iota case is 55% faster. The Niven/Tellumo duration remained around the same. Delta-V was the same except for 2 cases that were a bit higher.
-
Let's start with item 1:
1 minute ago, ManEatingApe said:Discrepancy in search duration when searching transfer from Test-0 to Iota (takes a while) vs searching for a transfer to Niven/Tellumo (quick)
RSVP's default search parameters are very conservative. The intention is to always find the best (lowest dV) transfer with the tradeoff of using extra time when performing the search.
The default search period is the maximum of either the synodic period between the two bodies or the sidereal orbital period . The synodic period is defined as the period for the phase angle between the 2 bodies to repeat. This period covers every possible relative orientation of the 2 bodies. Here's the relevant code line:
https://github.com/maneatingape/rsvp/blob/master/src/search.ks#L36
The search interval is smaller than the search period and is how often RSVP begins a new search using its hill climbing algorithm. The default search interval is half of the minimum orbital period. Relevant code line:
https://github.com/maneatingape/rsvp/blob/master/src/search.ks#L59
Here's a table of the 3 transfers from Test-0Destination Search Period (s) Search Interval (s) Ratio Tellumo 18625942 4600800 4 Niven 17061136 2988830 5.7 Iota 495456 1792 276 Note that the search interval used is half the orbital period of Gael when going to Tellumo/Niven, but half the orbital period of Test-0 when going to Iota. The default parameters work well for the planet to planet case and I was able to reproduce the decent transfers that you found.
Now we can see why the Iota transfer search is so much slower than the others. So the question isn't why the Niven/Tellumo transfers are so fast (they seem fine) but what can we do to speed up the transfer search between Test-0 and Iota.
One suggestion is to use the knowledge that Test-0 and Iota are in co-planar orbits. So a single orbit of Test-0 will cover all possible scenarios. Test-0 has an orbital period of ~30 min, so I changed the parameters tolocal options is lexicon(
"search_duration", 30 * 60,
"search_interval", 0.25 * 30 * 60,
"create_maneuver_nodes", "first",
"verbose", true).
This found a decent transfer in a fraction of the time.
I'll investigate item 2 next. -
Hey @Black-Two- thanks for the save file. I have setup:
- Clean install of KSP 1.12.2
- GPP 1.6.7
- kOS 1.3.2
- RSVP v6
- Your save file "Abyss of the Void" (love the name!)
Reading your post, looks like the items to investigate are:
- Discrepancy in search duration when searching transfer from Test-0 to Iota (takes a while) vs searching for a transfer to Niven/Tellumo (quick)
- Long pause between starting script and seeing any output.
- Bad transfer from Test-1 to Iota
-
Higher delta-v from Test-1 to Niven/Tellumo than with Test-0
-
7 minutes ago, Scarecrow71 said:
My issue is lander design. I can get a rocket to Duna and have all kinds of fuel remaining to get home. But the lander? I'm stuck. I'm just...stuck. I simply.csnnot think of a decent design that works, and all my designs seem to just be a variation on the same theme. And I can't seem to find any decent, recent tutorials on lander design that don't use every part from tier 7.
If you could upload some pictures of your lander design(s) then we could take a look and see if there are some design tweaks that could be made. I'd recommend creating a new thread (perhaps in "The Spacecraft Exchange" section ) to avoid cluttering this thread.
-
5 hours ago, Scarecrow71 said:
And I'm ready to give up. I cannot design a rocket that can get to Duna and Ike and back. My lander always ends up being top-heavy, or I cannot get back into orbit, or something else goes wrong. I've spent the last several weeks trying to get somewhere other than Dres and I can't do it. Simply put, I CANNOT DO IT.
Hang in there Scarecrow, we've all been stuck in that frustrating zone! It might help to take a small break and try something else, sometimes insights may come to you when least expected.
Getting to Dres is trickier than Duna, most folks do it the other way around, so that's a neat achievement.
If you like, you could post ask a question in the "Gameplay Questions and Tutorials" seeking feedback on your lander design. I'm sure there will be some good suggestions.
-
9 hours ago, Black-Two- said:
Hello! I've been using RSVP in stock KSP for a while now and it's been working great.
Delighted to hear it!
9 hours ago, Black-Two- said:However, I recently switched over to Galileo's Planet Pack and now RSVP is running much, much faster when searching for interplanetary transfer windows, but it finds a lot fewer of those windows. I wasn't really expecting a search with a maximum duration of 500 days to find fewer than 10 transfer windows to certain planets in the outskirts of the solar system as in stock similar searches would not only take a lot long (tens instead of single-digit minutes) and I'm curious if you can think of why this would be the case.
Maybe it's just the layout of the solar system (I've tried JNSQ but can't remember noticing this), but I just wanted to make sure.
Hmm...the default search parameters could need tweaking to better suit GPP. If you upload a copy of your save file and the transfer(s) you're attempting, I can take a look.
-
7 hours ago, Scarecrow71 said:
The funny thing is that @ManEatingApe did all of that as part of the Kerpollo Challenge. The videos are amazing
Well, just Kerbin orbit without any unlocks although the Jool 5 was very primitive.
I'd love to see someone attempt a Mun landing with Fleas only!
In the spirit of this thread, have a meme... -
Let's get the ball rolling with an actual entry!
The first task is to find a suitable spot to land. A kOS script scans Tylo's equator looking for the highest point. At longitude -73.7927 it finds a nice mountain at 9,074m elevation. There are higher spots elsewhere on Tylo but choosing a location on the equator makes targeting a precise landing easier.
Next task is to design a suitable craft. A second kOS script simulates a constant altitude landing burn, predicting the final TWR, burn duration and delta-v needed, so that the craft design can iterate quickly without needing trial and error.
Lastly, let's fly the mission. A third kOS script controls the craft, performing a precision landing at our desired location.
Let's see how the simulation compared against the actual mission.
Predicted Actual Duration 434s 450s Delta-V 3,266 m/s 3,383 m/s Initial TWR 0.63 0.63 Final TWR 0.95 0.97 Not too shabby! The main difference is that the simulation ignores the final vertical landing phase for simplicity, causing a slight discrepancy.
For anyone considering an entry, please feel free to use, tweak, modify and improve the scripts linked in this post.
[1.8.1 - 1.12.5] RSVP - kOS library for scripted interplanetary transfers and vessel rendezvous
in KSP1 Mod Releases
Posted · Edited by ManEatingApe
I appreciate all the suggestions and another pair of eyes checking that the code actually does what it's supposed to!
.
IIUC the core issue is:
* Searching for a transfer from LKO to Mun takes a longer time than desired (assuming that CONFIG:IPU is set to 2000 for a "moar boosters" style of speedup) but results in a reasonable transfer.
* Shortening the search to a single orbital period of the origin results in janky transfer results.
So we're trying to find either a reasonable combination of setting to make the shorter search reliable and/or update the library code.
The most reasonable approach I can think of is what you're already doing - look for a retrograde target orbit, without a 2nd circularization node at the destination. Presumably some extra math can calculate the desired destination AP ahead of time.