Jump to content

Arrowstar

Members
 View Profile  See their activity

  • Posts

    2,557

  • Joined

  • Last visited

 Content Type 

Everything posted by Arrowstar

  1. Arrowstar
    So I'm not actually sure the calculations you're seeing are wrong. Take a look at this plot of the location of the spacecraft and ground station in question during the second green "1" area on your GA plot. Blue square is spacecraft, red diamond is the ground station. The blue line is the vector from spacecraft to the ground station. (It's shorter than it should be, which I think might have to do with numeric round off since these are all sun-relative positions I'm plotting.) The sphere is Kerbin. Coordinates are sun relative. That honestly looks like you have visibility to the ground station. I'm wondering if your altitude has increased enough that, for just a brief time, you actually do have line of sight back to the station. That might explain why your ground track doesn't go backwards but you still see additional visibility. Eventually forward motion carries you back over the horizon of the station, again, though and you lose it. Or that's my theory anyway. What do you think?
  2. Arrowstar
    Thanks for these pictures. There's still definitely a bug, because the elevation angle for the station you mentioned is negative for most of the flight. I'll look into it.
  3. Arrowstar
    Oh, well, glad it's all working now! @Drew Kerman: Can you take a look at KSPTOT v1.6.6 pre-release 6? This should resolve your issue. Change log: MA: Resolve issue with line of sight to ground stations. LVD: Added thrust continuity options to the various thrust profiles. LVD: Added view profile option to draw the spacecraft body axes on the orbit projection.
  4. Arrowstar
    Okay, that's bizarre. Do you have write permissions to that folder? If not, move the KSPTOT executable file to somewhere you do (desktop works fine as a test). I need to see the log file to see the error message that is causing the problem.
  5. Arrowstar
    It should be right next to the place you have your KSPTrajectoryOptimizationTool.exe executable file. It's called "ksptot.log" and is generated as soon as you start the program.
  6. Arrowstar
    Let me look into it and I'll get back to you. Can you post the contents of your ksptot.log file for me to see?
  7. Arrowstar
    I think I've got it fixed (finally). I'll create a build tomorrow you can test on. And this build also will resolve the other issue as well with creating ground stations in MA.
  8. Arrowstar
    Are there any ground stations which are definitely not visible or which come into visibility (or leave visibility) during the flight that you know of?
  9. Arrowstar
    Can I see the MAT file?
  10. Arrowstar
    Okay, no worries. If the idea is to create movie files similar to what Mission Animator does in MA, I have considered adding this functionality, if that would ever interest you. Let me know.
  11. Arrowstar
    Glad to hear there are no issues! And I guess we can share ownership of the bug, haha. It's not impossible but it would require a new, separate to implement. What are you trying to accomplish? Maybe I can implement something that does what you're looking to do directly.
  12. Arrowstar
    Here's KSPTOT v1.6.6 pre-release 5. This should fix your adjust variables bug, if you could take a look?
  13. Arrowstar
    I looked into this and it doesn't look like it's possible. Basically MATLAB is just taking everything that would normally get written to console and writing it to file instead, and I don't have much of a way to influence that. I found a bug in the variable adjuster code. I'll put out a pre-release that hopefully resolves this tomorrow. Also note that all angle measures in KSPTOT are stored in radians in memory, so what you're looking at there might be radians/sec and not deg/sec. The bug shows up when time is part of a state definition (initial state or Set Kinematic State action) but is not an optimization variable. I will fix tomorrow.
  14. Arrowstar
    I'm not a big fan of video tutorials myself because I don't have any experience doing it and I don't have the equipment (screen recording software, microphone) in order to pull it off well enough. I can try to answer questions though, and I'm not opposed to having others make video tutorials if they want to. By the way, there are a few tutorials included with the software. Take a look and see if any are any help to you. You could do this in Mission Architect, yes. You'd set up a mission plan to go from KEO to a particular point around the Mun. You could also do this in Launch Vehicle Designer, they work pretty similarly. MA is probably a bit easier to get your head around, though neither is ultra easy. What you're asking is actually a fairly complex rendezvous problem. Check out my Kerbin to Duna example for Launch Vehicle Designer. It does this basically this, aside from the polar orbit. Should be a decent starting point to work off from. Ooo boy, low thrust trajectory optimization is something I'd love to tackle in in LVD, but honestly, what you're asking is an extremely complex trajectory design question, assuming you intend to actual model the low thrust departure burn directly. (And I'm a professional astrodynamicist, so you can take my word for it lol.) Here's what you could do, though. In LVD, set up an initial state and allow the SMA, inclination, and RAAN to be optimized quantities. Assume the eccentricity is 0 and argument of perigee doesn't matter. Figure out your bounds for SMA, inclination, and RAAN. Set up another event to actually model the low thrust burn. Set constraints for the end of that maneuver that align with whatever your departure conditions are. Be warned, this isn't a simple problem. The NOMAD solver might be able to pull off a solution, but I wouldn't try anything that relies on a gradient to actually solve this one. Let me know if you pull it off though! I hope this helps a bit. You have some pretty complex trajectory design problems you're looking. If you get stuck somewhere, let me know and if you're using MA or LVD, post your MAT file so I can take a look at it.
  15. Arrowstar
    I added a couple more new features today to the LVD view profile system. For a while now, I've wanted to be able to display the Sun's location as a vector from the center of the central body being plotted i the display area, and to have the optional ability to render the lighting that would be caused from the Sun. I've added both of those tonight. It was super easy actually, generally in thanks to the modularity of the new view system. Here's the sun vector and sun lighting in action. The render is about 1 Kerbin day and the orbit is shown in a Kerbin body-fixed frame. Both of these options are disabled by default and can be enabled/disabled independently.
  16. Arrowstar
    A few updates for the next pre-release, whenever that drops: LVD now remembers your view zoom and pan settings when you zoom and pan around. Theses settings are saved to the view profile, so when you switch view profiles, the zoom and pan will be set to where ever you left left. LVD can now plot thrust vectors. You can change the color, line style, scale, and spacing of the thrust vectors. Note that thrust vectors are not kinematic quantities, so if you plot them in a non-inertial frame, their orientation will be correct, but their orientation relative to things like the apparent velocity will not look right, as kinematic quantities such as position and velocity are transformed via the basic kinematic equation (or "transport theorem") and the thrust vectors are just rotated into the correct frame via a rotation matrix.
  17. Arrowstar
    No worries, I'm just giving you a hard time. You aren't the first person to say KSPTOT is a bit intimidating and you won't be the last. I don't require the burn location to be at the periapsis of the outbound orbit, no. What I do is optimize the burn location (the true anomaly) in the elliptical orbit and compute the delta-v required to achieve the required outbound hyperbolic excess velocity vector from that point. I then minimize that delta-v using an optimizer. The code in the file computeDepartArriveDVFromEllipticTarget should give you a rough idea of what's going on. Also look at computeHypOrbitFromEllipticTarget as well. Sorry for the lack of comments anywhere, I'm pretty terrible at doing that. And you're right, occasionally this does result in small radial components to the burn. You're correct here, at least for the porkchop plot and Compute Departure code. I make the same assumption. Feel free to ask any other questions and go through the KSPTOT code base for ideas: https://github.com/Arrowstar/ksptot/
  18. Arrowstar
    Wow, a ~30% decrease in run time, that's awesome. It's even better than I thought.
  19. Arrowstar
    I'm afraid not, not without rolling back anyway, as I don't create separate branches for pre-releases. A comparison against 1.6.5 would be just as useful to me though. And yes, I'll remember the versioning PR number stuff for next time!
  20. Arrowstar
    @Drew Kerman: I re-uploaded PR4 with a fix, give it a try now. EDIT: Hold off for a moment, I found another bug lol. EDIT 2: Okay, should be resolved now. New upload on the way.
  21. Arrowstar
    Weird, it works for me in native MATLAB but I also see it fail when built. I'll get a new version out tonight with a fix, hopefully (assuming I can find the flaw).
  22. Arrowstar
    Hi everyone, This afternoon, I've built KSPTOT v1.6.6 pre-release 4. This big update in this pre-release is LVD performance. I've really been focusing on getting the runtime for a simulation with atmospheric flight down as much as possible. Between pre-release 3 and pre-release 4, there should be a 15% to 20% decrease in runtime when running the example Two Stage to Orbit case file. If anyone has the time and wants to run some of their simulations under 3 and 4 and compare times to execute the scripts and report those numbers back here, I would be much obliged. Also as a note, there are some structural changes to some data models under the hood in PR4, so don't save things if you want to go back to PR3 or earlier still.
  23. Arrowstar
    Hey now. Cool tool, though, it's gotta neat look to it. You're on the right track with it.
  24. Arrowstar
    I don't think it will be too bad, but as always, evaluate and let me know your thoughts. In other news, I was able to squeak out another 5%-10% performance out of atmospheric flight in LVD. Right now the biggest single cause of run time in an LVD launch simulation (with an atmosphere) is computing the atmospheric temperature, and of that, computing the "sun dot normal" term is most of it. I've tried all sorts of ideas to improve the performance of this function the past few days, but so far, nothing has been shown to be viable on the level that would be required to make the effort worth it. Work continues though.
  25. Arrowstar
    I was thinking about it today, and I think it would be possible, yes. I'm not sure what the use case would be, though. What would you use a function like this for?
×
×
  • Create New...