• Content Count

  • Joined

  • Last visited

Everything posted by Arrowstar

  1. Thanks for the visibility! Sorry I haven't been able to code as much over the past few weeks, personal life has been crazy.
  2. Correct! And sometimes not within acceptable margins lol (though we have plans for that sort of thing). How far off are you?
  3. @Drew Kerman, sorry I haven't had the chance to respond to your messages over the past week. It's been a crazy few days. I think I've addressed everything bug-related you've mentioned though and I'll post a pre-release today with the fixes. And here it is: KSPTOT v1.6.5 pre-release 7 Change log: LVD: Added the ability to compute the gradient sparsity to the custom finite differences gradient method, which can improve optimization speed and accuracy in some situations. LVD: Added IPOPT to optimizer list. MA: Resolved issue with orbital decay on coast that was breaking it. Resolved two issues with MA drag coefficient calculator that would slow down the calculations in some instances.
  4. Issue also resolved for next release, as well as another bug I found along the way. It looks like the way you've got it set up is causing the code that runs the drag calculations to become "stiff", meaning that the differential equations take forever to solve. I've made a change to the ODE solver function to something that handles stiff ODEs better, but it is still going to take some time to solve. I'm not completely sure why, to be honest. It could be the pretty high periapsis altitude means that there isn't a lot of variance on the trajectory when you change the drag coefficient. EDIT: Yeah, with that it solved in a few minutes. The answer I got was 3286.799992 though... lol.
  5. Author of KSPTOT here: Please let me know if you have any questions by posting on the KSPTOT thread!
  6. Red and blue is the main vehicle. Green is the first stage disposal trajectory after it falls away. Black dotted line is the orbit of the space station we're meeting up with. This is all with the new Set Kinematic State action I added a few pre-releases ago. Pretty neat, huh?
  7. I'll take a look this weekend! Thanks for sharing. In the mean time, I do want to share a new feature that's going to be in the next KSPTOT release within Launch Vehicle Designer. For some time now I've had the desire to be able to change variable values directly without either having to go through the optimizer or the specific UI window where that value is set. Enter the new "adjust variables" feature, available from the Optimization menu: This simple UI shows you all of the variables that are currently active in your script (NOT including any you've disabled in the event listbox), the current value, and the bounds. You can then adjust the value directly or with the slider. As you adjust, the plot and state windows in the main LVD UI will update so you can see what's happening. Saving will keep the changes you've made and canceling will restore the values of all variables to their original state. I hope this feature is useful to people as they use LVD! Oh, there is another enhancement. The variable bounds warning that you see below now shows the actual variables that are near bounds and not just the events that they're on. Should be more intuitive to use this way. Let me know if you have any questions!
  8. No problem. I don't know for sure why things behaved the way they did, but what I often find is that having constraints and objective functions that are very similar ("distance to body" and "periapsis altitude" for example), you may get funny behavior. But as you suggested, yes, all this is really something you just learn over time. Keep playing with MA (and give Launch Vehicle Designer a go - it's basically an advanced MA with a more powerful way to structure what your vehicle is doing). You'll get it in no time!
  9. Here you go. All I had to do was change the objective function to Maximize Spacecraft Mass and reoptimize. It snapped right in, so I'm not sure what the issue was, but it seems to have been solved! EDIT: Also I found a bug in MA after optimizing that is definitely in the v1.6.5 pre-releases and causes the program to crash. I'll put out a new pre-release tomorrow with it fixed.
  10. Enjoy: KSPTOT v1.6.5 pre-release 5. Change log (LVD): Resolves an issue with the true anomaly event termination condition where the directional termination was reversed from expected behavior. Added a pop out orbit display button to the main LVD UI.
  11. Hey, yes, lol. I finally had a chance this afternoon. The true anomaly coast thing was a one-line bug that I fixed easily, so thanks for that report. About your insertion burn question: I haven't had a chance to fully recreate what you did yet. I need to walk through your steps. However, I would recommend allowing the pre-burn coast duration and burn attitude to be optimized, and then optimize those quantities. Some of the disconnect between LVD and MA is probably that inertial aero angles are not really the same thing as the NTW (prograde/radial/normal) vector components, although they are close. This may be why the MA and LVD solutions are different. But I still need to look into it more. EDIT: Okay, I got it. After you turn your engine on in event 18, create a Set Steering Model action and set it to an Inertial Aero Angles model with zeros across the board. Do not inherit the attitude. Set the burn duration in Event 19 to 30.478 seconds. You should get ~700 km SMA. I did. Basically your burn attitude in MA was pure prograde. Prior to this, you forgot to set your steering to be the same thing, so your burn didn't do what you expected. Glad you got it working! Please let me know if you have any questions. The maneuver planning tools are fairly straight forward but Mission Architect and Launch Vehicle Designer are definitely complicated tools to learn. I can help get you on the right path though! lol yes, I do wish KSPTOT got a bit more exposure for the amount of work I sink into it, but I mostly do it for myself, so it's not too big of a deal.
  12. Hi Scott! There is definitely a KSPTrajectoryOptimizationTool.exe file in the file that you downloaded. Check to make sure a firewall or antivirus program didn't remove it. It does require TCP/IP access for the local parallel processing to work (and I suspect MATLAB knows that when it starts the program). If nothing else, redownload the KSPTOT ZIP file. EDIT: Also, thanks for the complements! And please let me know if you have any questions about KSPTOT. EDIT 2: There is no actual install process per se. You just unzip the contents of the file to some folder and run the executable I mentioned above. It may take a few minutes to start running the first time. That's MATLAB unzipping some files into a hidden directory and nothing to be concerned about.
  13. Tonight I compiled KSPTOT v1.6.5 pre-release 4. It has the following changes to Launch Vehicle Designer: UI fix for Edit Event dialog box; Implemented universal elements for the Initial State and Set Kinematic State Action dialog boxes; Minor performance enhancements to calculating atmospheric temperature. What are universal elements? Universal elements are very similar to Keplerian orbital elements, with three differences. The size and shape of the orbit are specified by a combination of C3 energy and radius of periapsis (as opposed to SMA and eccentricity), and the true anomaly is replaced by a "seconds past periapsis" quantity. Why use universal elements? Universal elements are most helpful for specifying and optimizing hyperbolic flyby orbits using the new Set Kinematic State action in LVD. This is because, where SMA is singular (goes to infinity) as an orbit crosses from eccentric to hyperbolic, C3 energy merely goes from negative to zero to positive. This means that the underlying process of optimizing the flyby state is much easier, and you can constrain your C3 energy to be positive to ensure the flyby orbit is hyperbolic. In addition, because you can set the radius of periapsis directly, you can ensure that your flyby orbit doesn't enter atmosphere (or become a drill) just by setting the appropriate lower bound. As always, please let me know if you find any bugs. Thanks!
  14. Hi everyone, Tonight I'm happy to push out KSPTOT v1.6.5 pre-release 3. This is a super exciting pre-release for me and features the following changes and enhancements to Launch Vehicle Designer (LVD): Implementation of the new state representation system. In the initial state dialog box and the set kinematic state action dialog box, state representation and reference frame are now select-able in more combinations than before, and adding new reference frames and state representations is much, much easier going forward. New "set kinematic state" action. Use this to set the time, position, velocity, and stage states of the spacecraft arbitrarily (or optimize them), or inherit them from the final state of a previous event. New time, position, and continuity constraints for use with the set kinematic state action. FMINCON options now allow constraint, optimality, and step tolerances to go to 0. Objective functions are now "composites" of different functions. The values of these functions are added together in a fashion defined by the user. New plotting methods for events (applies to both the orbit display in the main LVD UI and graphical analysis plots). Also, I do want to take a moment to thank everyone that has helped in the development of KSPTOT over the past year by finding bugs, suggesting features, or even just asking questions that give me insight into how users use KSPTOT. And a big thank you to everyone who supported the development of KSPTOT financially over the past year via my Ko-Fi account. Thank you to you all! Happy orbiting and happy new year!
  15. By the way, here is an example of the branching trajectory I mentioned in the previous post. The red and blue lines are the normal ascent trajectory. The green line is the first stage disposal trajectory. Event 12 inherits the state from Event 5 and Event 13 propagates it to the ground. EDIT: By the way, in order to handle plotting correctly, there's a new "Plotting Method" drop down menu in the Edit Event dialog box. The default is "continuous" plotting which grabs the final state from the previous event and plots a line between that and the first state of the event. However, for these branching trajectories, this produces a disjoined trajectory, so I've added a new mode that basically skips that. It's called "skip first state" or something to that effect, and it will product what you see above. Also, there is now a method to skip plotting an event entirely, if you wanted to do that.
  16. Hi everyone, Today I have some pretty neat news regarding a new feature in KSPTOT's Launch Vehicle Designer (LVD) tool. One of the things that has always bugged me about how complicated trajectories are computed in KSPTOT (either Mission Architect or LVD) is how complicated it is to set up a flyby and then achieve the next flyby. Part of the issue is that intercepting a celestial body correctly, even the Mun, is a fairly challenging numerical task. Up to now, it could be done, but it took quite a bit of effort from users to get it right. Today I've introducing something that I hope will make that easier. Enter the "Set Kinematic State" event action and "continuity" constraints. Let's talk about the former first. This is the user interface for the new "set kinematic state" action. Kinematics is essentially time, position, and velocity (in any representation out there), and I've expanded the definitely slightly to include mass. I realize this looks a bit complicated, so let's break it down. The big thing to realize is that this is a way to set the state of the spacecraft, and you can either specify parts of the state directly or inherit those bits from the previous state (which is how the LVD normally works) or inherit them from the final state of an event of your choosing. Up top in the "orbit parameters" panel we have the way in which your orbit will be set and displayed in the UI. The "element set" is which set of six numbers to use for representing the orbit (so keperian elements, position and velocity vectors, or geographical elements such as latitude and longitude). The frame type sets which style of reference frame to use. Right now there are two: an inertial frame and a body-fixed frame. And finally, the central body tells the code which celestial body the orbit is relative to. This is fairly similar to the "set initial state" UI that was in there before, and indeed that user interface now has these three options as well. In the "time" panel, we have a few different things. First, there is a check box for "inherit time." If this is unchecked, then you either specify the time directly or can let an optimizer find it for you. If you check this box, then you decide where to inherit the time of this new state from: you can either let it come from the state immediately prior to executing this action, or you can pull it from the last state of an event that occurs prior to this one. The former is the default behavior for LVD and just lets time propagate forward as it does, continuously. If you specify an event, then the time of the state that comes out of this action will be the final time of the event you specify. The "state" and "stage states" panels work identically to time as far as inheritance goes. The only difference is that the state panel controls the position and velocity inheritance or specification, and the stage states panel controls how things like dry mass, tank masses, and engine and stage activation states are inherited. Stage states must always be inherited at the moment because I don't have a good way of letting users specify them right now. So how can you use this new functionality? There are two ways I've come up with: Specify a target orbit, such as GEO or a flyby of the Mun, and then optimize whichever parameters of those you desire. Use the continuity constraints, which I'll talk about below, to achieve a continuous trajectory. Branching trajectories: Let's say you are modeling a launch from Kerbin to low Kerbin orbit. You are a good engineer and want to make sure you don't drop your first stage on anyone's head. After modeling the full trajectory normally, create a new event with zero duration as the termination condition and apply this action to it. Then inherit the time, state, and stage states from immediately prior to first stage separation. This time, deactivate all stages but the first stage, and allow the trajectory to propagate the orbit until impact with the ground. Determine the impact location. I'm sure other people will come up with new uses as well, this is just what I've come up with off the top of my head. Okay, now continuity constraints. If you are using the first application of this new action, then you'll want to make sure that your inbound trajectory meets up with the state that you specify/optimize here. Enter continuity constraints. If you apply time, position, and velocity continuity constraints on the event where this action is used, and you follow the advice and only have this action on a zero duration event, then you'll end up with a constraint which is satisfied when the end state of the previous event and the specified state in the UI are equal in time, position, and velocity. Why do this? It is very challenging for an optimizer to find those flybys, but as it turns out, enforcing continuity is actually pretty straight forward and a much easier numerical problem. This is a great way to specify the flyby you want and then make sure that the trajectory is actually continuous so that when you go to fly it, you end up with something realistic. There are seven new continuity constraints: one first time, three for position (X, Y, Z) and three for velocity (X, Y, Z). There is a new LVD example MAT file that shows how to set all this up. Well that was a lot! Any questions? I'll be releasing a pre-release with this all in it soon enough.