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

[curiousepic]

Sorry, to clarify, I meant for a landing at the destination and a meaningful amount of time on the surface, but not being stuck there for years.

[Arrowstar]

Sorry, no, that functionality doesn't exist.

[Kimberly]

Sorry, no, that functionality doesn't exist.

Sounds like it would be very useful, though. Basically asking when/how a launch to a body should be scheduled so that, upon arrival, a return window from that body exists. (If we make the fair assumption that landing and surface activity take a negligible amount of time.)

[Drew Kerman]

How would one optimize for minimization of duration of stay at a destination before a good return window?

Unless I'm missing something this is easy enough:

Step 1 - use the TOT to decide when would be best to head from Kerbin to wherever you want to go.

Step 2 - take the time of your arrival and plug it back in to TOT with Kerbin as the destination and search for the optimal time to head back

Step 3 - whatever time you have between arrival and optimal return is also your optimal time of stay

[Arrowstar]

Unless I'm missing something this is easy enough:

Step 1 - use the TOT to decide when would be best to head from Kerbin to wherever you want to go.

Step 2 - take the time of your arrival and plug it back in to TOT with Kerbin as the destination and search for the optimal time to head back

Step 3 - whatever time you have between arrival and optimal return is also your optimal time of stay

Pretty much this, yes.

[Arrowstar]

Hey everyone, just wanted to share a sneak peak of my next Mission Architect addition. Tell me what you think.

[Drew Kerman]

so is that a way to do this? (among other things perhaps)

I don't see a field for time though, so I'm a bit unclear as to what's being analyzed. Hrm maybe it will give you a whole report on when the active vessel can see the target over a period of... wait, there's still no time field. Oh, perhaps it's over the period of the currently defined mission?

w00t midnight post

[Arrowstar]

Kind of. It's really a way to not have to run the line of sight calculations for each "other spacecraft" against your spacecraft manually. It also allows you to run LoS calculations between "other spacecraft," and because the code underlying the comm path calculations is pretty smart, it can figure out the multiple hops in your comm network to get a signal from point A to point B.

Basically the idea is to tell the application what your communication network is made up of and tell it where you want to be able to transmit signals from and to (points A and B, we'll call them). The code then does the analysis and each time step to figure out A) if a path from A to B exists, and what that path is. It's doing what RemoteTech does for you in real KSP, and I'm actually writing this with RemoteTech in mind. Does that make any sense?

You're right, though, I do need start/stop UT boxes like I have for Graphical Analysis. I'll add those tonight.

[Drew Kerman]

You're right, though, I do need start/stop UT boxes like I have for Graphical Analysis. I'll add those tonight.

Yea that missing was the only thing that confused me. Otherwise, makes perfect sense and sounds really cool! I'm sure the RT2 crowd will be thrilled

[diomedea]

Kind of. It's really a way to not have to run the line of sight calculations for each "other spacecraft" against your spacecraft manually. It also allows you to run LoS calculations between "other spacecraft," and because the code underlying the comm path calculations is pretty smart, it can figure out the multiple hops in your comm network to get a signal from point A to point B.

Basically the idea is to tell the application what your communication network is made up of and tell it where you want to be able to transmit signals from and to (points A and B, we'll call them). The code then does the analysis and each time step to figure out A) if a path from A to B exists, and what that path is. It's doing what RemoteTech does for you in real KSP, and I'm actually writing this with RemoteTech in mind. Does that make any sense?

You're right, though, I do need start/stop UT boxes like I have for Graphical Analysis. I'll add those tonight.

As a RT user, I'm certainly interested. Hope the feature will include total distance of each couple of nodes along the path with time (kind of that graphical analysis Gaiiden showed), as RT makes links active only when distance is less than the maximum range, defined by both the antennae in the link. Actually the range could be based either on "standard" model (link range = Min (r1, r2)) or the "root range" model (link range = Min (r1, r2) + √(r1*r2), eventually corrected by RangeMultiplier). Would be great if that analysis tool showed the actual range against the maximum possible range for each single link (could be shown as a % of the max link range), and even output a warning in Mission Architect when no valid link is found (and particularly if this lack of a valid link happens while a burn is planned).

[Arrowstar]

as RT makes links active only when distance is less than the maximum range, defined by both the antennae in the link. Actually the range could be based either on "standard" model (link range = Min (r1, r2)) or the "root range" model (link range = Min (r1, r2) + √(r1*r2), eventually corrected by RangeMultiplier).

So you're saying that RT only shows a link valid when the range between nodes is less than the maximum range for both antenna? Or just the transmitting antenna?

I don't understand your comments and equations about link range. Why isn't the link range just the distance between both vehicles?

Would be great if that analysis tool showed the actual range against the maximum possible range for each single link (could be shown as a % of the max link range), and even output a warning in Mission Architect when no valid link is found (and particularly if this lack of a valid link happens while a burn is planned).

Because this analysis takes a nontrivial amount of time to run, it will not be run in parallel with the mission script propagation engine. Instead think of this as a kind of graphical analysis tool for a very particular purpose. In any event, because it's not running with the propagation engine, it can't issue errors in MA's main window. Sorry about that.

But yes, output will include the actual link range for each step, as well as the total. I can include the percent of max range for each hop as well. Good suggestion.

[diomedea]

So you're saying that RT only shows a link valid when the range between nodes is less than the maximum range for both antenna? Or just the transmitting antenna?

I don't understand your comments and equations about link range. Why isn't the link range just the distance between both vehicles?

Sure, RT shows valid link only when distance is less than the maximum allowed. As shown above, RT uses two alternative models to compute maximum range for a link, in both cases both antennae are considered. Those equations are also shown in the RT page (the function are simply the minimum of the two values for antennae ranges, and the square root of the product of the same), and here I'm not talking about the distance between both vehicles (the current range) but the maximum link range, as the link in RT is only valid when the current range is less than the maximum.

Because this analysis takes a nontrivial amount of time to run, it will not be run in parallel with the mission script propagation engine. Instead think of this as a kind of graphical analysis tool for a very particular purpose. In any event, because it's not running with the propagation engine, it can't issue errors in MA's main window. Sorry about that.

But yes, output will include the actual link range for each step, as well as the total. I can include the percent of max range for each hop as well. Good suggestion.

Great .

[Arrowstar]

Okay got it. And which max link range model does RT use in which cases? Or is it uses defined? Any idea how all of that works? :-)

[diomedea]

Okay got it. And which max link range model does RT use in which cases? Or is it uses defined? Any idea how all of that works? :-)

