maneatingape
commented
3 years ago @meep366 Thanks for the thoughtful feedback and happy new year to you too!
First the good news - this feature should be theoretically possible. Next the tricky part - there might be practical considerations that make it difficult to implement in a reliable, timely and accurate fashion.
Background I had considered this use case when originally writing RSVP but decided not to include as it increases complexity and test cases substantially and I felt that the cost/benefit balance was not enough. In the stock game the utility of this feature is mostly limited to a single case (Kerbin transfer directly to a Joolian moon, for example Laythe or Tylo). However there is the example that you provide in your report and several players have also used this library with planet packs (for example Galileo's Planet Pack) that have more extensive planet-moon systems (and even sub-moons) where this feature could come in useful.
Technical context RSVP implements the Lambert problem solver that assumes 2 bodies in orbit around a single common parent, for example 2 ships in orbit around the Sun. However this would not be overly useful, so it uses a trick to allow travel from orbit around planets.
Let's use your example of a rendezvous from a ship in orbit around Minmus to a ship in orbit around Kerbin.
- Common parent is Kerbin
- Transfer is first computed as if the ship has the same orbit as Minmus around Kerbin, assuming the ship is a single zero-dimensional point located at the center of Minmus.
- Once a transfer is found, an iterative algorithm adjusts the departure position and time to account for the fact that the ship will leave from the edge of Minmus's SOI (and not from the center of the planet)
- This algorithm mostly converges. The smaller the SOI relative to the radius of the orbit the more likely this is. For example most planets are fine, but Ike-Duna, Jool-Laythe and Jool-Tylo have abnormally large ratios of SOI to orbital radius, so failure is more likely in those scenarios.
So how could your suggestion be implemented? Let's use the example provided: A ship in orbit around Kerbin desiring a transfer to ship in orbit around Minmus.
There's no direct common parent but one idea is to use a simplifying trick. The destination ship is in elliptical orbit around Minmus, which is in elliptical orbit around Kerbin. By combining the ship's position and velocity with Minmus's position and velocity respectively, we could "erase" Minmus and pretend that the destination ship is in a strange orbit around Kerbin that speeds up and slows down and wobbles (this approach could also be recursively applied to sub-moons). The Lambert solver only considers zero-dimensional points, so would provide a transfer solution.
Now for the first tricky part. The script uses a simple hill climbing algorithm to find the best transfer window. This assumes a "smooth" gently sloping porkkchop plot that has an obvious valley. For example here is the plot from Kerbin to Duna with a single valley that the algorithm will nearly always converge to (notice the diagonal ridge from bottom left to top middle that can throw off the some searches).
Kerbin to Moho is more challenging, the features repeat (at the synodic interval), and are much more "rugged" with local minima that the alogorithm could get trapped in. To workaround this the script simply starts many searches and usually one will find the global minimum (for the given search parameters).
The trick suggested above would add a layer of wrinkles (or noise) to the porkchop plot that could throw off the hill climbing algorithm. Instead of a single smooth curve from peak to valley, it would rise and fall in a bumpy manner (although overall decreasing).
However this is just one idea - I'm sure there are other approaches that you could try.
Alternatives As a plan B, there's always the workaround that you suggested of plotting a transfer to Minmus and then a second transfer to rendezvous with the ship. With the foreknowledge that the ship is the final destination, the script could choose a target orbit around Minmus that gives a good chance of an optimal second transfer orbit. One nice feature of this approach is that it would be much simpler to get started, you would essentially be writing a wrapper script to build more sophisticated transfers on top of the direct transfers provided by the RSVP library. Detailed knowledge of the internal workings of RSVP would not be needed.
meep366
Feature Request
Before creating a feature request please check that:
Is your feature request related to a problem? Please describe.
Happy New Year! It is currently not possible to plan a vessel intercept when the destination vessel is around a child of the current body, even if the inverse is possible. For example, a vessel in orbit around Kerbin cannot plan an intercept with a vessel around Minmus, however, a vessel in orbit around Minmus can plan an intercept with a vessel around Kerbin.
Describe the solution you'd like
Ideally, it would be possible to plan these transfers as it would appear to be the same 2-body SOI problem that's been solved so well with your library. All the standard options for vessel intercept planning would still apply.
Describe alternatives you've considered
The obvious solution being simply planning a transfer out to the second body, say Minmus, then planning a transfer from there is the immediate work-around, however sub-optimal the deltaV of that transfer set up might be. I expect there's probably a good reason for this feature not being in the current release, but I will try to go through the code myself as well to see what would be required to get this functioning. Creating this issue to see what roadblocks there might be, and happy to put up a PR with my implementation if by some miracle I understand enough orbital mechanics to make it work.
Additional context
Appreciate the library a lot already and hope for some helpful feedback!