bk2w
-
Posts
42 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Everything posted by 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
-
I'm making progress with Mission Architect in my attempt to swing by Jool and intercept Pol. I'm having a lot better luck getting a solution by using the Jool-flyby to lower the apoapsis to somewhere around 400Mm, then burning at api to raise periapsis to near Pol's orbit. The Optimizer can then take over and tune those two burns to get close to Pol. Mission file is here; I'm still playing with it as it doesn't reach Pol quite yet. I do have some suggestions to make the process a bit easier: - When looking at the whole Joolean system with child bodies visible, the child bodies are so small that they visually merge with the arc of their orbits. I end up having to show SoI radius and popping the orbit display out so I can make it larger, before I can finally locate Pol and Bop. So it would be useful to make child bodies a minimum size and a contrasting color in order to make them visible. - With multiple burns in the Joolean system, I see the locations of child bodies at multiple points on their orbits. I'm presuming these are the body locations at each event. However, it's difficult to tell which location correlates to which event. Could we color the bodies according to the event location corresponds to? The Mission Animator is particularly interesting, and has the potential to be a really useful visualization tool. - Can you add the option to display orbit arcs for child bodies? This would make identifying which body is which easier. - When using "Custom" camera position, can you add a "zoom" capability? It seems that the Custom camera creates a 3D box the size of the entire SoI. In other news, OSX version compiled and handed off to Arrowstar. If anyone else is successfully using the OSX version, please chime in; I'd like to know if anyone else is able to use it. -Brian
-
So I'm trying to plan a tricky maneuver using Mission Architect, and I'm not figuring things out quite right. I'd appreciate any help. I have a craft in Kerbin orbit (and can get state from the SFS, no problem). I departing Kerbin and transferring to Jool with a low Pe over Jool (~8000km radius). Somewhere near the Jool Pe (maybe before, maybe after), I'll make another burn to adjust my swing around Jool and intercept Pol. Unfortunately, while I can work up a mission that gets me an 8000km periapsis and very little inclination, I can't seem to find the Pol intercept. The optimizer ends up halting with a Pol-periapsis of 50Mm, or 100Mm. Using a fake orbit (prior to launching the actual spacecraft), I was able to find a mission that got my into an equatorial Pol orbit for about 3300m/s (1950m/s to transfer to Jool, 350m/s to intercept Pol, and 1000m/s to capture in Pol orbit). But reloading with the actual orbit shifts things enough that I can't locate any solution anymore. A couple of runs with the Graphical Analyzer have suggested that Pol is basically on the wrong side of Jool when I make the fly-by. If I know where Pol is when I swing by Jool, I can advance or delay my Kerbin departure to compensate and place Pol in the right section of its orbit. But I can't quite determine where Pol IS when I fly-by. Is there some way of determining where Pol is in relation to my spacecraft at the fly-by? Some other way of laying up the mission that can allow the optimizer to find a feasible solution? -Brian
-
At this point, I'm down to googling around for similar problems. So far I see that to install MCR R2013a you need: - Java 6 SE (available from http://support.apple.com/kb/DL1572?viewlocale=en_US&locale=en_US) - no other MCR version installed (uninstall instructions: http://www.mathworks.com/help/compiler/working-with-the-mcr.html#bs6mchw-1) I'm unable to remove Java 6 from my machine (Apple made it darn near impossible), so I can't really replicate the problem that AppleDavidJeans is running up against. All I can suggest is to delete all version of MCR, make sure that Apple's Java 6 SE is installed, and try to install MCR R2013a. -Brian
-
Ah, I believe that Java is too new for MCR R2013a. You'll need to remove Java 8 and install Java 6. http://stackoverflow.com/questions/19039752/removing-java-8-from-mac talks about how to remove Java 8. You can get Java 6 from http://support.apple.com/kb/DL1572. -Brian
-
Unfortunately, MCR is not always compatible between versions. Mathworks reorganized the libraries between R2013a and R2014a in a way that would require us to recompile (and possibly rewrite) KSPTOT. Open up a Terminal window and type in java -version. What does it print out? -Brian
-
That looks like you might have a problem related with Java. Take a look at https://discussions.apple.com/thread/6163798 and try some of their suggestions. -Brian
-
I will point out that the run_KSPTOT.command script tries to locate the MCR libraries, but isn't the smartest thing in the shed quite yet. If it doesn't succeed in starting up KSPTOT, please let me know and we'll see what we can do to make the script smarter. -Brian
-
Arrowstar, I was inspired by your improvements of the fly-by planner through vectorization to try my hand at some as well. I aimed to speed up the Porkchop plot through vectorizing the lambert solver. It, uh, works amazingly well. Plotting 2500 points in 0.1622 seconds, versus 44.8668. Plotting 62500 points in 2.0 seconds, versus 437 seconds. 280x faster is kinda nice. And I'm absolutely positive I'm still doing some things inefficiently. I ended up heavily reworking Oldenhuis's lambert.m into lambert_vector.m to vectorize the solutions. I also used the mtimesx routine to enable multi-dimensional matrix multiplies. Ends up being very handy for storing position and velocity vectors in a higher-order matrix, and still being able to calculate each vector's 2-norm and otherwise manipulate the individual vectors. Finally, computePorkChopData.m had to be modified to marshall all the data in the matrices needed for lambert_vector. It's been a fun weekend exercise. I'm happy to pass the files on to you, if you'd like. -Brian
-
Arrowstar, It appears that Squad changed the definition of a 'day' in 0.24. KSP 0.24.2 treats 6 hours as 1 day, while KSPTOT treats 24 hours as 1 day. Also, KSP now defines a years as 426 days, while KSPTOT defines it as 365 days. This means there's an ambiguity in a lot of the epoch times and durations that KSPTOT lists. I'm presuming that we still want to follow the UT number, and not the years/days/hours number. -Brian
-
I'll have to leave it up to Arrowstar. The menu bug that I'm seeing makes the app awkward to use. In addition, the Matlab-compiled script currently knows nothing of where the MCR libraries are located, so right now the app has to be started via a script that informs the app of where MCR is installed; I haven't yet figured out how to bundle this script with the app. -Brian