The model used in RT depends on the "RangeModelType" setting, in the RemoteTech_Settings.cfg (of course within the RT folder). It can be set to "standard" (the default one), "additive" or "root" (both for the root model). So, it is up to the user to select the model he likes. Also, the "RangeMultiplier" setting is used in conjunction with the above (=1 by default, should be changed to = 0.5 when using the root model).

[Arrowstar]

The model used in RT depends on the "RangeModelType" setting, in the RemoteTech_Settings.cfg (of course within the RT folder). It can be set to "standard" (the default one), "additive" or "root" (both for the root model). So, it is up to the user to select the model he likes. Also, the "RangeMultiplier" setting is used in conjunction with the above (=1 by default, should be changed to = 0.5 when using the root model).

Okay thanks. And is the actual link range equal to RangeMultiplier * computed link range then?

[diomedea]

Okay thanks. And is the actual link range equal to RangeMultiplier * computed link range then?

Exactly .

[Arrowstar]

Cool. If all goes well tonight, expect a working prototype build to show up here this evening. :-)

[Arrowstar]

Hey guys,

Here's the v1.4.0 pre-release with the new Comm Network Analysis tool in Mission Architect.

https://dl.dropboxusercontent.com/u/29126891/KSPTOT_v140_prerelease1.zip

To use this, open Mission Architect and then go to Tools -> Comm Network Analysis. Note that you need to set the comm antenna range for each station, other spacecraft, and your vessel prior to opening this menu (they default to Inf range). Edit these in their respective menus under Spacecraft menu.

Please let me know if you have any questions or find any bugs. Thanks!

[Drew Kerman]

Can anyone post some screens of what the analysis looks like? I'm unable to play with this until I get home Sunday evening

[diomedea]

Computing the network path is very time consuming currently, even a modest scenario with a few nodes takes several minutes. The one below (based on a simple Kerbin-Mun-Kerbin flight), made with 4 crafts (network nodes) beyond the current spacecraft and KSC, required about 450s to be output on my machine (that is not precisely slow, quad-core i7 @3.4GHz, 64bit). However I accept this feature requires time, and I am pleased of the result:

I am certainly not (yet) an expert using the graphical analysis tools with KSPTOT. Anyway, the different graphs are quite telling. Few things however I would like to suggest:

1) the first graph is only about existence or not of a valid path (boolean answer). In itself is difficult to read (vertical bars show transitions, but nothing tells the state between those). This graph is not really needed however while the state is readable from the third graph (number of hops).

