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

[Gordon Dry]

@Three_Pounds I guessed the mission architect is needed for more than just an escape-and-intersect maneuver, so when creating multiple manuevers in a row.

This should be a planetary transfer thing that I also could MechJeb let create for me quickly.

Spoiler

MechJeb even is better than TWP because TWP always creates maneuvers which are not on the calculated ejection angle - the fun fact is that TWP itself (and KAC which is from the same dev) can show that ejection angle.
And TWP only shows prograde and normal, but not radial. Also the KAC alarm doesn't show radial.

 

[Arrowstar]

35 minutes ago, Gordon Dry said:

I'm not sure if this is intended to be used with additional planets.

Yes, I created a new bodies.ini just a couple of minutes ago out of the actual session in flight mode.

I want to go to Urlum - I also want to go there as quick as possible, so I entered 8 km/s to be taken into account for the calculation incl. capture burn.

I have set "Get orbit from KSP (Active vessel)" of course.
Same for UT.

I uploaded the manuever to the connected vessel.

 

I get this:

Ingame:

5years <> 14 years, totally something else ...

Where do I start to use this software the correct way?

2nd approach, when I don't "optimize" anything to get there quicker, I get these:

Can I please see the window that pops up when you hit the Compute Departure button?  It's labeled "Enter Transfer & Initial Orbit Information".  I need to see how it looks right before you hit the Compute Departure Burn button.

Btw, most likely what is happening is that you are burning in the wrong place in your Kerbin-centric orbit.  This would happen if you didn't tell KSPTOT your mean anomaly and orbit epoch information.  If you don't do this, it just assumes you'll be where you need to be at the time you need to be there.

20 minutes ago, Three_Pounds said:

I think you're supposed to take the information given in the departure information and take them to the mission architect to do some proper optimization on them before you can upload them to your game.

While this is certainly the best way to do it, it's not necessary so long as you don't mind being a bit off in your burn or the target SoI is so large that you'll hit it anyway.  For this problem, just using the porkchop-based Compute Departure function is fine.

[Gordon Dry]

7 minutes ago, Arrowstar said:

This would happen if you didn't tell KSPTOT your mean anomaly and orbit epoch information.

Actually I'm in the middle of a burn.

But I can tell that I tried it a couple of times starting from scratch, also with and without using the mean anomaly and epoch time checked.

But ofc I can do it again with the next vessel, that goes to another planet. Same brand, same workers.

[Arrowstar]

4 minutes ago, Gordon Dry said:

Actually I'm in the middle of a burn.

But I can tell that I tried it a couple of times starting from scratch, also with and without using the mean anomaly and epoch time checked.

But ofc I can do it again with the next vessel, that goes to another planet. Same brand, same workers.

Okay, let me know.  The burn information that comes out of that tool is correct.  I verified it in Mission Architect independently and the results were very close.  There's just a misunderstanding going on somewhere, hopefully I can help clear that up next time.  Happy orbiting.

[Arrowstar]

I'm happy to announce this afternoon the release of KSP Trajectory Optimization Tool v1.5.10!  This release is packed with new features and bug fixes that have shown up in the various pre-releases up to this point.  Here's the change log:

Quote

