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

[Drew Kerman]

2 minutes ago, Arrowstar said:

Can you check to make sure the mission file you gave me for the first problem is correct?

dbl-checked and it's def there @ 22010220.76124 UT - I closed down KSPTOT, downloaded the file I uploaded, restarted KSPTOT, loaded the file in MA, selected Graphical Analysis with Altitude and when you zoom in to the Periapsis you'll see the jump

[Arrowstar]

2 minutes ago, Drew Kerman said:

dbl-checked and it's def there @ 22010220.76124 UT - I closed down KSPTOT, downloaded the file I uploaded, restarted KSPTOT, loaded the file in MA, selected Graphical Analysis with Altitude and when you zoom in to the Periapsis you'll see the jump

See the edit to my post for what's going on.

[Drew Kerman]

3 minutes ago, Arrowstar said:

See the edit to my post for what's going on.

ah, gotcha. I figured it was something like that just didn't know you could adjust the resolution. Cool! That did fix it. I didn't see your edit thx to my reply jumping to a new page

[Arrowstar]

Yet another "I'll just leave this here" post.

[Arrowstar]

I have another neat feature that I was able to squeak into KSPTOT Mission Architect today and I would like to discuss tonight.  This new feature is called "Coast to Function Value" and it allows you to do some crazy things.  In essence, it allows you to determine when a particular function (we'll get to this) has a particular value and then coast to that time.  The functions that are available is basically anything that is available in Graphical Analysis.  In fact, a part of the work I did today was to set up for merging all the data providers in Mission Architect so that I can reference them outside of just Graphical Analysis.  More on that in a future post.

In the example below, I wanted to coast my spacecraft to the relative node between my spacecraft and this other spacecraft.  You can do this by coasting to where the relative crosstrack position between the two spacecraft is 0.0 km.  To do this, we create a new Coast event.  Notice on the left box, in the Coast to Function Value Parameter area, how the function is set to Relative Pos. of Ref. Spacecraft (Crosstrack), and the Function value is set to 0.0 km.  The Ref. Spacecraft is Test Spacecraft, which is shown by the black dotted line.  Notice how my spacecraft's red line goes right up to the black dotted line, and then stops.

So the way this works is that I essentially use a root finder to look for the point where the function value matches the desired value.  There's a maximum propagation time that the solver searches up to.  The code uses a series of Coast to Delta Time events internally to do the search.  If the solver can't find the find the desired value, it will propagate to the maximum propagation time and throw a warning.

In the past, if you wanted to do this, you would have had to use the optimizer and hope it could find something.  Now, no more!

The only Graphical Analysis task/function that can't be coasted to is the Distance Traveled function, because there is some funniness with the way that's computed.  But everything else works.

The next revision I want to do is to update the constraints in the optimizer to use the same data providers that Graphical Analysis uses, too.  We'll see how much work that takes, but should be possible.

So what do you guys think of all this?  Pretty neat, huh?  I'm happy with how it turned out so far.  

[Stract]

Hi Arrowstar!

About year ago I told you about problems with TOT in RSS (here is the link to that post). I didn't play KSP much since then but recently I've decided to look at this problem more carefully. And I think I've found a possible cause of it. As far as I understand, TOT calculates positions of planets by solving Kepler equation with parameters from bodies.ini. But the thing is planets in RSS (and probably any Kopernicus-created system) are moving not like in stock KSP. Orbital periods for planets in stock KSP are calculated as T=2pi*sqrt(SMA^3/GM) where M is the mass of central body. In RSS T=2pi*sqrt(SMA^3/G(M+m)), m is the mass of orbiting body. This makes orbital periods more realistic, especially for the systems where masses of two bodies are comparable, like Pluto-Charon system. That's why planets in game are moving slightly faster than TOT expect. I've checked it in game by putting a probes into orbits of different planets and confirmed that probes are moving slower than planets with similar orbital parameters.

So that's my assumption. If this is the case then TOT requires a slight modification for non-stock Solar systems. It must calculate position of planets in time by using not parent body GM, but sum of Gms of parent and planet itself.

[diomedea]

1 hour ago, Stract said:

Hi Arrowstar!

About year ago I told you about problems with TOT in RSS (here is the link to that post). I didn't play KSP much since then but recently I've decided to look at this problem more carefully. And I think I've found a possible cause of it. As far as I understand, TOT calculates positions of planets by solving Kepler equation with parameters from bodies.ini. But the thing is planets in RSS (and probably any Kopernicus-created system) are moving not like in stock KSP. Orbital periods for planets in stock KSP are calculated as T=2pi*sqrt(SMA^3/GM) where M is the mass of central body. In RSS T=2pi*sqrt(SMA^3/G(M+m)), m is the mass of orbiting body. This makes orbital periods more realistic, especially for the systems where masses of two bodies are comparable, like Pluto-Charon system. That's why planets in game are moving slightly faster than TOT expect. I've checked it in game by putting a probes into orbits of different planets and confirmed that probes are moving slower than planets with similar orbital parameters.

So that's my assumption. If this is the case then TOT requires a slight modification for non-stock Solar systems. It must calculate position of planets in time by using not parent body GM, but sum of Gms of parent and planet itself.

Very interesting. Just one question, as you know how RSS does orbital period, have you also checked how SMA is computed? Because while in stock KSP both Ap and Pe are measured from the mainbody center, with n-body gravitation those are to be taken from the center of mass of the system (which in a two-body system is always closer to a minor then the major body center). Of course SMA = (Ap+Pe)/2 therefore the orbit of the minor is smaller around the common center of mass then around the major body. If both major and minor positions were computed from the common center of mass all would fit; but if the major remains "on rails" around Sun instead of around the center of mass of the system (which is orbiting Sun) both minor and major positions would be wrong.

[Arrowstar]

4 hours ago, Stract said:

Hi Arrowstar!

About year ago I told you about problems with TOT in RSS (here is the link to that post). I didn't play KSP much since then but recently I've decided to look at this problem more carefully. And I think I've found a possible cause of it. As far as I understand, TOT calculates positions of planets by solving Kepler equation with parameters from bodies.ini. But the thing is planets in RSS (and probably any Kopernicus-created system) are moving not like in stock KSP. Orbital periods for planets in stock KSP are calculated as T=2pi*sqrt(SMA^3/GM) where M is the mass of central body. In RSS T=2pi*sqrt(SMA^3/G(M+m)), m is the mass of orbiting body. This makes orbital periods more realistic, especially for the systems where masses of two bodies are comparable, like Pluto-Charon system. That's why planets in game are moving slightly faster than TOT expect. I've checked it in game by putting a probes into orbits of different planets and confirmed that probes are moving slower than planets with similar orbital parameters.

So that's my assumption. If this is the case then TOT requires a slight modification for non-stock Solar systems. It must calculate position of planets in time by using not parent body GM, but sum of Gms of parent and planet itself.

Interesting.  I was unaware of this. 

Unfortunately, if RSS is propagating orbits in a manner different from the way that stock KSP does, then there may not be much I can do about it (simply).  Right now the whole two body orbit propagator is effectively designed to work the same way that KSP does.  Changing that, or introducing an alternative mode of operation, would be a ton of work.  I also have to make sure that I always support stock KSP out of the box.  So while I won't claim its impossible, but I suspect that I simply won't be able to address this issue. 

Would it be possible to compute a new effective SMA and/or GM for each body that provided the same motion?  I haven't sat down to look at it and do the math, but that's probably the only reasonable course of action in the immediate future.

[Stract]

3 hours ago, Arrowstar said:

Would it be possible to compute a new effective SMA and/or GM for each body that provided the same motion?

I doubt it. It appears orbital speeds in RSS depend on the mass of the orbiting planets, which can not be easily avoided. Probably the most simple way is to disable this feature in RSS itself, which I suppose should be doable.

[Drew Kerman]

4 hours ago, Arrowstar said:

I was unaware of this. 

Not completely, but it's been a while since this issue last came up. You may recall like in 2015 sometime I think I had that problem getting a Mun intercept and discovered the reason I wasn't getting the in game intercept KSPTOT said I should have was due to Mun's orbital period being different as I was using RSS for better atmosphere realism (I think - honestly can't remember why I had RSS, it def wasn't for system scaling)

[Arrowstar]

18 hours ago, Drew Kerman said:

Not completely, but it's been a while since this issue last came up. You may recall like in 2015 sometime I think I had that problem getting a Mun intercept and discovered the reason I wasn't getting the in game intercept KSPTOT said I should have was due to Mun's orbital period being different as I was using RSS for better atmosphere realism (I think - honestly can't remember why I had RSS, it def wasn't for system scaling)

Fair enough!  I'd have to go back and look but I believe you. :-) In any event, the issue really isn't solvable on my end without rewriting the whole propagation engine. Since that would a huge undertaking and could introduce compatibility issues with stock KSP, I don't think I can do anything to fix it. Sorry! :-\ 

[Arrowstar]

Hi everyone,

Tonight I'm pushing out KSP Trajectory Optimization Tool v1.5.7 pre-release 6.  This pre-release has a number of changes over the previous pre-release, all of which are in Mission Architect.

• Implemented the Landing event in Mission Architect.  This event holds you fixed within the rotating frame (lat/long/altitude) of the spacecraft's current central body.
• Implemented a new Coast type, "Coast to Function Value."  This allows you to coast to values that are otherwise computable from Graphical Analysis, such as relative crosstrack postition, longitude, altitude, etc.
• I've revamped the way the graphical analysis data providers (aka "Tasks") are implemented within Mission Architect.  Now, these data providers are used not only within Graphical Analysis but also for optimizer constraints and for the "Coast to Function Value" feature as well.  In the future, they could conceivably be used for other things as well.
• A number of smaller bug fixes here and there.

As a note, older mission cases from previous versions, including the last pre-release, may have some optimizer constraints removed upon load in this version.  This is because the name of some constraints changed and I needed to have the optimizer reload them (via user commands) or the application will crash.

Because of the somewhat larger changes in this pre-release, if anyone using it finds a bug, please let me know!  I've tried to test everything to the extent that I can, but I assuredly cannot find every use case myself in a finite amount of time.

Thanks, and happy orbiting!

[Drew Kerman]

2 hours ago, Arrowstar said:

Tonight I'm pushing out KSP Trajectory Optimization Tool v1.5.7 pre-release 6. 

Uhhhhh, I just downloaded a 278MB executable file and I'm honestly afraid to run it. Last release was 68MB I'm not complaining but I just wanna make sure this is for real

[Arrowstar]

29 minutes ago, Drew Kerman said:

Uhhhhh, I just downloaded a 278MB executable file and I'm honestly afraid to run it. Last release was 68MB I'm not complaining but I just wanna make sure this is for real

It's real, though probably means I messed something up on my end. I had to rebuild the Matlab compiler project for this build and I bet I added in a bunch of files I don't need to include. I'll look at it tomorrow. In the mean time it should all work. :-) 

[Drew Kerman]

Got another asteroid with a wacky orbit that MA can't load. I've applied its orbit to a stock probe and here is the stock game file

It loads the orbit the same both through the game and through the SFS file but in both instances says the SMA is invalid. Tested in both the pre-release posted just above and the one posted before that.

[Arrowstar]

18 hours ago, Drew Kerman said:

Uhhhhh, I just downloaded a 278MB executable file and I'm honestly afraid to run it. Last release was 68MB I'm not complaining but I just wanna make sure this is for real

So I accidentally included the MCR installer in the EXE file I think, which is why the file size went up by a factor of ~4.  I've reuploaded pre-release 6 and it's about ~69 MB, which is much more reasonable.  Thanks for noticing!

20 minutes ago, Drew Kerman said:

Got another asteroid with a wacky orbit that MA can't load. I've applied its orbit to a stock probe and here is the stock game file

It loads the orbit the same both through the game and through the SFS file but in both instances says the SMA is invalid. Tested in both the pre-release posted just above and the one posted before that.

I'll take a look!   EDIT: Is this on the pre-release?

Edited May 17, 2017 by Arrowstar

[Arrowstar]

46 minutes ago, Drew Kerman said:

Got another asteroid with a wacky orbit that MA can't load. I've applied its orbit to a stock probe and here is the stock game file

It loads the orbit the same both through the game and through the SFS file but in both instances says the SMA is invalid. Tested in both the pre-release posted just above and the one posted before that.

Okay, I think I've resolved the issue and I just replaced the pre-release 6 EXE again (as I had just replaced it).  Go ahead and try that out.  I was just a bit overzealous with the bounds checking on some numbers.

[Drew Kerman]

3 hours ago, Arrowstar said:

Okay, I think I've resolved the issue and I just replaced the pre-release 6 EXE again (as I had just replaced it).  Go ahead and try that out.  I was just a bit overzealous with the bounds checking on some numbers.

did a quick check loaded from the SFS file works great, thanks for the quick fix will do some actual playing later & report anything else I find

[gruneisen]

I wanted to return briefly to the conversation with @Stract and @Arrowstar about RSS from a few days ago - as another user who remains frustrated by KSP TOT not working with RSS, I hoped that what was found was at least a path forward to try to get the two mods to work together. Unfortunately, I had a nagging feeling that something didn't quite make sense and that something was MechJeb. MechJeb has no issues working for both stock and RSS with the exact same code - nothing is required to change between RSS and stock. With that in mind, I went in briefly checked the MechJeb code and, lo and behold, orbital velocities are calculated from v=sqrt(GM/r) and GM comes from the parent body of the orbit - not the barycenter.

So, (un?)unfortunately, this is not the issue with KSP TOT and RSS. Hopefully a continued review / comparison of MechJeb and KSP TOT can highlight where the problem lies. Nothing constructive here, just hopefully some useful information.

Cheers!

[Starwaster]

2 minutes ago, gruneisen said:

I wanted to return briefly to the conversation with @Stract and @Arrowstar about RSS from a few days ago - as another user who remains frustrated by KSP TOT not working with RSS, I hoped that what was found was at least a path forward to try to get the two mods to work together. Unfortunately, I had a nagging feeling that something didn't quite make sense and that something was MechJeb. MechJeb has no issues working for both stock and RSS with the exact same code - nothing is required to change between RSS and stock. With that in mind, I went in briefly checked the MechJeb code and, lo and behold, orbital velocities are calculated from v=sqrt(GM/r) and GM comes from the parent body of the orbit - not the barycenter.

So, (un?)unfortunately, this is not the issue with KSP TOT and RSS. Hopefully a continued review / comparison of MechJeb and KSP TOT can highlight where the problem lies. Nothing constructive here, just hopefully some useful information.

Cheers!

I think the real reason is that MechJeb doesn't have to be as precise: The planet/moon SOI will catch the ship so MJ only has to get the ship in the general vicinity. But this mod probably requires more precision than that, especially if it's having to look several years into the future.

[gruneisen]

9 minutes ago, Starwaster said:

I think the real reason is that MechJeb doesn't have to be as precise: The planet/moon SOI will catch the ship so MJ only has to get the ship in the general vicinity. But this mod probably requires more precision than that, especially if it's having to look several years into the future.

I agree that TOT is far more precise, but I use MechJeb do to interplanetary transfers that are years out using its porkchop plotter and nail the transfers with no problem whereas for a simple Earth - Moon transfer, in KSP TOT I can load a current vessel into Mission Architect, find a transfer from the earth to the moon, upload the maneuver and it have it be off by as much as 180°. Do a Hohman transfer in MechJeb and bam, spot on. A lot of people have said it before and I'm going to say it again - all signs point to the KSP TOT thinking the bodies in RSS are in a different place then where they are - it is completely inaccurate with RSS over any timescale.

Edited May 18, 2017 by gruneisen

[Stract]

4 hours ago, gruneisen said:

I wanted to return briefly to the conversation with @Stract and @Arrowstar about RSS from a few days ago - as another user who remains frustrated by KSP TOT not working with RSS, I hoped that what was found was at least a path forward to try to get the two mods to work together. Unfortunately, I had a nagging feeling that something didn't quite make sense and that something was MechJeb. MechJeb has no issues working for both stock and RSS with the exact same code - nothing is required to change between RSS and stock. With that in mind, I went in briefly checked the MechJeb code and, lo and behold, orbital velocities are calculated from v=sqrt(GM/r) and GM comes from the parent body of the orbit - not the barycenter.

So, (un?)unfortunately, this is not the issue with KSP TOT and RSS. Hopefully a continued review / comparison of MechJeb and KSP TOT can highlight where the problem lies. Nothing constructive here, just hopefully some useful information.

Cheers!

I don't know how MechJeb deals with RSS, but at least the following seems to be true because it is easy to check: RSS calculates orbital periods using sum of masses unlike TOT. Actually I've played with TOT code a bit. I've changed the way of calculating the SOI upward transition in mission architect by replacing "[rVectBody, vVectBody] = getStateAtTime(bodyInfo, ut, parentBodyInfo.gm);" line with "[rVectBody, vVectBody] = getStateAtTime(bodyInfo, ut, parentBodyInfo.gm+bodyInfo.gm);" in "convertRVVectOnUpwardsSoITransition" function. After this correction mission architect became to predict orbits after upward SOI transition much more accurately. Here are exapmles for stock and modified TOT (TOT predictions for the probe on Earth escape trajectory and actulal orbital parameters after entering Sun SOI:

Spoiler

Stock TOT, edited TOT and actual parameters

 

Edited May 18, 2017 by Stract

[Phineas Freak]

@Arrowstar Judging from the tests that @Stract did, wouldn't a toggle in the KSPTOT Options window be enough for KSPTOT to be compatible with both velocity calculations?

Might be completely wrong here. If so then excuse me...

Edited May 18, 2017 by Phineas Freak

[Arrowstar]

4 hours ago, Phineas Freak said:

@Arrowstar Judging from the tests that @Stract did, wouldn't a toggle in the KSPTOT Options window be enough for KSPTOT to be compatible with both velocity calculations?

Might be completely wrong here. If so then excuse me...

Thanks for doing the research, @Stract!  That's very interesting. 

As far as a toggle goes... Yes, that's what it would be on the UI side. I still have to implement it though!  Let me see what I can come up with after the 1.5.7 release drops next week hopefully. 

@Stract, is the only modification you needed to do to add the GM of the smaller body, as you showed in your code example?  And that provided good results where used?

 

 

[Stract]

17 minutes ago, Arrowstar said:

Thanks for doing the research, @Stract!  That's very interesting. 

As far as a toggle goes... Yes, that's what it would be on the UI side. I still have to implement it though!  Let me see what I can come up with after the 1.5.7 release drops next week hopefully. 

@Stract, is the only modification you needed to do to add the GM of the smaller body, as you showed in your code example?  And that provided good results where used?

 

 

Hi Arrowstar!

 

Yup, all I did is add this smaller body GM. As far as I can see, the only problem in TOT with RSS is that TOT calculates the relative position of planets and moons incorrectly, so every SOI transition creates an error. In my example stock TOT determined the wrong location of Earth on Sun orbit (wrong true\mean anomaly to be precise, caused by wrong orbital speed of the Earth) at the moment of SOI transition, which ended up in wrong Sun orbital parameters of a probe. By adding Earth GM into the function I corrected orbital speed of the Earth and hence the true anomaly of the Earth at that moment. So yes, my assumption is that adding GM of smaller body at every time TOT tries to locate the current position of planet or moon (i.e. at every SOI transition, every fly-by trajectory calculation and so...) should do the trick. At least it worked in my example.