Arrowstar

This afternoon I've built KSPTOT v1.6.9 pre-release 2! This pre-release introduces the new Sensor system into KSPTOT's Launch Vehicle Designer (LVD) tool. Here's the change log: LVD: New Sensor system Model sensors attached to vehicles, ground stations, and other points. Detect sensor targets, defined as points or sets of points. Plot sensor data and output to XLS files. New actions to update sensor properties. LVD: The yellow "working" labels are now gone and have been replaced with a more modern looking notification area at the bottom of the UI, complete with spinning "busy" widget. LVD: View Settings UI is now properly resizable. Let's talk through how the new sensor system works in practice. In order to use the sensor system, you need to model at least one sensor and at least one sensor target. Both of these options are found under the new Scenario -> Sensors menu. When you select Edit Sensors from this menu, you'll see the usual add/remove/edit component dialog box that's used all over LVD. Go ahead and add a new sensor. You'll be prompted to select the sensor type (there is only one type at this time). When you select Conical Sensor, you'll be greeted with this UI. From here, you can adjust the size and range of the sensor, as well as whether or not the sensor is active at the initial state. You can also adjust the sensor's origin, which is always a Geometric Point. The scenario must have at least one geometric point to be able to use sensors. You can also adjust the sensor's pointing model, which describes which direction the sensor points. At this time you can either fix the sensor in the vehicle's attitude body frame or you can fix it in a Geometric Coordinate System. You need at least one geometric geometric coordinate system to use this last function. Next up we need to add a target. You add targets using the Edit Targets menu item in the same Sensors menu as before. There are three different kinds of targets available: Point targets These use one Geometric Point, turning that point into a single target the sensor can detect. Rectangular lat/long grid targets These are a rectangular grid of latitude/longitude target points at a certain altitude above a celestial body. Circular lat/long grid targets These are similar to the rectangular grid targets, but the grid is a circle, centered at a lat/long point with a certain radius, at a certain altitude above a celestial body. If you select the circular lat/long grid target option, you'll be greeted with the following UI. Options are generally self-explanatory here: select the celestial body, select the circle grid parameters, etc. You can draw a circle on the 2D map if you want to generate your parameters visually. Note that some points are displayed as if "found" and others as if "not found" so you can get a sense for what they look like. Finally, once you have a sensor and a sensor target, you can generate a sensor report from the Sensor Reports menu item. Select the sensor and the target you just created, select where you want the output files to be written to, and tap "Generate Report". This process can take some time as the sensor geometry and target locations are computed at every time step in the simulation. Once done, the Data Viewer tab will be populated and XLS files containing that same data will be generated. You are free to work with the data as you need to at this point. And that's all there is to it! As you're using this new system, please keep me in the loop if you have any features you'd like to see or bugs you find that need fixing. Thank you!

Yep, KSPTOT's Multi-Flyby Maneuver Sequencer can help find these mission plans. Let me know if you have any questions once you've got KSPTOT running.

Alright, here's a fun image for you all to look at. As it turns out, the sensor obscuration system works with celestial bodies other than the central body of the current orbit. In this case, I have a sensor on the surface of Kerbin (at KSC, of course) and I have a grid of sensor target points all over the surface of Minmus. Here's what the display currently looks like. See those big black cones in the middle of the big green sphere? Those are sensor shadows being created by the Mun (the big one, left) and Minmus (small one, right). Here's what the grid of points on the surface of Minmus looks like. Anyway, I'm working on a tool that will do the analysis of sensor data and provide XLS files out for the user. It turns out that in this particular scenario, we can actually get out what kind of coverage of Minmus KSC gets. The first ~4000 seconds of this plot represent time that KSC cannot see Minmus at all. The blue line you see represents the approximate instantaneous amount of the surface of Minmus visible from KSC, and the orange line is the total amount of the surface cumulatively seen by the sensor. Keep in mind that "the surface" here is represented by points that are 0.01 km off the surface of Minmus, and so we're not looking at the surface as a continuous thing, but rather sampling points near it for this analysis. I'll have more to show next week, but I hope this gets people excited about what's possible here. Let me know if you have any questions!

