[1.9,1.8] ascent/descent addon for interplanetory transfer (before launch planning and PLAD's flyby finder interface)

[okder]

fixed and extended functionality in case of returning from moon and doing transfer to another planet (but still need manually choose Orb. Par. of Incl, and moon escape time and vector)

 

update2, it seems after swithing from GravityTurn back to mechjeb addon i lost 4 lines of code in gui, now just copied them back, and Destination speed optimization feature fully function (actually all code was ok, but becouse of that 4 lines no gui for feature was available)... i hope some one could point me out if that happens next time (about feature loss in gui).

p.s. because of loss of such feature i did spend 300 m/s more for transfer showed in picture (for slowing down to orbit destination planet), but it too late to revert fly now, but at least i know how much i did lost :).

Edited January 24, 2017 by okder

[okder]

P.S. still alive and waiting for suggestions

 

[okder]

updated for 1.3 MJ 2.6.1

 

[Nansuchao]

On 21/5/2017 at 0:45 PM, okder said:

P.S. still alive and waiting for suggestions

 

I find this mod extremely interesting, but sadly never able to use it. Probably when MechJeb and RO are updated to KSP 1.3 I'll give it a shot.

[PLAD]

Hello Okder, I still use your addon everytime I start a flyby mission, I'm glad you are keeping it updated.  I have a suggestion for a new function if you are looking for ideas from your users.
Here's the quick version- I'd like a way to enter a start date and start planet, then an arrival date and arrival planet, and then see the departure asymptote line for the transfer projected onto the start planet. I won't need delta-v info, or a drawing of the departure orbit itself, just the asymptote line. There will be the complication that the Lambert finds two solutions but I'd only want the solar-prograde one.
   Here's why- when I perform a piloted mission to a planet I usually leave a carrier ship in orbit around the planet while a lander brings the crew to the surface. After a pre-planned amount of time the crew returns to the carrier and uses it to go off to another planet (usually back home). The problem is that it is hard to visualize what the optimal departure orbit for the carrier will be, since it can be hundreds of days between arrival and departure from the planet. I do know when I plan to leave the planet before I get there. I want a way to visualize what the optimal departure orbit will be before the carrier arrives in orbit at the planet, so that I can make the arrival orbit be one that will allow an optimal departure later. The only things the arrival orbit will need is to intersect the departure asymptote line and to have an inclination high enough to reach my desired landing point on the planet.
   This might also be useful for setting up flybys. If you were, for instance, supposed to leave Kerbin on day 1, flyby Eve on day 186, and then arrive at Duna on day 744, after you had left Kerbin's SOI (using your departure guide) and were fine tuning the Eve flyby you could show the departure asymptote for the Eve (day 186) to Duna (day 744) flight on Eve to set it up properly. Your flyby path would only have to intersect the asymptote on the right side of the Eve and have the right periapsis altitude. This would not work perfectly if your Kerbin-Eve transfer was a bit wrong since the energy of the E186 to D744 leg might no longer match your incoming energy, but it would be close enough to make setting up the flyby much easier.
   I picture it as a straight line going through the center of the planet and up several planet diameters, and the user would rotate the view so that they are looking at the line 'head on' (so it appears as a point) and adjust their path so it crosses that. There might be two solutions, one that goes retrograde around the planet and one that goes prograde, but it would be easy for the user to decide which solution they want to use.
    Thank you again for writing your superb add-on!
PLAD

 

[okder]

@PLAD in simple words you need two features

1. ability to select departure planet (independent of current vessel SOI) or choose it by name?

2. draw ejection trajectory instead of preboosted orbit (actually preboosted orbit with pre-boost = full boost is ejection trajectory, but mechjeb render (which is currently used) draws it very badly).

if i miss something important, please point it out.

p.s. you still need to tune orb.par. of inclination, because it's not that simply, actually if you going to enter orbit you need that apoapsis of your elliptic orbit (with lowest capture delta-v) to be close to apoapsis of preboosted (pre) transfer orbit, as inclination could be changed very cheaply at apoapsis, but if you don't entering orbit, in that case you need full match of ejection trajectory(" departure asymptote line ") to your actual inbound trajectory (i.e. you need to tune both inbound trajectory AND orb.par. of inclination, (in case if arrival/departure dates fixed)).

 

