Jump to content

Arrowstar

Members
 View Profile  See their activity

  • Posts

    2,557

  • Joined

  • Last visited

 Content Type 

Everything posted by Arrowstar

  1. Arrowstar
    This is a great question. When I built Mission Architect, I didn't know anything about object oriented programming or anything like that, so I built the underlying data structure using something called "structures" which are just fancy keyword/value pair things. The problem is that these are super inflexible and if you make a change somewhere, you have to update it *everywhere*. Compare this to using classes and objects, where an update to the class propagates to all objects immediately and effortlessly. Long story short, there's no way I could get any of this into Mission Architect without a ton of work, sadly. It's just too clumsy on the back end at this point. Anyway, it's become extremely hard to update Mission Architect in any big way because of the limitations of the underlying data structure type. Because of that, yes, I do envision that Launch Vehicle Designer will ultimately become a replacement for MA in many ways. Mission Architect's big thing that it has going for it right now is speed: it's a lot faster to propagate a trajectory in MA because of the analytical way that trajectories are computed, as opposed to using an integrator. I've made some progress in LVD in this regard with the Two Body propagator model, which is faster in general than the Force Model propagator, and the ODE5 integrator, which is generally much faster (per step taken) than the ODE45/ODE113 integrator that MATLAB ships with. LVD is also more general and less hacky when atmosphere comes into play, because I can model drag and lift seamlessly with other force models like gravity. I'm not sure if this is what you wanted to hear or not, but it is my general vision for the future of end-to-end trajectory design in KSPTOT. I'm not going to get rid of Mission Architect, though: it's a great tool for in-space trajectory analysis still, and like I said, much faster at computing trajectories and the like. And I will continue to fix bugs in MA (and anywhere else) for as long as I maintain KSPTOT. Active development of MA is probably more or less complete at this point, though. -------------- In other news, here's KSPTOT v1.6.6. pre-release 3. The change log is as follows: LVD: Creation of new view settings/profile system. Addition of two-body rotating frame math under the hood, for use with the state representation code. EDIT: If you previously downloaded the pre-release, please go ahead and re-download it. I found a bug I wanted to get patched before this pre-release got out too much.
  2. Arrowstar
    Hi KSPTOT community! I've got some more exciting news for you all today. A while back I decided that the view options in Launch Vehicle Designer (LVD) were in need of an update, mostly due to things being pretty hacked together, especially with the addition of the different Orbit Displays (really, reference frames) that you could use. I've finished my update of this system so that things are now A) much more modular, and B) less hacked together, making new additions to the view system much easier to implement. First, let's start with a tour of the new View Settings UI, accessible from the LVD View menu. Here we introduce a new concept called "View Profiles." These are individual settings for how a mission should be displayed on the display area of the LVD user interface. An LVD mission case file can have as many profiles as necessary, and the profile with the * next to its name is the "active profile", meaning that is currently being used to display the mission. There are some new settings here for you to check out. First, you can now turn off the lat/long grid in the Body Fixed frame. You can also play with the background color of the plot, as well as the grid line colors (as well as turn grid lines on and off). Finally, there is a new way to view trajectories. You are all familiar with the current methodology for doing so, where the trajectory is rendered in "segments" that are grouped together by sphere of influence. So, for example, you view all of the Kerbin segments until you get to the Mun, and then the Mun segments, and then the remaining Kerbin segments. There are three mission segments here. The new way to view trajectories leverages my work with the reference update I made a few months ago. You can now view all mission segments all at once, regardless of which SoI they are part of, because all trajectory elements are converted over to whatever reference frame you want to view them in automatically. You can also view trajectories with respect to a two body rotating frame, as well as the previously available inertial and body-fixed frames. A two body rotating frame has one axis pointing from one body to the other body, another axes in the direction of the angular momentum of the one body to the other body, and the third completes the coordinate system. This is very useful for missions from, say, Kerbin to the Mun because you can construct a reference frame where neither Kerbin nor the Mun move, making it easier to visualize. I removed the Mercator projection 2D plot because it didn't work well, had limitations that didn't apply to the 3D views, and frankly didn't seem useful when you can make the same plots within GA. Finally, you may have noticed there is no checkbox to plot child bodies. I removed this and added the ability to plot any body in the display area. You can render those other bodies as either points ("Dots") or 3D spherical meshes. Now, let's take a look at some modest changes to the LVD main user interface. The first thing you should notice is that all those checkboxes and buttons under the display area are gone. They were either moved to the view settings UI, eliminated, or (in the case of the pop out frame button) moved directly to the View menu. Replacing that mess is a time slider. When you slide the slider around, you'll move the little diamond that represents the location of the spacecraft at that point in time around. You'll also move any celestial bodies that you plotted around too. Here's a simple example of what that looks like. This image also shows a two body rotating frame with Kerbin as the primary body and the Mun as the secondary body. The viewing stuff also natively supports the fact that multiple segments can have overlapping times, like in this mission. The black icon is the station to be met up with, the green icon is the discarded first stage, and the other icon is the spacecraft's trajectory in orbit. And here's that same Kerbin/Mun mission I showed first, but from an inertial frame so you can see the Mun moving. That's all I've got tonight! I'm open to thoughts and suggestions if you have any! A build with this in all it should be available by tomorrow.
  3. Arrowstar
    It's a conspiracy, @Drew Kerman. Thanks for the heads up, I'll take a look. Most likely it'll be fine, but it's good to be sure. EDIT: I ran the KSPTOTConnect plugin against v1.10 and didn't see any issues, but please let me know if anyone sees anything or finds a bug. I reploaded the pre-release 2 build because I found a bug that I wanted to get patched. Luckily for you all, this build also includes a new performance improvement that I stumbled upon. In atmospheric flight, I was seeing performance gains of ~10%-15%. It's pretty awesome.
  4. Arrowstar
    No no, nothing of the sort, haha. This is just a way for people to do things that LVD doesn't currently do that wouldn't make sense for me to implement either because they're too specific to one use case or because there isn't enough value to add the functionality based on the effort required. Quite a few commercial trajectory design software packages have a plugin feature and I felt my should, too. Speaking of which, here is KSPTOT v1.6.6 pre-release 2 that contains the first version of the plugin functionality! There's also a MAT file in there that shows an example usage, but really, most of the MATLAB language is now at your beck and call. Feedback on usage improvements and bugs is welcome. EDIT: Change log for my own future self's sake: LVD/MA: Fixed issue with eclipse calculations being wrong; LVD: Implemented initial cut of plugin system. Performance improvement when looking up celestial body data by body ID number.
  5. Arrowstar
    A possible use case would be to compute the value of some quantity that isn't in Graphical Analysis. Yes, you can always just ask your friendly neighborhood KSPTOT developer to add it to GA, but in cases where it's something too specific to really make sense, you can now create a plugin to: Open a CSV file on your computer; At every time step, compute the value of the quantity you wish to save; and After propagation, close the file and save. Another would be to set the value of a constraint to be a number that comes out of propagating the trajectory. For example, if you wanted the end position of Event 1 to be equal to some other position that couldn't be known ahead of time, you could use this to do that programmatically.
  6. Arrowstar
    Hi everyone! A week or two ago I mentioned that I was working on a plugin system for Launch Vehicle Designer in KSPTOT. I'm happy to announce that I've got something that is working reasonably well. Let's take a look at the new user interface, which is accessible from a new Plugins menu on the LVD main user interface. So what do we see here? On the left, you'll see a list of all the plugins contained within the current LVD mission file. The ability to add plugins, remove the selected plugin, and move plugins up and down in the list is identical to other places in LVD which this sort of functionality. In the center is the code editor. Right now it's a bit sparse, but you'll see a space that shows line numbers and highlights text according to the MATLAB language syntax. The drop down menu above the code box is mostly a way to change the context with which the plugin is executed, which in turn is basically a reference for what the function call to execute the plugin looks like, and tells you what inputs are available with that context. On the right, you'll see a place for setting the name of the plugin and a space for text that can be used to describe the plugin or put in notes. There's also a checkbox to turn execution of all plugins on an off in one switch, which might be useful for testing purposes or the like. You'll also see a bunch of check boxes in a "plugin execution" panel. Checking each of these boxes enables the plugin to be executed at that point in the propagation. In this way, you can control when and where a plugin's is run, as some code may only be applicable before propagation, or after an event is propagated, etc. You can also execute plugin code at each integrator time step, which might be useful for computing quantities that are not available in Graphical Analysis, if you can do the math for them. Finally, you'll see a Data Explorer button on the bottom right. This is a convenient way to take a look at the data structures are available within each execution context, and will be helpful for knowing what data you have available when coding and how to call it. Here's some images of what that UI looks like. The top level of data shown is always the function scope, which shows you all the data structures available to you as a plugin coder. Double clicking on each element in the list will change the data shown to that element of data, and the bread crumbs on the top of the UI will update to show you were you are at in exploring the data structures. Clicking a button in the bread crumbs will jump you to that data structure, and right clicking in the bread crumb area (not on a button) will give you a menu option to copy that data path to clipboard in a format that can be immediately used in your plugin code. Note that data is not editable in the data explorer at this time. Data should be edited in the plugin code directly, if needed. A few items that I'd like to try implementing in the future (that is, forward work) include: The ability to save and load plugins to/from file; Done and implemented. The ability to run plugin code with notional inputs directly in the editor as a method of debugging; and The ability for plugins to share data with each other. Done and implemented. I'm open to thoughts and suggestions! Thanks for reading, everyone.
  7. Arrowstar
    KSPTOT author here! If you have any questions, please post them over on the KSPTOT forum thread and I'll do my best to get back to you. And yes, it does use a lot of CPU time for various calculations, but as Elon Musk once said, "space is hard."
  8. Arrowstar
    Something like this? Can you verify for me if there's a munar eclipse in there somewhere around the halfway point? That funny spike in the otherwise uniform distribution shouldn't be happening if only Kerbin was involved.
  9. Arrowstar
    Alright, well, I can certainty see that there's a problem. I'll dig into it, thanks! EDIT: Well that was easy. Should be resolved for next release.
  10. Arrowstar
    Can I see a MAT file?
  11. Arrowstar
    Hi, KSPTOT community! Tonight I'm excited to announce that I'm working on an experimental feature I'm calling "plugins" for Launch Vehicle Designer. Have you ever found yourself wanting to do something complicated in LVD, something that would require a lot of work under the LVD hood and might only be useful for your specific situation? Plugins are designed to handle these sorts of cases by allowing you, the user, to write active MATLAB code that can interact with the LVD data in memory, modify it, and even manipulate some minor elements of the LVD UI: I envision that plugins will be allowed to execute at one or more of five points during trajectory propagation: Immediately prior to execution of the mission script; Immediately prior to the execution of sequential events; Immediately after the execution of sequential events; Immediately after the execution of the mission script; and Immediately after each integrator time step. The first four of these is basically already working, as you can see in the image above. The fifth will come later, as it will require some additional complexity to interface with the ODE suite's output function interface. I envision that plugins will be coded by the user in a user interface that I still need to create, but that would work somewhat like the MATLAB IDE, though significantly more limited (think syntax highlighting and line numbers only). I want to also have a tree menu that breaks down the object structure of the LVD data in memory and shows object properties and methods. I will warn people ahead of time that use of this feature will have a steep learning curve, as it will involve learning not only the MATLAB language but also the LVD data and how it is structured. I will also warn that it will be possible to completely hose your mission with this functionality, though luckily the Undo and Redo functionality should be helpful in making sure you don't lose everything completely. (Undo/Redo stores the complete LVD data set in memory after each action and "undoing" or "redoing" just involves loading that data set up and propagating again.) However, if you can get over those hurdles, this should be an immensely powerful tool to do things not currently possible in LVD, and that may never be possible in stock LVD. Since this work basically just started, I'm open to comments and suggestions for functionality you might like to see. Please let me know, thanks!
  12. Arrowstar
    Thanks for pointing this out. The amount of drag coefficient data is definitely going to be a part of it, not so much from the overhead in holding that in memory (it's pretty small), but the way the integrator needs to control error by handling the fact that the drag coefficient is changing more frequently, which results in more time steps. You have a few choices to mitigate this: Accept the performance as-is (which, btw, is half the time I spent propagating the "fine" MAT file lol); or Reduce the integration tolerance on ODE45 and consider switching to ODE113 for the longer two coasts at the end of the file; or Switch events 4-8 to use the ODE5 integrator with a time step that you believe offers sufficient accuracy. I was able to get the run time down from 30 seconds to 7 seconds by a combination of the latter two items and I believe the impact to accuracy wasn't so bad that it wouldn't be acceptable for me, but that decision is up to you. Just remember with ODE5, smaller time step means more CPU time and higher accuracy; and larger time step means less CPU time and lower accuracy.
  13. Arrowstar
    I'll look into it, thanks for the suggestion. Could I see one of the MAT files where things are running slowly? I'd like to profile it to see where the slowdown is. But yes, in general, try not to use more data than is strictly needed to get things to run accurately. This may not be fully me, as you mentioned. There's a lot of code in memory with LVD and MATLAB holds all that for performance reasons. It is starting to feel like at least 4 GB RAM is necessary to run KSPTOT plus the rest of the Windows operating system and other applications, yeah. I wish I had better news in this regard, but more features in KSPTOT means more code and that means more RAM usage.
  14. Arrowstar
    Wow, that should not have been the case with those specs. Could you tell me how to reproduce this freezing and high RAM usage?
  15. Arrowstar
    I'm sorry you had some issues with KSPTOT. Out of curiosity, could you tell me a bit about your computer? How much RAM and hard drive storage space do you have? Do you know what the processor is? KSPTOT can be a bit intensive, but the flyby tool shouldn't be causing your computer to crash.
  16. Arrowstar
    Resolved in KSPTOT v1.6.6 pre-release 1. Change log: MA: Resolved issue where Ground Targets UI would not open. LVD: Adjust variables UI is now not modal. Heed warning on dialog box. LVD: Graphical analysis now has an "event termination" time indicator line option for plotting. LVD: Resolved bug when adding a Set Drag Aero Properties action to an event that caused an error to be thrown (and no action to be added to the event).
  17. Arrowstar
    Glad to hear it!
  18. Arrowstar
    Well on the up side, at least I know I didn't mess anything up.
  19. Arrowstar
    Can I see your bodies.ini file? I can tell you that I'm pretty sure the xyz.6 version is what I think I have in the bodies.ini file that ships with KSPTOT. Are you sure you imported your bodies.ini file when you created the other .mat file?
  20. Arrowstar
    Are you sure this belongs in the Tools and Applications sub-forum?
  21. Arrowstar
    I found the issue. Luckily this one is a configuration issue. The gravitational parameter of Kerbin is different in the two files. One is using 3531.47300361997 and the the other using 3531.6 (Alaba Prediction... .mat is using this one). I'm not sure if something I told you at some point caused this, but this is causing the mean motion of the search tool to be different, which in turn is causing the propagation to happen differently, which in turn causes the different arrival times. Let me know if you need any help figuring out why this happened. Were you two ever able to get KSPTOT to work? Did you wait for the package to fully unpack before killing it?
  22. Arrowstar
    Both implemented for next release.
  23. Arrowstar
    Resolved for next release. Are you all set here then? It sounds like it from the look of it?
  24. Arrowstar
    Hey guys, sorry I've been absent from the thread for a bit now. I see your messages and notes. Every so often I just need a creative break from KSPTOT to go do other things or whatnot. Never fear, though, I will return. Yes, it does support Windows 7. The first time you run KSPTOT it might take a few minutes to start because it's unpacking the application from the compressed state that it's in. This is a quirk of MATLAB's app deployment tool, there's nothing I can really do about it unfortunately. Next time you try to start KSPTOT, let it run for a few minutes and just make sure the background app is still there and doesn't disappear.
  25. Arrowstar
    You're welcome! And yes, UT seconds don't care how long the day is, you are correct.
×
×
  • Create New...