In this case, I had most of the math worked out before I asked people if they would be interested. Acutally getting it into LVD then was just a matter of writing the classes that do what you see based on the original development script. All the hard work was done before I asked lol.

Well obviously if you would like it, @Drew Kerman, then I think I have to implement it. These are some good ideas. I'll have to post a demo video in the SCANSat thread once I've got everything to my liking. Thanks! Speaking of demo videos, I've got an initial implementation into LVD! It's actually pretty slick to play around with. I'm going to have fun with this. Check it out.

Hey everyone, Tonight I've built KSPTOT v1.6.9 pre-release 1. This update is more or less purely cosmetic in that it finalizes the conversion of KSPTOT over from the old "GUIDE" UI framework to the new App Designer framework. Here's the change log: Converted all remaining maneuver planning tools to App Designer. Converted all remaining Launch Vehicle Designer UIs to Ap Designer. Converted a few misc UIs to App Designer. A few minor bug fixes. Note that Mission Architect and the KSPTOT Real Time System (RTS) UIs will not be ported over to App Designer, at least not at this time. If you're running the KSPTOT v1.6.8 release, could you please update to this new PR? It's functionally identical to 1.6.8, and I could use some help with testing the new UIs since as we've seen they are not always bug free. Please let me know if you find any bugs, and happy orbiting!

Alright, feature question for you all. Would anyone get any use out of being able to model spacecraft sensors in Launch Vehicle Designer (LVD)? I'm thinking things like cameras, x-ray telescope things, and the like. The idea would be that a sensor would be fixed to the spacecraft. Users could create sensor targets (either single points or lat/long grids on/above the surface of a celestial body) and Graphical Analysis could tell you when a target is in view and (for grids) how much of the grid has been viewed by the sensor over the course of the simulation. Some use cases I've come up with include: How much of that celestial body can I scan (think Scan Sat or similar mods) with a given sensor and orbit altitude in a given time? How often can I see a comm relay? For people who use that weapons mod, maybe there's a laser lock application? So a few questions. First, would anyone actually use something like this when they play KSP? Be realistic, as this could potentially be a lot of effort. And second, are there any other uses you can come up with that you might want to be able to do with this sort of functionality? For the visually minded, here's a concept of what it might look like in the display. Red sphere is the planet, green cone is the sensor field of view, and the green dots on the surface represent surface points the sensor can see. What do you all think?

Sounds good. Please do keep me in the loop regarding bug reports. I'm happy to fix anything my users find and I'm usually pretty fast at turning around bug fixes. Thanks!

No problem, glad everything is working better now. Thanks for the bug reports.

KSPTOT author here! Let me know if you need anything help with it.

Alright, go ahead and re-download from the first post again. Let me know if that fixes the issue. Thanks!

Thanks for the report. I think I've got all of them fixed and I'll get a new build out ASAP. Turns out they were pretty straight forward.

Hey there, @antipro! This is probably a question that's better off asked on the KSPTOT thread so we don't clutter up @Krafpy's thread here: That said, to answer your questions: The departure maneuver from Kerbin can be "uploaded" to KSP directly by right clicking the "DV Maneuver Information" text box. The other maneuvers can't be "uploaded" in that way, though it's something I could pretty easily add. There's a caveat though: the assumptions used in MFMS that make the calculations fast also simplifies the dynamics model quite a bit and there's going to need to be a fair bit of hand-tuning involved in order to get the maneuvers to work out. The better process flow is to use your MFMS designed trajectory as a starting point and then model the trajectory in higher fidelity using Launch Vehicle Designer (which, at this point, is less than aptly named since it does everything Mission Architect can do and more lol). LVD actually models the spheres of influence of the bodies, which MFMS and similar tools cannot do, and you'll get much more precise results. If you need help with this, check out the LVD example mission file "lvdExample_ToEelooViaJool_BackPropExample.mat" that ships with KSPTOT and ask questions over on the KSPTOT thread I linked to above. Thanks!

