Jump to content

[WIN/MAC/LINUX] KSP Trajectory Optimization Tool v1.6.7 [LVD / kOS Integration!]


Recommended Posts

On 1/12/2021 at 8:09 PM, Drew Kerman said:

@Arrowstar the latest Kerbal Weather Project update has been made to work with FAR so that the pressure and temperature changes are put into effect. Does my suggestion about manual input for weather data in LVD make sense? I feel this should be more upon the user to handle if they want to deal with it

You can certainly change the atmospheric inputs in the bodies.ini file for pressure and temperature.  I think that's as far as this is going to go in KSPTOT.  Managing the current atmospheric model is a pain in the neck already, and I would hate to try to add another one that's even more complex.

8 hours ago, RaceToTheMun said:

Is there any PDF advance tutorials in the Multi-Flyby Manuever Sequencer?

I think one of the two tutorials that ships with KSPTOT does include some brief discussion of MFMS, even if it's for MA.  But it's pretty simple to use in general, so I'd encourage you to play around with it and ask specific questions here if they come up.

Link to post
Share on other sites
19 minutes ago, Arrowstar said:

I would hate to try to add another one that's even more complex.

Not sure where this is coming from - I did not think that is what I was asking for. I was wondering if you'd make an additional dialog for changing temp/press curves but I personally have no problem just editing the .ini myself. It was more of a general user request

Link to post
Share on other sites
14 hours ago, Drew Kerman said:

Not sure where this is coming from - I did not think that is what I was asking for. I was wondering if you'd make an additional dialog for changing temp/press curves but I personally have no problem just editing the .ini myself. It was more of a general user request

Ooooh.  Okay, I see.  I guess maybe I didn't understand the original request.  I had been sort of under the impression you wanted me to implement the KWP model in KSPTOT, which is not really feasible lol.

I'll see what I can do. :)

Link to post
Share on other sites
6 hours ago, Arrowstar said:

I had been sort of under the impression you wanted me to implement the KWP model in KSPTOT, which is not really feasible lol

auuuugghhhhdffdweydfwjqefdwe I'm sorry you even had to think about that LOL :D I get it tho - I kinda ran with your joke about rewriting the atmo model and made it seem like it was a serious request. It most certainly was not heh heh. :)

You're more than welcome to wait until I (or someone else) actually start using the mod... just never heard back from you regarding this suggestion about possible LVD support in the KWP thread

Edited by Drew Kerman
Link to post
Share on other sites

Hi everyone,

Tonight I'm pleased to be able to share with you all the next major feature coming to KSPTOT's Launch Vehicle Designer (LVD).  Having previously improved the ability of LVD to handle different types of orbital elements,  the next thing I wanted to do was allow users to create their own reference frames within which those elements could be used.  This has led to the creation of the Geometry system within LVD.

The geometry system has four main components: points, vectors, coordinate systems, and reference frames.

  • Points are just that: 0-dimensional locations in space.  They have no mass, and are generally used to describe the location of an object.  There are five different types of points in LVD:
    • Fixed in Frame: These points have locations which are static within a particular reference frame.
    • Celestial Body: These points are located at the center of mass of celestial bodies.
    • Ground Object: These points are located at the location of ground objects.
    • Two Body: These points move according to the rules of two body gravitational motion.  Better yet, unlike the Other Spacecraft system of Mission Architect, these points are propagated with LVD's own Two Body Propagator and therefore can transition from one sphere of influence (SoI) to another.
    • Vehicle: These points are located at the location of the vehicle being modeled in LVD.  You generally only need one.
  • Vectors are geometric objects that have magnitude and direction.  They generally don't have an origin, though some vectors are displayed as offsets from a particular point.  There are a variety of different vector types.
    • Two Point:  These vectors are drawn from an origin point to a terminal point.  Their magnitude is the distance between the two points.  They may be constructed from any of the point types discussed earlier.
    • Cross Product: These vectors are constructed by taking the cross product of two other vectors.
    • Fixed in Frame: Like fixed in frame points, these are vectors that are unchanging within a given, specified reference frame.
    • Scaled: These vectors apply a scale factor to another vector. Scale factors can be negative to flip the direction of the vector.
    • Vehicle Data: These points can provide a variety of vector information regarding the vehicle under analysis, including radial vector, velocity, orbital angular momentum, north, and east.
  • Coordinate Systems are objects which describe an orientation.  They're similar to the concept of Rotations in kOS.  There are two sorts of coordinate systems thus far:
    • Aligned/Constrained coordinate systems fix one unit  vector of the system (say, the +X direction) along a specified vector, and then constrain another unit vector of the system (say, +Z) to be as close to another vector as possible.
    • Parallel coordinate systems are coordinate systems that are parallel to another reference frame.  Want to put Duna body-fixed coordinates on Jool for whatever reason?  This is how you can do that.
  • And finally, Reference Frames are basically coordinate systems that have an origin point.  You construct a reference frame by selecting a Point to serve as an origin and a coordinate system.

