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

[Arrowstar]

2 hours ago, Drew Kerman said:

So this is AMAZING and will continue to make my mission communication even better for my KSA audience. Plus just looks fun to play with. looking forward to getting home soon

one thing missing from your post however is what this means for Mission Architect. Is LVD gradually looking to replace it as a more complete and powerful start to end mission planner? If not will it be possible to also implement these types of views in MA?

This is a great question.  When I built Mission Architect, I didn't know anything about object oriented programming or anything like  that, so I built the underlying data structure using something called "structures" which are just fancy keyword/value pair things.  The problem is that these are super inflexible and if you make a change somewhere, you have to update it *everywhere*.  Compare this to using classes and objects, where an update to the class propagates to all objects immediately and effortlessly.  Long story short, there's no way I could get any of this into Mission Architect without a ton of work, sadly.  It's just too clumsy on the back end at this point.

Anyway, it's become extremely hard to update Mission Architect in any big way because of the limitations of the underlying data structure type.  Because of that, yes, I do envision that Launch Vehicle Designer will ultimately become a replacement for MA in many ways.  Mission Architect's big thing that it has going for it right now is speed: it's a lot faster to propagate a trajectory in MA because of the analytical way that trajectories are computed, as opposed to using an integrator.  I've made some progress in LVD in this regard with the Two Body propagator model, which is faster in general than the Force Model propagator, and the ODE5 integrator, which is generally much faster (per step taken) than the ODE45/ODE113 integrator that MATLAB ships with.  LVD is also more general and less hacky when atmosphere comes into play, because I can model drag and lift seamlessly with other force models like gravity.

I'm not sure if this is what you wanted to hear or not, but it is my general vision for the future of end-to-end trajectory design in KSPTOT.  I'm not going to get rid of Mission Architect, though: it's a great tool for in-space trajectory analysis still, and like I said, much faster at computing trajectories and the like.  And I will continue to fix bugs in MA (and anywhere else) for as long as I maintain KSPTOT.  Active development of MA is probably more or less complete at this point, though.

--------------

In other news, here's KSPTOT v1.6.6. pre-release 3.  The change log is as follows:

• LVD: Creation of new view settings/profile system.
• Addition of two-body rotating frame math under the hood, for use with the state representation code.

EDIT: If you previously downloaded the pre-release, please go ahead and re-download it.  I found a bug I wanted to get patched before this pre-release got out too much.

Edited July 6, 2020 by Arrowstar

[Drew Kerman]

As a fellow coder, I understand the limitations you’re facing with MA. I think the path forward you’ve outlined makes perfect sense.

Next question then - would it be possible have LVD open MA .mat files? I understand the real process would be a possibly complicated conversion, but i’m looking at it from an end-user perspective. 

[Arrowstar]

22 hours ago, Drew Kerman said:

Next question then - would it be possible have LVD open MA .mat files? I understand the real process would be a possibly complicated conversion, but i’m looking at it from an end-user perspective. 

I was thinking about it today, and I think it would be possible, yes.  I'm not sure what the use case would be, though.  What would you use a function like this for?

[Drew Kerman]

51 minutes ago, Arrowstar said:

I was thinking about it today, and I think it would be possible, yes.  I'm not sure what the use case would be, though.  What would you use a function like this for?

Not 100% sure at this time, but wanted to put it out there. Will def have a more concrete idea as I work through missions and experience the workflow. Basically, how much will I (and users in general) be jumping between LVD and MA and how much of the mission planning will want to be carried over instead of recreated? I think for most cases it will just be copying the last state from MA to LVD and vice versa, which is already easy enough

[Arrowstar]

19 hours ago, Drew Kerman said:

Not 100% sure at this time, but wanted to put it out there. Will def have a more concrete idea as I work through missions and experience the workflow. Basically, how much will I (and users in general) be jumping between LVD and MA and how much of the mission planning will want to be carried over instead of recreated? I think for most cases it will just be copying the last state from MA to LVD and vice versa, which is already easy enough

