Jump to content

Arrowstar

Members
 View Profile  See their activity

  • Posts

    2,559

  • Joined

  • Last visited

 Content Type 

Everything posted by Arrowstar

  1. 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).
  2. 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.
  3. 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.
  4. 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!
  5. 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.
  6. 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. :)
  7. Arrowstar
    Thanks! I'll take a look!
  8. Arrowstar
    Thanks! I will let you know.
  9. Arrowstar
    @Papa_Joe, do you have your new source code on github or something yet?
  10. 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!
  11. 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?
  12. 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?
  13. 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!
  14. 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.
  15. 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.
  16. 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.
  17. 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.
  18. 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!
  19. 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.
  20. 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.
  21. 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
  22. 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!
  23. Arrowstar
    Hah, perfect. That's wonderful. This is actually very interesting for me, because it demonstrates something I was never entirely sure about myself: that KSP is clearly using a similar technique that I am to find SoI transitions. I suspect that they're doing something to keep the CPU time of the calculations down (whereas I just do what I need to do), but I suspect it's fundamentally the same approach. Very cool. Thanks for the verification tonight!
  24. Arrowstar
    Sweet! This is excellent to hear! I'm glad it worked well. So the times are within 1 second of KSP itself?
  25. Arrowstar
    So... I had a shower thought last night after I typed out my reply to you. I didn't want to go speculating here until I tried it out, but now that I have, I think it will work. Yesterday I mentioned SoI dithering. This is when the code that finds and executes SoI transitions rapidly switches from a higher SoI to a lower one and back again without the spacecraft actually moving in space. It always happens at the SoI boundary and can lead to infinite loops in the code actually. This was the reason for having that 1-2 km pad in the SoI transition code: if the spacecraft was safely inside the SoI, then it wouldn't go looking for an upwards transition that shouldn't occur. I realized that this is inelegant, however, after explaining it to you, and I did some thinking. Basically, when there is a downwards transition, at the moment of transition, the new spacecraft state (in the lower SoI) must have a flight path angle that is negative, which is equivalent to a true anomaly between -180 degrees and 0 degrees. The spacecraft must be descending, in other words. (I actually use a slightly different test, a dot product between the position and velocity vectors, but it's the same thing.) Likewise, at an upwards transition, immediately before the SoI transition, the spacecraft in the lower SoI must have a flight path angle that is positive - the spacecraft must be ascending. So, what I've done tonight is set that "safety factor" distance to 0.0 km in my code, and then add these two tests at each SoI transition that is found. The effect is that SoI transitions now occur immediately at the SoI boundary and not 1-2 km inside in for downwards transitions. (Upwards transitions are unaffected since those could be computed exactly without numerical search algorithms.) The SoI transition times should be anywhere from 0 to maybe 5 seconds more precise. In most cases this really didn't alter any of my test cases, but in one it actually did disrupt the last leg of the trip such that I had to go reoptimize to re-find Duna's SoI again. So maybe it was important, lol. Anyway, this new code is in KSPTOT v1.5.10 pre-release 12. The changes here are: Update to the SoI transition search code that should now precisely find the SoI boundary for downwards transitions. Fixed a bug with the optimizer constraint warning message units. @Drew Kerman (and anyone else interested!), could you take a look at some of your existing missions or asteroid cases with this new build and see if it helps the SoI transition times you've been documenting? Would definitely appreciate it.
×
×
  • Create New...