GithubHelp home page GithubHelp logo

Comments (9)

maneatingape avatar maneatingape commented on June 12, 2024

Thanks for the suggestion!

Do you have any examples/situations where a mid-course inclination change is an advantage over a ballistic transfer? Stock is ideal, but modded planet packs are fine too.

The reason I ask is to consider the cost/benefit of this feature.

from rsvp.

mgalyean avatar mgalyean commented on June 12, 2024

To get an efficient rendezvous at some point you have to match inclinations with the target. If left until capture then it is done at capture. But matching inclinations is always most efficient at the highest radius relative AN/DN. Going sunward, most efficient is departing at the relative AN/DN. Does RSVP always put the first node in time at a relative AN/DN (the begin body being at that relative AN/DN in its orbit)? I just started using it. Going outward from the Sun, like Jool, or Duna even, the most efficient plane change will be nearer the target body.

Also once one has ISRU and mining going on Minmus and fuel is far less of an issue one can depart for, say Eve, prior to a relative AN/DN and do the inclination match en route even in cases where it will cost a bit more fuel, but save time. I guess it comes down to time efficiency being more important than fuel cost in certain phases of the game.

For the stock system, matching Jool's inclination results in an equatorial injection (or close enough that I can't tell the diference) making Laythe aeobraking or Tylo sling-shotting/braking a lot easier to set up. When going from Bop to Pol, one can depart sooner and match planes mid course and so arrive many days ahead of waiting for the starting body to reach a relative AN/DN for the first burn.

Lastly comet intercept contracts, and some wild rescue contracts, often require leaving nearly immediately if you want to intercept it near perihelion at all and being in the same plane at some point makes rendezvous far easier

from rsvp.

maneatingape avatar maneatingape commented on June 12, 2024

To get an efficient rendezvous at some point you have to match inclinations with the target. If left until capture then it is done at capture. But matching inclinations is always most efficient at the highest radius relative AN/DN. Going sunward, most efficient is departing at the relative AN/DN. Does RSVP always put the first node in time at a relative AN/DN (the begin body being at that relative AN/DN in its orbit)? I just started using it. Going outward from the Sun, like Jool, or Duna even, the most efficient plane change will be nearer the target body.

RSVP usually finds transfers that intercept the destination at AN/DN (or leave the origin at AN/DN), so that the inclination velocity component is folded into the insertion burn, where it can take advantage of Oberth. Delta-v values match well with predicted values from other Lambert solvers (e.g Alex Moon) or the orbital transfer subway map.

Is there a transfer where a mid-plane inclination change is a better strategy?

For the stock system, matching Jool's inclination results in an equatorial injection (or close enough that I can't tell the diference) making Laythe aeobraking or Tylo sling-shotting/braking a lot easier to set up.

For this specific scenario (intercepting a Joolian moon), run RSVP twice, first to get a Jool intercept with a target PE near the desired moon's orbit, then a second time once inside Jool's SOI to intercept. RSVP will handle the tricky details of a good intercept, even when you are coming in towards Jool at a slight inclination.

Lastly comet intercept contracts, and some wild rescue contracts, often require leaving nearly immediately if you want to intercept it near perihelion at all and being in the same plane at some point makes rendezvous far easier

This feels like the strongest potential use case - time restrictions forcing a departure where a ballistic trajectory is sub-optimal over a plane change. However RSVP can calculate transfers that would be painful to find manually, so there would have to be a significant delta-v advantage.

I'm enjoying this conversation and please understand, do not intend to come across as overly critical on your suggestion at all! RSVP already has to handle a number of complex edge cases already for common scenarios, so my philosophy is to focus on handling the 90% of common scenarios as best as possible. Adding a feature with niche application that complicates the code base, may not have a good cost/benefit ratio.

Hence metaphorically "kicking the tires" to see if there's a compelling benefit.

from rsvp.

mgalyean avatar mgalyean commented on June 12, 2024

To get an efficient rendezvous at some point you have to match inclinations with the target. If left until capture then it is done at capture. But matching inclinations is always most efficient at the highest radius relative AN/DN. Going sunward, most efficient is departing at the relative AN/DN. Does RSVP always put the first node in time at a relative AN/DN (the begin body being at that relative AN/DN in its orbit)? I just started using it. Going outward from the Sun, like Jool, or Duna even, the most efficient plane change will be nearer the target body.

RSVP usually finds transfers that intercept the destination at AN/DN (or leave the origin at AN/DN), so that the inclination velocity component is folded into the insertion burn, where it can take advantage of Oberth. Delta-v values match well with predicted values from other Lambert solvers (e.g Alex Moon) or the orbital transfer subway map.

Is there a transfer where a mid-plane inclination change is a better strategy?

