[WIN/MAC/LINUX] KSP Trajectory Optimization Tool v1.6.10 [Major LVD Improvements!]

[Tacombel]

1 minute ago, Arrowstar said:

Okay.  And can you describe for me what you wanted to do, what actually happened, and how I can reproduce the issue?

For the first part, just load the mat. You will see that the final state corresponds to event 4, not event 7.

For the block, i don't now what happened but now it is just working.

I was trying to design a return trip to low kerbol. First step without problem, I find the burn that takes my probe from LKO to 180000km Kerbol Pe. The problem is when I try to go back to Kerbin. It just started and never went ahead of iteration 0, but now it works.  By the way, after stading it the whole evening now I realize that what I want to do probably cant be done, at least in a single orbit.

[Arrowstar]

3 minutes ago, Tacombel said:

For the first part, just load the mat. You will see that the final state corresponds to event 4, not event 7.

The final state does correspond to event 7.  The issue is that your two coast segments both say to go to a true anomaly of 0, but event 4 is already at 0 and the Event 6 DV is all zeros, so there's nothing to be done.  That's why they don't propagate out in time further.

[Tacombel]

8 minutes ago, Arrowstar said:

The final state does correspond to event 7.  The issue is that your two coast segments both say to go to a true anomaly of 0, but event 4 is already at 0 and the Event 6 DV is all zeros, so there's nothing to be done.  That's why they don't propagate out in time further.

mmmm, now it is clearer.

Edit: If I set the True Anomaly in the second coast to 1 to avoid problems and add one orbit I get an encounter. Great!!!!

Edited February 23, 2021 by Tacombel

[Arrowstar]

This afternoon I've build KSPTOT v1.6.8 pre-release 3.  This PR has a bunch of new features that I'm looking forward to sharing.  Here's the change log:

• LVD: T2W throttle model now checks minimum throttle T2W as well as maximum.
• LVD: Sim Driver now warns if integrator output event index (ie) is empty.
• LVD: When editing non-seq events, the event UI now greys out any non-relevant widgets.
• LVD: New geometry type: Angles.
  • Angles measure the angle between other geometric objects.  Right now there are angles between vectors and angles between a vector and planes.
  • Angles can be viewed in the LVD view area.
• LVD: New geometry type: Planes.
  • Planes are infinite, flat, 2D surfaces that run through a point and are perpendicular to a vector.
  • There are two plane types: Planes formed from a vector and point, and Planes formed from three points.
  • Planes can be viewed in the LVD view area.
• LVD: New "plane to point" geometric vector type.
• LVD: Added new Sum of Sines steering model.

The Sum of Sines steering is particularly interesting.  The model is a set of sine waves, each with their own amplitude, frequency, and phase shift.  The number of sine waves is user-defined and each sine can have any of its parameters optimized.  There is also a constant offset parameter that can be optimized.

Here's an example of what I'm talking about:

Why is this cool and helpful?  Well, first of all, there's an idea out there that any arbitrary function can be defined as a sum of sines.  (I believe this is known as a Fourier series.)  Using this functionality, it should be possible to create complex steering models that can be far more flexible than polynominal steering.  How complex?  Well, here's a one event low thrust burn from low Kerbin orbit to KEO using the above sum of sines steering model.  (Thrust is only 0.25 kN!)

This would not have been possible with any of the previously existing steering models.

I will note that optimizing the various sine values is best done with the NOMAD or patternsearch optimization algorithms.  Once you get close with that optimizer, though, then FMINCON is perfectly happy optimizing something like the above.

Please let me know if you find any bugs or have any issues in this new PR.  Thanks, and happy orbiting.

[Arrowstar]

On 2/19/2021 at 8:23 PM, Drew Kerman said:

@Arrowstar just realized I heard back from you on all my recent postings except this one with the odd dynamic pressure plot:

 

Okay, there's a bug in the dynamic pressure calculation in GA.  I think I've got it isolated and I'll fix it tonight or tomorrow.

EDIT: Nevermind, what I thought was wrong is not wrong.  The search continues.

EDIT2: Okay, here's what I think is going on, and why I think this isn't a problem.  At 61.366 seconds, the vehicle in your MAT file hits a point where the slope of the atmospheric density curve (which, remember, is a piecewise linear curve as far as KSP models it goes) changes drastically.  This point in time is also when the dynamic pressure curve starts ascending again.  I'm going to chalk the "double hump" nature of the dynamic pressure curve to this, then.  And since KSP models the atmospheric temperature and pressure using piecewise linear curves, I think it's "accurate" as far as KSP goes, even if it's not in real life.