* Corrected an issue with the SFS import function
* Added the ability to set the line style of coasts and finite DV maneuvers.
* Added the line style updates to five Mission Architect events.
* Updated the drag coefficient calculator to use orbital energy instead of SMA to solve on.
* In Mission Architect, after running the optimizer, any constraints that are active or violated after optimization will show a warning message with information about the constraint values and bounds.  
* Resolved issue with the MA Delta-V dialog box not updating until another event is processed.
* Resolved an issue with the main MA UI not refreshing after optimization.
* Added a warning to MA if the user tries to close the application while the software is processing data (either because the UI is running the mission script or the orbit display is updating).
* Corrected a bug in the SoI transition code.
* Importing orbits from KSPTOT Connect into RMS and OTBOC tools now automatically sets the central body correctly.
* Fixed a bug with the context menu in OTBOC tool.
* Added SoI search tolerance menu option to Mission Architect;
* Added ability to perturb Mission Architect optimization variables by a percentage amount via menu;
* Fixed bug with Mission Architect optimization constraint analysis warning text;
* Added warning dialog to MFMS is the user attempts to close the UI while MFMS is running.
* M ission Architect: Two new graphical analysis tasks and constraints, the hyperbolic excess velocity vector right ascension and declination angles.
* Mission Architect: The Optimizer observation window is now more useful.  The top plot showing variable values has been changed such that it plots from lower bound to upper bound of every value.  This means that extra large variable values (like times) will not completely wash out the plot anymore.
* MFMS: The number of decimal places in the output window has increased to 4 for each united value.
* Mission Architect: Tweaks to the options fed into the fmincon optimizer algorithm.
* Mission Architect: Included a new example case file: Kerbin-Eve-Jool-Eeloo mission.
* An error message when the MFMS optimizer returns abnormally, with a particular suggestion to check the waypoint flight time and maximum mission duration constraints.
* Update to the SoI transition search code that should now precisely find the SoI boundary for downwards transitions.
* Fixed a bug with the optimizer constraint warning message units.

As usual, the download is in the OP.  Please let me know if you have any questions.  Happy orbiting!

Edited June 24, 2018 by Arrowstar

[Gordon Dry]

@Arrowstar I'm not sure how to handle the mean anomaly - when I "Get orbit from KSP (Active vessel)" than this value changes each time I do, so how can I make it the value needed in future when the actual burn should occur?

I can copy the departure time and paste it into the epoch field, but that doesn't change the result which is bad.

Without changing these two values it looks like this:

 

 

[Arrowstar]

5 minutes ago, Gordon Dry said:

@Arrowstar I'm not sure how to handle the mean anomaly - when I "Get orbit from KSP (Active vessel)" than this value changes each time I do, so how can I make it the value needed in future when the actual burn should occur?

I can copy the departure time and paste it into the epoch field, but that doesn't change the result which is bad.

Without changing these two values it looks like this:

<snip>

Okay thanks.  Can I see the KSP save file (the one with an extension of *.SFS) that you're working in?

Oh, just to be clear, the epoch field in that box is NOT the departure epoch.  That is the point in time that your spacecraft is at the entered mean anomaly.  (Normally I'd call the mean anomaly field "mean anomaly at epoch" but there wasn't space.)  Entering these and checking the "Use?" checkbox forces the code to try and find the correct departure time such that when you leave your hyperbolic excess velocity vector is in the same direction as the ideal.

Edited June 24, 2018 by Arrowstar

[Gordon Dry]

12 minutes ago, Arrowstar said:

Can I see the KSP save file

Jep, also the log and stuff, in a .7z (btw the log is 300 MB, the most comes from KSPTOT):
https://www.dropbox.com/s/hoij37n9qwv1jpj/2018-06-24_2 KSP.log.7z?dl=1

And you know what? Just downloaded the release and trying it again ...

Edit:

Same issue for me.

Edited June 24, 2018 by Gordon Dry

[Arrowstar]

19 minutes ago, Gordon Dry said:

Jep, also the log and stuff, in a .7z (btw the log is 300 MB, the most comes from KSPTOT):
https://www.dropbox.com/s/hoij37n9qwv1jpj/2018-06-24_2 KSP.log.7z?dl=1

And you know what? Just downloaded the release and trying it again ...

Thanks.  So I'm pretty confident that the burn solution you're getting is good.  Take a look when I model the maneuver in the high fidelity Mission Architect tool: https://imgur.com/a/n3TbtBB

At this point there are two things that could be wrong:

1. You are burning at the wrong time.  Make sure that the epoch (time) of the maneuver node is within one orbital period of the time shown in KSPTOT.  It should be pretty close to UT = 12035219.659 sec.  The period of that 900 km orbit you're in is 2855 seconds.
2. You are burning at the wrong point in the orbit.  The departure true anomaly is 288.53 degrees.  This is equivalent to 1519.20599 seconds past periapsis.

