• Content Count

  • Joined

  • Last visited

Community Reputation

542 Excellent

1 Follower

About Arrowstar

  • Rank

Recent Profile Visitors

1,970 profile views
  1. Hey everyone! Today I've created KSPTOT v1.6.0 pre-release 2. This is the second pre-release with updates for the upcoming Launch Vehicle Designer feature I've been discussing. The changes from the last pre-release to this one are too numerous to enumerate in full, so I won't even try. However, you should find that everything is a bit more stable and there are more features. The only other feature I want to get in is a Graphical Analysis tool for outputs. However, that will need to wait on the next pre-release due to the complexity of that task. LVD *.mat save files created with the first pre-release are not compatible with this release due to the massive changes in the code between releases. Sorry about that. As always, please let me know if you have any questions or if you find any bugs. Thanks! No worries. Please make sure you take a look at the latest pre-release when you poke around with it. Thanks!
  2. Quick update on Launch Vehicle Designer: I've changed the way the Euler angles steering law works for the next update. What I released before used a Velocity (Inertial) Vector, Local Horizontal frame to compute yaw/pitch/roll. As of now, it will use a "North-East-Down" frame. The big difference here is that yaw is relative to north now and not the velocity vector. So to launch east, you always use a 90 degree yaw angle. Or roll to 90 degrees while pitched straight up, the bring the pitch down, same thing. This just made a little more sense to me I think, I never did like your steering being tied to the inertial velocity vector like that.
  3. Hi everyone! I have excellent news. This afternoon I finished compiling what I am calling KSPTOT v1.6.0 pre-release 1. This is the first version of KSPTOT with the new Launch Vehicle Designer (LVD) in place. Since I know there are some who are eager to get using this functionality, here's the link: KSPTOT v1.6.0 pre-release 1 (EDIT: Hang on one second, I found a sort of big bug with the constraints UI. Stand by...) (EDIT: Okay, all clear. Go redownload the ZIP file if you haven't already.) To access LVD, start KSPTOT, go to the Tools -> Mission Planning -> Launch Vehicle Designer. A few caveats: There's not really any way to get anything useful out of LVD at the moment. You can certainly use it to design launch vehicles and create optimal ascent trajectories, but there's no Graphical Analysis support (yet), no outputs for roll/pitch/yaw profiles (yet), etc. There's no way to edit the way the integrator or optimizer work (yet). The code does not currently handle sphere of influence changes (yet), so whatever body you start on is the one you're stuck around for the time being. Mostly the vehicle attitude stuff makes this complicated. When you start LVD, there will be a pre-created mission profile in there. I wanted to give everyone an idea of what a very basic launch vehicle and mission might look like. This will be removed for the final v1.6.0 release and replaced with something more generic, just as Mission Architect is now. Some things are potentially very fragile and might cause crashes, but I couldn't tell you what they are... that's the point of giving it to everyone to play with lol. Here's what I need from you if you decide to use LVD in this pre-release: If you find any bugs, please report them in this thread or on the Github. Either way, I need to know what happened, how I can recreate it, a copy of the ksptot.log file, and if you can, the LVD *.MAT save file with the issue. If you see some functionality that you feel is missing, please report it here or on Github. I need a good description of what you're looking for. Examples of this I'm anticipating include event termination conditions and event actions. If you have any comments on usability or work flow, please just post those here. And that's it! I look forward to everyone giving this a try and helping me improve it for the upcoming v1.6.0 release. @Drew Kerman, you can stop screaming now I think.
  4. The simplest thing to try is to see if moving the maneuver node around actually gets you to the target, Duna in your case. If it does, then there's something wrong with how you're uploading it. Make sure you're using the Time Past Periapsis upload option, make sure that the orbit you have in the game matches the orbit you have in KSPTOT, and make sure that the maneuver node Delta-V components are correct. If you still don't have any luck, please provide a screenshot that shows the problem (both of KSPTOT and of KSP with the node that isn't working), that would be great. I'll see what I can do with it. Alternatively, if you give me the KSP save file and the inputs you used to generate the Kerbin to Duna trajectory, I'll see if I can't recreate what you're going through and advise on how to use KSPTOT better. Thanks!
  5. RSS/RO: Yes. As with all elements of KSPTOT, LVD will use the same celestial body information provided by the user. You just need to create a bodies.ini file with RSS values (the plugin KSPTOTConnect can do this, see the OP of this thread). Principia: No. But LVD is primarily a launch vehicle tool, where the main forces to model are central body gravity, drag, and thrust. 3rd body perturbations are much less significant than these. Naming: Launch vehicle design and trajectory design go hand in hand. You can't optimize the trajectory without a launch vehicle, and you can't optimize the launch vehicle without a basic idea of where the trajectory is going. This sort of thing is an iterative cycle of designing the vehicle, optimizing the trajectory, and then changing the vehicle to get more performance and repeating. So really, it's all of the above.
  6. Could everyone that's been having issues with the MCR please give this possible solution from The MathWorks a try? It involves adjusting some environment variables. Be sure to restart your computer after you follow these instructions, and then report back letting me know if the issues persists or has been resolved. EDIT: By the way, in the solution you have to specify the path to the MCR. The example they give is " C:\Program Files\MATLAB\MATLAB Compiler Runtime\v82\runtime\win64". That "v82" probably needs to be something like "v93" for this version of KSPTOT, but please check the path yourself and verify that whatever you put into the environment variable is actually where the MCR is installed. EDIT2: I just installed the MCR and checked myself. I believe this is what you need to add to your Windows path: "C:\Program Files\MATLAB\MATLAB Runtime\v93\runtime\win64"
  7. Hi everyone! Today I have a very special announcement related to the upcoming release of KSP Trajectory Optimization Tool. Some of you will remember that a number of years ago I attempted to put together a tool for KSPTOT that would help optimize launch trajectories. This problem is fundamentally different than spacecraft trajectory design and KSPTOT felt lacking without it. However, the approach I used then was the wrong one and I ultimately shelved the idea because I could not get it to work. After a fair bit of time, I'm excited to announce that I have rethought the idea from scratch and have begun working on what will be a feature of Mission Architecture known as Launch Vehicle Designer (LVD)! The first thing that will strike you about LVD is that it looks very much like Mission Architect. This is by design. MA has a stable user community and a well-defined work flow. I wanted people familiar with Mission Architect to be able to jump in with a general idea of where everything on the main UI was and what it did. Everything from the mission script to the state displays to the graphical trajectory display will be familiar to existing MA users. People should be able to jump in and start designing launch vehicles and optimizing their trajectories with a minimum of new knowledge. In the "Launch Vehicle" menu is an option to edit your launch vehicle. This is very similar to the Spacecraft menu in Mission Architect. Here you define all the physical properties of your spacecraft. Launch Vehicles (LVs) are made up of four components: stages, engines, tanks, and engine-to-tank connections (or 'connections'). This UI has buttons to help you edit each of these component types, as well as a handy display for showing critical launch vehicle information. Stages are the basic building block of an LV. As in KSP, stages are basically made up of tanks and engines. A stage element also models all of the dry mass for that stage. Stages can be active or inactive. Active stages are considered to still be part of the LV. Inactive stages are not, and nothing attached to them (engines or tanks) will function as soon as the stage is inactive. Inactive stage dry mass also is not counted. Turning a stage "inactive" is a bit like tapping spacebar in KSP to fire a decoupler. Engines provide thrust at a specific impulse. As in KSP, both sea level and vacuum thrust and Isp are modeled. Engines can also be active or inactive and this state can be switched on the fly in flight. Inactive engines provide no thrust. Tanks hold propellant. Tanks are defined with an initial amount of propellant and that amount decreases as engines draw from it over time. Engine to tank connections tell LVD which tanks every engine draws propellant from. Engines decrease tank masses equally across all connected tanks by an amount specified by the thrust and Isp of the engine. Multiple engines can draw from the same tank and multiple tanks can feed the same engine. Like stages, connections can be turned on and off in flight. This lets people model all sorts of complex behavior, including asparagus staging. The initial state of your launch vehicle is defined not as an event (like in Mission Architect), but separately, also under the Launch Vehicle menu. This is similar to the Set State event from MA, however. You'll notice that you can define an orbit a variety of ways. Right now, either Keplerian elements or latitude/longitude/altitude are supported. Aerodynamics properties can also be set and adjusted on the fly in flight. The Launch Vehicle and Stage States button allows you to define which stages, engines, and connections are active or inactive at the start of the mission. If you tap the Edit Steering Initial State, it'll bring up a dialog box to define the initial orientation of the vehicle. Like MA, all steering in LVD is proscribed (so no modeling of torque or anything goes on). However, unlike MA, LVD tracks the full orientation of the vehicle. You can do so using two different element sets: either the familiar roll/pitch/yaw, or the aerodynamics angles of bank, angle of attack, and side slip. Note that the way the coordinate systems are defined, a pitch of -90 degrees is actually up and +90 degrees is down. I'll need to put a note in this UI about that. Each of the steering angles can be set and optimized independently, and each angle can vary in time using linear and acceleration terms. Throttle works similarly to steering. A throttle setting of 1 means any active engine with fuel will provide full thrust, and 0 means no thrust. Throttle can be varied in time using the same linear and acceleration terms steering uses. All of these quantities can be optimized, too. Finally, events. This is probably the biggest departure from the MA paradigm. Every event uses the same structure. Events are made up of two elements: the termination condition and the actions. The termination condition is like the "go to" element of MA coasts. The propagator will propagate the orbit, with any thrust from the engines and drag from the air, until the termination condition is met. Right now I think I only have termination conditions for duration, tank mass (useful for stopping when you run out of prop in a stage), and angle of attack. I plan on getting true anomaly in there soon. Actions are things that occur after the propagation of an event. The picture shows two: setting an engine state to active, and adjusting the throttle model to something else. You can also adjust the steering model, setting a stage active or inactive, and other things. Anyway, that's all I can show tonight! There's still plenty of work to be done. The propagator needs some serious performance improvement help, the warnings and alerts need to be created, more termination conditions need to be created, and some other user friendly things need to be added. But it's a good start! I do plan on releasing a pre-release as soon as I get the code to the point where the public can use it without it crashing or being excessively slow. So, thoughts?
  8. As an FYI, this occurs the first time you run it because a bunch of files need to get unpacked. After that, the executable just calls the already unpacked files and so it starts much quicker. Unfortunately I don't have any way to influence how that works or put up a note to the user or anything like that.
  9. Hmm that is very strange. Out of curiosity, is there another computer you can try on? Also can I get the exact text of the error message?
  10. Did you upgrade to the MATLAB R2017b (9.3) runtime? Can you verify that this is the version you have installed? If you have other MCR versions installed, have you tried uninstalling them? Have you restarted your computer since installing the R2017b MCR? EDIT: You are running this on 64-bit Windows, right? Mac and Linux are not supported.
  11. Hey, sorry, just seeing this now. The answer is that stock KSP assumes that the planets have no tilt, and so I made the same assumption with KSPTOT. In other words, every planet's coordinate system is assumed to be parallel to the solar system coordinate system. It wouldn't be too hard to add in support for that, I assume. I would just need the z and (maybe) x axis directions in the solar system coordinate system for each body coordinate system. The answer, at the moment, is sort of. You have to use Mission Architect (MA) for it. You can definitely do "vacuum" impact point calculations, that's easy. (See the Mission Architect example included called "Mission to Minmus" or something to that effect.) A vacuum impact point is the point at which a trajectory intersects the ground without accounting for atmospheric drag. However, atmospheric modeling is somewhat primitive at the moment. You could try using the aerobraking event type in MA, though I think that event doesn't like it when you never show up out of the atmosphere again. I would start by just modeling your reentry using the two body assumption (so just a basic coast, and coast down to an altitude of 0), and then come up with a way to adjust your pre-entry orbit to account for the fact that drag will pull that impact point a bit closer to the point where you hit the atmosphere. Honestly, depending on your flight path angle at entry interface, the vacuum impact point may not even be a terrible assumption. Give it a go and let me know how it goes. I'm happy to help you come up with a good solution if I can. :) Yes, it will work with re-scaling mods. Follow the instructions in the OP to create a custom bodies.ini file for your re-scaled solar system and then import that custom bodies.ini file into KSPTOT. Let me know if you need help, I'm happy to help!.
  12. No worries! I'll probably do the release of the current development code before then, but you can tell me if you find any bugs when you get back.
  13. @Kobymaru: The inclination is most likely the problem, yes. I know why they add it, but I wish they wouldn't... it causes issues like what you discovered. The only solution is to create the RSS bodies file like normal and then manually edit the inclinations to be more reasonable in the file. There's nothing much KSPTOT can do for it. I know it's a pain, I'm sorry. 1) Yes, that is expected behavior. When KSPTOT detects that a long Go To UT/DT coast is executing, and the orbit is eccentric, the code automatically splits out each orbit period into its own sub-coast. This is mostly done for graphical purposes (for example, if you go around 100 revs and use 100 states per coast, you would only get one point per rev, so the spacecraft would not appear to be moving). 2) Thanks for the report! I fixed it. Silly typos. In other news, I have an update on the new atmospheric model. I implemented the paper I noted above from U of Texas and it works quite nicely. Here's a someone eccentric orbit running with the orbit decay option on in Mission Architect: Green lines are perigee passes and blue lines are apogee passes. As expected, the spacecraft loses most of its apogee altitude at perigee, when the atmosphere is densest. Also note that perigee doesn't drop much at all, which I would expect too. Fun story, by the way: I was looking at this a few days ago and got stuck on a case where a very high eccentricity broke the algorithm. I ended up grabbing a fellow engineer at work over a break and we deconstructed what the UT author did, figured out they made a "nearly circular orbit" assumption in their math that they didn't mention in the paper, and re-worked the differential equations to eliminate the problem and to be more general. I really do like my job lol. (I did some testing on the raw algorithm yesterday on some cubesat data I found online and it compares reasonably well, so I'm much more confident in this model than the other one that's currently in the Orbit Decay mod.) Anyway, this new algorithm, correction and all, is in the next pre-release, here: KSPTOT v1.5.11 pre-release 4. This build also includes the fix mentioned above. Please give it a spin, all, and let me know if you find any bugs.