Arrowstar

Hi everyone, This afternoon I've built KSP Trajectory Optimization Tool v1.6.9 pre-release 7. Here are the major feature updates in the pre-release: LVD: Added "plugin variables" which allow users to create their own plugin-accessible quantities which can be optimized. Refreshed the icons of many UIs. LVD: Performance improvements for 3rd body gravity. LVD: Updated the version of the IPOPT optimizer. LVD: Initial implementation of the Case Matrix Runner tool. Some other bug fixes and performance improvements. If you'd like to see the Case Matrix Runner tool in case, you can start with the "lvdExample_PluginVariablesAscentStateLookupTable.mat" example LVD file. To use it: Open up KSPTOT v1.6.9 PR7, then open LVD. Open up the "lvdExample_PluginVariablesAscentStateLookupTable.mat" file in LVD. Open up the Case Matrix Runner (Scenario menu -> Run Case Matrix) Turn on one or more of the parameters, update the output location/folder, then tap the Run Case Matrix button at the bottom and let it do its thing. If you'd like to see an example of the thing I talked about a few weeks ago where I use a look up table to provide an ascent insertion state based off real KSPTOT LVD simulations, then open up the "lvdExample_InsertionStateLookupTable.mat" LVD file. The look up table data for that file is located in "LaunchVehicleLookupTable.csv" and it was generated by running the Case Matrix Runner tool on the "lvdExample_TwoStageToOrbit_PluginVar.mat" LVD file. The output from that Case Matrix run, including the look up table which demonstrates how I put that together, is located in the "LVD_Case_Matrix_Run_20220404_083435.xlsx" Excel file. Please let me know if you have any questions. Happy orbiting!

Yep, this is another great use for it. It's pretty cool to see how different payloads or different insertion orbits changes, for example, your pitch profile over time. When you see that pitch up right at stage separation because you're moving to a lower thrust engine... just wonderful. To be honest, there's no resource out there that will tell you exactly how trajectory design should be done. A lot of it is from personal experience or instinct. That said, there's a few things you can do to get better: 1) Learn how the optimizers work. Read up on FMINCON and the interior point optimization algorithm. If you can implement it yourself, go for it. A lot of people treat these as black boxes when they really should have a better understanding of what's going on under the hood. Especially try to understand what you're looking for when you define objective functions and constraints. 2) Make sure you're familiar with what parameters aren't "smooth" and where, and what good alternative quantities could be. For example, SMA goes to infinity between eccentric and hyperbolic orbits, so if you could be on that line it might make sense to use C3 energy instead. Or eccentricity does weird things to your constraint gradients around 0.0, so it might make sense to go to H1 =0 and K1 = 0 in that case instead. 3) You can check out "Space Mission Analysis and Design" by Wertz and "Fundementals of Astrodynamics" by Vallado for some more academic tips and theories. 4) Read papers on real missions and how they were designed. Pay attention to the objective functions and constraints used if the authors describe them. 5) Just play around and ask for help! I'm always happy to share with people particular advice and to take a look at LVD case files and describe what I would do differently if it were me. This is the best way to learn in my opinion.

