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

[Drew Kerman]

I have a Duna transfer window coming up according to this tool and now with v1 I will be working on my first interplanetary trip! Thanks so much for this application. I definitely plan to use the MSMF for a Voyager-style mission as well at some point

[diomedea]

... I will probably leave the ability to plot multiple flybys, but you can bet I'll be checking memory usage aggressively as the application runs and attempting to terminate graceful if something bad happens...

...

Definitely! I really like the idea of zoom-recompute. I'll put a checkbox on the GUI, though, to enable this feature, as recomputing is CPU/memory intensive, as I've said. I will also allow bounds for flight time, that's not a bad idea as well. I'll probably also have a "number of points per axis" input that users can use to adjust memory usage (less points per axis -> fewer calculations -> less memory usage). Unless you think this might be too complicated for basic users?

I don't have any additional progress to show on this tonight as I was concentrating on getting KSPTOT v1.0 out. But I'll start again tomorrow and see what progress can be made. Thanks!

Your progress has been really impressive. Congrats for the release of KSPTOT v. 1.0, really something to celebrate .

Yes, I like all the options about different sets of bounds for plots. Too complicated? Perhaps (I will have to try to get how plots may differ if I limit the number of points, against a limited range of dates), but having all those different options may really help users get what they like, while keeping under control computing time and resources.

About users, I would say that anybody going to use KSPTOT likes to handle complicated stuff anyway; however the learning curve is steep (it took months for me to learn how to use MA). You may enable specific options "only for advanced users", tying them to a setting to be managed via a menu switch. But I guess every KSPTOT user is going to select "advanced mode" anyway.

About plotting multiple flybys, I like that approach, keeping it in but checking memory usage to prevent overflows. Together with stricter bounds, some of those plots may indeed be possible to generate within a 32bit memory space. And, even if MCR 64bit (up to ver. R2014a) proved not to be usable with KSPTOT, a future version may be working, allowing more memory to be used. And, TBH, I foresee more powerful computers to be used to run KSPTOT, than the ones currently available to the average KSP user.

[Arrowstar]

I have some progress to show from work on the Flyby Porkchop Plotter tonight. Take a look:

A few notes:

1) I had a severe problem with the data post-processing prior to tonight. This plot actually shows non-random trends in the delta-v, which is what I expected.

2) Most of the GUI is non-functional, but the button to do the plotting works, as do the waypoint table and buttons since I borrowed from MFMS.

3) All of this is very Work In Progress at the moment.

I could use some feedback on two items:

1) First, where should I stick the ability to place bounds on the flight times? It needs to be one set of upper/lower bounds per leg of the journey (or number of waypoints -1). I could stick it in the table with the waypoints, but then it gets ambiguous as to if the second row corresponds to the first leg or the second leg and so on. Any thoughts, anyone?

2) Any thoughts on issues you see with the GUI or additional options you'd like to see? Now's the time for feedback here, as once I get the GUI mostly worked up, it's hard to really change it.

In other news:

1) I fixed a regression in Mission Architect that made it hard to find SoI transitions in some places. This fix will be in KSP TOT v1.1.

2) I made a minor change to Mission Architect's optimizer settings that can improve convergence speed by a factor of 5x in the absence of optimization constraints. Pretty cool.

[diomedea]

I have some progress to show from work on the Flyby Porkchop Plotter tonight. Take a look:

...

I could use some feedback on two items:

1) First, where should I stick the ability to place bounds on the flight times? It needs to be one set of upper/lower bounds per leg of the journey (or number of waypoints -1). I could stick it in the table with the waypoints, but then it gets ambiguous as to if the second row corresponds to the first leg or the second leg and so on. Any thoughts, anyone?

2) Any thoughts on issues you see with the GUI or additional options you'd like to see? Now's the time for feedback here, as once I get the GUI mostly worked up, it's hard to really change it.

Given we have multiple possible plots with any flyby, I would suggest a title showing what the plot shown actually is. In the image you linked, I bet Flight Time gives out the plot is about the first leg (Kerbin-Eve); but for other flybys I would not be sure.

From the above, I note there is need to have a selector about what leg I want plotted (or, option for the whole trip plotted). Indeed the most easy spot to put a selector is close or embedded with the table of the waypoints (left center in the window). If embedded, no other way then to have selectors on the same rows of the bodies, so the question is only if going with the departure or the arrival body to represent a leg. Because in one or the other case, the first or the last row has no associated selector, it would not be all that confusing. If possible to have a line of selectors not embedded with the table, those may be spaced so to appear at the conjunction of two waypoints in the table. Please note, I don't know what is possible to design in terms of GUI using MATLAB, I write with knowledge of different visual application development environments that make possible to link graphical elements in your code. Of course, those selectors are mutually exclusive (what generally known as "radiobutton" in Windows GUI terms). Somewhere, the selector for the whole trip has to be positioned: could be below the table, as it requires one line of text explaining what it is.

