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

[Drew Kerman]

On 2/11/2018 at 10:53 PM, dlrk said:

When I try to load an orbit from SFS, I get a chord sound and this error in the log:

I've been loading orbits fine from SFS with the latest KSPTOT. Just tried it, no problem. Provide reproduction steps

[dlrk]

Literally, for me the only reproduction steps are:

1. Select load from SFS.
2. Select persistent.sfs
3. Hear chord
4. Open log
5. See error
 

[Arrowstar]

1 minute ago, dlrk said:

Literally, for me the only reproduction steps are:

1. Select load from SFS.
2. Select persistent.sfs
3. Hear chord
4. Open log
5. See error
 

Can you post the SFS file?

[dlrk]

I'll post it as soon as I get home.

[dlrk]

https://www.dropbox.com/s/tbhqex37ztt676k/persistent.sfs?dl=0

[ManuelKSP]

What an Amazing tool!! Great job my friend!
I guess I'm late on this, but I have found yesterday this tool and just started paying with it.

I have a question: once you have found a nice maneuver that gives you nice transfer to somewhere, let's say Kerbin -> Duna, how do you actually implement it? I mean, you create a new maneuver with correct DeltaVs, but there are two information that looks like they're missing.

1) I get true anomaly of the maneuver, but I have no way to know the true anomaly of the maneuver I'm creating... other then eyeballing it of course. You could fix this by using "Upload Maneuver to KSP"  in "Time Past Peri." mode. And here come the second problem:

2) How do I know how many revolution I have to make before burning? Again, you could fix this click again and again the "+ orbit" button of your maneuver untill you get the clean encounter (for the few experiments I'v done it worked) but it doesn't sound like a nice solution.

My question is: why no information about the theoretical Universal Time of the maneuver in the "Compute Departure Burn" is given? I really don't get it.. it tells me the departure time which really look more a kind of the starting point of the optimization window.

Maybe a number of revolutions could be provided other then the True Anomaly and Time Past Peri. indications.

Probably I'm just not using it the right way I guess...

 

Cheers guys!

[Arrowstar]

On 2/13/2018 at 11:42 PM, dlrk said:

https://www.dropbox.com/s/tbhqex37ztt676k/persistent.sfs?dl=0

Okay, give this a try.  KSPTOT v1.5.10 pre-release 1.  As far as I can tell, this corrects the issue you found with the SFS import.

13 hours ago, ManuelKSP said:

What an Amazing tool!! Great job my friend!
I guess I'm late on this, but I have found yesterday this tool and just started paying with it.

I have a question: once you have found a nice maneuver that gives you nice transfer to somewhere, let's say Kerbin -> Duna, how do you actually implement it? I mean, you create a new maneuver with correct DeltaVs, but there are two information that looks like they're missing.

1) I get true anomaly of the maneuver, but I have no way to know the true anomaly of the maneuver I'm creating... other then eyeballing it of course. You could fix this by using "Upload Maneuver to KSP"  in "Time Past Peri." mode. And here come the second problem:

2) How do I know how many revolution I have to make before burning? Again, you could fix this click again and again the "+ orbit" button of your maneuver untill you get the clean encounter (for the few experiments I'v done it worked) but it doesn't sound like a nice solution.

My question is: why no information about the theoretical Universal Time of the maneuver in the "Compute Departure Burn" is given? I really don't get it.. it tells me the departure time which really look more a kind of the starting point of the optimization window.

Maybe a number of revolutions could be provided other then the True Anomaly and Time Past Peri. indications.

Probably I'm just not using it the right way I guess...

 

Cheers guys!

1) The method you described, using the Upload Maneuver feature, is the correct way to execute the maneuver in KSP itself.  This will automatically place a maneuver node in the correct place for execution.

2) If you upload the maneuver to KSP, it will get the timing correct as long as you tell KSPTOT the epoch of the orbit and the mean anomaly of the orbit at that epoch.  If you don't provide timing information to KSPTOT, then it will assume that less than one revolution is sufficient to phase the maneuver.

Please let me know if you have any other questions.  Happy orbiting!

[dlrk]

@Arrowstar

That works, thanks!

[Drew Kerman]

hey @Arrowstar is it possible to also have the line type options (dotted, dashed, etc) available for plotting in the mission trajectory in the various states that let you pick a color for the line plot?

Small bug report too that the Docking and Landing state windows are missing the event capture for the Esc key to close them. Thx!

An additional thought: saving the values for all the MFMS initial variables to the text file along with the final trajectory data (central body, launch window, run count, etc)

Edited February 27, 2018 by Drew Kerman

[Drew Kerman]

me again

Found something off, might be a precision issue or might be a genuine bug I can't tell. Here are the files for reproduction.

