Arrowstar

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!

Yep, it's a combination of two things probably: The zero-radius SoI assumption that goes into MFMS and most of the other sort of similar calculations. Basically, KSP models actual, finite-sized SoIs when the game is running, but MFMS and other similar tools just assume that the SoI radius of Earth is 0. This simplifies a ton of math but introduces some error; and It's possible that something funny happened with the code that tries to sync up the mean anomaly of your vehicle at the start with the departure mean anomaly to figure out how long to coast before burning. I would try to hit the departure true anomaly and not worry about the time so much, to be honest. The true anomaly is going to be more accurate. If you can create a high-res video that shows what you described, please do! I'll take a look and see if anything is broken. Thanks!

Thanks for the shout out! Yes, KSPTOT can do all sorts of fun stuff, including what @Razgriz1 mentioned and more. Anyone interested should come visit us on the KSPTOT forum thread for more information and to get help in learning the software.

Thanks, @Drew Kerman! This is basically correct. @dlrk, if you have any particular questions, please let me know. Thanks!

By the way, if you re-download your file that I provided back to you yesterday, you'll see that I've managed to find an even better solution that saves something like 3 mT of propellant. I did this by: Perturbing the trajectory by 1% or so a few times; Switching the optimizer to NOMAD and letting that run until it had converged on something, more or less; and then Switching back to FMINCON and using the SQP algorithm to get the final trajectory. Take a look and let me know if you have any questions.

Thanks for sharing KSPTOT! I'm the author. If anyone is interested in modeling fun 3/4/N body orbits in Launch Vehicle Designer (LVD), please be sure to grab the latest pre-release of KSPTOT, v1.6.8 PR9. You'll also need to download and install the MATLAB Compiler Runtime R2021a. Let me know if you have any questions!

Yes, the purpose of the constraints is to tell the optimizer to achieve particular things about the trajectory while also trying to minimize or maximize some quantity. The purpose of scale factors is to make the numerical side of the problem easier for the optimizer. Optimizers like to have objective functions and constraints whose values are between -1 and 1 generally. (They also like to have variables whose values are between -1 and 1 too, but I actually handle that under the hood without the user needing to worry about it.) Scale factors work by dividing the actual value of the constraint by that number. It has the added value of making the value of each constraint roughly the same order of magnitude when the optimizer sees it, meaning that you won't have some constraints be "more important" than others just by virtue of their natural numeric magnitudes (e.g. position vector values are usually a lot bigger than velocity vector values). Oh yes, I did forget that. I just set the propagator back to Force Model. You could achieve a similar effect by setting the integrator output step size to a positive number, maybe 10000 seconds for the longer coast periods. Yes, that's the one.

I've fixed up your mission a bit. Here's what I changed: I set the objective function to be maximize total spacecraft mass. You had it set to minimize, which would try to make the optimizer use more fuel. I set the constraint scale factors. The position constraints got scaled by 1E5, the velocity constraints by 10, and the time constraints got scaled by 1E6. This is really important to do in order to make FMINCON work better. I set the Events Plotting Style to "View All" and not "View By SoI Grouping". This way you can see all events in one go, which is really helpful for these kinds of missions. You edit this in the View settings. I ran the optimizer (FMINCON) and let it converge, which it did fairly quickly. Here's your mission back. Let me know if you can't open it in LVD (if it throws an error or whatever). I'm using what's basically v1.6.8 pre-release 9, which I would highly encourage you to download and try out if you're not already.

The Epoch of the Set Kinematic State action in Event 7 is 0.0 seconds. This is where that is coming from. You'll need to adjust this to get things to line up.

Well that is the weirdest thing in KSP I've ever seen. Negative inclination makes no sense and shouldn't be output. Mind if I submit your save file as a bug report? In the mean time, you can use this state in KSPTOT. It should be equivalent to what's in your save file. Keplerian State Time: 63961720.905 sec UT SMA: 43822373.630 km Ecc: 0.628969614 Inc: 12.292 deg RAAN: 180.000 deg Arg Peri: 180.000 deg True Anom: 327.499 deg Frame: Inertial Frame (Origin: Sun)

Can you share the save file and tell me which comet it is you're trying to go to?

The reason your propagation is taking so long is because you're coasting for 6 days in low Kerbin orbit. This is a big no-no. Adjust the start time of the simulation forward so that you only have to coast for ~1 or ~2 revs in LKO. EDIT: Also, on event 7, I think you misunderstood what I had written before. Your C3 needs to be positive when you set the kinematic state. Yours was negative and so you were just orbiting Kerbin for many days. Change the bounds to positive 0.001 to positive 10 and the C3 energy to 1 (or whatever) to start. The case runs much more smoothly when you do this (not to mention you actually will get a result...). EDIT 2: A few other things for you to check on: There are a few events which you intended to propagate backwards but actually they went forwards. Your Eve periapsis state is actually defined around Kerbin, so go ahead and change the reference frame to fix that. Your Eve periapsis state has a weirdly low Rp lower bound. Set this to 800 and make the upper bound like 2000 km or something. You don't want to get too close to the center of mass of a planet, it messes with the integrator.

