Arrowstar

Hi everyone, Tonight I've built KSPTOT v.1.6.8 pre-release 7. This is a fairly large pre-release with a number of new features. Here's the change log: LVD: Bug fixes to the 3rd body gravity model. LVD: Bug fixes to optimizing Cartesian elements. LVD: Graphical Analysis is now using the App Designer framework and sports a new look. LVD: All fluid types are now their own GA tasks. Main KSPTOT user interface window is now ported over to App Designer framework. LVD: Constraints and objective functions now are aware of and respect user selected reference frames when evaluating values. LVD: Added halo orbit examples. The L2 halo orbit example is a full mission from low Kerbin orbit to the halo orbit around the Mun! LVD: Added third body gravity validator that checks to see if third body gravity sources are active with no force model or if the 3rd body gravity force model is active with no bodies. LVD: Extrema, Calculus Calculation objects, ground objects, and geometry objects now respect reference frames when computing their values. LVD: View Settings dialog now moved over to App Designer framework and sports a new look! LVD: Added Halo Orbit Constructor tool (Tools -> Halo Orbit Constructor menu) LVD: Performance improvements to frame conversions. Let's talk about the Halo Orbit Constructor tool for a moment! This is the new big feature I've been working on and will be very handy to those using Principia (or other n-body gravity mods for KSP). Halo orbits are a special kind of orbit that only appear in the circular restricted 3 body problem. They have a lot of special uses, but in general, you can think of them as orbits that are designed to stick around Lagrange points, or points where gravity between two celestial bodies sort of "balances". We see a few things here. Halo orbits are always constructed around a primary body and a secondary body that orbits it. In this case, I've selected to create a halo orbit near the Kerbin-Mun system. The Libration point (or Lagrange point) is the location around which the halo orbit will be closest. L2 is on the far side of the Mun from Kerbin. L1, the other option, is on the near side of the Mun. The "Z Amplitude" is an estimate of the height of the halo orbit above the plane of the Mun's orbit around the Mun. That "height" can be positive or negative depending on if you select a Northern or Southern sense. The differential corrector parameters allow you to adjust how the orbit is solved for. The Step Size Factor is used to provide numerical stability at the cost of longer computations. The smaller the number (> 0), then slower the code will run but it should not diverge as frequently. The Coordinate to Adjust defines which part of the initial estimated position vector the solver will adjust to compute your halo orbit. You can get very different results by changing this parameter. On the right you'll see the completed calculation results displayed. The blue line is the approximated halo orbit (derived from something called Richardson's 3rd Order method), the yellow line is what would happen if we propagated the approximated halo orbit directly, and the green line is the final result after using the differential corrector to make the orbit periodic. The green line is the final product of the calculations. On the results tab we have the initial state of the halo orbit you can use in LVD along with instructions on how to use it properly. Basically you can use it as an initial state or put it into a Set Kinematic State Action and away you go. You will need to do a bit more optimization with an LVD optimizer to get an actual periodic orbit, but it's not too hard if you follow the instructions. And if you do, magical things like this are possible: This is a full up mission to a halo orbit from LKO. You can see the green initial orbit line around Kerbin, the cyan coast out to the Mun, the blue Munar flyby orbit, and the orange halo orbit. The halo is actually moving clockwise and so the spacecraft turns around a bit down at the apoapsis, but that's okay. And where did the idea for this mission profile come from? NASA, of course! Check out this image that they're using for getting out to the Moon. Look familiar? Happy orbiting everyone! Feedback on the PR7 release is highly sought, especially for all the new bits that use App Designer now as well all the new items in LVD using reference frames. EDIT: PR7 download link now available!

Did anyone order a Near Rectilinear Halo Orbit? A while back I mentioned that I had fixed the 3rd body gravity model code in LVD. The past few days I've been working on a new tool within LVD called "Halo Orbit Approximator" which will allow users to construct these orbits fairly easily. It's not ready to be shown yet (I only have code now, no UI), but I should be able to get it into the next pre-release. I'm not sure how many people here use the Principia mod for KSP (the n-body gravity mod), but if you do, I would certainly appreciate real feedback from this new tool!

Hey everyone! Last week I found a pretty serious bug in the 3rd body gravity model within LVD. I fixed the bug and I'm happy to report that you can now create those fun halo orbits and the like in KSP, as if you were using Principia (for example). Happy orbiting!