1. Start a new MA project
2. Import from the SFS file the orbital data from Ast. AXX-667
3. Create coast to Pe
4. Edit coast and switch to UT, back off 5 minutes
5. Create coast to function value - 70km altitude with a max propagation time of 500s
6. Make note of the Final State time
7. Open the include MAT file
8. Goto Other Spacecraft
9. Copy to the clipboard the orbital data for AXX-667(C)
10. Start a new MA project
11. Paste into the initial state the orbital data
12. Repeat steps 3-6

When I import from the SFS versus pasting the orbital data I get an atmospheric entry point 388km further east because the times are different. Not sure if the orbital copy/paste is to blame or if it's just because the values saved for Other Spacecraft are not carried out to as many significant digits as what is imported from the SFS file.

[Gilph]

I can't let @Drew Kerman have all the fun using MFMS, so I decided to try a Gael-Tellumo-Leto trip (GPP).

It found a nice solution that cut 20Y from a 44Y trip, but as you would expect, I had a hyperbolic excess velocity of almost 2k at Leto arrival, which will burn a lot of deltav to get captured. I looked to try and find some ways to increase trip duration while lowering HEV, but the trip duration fields of the screen were grayed out as NA and not editable.

I thought of putting things in MA and try to optimize for lower HEV, but there is no way to do that (based on some guidance you had previously shared).

So how would I go about looking for the best solution in MFMS that allows me to arrive at a more reasonable speed?

Thanks

[Drew Kerman]

4 hours ago, Gilph said:

So how would I go about looking for the best solution in MFMS that allows me to arrive at a more reasonable speed?

My bet would be to shorten the range of the Min/Max flight bounds far to the high end. Use the porkchop plotter to get a good idea of an ideal transfer time to Leto from Tellumo. Say that time is 350 days. Now tell the MFMS that you want to make your leg from Tellumo to Leto last 300-400 days. This should give you a more leisurely trajectory towards the planet, if possible. Obviously the faster you want to get there time-wise the faster you're going to be traveling when you arrive. It's not a direct correlation because distances themselves can be shorter depending on the route you pick but generally you gotta move fast to get places fast

Also I've begun my 500 run plots for 68 trajectories, have already found slightly more optimal routes but also have ended up with the same result for some as well. Will of course have the full report when I finish up in May/June

Edited March 2, 2018 by Drew Kerman

[Gilph]

1 hour ago, Drew Kerman said:

My bet would be to shorten the range of the Min/Max flight bounds far to the high end. Use the porkchop plotter to get a good idea of an ideal transfer time to Leto from Tellumo. Say that time is 350 days. Now tell the MFMS that you want to make your leg from Tellumo to Leto last 300-400 days. This should give you a more leisurely trajectory towards the planet, if possible. Obviously the faster you want to get there time-wise the faster you're going to be traveling when you arrive. It's not a direct correlation because distances themselves can be shorter depending on the route you pick but generally you gotta move fast to get places fast

Also I've begun my 500 run plots for 68 trajectories, have already found slightly more optimal routes but also have ended up with the same result for some as well. Will of course have the full report when I finish up in May/June

Got it, thanks. Made a silly mistake on the UI.  If the last leg is selected, the flight time bounds fields are grayed out and say N/A. I have to select the second leg and put the time bounds in.

[Arrowstar]

On 2/27/2018 at 8:23 AM, Drew Kerman said:

hey @Arrowstar is it possible to also have the line type options (dotted, dashed, etc) available for plotting in the mission trajectory in the various states that let you pick a color for the line plot?

Small bug report too that the Docking and Landing state windows are missing the event capture for the Esc key to close them. Thx!

An additional thought: saving the values for all the MFMS initial variables to the text file along with the final trajectory data (central body, launch window, run count, etc)

1) Yes, it could be.  I can try to add it this weekend, shouldn't be too hard.

2) Bugs have been fixed.  Thanks for the report!

3) I guess this would be possible.  At each optimizer run?  What would be the purpose or use case?

On 3/1/2018 at 5:38 AM, Drew Kerman said:

me again

Found something off, might be a precision issue or might be a genuine bug I can't tell. Here are the files for reproduction.

1. Start a new MA project
2. Import from the SFS file the orbital data from Ast. AXX-667
3. Create coast to Pe
4. Edit coast and switch to UT, back off 5 minutes
5. Create coast to function value - 70km altitude with a max propagation time of 500s
6. Make note of the Final State time
7. Open the include MAT file
8. Goto Other Spacecraft
9. Copy to the clipboard the orbital data for AXX-667(C)
10. Start a new MA project
11. Paste into the initial state the orbital data
12. Repeat steps 3-6

When I import from the SFS versus pasting the orbital data I get an atmospheric entry point 388km further east because the times are different. Not sure if the orbital copy/paste is to blame or if it's just because the values saved for Other Spacecraft are not carried out to as many significant digits as what is imported from the SFS file.