Thanks for the report!

Yes, you can do that, but you'll need to be very careful about trajectory continuity. You'll also need to re-optimize your flyby times, DSM times and delta-vs, and the rest of it, using the lower fidelity model as a starting point, because once you introduce the higher fidelity models, the answer will change. I think I maybe see a flaw in your thinking about this problem in general. Why do we use the zero radius SoI assumption, and the instantaneous flyby assumption, and Lambert arcs, and all that? It's because it lets us quickly explore the problem space, find reasonable trajectory concepts, and then implement them in a higher fidelity tool. No one in the "real world" uses software like yours or like my MFMS tool to actually plan a real mission: it's all about exploring the problem space. Once a trajectory engineer has identified a good trajectory, they always move up to tools that can provide higher fidelity dynamics, like my KSPTOT Mission Architect or Launch Vehicle Designer tools, and rework the trajectory there. Because of all that, while you can certainly add more fidelity to your code, at some point you'll have to break away from the Lambert arc assumption. By all means, definitely dive into handling finite sized SOIs and celestial body motion and finite duration flybys and the like! I just don't know how long you'll be able to keep your tool "simple" (and the underlying code simple!) if you do. It'll be an interesting science experiment to find out.

I believe I've fixed the issue and have uploaded the new executables. Can you go to the first post and re-download KSPTOT from the link there? Once you've done that, please let me know if that resolves your issue. Thanks!

Local gravity wells are modeled as zero radius SOI with instantaneous flybys. It simplifies the problem space down into a bunch of Lambert arcs while still producing reasonable results. If people want to model more accurate trajectories, that's what KSPTOT's Mission Architect (and really, Launch Vehicle Designer, which has mostly filled the role of MA for some time now) is for. LVD numerically integrates equations of motion to produce trajectories and can model discrete vehicle stages, tanks, engines, electrical systems, and can propagate forwards and backwards in time to help make it easier to find those multiple gravity assist trajectories.

Okay so I haven't had a chance to go through and really think about what you said earlier but I do have some thoughts. I'm not talking about multiple revolutions, I'm talking about the concept that every Lambert's problem, even the single rev cases, all have two solutions: one where the transfer angle is greater than 180 deg and one where it's less than 180 deg. If you're only using one of those solutions everywhere then you're going to have an issue because short way and long way can have radically different delta-v. Looking at the lambert code you're using, I think the input flag is the "const int &cw" input, though I've run into the ESA ACT's Lambert solver before and I've never been a big fan of their "clockwise" / "counterclockwise" notation. Anyway, what are you using for that parameter and have you tried changing it to verify that it works the way you think it does? I guess on top of that, you might consider playing around with the automatic bounding of the time of flight variables as well, if I'm reading your post correctly. It can be hard to pick generalized bounds that work for all cases. It might be worthwhile allowing the user to specify the upper and lower bounds for time of flight between bodies. That's all I've got for now, there's a lot of math to look at lol.

So I tried a Kerbin - Eve - Jool - Eeloo flyby with your software tonight and compared it to KSPTOT. I end up with a total mission delta-v of 2.5 km/s. Yours seems to settle pretty consistently around 5.5 km/s - 6.0 km/s. A few questions that might help debug a bit: How many individuals are in your DE population? How are you bounding the optimization variables? Does your Lambert solver consider both long way and short way trajectories?

By the way, everyone, I should mention that it's likely that we won't spend a lot of time on MATLAB R2021a. I've gotten a chance to play with the R2021b pre-release in a professional environment and there are some enticing new functions and functionality that I think I might want to bring into KSPTOT, especially Launch Vehicle Designer. I don't think I can say what right now (pre-release NDA) but when it releases next month I'll have a better idea of if it will be worth it. Stay tuned.

