[WIN/MAC/LINUX] KSP Trajectory Optimization Tool v1.6.9 [New MATLAB Version!]

[Joshie]

Which is what makes me suspect that the bodies.ini is the problem. If the manoeuvre is exactly the same, but doesn't pan out the same way in KSP than it did in KSPTOT, then it would seem possible that KSPTOT and KSP itself have different solar system configurations. I've never loaded a bodies.ini file, and I've never had a problem like you describe. What happens if you don't load the bodies.ini file?

OK, So without using the bodies.ini file the planets in mission architect are colored but I have the same results: http://gyazo.com/06b1b4620ed3336aae79247a81ac1693

[Snoman314]

You are trying to import orbital states from KSP, right?

Can you provide some more information about what exactly you are doing?

There are two ways of interacting with KSP. You can import from the persitent.sfs or you can download directly from KSP via ksptotconnect. Which one are you using?

I have KSPTOTConnect installed, but it's never worked for me on this current install. I've been quicksaving, then importing from the persistent.sfs and/or quicksave.sfs. I then get a list of vessels (and some asteroids) that are currently in the game, except that there are vessels missing. The first one that was missing was when I first posted a few days ago. Now there are a bunch of the latest probes I launched that aren't showing up.

Edit: OK, that's interesting. I just removed all the debris from space (about 6 objects), and then quicksaved from a different vessel. Now the one I was trying to load is showing up. Not sure if it was saving from a different vessel, or getting rid of the debris that did it.

Edit2: I'm starting to suspect that it just doesn't show the currently active vessel. I'll have to test more on the weekend.

Edited November 21, 2014 by Snoman314

[Snoman314]

OK, So without using the bodies.ini file the planets in mission architect are colored but I have the same results: http://gyazo.com/06b1b4620ed3336aae79247a81ac1693

Well, other than the fact that the orbit in KSP is now massively overshooting instead of undershooting, but that could have been something else.

