Arrowstar

Hey sure! I know that LVD can be a bit more challenging to use because, as you said, it does have a ton of options. This is what makes it super powerful, but I do realize that it increases the learning curve a bit (or a lot lol). For what it's worth, I've done a decent job (IMHO) of picking decent default options for things, so usually you don't have to get down in the weeds unless you really want to. Here's how I would go about your Kerbin to Jool mission. Please grab the most recent pre-release of KSPTOT before starting. The general plan is this. We're going to create the initial Kerbin orbit state, then propagate in Kerbin orbit for a bit, use an impulsive delta-v to send us on our way, and then propagate forwards in time to a point about halfway between Kerbin and Jool. The magic then happens next: we are going to jump forwards in time to the Jool periapsis point and then propagate backwards in time to that same half-way point in space. We'll constrain our mission to make these points have the same time, position, and velocity, and we'll maximize the spacecraft mass at the end of the mission at the same time. Use the porkchop plot in the main KSPTOT UI to figure out when to depart Kerbin and arrive at Jool. I found 4291060.8566 sec UT and 25862156.6544 sec UT for those times, respectively. Then tap the Compute Departure button and get your departure delta-v. I got 1800 m/s prograde, 1541 m/s normal, and 256 m/s radial DV. Open LVD. Open up the Initial State dialog (Scenario -> Edit Initial State). Set the Frame Type to Body Centered Inertial. Click Frame Options and select Kerbin as the center of the frame. Set the Epoch to 4291060.8566 seconds. Click the "Opt?" checkbox and then in the first (left, lower bound) textbox enter 4291060.8566/2. Enter 4291060.8566*2 in the right (upper bound) textbox. You'll see that the textbox automatically does the math and evaluates those expressions to the numbers they work out to be, so that's normal. Set your departure orbit to whatever you would like. I used a circular orbit at an SMA of 700 km, but whatever you need is what you can do. Save and close the initial state dialog box. It's time to make our first three events to depart Kerbin: Event 1: Tap the Insert Sequential Event button on the main LVD UI. The Edit Event dialog box appears. Name the event "Coast to Departure DV". Open the Termination Condition dialog box. Enter 2000 seconds into the Event Duration line, check the "Opt?"box, and then 1000 seconds and 3000 seconds into the lower and upper bound textboxes. Save and Close. Save and Close the Edit Event dialog box. Event 2: Tap the Insert Sequential Event button on the main LVD UI. The Edit Event dialog box appears. Name the event "Departure DV". Leave the event termination condition at 0.000 seconds. Click the Add Action button and select "Add Impulsive Delta-v". A dialog box appears. Select the Orbit Frame (NTW) in the delta-v frame. Enter in your delta-vs from the Compute Departure tool into the three left textboxes. Check the three "Opt?" checkboxes. Enter 0 and 5000 for the lower and upper prograde bounds, -2000 and 2000 for normal bounds, and -1000 and 1000 for the radial bounds. Save and close. Save and close the event. Event 3: Tap the Insert Sequential Event button on the main LVD UI. The Edit Event dialog box appears. Name the event "Coast to Jool (+)". The "+" tells me that the event is propagating forwards in time. Tap the termination conditions button again. Enter "10800000.0" seconds into the event duration box, check the "Opt?" box, and then "10800000.0/2" into the left (lower bound) textbox and "10800000.0*2" into the right (upper bound) text box. Save and close. Make sure "Forward Propagation in Time" in selected in the lower right, and "Consider SoI Transitions" is checked. Save and close the event box. Now that we've created the events propagating away from Kerbin, it's time to create the next two that propagate backwards in time from Jool. This is a radical idea but you'll see how powerful it can be, and it's something you could not do in MA at all. Event 4: Tap the Insert Sequential Event button on the main LVD UI. The Edit Event dialog box appears. Title the event "Jool Periapsis State". Set the plotting type from Plot Continuous to Skip First State (three lines below the name). Tap Add Action and select "Set Kinematic State". The dialog box appears. On the Time Tab: Enter 25862156.6544 seconds, check the Opt? box, and then enter "25862156.6544/2" for the lower bound and "25862156.6544*2" for the upper bound. On the Orbit State tab: Set the Element Set to Universal Orbit Elements. Set the Frame Type to Body Centered Inertial. Set the Frame Options to Jool. Set your initial C3 to 5 km^2/s^2, check the Opt? box, and set your lower and upper bounds to 1.0001 and 20.0. Set your radius of periapsis to 7000 km. You can actually use whatever here so long as it's above the atmosphere of Jool, 6200 km. Set your inclination to 0 deg, check Opt?, and set bounds to 0 deg and 180 deg lower and upper respectively. Set RAAN to 0 deg, check Opt?, set bounds to -360 and 360 deg. Set arg peri to 0 deg, check Opt?, set bounds to -360 and 360 deg. Set time past peri to 0 seconds and DO NOT check the Opt? box. Save and close the Edit Action dialog box. Save and Close the event box. Event 5: Tap the Insert Sequential Event button on the main LVD UI. The Edit Event dialog box appears. Call the event "Coast to Jool (-)". The "-" means we are going to propagate backwards in time to me. Open up the termination conditions box. Set the event duration to 10800000 seconds, check the Opt? box, and set the lower and upper bounds to 6480000.0 seconds and 25920000.0 seconds, respectively. Save and close. Set the propagation direction drop down menu to "Backwards Propagation in Time" in the lower right. This is very important! Save and close the event dialog box. The next step is to create constraints for the optimizer that will make the trajectory continuous. To do this, right click the Sequential Events list, and select Create Continuity Constraints option. A dialog box appears. Make the first event Event 5 ("Coast to Jool (-)") and the second event Event 3 ("Coast to Jool (+)"). Select the Time, Position, and Velocity checkboxes. For time, set the scale factor to 10000000 seconds. For position, set the scale factor to 100000000 km. For velocity, set the scale factor to 10 km/s. Save and close. You should get a dialog box with a green checkbox saying constraints were created. Now we just need to create an objective function to minimize fuel usage. On the main LVD UI, Optimization -> Edit Objective Function. Click the Add Obj. Function button. Select the event to be Event 4, the Jool Periapsis State. Set the Scale Factor to be 10. Set the Optimization Type to be Maximize. Save and Close. Now we just optimize the mission! Optimization -> Optimize Mission. This should, in theory, end with all constraints satisfied and a decent objective function value. If you would like to see how I set up your mission, go ahead and load this MAT file into LVD. If you want to keep going in Jool orbit, keep adding events in the order I described above. First propagate forwards in time, then use a Set Kinematic State action to jump to the next periapsis point or other point in space, and then propagate back in time to meet up in the middle of empty space with continuity constraints. Let me know if you need any help! I'm happy to.