Edited August 7, 2017 by okder

[PLAD]

5 hours ago, okder said:

@PLAD in simple words you need two features

1. ability to select departure planet (independent of current vessel SOI) or choose it by name?

2. draw ejection trajectory instead of preboosted orbit (actually preboosted orbit with pre-boost = full boost is ejection trajectory, but mechjeb render (which is currently used) draws it very badly).

if i miss something important, please point it out.

p.s. you still need to tune orb.par. of inclination, because it's not that simply, actually if you going to enter orbit you need that apoapsis of your elliptic orbit (with lowest capture delta-v) to be close to apoapsis of preboosted (pre) transfer orbit, as inclination could be changed very cheaply at apoapsis, but if you don't entering orbit, in that case you need full match of ejection trajectory(" departure asymptote line ") to your actual inbound trajectory (i.e. you need to tune both inbound trajectory AND orb.par. of inclination, (in case if arrival/departure dates fixed)).

 

1. I would have to select the planet independently of the SOI I'm currently in. For instance if I am currently in the Sun's SOI while traveling from Kerbin to Duna I want to see the departure asymptote (DA) for a future trip from Duna back to Kerbin. That way I can make a mid-course correction to adjust my incoming (to Duna) path to cross the DA, which makes it possible for my future Duna-Kerbin burn to be as inexpensive as possible.

2. I don't need the future ejection trajectory, just the straight line of the DA. You are right that if I go into an elliptical orbit I would need to set the periapsis properly for maximum Oberth effect on the future departure burn, but I usually go into a fairly circular orbit (it is generally cheaper to put extra dV in the orbiter rather than the land/ascent vehicle).  Knowing the direction of the future DA will give me a good idea of where the periapsis should be if I want that though. The problem I foresee is that it will sometimes be impossible to make the incoming orbit cross the future DA , or to put the periapsis near where it should be for maximum efficiency. There would still be benefit in getting as close as possible.

Note that I don't need to know the LAN or inclination of the future departure path since anything that goes through the DA will be good enough.

http://imgur.com/vWDUOx4

There might be a problem in that the incoming path that crosses the DA does not have a high enough inclination to reach my desired landing spot, but once again I could still try to get as close as possible.  I could execute a plane change simultaneously with the orbit entry burn (just like Apollo did at the Moon). If the DA was showing I could place the orbit entry burn node and adjust it to cross the DA.

I really just want something like the black DA line in my old drawing:

http://imgur.com/rFv4gGo

I should make a drawing showing how I figure this would look when I'm using it.

 

[okder]