Hi everyone, I have a few KSPTOT related announcements for tonight. First, this is the official note that as of the next version of KSPTOT (and, in fact, the next pre-release), KSPTOT will be moving to MATLAB R2022a. There's a few UI features that I want to take advantage of, as well as a few under the hood improvements that seem nice. Everyone will need to use the R2022a MCR going forward. I'll put a note in the post that has the next pre-release in it so you don't forget. Second, tonight I want to introduce you to the new "Case Matrix Runner" in Launch Vehicle Designer! This goes hand-in-hand with the new plugin variables I showed off earlier. The Case Matrix Runner is an automated tool to automatically run and optimize a set of LVD missions derived from a user-created template. Each "case" in the set is a combination of some set of Plugin Variable values. Users select a lower bound, an upper bound, and a step size for each one of the Plugin Variable parameters in their LVD missions. The Case Matrix Runner then computes all the combinations of each set of parameter values, creates the associated LVD data for each new case, and runs/optimizes them in parallel. Some special trickery under the hood is performed to help cases that are "far away" from the template case optimize better. Here's a shot of it in action. Here you can see that I'm running two parameters. The second one, "Initial SMA" is selected and its range is shown at the top of the dialog box. I'm running initial SMAs from 700 km to 1500 km in increments of 100 km: 700 km, 800 km, 900 km... to 1500 km. I'm also running initial inclinations from 30 deg to 60 deg in increments of 10 deg, but that's not visible on the UI directly. (It would be if I selected the "Initial Inc" item in the listbox at the top there.) In the center we have some user definable parameters that show how the cases will be run. The output data folder is defined first, I'm using 3 parallel workers, and Case Matrix Runner will attempt to solve each case 2 times. The table at the bottom of the dialog box shows some information on the cases and their current status. Each row represents a case and shows the combination of parameters that make it up, the run status. Here you see some cases that have completed successfully, three cases running, one on each worker, and one run at the bottom still waiting to be run. To start a run you push the big "Run Case Matrix" button. At the very bottom of the dialog box there's some information and controls. You see that the last run status update was Case 14 moving from Not Run to Running status at 6:19 PM. The total run duration is shown on the bottom right (6 minutes, 49 seconds so far). Finally, users can cancel the case matrix run completely with the Cancel button. Once a run has completed, the output location will be populated with all the output products. First, each case has a corresponding LVD MAT file generated so you can see what happened to it under the hood. Similarly, the log file from the optimization run is generated. Finally, a giant spreadsheet is created. It contains a summary of the entire case matrix run and a worksheet for each case populated with data from the Graphical Analysis tasks that are defined in the template LVD file. You can see an example of that here (Excel file) or here (Google Sheets, but sort of gimped because the Excel conversion wasn't perfect). There are a few caveats here that should be mentioned as well. First, while there's technically no limit to how many different parameters you can sweep over, unless you want your run to take forever to complete, you're realistically limited to 3 or (maybe) 4 parameters as the number of cases will start to increase exponentially. Second, and similarly, this feature is definitely for those with beefy CPUs. Each case gets optimized using serial calculations, so it's not unusual to see your Case Matrix run take overnight. The more CPU cores and RAM you have available here, the better. Third, it definitely takes a bit of practice to get a template LVD case to the point where you can sweep over a bunch of parameters like this and the optimizer will solve the problem well. Expect to put in a bunch of time tuning constraint scale factors, optimizer parameters, and other LVD inputs in order to get this to work. And finally, since this does interface exclusively with the Plugin Variables stuff, learning a bit of code will be mandatory in order to use this in any real way. So why use this? Well remember in my last big post how I was talking about how if you could get a big look up table of orbit insertion state as a function of launch azimuth you could cut out modeling the ascent directly and just do the in-space portion of LVD? Well, one use case for this tool is the ability to generate that table. In fact, the two data files I linked to above contain the data to do just that. Another use case would be to step a solar system tour scenario forward and backwards in time, day by day, to verify that you have the best launch day or to see what happens if you miss a launch day or need to launch early or whatever. The sky's the limit really. I'm going to be running a few more tests over the next day or so, but I'm anticipating having this ready to put into a pre-release soon. Before then, though, please definitely pass along any thoughts or comments or suggestions you might have. Happy orbiting, everyone!

There's not unfortunately.

You just need to get the angle (-293 deg) back into the acceptable range for that field. Angles wrap every 360 degrees so adding 360 degrees doesn't change the value of the angle .

Add 360 to your -293 and you'll be all set.

Right, who wants to see something cool? For a while now Launch Vehicle Designer (LVD) has had user customizable constraints and objective functions via the Plugins functionality. Yesterday it occurred to me that the only thing we were missing were user-definable variables, or what I'm calling "plugin variables". I put something together that's now accessible from the Plugins menu in LVD. Variables can be added and removed in the usual LVD way. As you can see, each variable can be optimized between bounds that the user defines. In the above case, I have a variable called "Initial Inclination" that is currently 36.68 deg and is set to be optimized between 0 and 90 degrees. (The degrees bit is implied. It's what I understand those numbers to mean as the analyst, but LVD doesn't care.) So how do we use this? The values of all plugin variables, regardless of if they are being optimized or not, are passed into the plugins now using a new variable: "pluginVarValues". This is an array of numbers arranged in the same order as you'd see in the Edit Plugin Variables dialog box (above). From here you can do anything you want with them. Here's just one example of a possible use case. Note that this is just a toy example and the possibilities for what anyone could do with this go far beyond what I'm about to show. Optimizing an ascent trajectory from the surface of a body to space is complicated and often doesn't mesh well with trying to optimize the rest of the in-space trajectory. With this new functionality, what users could do is run a bunch of launch trajectories at different launch azimuths, extract the orbit insertion state, and generate a look up table of those states. You could then create a variable for "launch azimuth" that would be used to interpolate between the rows of your look up table, and the numbers that come out of that are your SMA, inclination, eccentricity, masses, etc. Here I'm doing something slightly differently. I'm skipping the launch azimuth bit and just tying orbit insertion inclination to mass in the "upper stage" tank. This is the variable I created earlier in this post. To do all this, we'll need to create a new plugin, so let's do that. Let's break down what's going on here in the code first. %Grab the initial inclination from the plugin variable value initIncDeg = pluginVarValues(1); initIncRad = deg2rad(initIncDeg); This bit grabs the value of the plugin variable, which we know is in degrees, and converts it to radians. %set the initial inclination in the initial state model's orbit model %Note: to work the initial state's orbit element set must be Keplerian. lvdData.initStateModel.orbitModel.inc = initIncRad; This bit sets the initial inclination of the mission to be the initial inclination from the plugin variable in radians. %Look up table for initial inclination to fuel in tank %Pretend launch latitude is 28 deg so that's where we get our highest %initial tank mass, with tank mass going lower as you go further north or %south. %This table could also be imported from a CSV file using csvread() or from %Excel using xlsread(). %Table Format: [Initial Inc (deg) | Init Tank Mass (mT)] xv = [0 3; 28 3.5; 90 3]; Here I generate a very simple look up table, with inclination (in degrees) in the left column and tank mass in the right column. Note that you could eventually set all this up so that this table reads in from a CSV or Excel file. You definitely don't need to be hand coding it into the plugin like I'm doing here, but this is just a toy example. %Use linear interpolation to compute the initial tank mass initTankMass = interp1(xv(:,1), xv(:,2), initIncDeg); This bit here sucks in the look up table and linearly interpolates it using the initial inclination in degrees to find the initial tank mass of our upper stage. The function "interp1" in MATLAB is used for 1D interpolation. %Set the initial tank mass lvdData.initStateModel.stageStates(1).tankStates(1).tankMass = initTankMass; And finally, I take the interpolated tank mass and I put it in the initial state in the right place. Note that the Plugin Data Explorer is super useful here for figuring out what's in the mission's data (the lvdData variable) that I've referenced a few times. Use the button in the bottom right of the Plugin Manager UI to access it. The last big thing to do is activate the plugin so it runs! First, the "Enable Plugins" checkbox in the bottom right must be checked. Then, we know we want this to kick in before propagation occurs so that the initial inclination and tank mass are updated before the propagation engine does its thing and propagates the trajectory. To do this, we check the "Execute Before Propagation" checkbox in the upper right. After setting up this plugin and a few constraints for a target orbit, we can run the optimizer and see that it selects an inclination to maximize the final mass! Note that the selected inclination isn't the target inclination of 45 degrees, which implies that our optimizer is trading off some initial inclination for a higher initial tank mass. And mission accomplished! This will be a new feature in PR7, and I'm going to make this MAT file an LVD example file for the upcoming release (and I'll put it in the PR7 build too). Any questions?

Okay, this bug was a pain in the neck that drove me insane for a few hours but I think I've got it figured out. I see the Minmus encounter too now. As usual it was a single line of code that, in this case, was missing. Ah well lol. I've updated PR6. Can you check this new version out and see if it fixes your bug? I believe I see it's fixed over here.

No worries! It's probably some weird visualization thing. Next time it happens please check the ksptot.log file and see if there's anything in there you can share with me. Btw, PR6 has been updated again with fixes for the two bugs that were reported yesterday.

I couldn't reproduce the bug you showed. Does this happen consistently? Did you change anything in your LVD or KSPTOT settings that might impact this? Are you using RSS like gravity or something else? RSS-like gravity uses the sum of the parent's gravitational parameter and the current body's gravitational parameter to compute the effective gravitational parameter of the parent body. I would just stick with KSP-like gravitational parameters unless you know what you're doing, it can be a little unintuitive otherwise..

I believe both of these bugs are fixed. I will upload a new version of PR6 tomorrow. Thanks for the reports!

Thanks for the report, I've fixed the bug. About 5 minutes after this post you can re-download PR6 to get the fixed version.

This bug should be fixed in the re-upload of PR6 that I recreated tonight. Can you check it out and tell me if it worked? Sorry it took 10 months to stumble into a fix...

Thanks!

Hi everyone, The other day the latest release of MATLAB, R2022a, was released. I've been trialing it and I see that I'm actually getting a pretty decent speed boost in LVD, perhaps as much as 10% faster when running cases. Could I get some help in evaluating if this is more than just something I see? Here's what I need some folks to do in order to help: Download and install the R2022a MCR package. Download the latest (R2021a) pre-release. Download the same pre-release but for R2022a. Run the KSPTOT executable in the R2021a PR: Open up LVD. Open the LVD MAT file contained in the R2022a pre-release. Tap control-p 10 times in order to run the script. Wait for th script to finish running between each tap. Copy the output window text. You should see a bunch of lines with data concerning how long the script execution took. Now run the KSPTOT exectuable from the R2022a pre-release and repeat the process for this new executable (open LVD, load the MAT file, run the script 10x, etc). In this thread, please copy/paste the two outputs and also provide your CPU and how much RAM you have. Please let me know if you have any questions. Thanks, everyone!

I'm glad it's working for you! Please let me know if you have any other questions.

How many times did you try to run the optimizer? The genetic algorithm underpinning things is semi-random and it's not unusual to see different results from run to run.

You're welcome.

It's pretty straight forward! Just load the bodies.ini file with your planets in it, open up the Multi-flyby Maneuver Sequencer, and set it up like this: The big thing is to make sure the Earth to Earth segment has a max number of revolutions greater than 0. Here I used 2. Tap the "Compute" button and away you go. Let me know if you have any other questions.

Glad to hear it! I updated KSPTOT v1.6.9 pre-release 6 with a fix for your Mission Architect bug. Could you try it out and let me know if that resolves your issue? Thanks!

Select the event you want to edit so it's highlighted. Then right click the name of the event you want to edit. A pop up menu should appear and its first entry will be "Edit Event". As an example:

I'm working the bug you mentioned in MA now and I'll put out an update pre-release soon (probably tomorrow at this rate) with a fix. As for LVD, please see my last post.

Hey, this is a known issue with the App Designer GUI environment at the moment. To edit an event that doesn't seem to be working, right click the list of events and select Edit Event in red. Sorry about the confusion.

There really isn't, sadly. In LVD it'll either be the body named Kerbin or the first body in the list. Otherwise, in some other places it could be the first body in the list or the third body in the list (Kerbin is the third in the default list). Sorry for the inconsistency here, I wrote all this code over the course of 8 years so sometimes things aren't always as they should be.

This is done for the next release.