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

[Drew Kerman]

2 hours ago, OndrikB said:

Question regarding MFMS:

Does "Departure Time" refer to the time at which the maneuver is created or to the time at which you leave the SOI?

The first one. It’s your departure burn, actually

[OndrikB]

Thank you

[Arrowstar]

13 hours ago, Drew Kerman said:

The first one. It’s your departure burn, actually

More technically, since the SOIs are considered infinitesimal, they are technically the same time under the theory I'm using for all this.  Therefore the answer to which "real" time it is is fuzzy.  It's probably best to assume it's the departure burn as @Drew Kerman said, but play with it and see what works for you. 

[Arrowstar]

Hi everyone,

Today I have some pretty neat news regarding a new feature in KSPTOT's Launch Vehicle Designer (LVD) tool.  One of the things that has always bugged me about how complicated trajectories are computed in KSPTOT (either Mission Architect or LVD) is how complicated it is to set up a flyby and then achieve the next flyby.  Part of the issue is that intercepting a celestial body correctly, even the Mun, is a fairly challenging numerical task.  Up to now, it could be done, but it took quite a bit of effort from users to get it right.  Today I've introducing something that I hope will make that easier.  Enter the "Set Kinematic State" event action and "continuity" constraints.  Let's talk about the former first.

This is the user interface for the new "set kinematic state" action.  Kinematics is essentially time, position, and velocity (in any representation out there), and I've expanded the definitely slightly to include mass.  I realize this looks a bit complicated, so let's break it down.  The big thing to realize is that this is a way to set the state of the spacecraft, and you can either specify parts of the state directly or inherit those bits from the previous state (which is how the LVD normally works) or inherit them from the final state of an event of your choosing.

Up top in the "orbit parameters" panel we have the way in which your orbit will be set and displayed in the UI.  The "element set" is which set of six numbers to use for representing the orbit (so keperian elements, position and velocity vectors, or geographical elements such as latitude and longitude).  The frame type sets which style of reference frame to use.  Right now there are two: an inertial frame and a body-fixed frame.  And finally, the central body tells the code which celestial body the orbit is relative to.  This is fairly similar to the "set initial state" UI that was in there before, and indeed that user interface now has these three options as well.

In the "time" panel, we have a few different things.  First, there is a check box for "inherit time."  If this is unchecked, then you either specify the time directly or can let an optimizer find it for you.  If you check this box, then you decide where to inherit the time of this new state from: you can either let it come from the state immediately prior to executing this action, or you can pull it from the last state of an event that occurs prior to this one.  The former is the default behavior for LVD and just lets time propagate forward as it does, continuously.  If you specify an event, then the time of the state that comes out of this action will be the final time of the event you specify.

The "state" and "stage states" panels work identically to time as far as inheritance goes.  The only difference is that the state panel controls the position and velocity inheritance or specification, and the stage states panel controls how things like dry mass, tank masses, and engine and stage activation states are inherited.  Stage states must always be inherited at the moment because I don't have a good way of letting users specify them right now.  

So how can you use this new functionality?  There are two ways I've come up with:

1. Specify a target orbit, such as GEO or a flyby of the Mun, and then optimize whichever parameters of those you desire.  Use the continuity constraints, which I'll talk about below, to achieve a continuous trajectory.
2. Branching trajectories: Let's say you are modeling a launch from Kerbin to low Kerbin orbit.  You are a good engineer and want to make sure you don't drop your first stage on anyone's head.  After modeling the full trajectory normally, create a new event with zero duration as the termination condition and apply this action to it.  Then inherit the time, state, and stage states from immediately prior to first stage separation.  This time, deactivate all stages but the first stage, and allow the trajectory to propagate the orbit until impact with the ground.  Determine the impact location.

I'm sure other people will come up with new uses as well, this is just what I've come up with off the top of my head.

Okay, now continuity constraints.  If you are using the first application of this new action, then you'll want to make sure that your inbound trajectory meets up with the state that you specify/optimize here.  Enter continuity constraints.  If you apply time, position, and velocity continuity constraints on the event where this action is used, and you follow the advice and only have this action on a zero duration event, then you'll end up with a constraint which is satisfied when the end state of the previous event and the specified state in the UI are equal in time, position, and velocity.  Why do this?  It is very challenging for an optimizer to find those flybys, but as it turns out, enforcing continuity is actually pretty straight forward and a much easier numerical problem.  This is a great way to specify the flyby you want and then make sure that the trajectory is actually continuous so that when you go to fly it, you end up with something realistic.

