Jump to content

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


Recommended Posts

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?

Eh, my bad. The MAT file is that, but I took a shortcut and instead of changing all ranges to ensure coverage up to Mun, I run the network analysis with additive model and RangeMultiplier =1 (instead of 0.5).

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.

Elevation angle fits me perfectly (is exactly the name I use actually due to my studies in artillery, and sure is a useful value as I wrote above calling it "angle-to-the horizon" to make it more clear).

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).

The actual antennae on the crafts don't orient to the target in the current RT, but their orientation is simulated when the links are computed. Indeed they act as if slaved to a target (single craft or planetary body), staying oriented with it at all times. The original author of RT (JDP) let me know there was code in the original version to implement the orientation of the craft too, so it had to be actually rotated towards the target.

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? :)

Your code is helpful to show when and where a problem will arise, but sure can't also look at the actual control of the antennae on crafts: if mismanaged, those will actually create more problems (like links dropped when a dish is pointed to another target). I could show pictures of how a communication infrastructure works in RT, but those would probably be even more confusing. If you like to have a look, believe the RT Player's guide is really useful to show the basics.

Link to comment
Share on other sites

All good and nice about the elevation angle, seems working perfectly fine here, and I'm linking a pic showing it (with altitude too):

Sx09S4q.png

And now, that lets me know what could be the cause for another possible issue: this is the network analysis after prerelease 3 (but same with prerelease 4), where the issue from SoI transition changing max Hop distance was already corrected:

gJVl5pb.png

I'd like now to put the attention to those spikes in "Total Path Distance" and "Longest Hop Distance" @ 0.15 and 4.95 *10^4 s. By comparing against the graphical analysis charts above, those are synced with the periods the spacecraft went below the horizon (at KSC), before initial burn and after the final injection burn. With the spacecraft unable to have a direct LOS to KSC, the network analysis found another path... that involved a hop to one of the crafts orbiting Mun and from there back to KSC. This is what actually happens in RT too, and shows all too well how good this tool can be :cool:.

Link to comment
Share on other sites

Diomeda I'm a bit confused that you mentioned a possible issue but I'm not sure what that is from your post

suggestion for new graph - transmission time delay in seconds (round trip would make the most sense here I think). Sry that it ruins the nice 4-way split :P note that RT2 by default uses a rounded value for speed of light, but if KSPTOT used the precise SoL value it wouldn't make a huge diff in the stock Kerbin system (or make it configurable in the program options)

Edited by Gaiiden
Link to comment
Share on other sites

Diomeda I'm a bit confused that you mentioned a possible issue but I'm not sure what that is from your post

oh, sorry if what I put above made it confusing. Those spikes close to the start and end time visible in the graphs on the right could be seen as a mistake while the spacecraft is still close to KSC (as shows in the first, altitude graph). However those are correct when it is seen they match with the elevation angle from KSC, so that the path goes to include a hop to a probe in munar orbit and another from there back to KSC. It is a situation well known when playing with RT, but could not have been understandable otherwise.

suggestion for new graph - transmission time delay in seconds (round trip would make the most sense here I think). Sry that it ruins the nice 4-way split :P note that RT2 by default uses a rounded value for speed of light, but if KSPTOT used the precise SoL value it wouldn't make a huge diff in the stock Kerbin system (or make it configurable in the program options)

Actually, there is no need for one further graph. Transmission time delay (another well known thing in RT) is = Total Path Distance (already on the second graph) divided by speedlight. Being speedlight a constant, the graph would be exactly the same. However could be worth to add another scale (to the right of the graph?) giving delay in seconds.

Link to comment
Share on other sites

oh, sorry if what I put above made it confusing. Those spikes close to the start and end time visible in the graphs on the right could be seen as a mistake while the spacecraft is still close to KSC (as shows in the first, altitude graph). However those are correct when it is seen they match with the elevation angle from KSC, so that the path goes to include a hop to a probe in munar orbit and another from there back to KSC. It is a situation well known when playing with RT, but could not have been understandable otherwise.

ah, possible user confusion. I get it

Actually, there is no need for one further graph. Transmission time delay (another well known thing in RT) is = Total Path Distance (already on the second graph) divided by speedlight. Being speedlight a constant, the graph would be exactly the same. However could be worth to add another scale (to the right of the graph?) giving delay in seconds.

