[WIN/MAC/LINUX] KSP Trajectory Optimization Tool v1.6.10 [Major LVD Improvements!]

[storm6436]

So, random question:  is there an easy way to plot multiple burn departures?  Oddly enough I'm not using ions for this  

 I had a mission vehicle, quad nukes at roughly 0.6 TWR,   that was supposed to deliver 5 comm sats (2 polar uplinks, 3 equatorial relays)  to Moho in a slightly less than optimum launch window, about 5.5k dV total.  While I have other show stoppers (like Remotetech deciding no connection available despite no obstructions and both ends using HG-5Ss pointed to eachother, yay for quicksave), my TWR is too low to dump out the 2.4k dV required on the initial pass at my parking orbit (~80k).  Ended up dumping a fair amount of fuel before I realized what was going on, made a second maneuver once I got out of Kerbin SOI, figure I wasted about 500 dV above fuel allotment for departure, but at that point it was more about being bullheaded and proving I could get there anyway

 

 I'll apologize if this was covered somewhere in the 90+ pages earlier. Just woke up and prepping for class, haven't had time to skim the whole thread yet. 

[Arrowstar]

38 minutes ago, storm6436 said:

So, random question:  is there an easy way to plot multiple burn departures?  Oddly enough I'm not using ions for this  

 I had a mission vehicle, quad nukes at roughly 0.6 TWR,   that was supposed to deliver 5 comm sats (2 polar uplinks, 3 equatorial relays)  to Moho in a slightly less than optimum launch window, about 5.5k dV total.  While I have other show stoppers (like Remotetech deciding no connection available despite no obstructions and both ends using HG-5Ss pointed to eachother, yay for quicksave), my TWR is too low to dump out the 2.4k dV required on the initial pass at my parking orbit (~80k).  Ended up dumping a fair amount of fuel before I realized what was going on, made a second maneuver once I got out of Kerbin SOI, figure I wasted about 500 dV above fuel allotment for departure, but at that point it was more about being bullheaded and proving I could get there anyway

 

 I'll apologize if this was covered somewhere in the 90+ pages earlier. Just woke up and prepping for class, haven't had time to skim the whole thread yet. 

No worries!  Basically the departure code is designed to give a quick and easy maneuver plan for estimating DV requirements and for execution of you have high thrust to weight. 

If you don't have this, you'll need to break up the depature burn into a series of burns. This more complicated approach should be modeled on Mission Architect. Basically you would create the burn in MA as shown in the departure screen, the right click on the burn and click "split burn" or something like that. You'll then need to use the optimizer on the burns and itermediate coasts to target whichever body you're going to. 

Okay, so that's a fairly long explanation, but it's the gist of it anyway. I suppose the big take away is that modeling multi burn departures with low thrust engines is hard. :-) 

Let me know if you have any questions!

[Gilph]

4 hours ago, storm6436 said:

So, random question:  is there an easy way to plot multiple burn departures?  Oddly enough I'm not using ions for this  

 I had a mission vehicle, quad nukes at roughly 0.6 TWR,   that was supposed to deliver 5 comm sats (2 polar uplinks, 3 equatorial relays)  to Moho in a slightly less than optimum launch window, about 5.5k dV total.  While I have other show stoppers (like Remotetech deciding no connection available despite no obstructions and both ends using HG-5Ss pointed to eachother, yay for quicksave), my TWR is too low to dump out the 2.4k dV required on the initial pass at my parking orbit (~80k).  Ended up dumping a fair amount of fuel before I realized what was going on, made a second maneuver once I got out of Kerbin SOI, figure I wasted about 500 dV above fuel allotment for departure, but at that point it was more about being bullheaded and proving I could get there anyway

 

 I'll apologize if this was covered somewhere in the 90+ pages earlier. Just woke up and prepping for class, haven't had time to skim the whole thread yet. 

iirc, there was a mod called mechval, that handled very low twr burns, which sounds like what you are looking for. Never used it myself, but you may wish to see if it will help.

