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

[blu3wolf]

I have used this tool to solve a variety of orbital problems from a wide variety of starting orbital configurations, including very high eccentricity and highly inclined orbits.

 

[Wcmille]

Does that include hyperbolic escape orbits (e.g.  interplanetary travel)?

[blu3wolf]

Ive done it with hyperbolic orbits around minmus, so sure.

That said, the specific tool I was using that I am thinking of, the Rendezvous Maneuver Sequencer, assumes you will only make 2 burns, so for a hyperbolic trajectory it is quite inefficient; I found I could save lots of delta V by circularising first, then solving the problem.

Next question is what sort of problem do you have? There is a lot of tools included in this software, but all of the ones I have tried, you could input the starting orbit, to include inclination and eccentricity. In fact, if KSP is running in the background, you can have it pull the orbital parameters directly from it (or even if it is not running, but its a little faster if it is running).

The toolset that TOT provides is I can safely say the most powerful that I have ever used for KSP, in any event. I think you will like it.

[Wcmille]

I want to do things like be in an inclined, elliptical orbit around Eve, and find a transfer solution back to Kerbin. Things like Alex Moons Transfer Window planner can't do that.

[Drew Kerman]

1 hour ago, Wcmille said:

I want to do things like be in an inclined, elliptical orbit around Eve, and find a transfer solution back to Kerbin. Things like Alex Moons Transfer Window planner can't do that.

Totally doable. If you run up against a wall post the SFS file containing your ship's current orbit that you're looking to find a transfer for

[blu3wolf]

Hmm... not sure which tool would be best for that. So the problem is limited deltav, a specific starting orbit around eve (which is highly elliptical, highly inclined), and a transfer solution back home.

Thinking about it, you need to find transfers into a specific hyperbolic trajectory around eve which lead into a transit orbit back to kerbin. So you need the specific hyperbolic orbit around eve to have a similar RAAN, a similar inclination, as well. The basic two body porkchop plot for TOT could do this couldnt it? Then once it has a candidate trajectory, put it into the mission architect... yeah that sounds totally doable!

 

[Sigma88]

On 25/12/2015 at 11:32 PM, Gaiiden said:

so hey @Arrowstar if you have some free time + motivation over the holiday may I suggest taking a look at Sigma Binary? It adds barycenters to planetary systems. I haven't yet explored the full implications of using it with KSPTOT but here's the .ini file if you want to have a look.

If you are still having troubles/doubts about Sigma Binary feel free to pm me, I will be more than happy to help you with whatever you may need

EDIT:

quoted the wrong guy  I meant to ping @Arrowstar

Edited January 13, 2016 by Sigma88

[Arrowstar]

So you can do binaries so long as, from a modeling perspective, you can pretend they are normal systems. The solar system tree hierachy concept is fundamental to KSP TOT, so that can't change to support binary systems exclusively. But feel free to work within the capabilities I've already provided. 

Sorry for my absense lately, btw, life has been busy and I recently took up astronomy as a hobby so that's kept me occupied as well. :-) 

[Sigma88]

8 minutes ago, Arrowstar said:

So you can do binaries so long as, from a modeling perspective, you can pretend they are normal systems. The solar system tree hierachy concept is fundamental to KSP TOT, so that can't change to support binary systems exclusively. But feel free to work within the capabilities I've already provided. 

Sorry for my absense lately, btw, life has been busy and I recently took up astronomy as a hobby so that's kept me occupied as well. :-) 

do you calculate Sphere of influences or do you just take the value saved in the bodies parameters?

If you calculate them I could see it breaking when using SigmaBinary, if you load them from KSP than everything should work fine.

for example, in ksp the barycenter is basically a planet. but if you fly through it you won't be slingshotted away because you will be actually in another Sphere of influence (for example the SoI of Pluto)

Edited January 13, 2016 by Sigma88

[Arrowstar]

Sphere of influence radius is computed, not stored from KSP itself. 

[Sigma88]

9 minutes ago, Arrowstar said:

Sphere of influence radius is computed, not stored from KSP itself. 

Actually with custom planets you may choose to override ksp calculation and set a desired value for the sphere of influence.

To give you an example, opm sets the sphere of influence of some of the smaller moons to make it easier to approach them and RSS uses a feature of kopernicus that calculates sois differently.

