Arrowstar

Hey there, I'm the author of KSP Trajectory Optimization Tool. Please let me know if you have any questions about the tool, either PM or a message in the KSPTOT tread will work fine. The maneuver planning tools are pretty simple to get the hang of, and the full up mission planning tools are not too bad either once you get the hang of them.

I could probably do that, yup.

Hi everyone! This evening I'm please to have released KSP Trajectory Optimization Tool v1.6.5! This is a major update with a focus primarily on improving the Launch Vehicle Designer (LVD) experience. New optimization algorithms, integrators, and models are included for use in LVD. A few performance enhancements have also been incorporated. The goal is to allow the analyst even more flexibility in how trajectory problems are set up and solved. The highlights include: The inclusion of the NOMAD gradient-free optimization algorithm; The ODE5 integrator; All new optimization algorithm and integrator options; and The interpolated curve drag coefficient model. Here's the full 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. MA: Improved robustness of "coast to function value". 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). 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. LVD: 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. LVD: 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. LVD: New time, position, and continuity constraints for use with the set kinematic state action. LVD: FMINCON options now allow constraint, optimality, and step tolerances to go to 0. LVD: Objective functions are now "composites" of different functions. The values of these functions are added together in a fashion defined by the user. LVD: New plotting methods for events (applies to both the orbit display in the main LVD UI and graphical analysis plots). LVD: Minor performance enhancements to calculating atmospheric temperature. LVD: Resolves an issue with the true anomaly event termination condition where the directional termination was reversed from expected behavior. LVD: Added a pop out orbit display button to the main LVD UI. LVD: Added the ability to compute the gradient sparsity to the custom finite differences gradient method, which can improve optimization speed and accuracy in some situations. LVD: Added IPOPT to optimizer list. MA: Resolved issue with orbital decay on coast that was breaking it. MA: Resolved two issues with MA drag coefficient calculator that would slow down the calculations in some instances. MA: Marker type for mission animator added. Fix to SFS file read. Bug was causing some vessels to not get found in the file. LVD: Addition of a new propagator type, "Two Body Motion." This change also includes a number of backend reworks to incorporate a new way to propagate spacecraft orbits and a generic interface for adding new propagator types in the future. LVD: Changed drag model such that drag coefficient is now entered as set of points which are interpolated over. Drag coefficient data may be imported from a CSV file. LVD: Added a new, fifth order fixed step integrator, ODE5. See below for more information. LVD: Added drag area to graphical analysis outputs. LVD: Added Cntrl-F shortcut to remove or re-added event from optimization. MA/LVD: Resolved issue with plotting periapsis crossings. As usual, the release can be downloaded from the first post of this thread. Please let me know if you have any questions or find any bugs. Thanks, and happy orbiting!

Yeah, that could be helpful if you can figure it out. I haven't touched that code in a long time, though, so I'm surprised to hear that lol.

Oh is the flowrate of the engine constant?

Oh got it. I don't think that's going to be really fixable. MATLAB's 3D rendering capabilities are pretty simplistic and this appears to be related to that simplicity. I might be able to tweak it, but I'm not sure the rendering is going to look all that much better.

Thank you! Do you know where or how KSP interpolates thrust as a function of atmosphere density/pressure? In the engine data shown in the game, we see sea level and vacuum thrust levels, but these don't appear in your curves.

