bk2w

Nice work! What kind of algorithm are you using to solve the shortest-paths? -bk2w

Sorry, I didn't notice that you'd sent a PM. Somehow I turned off the notification for that, and got out of the habit of manually checking. I'm unable to replicate your problem, but I did find a few articles from MathWorks that might help: - http://www.mathworks.com/matlabcentral/answers/160070-how-do-i-install-r2013a-student-on-yosemite suggests that a problem with your Java installation might also be causing the problem. - http://www.mathworks.com/matlabcentral/answers/101399-why-do-i-receive-the-error-exception-in-thread-main-com-google-inject-provisionexception-when-in looks like it addresses this error message for older version of Matlab, don't know if it's still an issue for OS X 10.10 -bk2w

At 150 iterations, you've either given the optimizer a very hard problem to solve with a lot (10+) of variables, or it's running up against an optimization limit. My suggestion is to stop the optimizer and accept its solution. Once you're back to the MA window, take a look at the variables that you've enabled for optimization in Event 2 and Event 3. In general, I try to have no more then 5 variables being optimized at a time; since this is such a short mission, you've got no more than 4 variables total. Most likely one of your variables is near a limit. MA may even be telling you in the status pane at the lower right that some variables are near their optimization limits. You'll need to find them and increase the limits to give the optimizer some more room to explore. -bk2w

Ah, I see. The problem you're running into is that Constraints aren't the best way to direct the optimizer to what you want to achieve. In general, optimizers like this will have Constraints, which must not be violated, and an Objective Function, which should be minimized or maximized as much as the optimizer can manage. Solutions can be characterized as "feasible" or "infeasible", depending on whether the Constraints have been met. The MA optimizer has a hard time working if the starting point is infeasible, particularly Central Body constraints, which is what you've arranged. Think of the constraints as the edges of the playing field, and Objective Function as the direction you'd like to move on the field. If it starts way off the field, the optimizer has a hard time finding the field. Once it's on the field, it can push things around towards your goal. In this case, a better approach is to set the Objective Function to "Minimize Distance to Body", set the Applicable Event to "Event 4: Coast", and the Applicable Body to "Eve". Remove the Central Body constraint, and hit "Optimize Mission". It'll think for awhile, and should eventually come up with a solution that crashes straight into Eve. Once you've got a solution that crashes into Eve, add an "Altitude of Periapsis" constraint of 100km (just above Eve's atmosphere), and a Central Body constraint for Eve, then rerun the optimizer. That'll get you a fly-by that doesn't crash into Eve, but probably isn't anywhere near the inclination that you want. The Central Body constraint is most useful for when you've already got a solution that reaches Eve, and are trying to adjust the inclination, which is the next step. Add a Central Body constraint to prevent the optimizer from moving outside of Eve's Sphere or Influence. Look at the Event Information for Event 4, and you should see an Inclination, it may be larger or smaller than your desired inclination. Add an Inclination constraint that goes from the current inclination to your desired inclination. Change the Objective Function to either Minimize Inclination or Maximize Inclination depending on which direction it needs to move, and run. -bk2w

I've been supplying the OSX builds so far. At the moment, I need time. The switch from R2013 to R2014 has introduced a number of quirks and bugs that I'm trying to isolate. The majority of the quirks are that many UI elements are printed with really really small text. Makes for difficult reading. I'm also encountering a number of bugs in the communication between KSPTOT and KSP. At the moment, I'm unable to read KSPTOT save files for orbit data, and the KSPTOT Connect plugin cannot reliably move orbit data over to KSPTOT. At least uploading maneuver nodes into KSP is working reliably. I suspect most of the problems are due to changes in how Matlab handles Windows versus OSX UI elements and file systems. I'm making some progress, but it's taking time. Congratulations! Now I'm terribly curious. Can you share what you're going to be doing? Goddard? Marshall? Johnson? -bk2w - - - Updated - - - This is pretty typical when moving from the various Manuver tools to MA. The fact is that that distances involved are so large and the planets so small that very tiny differences at Kerbin can mean the difference between crashing into Eve and flying past it 100 million meters away. If you look at the orbit plot, you'll probably see your spacecraft's orbit arcing down from Kerbin to very close to Eve's orbit. It sounds like you've got a good start with MA, and the next step is to use the Optimizer to fine tune the when the departure burn happens, and what the burn is. It sounds like you might not have the optimizer configured quite right. What goal are you attempting to optimize, and what constraints are you using? (A screen shot of the optimizer window would be very helpful) I know it can be a bit frustrating for a while, but it'll eventually make sense. -bk2w

I've been having good luck working on my Kerbin-Eve-Moho sequence (down to ~4km/s and leaving Kerbin around day 185). Skipping some of the detailed steps: 1. Setup the initial state and first burn so that I get the Kerbin Departure Date at the True Anomaly with the Departure Burn. Add a coast to get to the Solar SOI. 2. Optimize the departure burn so that the first solar transfer orbit matches MFMS. 3. Minimize the distance to Eve with a constraint that the periapsis occurs at the UT of the Eve Arrival Date. The time is an important factor, here, and the optimizer can find other encounters that don't work for the full mission. 4. With the final step still being the coast to Eve periapsis, optimize to match the Inclination and Periapsis Radius for the "Inbound Hyperbolic Flyby Orbit to Eve" and being in the general range of the right ascension of the ascending node (plus/minus 20 degrees is plenty tight enough of a constraint). 5. Add the flyby burn at Eve, and a coast back out to Solar SOI. 6. Go back to 2 and optimize the flyby burn to match the second transfer orbit in MFMS. Repeat for each flyby in your sequence until you get an encounter with your final destination. Now, actually turning this mission into a reality is proving difficult. I've created the mission with both Impulse and Finite Duration maneuvers. Executing either version of the departure burn doesn't get me anywhere near an encounter with Eve. I managed to get to stop one of the burns early when it encountered Eve, but that was more than 10% short of the planned delta-V for the burn. So far my only hypothesis is that I planned about 50 Kerbin days in advance, and perhaps the orbit isn't the same after that much time; I'm trying to replan with new orbital elements extracted ~30m or so from the maneuver. -bk2w

