Comments (9)
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.
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.
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.
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.
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.
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.
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.
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.
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)
- Transfers *from* moons not working properly HOT 2
- max_time_of_flight default value
- Allow for transfer into custom orbit HOT 2
- Define minimal altitude
- Add retry logic to transfer creation HOT 1
- Add "impatience_factor" option to weight transfer search by time as well as delta-v
- search.ks fails when time:seconds > 2^31 HOT 1
- Running other files should not include extension HOT 2
- Tried to push NAN into the stack when attempting an intercept from a nearly-approaching orbit HOT 7
- Request: polar insertion HOT 3
- Planning Transfers between Vessels in same SOI hierarchy HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
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.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from rsvp.