Arrowstar

Could you please post the Mission Architect MAT file you're working on so I can take a look? Thanks!

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.

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

Sounds good, let me know how it goes.

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.

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!

Well dang! That looks great.

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!

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.

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

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.

Hi everyone! This afternoon I'm releasing KSPTOT v1.6.5 pre-release 2. There are a few nice changes in this release: LVD/MA: New mission plans now use the celestial body data that's currently loaded in the main KSPTOT GUI and not the data from the previous mission plan. LVD: Added a new impulsive delta-v event action. LVD: Added a new event number and total effective specific impulse (Isp) tasks to Graphical Analysis. LVD: Objective functions are now "composites" of a number of sub-functions. Those sub-functions mirror what is available for use as a constraint. LVD: Added a constraint (and therefore also an objective sub-function) for the amount of delta-v expended during an event. Listed under "event delta-v expended" or something to that effect. I also want to give a warning: After this pre-release, mission cases created in LVD will likely not be compatible with the next pre-release. This is because I am completely rewriting, from scratch, the way that spacecraft states are represented in LVD (and really, these are generic and could be used anywhere, but I'm starting with LVD). This is because I want the flexibility to use any state element set (position velocity, Keplerian orbit elements, geographic elements, etc) with any reference frame (inertial, body fixed, etc) relative to any body. Right now everything is kind of hard coded and it's a pain in the neck to convert from one state representation to another. This new system makes everything really seamless in a way I should have been doing from the start. What's going to break, in LVD anyway, is the way that initial states are stored under the hood. I'm basically going to allow for much more flexibility, but that's going to mean changing data structures, so old MAT files will not carry through from this pre-release (or older) to the next pre-release and beyond. Sorry about this inconvenience! :)

Tonight I revamped the way objective functions work in Launch Vehicle Designer. Before, you got to select between one of basically three functions and that was it. Now, however, the flexibility has been increased significantly with the introduction of what I call composite objective functions. The way these work is that the user can create any number of sub-functions which are evaluated at the end of a particular event, just like constraints. Then the values of those functions at their respective events are "composited" together using one of four methods. Here, I'm using the standard "sum" method, which would just add up all of the functions shown in the list box on the left. (Of course, I only have the one function at the moment, but you get the idea.) Other composition types include RSS (root sum square), the minimum of the array of values, and the maximum of the array of values. The functions that are available for use as an objective function are identical to those available for use as a constraint, so anything you could constraint before, you can now optimize. Long story short, this should provide a lot more flexibility to all you mission planners out there. Please let me know if you have any questions or feedback (though I realize I haven't released it to the public yet). Happy orbiting! EDIT: Also, as of 5 minutes ago there's now a constraint in Launch Vehicle Designer for delta-v expended over the course of an event. This can also be used as an objective function, as I mentioned above. Use cautiously, though: it's a fairly expensive function because I have to compute the delta-v expended between each time step in order to get the math right and account for everything. It also doesn't account for things like staging and the like at the moment, so probably best to avoid using it in events where the rocket dry mass changes due to an action at the end.

Okay sounds good. Btw, I can't promise that the code will work on any release but R2017b, but if you have R2018b, check your command window to see if MATLAB is throwing any errors.

Okay, let's just wait until you can tell me what you need a bit better. Alright, safe travels and merry Christmas.

What is current Dv at the end of a state? Amount remaining?

Resolved for next release. EDIT: By the way, I took a look at your mission script in the file you provided. I realize I've probably never mentioned this until now, but it's not good practice to have sequential and non-sequential events with the same termination conditions. The script propagator can get confused and only register one event (probably the sequential one). If you have actions you want to execute at that termination condition, just put them on the sequential event and delete the non-sequential event, or put the non-sequential event just after the sequential one. This will prevent the issue.

Delta-v remaining would be easy enough to do in LVD, I suppose I could base it off currently active engines and the tanks they pull from. The problem with tracking usage is that it's not a quantity that is associated with a particular state but instead is the sum of a bunch of calculations that occur between states. (Remember that delta-v is computed as the Isp times the natural log of the ratio of old mass to new mass.) So I'm not sure how I would do that under the paradigm I have now. Do you have a use case for this information? Should be an easy fix, thanks for the report!

I added an "impulsive delta-v" event action to LVD this evening. This has been on my TO DO list for a while now. This allows Launch Vehicle Designer to model impulsive delta-v maneuvers, just like Mission Architect. You can specify the delta-v vector in either the inertial frame or the orbit frame, and the maneuver can be set to calculate the fuel usage of the maneuver or make it a propellant-less maneuver (such as two spacecraft undocking).