Geometry objects have three uses as of now:

  1. You can steer with them by specifying them as the reference frame in any of LVD's steering UIs.  Why would you want to do this?  Say you have an antenna on your vehicle that needs to point to KSC, but you also have solar panels which need to point to the sun.  Create a vehicle point, a Sun point, and a ground object point at KSC.  Then make two vectors, Vehicle to KSC, and Vehicle to Sun.  Create your aligned/constrained coordinate system using those two vectors, and make a reference frame from it centered at the vehicle point.  Now if you set your steering frame to the base frame and leave your steering angles at 0, your vehicle's attitude will be such that it always points to KSC and tries to get the solar panels into the sun as best it can.
  2. You can display points, vectors, and reference frames in the main LVD display.  Display settings for each object are on that object's UI.  Ground object points, vehicle points, and celestial body points cannot be displayed because there is already a way to display those objects in the view settings.  Objects that can be displayed are selected in the view settings, same as everything else.
  3. You can output data regarding points and vectors in Graphical Analysis.  Mostly this is only useful if you spit out data to a CSV file, but it can be done.

Here's an example of the geometry system in action.

Llpel3q.png?1

You can see a few things here going on.  The pink dashed line is a two body point in orbit around the Mun.  both points and their trajectories are displayed.  The green arrow is a Two Point vector from the vehicle to the two body point.  The cyan circle in the middle is a point fixed in the Kerbin-Mun rotating frame, and there's a reference frame (red, green, and blue lines) also at that point.  Finally, the purple line is a vector pointing west (minus east).

That's all I wanted to share about this tonight.  Please let me know if you have any thoughts!  This will be in the first pre-release for v1.6.8 and will probably land this weekend at some point.

Thanks!

Link to post
Share on other sites
4 hours ago, Drew Kerman said:

You're more than welcome to wait until I (or someone else) actually start using the mod... just never heard back from you regarding this suggestion about possible LVD support in the KWP thread

I will probably wait until you need it.  Just let me know.

Link to post
Share on other sites

Here's a nice video showing what LVD's kOS script plus the new reference frame system can do.  I have the vehicle pointing at KSC throughout an orbit, and during that time, we're trying to keep one face of the vehicle pointing at the Sun as closely as possible.

 

Link to post
Share on other sites

Hi everyone,

Tonight I've built KSPTOT v1.6.8 pre-release 1.  This pre-release introduces a major new feature to Launch Vehicle Designer, the geometry system.  Please see my post above for details.  Here's the full change log:

  • LVD: The function to export a kOS CSV file has been updated to allow users to select the event(s) they want to export.
  • LVD: Introduction of the geometry system.
  • LVD: The "launch vehicle" menu is now called "scenario," and the "edit launch vehicle" menu beneath it is now called "edit vehicle configuration."
  • Some additional bug fixes and performance improvements.
Link to post
Share on other sites

@Arrowstar is it possible to bring back the 2D Mercator plot option for LVD? Now with the surface texture it becomes more useful!

Also here's an LVD and MA file using the same SFS data and MA doesn't seem to rotate Kerbin properly. I know this isn't a big deal for the main MA display but the Mission Animator also does not properly set the rotation

Actually can we also get the option to use just shaded spheres in MA?

Edited by Drew Kerman
Link to post
Share on other sites
10 hours ago, Drew Kerman said:

@Arrowstar is it possible to bring back the 2D Mercator plot option for LVD? Now with the surface texture it becomes more useful!

Unfortunately this proved to be quite the pain in the neck.  I don't think it'll be possible.  You can always export the lat vs long from Graphical Analysis to see the 2D trajectory, of course.

Quote

Also here's an LVD and MA file using the same SFS data and MA doesn't seem to rotate Kerbin properly. I know this isn't a big deal for the main MA display but the Mission Animator also does not properly set the rotation