What do you think, @Drew Kerman?

Edited February 24, 2021 by Arrowstar

[Drew Kerman]

On 2/23/2021 at 7:48 PM, Arrowstar said:

What do you think, @Drew Kerman?

I think I'm going to be throwing more data at you in the future but for now I agree, seems like a good correlation to explain what's happening.

Also delay in response due to not checking the thread directly. FYI I have found that when you edit a post, even sticking in a new user tag doesn't generate an alert for that user

[Tacombel]

The way I am using KTOT, I will assume the ship in parking orbit and from there will plan the mission in MA , note the burns and then design the ship in the VAB.

Then, after each burn, I reload the initial state and calculate again the next burn or two.

After the initial problems, I find MA to be intuitive and easy to use. Does it make sense to use LVD for this? The provided tutorial is so exhaustive that I find difficult to emulate what I do in MA with LCD, and I don't even know if it makes sense or not trying.

[Tacombel]

And it seems that I have the ability to break everything. This missions breaks the optimizer even before it starts. The first burn takes the probe to kerbol Pe at 180000km, the next three burns shoud take it back to kerbol one year in the future.

.mat

[Arrowstar]

33 minutes ago, Tacombel said:

And it seems that I have the ability to break everything. This missions breaks the optimizer even before it starts. The first burn takes the probe to kerbol Pe at 180000km, the next three burns shoud take it back to kerbol one year in the future.

.mat

When I went to go optimize, I saw this first thing in the log:

Quote

Your initial point x0 is not between bounds lb and ub; FMINCON
shifted x0 to strictly satisfy the bounds.

This is definitely going to be the problem.  One of your variables is probably right on a bound.  Figure out which one it is and push it to be just inside the bounds.

Also, I noticed that you had your optimization objective function as minimize distance to body and a constraint for periapsis.  This is a bit redundant.  I would consider switching your objective function to Maximize Mass.

1 hour ago, Tacombel said:

After the initial problems, I find MA to be intuitive and easy to use. Does it make sense to use LVD for this? The provided tutorial is so exhaustive that I find difficult to emulate what I do in MA with LCD, and I don't even know if it makes sense or not trying.

In general, I think LVD is the superior tool for just about everything at this point.  Yes, it's more complicated, but it's worth the learning curve in my opinion.  Take a look at the examples I provide and see if you can't figure out how they work, and then go try to do you own stuff.

[Tacombel]

4 hours ago, Arrowstar said:

 

Also, I noticed that you had your optimization objective function as minimize distance to body and a constraint for periapsis.  This is a bit redundant.  I would consider switching your objective function to Maximize Mass.

In general, I think LVD is the superior tool for just about everything at this point.  Yes, it's more complicated, but it's worth the learning curve in my opinion.  Take a look at the examples I provide and see if you can't figure out how they work, and then go try to do you own stuff.

Yea, it is working now. The problem is that there is a second problem, probably related with Matlab. When the program crash, probably because of the problem with the boundaries, I have to kill the process because KSPTOT becomes unresponsive. After that, it doesn't work until y reset my computer. Something simple as modifying  a value in a DV maneuver gets stuck in this

Edit: I deleted events 5-9 to start again. I had no problem with event 5, but it hangs up as soon as I add the coast to Ap event 6.

Edited February 25, 2021 by Tacombel

[Tacombel]

I decided to give LVD a try, but it is intimidating :-)

I think I understand how to create coast to burn + burn and then,  How do I define a coast to periapsis?

Thx

Edited February 26, 2021 by Tacombel

[Arrowstar]

33 minutes ago, Tacombel said:

I think I understand how to create coast to burn + burn and then,  How do I define a coast to periapsis?

You can change the event termination condition to true anomaly and set it to 0.0 deg.

[Tacombel]

Slow progress, but progress all the same.

But it is not doing what I expect. True anomaly at Final State 114º instead of 0º

Edit: What I am getting as final is the end of event 2, why does it not propagate to event 3? This is before optimizing.

.mat

Edit 2: After modifying the event 1 duration to a more reasonable 1000(0,2000) and optimizing I get something closer to what I expect, but not exactly, 358.6976º instead of 0º

And I am having the same problem that with MA. If in event 3 I set True Anomaly to 180 it gets stuck working and never finishes processing the script.

Edited February 26, 2021 by Tacombel