I suspect it's the former option, #1.  My hunch is that you're planning these maneuvers many days before they are to be executed and are uploading them.  However, the upload tool can default to "Time Past Periapsis" in certain cases, and this would cause you to be burning far earlier than you want to.

If you can verify the time of the maneuver node is close to what it should be, then it's a problem with being at the wrong point in the orbit.  Try and verify that you're burning at the correct true anomaly or time past periapsis.

In either one of these cases, all you really need to do is move the burn epoch around until you get close.  When I modeled the burn in Mission Architect, I actually ended up with something closer to UT = 12037305.1782108 seconds.  Regardless, just push the epoch around 100 seconds or so at a time and see what it does to the resultant sun-centered orbit.  When you start getting closer to Neidon, start using smaller increments until you hit the planet's SoI.

[ThreePounds]

I once again tried to get the Launch Window Analysis to work properly to see if my issues were resolved between the awesome updates you've been putting out for this excellent tool, @Arrowstar! Unfortunately, the same problem persists: if I follow the directions closely, I sometimes get put into an orbit which has an LAN exactly 180° offset from where I want it to be, i.e. the launch azimuth that I was given has been flipped. In the past I corrected those issues with KER but unfortunately, there isn't no way to view your LAN in stock before lift off.

Here's the in-depth report.

 

Summary:

• When using the Launch Window Analysis, sometimes the launch azimuth given is due south when it should be due north and vise-versa

Steps to reproduce:

1. Launch KSPTOT 1.5.10, Mission Architect and Launch Window Analysis
2. enter: Target Inclination: 5.6, Target RAAN: 316 - everything else default
3. first result: 7280.158s UT, 84.401° Azimuth
4. launch KSP 1.4.4, create new sandbox game, put KerbalX on the launch pad
5. time warp forward to the specified time, which is Y1, D01, 02:01:00 approximately
6. launch east, heading slightly north, set the mun as target for inclination fine control
7. get KerbalX into orbit, quit to main menu

Expected Result:

• We arrive at approximately the orbit we targeted

Actual Result:

• now to see if we are in the correct orbit, we have to open the save file and get to the vessel orbit information, here's what I see:

			ORBIT
			{
				SMA = 684722.61710577214
				ECC = 0.00048902921829306199
				INC = 5.837735959910237
				LPE = 161.99738541595747
				LAN = 138.678376733356
				MNA = -2.3354479809756241
				EPH = 7535.6197543537428
				REF = 1
			}

• The inclination is correct as expected, however the LAN is exactly 180° less than what we expected. That means we had to launch slightly south, meaning our launch azimuth should have been reported as 95.599° by Launch Window Analysis for the specified time.

Save file: https://drive.google.com/file/d/1Q6B6VdjtrYGPtOhGzN_s5WMS0SNxKLbb/view?usp=sharing

Screenshot of KSPTOT: 

 

Hope this helps

[Drew Kerman]

Oh geez the launch azimuth thing is still a thing? In case you’re wondering @Arrowstar yea this is something we covered a few years ago. Damn, crazy it’s been that long but yea I haven’t launched any rockets that needed the launch window planner since I ended my original KSA run back in 2016

[Arrowstar]

On 6/28/2018 at 2:35 AM, Three_Pounds said:

I once again tried to get the Launch Window Analysis to work properly to see if my issues were resolved between the awesome updates you've been putting out for this excellent tool, @Arrowstar! Unfortunately, the same problem persists: if I follow the directions closely, I sometimes get put into an orbit which has an LAN exactly 180° offset from where I want it to be, i.e. the launch azimuth that I was given has been flipped. In the past I corrected those issues with KER but unfortunately, there isn't no way to view your LAN in stock before lift off.

Here's the in-depth report.

 

Summary:

• When using the Launch Window Analysis, sometimes the launch azimuth given is due south when it should be due north and vise-versa

Steps to reproduce:

1. Launch KSPTOT 1.5.10, Mission Architect and Launch Window Analysis
2. enter: Target Inclination: 5.6, Target RAAN: 316 - everything else default
3. first result: 7280.158s UT, 84.401° Azimuth
4. launch KSP 1.4.4, create new sandbox game, put KerbalX on the launch pad
5. time warp forward to the specified time, which is Y1, D01, 02:01:00 approximately
6. launch east, heading slightly north, set the mun as target for inclination fine control
7. get KerbalX into orbit, quit to main menu

Expected Result:

• We arrive at approximately the orbit we targeted

Actual Result:

• now to see if we are in the correct orbit, we have to open the save file and get to the vessel orbit information, here's what I see:

			ORBIT
			{
				SMA = 684722.61710577214
				ECC = 0.00048902921829306199
				INC = 5.837735959910237
				LPE = 161.99738541595747
				LAN = 138.678376733356
				MNA = -2.3354479809756241
				EPH = 7535.6197543537428
				REF = 1
			}

• The inclination is correct as expected, however the LAN is exactly 180° less than what we expected. That means we had to launch slightly south, meaning our launch azimuth should have been reported as 95.599° by Launch Window Analysis for the specified time.

Save file: https://drive.google.com/file/d/1Q6B6VdjtrYGPtOhGzN_s5WMS0SNxKLbb/view?usp=sharing

Screenshot of KSPTOT: 

 

Hope this helps

 

On 6/28/2018 at 12:31 PM, Drew Kerman said:

Oh geez the launch azimuth thing is still a thing? In case you’re wondering @Arrowstar yea this is something we covered a few years ago. Damn, crazy it’s been that long but yea I haven’t launched any rockets that needed the launch window planner since I ended my original KSA run back in 2016

Thanks for the report, @Three_Pounds!  I'm embarrassed to say I did actually find the bug and it was not particularly challenging.  Here is KSPTOT v1.5.11 pre-release 1 with the fix.  Please let me know if this resolves the issue for you.  Sorry about the long wait to get back to you, I've been out of town.

Change log:

1. Fixed issue with Mission Architect Launch Window Analysis tool that could cause the launch azimuth shown to be incorrect in certain cases.

[ThreePounds]

12 minutes ago, Arrowstar said:

 

Thanks for the report, @Three_Pounds!  I'm embarrassed to say I did actually find the bug and it was not particularly challenging.  Here is KSPTOT v1.5.11 pre-release 1 with the fix.  Please let me know if this resolves the issue for you.  Sorry about the long wait to get back to you, I've been out of town.

Change log:

1. Fixed issue with Mission Architect Launch Window Analysis tool that could cause the launch azimuth shown to be incorrect in certain cases.

Awesome! Btw, the astrodynamics calculator has trouble converting ap + pe to sme + e for hyperbolic orbits. It requires the ap to be positive, which isn't true for hyperbolic trajectories.

You can steal this code snipped I wrote in VBA for my excel table if you want:

Private Sub calc_from_below1_Click()

'define working variables

Dim a As Double
Dim b As Double
Dim e As Double
Dim pe As Double
Dim ap As Double
Dim Radius As Double

'read central body radius from cell
Radius = Range("D7").Value 
'read altitude of apoapsis from cell
ap = Radius + Range("D17").Value 
'read altitude of periapsis from cell
pe = Radius + Range("D18").Value 

'calculate semi-major axis
a = 0.5 * (ap + pe) 

'Check if the orbit is elliptical or hyperbolic
'elliptical
If ap >= 0 And pe >= 0 Then

'calculate semi-minor axis
b = Sqr(ap * pe) 
'calculate eccentricity
e = Sqr(1 - b ^ 2 / a ^ 2)

'hyperbolic trajectory
ElseIf ap < 0 Xor pe < 0 Then 

'calculate semi-minor axis
b = Sqr(-ap * pe) 
'calculate eccentricity
e = Sqr(1 + b ^ 2 / a ^ 2)

'Invalid Orbit
Else 

MsgBox "Error: At least one apside must be positive.", vbCritical, "Input Error"

End If

'write SMA to cell
Range("D14").Value = a 
'write eccentricity to cell
Range("D15").Value = e 

End Sub

 

