Jump to content

Arrowstar

Members
  • Posts

    2,561
  • Joined

  • Last visited

Everything posted by Arrowstar

  1. Huh. I've been unable to reproduce your problem, to be honest. Can I get a screenshot of your Optimization window? The one where you enter the constraints? Is the MA plan you linked to above still the one causing issues? I'll investigate more when I get home from work and perhaps put together a debug version for you to try. As far as I know, it is, but I've never tried with anything other than either A) a full version of MATLAB or the version of the MCR I link to in my OP. Please feel free to test, though, I'd be interested in hearing what happens. I'd also be interested in you trying the 2013a 64-bit version if the 2014 version does not work.
  2. Alright, can you try again with this (hopefully fixed) version? It's just the executable, so drag, drop, and replace the official 0.12 executable. Let me know if you get the same error. I wasn't able to reproduce it on my end anymore.
  3. Yep, an interesting suggestion. A quick survey of my code shows that the date/time format is pretty deeply embedded in many places. I never expected to have to be able to change that, so I didn't build in any mechanisms to do so. Don't think I'll be able to make much progress here... :/
  4. Thanks! Your issue is, at first, fairly obvious. You have a bunch of NaN in your state log, which means that something isn't getting propagated correctly. This is probably causing the issue you see. Problem, of course, is that I'm not sure why it's happening. I'll need some time to investigate. Thanks for the report.
  5. Hi everyone! This evening I am happy to announce the release of KSP Trajectory Optimization Tool v0.12! Here's a quick overview of the changes: Version 0.12 New Application: KSP TOT Mission Architect Allows for the planning of complete missions from Kerbin injection orbit to anywhere in the solar system. Plan ballistic trajectories, gravity assist maneuvers, injection orbits and more using the same basic orbital mechanics and patched conics system that KSP uses! No more infinitesimal sphere of influence approximations to ruin your burn planning. Tracks spacecraft mass and fuel usage so you ensure you always have enough fuel to return to Kerbin. Built in mission optimizer can goal seek to target celestial bodies, minimize fuel usage, or hit inclination/eccentricity targets -- all optimally. Full orbit visualization means that you'll know precisely where you're going and how you're going to get there. Mission state log provides the complete spacecraft state at effectively any point along the mission, from initial get-go to the final injection burn. And more! [*]Improvements to the astrodynamics code: Orbit propagation code has been vectorized to allow for faster execution. Orbit RV/Keplerian conversion has been vectorized for MUCH faster execution. Code is also far more robust! [*]Improvements/fixes to the rendezvous application. I just kinda buckled down today and finished off the one major bug that was standing between me and release. ALSO: people were shouting for a Mission Architect tutorial, so I created one! It's with the download package in PDF format: "From Kerbin to Laythe." Check it out and tell me what you think. I'd really appreciate feedback on the new Mission Architect, as it's a completely new tool and very complex compared to everything else. Please let me know your thoughts. If you find bugs, I need to hear about those too. And if you like it, I'd like to hear that, too. Download link is the same and located in the OP. Oh, I have a graphics art request for this fine community. If anyone has any skill with graphics applications, could I ask you a favor? I'd like to take the 6-8 images of the application I have in the OP and condense them down into a single, nice-looking collage. Would someone be willing to help with that? If so, please PM me. Thanks! Thanks, everyone, and happy orbiting!
  6. It probably doesn't work with 0.23.5 then. At the moment I'm too busy to take a look (I've worked 125 hours in the past two weeks), but I'll try to get to it when I can. Perhaps after 0.24 hits the shelves. Thanks for the notice.
  7. Hi Spacefan, Apologies, but I'm not too interested in opening that code to the public. I'm not actively maintaining it anymore and I'd rather Orbiter TOT just sit as it is. Best of luck, Arrowstar
  8. Hi all, Just wanted to let you know that I've restarted work on KSP TOT Mission Architect. My goal is now to get a finalized v0.12 out this weekend. Really, everything is mostly coming together, I just need to get the details (minor bugs/annoyances, tooltips, some documentation) taken care of. If you've used MA in the past and have comments, now's the time to let me know about them. I'm not sure how much time I'll devote to KSP TOT in the immediate future after the 0.12 release. I will keep supporting it and bug fixing of course, but it's a pretty time consuming endeavor and I occasionally need to go on breaks for a few weeks/months to recharge.
  9. Ah. That would be because KSPTOT doesn't actually know what time it is. However, it does know the location of the burn and the mean motion of the orbit, and from there it can figure out the time relative to periapsis. I guess I don't understand your last question. In what way was the Moho burn off? In the program or in KSP? If it was in KSP, this was probably just the infinitesimal local gravity field assumption screwing up the burn a bit. You shouldn't be that far off, though. Try moving the maneuver node around with a maneuver node editor. I think I have a tutorial linked in the OP that explains how to do that a bit.
  10. So I believe the DV being considered is just the Lambert-based delta-v. This isn't actually what you'd need to stop at the destination planet. Computing that is much harder because it involves knowing what your arrival orbit is and what your target orbit is. I've thought about this problem for a while, and the short answer is that it's probably not particularly valuable. In the mean time, I probably won't be displaying this information directly. However, if you know your inbound orbit and your target orbit, you can use the two-burn orbit change code to perform the required math for you and get the result you seek. So no, it probably won't be on the results screens, but there are other ways (the way I just listed) to get what you're after. Does that help? So UT retrieval works but not anything else? That is very weird. When you start KSP in the flight scene (that is, go to launch a rocket or whatever), open up the debug log and see what's in there. Should be something about KSPTOT Connect starting a server. Can you look for that? Maybe take a screenshot and post it here?
  11. Depends on what you mean by good reading material. If you're well versed in orbital mechanics, I would suggest Fundamentals of Astrodyanmics and Applications by Vallado. This is the single greatest orbits text you can find anywhere, hands down. I own a copy and I use it extensively when writing code for KSP TOT. If you're not that big into the orbital math yet, I would recommend something like this website. Or just Google "basic orbital mechanics." Now, do you have particular questions? I can't give a run down on all the math in KSP TOT, but I'd be happy to share how I did particular things. Always fun to talk about orbits with people who like to learn.
  12. Hi everyone, sorry for the delay in providing responses. I'll try to get to everyone's comments and questions here. KSP TOT does not consider atmospheric interactions in any of its calculations. Thus, you'll get the same experience with or without FAR installed. Insertion delta-v is factored in. However, the flyby code uses a particle swarm optimizer and there is a degree of randomness involved. It is normal and expected to get different results on different runs, and you may need to use the tool a few times to find something acceptable. It should be effectively identical. But KSP TOT does a lot more and has a lot more features than Alex's code. Don't get me wrong, I actually like what he's put together, but KSP TOT is for people who want to do lots of trajectory analysis work. See above, there is a fair bit of randomness in the generation of the solution. The optimal flyby problem is hard to solve, and I elected to do so by throwing CPU at the problem. Of course, the code could probably use an update and some optimization itself, but it seems to work alright for now. Thanks! Correct, I have not yet. I'm not particularly familiar with this family of transfer, though. Could you (or someone else) describe what you mean? The connection is made via TCP/IP.
  13. Hi chicknblender! Thanks for using KSP TOT! I'm glad to hear you got it working for you and your missions have been successful. If you have any questions, please post here and me know! To everyone else: sorry for the absence over the past few weeks. I've needed a bit of a creative break and work has been a bit overbearing. I will resume work on the next version and Mission Architect hopefully next week. Hang in there.
  14. Can you take a screenshot of the GUI and post it here? Which version are you using? The released v0.11 or the 0.12 pre-release? Bet way to help me out is the give me a save file (*.mat) that shows the error. Take a picture of the optimizer input GUI is if you were using that. Once I have these, I'll take a look and troubleshoot.
  15. Could I get these error messages from you? If I know what you're doing wrong, I can try to build in stops to these more common issues that prevent people from making the same mistake in the future. Certainly! I'll include a tutorial with the 0.12 release. Perhaps I'll model the Kerbin->Ike transfer I included, plus some other things. Thanks! Yes, as I said above, I'll write up a tutorial and include it with the final 0.12 release. Right, so last night I finished up the state log and modified the tab order of all the GUIs so they made sense. I also got a start on vectorizing the "minimize distance to target" objective function. The reason this is important is because this function includes a loop over the state log that the application records, and that's what makes the whole optimization slow right now. If I can get this vectorized, then I expect the already fast optimization will go much, much faster, and all will be happy. Keep letting me know about suggestions and whatnot, everyone. I want to make Mission Architect the best I can, and that's not possible without great user feedback.
  16. Ah, okay, so you've hit upon the difference between Mission Architect and the rest of KSP TOT. MA accounts for sphere of influence changes, everywhere else does not. It turns out that doing so is actually important and means you need to adjust your trajectory to account for it. Here's what you do. Use the optimizer as a "targeter" by minimizing the distance to Eve, using the main part of KSP TOT has the initial guess, as you've done. Do so first without any constraints and let it plow you right into the planet. Then, once you're headed into Eve's SoI, add constraints on radius of periapsis and inclination. Once you've got that licked, then add any maneuvers at Eve. You have to optimize in stages. Let the optimizer get you to where you're going with no constraints. Then slowly add constraints and maneuvers until you get the mission you want. And keep in mind that "optimization" is just a fancy way of saying "achieving a goal." Want to go somewhere? That's a goal. Want to minimize prop usage? That's a goal. All the optimizer does is achieve those goals. Oh, last tip: as of pre-release #2, you don't need the coast to the edge of Kerbin's SoI. Just make it a coast to Eve's periapsis and once the optimizer gets you in the SoI, you'll go there no problem. Okay thanks. That sounds great. I looked at the package you linked me too and it's quite intriguing. I'll take a look Saturday when I get sick and tired of looking at my 1040.
  17. Hi everyone, The pre-release build of v0.12 has progressed to #2. The second build is located here and features the following changes: Bug fix for coasting to true anomalies while in a hyperbolic orbit (diomedea's bug); A new "split coast at UT (universal time)" feature, it divides up coasts into two parts at a particular point in time; Some enhancements to the way that optimization parameters are stored and retrieved; Lots of tooltips everywhere; In the optimizer viewer, "Cancel" has been replaced with "Stop" and tooltip text has been added to describe what stopping does (namely, stop the optimization and return the current result). A few other minor things. Let me know what you guys think! We're nearing full release status, I believe.
  18. Interesting. Well, I think I've actually fixed the root issue and a new build will be up shortly. Please let me know if the issue persists there. So I suppose it's really a difference of philosophy. To me, if you say "go to true anomaly of 0" and then say it again, the code should do it once, then realize it's already there, and just return the same state. It's not an issue from a propagation perspective, it just means you have a redundant event. I'd hate for the application to throw an error that could kill an optimization process because of something that still works (even if it's a bit strange, as in the example you said). Now that said, if you have any other examples where things *should* throw an error because they'd present issues with propagating the orbit, then I'm all ears. I need to know about those so that I can fix them. Good to hear!
  19. I think I know what's doing this, but to confirm, can you respond with the warning message you get in the lower right corner? If it's what I think it is, should be easy to fix. Feel free to post a link to a MAT file that you save with the mission and warning in it. That'll help me pinpoint the issue, too. This is by design. Only coasts have finite durations, so only they show up on the orbit display. Maneuvers, mass dumps, and the like are all instantaneous. There's nothing to show on the display. Hope that makes sense. This is because the solution *is* changing, but it's so small that you can't see it in the display. It's just a tolerances thing for termination. If you cancel, you'll be offered a choice to keep the current solution as it's been found so far, so you won't lose anything. I need to rename that button to "Stop" or something like that. In any event, I'll play with the tolerances some today. Glad to hear it's fast, btw!
  20. Just a heads up, guys, I've uploaded a new pre-release build (same link above). It includes the following: A fix to a bug with bounds in the optimizer code; Addition of a "view state at event" feature; Addition of the "Advance script to event" feature State readouts now have tooltips The first item, the bug, was the main reason for this update coming out so fast, but the other features are nice, too. Please re-download at your convenience.
  21. Hi Iron! Thanks for using KSP TOT. I could, but it would probably take me a while. Might be faster for you to simply post what questions you have and I can answer them that way. It should be a fairly straightforward application to use: select your starting body, your fly-by body, and your arrival body, along with the time range you want to look at fly-bys over, and push go. Go get a cup of coffee or something, it usually takes a few minutes. Your mention of automatic differentiation is intriguing, but I can't say I'm very familiar with it. Can you describe what it is and how it would be useful here? I'm all for any suggestions that improve the efficiency of my code. Alright, will do, thanks! I'll provide some test inputs and outputs in a text file for you to use. TOT for Orbiter is not appropriate for KSP, sorry. It does use full n-body physics in some places and that would likely screw up things. Your best bet is to create a new bodies.ini file based on the example I provide in the KSP TOT release and go from there. Work with the author of Real Solar System to get the orbit and size information you need.
×
×
  • Create New...