I'll take a look!  Thanks for the report.

[Arrowstar]

On 3/1/2018 at 5:38 AM, Drew Kerman said:

me again

Found something off, might be a precision issue or might be a genuine bug I can't tell. Here are the files for reproduction.

1. Start a new MA project
2. Import from the SFS file the orbital data from Ast. AXX-667
3. Create coast to Pe
4. Edit coast and switch to UT, back off 5 minutes
5. Create coast to function value - 70km altitude with a max propagation time of 500s
6. Make note of the Final State time
7. Open the include MAT file
8. Goto Other Spacecraft
9. Copy to the clipboard the orbital data for AXX-667(C)
10. Start a new MA project
11. Paste into the initial state the orbital data
12. Repeat steps 3-6

When I import from the SFS versus pasting the orbital data I get an atmospheric entry point 388km further east because the times are different. Not sure if the orbital copy/paste is to blame or if it's just because the values saved for Other Spacecraft are not carried out to as many significant digits as what is imported from the SFS file.

Something is very, very off between the orbit in the SFS file and the orbit data in the MAT file.  I'm not sure what, I'll let you investigate, but here's a plot of the distance between the two spacecraft (one from the SFS file and the other from the MAT file, created as an "Other Spacecraft".)  Notice how the difference in initial position is ~1200-1300 km...

Edited March 4, 2018 by Arrowstar

[Drew Kerman]

7 hours ago, Arrowstar said:

What would be the purpose or use case?

Re-running the plot some other time with any changes the user may want to make. I kept detailed notes on how I ran things for my first series of 50 runs for various flyby combinations which I was able to use to re-program the MFMS to re-run the same values at 500 iterations. But without the foresight to take note of what I did the first time this would have been rough to recreate from memory (at least mine, which sucks haha). I'm getting the exact same results for some of these plots at 500 iterations as I did at 50 which is very reassuring.

7 hours ago, Arrowstar said:

Something is very, very off between the orbit in the SFS file and the orbit data in the MAT file. 

Interesting - do this: open the MAT file, add a new Other Spacecraft and import the vessel data from the persistent file for Ast. AXX-667. Now flip between the two entries for that same vessel and you should see no differences shown between the values. I had already done this but did not think to mention it in my original report

Edited March 4, 2018 by Drew Kerman

[Arrowstar]

17 hours ago, Drew Kerman said:

Re-running the plot some other time with any changes the user may want to make. I kept detailed notes on how I ran things for my first series of 50 runs for various flyby combinations which I was able to use to re-program the MFMS to re-run the same values at 500 iterations. But without the foresight to take note of what I did the first time this would have been rough to recreate from memory (at least mine, which sucks haha). I'm getting the exact same results for some of these plots at 500 iterations as I did at 50 which is very reassuring.

Interesting - do this: open the MAT file, add a new Other Spacecraft and import the vessel data from the persistent file for Ast. AXX-667. Now flip between the two entries for that same vessel and you should see no differences shown between the values. I had already done this but did not think to mention it in my original report

1) Got it.  Not sure how feasible it is to do simply, but I can look into it anyway.

2) So it does look like it's a rounding issue with the SFS import.  I think I need to issue the recommendation that for high precision work, only the direct import from the game itself (where I pull the double values representing the orbit directly) should be used.

[Drew Kerman]

5 hours ago, Arrowstar said:

2) So it does look like it's a rounding issue with the SFS import.  I think I need to issue the recommendation that for high precision work, only the direct import from the game itself (where I pull the double values representing the orbit directly) should be used.

what's keeping you from storing them at that precision?

[Gilph]

On ‎3‎/‎2‎/‎2018 at 5:12 PM, Drew Kerman said:

My bet would be to shorten the range of the Min/Max flight bounds far to the high end. Use the porkchop plotter to get a good idea of an ideal transfer time to Leto from Tellumo. Say that time is 350 days. Now tell the MFMS that you want to make your leg from Tellumo to Leto last 300-400 days. This should give you a more leisurely trajectory towards the planet, if possible. Obviously the faster you want to get there time-wise the faster you're going to be traveling when you arrive. It's not a direct correlation because distances themselves can be shorter depending on the route you pick but generally you gotta move fast to get places fast

Also I've begun my 500 run plots for 68 trajectories, have already found slightly more optimal routes but also have ended up with the same result for some as well. Will of course have the full report when I finish up in May/June

 

On ‎3‎/‎2‎/‎2018 at 6:34 PM, Gilph said:

Got it, thanks. Made a silly mistake on the UI.  If the last leg is selected, the flight time bounds fields are grayed out and say N/A. I have to select the second leg and put the time bounds in.