Below the table and the [+] [-] buttons to add/cancel waypoints, would go the entries for minimum and maximum Flight Time valid for the selected leg (or whole trip). That association of Flight Time to the selected leg makes it almost compulsory that those entries are very clearly shown to be referenced to what is selected. How to make so depends largely on what MATLAB allows in a GUI. If it was truly programmable, a possibility would be to draw a line connecting selector and Flight Time entries.

All the above are shown in the image below (I edited your image to add the elements proposed).

In other news:

1) I fixed a regression in Mission Architect that made it hard to find SoI transitions in some places. This fix will be in KSP TOT v1.1.

2) I made a minor change to Mission Architect's optimizer settings that can improve convergence speed by a factor of 5x in the absence of optimization constraints. Pretty cool.

Excellent, still improving. Can hardly wait for KSP TOT v1.1.

[Arrowstar]

Thanks for the mock up! That was super useful. I didn't quite implement it as you envisioned, mostly because the radio-button-in-table concept doesn't work in MATLAB, sadly. (MATLAB is great for computational work but the GUI aspect could use some improvement, sadly).

Anyway, here's what I implemented tonight:

Some notes:

1) The Flight Time Bounds box switches based on the table selection. So if you select the first row, you get Kerbin -> Eve flight time bounds; if you select the second row, you get Eve -> Duna bounds. If you select the third row, the min/max text fields gray out. In the first two cases, the numbers you enter are stored and used directly when you tap the Compute button. The initial bounds are pre-computed based on the same algorithm that the MFMS uses.

2) I can't do a "total flight time" plot because that would not lend itself to a uniform grid, which I need for the contour plot. Sadly!

3) I added checkboxes for adding in the departure/arrival hyperbolic excess velocity (V_Inf).

My biggest problem at the moment is what to do if someone adds or deletes a row in the waypoints table. There's already a restriction that says you can't go below 3 rows (makes sense, for flyby missions). However, let's say I go to four waypoints and then delete the second waypoint. This impacts the stored flight time bounds, which are, strictly speaking, no longer valid as I entered them for a body that might not exist now. Thoughts there? I don't want to just clear all of the user entered values and replace them with the precomputed ones, but maybe that would be easiest? Or maybe there's a more intelligent way to handle it. My thought is to just wipe the rows that were impacted by the deletion and replace them with precomputed rows.

In the event of an addition, I would do the same: wipe the rows that are adjacent to the new waypoint and replace with precomputed values.

Do you think that would work?

Any other thoughts on what you're seeing now?

[diomedea]

Happy to see the Flight Time bounds and a name for the plotted leg. Pity Total Flight Time can't be done, but you were already telling; as long as the kind of clear plot you showed with the second image on June 6th can be achieved, I will be happy with that .

About data for legs beyond a given body if that was deleted or another body added before. My first idea was about deletion of all data beyond that body, but then not all flybys are the same. The effect of flybys can be so very marked (an Eve flyby is certainly so) to radically change whatever comes next. But, with other flybys (Duna while aiming at Jool) the change is limited, so data about the legs further than that body may be worth keeping (question: could also a passage close to a moon, like Laythe, be considered a flyby while going to the parent body, Jool ?). So, a criteria could be the relative gravitational parameter of the bodies involved: Duna's being lesser than both Kerbin's and Jool's, its flyby may be added or discarded without a radical change to the whole flight plan; Eve's is greater than Kerbin's, so adding or deleting it will be markedly different. However, gravitational parameter alone may not fit, and would be better to compare gravitational pull at periapsis?

Returning to a previous subject, may I ask, have you already checked feasability with exponential scale for Delta-V?

[Arrowstar]

(question: could also a passage close to a moon, like Laythe, be considered a flyby while going to the parent body, Jool ?).

Sadly no. Only bodies directly orbiting the given central body may be considered. Use Mission Architect for any of that kind of more complicated stuff.

Returning to a previous subject, may I ask, have you already checked feasability with exponential scale for Delta-V?

Yes, sadly, and the answer is "not possible." I can scale the colormap itself, though, to have more constrast at the low end, and this is what I've done. (See below.)

---

Speaking of what I've done, I have a v1.1.0 pre-release for people to play with. Get it here.

As usual for my pre-releases, this is just the executable, no source or anything like that. The software should be stable, but no promises. I'm primarily looking for bugs and suggestions regarding design and functionality. Feel free to post comments of those natures here.

Diomedea, can you in particular tell me what you think of the Flyby Porkchop Plotter? Given that this endeavor is more or less your idea, your feedback is particularly valuable...

[diomedea]

...

As usual for my pre-releases, this is just the executable, no source or anything like that. The software should be stable, but no promises. I'm primarily looking for bugs and suggestions regarding design and functionality. Feel free to post comments of those natures here.