@Drew Kerman, have I missed anything you wanted in (that I haven't addressed)? I'm thinking we're getting close to the actual 1.6.5 release.

Looks like I removed that file from the package. I'm guessing that when I created the Vehicle Sizing Tool in KSPTOT, that spreadsheet (which did the same thing as VST and was its inspiration) was taken out. For the moment, just keep trucking on the tutorial. The spreadsheet was only informational.

Hi everyone! Could someone point me to resource(s) that define and document what the various curves that modify engine performance are and how they work? As of now I'm aware of the existence of with "atmosphereCurve", "velCurve", and "atmCurve". Are there any others? It would also be very helpful to know what the input and output of every curve is (with units) and how KSP applies those curves to its engine modeling. Does this information exist anywhere? Thanks!

Tangents doesn't look like it's going to be possible, sorry. The curve fitting code I use doesn't support them. That said, if you get the absolute values of the points in there, it should be close enough I would think for what you're doing. Give it a try, anyway, and see if it works.

Can you post a link to your bodies.ini file?

Not just you. I've been having some issues recently with MATLAB's packaging tool, and the error always seems to be that it can't find the icon for the software. I need to try and fix that for the next release.

Thanks for the report! You found a bug. Everything related to the new drag code should be backwards compatible. The code is supposed to take the old Cd values that are in the set drag action and update it to use the new interpolated scheme. The Set Drag action is definitely supposed to be around still. Anyway, I fixed the issue and I'm rebuilding the code now. I'll update the previous PR10 zip file with the fix when it's built and edit this post then. EDIT: Should be good to go, redownload PR10.

Hi everyone, Tonight I've built the KSPTOT v1.6.5 pre-release 10. Here's the change log: LVD: Changed drag model such that drag coefficient is now entered as set of points which are interpolated over. Drag coefficient data may be imported from a CSV file. LVD: Added a new, fifth order fixed step integrator, ODE5. See below for more information. LVD: Added drag area to graphical analysis outputs. LVD: Added Cntrl-F shortcut to remove or re-added event from optimization. MA: Resolved issue with plotting periapsis crossings. What's a fixed step size integrator? Thus far, all of the integrators available in LVD are part of a family of "adaptive step size" integrators. This means that the integrator automatically adjusts the size of each step it takes when running through the equations of motion in order to control of the integration error. On the other hand, a fixed step size integrator uses a predetermined step size to run through the equations of motion with no adjustment to control error. Why use a fixed step size integrator? Adaptive step size integrators are generally more accurate than fixed step size integrators. However, this often comes at the cost of high CPU cost for short integrations because the integrator needs to take very small steps initially in order to get a feel for the tolerance of the equations of motion. A fixed step size integrator, however, simply takes the step size associated with it, thus eliminating this cost. The take away is that for short integrations (relative to the time scale of the problem) where high fidelity is not needed, the fixed step size integrators can often outperform their adaptive step size cousins by non-trivial margins. The ODE5 integrator I implemented here was able to offer a 33% increase in total propagation speed in one of the example LVD mission cases with minimal loss of accuracy, just by selectively applying this integrator in suitable locations. How should I use ODE5? When building a mission, always start with the ODE45 or ODE113 integrators for your events. If you notice that your mission is running slowly, go through each event, right-click on the integrator drop-down menu, and select the option that lets you pick the fastest integrator. ODE5 should be reasonably fast for many short events, so pick that option when it's clear that it provides superior performance. After this, adjust the step size in the integrator options manually such that your final state for that event is roughly equal to what you were seeing with ODE45 or ODE113. How close is required is up to you as the analyst. A Warning I wrote the ODE5 integrator from scratch, it is not a MATLAB built in function. If you find any bugs with ODE5 when using it, please let me know. In particular, the event detection and output function handling is all me, so if events seem to be missing their termination conditions, please let me know. Step sizes that are too large can cause ODE5 to diverge and produce nonsensical results. This is a new behavior from the other existing integrators, where divergence basically could not happen because of the built in error control. If you notice your spacecraft trajectory doing weird things on an event with ODE5 enabled, shrink the step size until the solution stabilizes.

It only took 20 minutes so I added it. Right click on the listbox with all the points and select the Import CSV File menu that comes up. Your CSV file needs two columns. The first is the independent variable values, the second is the drag coefficient values. Any other columns are ignored. You must have at least two rows of valid Cd data.

Would CSV import into that listbox be useful then?

Tonight I want to share an update that is coming to the drag model within Launch Vehicle Designer. One of the items on my long term wish list has been to allow users to make drag coefficient a function of some independent variable. I'm pleased to share that I've finally gotten this together. Here's the new drag properties dialog box for actions and the initial state. The frontal area section is unchanged from what you have now. The big change comes in the drag coefficient section. Instead of a single number to enter, this section now lets you enter a list of points on a drag coefficient curve. These points are made up of drag coefficient values ("Y") at user defined values of the independent variable ("X"). The independent variable of the curve can be altitude, dynamic pressure, mach number, atmospheric density, atmospheric pressure, and body-fixed velocity. You can see the points currently entered in the list box to the left. The points are interpolated between using the selected method. Here in this picture, a particular type of cubic spline interpolation is selected. Other options include a linear interpolation and other types of splines. Extrapolation is always "nearest neighbor" so if you go off your entered points, the code will automatically use the drag coefficient at the highest or lower independent variable value that you provided. You can plot your curves to see how the interpolation will impact the currently entered points and interpolation method: The green diamonds are the entered points, the white line is the interpolation between them, and the nearest neighbor extrapolation is visible to the left and right extremes of the plot. I hope this adds some flexibility to LVD aerodynamics modeling and removes the need to create a ton of non-sequential events to update the drag coefficient manually. Let me know what you think!

Resolved for next release, thanks for the report.

Thanks! I've honestly never tried. I believe that 99% of the time it gets used locally, so this doesn't come up much. However, I can tell you that anything that "java.net.InetAddress.getByName()" can resolve can be used, as far as I can tell (see here for how I'm using it). Any idea if these ngrok addresses work with that? EDIT: I just tried it and it doesn't seem to work. If you have any insight into what I would need to do to make it work for you, let me know and I'll do my best to make it happen by this weekend. EDIT 2: I do know that it's port 8282 that the main KSPTOT RTS connection is through, but given my awful net code skills from years ago, each different connection type streams through a different port. I can get you the range if that helps. Hopefully this doesn't hinder the effort.

Added for next release. @OhioBob, @Drew Kerman: Yes, I was referring to @Drew Kerman modifying the throttle table in KSPTOT/LVD to accommodate the 0%-100% bounds on throttle via scaling the whole thing. Definitely no action required on your part, @OhioBob. @Drew Kerman, which four curves do you need? I have a post-it note on my desk with a long-term "TO DO" to add the other curves I'm missing, but I've never had any reason to do so because no one has ever needed them until now as far as I know. I could probably try to add them this weekend if it was useful...

Right now there's a fair bit of engine code that assumes that the throttle range is 0 - 100%. It would be a fir bit of effort to modify this. Could you scale the throttles in the code such that the maximum throttle with the booster is 100% and scale the other thrust points appropriately? Yep, I can look into this. It might be Cd*A though and not just area, but we'll see. I'm afraid not. The two time systems are somewhat hard-coded in there, so additional work would be required to add a new time system.

Okay, I see what happened. After 10 minutes from this posting, go ahead and redownload the ZIP file above. That should have the fix in it.

Here is KSPTOT v1.6.5 pre-release 9 with the fix for your bug, hopefully. Please test and let me know if the issue persists.

Do you have a ksptot.log file with an error message I can see? Thanks for the report. EDIT: Nevemind, issue resolved. I'll put out a new build tonight if I'm able. Sorry for the inconvenience.