Can you check your KSP and KSPTOT log files to see if any errors show up when you push the Create Bodies File menu?

Yes! If you set your inclination, RAAN, and argument to match those in the departure orbit, your departure delta-v should drop considerably.

Hi everyone, Tonight I've built KSPTOT v1.6.9 pre-release 4. Here's the change log: LVD: Added functionality to the script event list right click context to convert Add Impulsive Delta-V actions to finite burns. LVD: Final and initial spacecraft state displays now show earliest and latest state and not first and last state in state log. LVD: Added new UI to fine-tune creating continuity constraints. LVD: Added gravity only RKN1210 high precision integrator. LVD: There should be a 5%-10% performance increase when running scripts for most scenarios, especially those that make use of 3rd body gravity. All single UI apps (MFMS, RMS, etc) now display their central body spheres with the texture and not the colormap, if available. A few misc bug fixes. As always, please let me know if you find any bugs or have any questions! Happy orbiting!

Okay so at this point, when you open up LVD, what works and what doesn't? Do any of the other tools in KSPTOT exhibit any issues?

I wasn't able to reproduce this on my Linux VM. Can you try closing KSPTOT entirely and then reopening it. Immediately go to LVD and then the Halo Orbit Constructor tool. Do you still get the error? Evidently there's a limitation in Linux MATLAB where you can't change the OpenGL rendering method on Linux systems during runtime like you can in Windows. For now, just leave that setting where it is. If that doesn't work for you, then I'm guessing it could be the OpenGL stuff on your system. Investigate into that, and keep me in the loop as far as error messages you get go. I can help investigate them.

