[WIN/MAC/LINUX] KSP Trajectory Optimization Tool v1.6.10 [Major LVD Improvements!]

[Arrowstar]

On 8/16/2017 at 7:36 PM, Drew Kerman said:

@Arrowstar I have another wonky possible edge case in an asteroid orbit - mat file. Just try coasting to Next SOI or Periapsis. There's a warning that the trajectory intercepts Kerbin (which it does in the game as well) but I can't get it to show. Also tried bumping the log entries up to 100,000

Also, this didn't really affect me adversely but when I went to close KSPTOT it popped up the message from Mission Architect saying I had unsaved data so curious what that was I clicked "No" when it asked me to continue and everything exited anyways. So to reproduce open KSPTOT, open MA, do something to dirty the save state, close KSPTOT, say yes, close MA, then no, cancel close.

Well, you're certainly right!  You've yet again managed to find another awful edge case in the SoI transition code.  Congrats.

Notice that when you first hit the Kerbin SoI you actually have an eccentric (not hyperbolic) orbit?  This is because I have some code that actually searches for SoI transitions in a few kilometers into the SoI in order to help mitigate those funny cases where you bounce between SoIs because you're right on the bleeding edge.  Normally it's too small to matter, but in this case, apparently it somehow does and the resulting state is eccentric and not hyperbolic.  Anyway, the code wasn't set up to expect that (all downward transitions should be hyperbolic in theory), hence the funny issue. If you want to see where this is implemented, it's line 309 in the findSoITransitions() function.

Anyway, I've created a new pre-release build that should resolve the issue.  Give it a try and tell me what you think.

Regarding the closing message, yes, I agree it's not intuitive.  However, the main KSPTOT window is controlling the closing procedure, so there's not much I can do about it without lots of rework.  I'll give it more thought though and see if another solution presents itself.

@Three_Pounds - Did you still want a mean anomaly, true anomaly, eccentric/hyperbolic anomaly converter in the tools window as you originally requested?  Or are you good now?

[Drew Kerman]

Thx! Will give it a go when I get back from eclipse chasing on Wed, tho if it worked on your end should be good on mine. Yea I have a large sample set of asteroids to throw at MA  I like I can still help refine the software while I'm not yet ready to do "real" missions.

[Arrowstar]

1 hour ago, Drew Kerman said:

I like I can still help refine the software while I'm not yet ready to do "real" missions.

I definitely appreciate it!  That part of the code is the most finicky part of MA, so any refinements are useful and good to know about!

[ThreePounds]

On 19/08/2017 at 4:08 AM, Arrowstar said:

Did you still want a mean anomaly, true anomaly, eccentric/hyperbolic anomaly converter in the tools window as you originally requested?  Or are you good now?

No, I'm fine now. Thank you.

[ThreePounds]

Okay, I'm having a new problem with the mission architect and Galileo Planet Pack and KSPTOT 1.3.8. Basically, I think the issue is that KSPTOT expects the central star to be called "sun". Unfortunately, there isn't such a body in GPP. Instead it's called Ciro. I've linked a body.ini created with GPP loaded. The issue occurs when I open the mission architect and try to open the celestial body catalog, launch window analysis tool or the like. I hear an error sound and no window opens. This is what the log says:

Reference to non-existent field ''.
Error in mainGUI>departBodyCombo_Callback (line 175)
Error in mainGUI>loadBodiesFromFile_Callback (line 591)
Error in gui_mainfcn (line 95)
Error in mainGUI (line 42)
Error in matlab.graphics.internal.figfile.FigFile/read>@(hObject,eventdata)mainGUI('loadBodiesFromFile_Callback',hObject,eventdata,guidata(hObject))
Error while evaluating Menu Callback
Warning: 'popupmenu' control requires a non-empty String
Control will not be rendered until all of its parameter values are valid
Warning: 'popupmenu' control requires a non-empty String
Control will not be rendered until all of its parameter values are valid
Reference to non-existent field 'sun'.
Error in ma_getSortedBodyNames (line 17)
Error in ma_CelBodyCatalogGUI>setupCelBodyListbox (line 74)
Error in ma_CelBodyCatalogGUI>ma_CelBodyCatalogGUI_OpeningFcn (line 63)
Error in gui_mainfcn (line 220)
Error in ma_CelBodyCatalogGUI (line 42)
Error in ma_MainGUI>celBodyCatalogMenu_Callback (line 1222)
Error in gui_mainfcn (line 95)
Error in ma_MainGUI (line 42)
Error in matlab.graphics.internal.figfile.FigFile/read>@(hObject,eventdata)ma_MainGUI('celBodyCatalogMenu_Callback',hObject,eventdata,guidata(hObject))
Error while evaluating Menu Callback

When I try to make the body.ini created with GPP the default by naming it "body.ini" KSPTOT refuses to start up and instead gives me this message:

Reference to non-existent field ''.
Error in mainGUI>departBodyCombo_Callback (line 175)
Error in mainGUI>mainGUI_OpeningFcn (line 112)
Error in gui_mainfcn (line 220)
Error in mainGUI (line 40)
Error in projectMain (line 51)
MATLAB:nonExistentField
Error writing to output stream.

In essence, KSPTOT really doesn't like the file at all. I could just rename Ciro to sun and change all the references then, but then KSPTOT and KSP will run out of synch which would spawn a new set of problems trying to use KSPTOT Connect later.

bodies.GPP.ini https://drive.google.com/file/d/0B6KLmRpYz5AlVUFZVndXcFlIRkk/view?usp=sharing

[Arrowstar]

On 8/23/2017 at 5:57 PM, Three_Pounds said:

Okay, I'm having a new problem with the mission architect and Galileo Planet Pack and KSPTOT 1.3.8. Basically, I think the issue is that KSPTOT expects the central star to be called "sun". Unfortunately, there isn't such a body in GPP. Instead it's called Ciro. I've linked a body.ini created with GPP loaded. The issue occurs when I open the mission architect and try to open the celestial body catalog, launch window analysis tool or the like. I hear an error sound and no window opens. This is what the log says:

Reference to non-existent field ''.
Error in mainGUI>departBodyCombo_Callback (line 175)
Error in mainGUI>loadBodiesFromFile_Callback (line 591)
Error in gui_mainfcn (line 95)
Error in mainGUI (line 42)
Error in matlab.graphics.internal.figfile.FigFile/read>@(hObject,eventdata)mainGUI('loadBodiesFromFile_Callback',hObject,eventdata,guidata(hObject))
Error while evaluating Menu Callback
Warning: 'popupmenu' control requires a non-empty String
Control will not be rendered until all of its parameter values are valid
Warning: 'popupmenu' control requires a non-empty String
Control will not be rendered until all of its parameter values are valid
Reference to non-existent field 'sun'.
Error in ma_getSortedBodyNames (line 17)
Error in ma_CelBodyCatalogGUI>setupCelBodyListbox (line 74)
Error in ma_CelBodyCatalogGUI>ma_CelBodyCatalogGUI_OpeningFcn (line 63)
Error in gui_mainfcn (line 220)
Error in ma_CelBodyCatalogGUI (line 42)
Error in ma_MainGUI>celBodyCatalogMenu_Callback (line 1222)
Error in gui_mainfcn (line 95)
Error in ma_MainGUI (line 42)
Error in matlab.graphics.internal.figfile.FigFile/read>@(hObject,eventdata)ma_MainGUI('celBodyCatalogMenu_Callback',hObject,eventdata,guidata(hObject))
Error while evaluating Menu Callback

When I try to make the body.ini created with GPP the default by naming it "body.ini" KSPTOT refuses to start up and instead gives me this message:

Reference to non-existent field ''.
Error in mainGUI>departBodyCombo_Callback (line 175)
Error in mainGUI>mainGUI_OpeningFcn (line 112)
Error in gui_mainfcn (line 220)
Error in mainGUI (line 40)
Error in projectMain (line 51)
MATLAB:nonExistentField
Error writing to output stream.

In essence, KSPTOT really doesn't like the file at all. I could just rename Ciro to sun and change all the references then, but then KSPTOT and KSP will run out of synch which would spawn a new set of problems trying to use KSPTOT Connect later.

bodies.GPP.ini https://drive.google.com/file/d/0B6KLmRpYz5AlVUFZVndXcFlIRkk/view?usp=sharing

You do need a central body called Sun, yes.  As long as the body ID doesn't change, though, nothing should go out of sync.  I'll take a look at the file this weekend to see if that change helps any.

[ThreePounds]

6 hours ago, Arrowstar said:

You do need a central body called Sun, yes.  As long as the body ID doesn't change, though, nothing should go out of sync.  I'll take a look at the file this weekend to see if that change helps any.

Oh. So they'll use the body ID to communicate? I should I have guessed that. Well, in that case the work around is pretty simple: just replace all instances "ciro" with "sun" and the body.ini is good to go! I thought I saw NRE spam coming from KSPConnect but upon further investigation it probably was something else. I'll keep looking for issues.

Thanks a lot!

[Drew Kerman]

@Arrowstar can def confirm the new build works, I never got around to installing it but today came across a similar issue with a different asteroid and using the new build fixed that one as well

Edited August 31, 2017 by Drew Kerman

[1greywind]

I feel, that I don't understand how KSPTOT should work. I try to calculate maneuverer data for simplest transfer in Jool system: Tylo-Vall:

1) I build Porcchop plot, select desired Arrival/Depature dV

2) When I click on "Compute departure burn", enter vessel orbit from KSP, set Depature/Arrival date and click on another "Compute departure burn" button

3) KSPTOT calculates burn data, I upload it to KSP, maneuver node appear.

But: Resulting transfer orbit in KSP doesn't leads to intercept with Tylo. Neither this orbit looks like one in KSPTOT "transfer" orbit diagram.

I've double checked timing on maneuver node and it matches one in KSPTOT, but this timing places node on wrong side of Tylo-centric orbit: Vall transfer should start more or less in Jool-facing hemisphere, but maneuver from KSPTOT is on another side.

I'm very sad and I don't understand that can be wrong: I use minimum amount of mods (Hyperedit, KER, KSPTOTConnect, KerbalAlarm and Kerbal Transfer Window Planner).

Can you give me any clues that I'm doing wrong? I can record video of my actions or I can post more detailed sequence with screenshots.

[ThreePounds]

3 minutes ago, 1greywind said:

3) KSPTOT calculates burn data, I upload it to KSP, maneuver node appear.

At this point, instead of uploading the maneuver to KSP, I open the mission architect and build the tranjs jool injection there. I use the optimizer to get the correct trajectory which is ever so slightly different from the departure burn calculator, which as I understand takes a few short cuts. Once the optimizer has run and given me the intercept I want, I'll then go ahead and upload it to KSP. Unfortunately, the burn is usually off slightly radialy. I think it either has to do with timing or slight imprecisions in the KSPTOT-KSP interplay. Anyways, that's usually fixed by either adding a few m/s radially or carefully dragging the node.

Hope this helped?

[Arrowstar]

3 hours ago, 1greywind said:

Can you give me any clues that I'm doing wrong? I can record video of my actions or I can post more detailed sequence with screenshots.

Screenshots with accompanied explanations would be the best bet.  Please be as thorough as needed so I can exactly reproduce what you're doing.  Thanks!

[drhay53]

Is it possible that setting Argument of Periapse in the mission architect is bugged? When I try to set it manually, it still says 0.0 on the Initial Spacecraft State, and it sets the True Anomaly to the value entered. Further attempts to enter an Argument of Periapse change the True Anomaly to a different value and also mess with the eccentricity, but don't change the actual Arg. of Periapse entry.