Diomedea, can you in particular tell me what you think of the Flyby Porkchop Plotter? Given that this endeavor is more or less your idea, your feedback is particularly valuable...

Hope what follows is useful and not a simple list of features still to be implemented or improved that you already know about.

1. As could be expected, the flyby porkchop plot does not put the cursor at any specific location in the graph (unlike the transfer plot does for the least Delta-V point). Though, a minimum Delta-V point may probably still be shown within the current plot. What is really missing is however the data box from the transfer plot. I notice MATLAB allows to create what is called a "Datatip" inside the plot, but currently what it shows are X, Y, and Level values (instead of Date, Flight Time and Delta-V, and possibly other relevant info pertaining to the specific point). Also, it seems the datatips appear not exactly where the cursor is placed: another MATLAB quirk, perhaps.

2. While the Zoom feature in plot works great, it appears less easy to pan the plot. Numerical limits for dates and Flight times certainly do, but are less easy to use.

3. While using Zoom-recompute, the scale of Delta-V should adapt to the range of values present in the new plot. That would help a lot make out areas with different Delta-V.

4. Remaining on the theme of Delta-V scale, there is currently no bound that the user may select. Some plots show large areas with a Delta-V at the bottom of the scale (dark blue) and only small areas with higher Delta-V. My impression is, 10% of the points plotted take 90% of the color scale. I would easily use an upper bound at 20% of the current limit for Delta-V, and redraw the plot not caring of those little areas outside the bound (those would not be of interest anyhow), then having more variety for values on the scale. So the suggestion is to allow the user to define at least an upper bound (if not also a lower one) and balance the color scale within those bounds.

5. Changing waypoints in the table (as well as adding or removing ones) currently seems to not have effect. Recomputing a plot with a different set of waypoints still gives the original one. To draw a plot for a different set, is needed to close and reopen the flyby plotter. Then, to alter the waypoints and see what could differ is not really possible; but is not even possible to open two different instances of the flyby plotter at the same time so to compare.

6. The scrollbar below the plot (actually used to select the different legs) being placed just below the dates axis and aligned with it, seems intuitively to hint at being used to scroll the range of dates. If MATLAB does not allow a better way to make controls for selecting legs, at least that scrollbar should be moved to a different part of the window.

7. Multiple flybys aren't easy. Tried a number of times to make a plot with 4 waypoints, when computing initially KSPTOT shows briefly "Generating Flyby Porkchop Plot. Please wait..." but then nothing appears with the first leg selected, and scrolling to further legs brings up that dialog again apparently without ever completing. KSPTOT does not crash, but uses very low amounts of CPU power and has no impact on memory (monitored by Process Explorer).

8. The "Porkchop Plot Information" textbox on the right of the window is not updated.

Should I say, I am actually thrilled by how fast you implemented that plot? The list above may seem to suggest there is still some work to do, but the amount already done is impressive .

[Arrowstar]

Hope what follows is useful and not a simple list of features still to be implemented or improved that you already know about.

Yeah, I forgot to mention in my previous post that there were still some items that I knew had not been completed yet. That's what happens when you type posts in between bouts of Robocraft.

1. As could be expected, the flyby porkchop plot does not put the cursor at any specific location in the graph (unlike the transfer plot does for the least Delta-V point). Though, a minimum Delta-V point may probably still be shown within the current plot. What is really missing is however the data box from the transfer plot. I notice MATLAB allows to create what is called a "Datatip" inside the plot, but currently what it shows are X, Y, and Level values (instead of Date, Flight Time and Delta-V, and possibly other relevant info pertaining to the specific point). Also, it seems the datatips appear not exactly where the cursor is placed: another MATLAB quirk, perhaps.

Fixed. As for the data tip not being placed exactly where you click, this is because the data tip can only be placed on data points and not in between them. In other words, you need to be on the contour grid somewhere.

2. While the Zoom feature in plot works great, it appears less easy to pan the plot. Numerical limits for dates and Flight times certainly do, but are less easy to use.

Added ability to pan with mouse and recompute upon panning. Fixed.

3. While using Zoom-recompute, the scale of Delta-V should adapt to the range of values present in the new plot. That would help a lot make out areas with different Delta-V.

This should happen automatically. Can you let me know if it's still a problem in the next pre-release?

4. Remaining on the theme of Delta-V scale, there is currently no bound that the user may select. Some plots show large areas with a Delta-V at the bottom of the scale (dark blue) and only small areas with higher Delta-V. My impression is, 10% of the points plotted take 90% of the color scale. I would easily use an upper bound at 20% of the current limit for Delta-V, and redraw the plot not caring of those little areas outside the bound (those would not be of interest anyhow), then having more variety for values on the scale. So the suggestion is to allow the user to define at least an upper bound (if not also a lower one) and balance the color scale within those bounds.