Edited July 4, 2018 by Three_Pounds

[Arrowstar]

5 hours ago, Three_Pounds said:

Awesome! Btw, the astrodynamics calculator has trouble converting ap + pe to sme + e for hyperbolic orbits. It requires the ap to be positive, which isn't true for hyperbolic trajectories.

You can steal this code snipped I wrote in VBA for my excel table if you want:

Private Sub calc_from_below1_Click()

'define working variables

Dim a As Double
Dim b As Double
Dim e As Double
Dim pe As Double
Dim ap As Double
Dim Radius As Double

'read central body radius from cell
Radius = Range("D7").Value 
'read altitude of apoapsis from cell
ap = Radius + Range("D17").Value 
'read altitude of periapsis from cell
pe = Radius + Range("D18").Value 

'calculate semi-major axis
a = 0.5 * (ap + pe) 

'Check if the orbit is elliptical or hyperbolic
'elliptical
If ap >= 0 And pe >= 0 Then

'calculate semi-minor axis
b = Sqr(ap * pe) 
'calculate eccentricity
e = Sqr(1 - b ^ 2 / a ^ 2)

'hyperbolic trajectory
ElseIf ap < 0 Xor pe < 0 Then 

'calculate semi-minor axis
b = Sqr(-ap * pe) 
'calculate eccentricity
e = Sqr(1 + b ^ 2 / a ^ 2)

'Invalid Orbit
Else 

MsgBox "Error: At least one apside must be positive.", vbCritical, "Input Error"

End If

'write SMA to cell
Range("D14").Value = a 
'write eccentricity to cell
Range("D15").Value = e 

End Sub

 

It requires Ap to be a positive quantity, because in the strictest sense, apoapsis is undefined for hyperbolic orbits, even if mathematically it works out.  If there's interest in not requiring that, removing the check is pretty easy from the code.

[ThreePounds]

13 hours ago, Arrowstar said:

It requires Ap to be a positive quantity, because in the strictest sense, apoapsis is undefined for hyperbolic orbits, even if mathematically it works out.  If there's interest in not requiring that, removing the check is pretty easy from the code.

Well, I think it would make the tool that much more useful. Of course, a negative apoapsis radius is nonsensical from a pure physics standpoint, but it's a nice convention to make calculating hyperbolic trajectories easier using the existing variables and almost the same formulas (sign is flipped). Your astrodynamics calculator already spits out a negative apoapsis when supplied with a negative SMA, so I'll make sense if it goes the other way.

But it's your tool, you can decide how it's supposed to be used. I can definitely understand your argument against it.

[Arrowstar]

11 hours ago, Three_Pounds said:

Well, I think it would make the tool that much more useful. Of course, a negative apoapsis radius is nonsensical from a pure physics standpoint, but it's a nice convention to make calculating hyperbolic trajectories easier using the existing variables and almost the same formulas (sign is flipped). Your astrodynamics calculator already spits out a negative apoapsis when supplied with a negative SMA, so I'll make sense if it goes the other way.

But it's your tool, you can decide how it's supposed to be used. I can definitely understand your argument against it.

No worries, I removed the constraint that apogee must be greater than 0.  It was a very easy change.  It will be in the next release.  Thanks for the suggestion!

[Drew Kerman]

hey @Arrowstar the orbital decay mod was recently picked up by @Papa_Joe so it's been brought back up to compatibility with the latest KSP. It's got me thinking again about playing with it. Unlike the n-body mod, which really just adds more work for me on the backend with little exposure to my KSA audience, orbital decay plays a much more dynamic role in missions, requiring additional tasks like orbital boosting and re-fueling and missions ending due to decay if they can't be boosted/refueled and then me having to launch replacements - it just has the potential to add a lot more "action" to what the KSA is doing. My big problem with it though is that if I'm making a long-term mission plan for anything, Mission Architect won't be accurate anymore. PJ says he's willing to expose whatever data you need, and the mod itself already has a means of giving the user an estimate as to when the orbit will decay. If the task is a bit too much to integrate the decay model itself into MA, then perhaps you can work out some basic numbers MA can use to at least account for the decay - so while I wouldn't be able to model a long-term mission with full accuracy, it could potentially come close and I'll just need to do more work during the mission itself to keep in on track. I would enjoy that just as much I think.