In MA's main display, the body does not rotate at all because there is not really a singular time to rotate it to.  I've fixed the issue for mission animator, though.  The central body will now rotate properly.

Quote

Actually can we also get the option to use just shaded spheres in MA?

I suppose.  What's the use case here?  I generally feel like the textured spheres are an improvement all around and there isn't much of a reason to go back to them.

Link to post
Share on other sites
5 hours ago, Arrowstar said:

You can always export the lat vs long from Graphical Analysis to see the 2D trajectory, of course.

Yup, I do this already for plots on my Ops Tracker, it just would have been easier in some cases to do it this way. No biggie just wondering

5 hours ago, Arrowstar said:

I've fixed the issue for mission animator, though.  The central body will now rotate properly.

Nice! Thx

5 hours ago, Arrowstar said:

What's the use case here? 

Well as you said and as I mentioned it not being a big deal, the whole concept of the textured sphere in MA is a bit useless when it comes to conveying orbital plots. If I'm posting something like this:

Kerbin I Mission Trajectory

There's just no point to it being textured and actually could make people wonder if I'm inferring something about the bodies textured orientation. It's just unnecessary really.

that being said... I have no problem whatsoever manually reverting back to older versions to get the untextured spheres. I just figured I'd ask in case it was something easy to implement you could just throw it in with whatever actually cool stuff you do next :) If not, then again - no biggie

Link to post
Share on other sites

First thing first, great tool! Congratulations. 

 

But I have trouble finding solutions, even when I feed the mission planner nodes that I know are OK, because I get an encounter on KSP, frecuently the optimizer changes the node to something that doesn't even intercept the target 

On of the most frequent problems I encounter is when setting a coast to true anomaly event and the solution is around cero, creating boundary problems. 

Ignoring my little comprehension of what True anomaly is (defines a position in the orbit?), how do I set the boundaries in the coast event to solve around near cero values? 

And, once I get an encounter, how do I know the periapsis of the hyperbolic orbit?

Thank you and I hope there is not a post two pages before explaining just that that I missed :kiss:

Edit: i think I already improved my ability to get a solution. My ship is still in Kerbin SOI, so I could add a coast to SOi and then look for a solution in the sun orbit

Edit: Certainly improving, got an encounter.

Edit: Got it!!!!! After each step I use the upload DV maneuver so I could use the map as a visual help and it has been really useful

To solve the problem with TA close to 0 y added a coast to TA 10º, is this correct or just a cheat?

By the way, I don't get a nice picture of my final state around the planet.

c8G7Wa8.png

Edited by Tacombel
Link to post
Share on other sites
On 1/19/2021 at 8:05 PM, Drew Kerman said:

that being said... I have no problem whatsoever manually reverting back to older versions to get the untextured spheres. I just figured I'd ask in case it was something easy to implement you could just throw it in with whatever actually cool stuff you do next :) If not, then again - no biggie

I think I'll probably leave it for now, as this is the only use.  However, it's worth noting that because you're plotting orbits, there shouldn't an expectation for the rotation of the body to mean anything, since those orbits take place over a wide range of times.  You could always just note this somewhere and be done with it.  Most professional trajectory design software that can show body surfaces doesn't worry about it too much.

7 hours ago, Tacombel said:

First thing first, great tool! Congratulations. 

 

But I have trouble finding solutions, even when I feed the mission planner nodes that I know are OK, because I get an encounter on KSP, frecuently the optimizer changes the node to something that doesn't even intercept the target 

On of the most os frequent problems I encounter is that setting a coast to true anomaly event the optimizer solves around cero, creating boundary problems. 

Ignoring my little comprehension of what True anomaly is (defines a position in the orbit?), how do I set the boundaries in the coast event to solve around near cero values? 

And, once I get an encounter, how do I know the periapsis of the hyperbolic orbit?

Thank you and I hope there is not a post two pages before explaining just that that I missed :kiss:

Edit: i think I already improved my ability to get a solution. My ship is still in Kerbin SOI, so I could add a coast to SOi and then look for a solution in the sun orbit

Edit: Certainly improving, got an encounter.

Edit: Got it!!!!! After each step I use the upload DV maneuver so I could use the map as a visual help and it has been really useful

To solve the problem with TA close to 0 y added a coast to TA 10º, is this correct or just a cheat?

By the way, I don't get a nice picture of my final state around the planet.

