Arrowstar

Members
  • Content Count

    1,923
  • Joined

  • Last visited

Everything posted by Arrowstar

  1. You can think of it as the center of mass of the rocket. Yes, I know this moves as fuel drains, but that effect is so small that its impact on vehicle performance is negligible. In other news, life has calmed down a bit so hopefully I can get to some of the comments that have been posted here in the past month.
  2. Hello everyone! This evening I'm pleased to announce the release of the KSP Trajectory Optimization Tool v1.6.3. This release brings with it a host of new functionality across the spectrum of the KSPTOT application suite. The biggest new announcement is the inclusion of a new tool, the Vehicle Sizing Tool, or VST! The purpose of the Vehicle Sizing Tool is to allow KSP engineers to optimize vehicle masses while still hitting required mission delta-v across any number of mission phases and vehicle stages. As an example, you can use VST to plan a mission from Kerbin to Eve and back again, accurately sizing the vehicle for each leg of the journey and each stage of each of those legs. Never again will you need to question whether you've brought enough propellant on your interplanetary missions! Or even just those short hops to Low Kerbin Orbit. Other enhancements include some new Graphical Analysis tasks for Mission Architect (MA) and Launch Vehicle Designer (LVD), as well as a host of performance improvements and bug fixes for the same. Multi Flyby Maneuver Sequencer (MFMS) has also gotten a bit of love this go around with some new functionality for constraining your preliminary planetary tour mission designs. Finally, there is a new Launch Vehicle Designer tutorial included in the download package. Entitled "Eve: The Final Frontier", this tutorial walks users through a complete mission analysis cycle for a complete Eve-and-Back mission. Here's the complete change log: NEW TOOL: Vehicle Sizing Tool (VST). Allows engineers to optimize a spacecraft or launch vehicle's mass while targeting mission Delta-V or a variety of mission phases and vehicle stages. NEW TUTORIAL: "Eve: The Final Frontier", a Launch Vehicle Designer tutorial. LVD: Added third body gravity force model. LVD: Fixed bug with setting the initial state of t2t and e2t connections (if there were none of those types of connections). LVD: Fixed bug with setting the initial state of t2t and e2t connections (if there were none of those types of connections). LVD: Converted the velocity components of the body fixed initial state frame to use az el and magnitude LVD: Can now plot body-fixed rotating trajectories as well as 2D lat/long ground tracks. MEA: Resolved issue with maneuver node import. KSPTOT RTS: Resolved issue where the RTS host wasn't being saved (getting overridden with empty str) LVD/MA: Added tooltips to the optimization var bars in the observe optim GUI. RMS: Now can minimize only the first burn of the burn seq. RMS: Better plotting for hyperbolic orbits. MA: Fixed string error in InsertDVManeuver MA: Added a burn dv magnitude to the insert dv maneuver UI. MA: Fixed a bug with the lb/ub textboxes not being disabled when burn type changed. LVD/MA: Added a new C3 constraint to MA and LVD. LVD: Fixed plotting children bodies around Sun (or top level solar system body) LVD: Added new Eve sample return mission case LVD: Fixed title of Set Stage State UI. LVD: Fixed issues with deleting variables improperly LVD: Fixed issue with thrust being reported incorrectly if throttle is > 0 but all connected tanks to an engine are empty. Now reports zero for that engine as expected. LVD: Fixed issue when trying to create an Add Mass to Tank action LVD: Added ability to activate/deactivate constraints without deleting them. LVD: Added undo/redo states to most of the integrator/optimization option menu callbacks MA: Added line width to Other Spacecraft LVD: Added Mission Notes like MA LVD: Fixed issue with stop watch termination condition LVD: New Cd default for aero drag state is 0.3 MA: Added a GA task for "elevation of celestial body". MA: Ground stations can now be placed down to the center of central bodies (allowable altitude range changed). MFMS: Added ability to include or not departure and arrival Vinf from the MFMS objective function MFMS: Added arrival VInf vector components MA/LVD: Title bar for application now only shows file name and not file path of currently loaded file. MA/LVD: Added atmo press and density tasks to GA MA: UI now prompts users to change other s/c name when importing if name is not the default New Spacecraft MA/LVD: Added Mach Number GA task LVD: Resolved issue with non sequential events that occur immediately at the start of a sequential event causing the integration to go to the limits. LVD: Updated some LVD Example MATs to fix non satisfied constraints. ...and many more LVD performance enhancements and some other minor applicaton-wide bug fixes. As usual, the download is available in the first post of this thread. If you have any questions or discover any bugs, please drop me a line in some fashion to let me know and I'll do my best to address it! In particular, it would be great if those using the Linux version could provide any feedback on how it's working out. There are some known graphical issues, but those aside, if you discover any bugs that appear to be Linux-related, please let me know. Thanks! Finally, if you enjoy using KSPTOT and its many applications (the Porkchop Plotter, Multi-Flyby Maneuver Sequencer, Mission Architect, Launch Vehicle Designer, and all the rest), please consider buying me a coffee via my Ko-Fi account to support KSPTOT's development. As I note in the first post of this thread, KSPTOT is a labor of love that I have put many, many hundreds of hours into for the benefit of the KSP community. The best part of it for me, aside from knowing that KSPTOT is the premier mission design tool for KSP, is all the thank you notes I've received over the years. I offer this as another way to say "Thank you!", if you so desire. In any event, I hope you all enjoy! Happy orbiting!
  3. Okay thanks! It would be great if this could be a near term feature of FAR.
  4. In Launch Vehicle Designer, if there was a way for users to input drag coefficient and area (probably as a product, Cd*A) as a table with respect to Mach number, angle of attack, and side slip angle, would this be useful? @Drew Kerman?
  5. Oh right. I'll probably put in a quick dialog box that prompts the user to select if they want the name updated or not if the name is not the default name. Good suggestion.
  6. Does FAR have a method of outputting data from it's VAB/SPH analysis tools to a file?
  7. Correct. This was purely to update some gravitational parameters in the included file based on newer data released by NASA JPL.
  8. Hi everyone, Tonight I've compiled the 9th pre-release of KSPTOT v1.6.3. Here's the change log: Updates to the included bodiesSolarSystem.ini file, primarily in the gravitational parameter of the included bodies. MA/LVD: Title bar for application now only shows file name and not file path of currently loaded file. LVD/MA: Open/Save_As functions now remember the last selected location. Please let me know if you find any bugs or see any other issues. Thanks!
  9. I've done the latter. Will be in the next release. Done. I actually thought it was doing this, so definitely a bug. Whoops...
  10. No, it doesn't check or uncheck any of the boxes. That's the beauty of it, actually: if you want to easily disable optimization temporarily on an event, you can do so with one menu option, and then restore it with that same menu option. No more tedious clicking and all that.
  11. Basically it just removed any variables and constraints associated with that event from being included in the optimization process. It's way easier than having to check and uncheck those checkboxes every time you want something to stay the same (or start optimizing again).
  12. Hi everyone, I have another pre-release ready to go tonight, KSPTOT v1.6.3 pre-release 8. The change log for this one is fairly brief: MFMS: Added options to include or not departure and arrival hyperbolic excess velocities, as well as constrain those quantities with upper bounds. Vehicle Sizing Tool: Cleaned up the default values when you open it. Some code refactoring under the hood. Please let me know if you find any bugs or issues I haven't yet addressed. I'm thinking we're getting close to an official release here. Happy orbiting!
  13. Okay, fix deployed. Please re-download the pre-release 7 ZIP file again. If I missed something, please let me know. I had to put this together sort of fast so hopefully nothing else is broken. If it is I'll take a look tomorrow.
  14. There are some technical difficulties with this as the data structures that hold celestial body information really weren't designed to be used with the Comm analysis tool. The easier "fix" might just be to allow ground stations to exist at the center of celestial bodies. That would be easier. I can investigate that, it should have the same effect. ---------------------------- In other news, I have built KSPTOT v1.6.3 pre-release 7 tonight. Here is the change log: NEW: Vehicle Sizing Tool (initial release) LVD: A fix for errors when using thrust-to-weight related quantities as termination conditions for event. MA/LVD: Added an "celestial body elevation" task for Graphical Analysis. Please let me me know if you find any bugs or issues, particularly with the new Vehicle Sizing Tool. Thanks!
  15. Oh got it. No at the moment there's no way to store ground stations across missions. I prefer to have each mission case start as clean as possible. I only include the KSC because it's always there in stock and it makes a good example for people to add others. How many ground stations do you add when you start each new case?
  16. 1) Sure, this could be done. Elevation with respect to the local horizontal plane? 2) I'll check this afternoon to be sure but this functionality should already be in there. If you use the Spacecraft -> Ground Targets menu, you can add ground station locations. I believe these will show up in the Comm Network Analysis tool.
  17. Hi everyone! I have a brief announcement regarding a new feature coming to KSPTOT in v1.6.3. In the course of putting together the Eve tutorial for Launch Vehicle Designer, I realized that in order to determine how big my vehicle needed to be in order to complete the mission, I needed to do a bunch of rocket equation-based math that turned out to be not so simple. This inspired me to write a solution that I am happy to introduce to you as the new "Vehicle Sizing Tool (VST)"! The use of the tool is very straight forward. Every mission can be broken up into logical phases that have some set maneuvers. These maneuvers define the delta-v requirements for that phase. For example, to ascend from Kerbin to low Kerbin orbit, a delta-v map might show 3400 m/s required. This is one mission phase. The next might be a transfer to the Mun (1170 m/s) and the final might be that required to land on the Mun (580 m/s). Every phase uses a number of discrete rocket stages to meet the user-defined required delta-v. Each stage has its own engine specific impulse, mass fraction, and desired thrust to weight ratio. (The latter is important if you want to understand how much thrust is needed to get off Kerbin, but also useful if you're in deep space and you just don't care about needing high thrust engines as well.) When you tap the "Run Sizing Analysis" button, the the code will attempt to minimize the total mass of the rocket while meeting the delta-v for each stage and the required stage mass fraction. I came up with an intelligent methodology that provides decent initial guesses for the solver, so unless the vehicle or mission is completely infeasible, it should generally come up with a solution. The outputs include mass data on the full vehicle as well as each stage. The masses shown should be taken as targets for the designer as they develop their vehicle. In addition, the delta-v, required thrust to meet desired thrust to weight, and stage burn time are also computed and provided. The first build of KSPTOT with the VST included will be the next v1.6.3 pre-release, which should get pushed out sometime this weekend. Some future enhancements I have my eye on are the ability to compute stages with side-mounted boosters (think SLS or the Space Shuttle), as well as the standard KSP asparagus staging set up. What do you all think?
  18. Issue resolved for next release. So I could remove the "Sea Level" part of it, but honestly it's both arbitrary and doesn't change all that much for most altitudes where you care. Unless a use case arises where the local gravitational acceleration at the current altitude is important, I'm inclined to just leave it as is. The only thing I could think of is if you were very high above Jool or the Sun and falling directly into it and wanted to exactly counteract the pull of gravity to "hover" there. Then local T2W would be important. That's all I can think of off the top of my head.
  19. Yeah, unfortunately comm links can't be used as an optimization constraint. They're really CPU intensive to compute and binary on/off types of things don't really work well with optimizers that need smooth gradients to figure out which way to go. This is the same reason why eclipses aren't a constraint you can use either. They are either on or off (there or not there) and optimizers just don't work well with that. Good thoughts about using Mission Animator, though! That should be accurate as I do model the position of the Sun directly in that. I'll take a look at the TWR error later today if I can. Thanks for the report! And yes, that is what the Perturb Optimization Variables feature does! You give it a percentage and it computes that percent of the width between the upper and lower bounds of every variable and modifies them by up to that much (the actual amount changed is random for each variable each time). It's a good way to give the optimizer a little nudge if it needs it to home in on a solution.
  20. Your Kerbin atmosphere curves are empty again, which means that the default pressure / density of the atmosphere, 0.0, is being returned. This is causing the dynamic pressure to be computed as 0.0.
  21. Are you using Mission Architect? If so, you can save what you're working on as a MAT file and send it to me and I can try to help.