There are seven new continuity constraints: one first time, three for position (X, Y, Z) and three for velocity (X, Y, Z).  

There is a new LVD example MAT file that shows how to set all this up.

Well that was a lot!  Any questions?  I'll be releasing a pre-release with this all in it soon enough.

[Arrowstar]

By the way, here is an example of the branching trajectory I mentioned in the previous post.  The red and blue lines are the normal ascent trajectory.  The green line is the first stage disposal trajectory.  Event 12 inherits the state from Event 5 and Event 13 propagates it to the ground.

EDIT: By the way, in order to handle plotting correctly, there's a new "Plotting Method" drop down menu in the Edit Event dialog box.  The default is "continuous" plotting which grabs the final state from the previous event and plots a line between that and the first state of the event.  However, for these branching trajectories, this produces a disjoined trajectory, so I've added a new mode that basically skips that.  It's called "skip first state" or something to that effect, and it will product what you see above.  Also, there is now a method to skip plotting an event entirely, if you wanted to do that.

Edited December 30, 2019 by Arrowstar

[Arrowstar]

Hi everyone,

Tonight I'm happy to push out KSPTOT v1.6.5 pre-release 3.  This is a super exciting pre-release for me and features the following changes and enhancements to Launch Vehicle Designer (LVD):

• Implementation of the new state representation system.  In the initial state dialog box and the set kinematic state action dialog box, state representation and reference frame are now select-able in more combinations than before, and adding new reference frames and state representations is much, much easier going forward.
• New "set kinematic state" action.  Use this to set the time, position, velocity, and stage states of the spacecraft arbitrarily (or optimize them), or inherit them from the final state of a previous event.
• New time, position, and continuity constraints for use with the set kinematic state action.
• FMINCON options now allow constraint, optimality, and step tolerances to go to 0.
• Objective functions are now "composites" of different functions.  The values of these functions are added together in a fashion defined by the user.
• New plotting methods for events (applies to both the orbit display in the main LVD UI and graphical analysis plots).

Also, I do want to take a moment to thank everyone that has helped in the development of KSPTOT over the past year by finding bugs, suggesting features, or even just asking questions that give me insight into how users use KSPTOT.  And a big thank you to everyone who supported the development of KSPTOT financially over the past year via my Ko-Fi account.  Thank you to you all!

Happy orbiting and happy new year!

[Drew Kerman]

Flying home today & look forward to playing with new KSPTOT features this coming year! Orbit, hooooo!

[Drew Kerman]

Using a smaller rocket to test out new guidance fins for a larger rocket. Smaller rocket can fly faster than the larger rocket and the extra air pressure will give the fins more control authority and thus will not be a good test case, so the smaller rocket has to fly the same speed as the larger rocket. Planned out the larger rocket's ascent then recreated it for the smaller rocket with speed constraints along with pitch constraints and the optimizer had no trouble giving me what I wanted. It's like the Popcorn button on the microwave

[Arrowstar]

45 minutes ago, Drew Kerman said:

Using a smaller rocket to test out new guidance fins for a larger rocket. Smaller rocket can fly faster than the larger rocket and the extra air pressure will give the fins more control authority and thus will not be a good test case, so the smaller rocket has to fly the same speed as the larger rocket. Planned out the larger rocket's ascent then recreated it for the smaller rocket with speed constraints along with pitch constraints and the optimizer had no trouble giving me what I wanted. It's like the Popcorn button on the microwave

<snip>

Well dang!  That looks great.

[Arrowstar]

Tonight I compiled KSPTOT v1.6.5 pre-release 4.  It has the following changes to Launch Vehicle Designer:

• UI fix for Edit Event dialog box;
• Implemented universal elements for the Initial State and Set Kinematic State Action dialog boxes;
• Minor performance enhancements to calculating atmospheric temperature.

What are universal elements?

Universal elements are very similar to Keplerian orbital elements, with three differences.  The size and shape of the orbit are specified by a combination of C3 energy and radius of periapsis (as opposed to SMA and eccentricity), and the true anomaly is replaced by a "seconds past periapsis" quantity.

Why use universal elements?

Universal elements are most helpful for specifying and optimizing hyperbolic flyby orbits using the new Set Kinematic State action in LVD.  This is because, where SMA is singular (goes to infinity) as an orbit crosses from eccentric to hyperbolic, C3 energy merely goes from negative to zero to positive.  This means that the underlying process of optimizing the flyby state is much easier, and you can constrain your C3 energy to be positive to ensure the flyby orbit is hyperbolic.  In addition, because you can set the radius of periapsis directly, you can ensure that your flyby orbit doesn't enter atmosphere (or become a drill) just by setting the appropriate lower bound.