Ah, that's true. Then yea someway of also showing time delay via that graph would be good. Just because it's another prominently displayed RT2 feature in the game ppl may look for and not intuit from path distance (like I didn't - derp)

Link to comment
Share on other sites

So okay, there's been some conversation while I've been out of town. So summarize: Are there any outstanding issues I need to resolve for me to go ahead with a fairly stable 1.4.0 release?

My only suggestion was to include a Signal Delay graph for time in seconds to complete a transmission, but Diomeda pointed out it's just the speed of light divided by the hop distance so you can get it second-hand easily enough.

For the astrodynamics calculators, what is Ra/Rp?

Link to comment
Share on other sites

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.

Nice work! What kind of algorithm are you using to solve the shortest-paths?

-bk2w

Link to comment
Share on other sites

Nice work! What kind of algorithm are you using to solve the shortest-paths?

-bk2w

The code is using Dijkstra's algorithm for the path-finding. I have some experience with this type of algorithm before and it seems to do fine in this application as well :-)

Link to comment
Share on other sites

Hi everyone!

I'm pleased to announce the release of KSP Trajectory Optimization Tool v1.4.0. This is definitely a communications and RemoteTech oriented release! Here's the change log:

  • Added a Communications Network Analysis tool to Mission Architect. This feature allows you to assess communication node visibility, total comm path distance, and network node utilization.
  • Added a ground station elevation angle task to Mission Architect's Graphical Analysis tool. This is useful for assessing when comm spacecraft go below or rise above the horizon (and therefore become useful).
  • Added a series of astrodynamics calculators to Mission Architect's suite of tools.
  • One or two minor bug fixes here and there.

Download is in the OP as always. Let me know if you have any questions!

Link to comment
Share on other sites

This looks awesome, can't wait to play with it. If I'm running Outer Planets and have a few planets zipping around that aren't in the default game, can I simply modify bodies.ini with their correct orbital parameters or will that screw things up?

Link to comment
Share on other sites

If I'm running Outer Planets and have a few planets zipping around that aren't in the default game, can I simply modify bodies.ini with their correct orbital parameters or will that screw things up?

Actually, KSPTOT can create a bodies.ini file for you directly from KSP. Your best bet is to use the "File -> Create New Bodies File From KSP" menu on the main GUI. Make sure you have the KSPTOTConnect plugin installed first.

Let me know if you have any questions getting it to work.

Link to comment
Share on other sites

Hi!

I am trying to use the Transfer Planner to calculate a Transfer From Kerbin to Dres, and it "doesn't work" â„¢.

Here's what I did:

1. Install v1.4.0 of KSPTOT. (I suggest you put the version info in the "About" dialog)

2. Put the KSPTOTConnect Mod into GameData.

3. Edit -> Time System -> Use Kerbin Time

4. Edit -> Options ->

- Number of Points Per Axis

- Number of Optimization Iterations: 100

- Number of Synodic Periods to Plot: 1

- Maximum Delta-V to Plot: 10

- Optimizer Options: Departure+Arrival Delta V

5. Earliest Departure Time: Get UT from KSP, turns out to be 21498315.8742 (y 3, d144, ... in Kerbin Time)

6. Earliest Arrival Time to UT 27604800 (y4 d1)

7. Plot Datatype: Departure + Arrival Delta-V

8. Compute Porkchop Plot.

For Comparison, I use Alexmuns transfer tool:

- UNcheck no insertion burn

- Transfer Type Ballistic

- Earliest Departure y3,d144

- Source Orbit 140km, Target Orbit 50 km

So here is the first problem:

I get the lowest estimated Delta-V with 4219.8 m/s, while Alexmun's transfer planner gives me 3262 m/s. That's about 1000 m/s less!

Here's the two Porkchop plots for comparison

KSPTOT v1.4.0

XnbpYj9.png

http://alexmoon.github.io/ksp/

40UDgbv.png

Why is that? Why does KSPTOT give 1000 m/s more of dV? When I build a craft, those 1000 m/s make a huge difference in craft design and the launch costs go up exponentially.

Next Problem:

9. Compute Departure Burn

10. Right-Click on "Initial Elliptical Orbit Information (Kerbin)" -> Get from KSP (active vessel), The Orbit is now approx 140x140 with inc=0

11. Check "Use?" next to the Mean Anom./Epoch fields

12. Compute Departure Burn

Now the dV for the Departure burn matches alexmuns value almost exactly (1717 m/s). Then why did I get so much more before?

Question: Why is the Radial dV non-Zero? Shouldn't the radial component of the burn be set with the burn timing?

13. Right-Click in the "dV Maneuver Information": Upload Maneuver to KSP

The Maneuver is now Uploaded, but there's no encounter at all to Dres. Even if I mess around with the timing, I don't get an encounter.

Unmodified uploaded Maneuver

oXeH56K.png

Closest approach with timing-modified Maneuver

RshNk31.png

So what's up with that? Why don't I get an encounter if I upload a pre-calculated burn maneuver?

From multiple tries, I know that if you punch in the numbers from Alexmuns transfer window planner, I almost always get an encounter.

Edited by Kobymaru
Link to comment
Share on other sites

Why is that? Why does KSPTOT give 1000 m/s more of dV? When I build a craft, those 1000 m/s make a huge difference in craft design and the launch costs go up exponentially.

It's probably due to the fact that you can't input an insertion orbit target like you can in Alexmun's transfer planner. Your insertion Dv will vary widely depending on whether you want to capture into a low or high orbit, not to mention your inclination, so KSPTOT is giving you a best-guess estimate - you'll note that it does in fact say "Est. Delta-v". Furthermore KSPTOT expects you to then take the values from the porkchop plot and actually design a mission with the Mission Architect, so the porkchop is where you start your mission planning, but not where you get your final maneuver information from, our your actual Dv requirements

Why don't I get an encounter if I upload a pre-calculated burn maneuver?

Dres is a very small target for interplanetary travel, and like I said the departure burn you get from the porkchop plot may not be as accurate as it should be to hit it. But still, you should trust Mission Architect over what the game tells you. Load your flight plan into Mission Architect and see if that gives you an SOI hit. I've flown craft just to Minmus from Kerbin and although KSP's map view showed I had no intercept coming up with Minmus' SOI, Mission Architect told me I was on track. Mission Architect was always right and the encounter would pop up in KSP a couple thousand km out.

If your burn details don't hit Dres, then it's time to optimize! For that, follow the same procedures outlined in the included help document PDF on traveling to Duna

Link to comment
Share on other sites

Also note that the "estimated delta-v" is really just the sum of the relative departure velocity and arrival velocity, the actual values will always be a bit different. It serves as a good estimate, though. As for why there's no Dres encounter, the patched conics approximation isn't usually the accurate. I have no idea what Alex is doing to increase accuracy in his tool, but I do depend on Mission Architect to take you the rest of the way in your analysis. As Gaiiden said, it's often better than KSP itself, so that seems like a reasonable thing. :)

Link to comment
Share on other sites

There's (possibly) something new for v1.5.0 on the horizon...

WHzlD1F.png

I'll try to have a pre-release up today or tomorrow for people to play with.

EDIT: And here we go: https://dl.dropboxusercontent.com/u/29126891/KSPTOT_v150_prerelease1.zip

Mission Architect -> Tools -> Launch Trajectory Analysis.

Edited by Arrowstar
Link to comment
Share on other sites

So, I checked it out - fiddled around a bit and ran the optimizer for a while, stopped it and saw the initial high parabolic arc fall just under the target orbital altitude - cool! But I think I'll have to wait until you have an example use-case before I can really figure out how to muck around with it (plus, I can't seem to add a stage). You planning to shoot off a simple 3-stage rocket (booster/lifter/payload) into low orbit using this tool would suffice I would think. The pitch graph could use a key although it's obvious once you correlate with the Pitch Profile Definition numbers. A data point cursor option in the toolbar would be nice as well.

Despite Kerbin/KSC being used for the example, it seems that this is only actually good for bodies without an atmosphere, where you can just lock the throttle wide open and not care about any drag or heating during ascent. So is atmospheric launch analysis an eventual goal? Even if not, I'd still be happy using this tool to plot me a launch from Mun direct to an orbiting vessel or return from Kerbin.

Link to comment
Share on other sites

also is it possible to not allow the KSPTOT window to be closed while other windows are open? Mostly in the case of Mission Architect, I'm using that window so much I tend to think of it as my "Primary" window, such that when I switch over to KSPTOT to load up a new tool or paste seconds to check a time, I absent-mindedly close it before going back to MA because I'm thinking of it as a tool window of MA instead of the other way around. So then I have to quit MA to kill that instance of the program if I want to load up the KSPTOT window again without running a new instance. And if KSPTOT window isn't open, I can't do things in MA like open a dialog box to select an SFS file for import.

Actually maybe Mission Architect should just become the main window for the program. I know how the tool started out, but given how it's evolved since, Mission Architect is really the heart of it all nowadays. I understand this wouldn't be a small change, so maybe for 2.0

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...