As far as the solar system goes, yes, you can import exactly what's in KSP. You'll need to have the KSPTOTConnect plugin installed in the Gamedata folder (it ships with KSPTOT). Then just open up to the Flight Scene (basically, a rocket on the launch pad or in space) and then in KSPTOT, on the main UI, use the File Menu -> Create New Bodies File from KSP. Follow the prompts. As far as time goes, KSPTOT uses "universal time" under the hood for everything. So the year/day/hour/minute/second equivalent times might not be correct, but the UT will be because that's how KSP does it internally too. Yes, it's definitely possible in KSP and you can definitely model it in KSPTOT. Start with finding your flyby sequence in Multi-Flyby Maneuver Sequencer (MFMS). After that, you can export your trajectory to a binary file in MFMS and import it to Launch Vehicle Designer (LVD). You'll need the latest v1.6.9 pre-release 3 for this functionality (see above). Once you do that, you can optimize the trajectory to your heart's content and model the various tanks, engines, and dry mass on your vehicle (plus a bunch of other things!). Let me know if you have questions when you get to this point. Any other questions? I'm happy to answer any you have.

Okay, thanks! So I'm actually going to encourage you to work with Launch Vehicle Designer instead of Mission Architect. LVD is basically everything I had hoped to make MA and a lot more. It's just a far more powerful tool, and while the learning curve is a bit steeper, it's way, way more powerful. You're welcome to post questions here and I'll do my best to help if you'd like. Anyway, glad it's working now!

Oh goodness, that is... bad lol. Okay, some questions first: What operating system are you using? What is the resolution of your monitor set to? Does this happen with any of the other tools/UIs or just Mission Architect? Mission Architect is the only UI I didn't port over to the App Designer framework because it's "bug fix only" for me at this point. In your KSPTOT log, what does the header say for the version of MATLAB you're running? To answer your question, yes, there is actually a way for you to run the command yourself. Do the following: Open up Launch Vehicle Designer. Find the Plugins menu and click Manage Plugins . Create a new plugin with the button on the left. Copy/paste the code you created into the code editing area in the middle. Keep in mind that it's two lines there, and we don't include the ">>". That symbol is just the command prompt. So basically just the following, keeping in mind that you may need to play with that 1.5 number. s = settings; disp('Old Display Scale Factor:'); disp(s.matlab.desktop.DisplayScaleFactor.PersonalValue); s.matlab.desktop.DisplayScaleFactor.PersonalValue = 1.5; Check the box on the right that says to run the plugin before propagation. Check the box on the lower right which activates plugins. There should be a red area that appears when you have plugins activated. Save and close the plugin editor. Propagate the script (control-p). When you are finished with your plugin, your Plugin Manager should look something like this. You might need to restart MATLAB at this point. Can you tell me what happens when you do everything I've described? You probably also need to follow Step 2 in the Accepted answer of this post to calibrate the system DPI. Basically: Please let me know if any of this helps, as well as the answers to my questions above. Thanks!

Hi everyone, I've just build KSPTOT v1.6.9 pre-release 3. This primarily includes the new MFMS data import functionality that I described the other day. I would certainly appreciate if anyone who uses MFMS and LVD could try out this functionality on their end and see if there are any breaking bugs. I have tested the functionality on both the stock solar system and the JNSQ solar system and everything seems to be in order. Here's the change log: MFMS: Inclusion of a new button on the UI that allows for binary data from the last run to be exported to file. LVD: New menu item to create a new mission scenario from MFMS binary data. MA/LVD: Initial state and final state shown in the UI are now the earliest and last (chronological) state in the state log, as opposed to the first and last state log entries. This is important in LVD because of the ability to use Set Kinematic State actions to move around in time, and because propagation can be both forwards and backwards. The Edit Constraint UI now shows the current scaled value of the selected constraint. Please let me know if you find any bugs! Happy orbiting.

Haha, well, I'm glad I could come up with a tool that makes things a bit easier! I look forward to seeing what you come up with for new missions.

