Jump to content

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


Recommended Posts

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)

moon_Ret_Transfer.jpg

 

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 by okder
Link to post
Share on other sites
  • 3 months later...
  • 2 weeks later...
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.

Link to post
Share on other sites
  • 1 month later...

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

 

Link to post
Share on other sites
  • 2 weeks later...

@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 by okder
Link to post
Share on other sites
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.

 

Link to post
Share on other sites

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 by okder
Link to post
Share on other sites

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 by PLAD
Link to post
Share on other sites

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 by PLAD
Link to post
Share on other sites
  • 2 weeks later...

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.

Link to post
Share on other sites
  • 2 months later...
  • 2 months later...
  • 4 weeks later...
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 by okder
Link to post
Share on other sites
  • 6 months later...
  • 1 year later...
  • 2 weeks later...

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 by okder
Link to post
Share on other sites
This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...