I added a dropdown menu that lets the user select what fraction of the data they wish to view: 10% to 100% in 10% steps, and then a variety of steps below 10%. I didn't want to go with a text box because it required more space and I wasn't sure the user would understand it as well. Anyway, let me know what you think.

5. Changing waypoints in the table (as well as adding or removing ones) currently seems to not have effect. Recomputing a plot with a different set of waypoints still gives the original one. To draw a plot for a different set, is needed to close and reopen the flyby plotter. Then, to alter the waypoints and see what could differ is not really possible; but is not even possible to open two different instances of the flyby plotter at the same time so to compare.

You need to recompute the plot after changing waypoints by hitting the Compute button in the lower right corner. Just changing which plot you're looking at does not recompute everything (if it did, it would take too long to be useful).

6. The scrollbar below the plot (actually used to select the different legs) being placed just below the dates axis and aligned with it, seems intuitively to hint at being used to scroll the range of dates. If MATLAB does not allow a better way to make controls for selecting legs, at least that scrollbar should be moved to a different part of the window.

Sadly, I can't think of a better way to get MATLAB to change the plots. I guess I could use a dropdown menu? This scrollbar functionality is the same that's used in the MFMS, though. I do see your point, however. Is it confusing enough that it should be changed?

7. Multiple flybys aren't easy. Tried a number of times to make a plot with 4 waypoints, when computing initially KSPTOT shows briefly "Generating Flyby Porkchop Plot. Please wait..." but then nothing appears with the first leg selected, and scrolling to further legs brings up that dialog again apparently without ever completing. KSPTOT does not crash, but uses very low amounts of CPU power and has no impact on memory (monitored by Process Explorer).

Yeah, error management was something that didn't make it into the first pre-release. Try the next pre-release out and tell me if you experience the same issue.

8. The "Porkchop Plot Information" textbox on the right of the window is not updated.

I removed this because I didn't know what I wanted to do with it and it was taking a lot of screen space. I get a much bigger, better plot to look at now. Since that's the point of the application, I think it's warranted.

Should I say, I am actually thrilled by how fast you implemented that plot? The list above may seem to suggest there is still some work to do, but the amount already done is impressive .

Thanks, it's been fun! And speaking of fun, here's pre-release #2 of KSP TOT v1.1. Your feedback for the first pre-release was excellent, thank you. Additional feedback on the second pre-release would be much appreciated! Thanks!

[diomedea]

I take reference from the points # as numbered previously.

Happy about 1, 2 as implemented. Great .

About 3, Delta-V scales correctly now.

About 4, happy for the implementation. Would suggest to shrink the combo-box (too wide now to show just a percentage) and put some text like "Delta-V fraction" close to it.