<snip>

Great, glad you figured it out.  Your final orbit is there, but you're viewing the full trajectory within the Duna SoI so that's why things look small.  You can always use the zoom buttons to zoom in for a better view.  And if you model your trajectory in Launch Vehicle Designer, there are more sophisticated camera tools there that you could use.

Link to post
Share on other sites

Hi everyone,

This afternoon I've built KSPTOT v1.6.8 pre-release 2.  Here's the change log:

  • LVD: Added three new constraints: ground object elevation, azimuth, and range.
  • MA: Mission Animator now properly rotates central celestial bodies.
  • LVD: Added a new vector, vector projected onto a plane, to the geometry system.
  • LVD: A few bug fixes and performance improvements.

Please let me know if you find any bugs or have any suggestions.  Thanks!

Link to post
Share on other sites
6 hours ago, Arrowstar said:

think I'll probably leave it for now, as this is the only use.

that's fine, I actually forgot I tend to go back to 1.6.5 anyways to get those nice anti-aliased plot lines. I just hate jaggies :)

Link to post
Share on other sites
  • 3 weeks later...
On 12/9/2020 at 12:40 AM, Drew Kerman said:

R2017b:

(00:35:35) Executed mission script in 3.397 seconds.                                         
(00:35:44) Executed mission script in 1.566 seconds.                                         
(00:35:46) Executed mission script in 1.453 seconds.                                         
(00:35:48) Executed mission script in 1.290 seconds.                                         
(00:35:50) Executed mission script in 1.384 seconds.                                         
(00:35:52) Executed mission script in 1.269 seconds.                                         
(00:35:54) Executed mission script in 1.187 seconds.                                         
(00:35:56) Executed mission script in 1.250 seconds.                                         
(00:36:05) Executed mission script in 1.247 seconds.                     

Win10 Pro x64
i7 4790K @ 4.2GHz
24GB RAM

mobo died last week but I was overdue for a 4yr CPU upgrade anyways since my i7 was purchased in 2016. Now rocking an i9 10900K, haven't done any OC yet nor to I plan to anytime soon but decided to flex it and see the results. Was not disappointed:

 (01:25:41) Executed mission script in 2.144 seconds.
 (01:25:46) Executed mission script in 1.083 seconds.
 (01:25:48) Executed mission script in 0.969 seconds.
 (01:25:50) Executed mission script in 0.934 seconds.
 (01:25:52) Executed mission script in 0.987 seconds.
 (01:25:54) Executed mission script in 0.899 seconds.
 (01:25:56) Executed mission script in 0.893 seconds.

Look forward to unleashing 10 cores on the optimizer...

Link to post
Share on other sites
7 hours ago, Drew Kerman said:

mobo died last week but I was overdue for a 4yr CPU upgrade anyways since my i7 was purchased in 2016. Now rocking an i9 10900K, haven't done any OC yet nor to I plan to anytime soon but decided to flex it and see the results. Was not disappointed:

 (01:25:41) Executed mission script in 2.144 seconds.
 (01:25:46) Executed mission script in 1.083 seconds.
 (01:25:48) Executed mission script in 0.969 seconds.
 (01:25:50) Executed mission script in 0.934 seconds.
 (01:25:52) Executed mission script in 0.987 seconds.
 (01:25:54) Executed mission script in 0.899 seconds.
 (01:25:56) Executed mission script in 0.893 seconds.

Look forward to unleashing 10 cores on the optimizer...

Hey that's like a 25-30% performance improvement! Not bad, not bad at all.  I have to laugh at your "overdue for an upgrade" comment though because I'm still rocking a 3rd generation Core i5 lol.

Link to post
Share on other sites
4 hours ago, Arrowstar said:

Hey that's like a 25-30% performance improvement! Not bad, not bad at all.  I have to laugh at your "overdue for an upgrade" comment though because I'm still rocking a 3rd generation Core i5 lol.

yup 31.5% if you average out all the values. Spiffy. Ever since I built my own rig for the first time in 2006 I've stuck as close as possible with updating my CPU every 4yrs and my GPU every 4yrs but offset but 2yrs, so every two years I do a hardware upgrade, which gives me enough time to slowly save up and so far it's kept me on pace with games and tech in general, never really felt I had a "slow system" at any point

Link to post
Share on other sites