Hi everyone, Tonight I want to share some changes that are coming to Launch Vehicle Designer's Graphical Analysis tool. This is the system in LVD that lets users extract data from an LVD mission, plot it, and export it to CSV files. As usual, the easiest way to start is to just show how things look now. There are two new elements to this system. First, you'll notice on the left a list of Tasks. These tasks are what GA will execute when you tap the "Plot Graphical Analysis Tasks" button on the bottom. Each task line item has two parts: the name of the task and the associated reference frame. This brings me to the second new element. Each task now has a reference frame associated with it. What this means is that if you want to compute, for example, the position of your spacecraft in any available reference frame, you can do it. That's what's shown in the example above. Here I'm outputting the position of the vehicle in the Kerbin Centered Inertial frame as well as the Kerbin-Mun two body rotating frame. Most tasks respond to the reference frame at this point. Right now, the two still outstanding on my list are related to extrema values and calculus values. There are some peculiarities with these two so I'm still considering how I might go about it. Critically, though, anything associated with vehicle kinematics (position, velocity, and all Keplerian, Geographic, and Universal Elements, plus related quantities) now handle GA task reference frames correctly. This means that if you want to output SMA in a rotating frame, or longitude in an inertial frame, you can! It might not make any sense, but you can. Of course, some tasks are frame independent. The density of the atmosphere does not care about what frame it's in, for example. All of the usual buttons and check boxes and inputs from the original LVD GA are still there, of course, just on the right instead of the left. They all work the same way they did before. Lastly, you might notice that the appearance of this UI looks a bit different from before. I've migrated this UI over to MATLAB's new (sort of) UI system, App Designer. The old system, GUIDE, is going away at some point in the future, so presumably at some point every UI in KSPTOT will get this treatment. I'm starting with simple UIs that have no outputs, since that actually doesn't work yet (MATLAB doesn't allow UIs in App Designer to return values yet, ugh!). I expect the main KSPTOT UI (the porkchop plot) and many of the single UI, standalone tools will get this treatment for the next version too. Mission Architect will likely not be updated in this way. It will still run, of course, no worries there, it will just be a bit harder to update in the future if I need to. Please let me know if you've got any questions! Happy orbiting.

Hi everyone, I decided to get out the v1.6.8 pre-release 6 build earlier than I thought I might. Here's the change log: LVD: Different steering models can be selected for each Euler angle now using the Selectable Model steering mode. LVD: All constraints now support the ability to evaluate themselves relative to the value of the same quantity at the end of another event. This is in addition to evaluating them relative to fixed bounds as well. Fixed an issue with importing the UT from KSPTOTConnect into the main KSPTOT user interface (the porkchop plot). Please let me know if you find any bugs, especially with the two new features as they are certainly experimental at this point!

Looks like I missed one. I have fixed it and I'll try to put out a PR6 with it fixed tomorrow. Thanks for the report!

Hi everyone, I have another KSPTOT update I want to share this evening. Coming to LVD in the next pre-release is going to be the ability to set constraints to not only fixed values and bounds, but also to an equivalent value in another event. Here's what I mean. Note the new "evaluation type" drop down menu is set to "state comparison. In this mode, the quantity to be constrained (here, delta-v expended over an event) at the end of Event 1 will be compared to the delta-v expended over Event 2. The constraint is satisfied when the two values are equal (in this case). You can also set the constraint to be satisfied when the quantity in Event 1 is greater than or less than that of Event 2. Let's take a look at an example of how this works in practice. In this example, I have three burn "parts." The first two burn prograde and the third burns retrograde. I want the expended delta-v in the first segment to be exactly 0.05 km/s, and I want the delta-v in the second segment to be equal to exactly that. In the third segment, I want to return the SMA back to what it was at the start of the mission, 700 km, by burning retrograde. Notice that when states are compared instead, new tooltip text appears that shows you which state the constraint is using for comparison (always the last state of an event, same as with bound constraints). It also shows you the value of both quantities at the end of their respective events and indicates how the comparison is being done (equals to, greater than, or less than). What do you all think? Happy orbiting!

Hi everyone, I know there's been a bit of a break in KSPTOT development over the past month or two, but tonight I want to share a neat feature update for Launch Vehicle Designer. To date, all steering models have been pretty fixed in their format. For example, if you select polynominal steering, then everything is going to be a polynomial. If you select linear tangent steering, then pitch is linear tangent and everything else is polynomial. And so on. This has always bothered me a bit, and so tonight I have the solution: selectable steering models for each Euler angle. Right now I have all three major steering model types implemented: polynomial, linear tangent, and sum of sines. The fourth, attitude interpolation, needs to stay it's own thing because it relies on controlling all three angles directly. As you can see here, you can now set roll to use a linear tangent law, pitch to use sum of sines, and yaw can be a polynomial. In addition, the polynomial steering has gotten a lot more flexible (for this application - the old three term steering is still there if you select it). You can now create as many terms as you want and optimize their coefficient and exponent directly. See here: In this case, this is a linear function that varies the angular rate at 2.0 deg/s. I know it's linear because the exponent is 1.0 and I know the rate is 2.0 deg/s because the coefficient is 2.0. You can also have non-integer exponents, negative exponents, and all that. It's pretty cool! Because this supersedes the sum of sines steering model that I had in there directly, I'm going to be turning off the ability to select that option in the next pre-release. Instead, to get to this UI, you select the "Selectable Model" steering model in the list box prompt. Please let me know if you have any questions!

