Arrowstar

Members
  • Content count

    1,592
  • Joined

  • Last visited

Community Reputation

514 Excellent

1 Follower

About Arrowstar

  • Rank
    Astrodynamicist

Recent Profile Visitors

1,825 profile views
  1. Got it. Here's KSPTOT v1.5.10 pre-release 11, it includes: An error message when the MFMS optimizer returns abnormally, with a particular suggestion to check the waypoint flight time and maximum mission duration constraints. Let me know if this takes care of the issue for you, it seems to be for me. Thanks! Unless other bugs are found, this will be the v1.5.10 release version, I think.
  2. Thanks. I know what the issue is now, just some missed error handling on my part. I need to think about how to fix it, but it won't be hard. I'll try to get to it tomorrow. In the mean time, the actual issue is that your max mission duration constraint is too small. The genetic algorithm code is returning with a "unable to find a feasible starting point" error immediately. In the mean time, try loosening this constraint up a bit. I doubled what you provided and things ran just fine. In fact, while I can improve my error handling a bit, you'll need to change that constraint some before the optimizer will run regardless of what I do. Thanks for finding this!
  3. Okay, I had a look. The images were very helpful, thank you. Without the actual mission plan you're trying to reproduce it's hard to help for sure, but I have some thoughts: Drop the UT constraint for the time being. It's probably just making things harder than they need to be at the moment. Add it in later if you need to. The three constraints you want to use for this flyby are the same you used to depart from Kerbin: hyperbolic excess RA, Declination, and velocity magnitude. These should be easier to hit than the three orbital angles, or at least they were for me. You'll get these numbers out of the outbound hyperbolic orbit section of MFMS, same as with the angles you were using. Keeping the Central Body constraint isn't a bad idea either. Your difficulties are definitely just a problem with the way the problem is posed, not your hardware or anything like that. Try changing these things that I mentioned and then give it another go. Also look at the MAT file I included in the latest pre-release ZIP file. There should be some hints in there as to what I did with constraints and whatnot. If you still have the MFMS data you're using to put together this mission plan and can give it to me (just paste it into this thread as a quote I suppose), that would help me help you recreate it better. Good luck! Let me know if I can help more.
  4. By the way, @Drew Kerman and others, please let me know if you find any bugs in the latest pre-release version. Otherwise I think I'm going to use that as the 1.5.10 release either later this week or this weekend. Thanks!
  5. I spent a bit of time today adding a few features to the next pre-release that I've been thinking about. Included in KSPTOT 1.5.10 pre-release 10, these include: Mission Architect: Two new graphical analysis tasks and constraints, the hyperbolic excess velocity vector right ascension and declination angles. Mission Architect: The Optimizer observation window is now more useful. The top plot showing variable values has been changed such that it plots from lower bound to upper bound of every value. This means that extra large variable values (like times) will not completely wash out the plot anymore. MFMS: The number of decimal places in the output window has increased to 4 for each united value. Mission Architect: Tweaks to the options fed into the fmincon optimizer algorithm. Mission Architect: Included a new example case file: Kerbin-Eve-Jool-Eeloo mission. Please let me know if you have any questions! Thanks. I'll take a look at this tomorrow. In the mean time, go ahead and grab the pre-release I linked to in this post. Use it to open the included MAT file in the pre-release ZIP file. This is my take on the K-E-J-E mission you were talking about. Word of warning: this mission took me most of today to complete. It's a very hard case, even for a professional such as myself. It's not super surprising that you're having a bit of trouble, but keep at it and I'm sure you'll get it. A few tips: My process flow went something like this. When starting, use the hyperbolic velocity R.A., Declination, and magnitude constraints in the mission optimizer. Get the values for these from MFMS. Don't try to target either the Kerbin outbound orbit or the Sun-centered orbit directly, it won't work well. Allow the true anomaly of the burn and the three burn vectors to vary. After you achieve those constraints, then turn them off and add a Coast to Sun SoI event (go to next SoI) and then a Coast to Periapsis with 1 rev before it. Set the reference body to your target body. Optimize again, setting your objective function to distance to your target body at that "coast to periapsis" event. Once you've hit the target body's SoI and the periapsis of the inbound orbit is reasonably low, add a new set of constraints for the next set of hyperbolic velocity R.A., Declination, and magnitude constraints. Optimize to achieve these, maximizing total spacecraft mass. Be sure to insert a burn at the flyby periapsis and allow it's vector components to vary to hit the new constraints. Mid-course correction maneuvers are critical. It's just not going to happen that you're going to get Mission Architect to hit the flyby spot on without more parameters to vary. In between each flyby, add a coast to some true anomaly that doesn't go past the next waypoint body and then a burn. Look at what I did in the mission MAT file I put in the latest pre-release ZIP file (link above). Keep your bounds on your variables, especially your burn vector components, wide open to start. +/- 1000 m/s is probably fine for each. Go bigger if you need to. Once you're reasonably happy with how a leg of a transfer looks, turn off the variables before and during it. The more variables Mission Architect tries to optimize at once, the worse it's probably going to work. Your two best friend objective functions are "minimize distance to body" and then "maximize mass". Use the first to get into the SoI of each waypoint body and then the latter to help find the best transfer to that body. Stick with impulsive maneuvers for now. Finite burns will just make life harder. Keep practicing! EDIT: I just took a look at the MAT file you provided. I'm guessing your issue is that you haven't set the appropriate event (event 5) and the appropriate body (Eve) next to the objective function selection in the Mission Optimizer window. I did this and I got an Eve encounter on the first try. Give that a whirl and see how it goes.
  6. I had to request access to this file because it doesn't look like it was shared properly.
  7. I've compiled a new pre-release that addresses the following issues: KSPTOT v1.5.10 pre-release 9 Added SoI search tolerance menu option to Mission Architect; Added ability to perturb Mission Architect optimization variables by a percentage amount via menu; Fixed bug with Mission Architect optimization constraint analysis warning text; and Added warning dialog to MFMS is the user attempts to close the UI while MFMS is running. Please let me know if you have any questions. Thanks!
  8. Just an update: if this is the case, the only thing I can think of is that either the mass of the spacecraft is wrong some how, or the thrust of the engine used for the finite burn is wrong. Check both of these. If the impulsive maneuver is getting you there almost exactly, then these are the only two things that could be throwing you off.
  9. I took a brief look tonight and your trajectory seems sound. The kerbin to duna leg is pretty accurate. I haven't looked at the burn much though, I'll take a look tomorrow or Thursday. Have you had any luck?
  10. Thanks! That will be fine. No need to send anything if my bug fix solves all your problems... unlikely, I suppose, but one can dream. Right! This is what happens when you read too quickly. Thanks for the heads up. Glad that will work.
  11. Both of these bugs are now fixed in KSPTOT v1.5.10 pre-release 8. Sorry for the pre-release spam tonight, I've just been going through and getting features in, compiled, and uploaded as I go through posts and see them.
  12. On third thought @Drew Kerman, nevermind lol. Completely ignore what I said before about all this. I think you may have actually found a bug in my SoI transition detection code. I think I fixed it... all of my test cases work properly anyways. It's in the following new pre-release: KSPTOT v1.5.10 pre-release 7 Can you take a look and see if this improves anything? Thanks!
  13. I took a look at the bugs reported earlier and managed to fix all of the UI-related ones. I've compiled them into a new pre-release build: KSPTOT v1.5.10 pre-release 6. Change log: Resolved issue with the MA Delta-V dialog box not updating until another event is processed. Resolved an issue with the main MA UI not refreshing after optimization. Added a warning to MA if the user tries to close the application while the software is processing data (either because the UI is running the mission script or the orbit display is updating). On second thought, could I get the MAT file you're seeing this in? I want to understand it better now that I have a chance. Thanks!
  14. Hey there! Sorry for the delay in getting back to you. Are you still having problems? If so, please post your MAT file somewhere I can take a look at and I'll see what I can do for you. Thanks!