2) the second graph (Total Path Distance) has the bottom at a negative distance (something that always makes me wander about fractal dimensions in hyperspace)... makes easy to read when the distance is zero, but actually zero distance is lack of a valid path. Indeed to me, the 4th graph (Largest Hop Distance) has that right.

3) the third graph (Number of Hops) shows -1 for when no valid path exists. To me, negative hops is even more subtle than negative distance. I would consider the graph to start at 0 (just let the negative part go outside the chart).

Another thing I would like to see, is some color-coding on the charts showing what nodes are active with a path. However, I'm out of ideas now. A rough thing could be to make a chart with all the possible nodes on the y axis, and showing colored horizontal lines in time when those nodes take part with any hop. But, I'd also like to have the actual hops shown (kind of vertical lines connecting the two nodes in each active hop). I'd actually have this kind of chart instead of the first graph shown.

All in all, very pleased to see this functionality. It works nicely, allows to enter and correctly use info about the range model. Another great improvement .

[Arrowstar]

Computing the network path is very time consuming currently, even a modest scenario with a few nodes takes several minutes. The one below (based on a simple Kerbin-Mun-Kerbin flight), made with 4 crafts (network nodes) beyond the current spacecraft and KSC, required about 450s to be output on my machine (that is not precisely slow, quad-core i7 @3.4GHz, 64bit). However I accept this feature requires time, and I am pleased of the result:

The code can take some time, yes. It's solving a shortest path problem at every time step in order to determine the "best" comm path, so it goes without saying that some non-trivial CPU time is required to perform this analysis. My suggestion is to change the number of state log entries per coast event to something around 100 when you perform the analysis, and then reset to whatever higher number you were using before. Lowering the number of state log entries will reduce the analysis execution time proportionally. Script -> Execution Settings -> Set Num. State Log Entries Per Coast...

I am certainly not (yet) an expert using the graphical analysis tools with KSPTOT. Anyway, the different graphs are quite telling. Few things however I would like to suggest:

1) the first graph is only about existence or not of a valid path (boolean answer). In itself is difficult to read (vertical bars show transitions, but nothing tells the state between those). This graph is not really needed however while the state is readable from the third graph (number of hops).

2) the second graph (Total Path Distance) has the bottom at a negative distance (something that always makes me wander about fractal dimensions in hyperspace)... makes easy to read when the distance is zero, but actually zero distance is lack of a valid path. Indeed to me, the 4th graph (Largest Hop Distance) has that right.

3) the third graph (Number of Hops) shows -1 for when no valid path exists. To me, negative hops is even more subtle than negative distance. I would consider the graph to start at 0 (just let the negative part go outside the chart).

Thanks for the suggestions!

1) I've eliminated this graph because I agree it's not necessary. Good call.

2) I believe I've corrected the issue and set the minimum to zero if the graph would otherwise go negative.

3) I've corrected the issue and set the num hops to 0 when their is no valid path.

Another thing I would like to see, is some color-coding on the charts showing what nodes are active with a path. However, I'm out of ideas now. A rough thing could be to make a chart with all the possible nodes on the y axis, and showing colored horizontal lines in time when those nodes take part with any hop. But, I'd also like to have the actual hops shown (kind of vertical lines connecting the two nodes in each active hop). I'd actually have this kind of chart instead of the first graph shown.

I've tried to implement this idea but it's tricky. I could only do the horizontal lines, but those were a good idea. Color coding is not out of the question but does ruin the look of the graph, IMHO. Here's an update of what things look like now.

Could I get your MAT file to test with?

All in all, very pleased to see this functionality. It works nicely, allows to enter and correctly use info about the range model. Another great improvement .

Glad you like it! Thanks for the feedback. I'll put out another pre-release version tonight with these and other changes you suggest before then.

[diomedea]

...

Lowering the number of state log entries will reduce the analysis execution time proportionally. Script -> Execution Settings -> Set Num. State Log Entries Per Coast...

Thanks for that .

...

I've tried to implement this idea but it's tricky. I could only do the horizontal lines, but those were a good idea. Color coding is not out of the question but does ruin the look of the graph, IMHO. Here's an update of what things look like now.

Yes, I see and like the improvements. Color isn't really needed, though I was thinking to have it match the 3-D views or analysis charts with those crafts.

Could I get your MAT file to test with?

It's actually very simple (as I used the default Munar mission file and only added a bit with communication crafts/equipment), so simple I didn't think to save it and had to create a similar one to share (here).