Hi, thanks for the help. I did manage to do a 200 run plot with the parameters I wanted and got a really nice solution. The problem was, it did not seem to work when I transferred to KSP. The first leg got an intercept with Tellumo, but the second burn got me nowhere near Leto, although the magnitude of the burn should have resulted in a much larger orbit than KSP showed. It's 3 years in the future, so I'll warp to that time and play around with it some more.

I was trying to debug in MA and had a question. It looks like MFMS plans the intermediate burns to happen at Pe, since burn TA is at 0. What constitutes the arrival time? Is it the SOI transition for the body or when you arrive at Pe? I was trying to determine the burn time at Tellumo and it did not seem easy to do. Thanks

[Drew Kerman]

3 minutes ago, Gilph said:

I was trying to debug in MA and had a question. It looks like MFMS plans the intermediate burns to happen at Pe, since burn TA is at 0. What constitutes the arrival time? Is it the SOI transition for the body or when you arrive at Pe? I was trying to determine the burn time at Tellumo and it did not seem easy to do. Thanks

@Arrowstar will have to handle this one as I've only had experience plotting so far and not yet translating the results into an actual mission plan

[Arrowstar]

9 hours ago, Gilph said:

I was trying to debug in MA and had a question. It looks like MFMS plans the intermediate burns to happen at Pe, since burn TA is at 0. What constitutes the arrival time? Is it the SOI transition for the body or when you arrive at Pe? I was trying to determine the burn time at Tellumo and it did not seem easy to do. Thanks

So remember that MFMS is a two body, patched conics simulation only.  Therefore, there really isn't a concept of "SoI" or "Periapsis."  I've always taken it to be the periapsis time, but you could probably do either and it would be okay so long as the time scale of the transfer arc is much, much longer than the amount of time the spacecraft spends in the target body's SoI.

Also note that the burns are going to be slightly different from MFMS to MA because of the fact that you have to actually escape an SoI in MA.  In MFMS, those delta-vs might be shown in an SoI, but they're honestly just approximations of the real burn because MFMS doesn't actually do anything with SoIs.  That's why the burns can be a bit different between MFMS and MA.

[Gilph]

13 hours ago, Arrowstar said:

So remember that MFMS is a two body, patched conics simulation only.  Therefore, there really isn't a concept of "SoI" or "Periapsis."  I've always taken it to be the periapsis time, but you could probably do either and it would be okay so long as the time scale of the transfer arc is much, much longer than the amount of time the spacecraft spends in the target body's SoI.

Also note that the burns are going to be slightly different from MFMS to MA because of the fact that you have to actually escape an SoI in MA.  In MFMS, those delta-vs might be shown in an SoI, but they're honestly just approximations of the real burn because MFMS doesn't actually do anything with SoIs.  That's why the burns can be a bit different between MFMS and MA.

Thanks.

These were the steps I used to make a MA plan from MFMS:

1. Set current state
2. Coast to a departure time that is close to the departure time in MFMS
3. Coast to burn TA
4. departure burn
5. Coast to SOI (Sun)
6. Coast to SOI (2nd body)
7. Coast to Pe (TA equal 0)
8. second burn from MFMS
9. Coast to SOI (Sun)
10. Coast to Pe of third and last body)

Steps 1-5 worked really well and the burn in step 4 intercepted body 2. The burn in step 8 did not work well, even with a large range in optimizations. When I compared the state calculated in MA on step 9 with the second sun centric orbit in MFMS, it was very different. So, I thought the issue is the second burn. Are there a better set of steps to follow when I'm inside the SOI of the second body? I tried a few things like optimizing the argument of periapsis and Pe radius to match what MFMS had, but it didn't really help.

 

 

 

[Drew Kerman]

On 3/5/2018 at 12:36 AM, Drew Kerman said:

what's keeping you from storing them at that precision?

I fear this may have come across as snarky or demanding but I'm just curious

[Drew Kerman]

also remember the bug report I made where I would add an event and it would not appear in the event listing but I could still Undo it from the Edit menu and Redo it to add it back and it would show up? Yea I'm positive now that's just me being too quick for the application plugging in orbital data for asteroids to check things is a daily task and I'm so well-practiced at it that after loading up the Initial State and closing the window I can open up the Create Coast window so fast that the main application window sometimes still says  "loading..." and hasn't updated yet with the data from the Initial State window! So when I close the Create Coast the app finishes updating with the Initial State data but then doesn't actually add the new coast because that wasn't part of the update cycle when it kicked off. So yea, nothing to fix there I just need to slow down a bit haha (unless you really want to add in a block to not allow new dialogs to pop up until the current update is finished, but I doubt it's worth the effort to "fix" this issue)

Edited March 10, 2018 by Drew Kerman

[dlrk]

Is there a way to plan a rendezvous with a spacecraft orbiting a different central body than the initial one? Like planning a mission from Kerbin orbit to a space station orbiting the Mun? Or a mission from Kerbin to an asteroid in solar orbit?