[Arrowstar]

18 hours ago, Drew Kerman said:

hey @Arrowstar the orbital decay mod was recently picked up by @Papa_Joe so it's been brought back up to compatibility with the latest KSP. It's got me thinking again about playing with it. Unlike the n-body mod, which really just adds more work for me on the backend with little exposure to my KSA audience, orbital decay plays a much more dynamic role in missions, requiring additional tasks like orbital boosting and re-fueling and missions ending due to decay if they can't be boosted/refueled and then me having to launch replacements - it just has the potential to add a lot more "action" to what the KSA is doing. My big problem with it though is that if I'm making a long-term mission plan for anything, Mission Architect won't be accurate anymore. PJ says he's willing to expose whatever data you need, and the mod itself already has a means of giving the user an estimate as to when the orbit will decay. If the task is a bit too much to integrate the decay model itself into MA, then perhaps you can work out some basic numbers MA can use to at least account for the decay - so while I wouldn't be able to model a long-term mission with full accuracy, it could potentially come close and I'll just need to do more work during the mission itself to keep in on track. I would enjoy that just as much I think.

It's an interesting idea.  I could probably do it as a new type of coast. I would need to understand how that mod models the decay.  @Papa_Joe, can you provide me with some information on your decay model? 

[Drew Kerman]

1 hour ago, Arrowstar said:

It's an interesting idea.  I could probably do it as a new type of coast. I would need to understand how that mod models the decay.  @Papa_Joe, can you provide me with some information on your decay model? 

He's still new to the mod himself and hasn't really poked at it much other than to get it compatible with the latest KSP

[Arrowstar]

16 minutes ago, Drew Kerman said:

He's still new to the mod himself and hasn't really poked at it much other than to get it compatible with the latest KSP

Okay no worries.  After a quick assessment, I think it would be very doable to model the atmospheric losses.  The radiation pressure doesn't look worth it and the others I'm not so sure about.  Do you think that would be sufficient?

[Thomas, a Kerbonaut]

I am playing on Xbox, so I wonder if there is a way to run the KSP TOT without the ksp installed in my computer. This way, I could insert the details of my orbit, and time to run a simulation. If there were is no way to run the TOT without KSP, is there any other similar software to do so ?

[Drew Kerman]

5 hours ago, Arrowstar said:

Do you think that would be sufficient? 

seems like the atmospheric drag is the largest effect. The Radiation Drag and Yarkovsky Effect seem too minor to bother with and are too dependent on the shape and rotation of the craft. I like the MassCon idea but right now just being for Kerbin and Mun it's not worth looking at for Mission Architect. If you can get the atmospheric drag working, that would be beyond awesome

[Gilph]

12 hours ago, Thomas, a Kerbonaut said:

I am playing on Xbox

I am so sorry...

12 hours ago, Thomas, a Kerbonaut said:

so I wonder if there is a way to run the KSP TOT without the ksp installed in my computer.

Yes. KSP is not a requirement. Follow the instructions in the OP carefully and it runs fine. But it will be very time consuming to manually transfer parameters back and forth.

The only issue I can think of is whether the Xbox version is fully compatible with the stock bodies.ini file.

[Thomas, a Kerbonaut]

3 hours ago, Gilph said:

The only issue I can think of is whether the Xbox version is fully compatible with the stock bodies.ini file.

I think it might not be a problem. I have used this tool before “https://alexmoon.github.io/ksp/“ and it worked really well. So I would like to try thr TOT in order to find which is better when playing on consoles. Thanks

[Arrowstar]

3 hours ago, Gilph said:

The only issue I can think of is whether the Xbox version is fully compatible with the stock bodies.ini file.

I can't really comment because I don't own an xbox. Should be identical in theory though.

@Thomas, a Kerbonaut if you need help using KSPTOT or getting it installed, please let me know.  Thanks!