Issue has been resolved and I've updated the v1.6.8 PR5 download with the updated executables. Thanks for the report!

Do you have a copy of MATLAB R2017b or R2021a for MacOS?

The person who volunteered to build the MacOS version for me has not been around for some time (since maybe version 1.1 or so). I don't own a Mac and so basically my options were either to let the last built version stay up or ask people to use a VM. Using a VM will definitely cause a hit to performance, but it's the best I've got. I don't think this is true though! You can run the KSPTOTConnect plugin on MacOS in KSP and then just figure out what 192.168.x.y your Linux VM and main machine are at, and then connect accordingly. Or I think anyway. Long story short, you shouldn't need to run KSP in a VM to get this to work.

Just a heads up, I found a bug in the PR5 build that caused certain listbox UIs to not appear when opened. This was due to the upgrade to R2021a. I've resolved the issue and rebuilt PR5. Please redownload when you have a chance. Thanks!

You can but there's no need to.

Hi everyone! Tonight I'm excited to announce the release of KSPTOT v1.6.8 pre-release 5. This is a major update, not for the features that it brings, but because it marks KSPTOT moving to a new release of MATLAB after ~4 years on the venerable R2017b! As of PR5, we will be on the latest and greatest, R2021a! In order to use this release, and all releases going forwards, you will need to download and install the MATLAB Compiler Runtime for R2021a (MATLAB 9.10) for your operating system at this link: here. The R2017b MCR will not run PR5 and later. Why move to R2021a? Because I saw a ton of performance improvements across the board. In LVD, I was seeing a ~25% decrease in run time in my "Two Stage to Orbit" example just by moving to this version. It was simply too good to ignore and not pass on to you. And as an added bonus, the KSPTOT downloads are now 50% smaller than before. It's really win-win all around. Here's the change log. It's pretty minimal because most of my development time has been spent checking out R2021a. Upgrade MATLAB version to R2021a. LVD: Incorporation of surrogate optimizer as an optimization method. LVD: New optimizer output for NOMAD and PatternSearch optimizers. A bunch of bug fixes and tweaks all around. Because this is a new MATLAB release, and because it's impossible for me to test everything, I would certainly appreciate if everyone could please take a look at this release, test it out, and report back any bugs. Thank you! Happy orbiting.

I'm just glad it's been dealt with!

Hi everyone, Good news! The Reddit admins were able to restore my account to me. Needless to say, I am very grateful and have turned on 2 factor authentication so this doesn't happen again. I've also cleaned out the filth that the hijacker posted. Unfortunately it looks like all of my posts were basically deleted. I've asked to see if they can be recovered, but I suspect that the answer is no. Anyway, I will likely be deactivating the /u/Arrowstar2 account in the near future, so please don't follow that one or anything. Thanks!

Hi everyone, I wanted to make the KSPTOT community aware today that my Reddit account (/u/Arrowstar) that I've previously used to discuss KSPTOT on the KSP subreddit was hijacked last week. I am trying to get it back and have emailed the support people to see if they'll work with me. Unfortunately, at this time it looks like whoever now controls it has started to post NSFW content. This is not me. They also deleted the past 4 years of my posts, including KSPTOT postings as well as other personal things I've done (RIP to my paintings on /r/HappyTrees). Needless to say, I was pretty hurt when I saw this happen. I've created a (hopefully temporary) new account, /u/Arrowstar2. Obviously I don't have much KSPTOT stuff to post at the moment, but I wanted to make everyone aware so you didn't think terrible things of me or anything. If I get the account back, I'll update this post with more information. Thanks for understanding, everyone.

I appreciate the shout out, @Curveball Anders! Madman, genius, either works. For the record, @Dr. Kerbal, if you want to use KSPTOT for this, the tool you're looking for is the Multi-flyby Maneuver Sequencer. Here's an example of what you can get out of that:

I'm currently re-uploading KSPTOT v1.6.8 pre-release 4 with a fix for the LVD bug @Tacombel found. This is the only difference between the previously released PR4. Give it 10-15 minutes from this post and then re-download it if you'd like the fixed version. The bug had to do with optimizing the new flight path angle termination condition, so if you don't need that, then there's no need to download this build.

No, the MAT file you sent was an LVD file.

I can after I fix the bug you found. I'll push out a fix tomorrow.

I'm afraid it's not. That would break the assumptions of the underlying math. Doing Kerbin->Eve->Duna to get the departure/arrival dates and then use LVD to find the actual trajectory.

The true anomaly of the initial departure burn is listed. That's the burn location in the initial orbit. By the way, the arrival and departure dates for the mission are shown in the second, "Transfer Orbit" box on the right.

It's at the periapsis of the inbound hyperbolic orbit of each gravity assist.

Oh got it. All powered gravity assist maneuvers in MFMS occur at periapsis, so you can use that as your timing.