Jump to content

Arrowstar

Members
 View Profile  See their activity

  • Posts

    2,562

  • Joined

  • Last visited

 Content Type 

Everything posted by Arrowstar

  1. Arrowstar
    Hi everyone, I have compiled KSPTOT v1.5.8 pre-release 3. This fixes the bug I found in MFMS while investigating @drunkeNNN's post. It also fixes the bug that @EpicSpaceTroll139 found. It doesn't do anything for the SoI transition issue @Stract found with RSS, but I guess we'll continue investigating that. Please let me know what issues you find. Thanks!
  2. Arrowstar
    Okay, so here's the deal. I've played around with changing the way that the velocity of the spacecraft is computed on downward SOI transitions in an attempt to replicate what you have, but I can't figure it out. If I change the grav parameter function for the state conversion but not for the SoI transition, then the position of the spacecraft is wildly off in the new SoI. If I hack it so the position is computed with the G(M+m) but the velocity is just GM, then I ended up with a flat out wrong velocity. I'm going to need more information on what's going on with RSS before I can try to replicate it. This is more complicated than a one line fix on my end I suspect... Okay. Try deleting your appOptions.ini file and then restarting the application. Something didn't get upgraded correctly. I'll fix that.
  3. Arrowstar
    Yes, please post the contents of the ksptot.log log file. Thanks!
  4. Arrowstar
    Any idea if this happens on upwards transitions too? That is, Charon to Pluto?
  5. Arrowstar
    Oh dear. Okay, thanks for investigating. That honestly sounds like a bug in RSS. That behavior makes very little sense to me. Gravitational parameter should be consistent. Do we have any way of talking to a dev over there to ask?
  6. Arrowstar
    Yes, the flight time is correct for multiple revs. Try opening up your boundaries some and see what happens. I get a reasonable result when I use wider flight time bounds. Edit just to say that I did find a bug in the way departure orbits are computed if the first two way points are the same body. You might get a crash or weird results. :-)
  7. Arrowstar
    I agree that it appears to have something to do with Charon's orbit, as setting up the SOI targeter to hit exactly the edge of the SoI (as opposed to the two kilometers in that you saw) does not change my answer very much. Do you have any way to obtain the position and velocity vectors of Charon within the game? I could compare them with what I get here and that could verify that Charon's orbit is the issue. For the record, here's what I get for Charon's orbit at UT = 153757.07654467 seconds. Distances in km and speeds in km/s. And if I convert that to Keplerian orbit elements I get the following. Distances in km, angles in radians. What do you think?
  8. Arrowstar
    Is there anything in the KSP debug log or the KSPTOT log file that you can share which might pin down what's going on? Do you see any error messages anywhere? Yes, please send a mission file! That would be very helpful for me. Can you illustrate this with a screenshot or two, please?
  9. Arrowstar
    Okay I'll look into it. What version of KSP are you on? Latest version of KSPTOTConnect? EDIT: Seems to work for me on KSP v1.2.2 and the latest KSPTOTConnect DLL.
  10. Arrowstar
    Got it, thanks. If you can find a way to reproduce it, let me know! I've not yet encountered that sort of behavior, but it's something I want to squash if I can.
  11. Arrowstar
    So the issue is that I do not assume a circular parking orbit. You'll note that the UI has inputs for the full set of orbital elements. I allow the user to enter in any sort of eccentric orbit, and that flexibility comes with the cost of eliminating the use of simple equations like you suggested. Negating the inclination is also not particularly realistic. Plane change maneuvers can make up the bulk of the departure burn delta-v if the user selects the "wrong" orbit plane (inclination + RAAN). If I drop this, it would be very easy for the application to provide incorrect results. There is one other aspect of this beyond the math. That is, optimizing on the C3 energy (or in this case, the square root of the C3 energy, which is the hyperbolic excess velocity) is the "industry standard" way of going about it because it provides a parking orbit-agnostic method for optimizing the transfer orbit from body to body. This makes the results easier to port from mission to mission, as needed. So this really isn't true. It's not that the solution is only "good" at the edge of the SOI or whatnot. Try not to think about optimizing the departure/arrival excess velocity as optimizing the parking orbit or anything like that. It's merely a metric I use to ascertain how "cheap" it is to execute a departure burn to get onto the desired transfer orbit. When it comes to very CPU-intensive problems that require hundreds of thousands of function evaluations such as flyby optimization, you want to use the quantity that is fastest to compute and provides reasonable results. The excess velocity is that, and while it's not perfect, it's quick, does a reasonably good job, and is accepted practice. -------------------------------------------------------- In other news, I have another pre-release ready. KSPTOT v1.5.8 pre-release 2 contains the desired upgrade to the Multi-Flyby Maneuver Sequencer that allows users to let the optimizer find multi-rev trajectories between any waypoints. @EpicSpaceTroll139 and @drunkeNNN, this one's for you. Please try it out and let me know what bugs you find or issues you discover. Thanks!
  12. Arrowstar
    Could you post a mat file that shows the issue you're talking about with the moons? Also the new and old bodies files, if you could. :-)
  13. Arrowstar
    I was able to load both save files just fine. Can you show me screenshots of the behavior you're seeing? Maybe try the pre-release below, which is what I'm on. Thanks! Here you are. I guess this is KSP Trajectory Optimization Tool v1.5.8 pre-release 1. Please let me know what you find, good or bad. I'll try to get the bugs fixed ASAP so you can get up and running. To use the new RSS mode, in the main KSPTOT GUI, go Edit -> Gravitational Parameter -> RSS Like. Thanks! @Phineas Freak, I think you were interested in this modification too, so you're welcome to help out here as your interest and time dictate.
  14. Arrowstar
    Okay, I can't promise that it's perfect, but I think I'm close on RSS compatibility. This is from my test tonight. I could really use some testers. @Stract, @gruneisen, anyone else, if I provided a pre-release, would you be willing to put it through the RSS paces and see what issues arise? I am obviously doing the same, but this task was really huge. I've basically had to sort through the whole code base and make updates to the locations where celestial body states are being computed to update the GM values... I think I got them all but I could use a double check. Got it, thanks for the feedback on this. I suspect this feature is coming next, after I finish RSS compatibility. MFMS already optimizes the arrival excess hyperbolic velocity. It's just that the optimizer is balancing that against the departure excess velocity and the flyby delta-v and sometimes that quantity has to give to minimize the other ones. It's all a balance. Regarding optimizing the injection burn: Sadly not, no. That's computed after the fact for a reason, namely that it's fairly expensive to compute. (All those iterations on the waitbar after the GA finishes? That's the calculation for the optimal departure burn.) If I put that calculation in the loop with the flyby math, the whole thing would take weeks to run. But you can optimize your burn and initial orbit in Mission Architect, so I would suggest trying that out.
  15. Arrowstar
    Quick sanity check, @Stract: the period of an orbit and its mean motion would also use the G(M+m), yes? And G(M+m) would also factor into the element conversions from vectors to normal elements and back again, yes?
  16. Arrowstar
    Hi everyone! Tonight I'm happy to announce the release of KSP Trajectory Optimization Tool v1.5.7! This release has been in the works for a few months now and it's great to get it into production. The development is documented over the past several pages of forum posts, but the summarized change log is as follows: Mission Architect: New experimental N-body coast event. This event models N-body gravity for selected bodies. Allows for basic Principia compatibility. Mission Architect: New event "Docking" that models the user spacecraft being docked to another spacecraft by propagating the user spacecraft along the same orbit as the other spacecraft. Mission Architect: New event "Landing" that fixes your spacecraft relative to the rotating surface of the current central body. Can be used to model landings on the surface. Mission Architect: New initial state type "Estimate Launch." Allows for users to model a launch into a circular parking orbit at a desired altitude. Useful for determining initial orbits when that information is otherwise hard to guess or not available. Mission Architect: Initial state parameters may now be optimized like burn and coast parameters. Mission Architect: Relative in-track, cross-track, and radial positions of other spacecraft are now represented more correctly in Graphical Analysis. Mission Architect: Major update to the optimizer contraint system that allows for nearly all Graphical Analysis tasks to be used as constraints. A number of bug fixes in Mission Architect and the KSPTOTConnect plugin. As usual, the download link is in the OP. Please let me know if you find any bugs or issues that need to be addressed! Happy orbiting!
  17. Arrowstar
    No problem! Btw, if that works out for you, then I think we'll make this pre-release the actual release tomorrow.
  18. Arrowstar
    It shouldn't be that bad from an algorithmic perspective. I'll look into it for v1.5.8. Speaking of which, @Drew Kerman, here's the 7th pre-release of the upcoming version. I restored your coast conversion stuff with a fix for the issue that I was seeing. Turns out it was fairly easy to work out. Let me kno w how it works for you.
  19. Arrowstar
    Yeah, I turned that off because I noticed it was causing more issues than it was solving, at least for me. Did you like it? I can find a way to re-implement it that isn't so annoying if it's critical for you. Yes, you would need PEG or something. MechJeb works in a pinch, too. Okay, astrodynamics lecture time! It can be shown that given any two positions in space and a time of flight between them, you can draw a conic section (ellipse, hyperbola, or parabola) between those two points. The resulting conic section will obey the two-body laws of motion that KSP uses. Basically, you get an orbit. The problem of determining what that orbit is is known as Lambert's Problem and an algorithm that solves said problem is called a Lambert solver. Every Lambert solver in existence necessarily can solve the normal Lambert's Problem in which the spacecraft necessarily makes less than one revolution around the central body before it arrives. More specialized solvers can also solve what's called the multi-revolution Lambert's Problem, in which the spacecraft makes N revolutions around the central body prior to arriving at the destination point. N is 0, 1, 2, ... etc. The multi-revolution Lambert's Problem is quite a bit trickier to solve because not all values of N yield a solution. You can, in fact, show that there is an N_max after which no more values of N will yield a valid solution. This has to do with the fact that all multi-revolution solutions must have an eccentricity less than 1.0 (so you can actually go around more than once!). Now, KSPTOT actually does have a multi-rev Lambert solver but it's only used in MFMS to do transfers to the same body (so like from Kerbin to Kerbin, etc), and the number of revs is always hard-coded to 1. In other cases a normal Lambert solver (that can't do multi-revs) is used. It wouldn't actually take too much in order to get the multi-rev stuff implemented on the algorithmic side of MFMS but then there's UI work and other related things that need to go in with it, as well. So basically you're not wrong, KSPTOT MFMS is not letting the spacecraft go around multiple times. Good catch! I didn't know this was actually something people wanted, but if you'd like, I can look into it for the next version (v1.5.8). It probably won't be too much of a hassle. Let me know.
  20. Arrowstar
    Okay great. So the big problem with implementing this fix here is going to be updating all the locations where any of the functions that require a GM input to use the correct input. It'll potentially be quite the project. Like I said, I'll look into it after the 1.5.7 release and hopefully we can put the RSS issues behind us once and for all... Speaking of which, has anyone run into anything weird or wrong with the latest v1.5.7 pre-release?
  21. Arrowstar
    Thanks for doing the research, @Stract! That's very interesting. As far as a toggle goes... Yes, that's what it would be on the UI side. I still have to implement it though! Let me see what I can come up with after the 1.5.7 release drops next week hopefully. @Stract, is the only modification you needed to do to add the GM of the smaller body, as you showed in your code example? And that provided good results where used?
  22. Arrowstar
    Okay, I think I've resolved the issue and I just replaced the pre-release 6 EXE again (as I had just replaced it). Go ahead and try that out. I was just a bit overzealous with the bounds checking on some numbers.
  23. Arrowstar
    So I accidentally included the MCR installer in the EXE file I think, which is why the file size went up by a factor of ~4. I've reuploaded pre-release 6 and it's about ~69 MB, which is much more reasonable. Thanks for noticing! I'll take a look! EDIT: Is this on the pre-release?
  24. Arrowstar
    It's real, though probably means I messed something up on my end. I had to rebuild the Matlab compiler project for this build and I bet I added in a bunch of files I don't need to include. I'll look at it tomorrow. In the mean time it should all work. :-)
  25. Arrowstar
    Hi everyone, Tonight I'm pushing out KSP Trajectory Optimization Tool v1.5.7 pre-release 6. This pre-release has a number of changes over the previous pre-release, all of which are in Mission Architect. Implemented the Landing event in Mission Architect. This event holds you fixed within the rotating frame (lat/long/altitude) of the spacecraft's current central body. Implemented a new Coast type, "Coast to Function Value." This allows you to coast to values that are otherwise computable from Graphical Analysis, such as relative crosstrack postition, longitude, altitude, etc. I've revamped the way the graphical analysis data providers (aka "Tasks") are implemented within Mission Architect. Now, these data providers are used not only within Graphical Analysis but also for optimizer constraints and for the "Coast to Function Value" feature as well. In the future, they could conceivably be used for other things as well. A number of smaller bug fixes here and there. As a note, older mission cases from previous versions, including the last pre-release, may have some optimizer constraints removed upon load in this version. This is because the name of some constraints changed and I needed to have the optimizer reload them (via user commands) or the application will crash. Because of the somewhat larger changes in this pre-release, if anyone using it finds a bug, please let me know! I've tried to test everything to the extent that I can, but I assuredly cannot find every use case myself in a finite amount of time. Thanks, and happy orbiting!
×
×
  • Create New...