About 5, changing waypoints in the table works (somehow it didn't for me with pre-release #1).

About 6. Yes, I believe that scrollbar is confusing. As a minimum, there is no need to have it spanning the whole X-axis, I would reduce the size, that will both free some space on the window and make the scrollbar appear untied to that X-axis.

About 7. I keep monitoring KSPTOT. It now shows RAM use when doing a multiple flyby, and it skyrockets. Good thing is now KSPTOT tells to have gone out of available RAM (probably that also happeded before, but silently). Then, reducing the number of points per axis allows to remain within the 4GB limit, and a plot is generated.

About 8, better so, the plot shows great! .

New things:

9. Also the entry box for the number of points to be plotted is too wide. At most, it would hold 3 digits, so I would reduce it and align it to the text line "Number of Points Per Axis", to be shortened a bit.

10. I would suggest to show a marker on each leg that ties in time with markers on previous and further legs. It would help to see, if I am interested in a specific point in time (possibly, because I spot a nice DV minimum on a leg), where my choice brings with the other legs, by showing markers at the appropriate time and duration on them.

For planning purposes, it may even to useful to have a possibility to mark different spots on a plot (so, a number of markers, maybe in different colors), so the user may check what each one would bring with the other legs.

11. A bit worried that sometimes data shown are less than correct. The plot below shows a Kerbin-Eve leg, all points have solutions with Delta-V less than 65 m/s (I notice the ejection burn for a Kerbin-Eve transfer requires > 1000 m/s). Note that V-inf boxes were not selected. If results are uncorrect, possibly V-inf should be always selected (not even de-selectable?).

I'd like also to show how good and significant plots can be generated now: this one really helps!

[Alphahelix]

Question about the license; what's the practical difference between a CC-BY-NC-ND license for software and "all rights reserved" but distributing it freely (as in beer)? If I can't modify the source code at all, why include it? Creative Commons licences are discouraged for software by Creative Commons because they don't have any software concepts built into them. I could build another program that links into yours, using the same source (without internal modifications) but modify the output to bypass the "No Derivatives" restriction.

Anyways, would you consider licensing the code with a more permissive, software-oriented license?

[Arrowstar]

About 6. Yes, I believe that scrollbar is confusing. As a minimum, there is no need to have it spanning the whole X-axis, I would reduce the size, that will both free some space on the window and make the scrollbar appear untied to that X-axis.

Okay, I've altered this a bit. The scrollbar is now directly to the left of the compute button, the size is half of previous, and the plot has been resized to fit the available space. I think it works better this way, but I'm curious to know what you think.

9. Also the entry box for the number of points to be plotted is too wide. At most, it would hold 3 digits, so I would reduce it and align it to the text line "Number of Points Per Axis", to be shortened a bit.

Fixed. I also added another box for "number of contour levels" so you adjust that in your plots, too.

10. I would suggest to show a marker on each leg that ties in time with markers on previous and further legs. It would help to see, if I am interested in a specific point in time (possibly, because I spot a nice DV minimum on a leg), where my choice brings with the other legs, by showing markers at the appropriate time and duration on them.

For planning purposes, it may even to useful to have a possibility to mark different spots on a plot (so, a number of markers, maybe in different colors), so the user may check what each one would bring with the other legs.

So adding a point marker doesn't make sense because the solutions are generated for every combination of points possible. Thus a point marker on one plot would actually cover a line on another plot (corresponding to the departure UT). So that's what I implemented. You right click the plot to bring up the context menu, select "add marker line", click where you want on the plot, and you get a vertical line corresponding to the Departure UT you selected. You can add as many as you want and you can clear them with the second option in the plot context menu.

Let me know what you think.

11. A bit worried that sometimes data shown are less than correct. The plot below shows a Kerbin-Eve leg, all points have solutions with Delta-V less than 65 m/s (I notice the ejection burn for a Kerbin-Eve transfer requires > 1000 m/s). Note that V-inf boxes were not selected. If results are uncorrect, possibly V-inf should be always selected (not even de-selectable?).

Arrival and departure v-inf are only factored in if you explicitly tell the code you want them factored in. The values you see are (probably ) correct. Small values just mean that the flyby dv required for that particular trajectory is small. This is a good thing! It doesn't imply an error in the calculation, necessarily. Now, if you check the departure v_inf box and you still get small values, then we have a problem.

I would rather give users the choice to select or deselect the boxes, since what they're after when using the application may differ from time to time.

Question about the license; what's the practical difference between a CC-BY-NC-ND license for software and "all rights reserved" but distributing it freely (as in beer)? If I can't modify the source code at all, why include it? Creative Commons licences are discouraged for software by Creative Commons because they don't have any software concepts built into them. I could build another program that links into yours, using the same source (without internal modifications) but modify the output to bypass the "No Derivatives" restriction.

Anyways, would you consider licensing the code with a more permissive, software-oriented license?

I release the source code because the rules of the forum dictate that I must release the source code or I cannot distribute the application. Trust me, I'd rather not distribute the source code at all, much less headache packing up new releases. As for what's stopping you? Hopefully personal integrity, and that's about it. I can't police the whole internet of course...

To answer the second question, no, I'd rather not release under a more open license. In fact, I'm somewhat regretting not going to "all rights reserved" in the first place because it would definitely protect what I'm hoping to avoid most: people modifying the source code and then coming to me with questions when things don't work. KSP TOT is complicated and has lots of moving parts. My coding style has changed and improved over the past few years as well. To be honest, even I have to relearn how I did things back in the day. The application is so large that keeping it all in my head is no longer feasible. I couldn't imagine trying to wade into the source code at this point, having no previous exposure to it...

Edited June 15, 2014 by Arrowstar

[Arrowstar]

KSP TOT v1.1 pre-release 3 is now out. Changes basically include diomedea's change suggestions.

[diomedea]

Keeping reference to the item # previously established.

6. Scrollbar: much better now (only thing, a user must already know its function, as there is no label about it: possibly a popup giving a tip?).

9. Perfect. Also the contour levels number works great .

10. I should have better explained. The marker lines work, but keep track of just the departure date: if that's day 161, the line is found at date=161 on each leg now. But if I select a specific point with the first leg, I'm taking both a departure date and flight time; then the marker with the next leg should be placed at the date= departure+flight time, that is when the encounter occurs. And if the solution is unique (I mean, with selecting the specific point on the first leg, I am actually choosing one specific solution with all the legs involved in the trip), then also the flight time with the second leg is selected, so it would show as a single point on that leg. And so on, unless some trips allow multiple solutions: in that case the user may have to be offered the option of choosing which. Can't say if it could be done entirely, however.

11. Sure there is something I am missing here. I expect information from the flyby porkchop plot to have some resemblance with the transfer porkchop of KSPTOT. However, V-inf choice only exist for the first, while departure DV is used for the second (then perfected with knowledge of initial orbit parameters). I expect V-inf to tell me what speed my ship goes outside the SoI (at infinity actually), so if I include departure V-Inf I should get the whole speed I should have for both exiting SoI and the planetary transfer (no departure burn actually, but MFMS gives that nicely). I expect to find help from the plot to choose when best to depart (and to arrive), and that includes leaving SoI. I may be totally wrong, but if Delta-V shown was only the planetary transfer part (under the Sun influence alone) that may explain why the plot appears quite flat (when no V-inf is selected). It may mean something to others, but a flat plot means less than I like to me, and therefore my preference for including V-inf.

Edited June 15, 2014 by diomedea

[Arrowstar]

10. I should have better explained. The marker lines work, but keep track of just the departure date: if that's day 161, the line is found at date=161 on each leg now. But if I select a specific point with the first leg, I'm taking both a departure date and flight time; then the marker with the next leg should be placed at the date= departure+flight time, that is when the encounter occurs. And if the solution is unique (I mean, with selecting the specific point on the first leg, I am actually choosing one specific solution with all the legs involved in the trip), then also the flight time with the second leg is selected, so it would show as a single point on that leg. And so on, unless some trips allow multiple solutions: in that case the user may have to be offered the option of choosing which. Can't say if it could be done entirely, however.

Ah. I think there may be a slight misunderstanding of how the porkchop plot grid is generated. Let me illustrate by example. Assume I have a three waypoint trajectory. Along each axis I want three points. (Three points, three axes gives 3^3 = 27 points total.)

My possible departure times are: 1, 2, 3

My possible leg 1 flight times are: 4, 5, 6

My possible leg 2 flight times are: 7, 8, 9

The first thing my code does is find all possible combinations of those values, and this is where the RAM usage gets pretty crazy. Anyway, all possible combinations of those points are (according to my code):

     1     4     7
     2     4     7
     3     4     7
     1     5     7
     2     5     7
     3     5     7
     1     6     7
     2     6     7
     3     6     7
     1     4     8
     2     4     8
     3     4     8
     1     5     8
     2     5     8
     3     5     8
     1     6     8
     2     6     8
     3     6     8
     1     4     9
     2     4     9
     3     4     9
     1     5     9
     2     5     9
     3     5     9
     1     6     9
     2     6     9
     3     6     9

Now, let's assume we want to place a marker at departure time 2 and leg 1 flight time 6. What solutions does this leave us? These:

     2     6     7
     2     6     8
     2     6     9

But that's every possible value for the leg 2 flight time! So the "marker" has to be a line with terminal points (2, 7) and (2, 9) because when you go to the leg 2 flight time plot, all you're going to see are the departure UTs again.

Does any of that make sense? It's a hard concept for me to explain, and I'm hoping this gets the main idea across. Please let me know if it's still unclear, or if I'm completely misunderstanding you and there's a better way to do what you're suggesting.

11. Sure there is something I am missing here. I expect information from the flyby porkchop plot to have some resemblance with the transfer porkchop of KSPTOT. However, V-inf choice only exist for the first, while departure DV is used for the second (then perfected with knowledge of initial orbit parameters). I expect V-inf to tell me what speed my ship goes outside the SoI (at infinity actually), so if I include departure V-Inf I should get the whole speed I should have for both exiting SoI and the planetary transfer (no departure burn actually, but MFMS gives that nicely). I expect to find help from the plot to choose when best to depart (and to arrive), and that includes leaving SoI. I may be totally wrong, but if Delta-V shown was only the planetary transfer part (under the Sun influence alone) that may explain why the plot appears quite flat (when no V-inf is selected). It may mean something to others, but a flat plot means less than I like to me, and therefore my preference for including V-inf.

Ah, so another misunderstanding, I'm afraid. The delta-v that gets plotted is not the delta-v for the leg you're viewing, because that's actually impossible to simplify down (the dv for one leg depends on the trajectory of legs before and after it). It is instead the total mission delta-v across all legs. If you add the departure or arrival v_inf in there, then it gets added to that total mission delta-v and that become the new total mission delta-v. So really, every plot is the same data, but I just organize it differently. Also, where multiple solutions exist for the current leg being plotted (our 2-6-7, 2-6-8, 2-6-9 cases above), I take the minimum dv of the multiple solutions.

To be honest, even if I could show per-leg delta-v, I think I'd still show the total mission delta-v. It lets you see how changing the flight time in one leg changes the delta-v across the whole mission, which I think is invaluable.

I'd definitely like to hear your comments on all this. Am I way off the proverbial mark? Were you hoping to see something? Please do let me know.

[diomedea]

Fine. Thanks for shading light on that. It's just the way data are shown, it was written it was Total Delta-V for the trip but I figured the axis were meant for only the selected leg - so I expected a marker to mean something specific to a leg, and that had to be in match for the other legs. If my choice was the point @ 2,6 on the first leg, I had the idea to be selecting a specific flight time with that leg, so the start point on the next leg was fixed. But if the plot on leg 2 if the same range of solutions, just shown differently, then clearly the choice is unique for all legs at the same time. Useful anyway to have the markers.

Unfortunately, I still must include V-inf for the plots to make sense to me. I accept what is shown is Total DV, but again when a plot is almost flat with values less than 65 m/s for a flyby, those values make me wonder what I'm reading. If I use the MFMS to compute the same flyby, it finds a single solution that requires some thousand m/s. The flyby plot has no correct data about the starting orbit, but still I would expect something more closely related to that MFMS solution (actually, I would expect to find that solution and no better one in the range of dates used by the MFMS, but similar solutions at regular intervals of dates due to synodic periods matches).

I fully agree about showing Total Delta-V. The plot allows to choose a best solution in a range of dates when you need to make that trip, and to see how the solution gets better or worse with time, but the choice is because of Total Delta-V so that is the correct thing to show.

[Arrowstar]

Fine. Thanks for shading light on that. It's just the way data are shown, it was written it was Total Delta-V for the trip but I figured the axis were meant for only the selected leg - so I expected a marker to mean something specific to a leg, and that had to be in match for the other legs. If my choice was the point @ 2,6 on the first leg, I had the idea to be selecting a specific flight time with that leg, so the start point on the next leg was fixed. But if the plot on leg 2 if the same range of solutions, just shown differently, then clearly the choice is unique for all legs at the same time. Useful anyway to have the markers.

I definitely understand the confusion. Coming up with a good way to display the data based on the constraints I have w.r.t. MATLAB has been a real challenge. Is there anything I can do to either A) clarify the current approach of displaying the data or alter the current approach of displaying the data to improve clarity?