I don't think it will be too bad, but as always, evaluate and let me know your thoughts.

In other news, I was able to squeak out another 5%-10% performance out of atmospheric flight in LVD.  Right now the biggest single cause of run time in an LVD launch simulation (with an atmosphere) is computing the atmospheric temperature, and of that, computing the "sun dot normal" term is most of it.  I've tried all sorts of ideas to improve the performance of this function the past few days, but so far, nothing has been shown to be viable on the level that would be required to make the effort worth it.  Work continues though.

[Arrowstar]

Hi everyone,

This afternoon, I've built KSPTOT v1.6.6 pre-release 4.  This big update in this pre-release is LVD performance.  I've really been focusing on getting the runtime for a simulation with atmospheric flight down as much as possible.  Between pre-release 3 and pre-release 4, there should be a 15% to 20% decrease in runtime when running the example Two Stage to Orbit case file. 

If anyone has the time and wants to run some of their simulations under 3 and 4 and compare times to execute the scripts and report those numbers back here, I would be much obliged.   Also as a note, there are some structural changes to some data models under the hood in PR4, so don't save things if you want to go back to PR3 or earlier still.

[Drew Kerman]

1 hour ago, Arrowstar said:

If anyone has the time and wants to run some of their simulations under 3 and 4 and compare times to execute the scripts and report those numbers back here, I would be much obliged.

unable. I get the following error on startup for both PRs:
 

Error using imread
File ".\images\logo500px.jpg" does not exist.

Error in imread


Error in splashScreenGUI>splashScreenGUI_OpeningFcn (line 64)


Error in gui_mainfcn (line 220)


Error in splashScreenGUI (line 40)


Error in projectMain (line 30)

MATLAB:imagesci:imread:fileDoesNotExist
Error writing to output stream.
iostream stream error

1.6.5 release loads up just fine

[Arrowstar]

47 minutes ago, Drew Kerman said:

unable. I get the following error on startup for both PRs:
 

Error using imread
File ".\images\logo500px.jpg" does not exist.

Error in imread


Error in splashScreenGUI>splashScreenGUI_OpeningFcn (line 64)


Error in gui_mainfcn (line 220)


Error in splashScreenGUI (line 40)


Error in projectMain (line 30)

MATLAB:imagesci:imread:fileDoesNotExist
Error writing to output stream.
iostream stream error

1.6.5 release loads up just fine

Weird, it works for me in native MATLAB but I also see it fail when built.  I'll get a new version out tonight with a fix, hopefully (assuming I can find the flaw).

[Arrowstar]

@Drew Kerman: I re-uploaded PR4 with a fix, give it a try now.

EDIT: Hold off for a moment, I found another bug lol.

EDIT 2: Okay, should be resolved now.  New upload on the way.

Edited July 9, 2020 by Arrowstar

[Drew Kerman]

6 hours ago, Arrowstar said:

give it a try now.

works. Can you rebuild PR3? Also, don't forget to put the PR# in the About dialog versioning info

[Arrowstar]

5 hours ago, Drew Kerman said:

works. Can you rebuild PR3? Also, don't forget to put the PR# in the About dialog versioning info

I'm afraid not, not without rolling back anyway, as I don't create separate branches for pre-releases.  A comparison against 1.6.5 would be just as useful to me though.

And yes, I'll remember the versioning PR number stuff for next time!

[Drew Kerman]

5 hours ago, Arrowstar said:

A comparison against 1.6.5 would be just as useful to me though.

Sure. Here's 5 loads from 1.6.6 PR4

3.268s
1.834s
1.683s
1.601s
1.785s
2.0342s Avg

Here's 5 loads from 1.6.5 release:

4.111s
2.799s
2.653s
2.838s
2.855s
3.0512s Avg

[Arrowstar]

4 minutes ago, Drew Kerman said:

Sure. Here's 5 loads from 1.6.6 PR4