[ThreePounds]

1 hour ago, drhay53 said:

Is it possible that setting Argument of Periapse in the mission architect is bugged? When I try to set it manually, it still says 0.0 on the Initial Spacecraft State, and it sets the True Anomaly to the value entered. Further attempts to enter an Argument of Periapse change the True Anomaly to a different value and also mess with the eccentricity, but don't change the actual Arg. of Periapse entry.

Arg. Of Pe is only defined for eccentric orbits. Did you make sure the orbit is not circular?

[Drew Kerman]

@Arrowstar is there a way to not have the MFMS steal focus constantly while it is running? It's sucking up resources as expected but I think I can still get some basic stuff done while it runs in the background rather than having to walk away

(no big rush on this if it's possible, I needed an excuse to get my backup rig setup since I moved anyways and it's now happily humming away churning out plots

Holy hell the speed diff between my i7 4GHz and the older 2.4GHz Core2Duo from 2006 is staggering haha. Takes my current PC only 15-20min to run a 50 count MFMS sequence)

Came across an error during on of my runs. Log file.

Also, I can now do other things while the MFMS runs in the background, and I'm not sure why yet. it was constantly stealing focus on earlier runs, not sure what I did differently after restarting from the error posted above.

Edited September 24, 2017 by Drew Kerman

[drhay53]

7 hours ago, Three_Pounds said:

Arg. Of Pe is only defined for eccentric orbits. Did you make sure the orbit is not circular?

I was attempting to set the initial state orbit to the hyperbolic trajectory plane from MFMS, like in the tutorials, but that's a good point. I'll have to check that. 

Im just getting started and trying to plan a mission that's a flyby of eve to get to duna, just to see how everything works. But I'm having trouble even getting to eve at the right time. Basically the optimizes initial burn gets there way too fast, and once I try to constrain UT, it has no idea how to get there. I'm trying to follow along the solar systems edge tutorial but for my own mission, and the tutorial says that the constraint solving for the eve part should just finish quickly. But I've messed with it for hours and the UT thing seems to be the culprit. 

Perhaps a tighter upper limit on prograde burn is the answer?

 

btw in the tutorial I think it says to set the argument of periapse but I think that's a circular orbit too, so that's why I thought perhaps there was a bug. Just didn't know enough about what that angle is to catch that it's meaningless in a circular orbit. Now that you mention it, the name is pretty self-explanatory

Edited September 23, 2017 by drhay53

[ThreePounds]

1 hour ago, drhay53 said:

btw in the tutorial I think it says to set the argument of periapse but I think that's a circular orbit too, so that's why I thought perhaps there was a bug.

I think that particular element of the tutorial is no longer useful in the newest version. Ignore the argument of Periapse of the initial orbit and do one of these options 

1) Set the argument of Periapse according to the value of the hyperbolic transfer orbit you get from the "computer departure orbit" option in the pork chop plotter

or 2) don't set the augment of periapsis and make the margin for the true anomaly -180,360

Both should work

[drhay53]

3 minutes ago, Three_Pounds said:

I think that particular element of the tutorial is no longer useful in the newest version. Ignore the argument of Periapse of the initial orbit and do one of these options 

1) Set the argument of Periapse according to the value of the hyperbolic transfer orbit you get from the "computer departure orbit" option in the pork chop plotter

or 2) don't set the augment of periapsis and make the margin for the true anomaly -180,360

Both should work

I assume you mean the true anomaly of the coast to burn? 

I still have major problems getting things to converge on the right time of arrival at Eve. Basically following the tutorial steps, I end up with a high-dV burn before adding constraints, and then once constraints are added it's ~months off on the intended UT arrival.

[ThreePounds]

21 minutes ago, drhay53 said:

I assume you mean the true anomaly of the coast to burn? 

I still have major problems getting things to converge on the right time of arrival at Eve. Basically following the tutorial steps, I end up with a high-dV burn before adding constraints, and then once constraints are added it's ~months off on the intended UT arrival.

