Arrowstar

So it looks like you're in year 33 in game but the trajectory solution you have is in year 41. I would expect to see a very long wait until the burn because of that. The other thing you could be experiencing is that KSPTOT can use two time systems: Earth time and Kerbin time. You might have those set to different things between KSP and KSPTOT.

Can you take a screenshot of the maneuver upload display dialog box?

Hi everyone, This evening I'm releasing KSPTOT v1.6.10 pre-release 3. Here's the change log for this pre-release: MFMS: Implemented cancel button for the MFMS multi-run mode progress dialog box. MFMS: MFMS now computes departure delta-v for the objective function instead of departure C3 energy. LVD: Fixed a bug in the Set Kinematic State action where you couldn't use the set date/time UI. LVD: Implemented NOMAD 4.3.1 optimizer and removed NOMAD 3.9 optimizer. LVD: Main UI orbit display labels can now have their reference frame and element set configurable. LVD: NOMAD optimizer now can make use of the NOMAD surrogate library. See NOMAD optimizer options. LVD: Limited time slider updates to 20 Hz for smoothness. A number of bug fixes, both reported and not. Please let me know if you find any bugs or have any questions. Happy orbiting!

Thanks for the report. Can you clarify what you were doing when the error occurred? I tried to walk through what I think are the steps you took and I couldn't reproduce the issue. Thanks! I found and fixed this issue. Fix will be in the next v1.6.10 pre-release.

In other news, a few other improvements will be coming to v1.6.10 PR3. First, I've upgraded the NOMAD solver in LVD to v4.3.1. There should be some nice performance improvements in there. Second, I implemented the ability to change the reference frame and element set of the two orbit displays on the main LVD UI. Simply right click the display text to get the option to change things.

I wouldn't worry about the dates being too different actually. There are tons of solutions for the Kerbin-Jool transfer you're looking at. As long as you have a good one, it'll work out fine. For what it's worth, I'd use Launch Vehicle Designer instead of Mission Architect at this point. Despite the name, LVD is far more fully featured and is the code I'm actively maintaining at this point. Let me know if you have any questions.

Pretty sure I've got this one fixed but I'll check next week when I have more time to use KSP.

A few things: First, is there anything in the ksptot.log file that shows up when you run the software? Any errors or warnings? Second, could you show me a picture of the window with the RSS solar system data loaded into KSPTOT instead of the stock solar system? I'd like to try to recreate the issue you described earlier. To be honest, I'm still not entirely sure what's wrong, because the screenshot you provided does show plots and information in the text boxes.

How close are you getting? If it's close, you're running into the zero radius SOI assumption introducing some inaccuracies into the burn. All you need to do is tweak things slightly and it'll come in. If it's really off, then this is a case where your initial orbit definition (the mean anomaly and epoch) are probably off and it's throwing you out into space. Can you share some pictures or screenshots? Thanks for these! I couldn't reproduce the second one, but I'll take a look into the first. If you come up with more concrete steps to reproduce that issue, please let me know.

This, unfortunately, is an issue with MATLAB and not with KSPTOT. I've tried to work around it, but in general, when a figure's pan/zoom/rotate/etc tools are active, they block clicks to other UI elements, much to my chagrin. I can try to file a bug report with The MathWorks, but I suspect this one isn't getting fixed for a while. Fixed! Thanks for the report. It'll be in v1.6.10 PR3, which I'll look into releasing next week. If you can figure out how to reproduce it, please let me know. I've been running after bugs similar to this one for a bit and they've been hard to track down, though I have successfully fixed some cases where it occurs. Your reference image shows the state being defined in the Body Fixed Frame, but the states shown in the main LVD window are by definition in the inertial frame, which is why you're seeing a difference. It's my intention to let the user change the displayed frame and element set shown on the LVD window for both initial and final state, I just have to get around to it.

You don't need MATLAB to use this thankfully! You can freely acquire the MATLAB Runtime Environment from the install instructions in the OP. Install that and KSPTOT will just run. Good thing, too, because it would take years to reimplement KSPTOT in python lol.

Okay, thanks for the notice. I'll take a look!

Awesome, that's for the data. Are the years and days there Kerbin or Earth years and days? I will see if I can't find this trajectory in MFMS. Something I should look into is a quick method for determining the departure delta-v. Any idea how that tool computes it so quickly?

Okay, so the issue is in how this is all set up. What you're running into is not drag but instead integration error that accumulates because you're going around and around Kerbin many times. This is sending you into Kerbin. You can get around this by tightening your integration tolerances (say, to 1E-10 for both absolute and relative tolerances). A better way to go about this, though, is to only propagate less than one revolution and optimize the initial time directly. Propagating for millions of seconds is always going to be awful for both run time and optimization time. To your second point, after the initial propagations finish to compute the gradient, the optimizer needs to do a line search kind of thing and this is always done in serial. This is what's killing your optimization time, because it might have to repropagate the trajectory many times to finish each optimization step. As always, getting your trajectory propagation time down as low as possible is the best bet to speedy optimization. Sub 1 second times are preferable if you can swing them. Also make sure you're optimizing in parallel. If by steps you mean events: yes, you can do that. No reason why not!

Can I ask, does that 1100 m/s include the Kerbin departure? Because I can get MFMS to find a solution with about that delta-v if it's just the in-space delta-v after departure. Keep in mind that with MFMS because you're specifying the initial orbit completely, you probably have large radial and normal components to your burn unless you get lucky and your departure orbit is in the right orbit plane to begin with.

A few thoughts here. First, make sure that the bounds on the flight times are reasonable for each leg of the trip. If the optimal trajectory is outside the bounds, it'll never be found. Second, make sure that you're specifying years correctly. KSPTOT lets users switch between Earth and Kerbal years and it's important to know which you're working with. Third, if there's no arrival burn, turn off the option to minimize arrival excess velocity since this won't be important anymore. I'm sure MFMS can find a good solution to the problem, it's just a matter of setting things up correctly.

Oh, MFMS has always displayed the flyby trajectories. It has to compute the flyby trajectories to minimize the burn delta-v, so it was trivial to just display those trajectories.

Yep, you should leave it checked normally.

No, it means that it won't be factored into the optimization problem's objective function. There will still be a departure burn.

The hyperbolic excess velocity is basically the speed above the gravitational escape speed at infinite distance from the planet. Give this nice Wiki article a read for more details: https://en.wikipedia.org/wiki/Hyperbolic_trajectory

I do actually! I developed a semi-analytic way of computing the flyby orbit and the necessary powered flyby maneuver. It's really quick (because you don't have to solve it numerically), which is why the code runs as quickly as it does.

What's a reasonable amount of DV here?

I would bet you could pretty easily do Eeloo to Moho with just a Jool gravity assist: Eeloo -> Jool -> Moho. Give that a try maybe? This is a good suggestion. I'll take a look into adding this functionality. EDIT: Implemented for next release.

This means that the solver could not find a feasible trajectory. Your problem is most likely one of two things. Either your departure window (upper and lower bounds) is too narrow or your trajectory is too complicated with too many way points and needs to be simplified. It's hard for me to tell with the image you provided unfortunately because I can't see the UI. ------------------------ In other news, with the upcoming release of KSP 2, I have been thinking about how I'm going to support it. I think, at least initially, all I'm going to work on is a new KSPTOTConnect plugin for KSP 2 that handles making the bodies.ini file and user upload of delta-v nodes. Any other functionality will have to be evaluated in the future to see if it's worth the time for me to get it into KSP 2. As always I'm open to suggestions and the like in this regard!

There have been images encoded in the background hum of that part of the video in previous videos.