Hi everyone! This morning I'm happy to announce the release of KSP Trajectory Optimization Tool v1.6.8! This is a major release that primarily focuses on adding additional functionality to Launch Vehicle Designer (LVD). A couple of the more interesting new items in LVD are: The "Halo Orbit Constructor". This is a tool that allows users of Principia and other "N-body" gravity mods to generate approximations for halo orbit that can then be easily exported to the rest of LVD for mission design and planning purposes. The "geometry system". This is a component of LVD which allows users to define and work with geometric elements in their LVD scenarios for graphical/view, optimization, vehicle steering, and Graphical Analysis. You can read more here. Celestial bodies can now be numerically integrated. This is useful when using "N-body" gravity mods such as Principia as they don't use the two-body motion for celestial bodies that stock KSP does. This release also showcases the migration of many of the KSPTOT user interface windows to MATLAB's new App Designer framework. Finally, and perhaps most importantly, this release migrates KSPTOT to MATLAB R2021a! The new LVD UI in the App Designer framework Here's the full change log: LVD: The function to export a kOS CSV file has been updated to allow users to select the event(s) they want to export. LVD: Introduction of the geometry system. Points, vectors, planes, angles, coordinate systems, and reference frames are now all user definable and can be integrated with views, optimization, and Graphical Analysis. LVD: The "launch vehicle" menu is now called "scenario," and the "edit launch vehicle" menu beneath it is now called "edit vehicle configuration." LVD: Added three new constraints: ground object elevation, azimuth, and range. MA: Mission Animator now properly rotates central celestial bodies. LVD: Added a new vector, vector projected onto a plane, to the geometry system. LVD: A few bug fixes and performance improvements. LVD: T2W throttle model now checks minimum throttle T2W as well as maximum. LVD: Sim Driver now warns if integrator output event index (ie) is empty. LVD: When editing non-seq events, the event UI now greys out any non-relevant widgets. LVD: Added a flight path angle event termination condition. LVD: Added a new "vector magnitude" constraint type. LVD: Added a new "angle magnitude" constraint type. Upgrade MATLAB version to R2021a. LVD: Incorporation of surrogate optimizer as an optimization method. LVD: New optimizer output for NOMAD and PatternSearch optimizers. LVD: Different steering models can be selected for each Euler angle now using the Selectable Model steering mode. LVD: All constraints now support the ability to evaluate themselves relative to the value of the same quantity at the end of another event. This is in addition to evaluating them relative to fixed bounds as well. Fixed an issue with importing the UT from KSPTOTConnect into the main KSPTOT user interface (the porkchop plot). LVD: Bug fixes to the 3rd body gravity model. LVD: Bug fixes to optimizing Cartesian elements. LVD: Graphical Analysis is now using the App Designer framework and sports a new look. LVD: All fluid types are now their own GA tasks. Main KSPTOT user interface window is now ported over to App Designer framework. LVD: Constraints and objective functions now are aware of and respect user selected reference frames when evaluating values. LVD: Added halo orbit examples. The L2 halo orbit example is a full mission from low Kerbin orbit to the halo orbit around the Mun! LVD: Added third body gravity validator that checks to see if third body gravity sources are active with no force model or if the 3rd body gravity force model is active with no bodies. LVD: Extrema, Calculus Calculation objects, ground objects, and geometry objects now respect reference frames when computing their values. LVD: View Settings dialog now moved over to App Designer framework and sports a new look! LVD: Added Halo Orbit Constructor tool (Tools -> Halo Orbit Constructor menu) LVD: Performance improvements to frame conversions. LVD: GA task list area now has a search box. LVD: Formal continuity constraints are replaced with state comparison constraints for position, velocity, and time. LVD: Event termination conditions now have ref frame awareness. LVD: Halo Orbit Constructor now shows arrival/departure transfer orbits too. LVD: Event actions can now be executed before or after propagation on events. LVD: Constraints can now be evaluated at either the initial state or final state of an event. Same goes for the state comparison constraints and the node of the comparison event. Converted a whole bunch of the standalone analysis tools (MFMS, RMS, OTBOC, etc) over to the App Designer framework. Celestial bodies can now be propagated using numerical integration in addition to two body propagation. LVD: Added an Open Recent Mission item to File menu LVD: Migrated main UI and numerous other UIs to App Designer framework. There are still a number of LVD UIs that still need to be migrated, but this is a start. LVD: Plotting state logs should now be a bit faster due to updated frame rotation behavior. Added UI progress bars when opening all tools from main KSPTOT UI. LVD: Major change to the Set Kinematic State action and the associated GUI. You can now set the states of the individual vehicle components, including stages, engines, tanks (and their associated tank masses!), electrical powers sources, sinks, and storage (including battery state of charge). Astrodynamics Tools UI migrated to App Designer framework LVD: Edit Event UI migrated to App Designer framework. LVD: Edit Event UI now has buttons to cycle back and forth through the events list. LVD: Edit Event Termination Condition UI migrated to App Designer framework. LVD: Non Sequential Event UI migrated to App Designer framework. LVD: Plugins can now be used as objective functions, constraints, and graphical analysis output. LVD: All UIs should now render centered on the screen. LVD: Double clicking an available task in GA now adds it to the list of tasks. LVD: Outputting the propagation time to console now includes a breakdown of time needed for propagation and actions. LVD: Missing LVD cases don't show up in the recent cases list (File menu) anymore. Numerous bug fixes and performance enhancements, especially in LVD. NOTE: If you are upgrading from KSPTOT v1.6.7 or earlier, you MUST download the R2021a MATLAB Compiler Runtime (MCR)! KSPTOT v1.6.8 will not run without this! You can find the R201a MCR download for your platform here: https://www.mathworks.com/products/compiler/matlab-runtime.html Finally, if you enjoy using KSPTOT and its many applications (the Porkchop Plotter, Multi-Flyby Maneuver Sequencer, Mission Architect, Launch Vehicle Designer, and all the rest), please consider buying me a coffee via my Ko-Fi account to support KSPTOT's development. As I note in the first post of this thread, KSPTOT is a labor of love that I have put many, many hundreds of hours into for the benefit of the KSP community. The best part of it for me, aside from knowing that KSPTOT is the premier mission design tool for KSP, is all the thank you notes I've received over the years. I offer this as another way to say "Thank you!", if you so desire. 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!