Honestly, most of it you can leave with the stock settings. The big things (for FMINCON) are the solver algorithm, the tolerances, and parallelization. Everything else is less important. Of those, the only one with a non-obvious use case is the algorithm, and you'd just change it if the current selection wasn't making any progress. A different algorithm might solve the problem better.

Done for next release. Glad you like it lol. Took days to make those goofy UIs with all the options!

Ah, yeah. This is sort of by design and sort of behavior that is inherent in the way MA and LVD were written. I certainly can change it to use whatever is in the bodies.ini file pointed to in the appOptions file if you'd like. Open up the options for the selected solver and make sure that parallel computing is enabled. If it is, when you close the solver selection dialog box, it should start the parallel computing pool. Is that helpful?

It's on the to-do list! No, it should just work. Can you post the contents of your ksptot.log file here? How much RAM does your PC have? What about number of cores on the CPU?

Hi everyone, Tonight I've compiled KSPTOT v1.6.5 pre-release 1. Here's the change log: MA/LVD: Added option to auto-propagate (or not) the mission script when changes are made to it. Useful when your script takes forever to propagate and you have lots of changes to make. Improved robustness of "coast to function value" in MA. MA/LVD: Editing mission notes prompts user to save file (asterisk in window title). LVD: Overhaul of optimization: Added new optimizer: NOMAD Added new option for computing gradients of objective function (a custom finite difference scheme) Added a new UI for selecting optimization algorithm. Added many new options for FMINCON and Pattern Search algorithms (including two new UIs for them). Removed all the old optimization options (they are incorporated to the new options now). Caveats: The custom finite difference scheme still needs a UI for its options. NOMAD is not yet available on Linux. I can't get the code to compile properly yet and both the developer and I are perplexed to say the least. Still working on this. Please let me know if you find any bugs or issues with this build. A lot of the optimization changes are experimental at this point so the more testing the better. Thanks!

Hi everyone, I wanted to take a moment to talk about what's coming in v1.6.5. I've been doing a bunch of work on improving the optimization experience in Launch Vehicle Designer (LVD). Right now there are two different algorithms (FMINCON and Pattern Search) but PS was sort of hacked in there and almost none of the available options for either are exposed. In general, optimization in LVD can feel a bit rough and unproductive to me. I want to change this with v1.6.5. In addition to the items I've already posted about above, here's what I see coming for this release: New optimizer interface Right now the current optimizer interface is menu driven, exposes only a very small number of options for each algorithm, and is not the easiest to make sense of. That's all going to change. A new "Optimizer Algorithm Selection" user interface is coming that will allow users to cleanly select the algorithm they want. In addition, each optimizer will have its own options user interface that will allow users to set many more options than a few that are currently available now. New optimizer(s) As I mentioned before, there are two optimizer available in LVD right now. FMINCON works pretty well for what it does, and Pattern Search has its strengths, but it tends to work poorly on problems where feasibility is hard to find. Enter NOMAD, or "Non-smooth Optimization by Mesh Adaptive Direct search." NOMAD works astoundingly well at taking a trajectory with many constraint violations and reducing those violations to a place where something like FMINCON can pick it up and solve it. (It also does pretty well at finding feasible solutions in general if you give it enough time.) Right now NOMAD's biggest draw back is that it can't be run in parallel, but I've contacted the developers to see what I can do. (The software itself supports parallelization but something funny happens when you try to use it in MATLAB.) I may also include "IPOPT", where is pretty similar to FMINCON's "interior point" algorithm, but seems to work better in some cases. Both NOMAD and IPOPT are part of the OPTI Toolbox, and if I do end up including them, will (sadly) only be available on the Windows build because OPTI is only built for Windows. Constraint Jacobian visualization The constraint Jacobian is a matrix where each row represents a constraint and each column is a particular variable. Each element of the matrix is the sensitivity of that constraint to that variable. In general, you want each element to be roughly about 1.0, and you achieve this by scaling your constraints using the scale input in the Edit Constraint dialog box. A new feature to LVD is the ability to compute and visualize this matrix in a heat map so that you set those scale factors accordingly. That's all I've got for now. The dialog boxes for FMINCON and Pattern Search are done, the selection dialog box is basically done, and I'm actually running NOMAD right now to solve a full Kerbin - Mun - Kerbin mission in LVD, and it's doing pretty well. Just need to get an options dialog box together for that, check on the possibility of parallelization, and decide on IPOPT (which might just come in a later release if I decide I want to include it after all). Thoughts?