Unfortunately, I still must include V-inf for the plots to make sense to me. I accept what is shown is Total DV, but again when a plot is almost flat with values less than 65 m/s for a flyby, those values make me wonder what I'm reading. If I use the MFMS to compute the same flyby, it finds a single solution that requires some thousand m/s. The flyby plot has no correct data about the starting orbit, but still I would expect something more closely related to that MFMS solution (actually, I would expect to find that solution and no better one in the range of dates used by the MFMS, but similar solutions at regular intervals of dates due to synodic periods matches).

MFMS uses the following formula to compute delta-v for each solution it comes across:

dv = vInfDNorm + totDV + vInfANorm;

That is, the v_inf are already factored in there. This explains why you see much larger v_inf in MFMS than you do in the flyby pork chop plotter with the v_inf checkboxes unchecked: that cost simply isn't included in the plot. Now, I could simply make the departure v_inf checkbox permanently checked, or at least default it to that when the application starts if you think it would help. This would include that delta-v by default. I agree that the powered flyby delta-v only plots are not particularly useful most times and it really does make more sense to view the plot with departure v_inf included.

Thanks for all the great feedback!

[PlonioFludrasco]

I've just downloaded the last version of KSPTOT, and I was wondering if it's possible to plot a Duna cycler orbit with it. I've done some maths to calculate SMA, Ap and Pe of such orbit, and I'd like to know if there's a way to force the KSPTOT to compute an escape route from Kerbin that leads to a solar orbit with those parameters. After that, it could be only a matter of launch windows and optimization, right?