[storm6436]

4 hours ago, Arrowstar said:

No worries!  Basically the departure code is designed to give a quick and easy maneuver plan for estimating DV requirements and for execution of you have high thrust to weight. 

If you don't have this, you'll need to break up the depature burn into a series of burns. This more complicated approach should be modeled on Mission Architect. Basically you would create the burn in MA as shown in the departure screen, the right click on the burn and click "split burn" or something like that. You'll then need to use the optimizer on the burns and itermediate coasts to target whichever body you're going to. 

Okay, so that's a fairly long explanation, but it's the gist of it anyway. I suppose the big take away is that modeling multi burn departures with low thrust engines is hard. :-) 

Let me know if you have any questions!

I missed the split burn feature. Bleh, sorry.  Still kinda frustrated at myself for not expecting it with non-ions. On the plus side, now that I know about that feature I can start using ions more.

 Well, that and here's hoping I can figure out why Remotetech was deep sixing my comms with clear LOS and more than sufficient range available on two dishes targeting each other. 

[Gilph]

Quote

Hey there, KSPTOT author here.  I'm not sure what GPP is but if you post over on the other thread or PM me we can talk about it.  Thanks!

Hi, @Arrowstar

GPP is the Galileo Planet Pack.  It removes all of the stock bodies, including the sun, and replaces them with a whole new set.  I had tried to test TOT by creating a bodies file in a GPP save.  None of the dialogs worked correctly and I get loading errors if I try and start from scratch.  My post was as an FYI for someone who thought TOT could solve their issue in a GPP configuration. I would assume that TOT does not support this kind of configuration?

[Arrowstar]

18 hours ago, Gilph said:

Hi, @Arrowstar

GPP is the Galileo Planet Pack.  It removes all of the stock bodies, including the sun, and replaces them with a whole new set.  I had tried to test TOT by creating a bodies file in a GPP save.  None of the dialogs worked correctly and I get loading errors if I try and start from scratch.  My post was as an FYI for someone who thought TOT could solve their issue in a GPP configuration. I would assume that TOT does not support this kind of configuration?

So you get errors from trying to create the bodies file or errors when trying to load/use the bodies file afterwards?

If the latter, can I see the file please?  Thanks!

[Gilph]

7 hours ago, Arrowstar said:

So you get errors from trying to create the bodies file or errors when trying to load/use the bodies file afterwards?

If the latter, can I see the file please?  Thanks!

It was the latter. Here is the file: https://1drv.ms/f/s!AigvIEvgjetqyA4BE5I7SUm9og7S

When I load it, the main screen has the correct Transfer Central Body, but the departure and arrival dialog boxes disappear:

Also, Rendezvous Planner doesn't want to load.  If I start TOT from scratch with this loaded by default, I get:

Thanks

[Arrowstar]

18 minutes ago, Gilph said:

It was the latter. Here is the file: https://1drv.ms/f/s!AigvIEvgjetqyA4BE5I7SUm9og7S

When I load it, the main screen has the correct Transfer Central Body, but the departure and arrival dialog boxes disappear:

<snip>

Also, Rendezvous Planner doesn't want to load.  If I start TOT from scratch with this loaded by default, I get:

<snip>

Thanks

The issue is that you don't have a body called "Sun" in the bodies.ini file.  If you do a find/replace of "Ciro" for "Sun" and then restart KSPTOT and reload the file, it should work.

This is a requirement of the software.  There's a note in the header of the bodies.ini file that comes with KSPTOT that reads:

Quote

; Each bodies.ini file required a body called "Sun" with all
; zero orbital elements.

 

Edited April 16, 2017 by Arrowstar

[Drew Kerman]

minor issue: I went to create a coast to next SOI but by rote I highlighted the True Anomaly field and deleted the value to make ready to enter one and then was like "oh, yea, I want to coast to next SOI" so I switched the coast type and hit enter and it gave me an error for the TA box having no value. No biggie I just closed and re-opened the dialog (or could have just switched back to TA type and put a 0 back in the box). Just FYI