3.268s
1.834s
1.683s
1.601s
1.785s
2.0342s Avg

Here's 5 loads from 1.6.5 release:

4.111s
2.799s
2.653s
2.838s
2.855s
3.0512s Avg

Wow, a ~30% decrease in run time, that's awesome.  It's even better than I thought.

[Arrowstar]

A few updates for the next pre-release, whenever that drops:

• LVD now remembers your view zoom and pan settings when you zoom and pan around.  Theses settings are saved to the view profile, so when you switch view profiles, the zoom and pan will be set to where ever you left left.
• LVD can now plot thrust vectors.  You can change the color, line style, scale, and spacing of the thrust vectors.  Note that thrust vectors are not kinematic quantities, so if you plot them in a non-inertial frame, their orientation will be correct, but their orientation relative to things like the apparent velocity will not look right, as kinematic quantities such as position and velocity are transformed via the basic kinematic equation (or "transport theorem") and the thrust vectors are just rotated into the correct frame via a rotation matrix.

[AbhChallenger]

Is there any chance of a series of video tutorials or just videos of how you do various things with TOT?

 

A few I have in mind if you have time to do so. I intend to play using the JSNQ system once it is updated to 1.10 but any system will do.

The main one is doing a TLI burn to end up at the correct inclination and LAN after SOI change. So that you are in plane with a station or fuel depot orbiting the Mun.

The other is lets say you have to launch into a polar orbit but you want to go to Duna. How do you figure out the correct LAN to launch to?

The last one is finding the best orbit to put a fuel depot or perhaps the best orbit to depart from if using a very low TWR engine and want to do the transfer in a single burn.

[Arrowstar]

I added a couple more new features today to the LVD view profile system.  For a while now, I've wanted to be able to display the Sun's location as a vector from the center of the central body being plotted i the display area, and to have the optional ability to render the lighting that would be caused from the Sun.  I've added both of those tonight.  It was super easy actually, generally in thanks to the modularity of the new view system.

Here's the sun vector and sun lighting in action.  The render is about 1 Kerbin day and the orbit is shown in a Kerbin body-fixed frame.  Both of these options are disabled by default and can be enabled/disabled independently.

Edited July 11, 2020 by Arrowstar

[Arrowstar]

1 hour ago, AbhChallenger said:

Is there any chance of a series of video tutorials or just videos of how you do various things with TOT?

I'm not a big fan of video tutorials myself because I don't have any experience doing it and I don't have the equipment (screen recording software, microphone) in order to pull it off well enough.  I can try to answer questions though, and I'm not opposed to having others make video tutorials if they want to.  By the way, there are a few tutorials included with the software.  Take a look and see if any are any help to you.

Quote

The main one is doing a TLI burn to end up at the correct inclination and LAN after SOI change. So that you are in plane with a station or fuel depot orbiting the Mun.

You could do this in Mission Architect, yes.  You'd set up a mission plan to go from KEO to a particular point around the Mun.  You could also do this in Launch Vehicle Designer, they work pretty similarly.  MA is probably a bit easier to get your head around, though neither is ultra easy.  What you're asking is actually a fairly complex rendezvous problem.

Quote

The other is lets say you have to launch into a polar orbit but you want to go to Duna. How do you figure out the correct LAN to launch to?

Check out my Kerbin to Duna example for Launch Vehicle Designer.  It does this basically this, aside from the polar orbit.  Should be a decent starting point to work off from.

Quote

The last one is finding the best orbit to put a fuel depot or perhaps the best orbit to depart from if using a very low TWR engine and want to do the transfer in a single burn.