[diomedea]

I definitely understand the confusion. Coming up with a good way to display the data based on the constraints I have w.r.t. MATLAB has been a real challenge. Is there anything I can do to either A) clarify the current approach of displaying the data or alter the current approach of displaying the data to improve clarity?

Perhaps a simple text (or a tooltip) with both axis to remind the user the time displayed (departure date, time of flight) is always relative to the whole trip, while the title about the leg shown is only about the way solutions are displayed. Sure after figuring it, it becomes easy and natural, but I kept thinking each plot was showing dates relative to the specific leg. Wasn't for your help, I would not have figured it .

MFMS uses the following formula to compute delta-v for each solution it comes across:

dv = vInfDNorm + totDV + vInfANorm;

That is, the v_inf are already factored in there. This explains why you see much larger v_inf in MFMS than you do in the flyby pork chop plotter with the v_inf checkboxes unchecked: that cost simply isn't included in the plot. Now, I could simply make the departure v_inf checkbox permanently checked, or at least default it to that when the application starts if you think it would help. This would include that delta-v by default. I agree that the powered flyby delta-v only plots are not particularly useful most times and it really does make more sense to view the plot with departure v_inf included.

Sure some users (me first) are not astrodynamicists. Even knowing what V-inf is in hyperbolic orbits, to have it not included in a solution leaves me that "totDV" that is somehow less easy to figure (also, because thinking "Total", I figure all DV required for the trip is accounted). From what you wrote above, I have a sketchy idea this "totDV" is the amount obtained from all gravitational assists + all the burns done at flybys, leaving out the initial burn (ejection from the starting orbit) and the final burn (injection in the arrival orbit). If that was correct, this "totDV" value is golden, absolutely important to know. Just need to properly figure these values, then. No need to change how the V-inf selection boxes are managed once the concept is clear.