I also don't like that if you switch from TA to UT coast types the optimization values (I'm talking the default ones that are always there when you open the Create Coast dialog) immediately go out of range and you have to always uncheck the box - but on the other hand I guess it can be helpful sometimes to be aware that your ranges are no longer valid...

Edited April 16, 2017 by Drew Kerman

[Gilph]

3 hours ago, Arrowstar said:

The issue is that you don't have a body called "Sun" in the bodies.ini file.  If you do a find/replace of "Ciro" for "Sun" and then restart KSPTOT and reload the file, it should work.

<sigh> of course...reading the instructions...such a crazy plan, it just might work.  And it did.  Thanks again.

[somnambulist]

Could someone help me out with a problem I'm having using KSP TOT in a 3.2x rescaled solar system? I've gone through the steps to generate and import a bodies.ini of the rescaled system but every transfer I plot comes up well short of the target body.

As a test, I cheated a craft into an orbit with a 2120km SMA (200km parking orbit -- Kerbin's radius is 1920km in a 3.2x rescale) with zero inclination and zero eccentricity.  KSP TOT's calculation for a Duna flyby comes up 10 million+ KM short. MechJeb's transfer planner doesn't get an encounter but it gets a close approach that's easily tweaked into an encounter. I'm seeing the same thing on every body I try -- a Moho intercept gives me a PE that's barely inside Eve's orbit, Jool is several AU short, etc. 

My bodies.ini is up on Pastebin. The orbital parameters match-up with what I'm seeing in-game so either KSP TOT is doing something funky or I'm using it wrong.

 

[Gilph]

Hi,

If I may ask what might be a simple question, is there any case where we need to adjust times manually if we are using KSPTOT Connect? I've been going through the old tutorials where we had to subtract a year and a day in MJ and had to move time to before/after Pe to get the right intercept.  We don't need to do any of that anymore, right?

[Cristy2017]

I can't install MCR 

I have W10 and I get the message ''This app can't run on your PC'' 

Edit: Nevermind it was a download problem

Edited April 19, 2017 by Cristy2017

[Arrowstar]

On 4/17/2017 at 10:09 PM, somnambulist said:

Could someone help me out with a problem I'm having using KSP TOT in a 3.2x rescaled solar system? I've gone through the steps to generate and import a bodies.ini of the rescaled system but every transfer I plot comes up well short of the target body.

As a test, I cheated a craft into an orbit with a 2120km SMA (200km parking orbit -- Kerbin's radius is 1920km in a 3.2x rescale) with zero inclination and zero eccentricity.  KSP TOT's calculation for a Duna flyby comes up 10 million+ KM short. MechJeb's transfer planner doesn't get an encounter but it gets a close approach that's easily tweaked into an encounter. I'm seeing the same thing on every body I try -- a Moho intercept gives me a PE that's barely inside Eve's orbit, Jool is several AU short, etc. 

My bodies.ini is up on Pastebin. The orbital parameters match-up with what I'm seeing in-game so either KSP TOT is doing something funky or I'm using it wrong.

 

Can I see some screenshots of KSPTOT inputs and outputs?  I'll take a look and see what the issue is.

22 hours ago, Gilph said:

Hi,

If I may ask what might be a simple question, is there any case where we need to adjust times manually if we are using KSPTOT Connect? I've been going through the old tutorials where we had to subtract a year and a day in MJ and had to move time to before/after Pe to get the right intercept.  We don't need to do any of that anymore, right?

I'm not sure about the year and day thing in MJ, because I haven't used MJ in a long time.  I suspect that it still is.  The moving the burn time before or after Pe is still applicable if you don't use Mission Architect to further refine your mission plan.

3 hours ago, Cristy2017 said:

I can't install MCR 

I have W10 and I get the message ''This app can't run on your PC'' 

Edit: Nevermind it was a download problem

Glad to hear you got it fixed!

[somnambulist]

23 hours ago, Arrowstar said:

Can I see some screenshots of KSPTOT inputs and outputs?  I'll take a look and see what the issue is.

This is an Eve transfer instead of Duna because the Mun is in the way of the first optimal Duna window. I think the problem might be with the departure time -- if you take the exact same maneuver node and move it back to approximately 17251667 UT (~~30 minutes) you will start getting Eve encounters.

https://imgur.com/a/fDAv7

If you want to try to replicate the problem, install Sigma Dimensions and its dependencies, and use this as the CFG file. 

 

SigmaDimensions
{
	// Base Settings

	Resize = 3.2
	Rescale = 3.2
	Atmosphere = 1.12
	dayLengthMultiplier = 3.2


	// Advanced Settings

	landscape = 1
	geeASLmultiplier = 1

	resizeScatter = 1
	resizeBuildings = 0

	CustomSoISize = 0
	CustomRingSize = 0

	atmoASL = 1
	tempASL = 1
	atmoTopLayer = 1.25
	atmoVisualEffect = 1.12

	scanAltitude = 1.25
}

 

[Arrowstar]

16 hours ago, somnambulist said:

This is an Eve transfer instead of Duna because the Mun is in the way of the first optimal Duna window. I think the problem might be with the departure time -- if you take the exact same maneuver node and move it back to approximately 17251667 UT (~~30 minutes) you will start getting Eve encounters.

https://imgur.com/a/fDAv7

If you want to try to replicate the problem, install Sigma Dimensions and its dependencies, and use this as the CFG file. 

 

SigmaDimensions
{
	// Base Settings

	Resize = 3.2
	Rescale = 3.2
	Atmosphere = 1.12
	dayLengthMultiplier = 3.2


	// Advanced Settings

	landscape = 1
	geeASLmultiplier = 1

	resizeScatter = 1
	resizeBuildings = 0

	CustomSoISize = 0
	CustomRingSize = 0

	atmoASL = 1
	tempASL = 1
	atmoTopLayer = 1.25
	atmoVisualEffect = 1.12

	scanAltitude = 1.25
}

 

Okay, the issue is that you are targeting the departure without giving KSPTOT any information about the orbit epoch and mean anomaly. These are in that compute departure screen. If you provide them, KSPTOT can adjust the departure accordingly. 

What this means is that KSPTOT is just using the optimal departure time without full info about your orbit. So of course you're going in an unexpected direction, KSPTOT doesn't know where you are! :-) 

Fill in those two fields accurately and try again. It should be better. Keep in mind that you'll only get full accuracy of you plan the maneuvers in Mission Architect. All of the other interplanetary maneuver planning tools are approximate only. :-) 

[Drew Kerman]

found another one, same issue as before - pulling data from the game gives wrong TA but save file works - http://www.blade-edge.com/misc/MA Test.zip

[somnambulist]

On 4/21/2017 at 5:44 AM, Arrowstar said:

Okay, the issue is that you are targeting the departure without giving KSPTOT any information about the orbit epoch and mean anomaly. These are in that compute departure screen. If you provide them, KSPTOT can adjust the departure accordingly. 

D'oh. I just knew I was screwing it somewhere. I entered *all* the numbers and got a perfect ejection burn node. Thanks!

[Arrowstar]

On 4/24/2017 at 6:20 AM, Drew Kerman said:

found another one, same issue as before - pulling data from the game gives wrong TA but save file works - http://www.blade-edge.com/misc/MA Test.zip

Alright, let me know if this pre-release resolves the issue.

2 minutes ago, somnambulist said:

D'oh. I just knew I was screwing it somewhere. I entered *all* the numbers and got a perfect ejection burn node. Thanks!

Perfect!  Glad to hear it!

[Drew Kerman]

31 minutes ago, Arrowstar said:

Alright, let me know if this pre-release resolves the issue.

tested on the real article and it works great. Thanks, will continue to keep my eyes peeled

Also, I just realized this dialog is a bit... off:

OK & Cancel would be better button labels IMO since the dialog doesn't actually ask the user to make a decision. Or just add "Are you sure you want to quit?"

[Arrowstar]

3 minutes ago, Drew Kerman said:

tested on the real article and it works great. Thanks, will continue to keep my eyes peeled

Also, I just realized this dialog is a bit... off:

OK & Cancel would be better button labels IMO since the dialog doesn't actually ask the user to make a decision. Or just add "Are you sure you want to quit?"

Thanks for the heads up, I agree.  Resolved for next release (it was an easy fix).

[Drew Kerman]

1 minute ago, Arrowstar said:

it was an easy fix

I like to throw some of those your way every now and then too

[Arrowstar]

I have a couple small new features I want to share with the KSPTOT user community tonight.

The first is that I've completely revamped the way spacecraft relative motion is computed in KSPTOT Mission Architect.  Previously I used what's called a recti-linear coordinate system when computing the prograde/normal/radial components of the position of the Reference Spacecraft relative to your spacecraft.  This means that, for example, a reference spacecraft in the same circular orbit but 10 degrees behind would appear to be located in a position which was negative in both "prograde" and "radial" positions.  When you think about it, this makes no sense: the reference spacecraft is really along the prograde direction, it's just behind a bit.

My solution to this is to completely redevelop the way these coordinates are presented.  First, they've been renamed to a more industry-standard "radial/in-track/cross-track".  In-track is like prograde and cross-track is like normal, as a conversion.   Second, I now use a curve-linear coordinate system (that I'm proud to say I developed myself after I found no one else had a textbook chapter or research paper devoted to the subject) to present these quantities.  This means that, for example, you can now show charts like this using Graphical Analysis:

The Station is located at 0,0 in this plot, and the orange trace is my spacecraft.  I approach from below and behind, pop up from in front to trend backwards, and then ultimately approach from the top (where the presumed docking port is). 

These variables are available in the Mission Optimizer so you can optimize on them as well.  In addition, there is an "inverse" plot available where your spacecraft is the center of the plot and the reference spacecraft moves around it.  But I like this version, personally: it shows the motion of my spacecraft better in my opinion.

The MAT file that produced this plot will be a new Mission Architect example in the next release.

Next, a smaller announcement.  Mission Architect will now have a new event type called "Docking."  This is very simple: all it does is set your spacecraft position and velocity (and central body) to that of the selected Other Spacecraft for the set period of time that you denote.  After that period of time, other propagate and maneuver events can then modify the orbit as usual.  You can see the docking event in use below.

The idea is that you could use the new data types I showed above to get close to the station (and in my example, I get to within 10 meters), and then use the Docking event to fix your position at the station to simulate being docked there.  "Undocking" occurs after the event.

This new event type is compatible with all existing Other Spacecraft in existing MAT files you might have and also allows you to still consume or convert resources just as you would with a standard coast.

And there we are, that's all!  Thoughts?

Edited May 3, 2017 by Arrowstar

[Drew Kerman]

I didn't really grasp all of that first half but I'm sure it will become clear in time once I get some hands-on experience! Yay more cool plots to make. My followers have especially been liking these plots I make for all the asteroids swinging by Kerbin, I get asked a lot about how they are made and point them straight here

[Drew Kerman]

hey @Arrowstar I just noticed that all the Outer Planet Mod bodies except the moon Hale show up in the celestial body catalog with Epoch values hours or even days ahead of 0 like all the stock planets. I'm not sure why - could this be a KSPTOT issue or maybe something with Kopernicus? I created a new game so the UT was 0 and imported body values from it, but the catalog (and in fact the rendezvous planner) show Epoch values greater than 0. I mean, it's not really a huge issue cause no one is going to get out there in a few hours or days to need to know where the bodies are before then, but I also can't figure out why these bodies would have a starting Epoch that is not 0.