[Arrowstar]

Okay, thanks! Here's an updated build with all the new features:

https://dl.dropboxusercontent.com/u/29126891/KSPTOT_v140_prerelease2.zip

Let me know how that works for you.

Btw, comments/thoughts/suggestions on the CSV output?

[diomedea]

Okay, thanks! Here's an updated build with all the new features:

https://dl.dropboxusercontent.com/u/29126891/KSPTOT_v140_prerelease2.zip

Let me know how that works for you.

Btw, comments/thoughts/suggestions on the CSV output?

The updated build is amazing. Those charts really are effective!

Anyway, I may have spotted one issue. It shows pretty well on the fourth chart, in the time interval 1.9 - 3.1*10^4 s. That is the time when SoI is switched from Kerbin to Mun in my MAT file. Distance shows to be computed from Mun, instead of being about the longest hop (longest hop should always be about the distance Kerbin-Mun, as the crafts orbiting them remain in proximity of the respective body).

CSV works great. Other data could turn useful to play with RT, but isn't really that simple to handle. I'll talk a bit below of something about RT, but have not clear currently what could be made in the CSV to help players there.

I've till now focussed on link distance, which is a very well defined limit in RT. But certainly one problem is how to ensure time-above-horizon with communication satellites. The easy and most used answer is to use a stationary orbit (1:1 period with the orbited body), but highly elliptic orbits are also used (like 2:1 Molniya orbit) (thence the time-above-horizon). Or, quite easily, use a constellation of satellites on a same orbit. I have sometimes dealt with computing the angle to the horizon (at KSC) for specific orbiting crafts, as a value to be met for establishing links.

A more serious problem players face is with programming the use of dish antennae with each craft: dishes point at other crafts or at planets, and have a limited visibility cone. If too close, the cone would be too thin to cover a whole planet, or the orbits around a planet followed by other crafts to be linked with. So, if beyond the maximum distance is a limit for the hop, being too close would make for only intermittent coverage (unless the dish can be kept pointed at all times at just one craft, instead of using its cone to cover the area around a planet). The bane of RT players is generally with probes that can't be controlled once without a path towards a control station (like KSC), so antennae on them cannot be redirected to reestablish a link towards another node if the one they were pointed at "disappeared" (eclipsed, destroyed, out of EC).

Also, each craft can have multiple antennae, each one generally programmed to cover one specific link. Clearly crafts built to act as communication relays have to keep those dish antennae correctly oriented at all times. Now, each antenna has different maximum range and cone, so an improvement would be to model all those antennae. But this may prove excessive, adding a check about the cone coverage of each antenna would probably take too long to compute to be useful.

Indeed, I may have to think more about what could turn useful in the CSV. What's above may hint at something but could be too much work.

[Arrowstar]

So I downloaded your MAT file and ran it but I didn't get the same plot. Can you provide me with an updated MAT file that provides the you have above?

My plot:

In order to provide "time above horizon" I can add what we in the business call "elevation angle" to Graphical Analysis. This would take the selected ground station and compute its angle from the horizon. Positive is above the horizon, negative below. This doesn't solve the problem of actually developing the best constellation for comm relay purposes but it does give you another tool to help figure it out.

A more serious problem players face is with programming the use of dish antennae with each craft: dishes point at other crafts or at planets, and have a limited visibility cone. If too close, the cone would be too thin to cover a whole planet, or the orbits around a planet followed by other crafts to be linked with. So, if beyond the maximum distance is a limit for the hop, being too close would make for only intermittent coverage (unless the dish can be kept pointed at all times at just one craft, instead of using its cone to cover the area around a planet). The bane of RT players is generally with probes that can't be controlled once without a path towards a control station (like KSC), so antennae on them cannot be redirected to reestablish a link towards another node if the one they were pointed at "disappeared" (eclipsed, destroyed, out of EC).

Do the antennas actually point towards their targets? I thought it worked more like a fake pointing where you just told it to point at something and it "pointed" there (without actually having to move the spacecraft or antenna in the game).

But this may prove excessive, adding a check about the cone coverage of each antenna would probably take too long to compute to be useful.

I'm still not sure I understand exactly what's going on with the antenna in RT. However, since pointing is more of a spacecraft/antenna control problem, I'm not sure it falls under the problem my piece of code is trying to solve anyway. Unless you can think of how the existing MA infrastructure could be used to solve this problem? Like I said, I'm a bit confused still. Maybe draw a picture?