As always, please let me know if you find any bugs.  Thanks!

[Christopher Vaughen]

Hi Arrowstar, the KSP TOT looks FANTASTIC - very impressive.  I'm trying to teach myself orbital mechanics so I can add things into my calculus classes.  I'm still having trouble just installing...

  I downloaded MCR and the KSP TOT package.  I see the KSPTOTConnect folder and I copied it to the Gamedata folder in KSP.  

I just don't see the actual KSPTOT application anywhere.  I'm afraid I have a failed installation.   I think there was a message during installation about something being blocked.  Is there something else I might be missing?

Thank you so much for creating this app and sharing it - I'm excited to try it out!

Scott Vaughen

 

[Drew Kerman]

bug or misunderstanding in LVD, not sure. MA files (the one not named - Orbit is the LVD case file). I'm coasting up to a burn point and if you change sequential event #18's termination condition for True Anomaly to "Increasing at Value" the mission script will propagate past the current point. Shouldn't the TA be increasing as it approaches 180° apoapsis? If you set it to "Decreasing at Value" it also worked properly, which I find confusing.

Also this is my first attempt at modeling an orbital insertion burn in LVD and I haven't managed to get it right the way I thought it would work, so I'd like some advice before I bother fiddling around with it more. Here's what I did to model the burn as it is shown in the LVD case file:

1. Opened my Mission Architect file for the mission (also included in the zip with - Orbit in the name)
2. Coasted up to apoapsis and then added a circularization maneuver using the Viklun engine with same stats as the LVD vehicle
3. Copied the orbital state after my apoapsis coast
4. Pasted the orbital state into the Maneuver Execution Assistant (MEA)
5. Changed the maneuver to proscribed to get the amount of prograde Dv
6. Plugged the exact prograde Dv requirement into the MEA
7. Set MEA burn TA to 180
8. Set thrust and ISP to equal Viklun engine
9. Set Ini. Mass to that of initial state in MA (3.846214mT)
10. Computed burn timing info
11. Deleted maneuver from MA, changed apoapsis coast to UT coast
12. Subtracted MEA start time from UT coast
13. Plugged new True Anomaly value from final coast state in MA into Sequential Event #18 in LVD, which activates the Viklun engine
14. Plugged MEA burn duration time into LVD event #19, which deactivates the Viklun engine

Comparing the final states of LVD and MA you can see the mass is correct, but in LVD my trajectory falls short of orbit, let alone a circular one.

Since the fuel burn matches up, I'm thinking this has to do with the orientation of my launch vehicle? Take a look at Sequential Event #16 where I (think) I am locking the rocket onto a prograde vector based on what I asked you previously on how to do that. I tried both Body Fixed and Inertial Aero which produce different results but neither put me in the expected orbit.

Edited January 14, 2020 by Drew Kerman

[Arrowstar]

On 1/12/2020 at 9:25 PM, Christopher Vaughen said:

Hi Arrowstar, the KSP TOT looks FANTASTIC - very impressive.  I'm trying to teach myself orbital mechanics so I can add things into my calculus classes.  I'm still having trouble just installing...

  I downloaded MCR and the KSP TOT package.  I see the KSPTOTConnect folder and I copied it to the Gamedata folder in KSP.  

I just don't see the actual KSPTOT application anywhere.  I'm afraid I have a failed installation.   I think there was a message during installation about something being blocked.  Is there something else I might be missing?

Thank you so much for creating this app and sharing it - I'm excited to try it out!

Scott Vaughen

 

Hi Scott! There is definitely a KSPTrajectoryOptimizationTool.exe file in the KSPTOT.zip file that you downloaded.  Check to make sure a firewall or antivirus program didn't remove it.  It does require TCP/IP access for the local parallel processing to work (and I suspect MATLAB knows that when it starts the program).  If nothing else, redownload the KSPTOT ZIP file.

EDIT: Also, thanks for the complements!  And please let me know if you have any questions about KSPTOT.

EDIT 2: There is no actual install process per se.  You just unzip the contents of the KSPTOT.zip file to some folder and run the executable I mentioned above.  It may take a few minutes to start running the first time.  That's MATLAB unzipping some files into a hidden directory and nothing to be concerned about.

Edited January 14, 2020 by Arrowstar

[Christopher Vaughen]

1 hour ago, Arrowstar said:

Hi Scott! There is definitely a KSPTrajectoryOptimizationTool.exe file in the KSPTOT.zip file that you downloaded.  Check to make sure a firewall or antivirus program didn't remove it.  It does require TCP/IP access for the local parallel processing to work (and I suspect MATLAB knows that when it starts the program).  If nothing else, redownload the KSPTOT ZIP file.

ok, that was definitely what happened - it's a work laptop and some antivirus software must have swiped out the executable during the install - arrrgh!!

thank you for the feedback, so now I know to try again !

 

 

[Arrowstar]

11 hours ago, Christopher Vaughen said:

ok, that was definitely what happened - it's a work laptop and some antivirus software must have swiped out the executable during the install - arrrgh!!

thank you for the feedback, so now I know to try again !

 

 

Sounds good, let me know how it goes.

[Christopher Vaughen]

8 hours ago, Arrowstar said:

Sounds good, let me know how it goes.

OMG!! That was it - just had to try the download again.  It got it - it's running - so happy!  If I download with Firefox, and then check the "unblock" box in file properties before unzipping - well that does it!!

Now I just need to learn how to read all this stuff.  Fascinating!!!  Impressive stuff, thank you so much for making this available.

 

 

[Drew Kerman]

I bet Arrowstar wishes more people would show off the things they are doing with it. I know I do

BTW just to make sure - that Like of my post was the "cool, that's a bit involved so I'll look into it when I have more time" kind of like right? (press Like if Yes )

Edited January 15, 2020 by Drew Kerman

[Arrowstar]

50 minutes ago, Drew Kerman said:

BTW just to make sure - that Like of my post was the "cool, that's a bit involved so I'll look into it when I have more time" kind of like right? (press Like if Yes )

Hey, yes, lol.  I finally had a chance this afternoon.  The true anomaly coast thing was a one-line bug that I fixed easily, so thanks for that report.

About your insertion burn question: I haven't had a chance to fully recreate what you did yet.  I need to walk through your steps.  However, I would recommend allowing the pre-burn coast duration and burn attitude to be optimized, and then optimize those quantities.  Some of the disconnect between LVD and MA is probably that inertial aero angles are not really the same thing as the NTW (prograde/radial/normal) vector components, although they are close.  This may be why the MA and LVD solutions are different.  But I still need to look into it more.

EDIT: Okay, I got it.  After you turn your engine on in event 18, create a Set Steering Model action and set it to an Inertial Aero Angles model with zeros across the board.  Do not inherit the attitude.  Set the burn duration in Event 19 to 30.478 seconds.  You should get ~700 km SMA.  I did.  Basically your burn attitude in MA was pure prograde.  Prior to this, you forgot to set your steering to be the same thing, so your burn didn't do what you expected.

4 hours ago, Christopher Vaughen said:

OMG!! That was it - just had to try the download again.  It got it - it's running - so happy!  If I download with Firefox, and then check the "unblock" box in file properties before unzipping - well that does it!!

Now I just need to learn how to read all this stuff.  Fascinating!!!  Impressive stuff, thank you so much for making this available.

Glad you got it working!  Please let me know if you have any questions.  The maneuver planning tools are fairly straight forward but Mission Architect and Launch Vehicle Designer are definitely complicated tools to learn.  I can help get you on the right path though!

50 minutes ago, Drew Kerman said:

I bet Arrowstar wishes more people would show off the things they are doing with it. I know I do

lol yes, I do wish KSPTOT got a bit more exposure for the amount of work I sink into it, but I mostly do it for myself, so it's not too big of a deal.

Edited January 15, 2020 by Arrowstar

[Drew Kerman]

1 hour ago, Arrowstar said:

EDIT: Okay, I got it.  After you turn your engine on in event 18, create a Set Steering Model action and set it to an Inertial Aero Angles model with zeros across the board.  Do not inherit the attitude.  Set the burn duration in Event 19 to 30.478 seconds.  You should get ~700 km SMA.  I did.  Basically your burn attitude in MA was pure prograde.  Prior to this, you forgot to set your steering to be the same thing, so your burn didn't do what you expected.

Actually I messed up back where I pointed out in Event #16 that I was doing just that, but I left the constant term sideslip angle at 45°! Derp. I get the near 700km radius now too just by fixing that. Wow, that's great to have that work as expected now. I know I could have optimized my way there but I did want to see if I could get LVD to perform similar to MA by actually using MA since that's something I'm familiar with

Also LVD needs a popout figure window option like MA so I can blow-up and share them!