Hmm, have you selected the correct object to import the initial state orbital variables from? Get the wrong one and that could give you nonsense results like this. (Just another idea, you may have noticed that I don't really know what your problem is.)

[Drew Kerman]

a possible useful tweak for the graphical analysis tool, is for the AP/PE lines to only extend upwards as far as the data line being graphed. The reason is that I can set a data tip to the line and it can snap to the end points of the line. Since one of the line end points will be where it meets up with the graphed data, I can get a precise intersection without having to zoom way in to find it - mainly for graphs whose resulting plot lines are fairly vertical, like this:

Additionally, it might be useful to have zoom buttons that, instead of giving you the magnifying glass to choose an area/place to zoom on, simply zooms in/out at the position of the current data cursor. The problem with this tho is that you can have more than one data cursor on the graph Unless there's a way to show which one was last selected to be considered the "active" one, I suppose this idea, while nice, wouldn't work to well.

Edited November 22, 2014 by Gaiiden

[Drew Kerman]

Here's what I know will be a tricky request - any way this tool could help me point my craft towards objects for photos? Right now I'm just guessing numbers into Remote Tech's flight computer until I get the proper orientation.

[Drew Kerman]

I have an asteroid that was captured by Mun's gravity into orbit around Kerbin. Now, when I set a maneuver node and progress the orbit ahead several times I get another intercept with Mun in a few months. However if I import the orbit into MA and coast several months ahead (well past when the game gave me an intercept), I get no state change to show that the asteroid hit Mun's SOI (the Coast to Next SOI event didn't find anything either). Anyone have an idea why this would be?

SOI intercept shown via progressed maneuver node in game, no SOI event found in MA - even when doing a UT coast prior to when the game shows and coasting to Pe

I'm thinking this is either a bug or a limitation. I have a second example, where my Duna probe is supposed to dip in and out of Ike's orbit after passing Duna if it doesn't burn to capture into orbit. However if I remove my capture burn in MA and coast to next SOI it takes me back out around the sun with no Ike intercept.

Duna to Ike encounter in game but MA says my next SOI is back around the sun

This brings up the question of the limitations of the Coast to Next SOI event in general. For example I have an asteroid that's bound to strike Kerbin in just over 9 years (oh noes!). If I put its orbit into MA and try to coast to the SOI, MA tells me it can't find one. But if I set a UT coast to a few days prior to the SOI and then a coast to PE, I get the second mission segment showing me the impact trajectory onto Kerbin.

First coast to SOI fails (doesn't propagate out far enough it seems), but a UT coast followed by an SOI coast works

Edited November 23, 2014 by Gaiiden

[dfscott]

Really loving this tool since I'm such a planner. However, I'm having trouble with the mission planner on flybys. I've gotten a nice Kerbin-Eve-Moho orbit from the porkchop planner:

Phase 1 Transfer Orbit (Kerbin -> Eve)
---------------------------------------------
Semi-major Axis =             10989335.252 km
Eccentricity =                  0.23841
Inclination =                   2.091 deg
Right Ascension of AN =         14.250 deg
Argument of Periapse =          356.181 deg
Period =                     6685155.9724 sec
Departure True Anomaly =        183.819 deg
Arrival True Anomaly =          76.027 deg
---------------------------------------------
Phase 2 Transfer Orbit (Eve -> Moho)
---------------------------------------------
Semi-major Axis =              8401846.027 km
Eccentricity =                  0.29292
Inclination =                   6.316 deg
Right Ascension of AN =         68.143 deg
Argument of Periapse =          240.818 deg
Period =                     4469063.1127 sec
Departure True Anomaly =        137.590 deg
Arrival True Anomaly =          317.589 deg
---------------------------------------------
Kerbin Departure Date = 
                 Year 4, Day 81 23:46:59.647
                      (101605619.647 sec UT)
Eve Arrival Date = 
                Year 4, Day 130 07:26:32.143
                      (105780392.143 sec UT)
Moho Arrival Date = 
                Year 4, Day 162 18:57:31.204
                      (108586651.204 sec UT)

Burn Information to Depart Kerbin
---------------------------------------------
Total Delta-V =                 1.465 km/s
Prograde Delta-V =              901.254 m/s
Orbit Normal Delta-V =          -1155.092 m/s
Radial Delta-V =                0.000 m/s
---------------------
Burn True Anomaly =             316.107 deg
---------------------------------------------
Burn Information to Depart Eve
---------------------------------------------
Total Delta-V =                 0.708 km/s
Prograde Delta-V =              708.469 m/s
Orbit Normal Delta-V =          0.000 m/s
Radial Delta-V =                0.000 m/s
---------------------
Burn True Anomaly =             0.000 deg
---------------------------------------------

Hyperbolic Departure Orbit from Kerbin
---------------------------------------------
Semi-major Axis =               -2324.654 km
Eccentricity =                  1.3441
Inclination =                   21.043 deg
Right Ascension of AN =         136.107 deg
Argument of Periapse =          180.000 deg
---------------------------------------------
Inbound Hyperbolic Flyby Orbit to Eve
---------------------------------------------
Semi-major Axis =               -1448.557 km
Eccentricity =                  1.5559
Inclination =                   167.383 deg
Right Ascension of AN =         102.158 deg
Argument of Periapse =          318.826 deg
Periapse Radius =               805.183 km
---------------------------------------------
Outbound Hyperbolic Flyby Orbit from Eve
---------------------------------------------
Semi-major Axis =               -611.668 km
Eccentricity =                  2.3164
Inclination =                   167.383 deg
Right Ascension of AN =         102.158 deg
Argument of Periapse =          318.826 deg
Periapse Radius =               805.183 km
---------------------------------------------
Inbound Hyperbolic Orbit to Moho
---------------------------------------------
Hyperbolic Excess Vel. =        1.935 km/s

I then plugged it into the mission planner and started optimizing. My first attempt I treated like a mission to eve, only entering events up to eve and then minimizing periapsis (like in the Kerbin to Lathye example). Once that worked, I locked down the initial params, added the moho burn and coast to moho and then tried to hit moho. However, I couldn't get the optimizer to find a solution to get me to moho.

I thought maybe my initial eve optimizations threw off my transfer to moho, so I reset everything, added all the events in there and tried to just hit moho. This didn't work either (never found a solution that came close).

So then I loaded up the sample Kerbin-Eve-Duna flyby and saw that it had some extra nodes of type "Go to Next SOI transition". Do I need to add those in order to get this to work? And once I do, what's the best order to optimize? The example has some RAAN and inclination params, but I wasn't sure how to know what those values should be - do those get pulled from the Hyperbolic Departure and Flyby Orbit info.

I'm just a little confused on what order I need to do things. Would love a step-by-step example for a flyby similar to the Kerbin-to-Lathye example...

[tw33dl3dee]

Would it be possible to compile it into .jar instead of .exe? AFAIK that way it will be launchable with any corresponding MCR: Win/OSX/Linux.

[Drew Kerman]

So what can you do in the mean time? If your solutions are too far in the future, try sliding your initial epoch back bit by bit. I would suggest increments of 1 hour. You should get a time you want eventually by doing that. I agree it's not really desirable, but it should work in the mean time. Let me know if you have trouble.

Unfortunately this technique has proved rather useless. The main issue is that the RMS always produces different results without me having to change any parameters. So it's basically a crap shoot, even when I move the Initial Search Epoch back by several days. Sometimes I will get a burn time near where I want, other times it will still be days in advance. If the RMS were to produce more consistent results I could walk my way towards the optimal solution but until there's a constraint in place to limit how far forward it searches this tool is very limited right now.

[Drew Kerman]

Unfortunately this technique has proved rather useless. The main issue is that the RMS always produces different results without me having to change any parameters. So it's basically a crap shoot, even when I move the Initial Search Epoch back by several days. Sometimes I will get a burn time near where I want, other times it will still be days in advance. If the RMS were to produce more consistent results I could walk my way towards the optimal solution but until there's a constraint in place to limit how far forward it searches this tool is very limited right now.

I partially retract this earlier statement. It could be I'm just using the RMS improperly to look for rendezvous with moons (AKA Kerbin to Mun). When I used the RMS to get intercepts with craft in orbit it gave me repeatable results close enough to the Initial Search Epoch I'm sure it couldn't have found any sooner. Dunno what's up with that but if I play around with it more and figure it out I'll let it be known here.

Otherwise, except for Aerobraking (which I hope Arrowstar answers my PM about at some point) things seem to be working fine and dandy. Spent the last two days working on my first kerbed orbital Mun mission:

I rendezvous with 4 separate satellites in orbit around Mun, 1 on the first day I arrive, 3 on the second and then the third day is spent on a direct return to Kerbin. Not that it made much of a difference on this short trip, I still made sure to update my craft mass at each burn with the life support resources I used since the last burn. That'd be a cool thing to have handled for me by the mission planner.

[Drew Kerman]

getting close to operations in the Duna system and this is still bothering me:

The UT of the Duna Pe matches up within an acceptable margin of error between MA and the game so why does MA think Ike is all the way over there? I tried outputting a new bodies.ini file to see if the initial Ike orbital data is off but the whole bodies.ini creation process seems screwed with 1.1.8

[Drew Kerman]

Is it normal for things to be off by this much?

MA is telling me my altitude is going to be 919km at Pe after I set the Initial State to the orbital data pulled straight from the game, then insert a coast to Minmus Pe event. I re-downloaded the KSPTOT.exe and bodies.ini file for 1.1.8 since I had been experimenting with 1.1.9 for a bit and may have messed up settings or whatever. I think this discrepancy is a too much of an error. The game telling me 1,503km and MA telling me something like 1,495km would be more reasonable if there were to be any sort of error margin.

The only thing I can think of is it's related to my previous post about Ike and MA thinks Minmus' location is different than what it is in the game.

[Jalon]

Hey,

I discovered your tool whilst working on my own version of a similar tool I started writing in Python for a class project. I've got to say, very nice job!

[Drew Kerman]

moar chart p0rn! Arrowstar this graph overlay plotting is the best accidental feature ever! The key was added by me, although it is possible to show a line key with the Matlab toolbar, if it would be possible to set the line name with the reference body/station/craft you choose to plot against.

So, who can say what I've figured out here? I've been complaining about some possible inaccuracies lately so wanted to show this and say that the timing of the event was extremely accurate in the game!

It has to to with RemoteTech

[Drew Kerman]

I'm going to continue talking to myself here So I figure out a way to test whether there was actually a problem with some of the bodies.ini data. VOID gives you a celestial catalog window that presents all kinds of orbital data for bodies, including true anomaly, mean anomaly, RAAN, LPE, etc etc. So, I went into the RMS and copied to the clipboard the orbital data for Minmus. Then I made a copy of bodies.ini and deleted Minmus from it. Then I loaded the new bodies data and opened MA, plugging in Minmus' orbit for the initial state. I then progressed the mission up to the current game time, to the second, and took a screenshot of the game data and the MA data. Here are the results:

As you can see, there are several obvious discrepancies here, notably the Mean/True anomalies but also the LPE. To make sure this really wasn't an issue with the VOID data readout I went and checked up on Duna, which was a mission I planned and had been flying via MA without any noticeable differences between it and the game. Here are the results:

As you can see in this case, there are no discrepancies and everything matches up perfectly. Then I checked Kerbin. It wasn't quite as precise as Duna (game said 314.247 for mean/true anomaly when MA said 314.2448) but that's just me being ....

Sooo then I went and checked Mun. Wrong (Nooooooo my fabulous mission plan!!!!!). And I checked Ike. Wrong. Anyways, leveraging the power of arithmetics I calculated the offset value and added it to the mean anomaly setting for the body in the bodies.ini file. First I did Ike, and I came up with this (reference it against the previous game image that also has Ike orbital data):

At first glance everything seems good. Mean anomaly now matches up, true anomaly isn't perfect but close enough I guess. So I go and load my Duna mission, the one I posted earlier that is supposed to encounter Ike after initial Duna Pe if I don't circularize there, and there was still no Ike encounter. But it came close, a lot closer than before:

before: after:

What gives? I took another look at the orbital data in MA and checked out the orbital period by pasting it in a time box in KSPTOT. It told me 65517 seconds is 18h:11m:57s. Now, that's very interesting considering the VOID game data is telling me Ike's orbital period is 17h:39m:48.2s. Not sure what to do about that.

So next I gave Minmus the orbital data update treatment, changing its mean anomaly and LPE. When I checked for alignment I didn't get a match, but then I changed the LPE back to 0 instead of setting it to 38 like the game said and then I got a match for mean/true anomaly:

However when I reloaded MA with the new bodies.ini data and plugged in the current orbit of my Minmus probe straight from the game, MA still didn't have things right. It told me my probe was going to have a Pe of 918km at Minmus yet when I warped ahead and hit Minmus' SOI the game showed me I had the 1,500km Pe I had originally set up a maneuver node in the game for. Once again, I took a look at the orbital period that MA was giving me: 1077311 seconds plugged into a UT window in KSPTOT spits out 13d:11h:15m:11s when the game is telling me the orbital period of Minmus is 12d:11h:57m:52.1s. So then I took it to the wiki which tells me Minmus' orbital period is what MA says it should be. So maybe VOID is wrong in this regard but that doesn't explain why MA is telling me my Pe (altitude) is 918km when in the game it ends up 1,500km (really it's 1,498 something like that).

So rats, I thought I had things solved but although I got a step closer it seems something is still amiss... I'll have to sleep on it it's 4:30am now....

Edited December 16, 2014 by Gaiiden

[diomedea]

I'm going to continue talking to myself here

...

What gives? I took another look at the orbital data in MA and checked out the orbital period by pasting it in a time box in KSPTOT. It told me 65517 seconds is 18h:11m:57s. Now, that's very interesting considering the VOID game data is telling me Ike's orbital period is 17h:39m:48.2s. Not sure what to do about that.

So next I gave Minmus the orbital data update treatment, changing its mean anomaly and LPE.

...

Once again, I took a look at the orbital period that MA was giving me: 1077311 seconds plugged into a UT window in KSPTOT spits out 13d:11h:15m:11s when the game is telling me the orbital period of Minmus is 12d:11h:57m:52.1s. So then I took it to the wiki which tells me Minmus' orbital period is what MA says it should be.

...

Actually, your results are quite interesting, and if I didn't show my interest lately was only because I had other priorities (hint: 0.90 testing).

About the orbital periods: I use a spreadsheet to compute a number of orbital data from the known parameters, including those of the kerbol bodies. Calculations are based on well-known celestial mechanic equations, and always showed extreme accuracy (I generally use the computed data to position crafts so they stay in very specific orbits for very long time).

About Ike, the revolution period in my sheet is 65,517.86 s (18h 11m 57.86s). For Minmus, it is 1,077,310.52 s (12d 11h 15m 10.52s). These data match with the KSP Wiki. And from your findings, with MA.

[Drew Kerman]

About the orbital periods: I use a spreadsheet to compute a number of orbital data from the known parameters, including those of the kerbol bodies. Calculations are based on well-known celestial mechanic equations, and always showed extreme accuracy (I generally use the computed data to position crafts so they stay in very specific orbits for very long time).

About Ike, the revolution period in my sheet is 65,517.86 s (18h 11m 57.86s). For Minmus, it is 1,077,310.52 s (12d 11h 15m 10.52s). These data match with the KSP Wiki. And from your findings, with MA.

Oh whoops, I realize now the mistake I made in reading the time from KSPTOT UT box. Since the game starts on Day 1, 1,077,310 would take me to day 13 but that is in fact actually 12 days

So then what's still off with Minmus?? If I put an LPE of 38 for the initial orbital epoch data, I don't get a proper.... oh son of a.... I just realized typing this that the mean anomaly offset I calculated was based off a mean anomaly value I got without setting the LPE to 38. I need to set the LPE, get the offset, then apply the new EPH mean anomaly.

*several minutes later*

Ok, here is what I have now:

Despite the fact that MA shows the LPE as 0, these are the starting epoch values used:

[Minmus]
epoch = 0
sma = 47000.000
ecc = 0
inc = 6
raan = 78
arg = 38
mean = 338.1597016

Now, when I use this new data in MA as applied to my Minmus mission, it no longer shows that I have an SOI intercept with Minmus. However to be fair, neither does the game! In the game, I do end up getting a ~1,500km Pe but the SOI change doesn't show up until like 2mins prior to hitting it. However when I try to move my MA mission plan up to that point and search for an SOI transition, I still don't get one. MA says that my closest approach to Minmus is a little over 5,500km.

So yea. Still stumped.

[Drew Kerman]

Did some more experimenting. My Minmus encounter I said previously wasn't showing up either in the game or in MA. So that was "accurate". I decided to plan a maneuver in MA and import it into KSP to see how it would look, so I optimized my MA plot to intercept Minmus with a Pe of 900km. I uploaded the resulting burn to KSP and ended up with a Pe of 713,206km

So I tried updating Mun's mean anomaly and seeing how that affects mission planning. Here is Mun simulated in MA with the new mean anomaly value:

And here's what I got when I imported a craft bound for Mun using the new mean anomaly value:

Again, close. I'm not sure what the margin of error is with KSPTOT, or if there is any. Should this be considered an acceptable value? I think so - it's certainly more usable than the almost 300km difference shown in the Minmus example.

To double-check the offset I took the current trajectory and added a Dv maneuver, then optimized a solution for 1,000km Pe and uploaded the burn into KSP. It showed me a 1,030.86km Pe.

I'd also like to note yet again there is a discrepancy in the orbital period for Mun reported by MA (which matches the wiki) and what the VOID data window is showing. I've asked toadicus in the VOID thread whether the orbital periods shown for bodies is calculated from a game value or improperly inputted by him into a database the window is reading from.

Edited December 17, 2014 by Gaiiden

[Drew Kerman]

I just tried a bit of messing around with the significant digits of Mun's mean anomaly to no real success. At the setting of 115.622725172, which simulates a match up with VOID, when I set a burn in MA for my craft to go to 500km Mun Pe the game gave me 542.388km after the burn was uploaded. When I went +0.002 the game gave me 542.451km, and when I went -0.002 the game gave me 541.832km. Then I went -0.01 and I got 543.558km. Wat

[diomedea]

Interesting, really. It will take me some time to get the significance of all the numbers you show, you did a lot of work on this and is a bit hard to just enter now and follow the method. But definitely seems you are up to something.

Months ago I had a thought about the precision of KSP TOT compared with KSP. My maneuvers in MA did not match that closely when imported in KSP, and I wanted to check with Arrowstar what could be the reason, but there were more important issue to solve first. If I get it right, you are actually researching just about this problem.

Back then, I was under the impression that any dissonance may have to be tracked to KSP, in case (as I expect) KSP TOT makes calculations with the correctness and precision an astrodynamicist would use. When we see the orbits tremble and SoI transitions move or disappear in the conics shown by KSP, there is no doubt the internal calculations lack some precision (I'd suspect the floating point numbers used for the conics aren't precise enough at the scale used).

I have to ask if, actually, the difference you find remains the same importing a maneuver in KSP a number of times. If KSP suffers from a lack of precision in its FP numbers, it may show that the results of the imported maneuver also change while in KSP: in that case, it would be required to "average" the results to minimize the noise from the trembling conics.

What constant error remains after averaging will instead hint at either parameters being uncorrectly defined or used in calculations, or even a different computational method being used with intrinsic lower precision.

I would guess what is a method "good enough" for KSP (also to allow for real-time computations in game, as such not overly complex) may not be the choice used for KSP TOT.

[Drew Kerman]

Interesting, really. It will take me some time to get the significance of all the numbers you show, you did a lot of work on this and is a bit hard to just enter now and follow the method. But definitely seems you are up to something.

I'm just using MA to simulate the position of the planets/moons to confirm the data in the bodies.ini file.

Back then, I was under the impression that any dissonance may have to be tracked to KSP, in case (as I expect) KSP TOT makes calculations with the correctness and precision an astrodynamicist would use. When we see the orbits tremble and SoI transitions move or disappear in the conics shown by KSP, there is no doubt the internal calculations lack some precision (I'd suspect the floating point numbers used for the conics aren't precise enough at the scale used).

FP precision is what I'm suspecting is the real culprit as well. I have no doubt it's true that KSPTOT is ultra-precise and KSP dumps data (I should also mess with my physics tick setting). I'm still trying to work out though the exact level of variance between KSP and MA. I only spent a little time experimenting with significant digits in the mean anomaly value and re-importing the same maneuver node to see the effects (previous post before yours). Will have to devise a more controlled scenario to test with, as for the post above although I was creating the maneuver node at the same UT with the same goal of 500km Pe I was re-importing the orbital data from the game each time, so that wasn't a constant as I could see the actual plotted Pe in the game varying by several hundred meters every few minutes.

Toadicus is looking into the orbital period discrepancy in VOID. I'm interested to see what that's all about.

[Drew Kerman]

okay. this is veeery interesting...

NONE of these values match what KSPTOT or the wiki (which do match each other) state for orbital periods.

Toadicus got back to me on the VOID readouts but I think he read too fast and thought I was talking about the rotational period.

I've also cross posted now to the kOS thread to see about these orbital period values.

Edit: just saw confirmation from the kOS devs that these values are pulled straight from the game's API and outputted to the console without anything happening in-between. I've heard from Arrowstar, who is really busy at the moment, and will be drawing up conclusions on this issue and others I've come across recently into a concise PM for him to reference in his limited spare time. If anyone else has concerns they'd like me to include, voice them - I'll compose the PM once I wake up in about 8 hours

Edited December 18, 2014 by Gaiiden

[Snoman314]

I've got nothing really to add still, but I've been following your posts Gaiiden, and thanks for the testing work / research. I love this tool, and everything that can be done to make it better I appreciate.

[Drew Kerman]

PM is on hold for the moment while I run down one last major issue. It seems something may have affected the orbital periods of bodies in my game. Toadicus over in the VOID thread just showed me a screenshot of kOS from his install outputting orbital period values that match both kOS and the wiki. Dunno what the hell could be causing this but later today I need to strip down to stock and start investigating.

The good news is the changes I made to the bodies.ini file should still be valid improvements, edit: No, they are not so if anyone wants to check them out, use this link. Currently only Ike, Mun and Minmus have been modified.

Edited December 19, 2014 by Gaiiden

[Drew Kerman]

Well I'm happy to announce the herring chase is finally over. There was never an issue with KSPTOT, although it did help me realize there was an issue which eventually led me to fingering Real Solar System as the culprit that modified the orbital period of the moons, thus changing their proper mean anomalies in the process. I reported the issue over there.

(small error is from KSP, orbit Pe changes over time thx to precision issues)

So carry on everyone! Unless you're also using RSS in the Kerbol system to modify planetary atmospheres to get rid of the white horizon, in which case you better remove that until it's fixed if you want accurate SOI transition information along your flight plans.