For the stock system, matching Jool's inclination results in an equatorial injection (or close enough that I can't tell the diference) making Laythe aeobraking or Tylo sling-shotting/braking a lot easier to set up.

For this specific scenario (intercepting a Joolian moon), run RSVP twice, first to get a Jool intercept with a target PE near the desired moon's orbit, then a second time once inside Jool's SOI to intercept. RSVP will handle the tricky details of a good intercept, even when you are coming in towards Jool at a slight inclination.

Lastly comet intercept contracts, and some wild rescue contracts, often require leaving nearly immediately if you want to intercept it near perihelion at all and being in the same plane at some point makes rendezvous far easier

This feels like the strongest potential use case - time restrictions forcing a departure where a ballistic trajectory is sub-optimal over a plane change. However RSVP can calculate transfers that would be painful to find manually, so there would have to be a significant delta-v advantage.

I'm enjoying this conversation and please understand, do not intend to come across as overly critical on your suggestion at all! RSVP already has to handle a number of complex edge cases already for common scenarios, so my philosophy is to focus on handling the 90% of common scenarios as best as possible. Adding a feature with niche application that complicates the code base, may not have a good cost/benefit ratio.

Hence metaphorically "kicking the tires" to see if there's a compelling benefit.

I think that time priority rather than fuel priority covers all the cases I brought up really. There is a point in an ISRU game where you leave mostly when you want to as fuel is not the main issue. Waiting for an outer planet relative AN/DN can take a very long time in that flavor of game (Jool to Eeloo, lol), whereas dealing with the relative AN/DN when you cross it, or dealing with it at the destination if it comes to it, can be a lot more useful.

But of course it is completely up to you as it is your baby. Just throwing it out there for pondering

from rsvp.

mgalyean avatar mgalyean commented on June 12, 2024

One last thing, something kept nagging me about your statement about making use of the Oberth effect for doing the plane change at start or destination body. It is my understanding that the Oberth effect only makes a difference for prograde/retrograde burns, and actually makes normal/antinormal burns less efficient (or has no effect, can't remember). But there is a reason inclination changes are typically much cheaper the further from the body one can make them

from rsvp.

maneatingape avatar maneatingape commented on June 12, 2024

One last thing, something kept nagging me about your statement about making use of the Oberth effect for doing the plane change at start or destination body. It is my understanding that the Oberth effect only makes a difference for prograde/retrograde burns, and actually makes normal/antinormal burns less efficient (or has no effect, can't remember)

The greater the velocity the higher the benefit. Doesn't make any difference what direction that velocity is pointing. In the case of an insertion burn RSVP only cares about reducing the total velocity magnitude below the threshold to elliptical (to which the inclination contributes a component).

But there is a reason inclination changes are typically much cheaper the further from the body one can make them

Yup, the slower you're going the lower delta-v is needed for inclination changes. So if you'd like to adjust the inclination post-capture then that's best done at a high AP as possible.

from rsvp.

mgalyean avatar mgalyean commented on June 12, 2024

I'm fairly sure that Oberth only applies if thrust is parallel with the velocity vector because that is the line on which the kinetic energy of the craft exists and it is the kinetic energy on which the effect rests. If it applied to any direction then inclination changes would be more efficient closer to periapsis instead of farthest. The faster one is going, the harder it is to change direction. Newton law's and all. The effect works because it affects direction very little while affecting speed very much; so prograde/retrograde yes, but a 90 degree change in direction is just fighting Oberth, not gaining from it. In other words, an orbiting craft's normal/antinormal non-thrusting velocity is exactly zero by definition of an orbit, so how can it gain from the Oberth Effect when thrusting normal or antinormal?

from rsvp.

maneatingape avatar maneatingape commented on June 12, 2024

I'm fairly sure that Oberth only applies if thrust is parallel with the velocity vector because that is the line on which the kinetic energy of the craft exists and it is the kinetic energy on which the effect rests

Yup, that's the scenario we're considering here. Say you use RSVP to plot an transfer from Kerbin to Moho so that you arrive at Moho's AN. There's no need to match inclination (since you have an intercept) but the velocity difference due to inclination remains. So when thrusting retrograde for the insertion burn the velocity vector will be inclined (relative to Moho's equator) and the resulting orbit post-capture inclined also.

from rsvp.

mgalyean avatar mgalyean commented on June 12, 2024

I think we are merely differing on which orbit matters at what points in a transfer. It seems you are focused on the beginning and ending bodies while I'm trying to consider the intervening solar orbit. And if the moons around the destination body are mostly in equatorial orbit, and that orbital plane mostly matches the parent's orbital plane, then the solar orbital aspects for plane changes are worth considering. Especially when allowing for promoting time constraints and dialing down efficiency constraints

from rsvp.

Related Issues (12)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.