So if you load the values from ksp (which is what I assume you do when you generate the bodies file) then youll end up with the modofied sois.

On the other hand, if your program calculates sois independently, you may end up with different values than the ones in game

[Arrowstar]

Just now, Sigma88 said:

On the other hand, if your program calculates sois independently, you may end up with different values than the ones in game

This is what I meant, KSPTOT computes them independently. 

[Sigma88]

17 minutes ago, Arrowstar said:

This is what I meant, KSPTOT computes them independently. 

Yeah I misunderstood your post

So there will be probably some issues with sigmabinary since soi calculation is an important part of the mod :/

Edit:

I just realized that probably you calculate orbital periods too.

if that's the case, RSS overrides the standard orbital period calculation.

Stock ksp uses only the primary mass, while rss uses the sum of primary and secondary masses

This may be also cause for discrepancy

Edited January 13, 2016 by Sigma88

[Drew Kerman]

9 hours ago, Sigma88 said:

I just realized that probably you calculate orbital periods too.

if that's the case, RSS overrides the standard orbital period calculation.

Stock ksp uses only the primary mass, while rss uses the sum of primary and secondary masses

This may be also cause for discrepancy

Yea, Arrowstar and I managed to figure this out last year after the problem plagued my operations for weeks. NathanKell added in a cfg variable that turned off the RSS orbital period calculations - I'm not sure if it's still a cfg option or not, I stopped using RSS once Kopernicus got its atmosphere modifying code working (was using only using RSS to get rid of Kerbin's white atmo)

10 hours ago, Sigma88 said:

To give you an example, opm sets the sphere of influence of some of the smaller moons to make it easier to approach them and RSS uses a feature of kopernicus that calculates sois differently.

Thx for the heads up on that, I didn't realize. I will have to remember to check which ones are off and modify their configs to match what KSPTOT calculates.

Bummer on the binaries, but it'll take me a while to reach Duna again so maybe by then it will be viable...

[Sigma88]

6 hours ago, Gaiiden said:

Yea, Arrowstar and I managed to figure this out last year after the problem plagued my operations for weeks. NathanKell added in a cfg variable that turned off the RSS orbital period calculations - I'm not sure if it's still a cfg option or not, I stopped using RSS once Kopernicus got its atmosphere modifying code working (was using only using RSS to get rid of Kerbin's white atmo)

Thx for the heads up on that, I didn't realize. I will have to remember to check which ones are off and modify their configs to match what KSPTOT calculates.

Bummer on the binaries, but it'll take me a while to reach Duna again so maybe by then it will be viable...

they are both kopernicus features that are independent from the RSS dll

orbital period is recalculated when the Body node of the planet has the parameter

finalizeOrbit = true

Sphere Of Influence are recalculated if the body node of the planet has the parameter

finalizeOrbit = true

in addition, if the Body/Properties node has the parameter

sphereOfInfluence = #number#

that value will override the SoI calculation

 

so basically you will need to remove all of those parameters if you want the game to be consistent with your tool

something like this should do:

@Kopernicus:FINAL
{
	@Body,*
	{
		!finalizeOrbit = DEL
		@Properties
		{
			!sphereOfInfluence = DEL
		}
	}
}

 

of course, doing this will alter the behaviour of the mod and will most likely break any SigmaBinary installation

[Drew Kerman]

should just be able to say !finalizeOrbit to delete something - although as I wrote that I realize you probably added the = DEL just to make it clear what its doing. Didn't realize Kopernicus did it too! Thx. Maybe Arrowstar can find some workaround to make KSPTOT play nice with Sigma Binary but until then I'm not going to be able to use it. Binaries are pretty cool tho - he might be swayed

[Sigma88]

35 minutes ago, Gaiiden said:

should just be able to say !finalizeOrbit to delete something - although as I wrote that I realize you probably added the = DEL just to make it clear what its doing. Didn't realize Kopernicus did it too! Thx. Maybe Arrowstar can find some workaround to make KSPTOT play nice with Sigma Binary but until then I'm not going to be able to use it. Binaries are pretty cool tho - he might be swayed

Module manager used to require an equal sign and some text after it in order to actually delete the parameter.

That's why I always use = DEL

I don't know if that is not the case anymore tho  (reference)

regarding sigmabinary, I think it's safe to assume that if you create the bodies file for KSPTOT without SigmaBinary and restart the game with SigmaBinary later, the calculations for the "Binary-less" system should work fine also with the "Binary-yes" one

you can test that by planning a Duna slingshot with the stock KSPTOT and compare the results with and without SigmaBinary

Edited January 14, 2016 by Sigma88

[Drew Kerman]

new entry in the KSP Wiki: Graphing Techniques in Mission Architect

If you ever saw one of my KSA plots/charts and were like "how?!" then click that link.

[mcirish3]

Unfortunately the parameter 

rotini = Initial rotation about the body spin axis at given epoch [deg]

Does not explain what Longitude it is relative to.  I happen to know this number is not relative to 0^o 0' 0" on Duna (duna is set to 90 and Kerbin is set to 90)  BUT kerbin is rotated exactly 90 degrees from Noon( sunset),  However the sun is s at approximately 45 degrees from noon at that same time at  0^o 0' 0" on Duna. where t=0y 0d 0h 0m 0s

Any chance someone knows and if you know how it was set is it possible to determine what it is relative to?  I think I have an accurate way to figure this out experimentally in game but knowing the Latitude rotini is measured relative to would be way faster and easier.

[Drew Kerman]

there were issues with meridian calculation I had a while ago thanks to another mod messing with numbers in the game, but @Arrowstar never had to go into details with me about how KSPTOT got the planet meridian. He's mostly doing other things these days but still comes around every now and again so if you don't have it by the time he does hopefully he can give you some more info

[mcirish3]

3 hours ago, Gaiiden said:

there were issues with meridian calculation I had a while ago thanks to another mod messing with numbers in the game, but @Arrowstar never had to go into details with me about how KSPTOT got the planet meridian. He's mostly doing other things these days but still comes around every now and again so if you don't have it by the time he does hopefully he can give you some more info

Thanks for the info I find it odd that there is a variable for initial planet rotation with out a way to figure out what  that rotation is relative too.  Obviously it works it just seems weird to put one piece of info in an .ini and not the other.

As for how I will be figuring this out per @OhioBob's suggestion.

One thing you might do is to land a probe on each planet and use KER to record, for a specific time, your geographic longitude and celestial longitude.  From that you should be able to compute the longitude of the prime meridian at a particular data and time.

For example, let's say you're on Eve at a geographic longitude of 60.00000^o W.  At the time of Y10, D100, 0:00, you note that your probe's longitude of Pe is 90.00000^o.  The celestial longitude of your landed probe is that of Pe + 180^o, i.e. 90+180 = 270^o.  Since you're 60^o west of 0^o longitude, the celestial longitude of the prime meridian at the time of the observation is 270+60 = 330^o.

Given the date and time of Y10, D100, 0:00, we know that exactly 9 years, 99 days has passed since Y1, D1, 0:00 (i.e. 0s UT).  In seconds this is, (9*426+99)*21600 = 84,952,800 s.  Since Eve's sidereal rotation period is 80500 s, the number of rotations it has made since 0s UT is, 84952800/80500 = 1055.314285714.  This tells us that the prime meridian is currently 0.314285714 of a rotation east of where it was at 0s UT.  Therefore, the celestial longitude of the prime meridian at 0s UT is, 330-(0.314285714*360) = 216.85714^o.

So if you got a better method or want to help please feel free to do so.

[Arrowstar]

It's relative to the ksp universe x axis. :-) 

It's relative to the ksp universe x axis. :-) 

[mcirish3]

1 hour ago, Arrowstar said:

It's relative to the ksp universe x axis. :-) 

It's relative to the ksp universe x axis. :-) 

Great and how pray tell do I know were that is.  Should I assume that it runs directly through Kerbin and Sol at T=0?  (Because that actually would make a lot of sense to me)

Edit: or is that what the mean anomaly is measured against.

Edited January 25, 2016 by mcirish3

[Arrowstar]

It's the line at which any orbit, when crossing the equatorial plane at that line, has a RAAN of 0 degrees. 

[mcirish3]

2 hours ago, Arrowstar said:

It's the line at which any orbit, when crossing the equatorial plane at that line, has a RAAN of 0 degrees. 

Yes in general.  For KSP inparticular?  KSP must have a  world X direction at T=0, yes? (by world I mean the KSP universe)

Edited January 25, 2016 by mcirish3