If you're on an escape trajectory, it's most likely hyperbolic, which means theres a range of angles on either side of 180 true anomaly that simply don't exist for that orbit. In other words, your escape orbit may never reach 120 degree true anomaly in addition to not having an apoapsis. -bk2w

Arrowstar, Found a simple bug in the Rendezvous Sequencer: Using the Sun as the central body gets an error message of "Nonlinear constraint function is undefined at initial point. Fmincon cannot continue.". I tracked this down to the optimizer not liking 'Inf' as a return value from rendezvousNonlconFun(), which in turn comes from 'Inf' being returned by getSOIRadius(). I can get by this by editing getSOIRadius() to return something really big like 1e99 instead of Inf. Oh yeah, and they finally rolled out R2014b and I'm giving KSPTOT a workout. -Bk2w

I suspect the problem lies with helper_methods/astrodynamics/lambert.mex. I believe the source code is expecting the time of flight to be expressed in Earth days. If you're passing in the number of Kerbin days, you'll get very weird answers. -bk2w

I did, but due to a bug (see above) I was getting really weird and unattainable sequences. A lot of this effort is to dig into the mechanism used by metaphor (detailed here and here) to get from LKO to LMO in about 2.9k/ms. -bk2w

A capital idea! That approach let me plot out the Latitude over Longitude for both Spaceship Eve and Spaceship Moho, as well as Latitude over Time for Eve. Compare the Latitude plots to locate the line of nodes visually and identify the latitude of crossing, then look up in the time date for the when Eve is nearest that latitude. That identifies the times to within less than 6000 seconds. Interpolate the points, and I can get an estimate that should be accurate to within a few hundred seconds. Specifically, Eve descends through Moho's orbit at time ~3936400 seconds UT and latitude 1.9909° N Latitude. Eve ascends through Moho's orbit at time ~6799500 seconds UT and 1.9909° S latitude. Later nodes occur every 5657995 seconds. These closely align with my eyeballed numbers, as well. All of which brings me to 15252390 seconds UT, which is when Eve descends through Moho's orbit and can be reached in a 2.6km/s transfer. I'm sure there are later transfers that could be more efficient and reach Eve at its nodes with Moho, but this was simply the first one that showed up as anything resembling possible. Thanks for the tip, Gaiiden! -bk2w

Rechecking, I see that the Flight Bounds are the same elapsed time, i.e. the number of "days" in Kerbin Time is 4x the number of days in Earth Time. -bk2w

Okay, it turns out that a big part of my problem with the Flyby Tool is a bug in KSPTOT. Something isn't calculating the orbits correctly when TOT is set for Kerbin Time. The suggested burns and orbits simply don't work in KSP or MA, in addition to calling for large delta-V. Earth-Time Flyby: Kerbin-Time Flyby: I've confirmed this behavior with the Windows 1.2.1 app. Avoiding this bug helps me get good flyby sequences, and I can approximately control the flyby date by narrowly constraining the departure date. The Flyby tool ends up finding a sequence that passes Eve close to when I desire, and uses Eve to change into Moho's plane. Is there a way to constrain the Flyby tool to visit Eve at a particular time, and allow it to find the best departure date? However, I still haven't figured out the more basic orbital question: how can I determine when one planetary body is crossing through the plane of a second planetary body? -bk2w

I'm puzzling over an orbital problem that I can't quite get a grip on. I'm trying to arrange a Kerbin-Eve-Moho journey, and I'm trying to arrange to have the Eve flyby happen at the right time so that I can use the Eve flyby to change inclination and insert me into the same orbital plane as Moho. This way I use the free dV of the flyby to make the expensive maneuver. However, I can't figure out a good way of figuring out exactly when that flyby should happen. I can get a rough estimate by eyeballing the crossing nodes in KSP and fast-forwarding time until I see Eve at the estimated node. Add in multiple of the sidereal orbit period, and I get a number of candidate times. Check the pork chop plot and I see that 15271920 seconds UT gives me a decently cheap transfer (2.6km/s) and has the Eve fly-by occurring near where I think the node is. But when I plug the transfer into MA, and ask it to optimize the Kerbin ejection maneuver to get me Moho's inclination and RAAN, it can't manage it. I'll get the 7° inclination, but a 73° RAAN (as opposed to Moho's 70° RAAN). So, how can I improve my estimate of the Eve-Moho nodes and when Eve will arrive at the nodes? Is there another way to approach the whole problem of finding the right fly-b maneuvers? Mission Architect file can be found at https://www.dropbox.com/s/qxpzznnsupwzufb/Mission%20to%20Moho.mat?dl=0 -bk2w

My apologies, but after a dead laptop, it's taken me quite a while to get it fixed and back to a state where KSP is even a possibility. I'm finally back, and looking at updated KSPTOT for OSX. Sadly, I do not yet have access to 2014b, so while I can work on an OS X version of 1.1.9, I cannot do anything for 1.2.0. Hopefully that will change at some point, but it may be quite a while. -bk2w