ok i will try to implement drawing of DA and periapsis circle (depends on it's chosen altitude), and independent of soi and target src/dst selecting (actually Switch by name)

i should point out, that in case of atmosphere presence transfer stage could stay on elliptic trajectory, and descend stage could have heatshield for slowing,

if we use any transfer of energy or (and) impulse from transfer stage(vehicle) to ascend stage(vehicle), then accelerating ascend stage from circular orbit to elliptic orbit of transfer stage(vehicle) would be much cheaper than changing transfer stage(vehicle) orbit.

(impulse could be transferred by laser pressure for example, each time when stages is nearby, thus lowering orbit of transfer stage(vehicle), and rising of ascend stage(vehicle), assuming that transfer stage(vehicle) have much higher mass than ascend stage(vehicle))

 

Edited August 8, 2017 by okder

[okder]

https://drive.google.com/open?id=0B0rgcOJPK_8XSnZSM2h0Vzc4d0U

preview version, still need much testing and may be fixing.

 

[PLAD]

Looks like you Ninja's me. Here is a little album showing what I have in mind but I shall download what you just made and look at it now. Adding the periapsis circle sounds nice, that is basically the departure circle in reverse I think.

Let me study your work before I say anything else.

edit: OK, I ran it and that is superb! It did just what I wanted, I've put 2 more frames in the album above that show it worked. I went into an orbit around Mars that crossed the AD line your addon gave, then set up a node for execution 18 months later with the magnitude that FF gave me for the return trip and it worked as perfectly as my sloppy orbit circulization allowed. The periapsis circle is a nice touch to make the departure node setup a little easier. You nailed it!  Geezum that was fast.

I'm going to try some more things with this over the next few days, like flyby assistance, and testing cases where I can't get into the right arrival orbit without a normal component to the periapsis burn.

Thanks for this!

Edited August 9, 2017 by PLAD

[PLAD]

This works for setting up flybys too. I'm in the middle of a Earth-Venus-Mars, land, Mars-Earth mission and I used it to set up the Earth launch and departure (as usual), the Venus flyby, and the Mars orbit selection. I realized I can always find an arrival orbit that will pass through a given DA line, you just might not be able to reach everywhere on the planet from that orbit. On setting up a flyby it doesn't give a perfect DA direction because my arrival energy will probably never be exactly right for a given transfer, but it is so close that it is easy and fast to fine tune the flyby using the DA line from your addon as a starting point. Figuring out whether to use the short path or long path is easy because the wrong one will have a "boost from circular" of  many times the dV of the right one. (For instance with my Venus flyby one was 55 km/s, the other about 6 km/s).

More testing.... (to the casual observer this may look like playing, but I'm testing, testing)

Edited August 13, 2017 by PLAD

[okder]

@PLAD small problem here is that i did fix more than six bugs which was not reported here, still testing.

(will have new feature - select orbit inclination parameters by mouse clicking on some src planet position)

 

[okder]

new version released (links are the same). (~10 bugs fixed from intermediate version, and new feature (see prev. post(s)) )

 

Edited August 20, 2017 by okder

[PLAD]

Hello @okder, I just wanted to say that I have tried this with stock KSP, RSS/RO, GPP, and the GPP 10.625x rescale and it works well with all of them. I use it for all my interplanetary flights now including simple 2-body transfers, since the launch guidance, transfer node, and correction node work for any flight whether it will lead to a flyby or not. It also greatly simplifies setting up a flyby, I don't bother to try setting one up without it now.

 Thanks again for this.

[murradus]

Does anyone have an older version that will work with MJ 2.6.0? I have a 1.2.2 save that i would like to use this on.

[okder]

@murradus did you tried current version?

please provide error log (only exceptions/errors needed)

Edited November 15, 2017 by okder

[Lukas1]

Hi, I have a question. I installed the mod on version 1.3.1, but I did not have the Ascent StarTtime window 

Spoiler

 

Edited January 18, 2018 by Lukas1

[okder]

On 1/18/2018 at 3:02 PM, Lukas1 said:

Hi, I have a question. I installed the mod on version 1.3.1, but I did not have the Ascent StarTtime window 

 

need KSP.log all errors and messages around errors

probably you have too new mechjeb...

yea mecheb 2.7 changed some things, partially it's my fault (i did used some fields, which was internal just for optimization sake, now they protected, so it crashes on access).

updated and minimally tested for mechjeb 2.7.0 and ksp 1.3.1

 

Edited February 14, 2018 by okder

[Tosti]

How well does it work with principia?

[romanasul]

Any chance of updating for newest Mechjeb?

[okder]

updated for 2.9.2.0, tested with ksp 1.8.1, probably could work with 1.9, but untested.

there were too many changes in mechjeb, some code from old mechjeb included for compatibility.

 

Edited April 14, 2020 by okder

[okder]

another update for proper direction selection (it was buggy for several versions).

[romanasul]

Wow, thanks!

[okder]

CreateCorrectionNode partially fixed with workaround (buggy mechjeb code)

 

[okder]

laythe -> vall fixes and refactor begin

https://drive.google.com/file/d/1WzovyRVp_aYhe9p_UOdWcoMtDL_h2RH2/view?usp=sharing

many changes soon, sources would go in initial link, but dll s in separate link for now.