Jump to content

Arrowstar

Members
 View Profile  See their activity

  • Posts

    2,561

  • Joined

  • Last visited

 Content Type 

Everything posted by Arrowstar

  1. Arrowstar
    As far as I can tell, the difference is that MATLAB is now using OpenGL as the render instead of the built-in "painters" renderer (which, admittedly, is far, far slower). Switching to painters gave the look you showed before but at the cost of a lot of performance. Not sure there's anything I can do about this one (in this version of MATLAB, anyway).
  2. Arrowstar
    Did the old figure rendering not? I haven't touched anything in that regard, and honestly, I'm not sure how much control MATLAB gives me over rendering at that level anyway. Are you seeing something different? Yeah, this probably isn't a bad idea. (EDIT: Done for both MA and LVD, will be in next pre-release, which is coming today.)
  3. Arrowstar
    @Drew Kerman All of the ground station stuff we've been looking at has inspired me to add something similar to Launch Vehicle Designer. I wanted to do a bit more than what I had done for Mission Architect though, so I worked on improving that functionality for LVD. Instead of "ground stations" we now have "ground objects" in LVD. What's a ground object? Literally anything that spends most of its time near the surface of a body. Could be an antenna, could be a rover, and could be an aircraft. Yes, those latter two move, and the new code handles that! It's pretty slick. Here's the new input UI for LVD's ground objects, available under Launch Vehicle -> Edit Ground Objects menu. On the left, you'll see the typical big list of ground objects that you've created for your case. On the right, you can edit the details for each object. A name, description, and which celestial body the object is located on it all there, as usual. There's more, though. You see the waypoints? You can now define points on the surface of the body that your object moves between, as well as the duration spent traveling between each waypoint. Waypoints are defined by latitude, longitude, and altitude, as is usual. The distance over ground from the selected waypoint to the next waypoint is shown, as well. You can have an unlimited amount of waypoints and they can be rearranged with the arrow keys, again as is usual for many LVD listboxes. Ground objects can exist in one of two ways: either limited existence between times, or for all time. The time at which a ground object "pops" into existence is the initial time shown in the UI, but if the "extrapolate times" box is checked, then the initial time is only used for computing where the ground object is at any given time, and the ground object will exist for all times. Additionally, ground objects with multiple waypoints can either loop through them and track along them backwards and forwards. Looping is enabled by checking the "Loop Ground Object Track" box and tracing forwards and backwards is enabled by unchecking that box. Ground objects can have a custom marker symbol color and shape, and their ground tracks can also have a custom color and line style. The view options have been updated to allow for ground objects to be displays, for their tracks to be displayed, and for line of sight to be displayed from the ground object to the spacecraft being modeled. Here's what that looks like in practice. Future work involves creating some graphical analysis tasks for ground object to s/c elevation, ground object to s/c azimuth, ground object line of sight, and distance from ground object to s/c. What do you think?
  4. Arrowstar
    Sweet, my math is finally right.
  5. 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?
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. 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?
  11. 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.
  12. 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?
  13. Arrowstar
    Can I see the MAT file?
  14. 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.
  15. 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.
  16. Arrowstar
    Here's KSPTOT v1.6.6 pre-release 5. This should fix your adjust variables bug, if you could take a look?
  17. 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.
  18. 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.
  19. 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.
  20. 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.
  21. 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/
  22. Arrowstar
    Wow, a ~30% decrease in run time, that's awesome. It's even better than I thought.
  23. 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!
  24. 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.
  25. 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).
×
×
  • Create New...