Jump to content

Arrowstar

Members
 View Profile  See their activity

  • Posts

    2,562

  • Joined

  • Last visited

 Content Type 

Everything posted by Arrowstar

  1. Arrowstar
    Oh, so I just forgot to update the post about that. At the last second, after doing some more testing, I decided that 2 was better because it really seemed to improve the odds of finding the SoI transition, but didn't cost that much more time. So I left it at 2 instead of 1. Anyway, I believe I found the bug in mission animator it was plotting the orbit from one part of the state log, but at the boundary between two SoIs, grabbing the wrong spacecraft position. I have adjusted the code to correct this. I updated the v1.5.11 pre-release 2 ZIP file with the build that has the fix in it. Please test at your convenience.
  2. Arrowstar
    Can you take a few pictures of what you mean?
  3. Arrowstar
    Alright, want to know what the problem was? This is a plot of the distance of your spacecraft to the Mun SoI over time (horizontal axis is universal time, vertical is distance to SoI). See all those local minima (the bottoms of the valleys)? The SoI transition code was getting stuck in one of them, namely the middle valley. Because that valley is nowhere near the SoI, it was rejecting the whole solution. Luckily, I have a solution. I have added an option to the Mission Architect script execution settings called "Number of SoI Transition Search Attempts" (Settings -> Execution Settings -> Set Num. SoI Search Attempts). Here's what this does. See the plot above? That's a portion of one rev that the code pre-computes in such a way that, if the Mun was going to be intersecting your spacecraft orbit, it would be somewhere in there. We see that it is, in fact. There's margin on those bounds, though, so that nothing gets missed, and for fast periods, like the Mun and your spacecraft here, you will probably get a few local minima. The new setting divides that plot up into a number of equally-sized slices and then attempts to find an SoI transition in each slice, from left to right. The number you provide dictates the number of slices. So, if you say 1 (which is the default), the behavior is unchanged from before. If you say 2, then the first half of that plot gets searched, and then the second half gets searched (so long as an SoI transition was not found in the first half). If you say 10, then the first tenth gets searched, and then so on... Now, one caveat. This will definitely improve search functionality in cases where the solver was running into bad local minima. However, it also involves calling that solver more times, which means that setting this new setting to a number greater than 1 will slow down execution speed. Setting it to the maximum of 100 will probably slow down run time by a factor of at least 10x-20x. Anyway, this new function solves the issue you were seeing. It, as well as the fix for the line of sight issue you reported, are in a new pre-release: KSPTOT v1.5.11 pre-release 2. Please test these fixes out and see if they help! Thanks. (I will take a look at the mission animator stuff you mentioned later!)
  4. Arrowstar
    So... I did what you instructed and here's what I ended up with: Here's a link to the MAT file shown above so you can take a look and tell me what I did wrong lol. Once we get this sorted I'll compile the next pre-release and you can test out the fix(es).
  5. Arrowstar
    Okay, maybe I just need some clarification as to when you're restarting MA or creating a new mission plan or reloading the mission plan file or whatnot. That was not clear to me when going through the instructions.
  6. Arrowstar
    Oh, also, for those interested, I finally figured out how to actually use git and updated the repo tonight for the first time in 3 years lol. New source code is here: https://github.com/Arrowstar/ksptot This is just KSPTOT. KSPTOTConnect is not included there yet.
  7. Arrowstar
    I had trouble reproducing this one. The final event, Event 5, which is a coast to SoI transition, was not able to find an SoI transition. Judging by what you're describing though, I suspect it's yet again another thing with the numerical precision of the SoI transition finder algorithm. Do you have a more straight forward way of demonstrating the issue? Oh, you'll be happy to know I believe I've corrected the line of sight bug you reported before. When I get it posted if you could look and see if it corrects your issue that would be great. Thanks!
  8. Arrowstar
    Please, by all means! Start with the source code in the download package, whatever is online is out of date. If you can improve KSPTOTCONNECT, go for it. I'm not much of a C# dev so I'm happy for the help. If you do any work on the plugin, send me a PM with the source code and I'll check it out.
  9. Arrowstar
    Thanks for letting me know! Thanks for the report! Sorry I haven't been around much the past 3-4 weeks. I am seeing the reports here, but I've been busy with another project that is consuming my free time. I'm hoping to be able to get to some of these things here in the next few weeks. Sorry for the delay. :)
  10. Arrowstar
    Thanks! I'll take a look!
  11. Arrowstar
    Thanks! I will let you know.
  12. Arrowstar
    @Papa_Joe, do you have your new source code on github or something yet?
  13. Arrowstar
    I can't really comment because I don't own an xbox. Should be identical in theory though. @Thomas, a Kerbonaut if you need help using KSPTOT or getting it installed, please let me know. Thanks!
  14. Arrowstar
    Okay no worries. After a quick assessment, I think it would be very doable to model the atmospheric losses. The radiation pressure doesn't look worth it and the others I'm not so sure about. Do you think that would be sufficient?
  15. Arrowstar
    It's an interesting idea. I could probably do it as a new type of coast. I would need to understand how that mod models the decay. @Papa_Joe, can you provide me with some information on your decay model?
  16. Arrowstar
    No worries, I removed the constraint that apogee must be greater than 0. It was a very easy change. It will be in the next release. Thanks for the suggestion!
  17. Arrowstar
    It requires Ap to be a positive quantity, because in the strictest sense, apoapsis is undefined for hyperbolic orbits, even if mathematically it works out. If there's interest in not requiring that, removing the check is pretty easy from the code.
  18. Arrowstar
    Thanks for the report, @Three_Pounds! I'm embarrassed to say I did actually find the bug and it was not particularly challenging. Here is KSPTOT v1.5.11 pre-release 1 with the fix. Please let me know if this resolves the issue for you. Sorry about the long wait to get back to you, I've been out of town. Change log: Fixed issue with Mission Architect Launch Window Analysis tool that could cause the launch azimuth shown to be incorrect in certain cases.
  19. Arrowstar
    Thanks. So I'm pretty confident that the burn solution you're getting is good. Take a look when I model the maneuver in the high fidelity Mission Architect tool: https://imgur.com/a/n3TbtBB At this point there are two things that could be wrong: You are burning at the wrong time. Make sure that the epoch (time) of the maneuver node is within one orbital period of the time shown in KSPTOT. It should be pretty close to UT = 12035219.659 sec. The period of that 900 km orbit you're in is 2855 seconds. You are burning at the wrong point in the orbit. The departure true anomaly is 288.53 degrees. This is equivalent to 1519.20599 seconds past periapsis. I suspect it's the former option, #1. My hunch is that you're planning these maneuvers many days before they are to be executed and are uploading them. However, the upload tool can default to "Time Past Periapsis" in certain cases, and this would cause you to be burning far earlier than you want to. If you can verify the time of the maneuver node is close to what it should be, then it's a problem with being at the wrong point in the orbit. Try and verify that you're burning at the correct true anomaly or time past periapsis. In either one of these cases, all you really need to do is move the burn epoch around until you get close. When I modeled the burn in Mission Architect, I actually ended up with something closer to UT = 12037305.1782108 seconds. Regardless, just push the epoch around 100 seconds or so at a time and see what it does to the resultant sun-centered orbit. When you start getting closer to Neidon, start using smaller increments until you hit the planet's SoI.
  20. Arrowstar
    Okay thanks. Can I see the KSP save file (the one with an extension of *.SFS) that you're working in? Oh, just to be clear, the epoch field in that box is NOT the departure epoch. That is the point in time that your spacecraft is at the entered mean anomaly. (Normally I'd call the mean anomaly field "mean anomaly at epoch" but there wasn't space.) Entering these and checking the "Use?" checkbox forces the code to try and find the correct departure time such that when you leave your hyperbolic excess velocity vector is in the same direction as the ideal.
  21. Arrowstar
    I'm happy to announce this afternoon the release of KSP Trajectory Optimization Tool v1.5.10! This release is packed with new features and bug fixes that have shown up in the various pre-releases up to this point. Here's the change log: As usual, the download is in the OP. Please let me know if you have any questions. Happy orbiting!
  22. Arrowstar
    Okay, let me know. The burn information that comes out of that tool is correct. I verified it in Mission Architect independently and the results were very close. There's just a misunderstanding going on somewhere, hopefully I can help clear that up next time. Happy orbiting.
  23. Arrowstar
    Can I please see the window that pops up when you hit the Compute Departure button? It's labeled "Enter Transfer & Initial Orbit Information". I need to see how it looks right before you hit the Compute Departure Burn button. Btw, most likely what is happening is that you are burning in the wrong place in your Kerbin-centric orbit. This would happen if you didn't tell KSPTOT your mean anomaly and orbit epoch information. If you don't do this, it just assumes you'll be where you need to be at the time you need to be there. While this is certainly the best way to do it, it's not necessary so long as you don't mind being a bit off in your burn or the target SoI is so large that you'll hit it anyway. For this problem, just using the porkchop-based Compute Departure function is fine.
  24. Arrowstar
    Thanks for the report. I couldn't reproduce the "beep" error sound you found, but if you can post your ksptot.log file for me, and provide your MAT file that showed the error, I can investigate. As far as the argument of perigee value changing, that is expected. Your orbit is circular, and so argument of perigee is undefined because there is no perigee. KSPTOT recognizes this and transforms your state representation into something that won't cause problems in the future by zeroing out that element of the state. This error avoidance transformation is what you're seeing. It's not a problem, it is a good thing. For your interest, the relevant KSPTOT code. The line "arg = 0" is the part that's doing what you're seeing. %%%%%%%%%% % Special Case: Circular Inclined %%%%%%%%%% if(ecc < 1E-10 && inc >= 1E-10 && abs(inc-pi) >= 1E-10) u = real(acos(complex(dotARH(nVect,rVect)/(norm(nVect)*norm(rVect))))); if(rVect(3) < 0) u = 2*pi - u; end tru = u; arg = 0; end
  25. Arrowstar
    @Gaarst, could you add my KSP Trajectory Optimization Tool to your list? Link is in my signature or here. It should be classified as an external tool. Thanks!
×
×
  • Create New...