[Arrowstar]

5 hours ago, Tacombel said:

Slow progress, but progress all the same.

But it is not doing what I expect. True anomaly at Final State 114º instead of 0º

Edit: What I am getting as final is the end of event 2, why does it not propagate to event 3? This is before optimizing.

.mat

Edit 2: After modifying the event 1 duration to a more reasonable 1000(0,2000) and optimizing I get something closer to what I expect, but not exactly, 358.6976º instead of 0º

And I am having the same problem that with MA. If in event 3 I set True Anomaly to 180 it gets stuck working and never finishes processing the script.

Going to a true anomaly of zero is actually pretty tricky because of the 360 -> 0 discontinuity there.  I would ask yourself if you really, truly need to propagate to periapsis.  What are you trying to accomplish by doing that?  Is it something that you can just let fall out of the optimization naturally?  Same thing the "leave Kerbin SOI" event: do you really need to propagate to that or can you just coast for some period of time and let the SOI transition happen naturally?

[Tacombel]

10 minutes ago, Arrowstar said:

Going to a true anomaly of zero is actually pretty tricky because of the 360 -> 0 discontinuity there.  I would ask yourself if you really, truly need to propagate to periapsis.  What are you trying to accomplish by doing that?  Is it something that you can just let fall out of the optimization naturally?  Same thing the "leave Kerbin SOI" event: do you really need to propagate to that or can you just coast for some period of time and let the SOI transition happen naturally?

For the first, I want a burn there to raise the apoapsis. I could let it to find it, but I was trying to avoid the script looking for the place I already know is optimum.

The second was added for the reason I also ask you about the final state. If I don't add it, the final state showed corresponds to the burn in event 1, not Kerbol Pe. Later I realized that the only thing I had archived was to move the final state to the end of event 2 so, yes, it is redundant. But I don't know why it doesn't propagate to the coast to Kerbol Pe event end.

Edited February 26, 2021 by Tacombel

[Tacombel]

Whatever was happening that caused a crash when setting True anomaly to 180 seems to be solved deleting and reinstalling KSPTOT.

[Arrowstar]

3 hours ago, Tacombel said:

For the first, I want a burn there to raise the apoapsis. I could let it to find it, but I was trying to avoid the script looking for the place I already know is optimum.

The second was added for the reason I also ask you about the final state. If I don't add it, the final state showed corresponds to the burn in event 1, not Kerbol Pe. Later I realized that the only thing I had archived was to move the final state to the end of event 2 so, yes, it is redundant. But I don't know why it doesn't propagate to the coast to Kerbol Pe event end.

There's definitely nothing wrong with letting the code figure out the best place, so long as you get close.  You can also always just set a true anomaly constraint at the end of your event and let that handle it if there's a definite place you want your maneuver.  But the optimizers are pretty good, so as long as you get close, they should figure out the best spot on their own without much effort.

I'd need to see the MAT file for the second thing you mentioned.

[Tacombel]

3 hours ago, Arrowstar said:

I'd need to see the MAT file for the second thing you mentioned.

Perhaps the problem was with the Max. Simulation Time, too small.

Besides, I was doing it like in MA, placing the constrains in the coast event, but know I think that it works Ok placing them in the same event that the dV action, does this make sense?

Also something weird. Event 2 has a true anomaly termination set to 358.5º and I get what I expect

.mat

But, if a change it to 359 it jumps on orbit

[Arrowstar]

4 hours ago, Tacombel said:

Perhaps the problem was with the Max. Simulation Time, too small.

Besides, I was doing it like in MA, placing the constrains in the coast event, but know I think that it works Ok placing them in the same event that the dV action, does this make sense?

Also something weird. Event 2 has a true anomaly termination set to 358.5º and I get what I expect

.mat

But, if a change it to 359 it jumps on orbit

You're running into a case where the true anomaly target you want is too close to the discontinuity at 0 degrees and the integrator is getting confused.  There's not much I can do about this except suggest using a smaller maximum integrator step size or smaller integration tolerances.  That said:

I cannot recommend enough avoiding the true anomaly termination condition in particular and most of the non-duration event termination conditions in general.  Things can get numerically very unstable with these just as a matter of physics.  Time is the only genuinely stable parameter to target orbit propagation with except in a small number of very limited cases.  Trust me (and my professional experience) on this one: you will save yourself headaches down the road by only using the Event Duration termination condition in LVD.

[russm]

50 minutes ago, Arrowstar said:

Trust me (and my professional experience) on this one: you will save yourself headaches down the road by only using the Event Duration termination condition in LVD.

So with LVD, rather than setting events as "go until $target_state and minimise $thing", it's better to pull the error in state into the objective function and do something like "go until $time and minimise $thing + |$state - $target_state|" and let it figure out what $time works best for that?

[Arrowstar]

2 minutes ago, russm said:

So with LVD, rather than setting events as "go until $target_state and minimise $thing", it's better to pull the error in state into the objective function and do something like "go until $time and minimise $thing + |$state - $target_state|" and let it figure out what $time works best for that?

Not quite.  Use constraints instead and set the bounds to be whatever you want them to be for that quantity.

[Tacombel]

6 hours ago, Arrowstar said:

I cannot recommend enough avoiding the true anomaly termination condition in particular and most of the non-duration event termination conditions in general.  Things can get numerically very unstable with these just as a matter of physics.  Time is the only genuinely stable parameter to target orbit propagation with except in a small number of very limited cases.  Trust me (and my professional experience) on this one: you will save yourself headaches down the road by only using the Event Duration termination condition in LVD.

Understood. So the way to go would be to make an estimation of the time it will take to reach Pe and let the optimizer work?

By the way, another one and sorry for being so annoying : there is no DeltaV budget in LVD?

 

Edited February 27, 2021 by Tacombel

[Arrowstar]

10 hours ago, Tacombel said:

Understood. So the way to go would be to make an estimation of the time it will take to reach Pe and let the optimizer work?

That's one way, yes.  But I'm going to do you a solid since you really seem to want to have your event terminate at periapsis.  I've added a Flight Path Angle event termination condition to LVD.  You can use this to terminate the event at periapsis MUCH more cleanly than true anomaly.  At periapsis, flight path angle is 0 degrees and is increasing.  Use these two things in your event and you'll be all set.

I'll try to build this today or tomorrow and push out v1.6.8 PR4 with this in it this weekend.

Quote

By the way, another one and sorry for being so annoying : there is no DeltaV budget in LVD?

It doesn't.  It's a bit more complicated to this in LVD because of all the different engines that can be running at the same time, each with their own Isp and flow rates (not to mention throttle and all the different tanks).  I would work with mass directly if you have a vehicle roughly designed or use one of the other Maneuver Planner tools in KSPTOT (such as the Multi-Flyby Maneuver Sequencer or the like) to get delta-v, if it applies.

Alternatively, you can always spit out tank masses to a CSV file using Graphical Analysis and do your own delta-v calculations in Excel if you're savvy enough and the vehicle isn't too complicated.

[Tacombel]

2 hours ago, Arrowstar said:

That's one way, yes.  But I'm going to do you a solid since you really seem to want to have your event terminate at periapsis.  I've added a Flight Path Angle event termination condition to LVD.  You can use this to terminate the event at periapsis MUCH more cleanly than true anomaly.  At periapsis, flight path angle is 0 degrees and is increasing.  Use these two things in your event and you'll be all set.

Wonderful. I have advanced a lot today, but still miss the simplicity of MA with the coast to Pe event.

2 hours ago, Arrowstar said:

It doesn't.  It's a bit more complicated to this in LVD because of all the different engines that can be running at the same time, each with their own Isp and flow rates (not to mention throttle and all the different tanks).  I would work with mass directly if you have a vehicle roughly designed or use one of the other Maneuver Planner tools in KSPTOT (such as the Multi-Flyby Maneuver Sequencer or the like) to get delta-v, if it applies.

Alternatively, you can always spit out tank masses to a CSV file using Graphical Analysis and do your own delta-v calculations in Excel if you're savvy enough and the vehicle isn't too complicated.

I am just uploading the nodes to KSP and let the trip function of Precise Node do the math, but I don't understand, what has the ship to do with dV? I thought it was just adding vectors.

[Arrowstar]

1 hour ago, Tacombel said:

I am just uploading the nodes to KSP and let the trip function of Precise Node do the math, but I don't understand, what has the ship to do with dV? I thought it was just adding vectors.

It's not just vectors in LVD the way it normally is in MA.  In LVD, almost everything is done with finite burns.  This is why there are actions to turn engines on and off, throttle controls, etc.  It can get tricky to compute DV for events in LVD because you can't be sure if every engine running is actually on (what if the tank is out of fuel?), plus you can potentially have a variety of engines running with different flow rates and Isp.  It's not impossible but it's a lot harder than MA.