hey @Arrowstar have a look at this LVD case file - if you delete the Kerbin III stage and close the vehicle config window the script will propagate to the max 15s. It seems to actually be the SUL-V1 x2 tank. If you delete the SUL-V1 x2 -> LV 303 connection and close the config window, it's okay. If you then delete the Restart x6 tank and close, it's okay. If you remove the LV 303 engine and close, it's okay. As soon as you delete the SUL-V1 x2 tank however the script runs off the deep end

Rats, instead of deleting the problem tank after removing the engine and other tank I tried to set the mass to 0 and the script ran amok still. Even 0.0001 didn't work

Edited by Drew Kerman
Link to post
Share on other sites

another issue or perhaps just need some clarification on some behavior - check this LVD case file. If you compute a Jacobian you'll see values upwards of 8x10^5 but if you go into the Initial State and set the initial UT to 0, when you recompute the Jacobian you'll see the values are now properly scaled to less than 1

While you have this file open, check the Dynamic Pressure output from the GA. This is what it looks like for me:

y2vf4Ne.png

The double hump is back and it not being smooth on the backside is also strange. Would this have to do with the changes you made back here?

Looking back on this though, I realized that there was never any mention made of the switch to the linear model in the change log - neither for the pre-releases or in the full log in the OP

Also, if you could get this rocket into an orbit using the linear tangent steering model it would be great to see how that would work. However this is simply me asking a favor. I will get around to figuring it out myself eventually. Was hoping to use it for this upcoming mission but losing my PC for a week has me crunched to get this mission aloft and I'm just reverting back to what I know from previous flights.

Edited by Drew Kerman
Link to post
Share on other sites

woooah @Arrowstar I'm seeing some more serious hinkyness here when messing with the Initial UT, moreso than just its effect on the Jacobian. Files download.

Start with Ascension Mk3 #1 Ascent.mat, which is mostly the same file I linked to in the last post but I reset the Initial UT to 0 and changed my constraints to have it find me a 250km apokee. I also labeled the last event more appropriately since no pitch change happens just the end of the burn so the engine should be shut off, SECO-1.

Okay if I optimize from this point, after about 30 iterations or so over 45-60min it gets me the result I want, which you can see in Ascension Mk3 #1 Ascent 250km.mat

Now go and set the Initial UT to the day I want to launch:  139494660.0 - you should see the trajectory completely change. I was confused by this but since all I changed was the time I figured the optimizer could get me a launch time during this day that would work again.

So I disabled all the event optimizations and set a hi-lo for Initial UT and let the optimizer run. You can see the results of this in Ascension Mk3 #1 Ascent 250km Time Constraint.mat

Right, here's where it gets weird. Looking at the final state you can see I'm back to nailing 250km. Now change the Initial UT to 139494659.766019. The trajectory will change to reflect a final state Ap of only 108.5111km. Now change the Initial UT to 139494659.466019 and you should see the trajectory jump again back almost to normal at 249.9998km. Now change the Initial UT again to 139494658.466019. New trajectory will be back on the money at 250km. Okay one more UT change to 139494648.466019  - now it's telling me I'm going up to 810.1884km!! :confused:

BTW the timing is important for this mission cause I want to launch and put my Ap direct opposite the sun so I can go high on initial climb without hitting the inner radiation belt, which is further away on the night side. This also makes me ask if the Sun Vector view option can draw the arrow through the planet and maybe have a length adjustment? Right now I'm just taking a screenshot and using Paint.NET to continue the vector through to the night side

Edited by Drew Kerman
Link to post
Share on other sites

was there a behavior change with Non-Sequential Events coloring trajectory lines or am I not remembering correctly? I made this last year:

Uui1aY9.png

And when I went to do one for my current ascent, if I changed the line color for a non-sequential event I don't see a color change on the plot anymore. I thought the non-sequential event triggered a plot color/line type change when it occurred, and this change persisted until the next sequential or non-sequential event happened.

Of course I could be remembering wrong and the above colored plot could just be a rough approximation using only sequential event color changes rather than a combo of both

Link to post
Share on other sites

another example of weirdness that seems related to the UT issue would be to use the Ascension Mk3 #1 Ascent 250km Time Constraint.mat file and just uncheck the one optimized box for the steering in Event 3. That's it. Do nothing else just disable the optimization hi/lo and save, the trajectory will change. If you do this in the Ascension Mk3 #1 Ascent 250km.mat file where the UT starts at 0 it will not change the trajectory

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...