Edited January 15, 2020 by Drew Kerman

[Arrowstar]

22 hours ago, Drew Kerman said:

Also LVD needs a popout figure window option like MA so I can blow-up and share them!

Enjoy: KSPTOT v1.6.5 pre-release 5.

Change log (LVD):

• Resolves an issue with the true anomaly event termination condition where the directional termination was reversed from expected behavior.
• Added a pop out orbit display button to the main LVD UI.

[stankwoo]

First off, amazing program. I have been trying to do a simple mission plan from Kerbin to Mun and back. I was able to follow the Laythe tutorial to get a plan to Mun - now I am trying to plan back to Kerbin and I am having problems. I have been trying to follow the steps you have in the example mission where you go from Kerbin to Mun back to Kerbin.

This is what I have been trying:

1. Put vessel into orbit around Mun using cheat menu

2. Create new mission, on the "SET_STATE - Initial State" I right click and copy in my orbit information in.

3. Create a COAST step to True Anomaly with a random guess of 200 (check for optimize) 

4. Create a DV maneuver with a rough guess of what I need - I used Mechjeb to create a node to "transfer from the moon" - not sure if there is a better way to do this?

5. Create a COAST step to "Go to Next Sol Transition" - I would be very appreciative of an explanation of this step because I am not sure what the purpose is. I saw this is what the example mission did.

6. I am now copying the optimization constraints that the mission example had - i.e. for the "Coast - Go to Next Sol Transition" step, I set a constraint on Central Body ID to Kerbin and Altitude of Periapsis to [0,0], etc.

7. Watching the optimization, my Pe gets to 0 (most importantly into a capture orbit) but my Ap is infinity - my DV node sends me out of Kerbin SOI. 

 

My two big questions:

1. Can anyone help me out on understanding what I am doing wrong in creating a mission from Mun orbit back to Kerbin? I would be eternally grateful for tips or even a brief tutorial on how to plan from Mun orbit back to Kerbin.

2. In Mechjeb I used the maneuver planner to get back to Kerbin from the Mun orbit. I then tried to setup a mission and import what Mechjeb created. The mission architect and Mechjeb do not match up - i.e. Mechjeb and KSP show me I will get back to Kerbin but KSP TOT Mission Architect says I will not. I am curious on what I could be missing on getting everything to line up.

Thanks!

 

[Drew Kerman]

@stankwoo I’m about to go to sleep but visit the wiki on the KSPTOT github project page and you’ll find a tutorial for using one of the tools to get to/from planets & moons without having to guess & will give the optimizer an easier solution.

also always share the mission files so arrowstar can look at what you’re doing

also also @Arrowstar that wiki link still isn’t in the OP...

Edited January 20, 2020 by Drew Kerman

[stankwoo]

@Drew Kerman I appreciate the effort into the "get to/from planets and moons" wiki - this is what I followed with the other tutorial to plan my trip from Kerbin to the Mun.

Now that I am at the Mun and in orbit, I am working the steps again but reversed. When I load up the "Rendezvous Maneuver Sequencer" and select "Orbiting About: Mun" - I can't select anything on the "Final (Desired) Orbit Info" section. 

I am slowly learning all of this so I may be misunderstanding - should I be entering a SMA that will get me out of the SOI of the Mun? 

Thanks!

[Drew Kerman]

1 hour ago, stankwoo said:

Now that I am at the Mun and in orbit, I am working the steps again but reversed. When I load up the "Rendezvous Maneuver Sequencer" and select "Orbiting About: Mun" - I can't select anything on the "Final (Desired) Orbit Info" section. 

hrmm... so that's true. Not sure why when I wrote this I thought you could use it to get back to someplace outside the SOI of the current body you are orbiting. Okay, never mind there

1 hour ago, stankwoo said:

should I be entering a SMA that will get me out of the SOI of the Mun? 

I only made one mission that actually sent something back from Mun a few years ago and I can't remember well how I did it. I think I just stuck a maneuver along my last trajectory and kept bumping up the Dv prograde until it kicked me back into Kerbin orbit. Then I did a bit of manual fiddling to get close to what I wanted before using the optimizer to reach my specific target. Set your coast to the burn via True Anomaly for the optimizer to use to find the place along your orbit that sends you where you want to go when heading back towards Kerbin

[stankwoo]

Ok, I'll see what I can come up with tonight. 

In the mission example that is included to show how to play Kerbin to Mun and back, there is a coast that is set as "SOI transition" after the DV maneuver. That is what I was trying to understand how it worked.