I don't think your file worked on Google Drive. It's showing up as 0 bytes. Can you check that?

I'm going to need a bit more information. Do you get an error? Can you provide the LVD MAT file and what you're trying to enter (with a step by step process)? Universal elements are probably not a standard element set, it's just what I and some coworkers call them. They are useful for defining hyperbolic orbits. They are the same as the Keplerian orbital elements you found except: SMA is replaced with C3 energy. C3 is a measure, in some sense, of total mechanical energy of the orbit. It is positive when the orbit is hyperbolic and negative when the orbit is elliptical. See the Wiki article I linked for more information. For flyby orbits, constrain to be above 0.0 km^2/s^2 (I usually use the following range of C3s for lower and upper bounds: 0.0001 to 10). Eccentricity is replaced with radius of periapsis. This is useful because we generally know the flyby periapsis we want or at least a minimum (don't hit the surface!) we want. True anomaly is replaced with the time past periapsis. This is positive if you've flown by the periapsis point and negative if you're still coming up on it. Set to zero to get the minimum flyby altitude for a flyby orbit. Hope that helps! Let me know if you have any other questions.

Here's roughly what I would do in this case: Use the porkchop plot function in the main KSPTOT window to figure out your departure and arrival times. Use Kerbin instead of the Mun here. Use Launch Vehicle Designer (LVD) to put together the mission plan starting in low Mun orbit and going out to a Dyna flyby or orbit insertion. I've done step 2 for you as a template you can use for yourself. Take a look at this file in LVD and poke around to see what I did. Basically I just start in Munar orbit, put in a coast to the departure delta-v, and coast outwards to some point in interplanetary space. I then jump to Duna, optimize the insertion orbit, and propagate backwards to the same point in interplanetary space. Constraints ensure that the forwards and backwards propagated trajectories meet up at the same time with the same position and velocity. Let me know if you have any questions!

Sorry about the delay, it's been a very busy week for me. The general idea is that at each flyby, you create a flyby periapsis state and then propagate it backwards (to the previous flyby or the Kerbin departure orbit) and forwards (to the next flyby). You then constrain for position, velocity, and time continuity at the points where each forward propagated deep space trajectory meets up with the next backwards one. I call these points "patch points." The flyby state is optimized and defined using universal elements. You generally constrain the C3 to be greater than zero (plus a small bit), set the minimum radius of periapsis to be above the atmosphere, and allow the inclination, RAAN, and argument of periapsis to vary. The time past periapsis should not be constrained and should be set to 0.0 seconds. Optimize the time of that state as well, maybe +/- 10% of what comes out of MFMS. As an initial guess for each flyby state, use the flyby orbit that comes out of MFMS. You might need to convert the SMA and eccentricity to C3 and radius of periapsis, but this isn't hard: the math is on Wikipedia or you can enter the MFMS orbit in Keplerian elements and then switch to universal elements. It should do the element set conversion for you. Make sure to optimize the flyby orbit as I described because what comes out of MFMS will not be perfect. Does that help any? Have you made any progress? You want to find the maneuvers that minimize the total fuel expended. Optimization functions need to be numeric in nature and not just "do this thing." You define the thing you want to do (in this case, flyby Eve) by the structure of your mission profile.

I'm developing on R2021a and I haven't seen this issue before. Weird! Can you verify that "C:\Program Files\MATLAB\MATLAB Runtime\v910\toolbox\matlab\funfun" actually doesn't exist? How far up the path do you need to go before you get to a folder that does exist? Also, when you reinstalled it, did you redownload or just reinstall from the file you had? I see that the MCR has been updated to R2021a Update 2, which could fix the issue maybe.

Yes, you can definitely start in orbit. Just adjust the Initial State of the vehicle as desired. Hi everyone, Tonight I've build KSPTOT v1.6.8 PR9. Here's the change log: 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. Resolved bug with state caches for numerically integrated celestial body states. @Razgriz1, this should resolve the issue you mentioned earlier about the celestial body state cache. Please let me know if you find any bugs, especially in any of the new LVD user interfaces! Thanks!

1) There is a tutorial for LVD but it's old and probably more than a bit outdated. I wouldn't look too closely at it at this point. 2) I would actually use LVD for what you're trying to do. It has some nice functionality for implementing flybys. Take a look at the example mission case "lvdExample_ToEelooViaJool_BackPropExample.mat". The idea is to use forward and backwards propagation in order to create patch points in deep space that are easier to optimize to. Study that mission file and feel free to ask any particular questions! It's not too hard to put something together actually.

This looks like an issue with the MATLAB Compiler Runtime. If it's repeatable, can you redownload and reinstall the R2021a MCR? Hopefully that will clear up the issue.

Bug fixed for next release! I ended up needing to process the body data in descending order down the solar system hierarchy (Sun, planets, moons, etc) in order to make sure that when the inertial reference frame for the body being processed is figured out, the parent body's data is already there. Thanks for the report!

Please share the bodies.ini file you generated. Thanks!