Two of the big questions that I always seem to get from new users of KSPTOT and specifically the Multi-flyby Maneuver Sequencer (MFMS) are something in the form of: Why doesn't my MFMS trajectory match what I see in KSP? How do I actually execute my MFMS trajectory in KSP? Unfortunately, while MFMS is excellent for exploring the multiple gravity assist problem trade space, it was never designed to really be used in operations. What was designed to be used in operations, however, was Launch Vehicle Designer (LVD) and its higher fidelity orbit propagation models. Thus, the usual advice for people stuck on these two questions in the past has been "recreate your MFMS trajectory in LVD." Needless to say, this is sort of an ominous task for the beginner as LVD isn't the easiest to use. Today I want to introduce a new tool that will make the process of recreating your MFMS trajectories in LVD much, much easier. Say you start with this Kerbin-Eve-Jool-Eeloo flyby trajectory. Up until today, you basically had to import the trajectory by hand into LVD. This involved creating all of the events and initial state by hand, setting the variables, defining constraints, and everything else. It was definitely time consuming. Notice, though, the new button in the lower right portion of the window that reads Save Results to File for LVD. If you push this, it will prompt you to save a binary (MAT) file with the data generated from the last MFMS run. From there, all you have to do is open LVD up and use the File -> New Mission from MFMS Output menu option. When you do and select the file you just created, you'll see something like this: Well hey, that looks pretty close to the MFMS output! You'll notice that all of the legs of the trajectory have been imported, but they don't quite line up. You can see some discontinuities in the trajectory. If you mouse over the warning about optimization constraints being violated, you'll see that there's a bunch of continuity constraints that need to be brought in. You'll also notice that there are variables in the mission script. Were you to investigate these, you'd see that each impulsive delta-v, each leg's propagation duration, and each flyby periapsis state already has optimization variables associated with them. There's also a "maximize mass" objective function created too. Really, all you need to do at this point is scale the constraints properly and optimize the mission. The whole process has been reduced from 1 hour or more of event creation to just a few minutes at most (and when you get good, I think it's probably closer to just one minute or less). Anyway, after you let the optimizer run for a bit, your finalized mission plan should come in nicely. (Note, in the image that I show here, I imported a slightly different MFMS trajectory because I've been testing with this one. You get the idea though!) Pretty neat, huh? What do you all think?

There is not, sorry. Maneuvers are generated when it becomes necessary for two orbits to be connected in a way that can't be achieved through a passive gravity assist maneuver. Because this, in turn, is strictly dictated by when various bodies are arrived at, there's no way to artificially limit the number of maneuvers.

You found a bug! I've fixed it this morning in the v1.6.9 pre-release 2. Please download that and give it a try. It should hopefully do what you want. Thanks for the report!

You have a couple options. The "easy" way is to just use the departure and arrival dates in MFMS and plan the maneuver nodes yourself, knowing that you want to leave and arrive on certain days. This takes a lot of hand tuning but is procedurally straight forward. The "medium skill" method is to right click on the DV Maneuver Info text box to upload your departure maneuver node to KSP. You'll have to do the rest of the maneuver nodes yourself, but it'll work. The "hard" way is to use the information from MFMS as a seed for Launch Vehicle Designer and, using LVD, put together a high fidelity simulation akin to the "lvdExample_ToEelooViaJool_BackPropExample.mat" example LVD mission that I provide with KSPTOT. If you're new to the idea of mission planning, try the first way for now and just try to get the departure and arrival times in KSP to be close by hand adjusting your maneuver nodes. You're also looking to make sure that your post-flyby orbit around the Sun looks generally pretty close to what is shown in MFMS. Once you've tried that, let me know if you want help with any of the other more challenging methods and I'll answer whatever questions you might have. Hope that helps!

Hey everyone, I've found a bit of a flaw with the system that computes the shadowed sensor volumes for the conical sensors. I have corrected it, but unfortunately it means that conical sensors are limited to 90 degrees max half angle now. I'll explain more when I have a bit more time, but long story short, please download the PR2 release again to get the fix. Thanks!

It's pretty epic if I do say so myself.

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!