Thanks for explaining .

[Arrowstar]

I've just downloaded the last version of KSPTOT, and I was wondering if it's possible to plot a Duna cycler orbit with it. I've done some maths to calculate SMA, Ap and Pe of such orbit, and I'd like to know if there's a way to force the KSPTOT to compute an escape route from Kerbin that leads to a solar orbit with those parameters. After that, it could be only a matter of launch windows and optimization, right?

It certainly is! I would first use multi-flyby maneuver sequencer to figure out what a good Kerbin/Duna/Kerbin would look like. As soon as you know the approximate trajectory based on that, go into Mission Architect and use it to refine the trajectory based on real SoI transitions and the like.

Let me know if you need/want help with any of this. I know it can be a bit complicated, but I'm happy to teach.

Perhaps a simple text (or a tooltip) with both axis to remind the user the time displayed (departure date, time of flight) is always relative to the whole trip, while the title about the leg shown is only about the way solutions are displayed. Sure after figuring it, it becomes easy and natural, but I kept thinking each plot was showing dates relative to the specific leg. Wasn't for your help, I would not have figured it .

These are good suggestions. I'll see about implementing them tonight. Might not be able to do everything as you said, but enough to get the point across.

Sure some users (me first) are not astrodynamicists. Even knowing what V-inf is in hyperbolic orbits, to have it not included in a solution leaves me that "totDV" that is somehow less easy to figure (also, because thinking "Total", I figure all DV required for the trip is accounted). From what you wrote above, I have a sketchy idea this "totDV" is the amount obtained from all gravitational assists + all the burns done at flybys, leaving out the initial burn (ejection from the starting orbit) and the final burn (injection in the arrival orbit). If that was correct, this "totDV" value is golden, absolutely important to know. Just need to properly figure these values, then. No need to change how the V-inf selection boxes are managed once the concept is clear.

Thanks for explaining .

I'm going to do two things:

1) Put in a tooltip in the plot window that describes what kind of delta-v is being shown, and

2) Make departure v_inf checked by default.

Oh, to be clear on one thing, the delta-v shown when both v_inf boxes are unchecked is just the delta-v that the spacecraft engine had to provide to make the flyby. The amount of sun-relative delta-v picked up by the planet could be much, much larger. I don't compute or use it in any calculations though because we get that delta-v for "free" just by swinging around the planet in question.

---

Hey, also everyone, just wanted to show off something cool which is coming in the next version. I requisitioned on Reddit a logo for KSP TOT! It's going to be used in a new splash screen and Help -> About menu item. It looks kinda like this.

I'm still working with the artist a bit and we're not quite done yet, but this should more or less be its final form. Cool, no?

[Arrowstar]

Hi all,

KSP TOT v.1.1.0 pre-release 4 is officially up. Changes in this pre-release include:

1) Updates to the flyby porkchop plotter tooltip text that hopefully better explains what is being viewed

2) Updates to the multi-flyby maneuver sequencer to allow it to accept only two waypoints, thus becoming yet another way to find ballistic trajectories from A to B

3) Updates to the multi-flyby maneuver sequencer that allow users to specify bounds on flight time for all legs, similar to what's in the flyby porkchop plotter

4) A splash screen and KSP TOT logo that appears on start up for a short moment

5) A few little minor fixes in MFMS

Please let me know what you think!

[diomedea]

Great improvements, as always . Comments time.

1. My first thought, one can't have too many tooltips: moar tips (so to cover most significant objects shown in the plot window). My second thought (scratch the first), tips can not always be that good: the datatip at the cursor position is nice to show actual data, not so much if keeps displaying what that data means (after twice, users know that). My suggestion would be to put that tip (about the Delta-V shown) with the Delta-V scale, if possible.

2. Nice. And of course now one has to try both the normal transfer plot and the MFMS for ballistic trajectories. And wonder why results are not the same. Then check again, find what was left out, correct the entries. Then marvel at the accuracy while both tools show exactly the same .

3. Very useful those bounds in Flight Time also for MFMS.

4. Nice touch. Beyond the content, now KSPTOT also has the appearance of a professional tool (let me add, thanks for the mention, too kind ).

[Arrowstar]

Thanks for the comments! I'll make the change to the data tip string tonight. After that, do you see anything that would bar a formal release? The new code is feeling pretty solid to me.

[diomedea]

Nothing at all to hold this masterpiece from being released , and allow all interested users (even ones wary of beta or pre-releases) to enjoy.

[Mr Shifty]

I haven't visited this tool in several months. Looks like a bunch of new and very useful features. I love the Kerbin-to-Laythe tutorial. I'll check out the pre-release tonight and try to have comments for you.