Ooo boy, low thrust trajectory optimization is something I'd love to tackle in in LVD, but honestly, what you're asking is an extremely complex trajectory design question, assuming you intend to actual model the low thrust departure burn directly.  (And I'm a professional astrodynamicist, so you can take my word for it lol.)  Here's what you could do, though. 

1. In LVD, set up an initial state and allow the SMA, inclination, and RAAN to be optimized quantities.  Assume the eccentricity is 0 and argument of perigee doesn't matter.  Figure out your bounds for SMA, inclination, and RAAN.
2. Set up another event to actually model the low thrust burn. 
3. Set constraints for the end of that maneuver that align with whatever your departure conditions are.

Be warned, this isn't a simple problem.  The NOMAD solver might be able to pull off a solution, but I wouldn't try anything that relies on a gradient to actually solve this one.  Let me know if you pull it off though!

I hope this helps a bit.  You have some pretty complex trajectory design problems you're looking.  If you get stuck somewhere, let me know and if you're using MA or LVD, post your MAT file so I can take a look at it.

[AbhChallenger]

The low thrust trajectory thing is not very important to me. It was more of a question about how high to be so that the trajectory is relatively flat at say 0.2 TWR. Not how to do spiral trajectories or the nearest onramp to the interplanetary highway. Most gate orbits should be fine for this I think.

 

If you happen to have the time one day. Perhaps you could just make an example post about how you would go about setting up that TLI burn? That is really the main thing I want to use TOT for.

[Drew Kerman]

@Arrowstar I would like to request time stamps in the ksptot.log. I can't tell if the optimizer is hung up or not and looking at the log I see stuff but don't know if it happened before or during the optimizer run

what exactly is the value being edited in the variable adjust window? Because it doesn't correlate to the Linear Term of the steering values I'm adjusting. Just looking to get a better idea of the link between them

Edited July 14, 2020 by Drew Kerman

[Arrowstar]

4 hours ago, Drew Kerman said:

@Arrowstar I would like to request time stamps in the ksptot.log. I can't tell if the optimizer is hung up or not and looking at the log I see stuff but don't know if it happened before or during the optimizer run

I looked into this and it doesn't look like it's possible.  Basically MATLAB is just taking everything that would normally get written to console and writing it to file instead, and I don't have much of a way to influence that.

Quote

what exactly is the value being edited in the variable adjust window? Because it doesn't correlate to the Linear Term of the steering values I'm adjusting. Just looking to get a better idea of the link between them

I found a bug in the variable adjuster code.  I'll put out a pre-release that hopefully resolves this tomorrow.  Also note that all angle measures in KSPTOT are stored in radians in memory, so what you're looking at there might be radians/sec and not deg/sec.  The bug shows up when time is part of a state definition (initial state or Set Kinematic State action) but is not an optimization variable.  I will fix tomorrow.

[Drew Kerman]

2 hours ago, Arrowstar said:

so what you're looking at there might be radians/sec and not deg/sec.

oooohhh yea, that would make sense

[Arrowstar]

9 hours ago, Drew Kerman said:

oooohhh yea, that would make sense

Here's KSPTOT v1.6.6 pre-release 5.  This should fix your adjust variables bug, if you could take a look?

[Drew Kerman]

2 hours ago, Arrowstar said:

This should fix your adjust variables bug, if you could take a look?

wasn't it a bug you found? I was just confused why the values I was adjusting weren't what I expected. Anyways I'm working in PR5 and no obvious issues so far.

Is there any way to break out the animated view as well? I know you can still open the window and get the static view...

[Arrowstar]

1 hour ago, Drew Kerman said:

wasn't it a bug you found? I was just confused why the values I was adjusting weren't what I expected. Anyways I'm working in PR5 and no obvious issues so far.

Glad to hear there are no issues!  And I guess we can share ownership of the bug, haha.

Quote

Is there any way to break out the animated view as well? I know you can still open the window and get the static view...

It's not impossible but it would require a new, separate to implement.  What are you trying to accomplish?  Maybe I can implement something that does what you're looking to do directly.

[Drew Kerman]

11 minutes ago, Arrowstar said:

What are you trying to accomplish? 

nothing yet, just wondering. Since it's possible I will follow up on this with more details at a later point when I have more time spent with it. Certainly good enough as is