Yes. That's what I meant.

Months? That's a almost a multiple of the transfer duration. 

If the burn is too aggressive then the optimizer  homed in on a very suboptimal solution. I'm this case it's best to completely reset it and let it find another one. Try going back to the departure burn calculations and set your initial orbit in the mission architect accordingly. It should have the same RAAN, Inclination and Arg. of Pe. Make the margin on the "the coast to true anomaly event" -5,5 and set the contains on the transfer burn as closely as you can. It's fiddly I know but that's how the tool is. You aren't doing anything wrong fundamently I think.

I also find that the optimizer doesnt like the UT constraint too much. Once it found an orbit it's hard to make it adjust the timing in my experience. 

Edited September 23, 2017 by Three_Pounds

[drhay53]

Just now, Three_Pounds said:

Yes. That's what I meant.

Months? That's a almost a multiple of the transfer duration. 

If the burn is too aggressive then the solver homed in on a very suboptimal solution. I'm this case it's best to completely reset it and let it find another one. Try going back to the departure burn calculations and set your initial orbit in the mission architect accordingly. It should have the same RAAN, Inclination and Arg. of Pe. Make the margin on the "the coast to true anomaly event" -5,5 and set the contains on the transfer burn as closely as you can.

I've cleared and restarted the MA 3 times over the last 2 nights trying to get it right. It's always the same thing on the UT issue (I'll double-check the timescale of the offset). I don't think I'm missing anything. 

Basically, the optimizer's minimization target is the distance from Eve, so there's nothing suboptimal about a high-dV solution as far as it's concerned. But I'm following the directions in the tutorial basically to the 't', as far as I can tell. 

On setting the parameters of the orbit, the argument of periapse part we addressed above; the starting Kerbin orbit should be a circular orbit in the plane of the hyperbolic transfer, but this means argument of periapse is meaningless, right? Just making sure we're on the same page. 

Wait, isn't true anomaly also undefined for a circular orbit? The coast event is optimizing the true anomaly, which is undefined in a circular orbit right? Now I'm a little confused. Obviously MA selects a time to leave from the coast event, but it seems like a coast to UT might be better to optimize?

 

[ThreePounds]

52 minutes ago, drhay53 said:

I've cleared and restarted the MA 3 times over the last 2 nights trying to get it right. It's always the same thing on the UT issue (I'll double-check the timescale of the offset). I don't think I'm missing anything. 

Basically, the optimizer's minimization target is the distance from Eve, so there's nothing suboptimal about a high-dV solution as far as it's concerned. But I'm following the directions in the tutorial basically to the 't', as far as I can tell. 

On setting the parameters of the orbit, the argument of periapse part we addressed above; the starting Kerbin orbit should be a circular orbit in the plane of the hyperbolic transfer, but this means argument of periapse is meaningless, right? Just making sure we're on the same page. 

Wait, isn't true anomaly also undefined for a circular orbit? The coast event is optimizing the true anomaly, which is undefined in a circular orbit right? Now I'm a little confused. Obviously MA selects a time to leave from the coast event, but it seems like a coast to UT might be better to optimize?

 

Can you upload the mission architect file? I'm having trouble following. Maybe I can give you more valuable information we're looking at the same thing.

[drhay53]

Just now, Three_Pounds said:

Can you upload the mission architect file? I'm having trouble following. Maybe I can give you more valuable information we're looking at the same thing.

yes, that's the plan, but I have a toddler and I can't get things together until nap time

[drhay53]

@Three_Pounds  Ok here is the MFMS result, and the MA file while trying to optimize just to get to the Eve distance to zero. The last two nights of messing around at this point with this UT and orbit I've been having lots of trouble. 

Basically, the optimizer always seems to bump up against what seem like reasonable delta-V bounds. 

I have to get past this hurdle before I can even get back to the UT issue, and I spent 3 hours with this setup last night just trying to figure out what why even though I should be in the right plane for the departure orbit from MFMS, MA seems to want to add a bunch of normal and radial dV to get the eve distance to 0, and even then, wants a ton of prograde dV. I'm stumped a bit.

https://www.dropbox.com/s/zlfdypy5v7m48re/MFMS_drhay53_EveDuna.txt?dl=0

https://www.dropbox.com/s/ufupbbeiqpdvofd/MA_drhay53_EveDuna.mat?dl=0

I feel like I must be missing something stupid.

quick edit: I noticed when setting the initial state that mousing over the True Anomaly box gives a popup saying it's the Argument of Periapse. Argument of Periapse does seem to work fine when eccentricity isn't 0, so I don't necessarily think the underlying setting of values is bugged. I would think that would have caused so many issues that it would be caught very fast. 

Basically, from this starting MA file, I have to open up the delta-v constraints on normal and radial pretty wide just to get a "slamming into Eve" encounter as in the tutorial. And I'm just not sure why; I believe I've set the initial orbit into the right plane already, from the MFMS results.

Edited September 23, 2017 by drhay53

[ThreePounds]

@drhay53 Looking at your MA file, I noticed that indeed something is very wrong with the orbit that the optimizer has given you. This is way too aggressive and surely not what the fly-by finder had in mind. It's always important to actually look at the trajectories to figure out what's going on. KSPTOT is a powerful tool that will do all the maths for you, but it's also very, very dumb and the thinking is still on you

We have to fix this. Your initial orbit looks good. However, like I stated previously, I'm going to put 354.5° as initial Arg. of Pe just to make sure the TEI burn happens at the correct angle. I set the eccentricity to 0.005 just to make it something non-zero (probably just superstition ) On the coast event, I set true anomaly to 0° and the bounds to -2.5 and 2.5. I'm fairly confident that the burn happens at Periapsis (True anomaly there is 0°), so this will bring the optimizer pretty close to the solution I want. How exactly out TEI looks like is difficult to say. We can't rely on the print out from the fly-by finder because that had a very different initial orbit. First up, I set the radial component to 0 and deactivate optimization on it - as previously said I'm quite confident we have the correct angle so no need for radial burns. Normal is really the same deal - there shouldn't be a huge component as we already have the inclination we need. I set the value to 0 and bounds to -200 to 200. Most important is now the prograde component. I assume it's more than 1,000m/s and less than 1,300m/s. So I set those as bounds and the value as 1,010m/s (an educated guess based on the orbital print out). Now it's time to move on to the optimizer. The way you left it looks good to me so I'll just run it. And almost immediately I get the orbit I wanted. It's a few days off but that can probably be fixed with a little bit more fiddling. Here's your file back!

https://drive.google.com/file/d/0B6KLmRpYz5AlV0NTSk1Vc1prVmM/view?usp=sharing

Moral of the story: Make sure your initial set up is as close to the desired orbit as possible and make sure your constraints aren't too wild - make them as tight as possible. The optimizer will go off on a wild goose chase if you let it.  

 

 

Edited September 23, 2017 by Three_Pounds

[drhay53]

@Three_Pounds Wow, thanks! I knew the transfer was far too aggressive, I just couldn't figure out how to fix it (FWIW, I find the plots to be quite unintuitive to use. I'm sure I'm just not used to them yet). 

On the setting of the coast parameters, you're effectively telling it to burn right at the time that MFMS suggested, right?

For some reason though, I just can't open the file you posted. MA says it's loading but it never finishes. If I try to make your changes by hand to my version, I do not get the same good results that you report. Are you using KSPTOT v1.5.7 on windows?

[ThreePounds]

1 minute ago, drhay53 said:

For some reason though, I just can't open the file you posted. MA says it's loading but it never finishes. If I try to make your changes by hand to my version, I do not get the same good results that you report. Are you using KSPTOT v1.5.7 on windows?

I'm using 1.5.8. That might be the reason. You should be able to reproduce this by yourself though.