Powered flybys are a bit challenging, I agree. The idea is basically to figure out what the delta-v vector at flyby periapsis is that connects your inbound and outbound trajectories. I admit it took me a few weeks of getting the math worked out back in the day, but it works well now. I've actually considered adding DSMs to my software but powered flybys work pretty well and I just haven't been interested in doing it yet. I use a genetic algorithm as well. I've tried a few global optimization algorithms but GAs (or DE, same thing basically) seem to work the best. I definitely found that Direct Search methods and MATLAB's "Global Search" methods didn't work nearly as well.

This is pretty neat, good work. It's interesting you went down the DSM route instead of the powered flyby route like I do in KSPTOT's MFMS tool. Was there a reason for that decision? Btw, did MFMS inspire any of this? It looks very similar in some ways lol.

Hi everyone, This morning I've built KSPTOT v1.6.8 pre-release 11. This is a relatively minor update to PR10 that includes some bug fixes and one new feature: LVD plugins can now be used as constraints, objective functions, and Graphical Analysis output. I'll explain more below, but here's the change log: LVD: Plugins can now be used as objective functions, constraints, and graphical analysis output. LVD: All UIs should now render centered on the screen. LVD: Double clicking an available task in GA now adds it to the list of tasks. LVD: Outputting the propagation time to console now includes a breakdown of time needed for propagation and actions. LVD: Missing LVD cases don't show up in the recent cases list (File menu) anymore. This is the last PR before the final v1.6.8 release and I consider this PR to be a release candidate for the full release. I could really use some help testing LVD to make sure there aren't any boneheaded bugs in it. If you find any, please let me know ASAP! Thank you! So let's talk about using plugins as constraints, objective functions, and as Graphical Analysis output for a bit. First, how does one go about setting up a plugin for use like this? It's quite easy really. Let's start with an example and I'll walk through it. The code for this plugin is as follows: %We can use comments in plugin code if(execLoc == LvdPluginExecLocEnum.BeforeProp) kGmu = lvdData.celBodyData.kerbin.gm; %get Kerbin grav parameter str = sprintf('This note was set by a plugin.\n\nKerbin GM: %0.6f\n\nPlugin last executed at: %s', kGmu, datestr(now())); lvdData.notes = str; %set the string in the notes field userData = struct(); %create a structure for use with user data userData.T = []; elseif(execLoc == LvdPluginExecLocEnum.AfterTimestep && not(strcmpi(flag,'init')) && not(strcmpi(flag,'done'))) arry = userData.T; arry(end+1,:) = [t(1), y(1)]; %add time and first element of state to the user data userData.T = arry; elseif(execLoc == LvdPluginExecLocEnum.AfterProp) writetable(array2table(userData.T),'test.csv'); %print user data to file test.csv elseif(execLoc == LvdPluginExecLocEnum.Constraint || execLoc == LvdPluginExecLocEnum.GraphAnalysis) ue = stateLogEntry.getCartesianElementSetRepresentation().convertToUniversalElementSet().convertToFrame(frame); value = ue.c3; end In all plugin code, the execLoc variable is used to tell the code where it's being executed. See the line near the bottom where we test the following: execLoc == LvdPluginExecLocEnum.Constraint || execLoc == LvdPluginExecLocEnum.GraphAnalysis? That is testing if the plugin is used as a Constraint (or objective function) or as a Graphical Analysis task. You'll notice that code block creates a value called "value" that is populated by the current C3 value of the spacecraft orbit. That's the output that will be used as a constraint or objective function or Graphical Analysis output. To use plugins in this manner, you basically need to populate a variable with the name "value" with some scalar double value. Note that all data in KSPTOT is in units of kilometers, seconds, radians, and metric tons. Finally, note that there are two new inputs into the plugin function call to be aware of. The final two inputs are "stateLogEntry" and "frame". The first is the relevant spacecraft state that should be used for evaluation. Basically, if your plugin computes C3 energy like mine does here, then it ought to compute the C3 for that state and that's the value that should be returned. Frame tells you what reference frame values should be computed in, if it's applicable. Using plugins in this capacity is just a matter of adding a Constraint or Objective Function of the type "plugin value." For example: You'll notice our example plugin is used here by selecting it at the top in the "Plugin" field. You must have at least one plugin available to create a plugin value constraint or objective function. Speaking of which, here's that same plugin used as part of an objective function. Finally, let's talk about using plugins as part of Graphical Analysis. If you have at least one plugin, you can create a task like this in GA: When we go to plot that task and compare it to actual C3, we'll see we get the same thing: This proves that our plugin is working correctly and is providing the same information as the built in data type. Of course we could have programmed our plugin to provide any data type! This was just selected as an example. So what do you think? Could this sort of functionality be useful to you? If so, how? Please let me know, and happy orbiting!

This afternoon I've built KSPTOT v1.6.8 pre-release 10. This is a pretty major pre-release update with the following changes in the change log: LVD: Major change to the Set Kinematic State action and the associated GUI. You can now set the states of the individual vehicle components, including stages, engines, tanks (and their associated tank masses!), electrical powers sources, sinks, and storage (including battery state of charge). Astrodynamics Tools UI migrated to App Designer framework Edit Event UI migrated to App Designer framework. Edit Event UI now has buttons to cycle back and forth through the events list. Edit Event Termination Condition UI migrated to App Designer framework. Non Sequential Event UI migrated to App Designer framework. The first bullet point on this list really needs to be checked by more people than me, so if you find any bugs, please let me know!