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

[Arrowstar]

13 hours ago, Snoman314 said:

From what you're saying, it comes down to just coming up with a direction to point the vessel, burning for a set time, and hoping for the best. I'll just have to put up with any steering and velocity errors and do a later mid-course correction or something like that.

No, haha, this is not what I'm saying actually!  You have all the information you need in either MA or LVD to execute the maneuver precisely in KSP.  There doesn't have to be guesswork about it or "hoping for the best". What I am saying, though, is the "pick a direction to point" technique isn't going to work.  You need to dynamically steer the vehicle through the burn in order to hit your target.  This is why I recommended you rewrite some kOS code: because you're going to need to do it more precisely than you can get it by hand, and because a single maneuver node type of burn isn't going to cut it in general.

Before you jump back into KSP, pause for a moment and take a look at the data you have available for each burn and come up with a way to translate that into kOS code.  That's my best advice.

Maybe the next thing I need to do is write a feature in LVD that spits out kOS code for people to execute... 

Quote

OK, I still don't have the first clue how to use the X/Y/Z mode. Given that step one for, say, a trans-munar injection burn would be to create a manoeuvre node prograde with approx 840m/s, roughly 90 degrees behind the Mun's current position, and then let the optimiser figure out where to go from there - where do I start if using X/Y/Z? How do I input a burn that's in the ballpark, so that the optimiser has a place to start?

I think the confusion is in what the inertial ("X/Y/Z") mode is.  Do you know what inertial means?  If not, stop for a second and go look that up first.  The short answer is that it means not accelerating, which can generally mean "not rotating" for reference frames. 

In the inertial X/Y/Z frame, the origin of the frame is located at Kerbin's center (for example).  The Z direction points up through the north pole.  The X direction is in a fixed direction that does not vary.  The Y direction completes the right handed system.

In the orbit frame, the prograde direction always changes to point along your velocity vector.  The radial direction always points from the center of Kerbin (for example) to your spacecraft.  And normal always points along the angular momentum vector. 

The orbit frame vectors move in time as a function of your orbit and your position in that orbit.  The inertial vectors are fixed in every sense of the word.  They do not change with time.

This is why I can't give you an answer about the inertial X/Y/Z frame.  It depends on your orbit.  To get a good guess, though, what you can do is set up the maneuver in the orbit frame and then switch to inertial.  I'm pretty sure my code will do the conversion for you (in MA).  Just reoptimize from that point.

4 hours ago, vitorboschi said:

Out of curiosity, do you know how precise are real life orbital maneuvers today? In terms of dV/timing/thrust direction?

It depends on the vehicle.  Back in the day when I flew Cygus, we had accelerometers that would hit delta-v down to sub 1 cm/s.  The geostationary vehicles I flew were not as precise because they were just point (inertially) and go for a fixed duration.  But we still hit SMA targets within 1 km by the end of the mission.  It was close enough to clean up with RCS at a convenient time.

[Arrowstar]

A few updates:

First, I did implement a "advance to event" action in LVD.  It was fairly challenging to get right, though, because of the way steering and throttling works in LVD, so it's pretty experimental for now.

Second, I am going to write a kOS program to execute an LVD mission's steering and throttling.  It'll basically be a fixed template with the ability to read in from file a set of steering and throttling values over time.  It doesn't look that hard, and I'm looking forward to it.

Both of these are the final two features I want to incorporate into v1.6.7 before release.

[Arrowstar]

Alright, so here's a fun one for everyone.  I'm currently testing my kOS code above.  I have a vessel in KSP which kOS reports as having a mass of 0.3842 mT.  The engine on it has a vacuum thrust of 2 kN.  Therefore, if you use

accel = Force / mass

You get:

accel = 2.0 kN / 0.3842 mT = 5.2 m/s^2 (because the 1000 factors cancel).

Yet KSP reports the max acceleration as 4.7 m/s^2.  Can someone tell me what I'm missing?  What's wrong with my logic?

The reason I'm bringing this up is because I'm testing my kOS code and trying to get it to circularize an orbit from a KSPTOT LVD mission script using its attitude and throttle information.  My initial orbit lines up perfectly, my initial and final masses (before and after the first burn) are good, but the final velocity after the first burn is too low, which suggests the acceleration is too low.

Clearly something is wrong, but I'm not sure what... any ideas?

[AVaughan]

1.11 ?  Do you see the same thing in earlier versions?  Crewed part?

Sounds like it might be

 https://wiki.kerbalspaceprogram.com/wiki/1.11 mentions a minimum part mass, but my reading of that means it shouldn't affect dV/acceleration.  

Quote

• Parts now have a minimum Rigidbody mass minimumRBMass which affects how small the rigidbodies mass can be. Does not affect part.mass - which is whats used to calculate force, etc - but does affect rigidbody collisions.

Another possible cause might be whatever function is returning vessel mass is ignoring crew mass or maybe the mass of eva attachable things in crewpods/containers.

 

[Arrowstar]

1 hour ago, AVaughan said:

1.11 ?  Do you see the same thing in earlier versions?  Crewed part?

Sounds like it might be

 https://wiki.kerbalspaceprogram.com/wiki/1.11 mentions a minimum part mass, but my reading of that means it shouldn't affect dV/acceleration.  

Another possible cause might be whatever function is returning vessel mass is ignoring crew mass or maybe the mass of eva attachable things in crewpods/containers.

 

Holy moly, this was it!  Thanks for sharing this.  I set the   "partRBMassMin" parameter in the physics.cfg file to something small and all of a sudden everything works.  I was seriously going crazy here for a while...

[Arrowstar]

Hi everyone!

Well, I said I was going to write some kOS code to execute LVD mission files and I've done just that.  I want to share a very simple example of what's going on with this new function through a video.  Sorry about the lack of sound or any other oddities.  I've literally never recorded a video before, so if anyone has any tips, please let me know.

Before you watch, let me explain what's going on.  In this video, we see a satellite in a circular, equatorial Kerbin orbit with an SMA of 700 km.  The goal is to raise the SMA to 750 km using two burns.  The mission plan in KSP to do this has already been created and the necessary data from KSP has been output to CSV file.  The kOS script will read in the data (which is really just time, attitude, and throttle) and control the vehicle according to those numbers.  Burns are executed prograde with a 1 deg/s roll around the long axis.  In between burns, the vehicle sits in a sun pointing attitude and spins at 1 deg/s.  The kOS script terminates shortly after the second burn.

You'll notice we didn't exactly hit 750 km, but we got real close.  Normally in real life, you'd replan you maneuvers after each burn in order to account for issues like this.  But I think it's close enough for KSP, and any discrepancy is really down to the physics model in KSP and the speed of kOS.

Anyway, let me know what you think!  I'm super excited for this.

I'm building KSPTOT v1.6.7 PR12 right now that has this functionality in it.  It'll be up later today if anyone wants to play with it.  Instructions on what to do will be in the kOS .ks script file.

Edited January 2, 2021 by Arrowstar

[Arrowstar]

And here's KSPTOT v1.6.7 PR12.  Btw, I realize I forgot to update the version number in the software, but don't worry about it for now.  It says PR11, but it really is PR12.  It'll be correct in the future.  Here's the change log:

• LVD: Initial throttle and steering dialog boxes now grey out the continuity checkbox, since it's not used in those situations.
• Updated the wait time for RTS data to be the same as TCPIP timeout, and updated that timeout to be 10 seconds. This accomodates larger bodies.ini files.
• LVD: Added a time offset parameter to any PolynomialModel or LinearTangentModel steering or throttle models.
• LVD: Added an "advance to event" option in the script listbox right click menu.
• LVD: Added kOS script that can execute LVD steering and throttle, and implemented initial ability to dump data to file for kOS. 
• LVD:  Fixed bug with event set steering action not setting the steering model correctly.
• LVD: Fixed some bugs with steering rotation math.  Compatibility alert!  Your steering may be different going forward if you inadvertently relied on the bugged code.

To use the kOS script, you need to place the Ship folder in your root KSP directory and have kOS installed.  Doing so will create the Script directory and place the execLvdControl.ks script there.  Follow the instructions at the header of the kOS script file to learn how to use it.

Please let me know if you find any bugs.  I'm considering this the first 1.6.7 release candidate, so we're getting close!  Thanks!

Edited January 2, 2021 by Arrowstar

[Arrowstar]

I've got a new video showing an upgrade to the kOS script included with PR12.  (These updates will be in the final release but are not in the PR.)  There's more information regarding the current and next event, including event names and a countdown to the next event.  I also have a resource display in for now, but that might be removed as it's a bit redundant with the existing KSP UI.

Anyway, this is the same mission as before, except I added a 5 degree inclination target to the final orbit.  Please tell me what you think, feedback is welcome!

 

[Drew Kerman]

will try to take a closer look this week but cool stuff and I can def attempt to apply it to my next orbital mission launching in Feb

[vitorboschi]

@Arrowstar hey, thank you for the update! I have tried to reproduce the problem on the Multiflyby porkchop  plotter and it's still consuming a ton of memory here. Unfortunately I couldn't test it on a Windows machine yet.

Another one which I'm not sure is a bug or user problem: I tried to model a direct launch to impact mission to Mun, in order to test the new KOS script, but I couldn't model the mission. For some reason, event 2 is never completed (reach 0.6km altitude). I tried to enable "Show S/C Body Axes" on the view settings to help me understand what is wrong, but I've got this error on the log:

Error using makehgtform (line 80)
Arguments to translate must be finite

Error in LaunchVehicleViewProfileBodyAxesData/plotBodyAxesAtTime (line 108)


Error in timeSliderStateChanged (line 22)


Error in LaunchVehicleViewProfile>@(src,evt)timeSliderStateChanged(src,evt,lvdData,handles) (line 427)


Error in LaunchVehicleViewProfile/configureTimeSlider (line 430)


Error in Generic3DTrajectoryViewType/plotStateLog (line 335)


Error in LaunchVehicleViewProfile/plotTrajectory (line 99)


Error in LaunchVehicleViewSettings/plotTrajectoryWithActiveViewProfile (line 25)


Error in lvd_processData (line 14)


Error in ma_LvdMainGUI>editViewSettingsMenu_Callback (line 2002)


Error in gui_mainfcn (line 95)


Error in ma_LvdMainGUI (line 42)


Error in matlab.graphics.internal.figfile.FigFile/read>@(hObject,eventdata)ma_LvdMainGUI('editViewSettingsMenu_Callback',hObject,eventdata,guidata(hObject))

Error using waitforallfiguresclosed (line 9)
Error while evaluating Menu Callback.

Care to take a look? Here is the .mat: https://www.dropbox.com/s/5aaniunzgdel6s6/Mun impact mission.mat?dl=0

[Arrowstar]

3 hours ago, vitorboschi said:

@Arrowstar hey, thank you for the update! I have tried to reproduce the problem on the Multiflyby porkchop  plotter and it's still consuming a ton of memory here. Unfortunately I couldn't test it on a Windows machine yet.

Another one which I'm not sure is a bug or user problem: I tried to model a direct launch to impact mission to Mun, in order to test the new KOS script, but I couldn't model the mission. For some reason, event 2 is never completed (reach 0.6km altitude). I tried to enable "Show S/C Body Axes" on the view settings to help me understand what is wrong, but I've got this error on the log:

Error using makehgtform (line 80)
Arguments to translate must be finite

Error in LaunchVehicleViewProfileBodyAxesData/plotBodyAxesAtTime (line 108)


Error in timeSliderStateChanged (line 22)


Error in LaunchVehicleViewProfile>@(src,evt)timeSliderStateChanged(src,evt,lvdData,handles) (line 427)


Error in LaunchVehicleViewProfile/configureTimeSlider (line 430)


Error in Generic3DTrajectoryViewType/plotStateLog (line 335)


Error in LaunchVehicleViewProfile/plotTrajectory (line 99)


Error in LaunchVehicleViewSettings/plotTrajectoryWithActiveViewProfile (line 25)


Error in lvd_processData (line 14)


Error in ma_LvdMainGUI>editViewSettingsMenu_Callback (line 2002)


Error in gui_mainfcn (line 95)


Error in ma_LvdMainGUI (line 42)


Error in matlab.graphics.internal.figfile.FigFile/read>@(hObject,eventdata)ma_LvdMainGUI('editViewSettingsMenu_Callback',hObject,eventdata,guidata(hObject))

Error using waitforallfiguresclosed (line 9)
Error while evaluating Menu Callback.

Care to take a look? Here is the .mat: https://www.dropbox.com/s/5aaniunzgdel6s6/Mun impact mission.mat?dl=0

Your issue is that your initial state's reference frame is set to Body Centered Inertial.  You need to be using the Body Fixed frame, which rotates with the surface of the planet.  Your NaN and Inf errors are because your initial velocity is 0.0 m/s inertially, which just causes issues all over the place.

[vitorboschi]

1 hour ago, Arrowstar said:

Your issue is that your initial state's reference frame is set to Body Centered Inertial.  You need to be using the Body Fixed frame, which rotates with the surface of the planet.  Your NaN and Inf errors are because your initial velocity is 0.0 m/s inertially, which just causes issues all over the place.

Thank you! I feel a bit dumb now ><

Another bug: there seems to be another issue with events/variables being optimized when they shouldn't be. This time it happened with events that still exists, but with optimization toggled off (ctrl+F). As the previous one, it fixes itself when the .mat is reloaded from disk.

 

[Arrowstar]

12 minutes ago, vitorboschi said:

Thank you! I feel a bit dumb now ><

Another bug: there seems to be another issue with events/variables being optimized when they shouldn't be. This time it happened with events that still exists, but with optimization toggled off (ctrl+F). As the previous one, it fixes itself when the .mat is reloaded from disk.

 

Can you give me an example file where this shows up?

[vitorboschi]

23 minutes ago, Arrowstar said:

Can you give me an example file where this shows up?

I didn't bothered to keep it because the problem is gone when you load the file again,so I don't have it anymore, unfortunately.

I'll keep a sample next time it happen.

[Arrowstar]

43 minutes ago, vitorboschi said:

I didn't bothered to keep it because the problem is gone when you load the file again,so I don't have it anymore, unfortunately.

I'll keep a sample next time it happen.

No worries, I've added some additional checking/removing to hopefully ensure it doesn't happen in the future.  Thanks for the report!

[Arrowstar]

I've been showing some videos of in-space maneuvers using the new LVD/kOS system recently.  I have been wondering, though about how it would perform during launch.  I put together a test launch from the surface of the Mun and handed the steering and throttle to kOS to run.  Here's the results!  It did pretty well.  The target 150 km SMA is not quite reached, but I pin this on steering error and a bit of a hiccup at the start with the landing legs.  Also notice that the steering is set up to intentionally keep the solar panels in the sun during the ascent.  This is to keep the vehicle from running out of electric charge, which may or may not have happened in an earlier test...

Let me know what you think!

Edited January 4, 2021 by Arrowstar

[vitorboschi]

6 hours ago, Arrowstar said:

Let me know what you think!

Awesome! I'm planning an atmospheric launch and will report back when I have the results.

 

Now, time for bug reports:

1. Trying to add a Two-Body Impact Latitude constraint will add a Two-Body Impact Longitude instead.

2. After adding the above constraint, I get this error when the script is propagated:

Operands to the || and && operators must be convertible to logical scalar values.

Error in findSoITransitions (line 112)


Error in ma_executeCoast_goto_tru (line 67)


Error in lvd_TwoBodyImpactPointTasks (line 34)


Error in TwoBodyImpactPointLongitude/evalConstraint (line 31)


Error in ConstraintSet/evalConstraints (line 107)


Error in LaunchVehicleScript/executeScript (line 329)


Error in ma_LvdMainGUI>propagateScript (line 260)


Error in ma_LvdMainGUI>runScript (line 235)


Error in ma_LvdMainGUI>editConstraintsMenu_Callback (line 661)


Error in gui_mainfcn (line 95)


Error in ma_LvdMainGUI (line 42)


Error in matlab.graphics.internal.figfile.FigFile/read>@(hObject,eventdata)ma_LvdMainGUI('editConstraintsMenu_Callback',hObject,eventdata,guidata(hObject))

Error using waitforallfiguresclosed (line 9)
Error while evaluating Menu Callback.

 

2. My current mission seems to hit the Mun directly, but LVD still thinks the mission ends at Kerbin. Here's the .mat: https://www.dropbox.com/s/hw3keljbm67yqqr/Mun impact mission2.mat?dl=0

 

 

 

Edited January 4, 2021 by vitorboschi

[Arrowstar]

4 hours ago, vitorboschi said:

Awesome! I'm planning an atmospheric launch and will report back when I have the results.

 

Now, time for bug reports:

1. Trying to add a Two-Body Impact Latitude constraint will add a Two-Body Impact Longitude instead.

2. After adding the above constraint, I get this error when the script is propagated:

Operands to the || and && operators must be convertible to logical scalar values.

Error in findSoITransitions (line 112)


Error in ma_executeCoast_goto_tru (line 67)


Error in lvd_TwoBodyImpactPointTasks (line 34)


Error in TwoBodyImpactPointLongitude/evalConstraint (line 31)


Error in ConstraintSet/evalConstraints (line 107)


Error in LaunchVehicleScript/executeScript (line 329)


Error in ma_LvdMainGUI>propagateScript (line 260)


Error in ma_LvdMainGUI>runScript (line 235)


Error in ma_LvdMainGUI>editConstraintsMenu_Callback (line 661)


Error in gui_mainfcn (line 95)


Error in ma_LvdMainGUI (line 42)


Error in matlab.graphics.internal.figfile.FigFile/read>@(hObject,eventdata)ma_LvdMainGUI('editConstraintsMenu_Callback',hObject,eventdata,guidata(hObject))

Error using waitforallfiguresclosed (line 9)
Error while evaluating Menu Callback.

 

2. My current mission seems to hit the Mun directly, but LVD still thinks the mission ends at Kerbin. Here's the .mat: https://www.dropbox.com/s/hw3keljbm67yqqr/Mun impact mission2.mat?dl=0

 

 

 

Thanks for the report!  All issues resolved for next release.  I'll aim to put out a PR today.

Edited January 4, 2021 by Arrowstar

[Arrowstar]

Hi everyone,

This afternoon I've built KSPTOT v1.6.7 pre-release 13.  This is basically a bug fix release.  Here's the change log:

• LVD: kOS script now shows current and next event, as well as time to next event.
• LVD: Fixed bug where attitudes would not display in backwards prop segments.
• LVD: Added option to FMINCON otimizer to automatically find optimal step size.
• LVD Removing an event now removes the variables associated with that event's termination condition and actions.
• LVD: Resolved issue with typo in 2BImpactPointLat name.
• LVD: Resolved issue with empty globals in 2BodyImpactPt calls to findSoITransitions.
• LVD: Fixed issue with finding down SoI transitions not working if eccentricity >= 1.
• MA/LVD: Fixed bug with chunked state log generation skipping last state log entry if there's only one event in SoI.

Please let me know if you find any more bugs!  Hopefully the full v1.6.7 release can get out by this weekend, if not sooner.  Thanks!

[Drew Kerman]

1 hour ago, Arrowstar said:

LVD: Added option to FMINCON otimizer to automatically find optimal step size.

is this enabled by default?

[Arrowstar]

Just now, Drew Kerman said:

is this enabled by default?

It is not, because it requires some (possibly considerable) CPU usage up front.  You can enable it in the FMINCON options, though.

[Drew Kerman]

Just now, Arrowstar said:

It is not, because it requires some (possibly considerable) CPU usage up front.  You can enable it in the FMINCON options, though.

ok that's fine, just wanted to know if it was something I needed to keep in mind possibly using

[Arrowstar]

Just now, Drew Kerman said:

ok that's fine, just wanted to know if it was something I needed to keep in mind possibly using

It is worth using, I think.  I've gotten pretty good results with it on my example missions thus far.

[vitorboschi]

1 hour ago, Arrowstar said:

Hi everyone,

This afternoon I've built KSPTOT v1.6.7 pre-release 13.  This is basically a bug fix release.  Here's the change log:

• LVD: kOS script now shows current and next event, as well as time to next event.
• LVD: Fixed bug where attitudes would not display in backwards prop segments.
• LVD: Added option to FMINCON otimizer to automatically find optimal step size.
• LVD Removing an event now removes the variables associated with that event's termination condition and actions.
• LVD: Resolved issue with typo in 2BImpactPointLat name.
• LVD: Resolved issue with empty globals in 2BodyImpactPt calls to findSoITransitions.
• LVD: Fixed issue with finding down SoI transitions not working if eccentricity >= 1.
• MA/LVD: Fixed bug with chunked state log generation skipping last state log entry if there's only one event in SoI.

Please let me know if you find any more bugs!  Hopefully the full v1.6.7 release can get out by this weekend, if not sooner.  Thanks!

 

Found another one while optimizing this mission: https://www.dropbox.com/s/59fp4n0j85tohik/Mun impact mission3.mat?dl=0

Error using optimfcnchk/checkfun (line 242)
Supplied function '@(x)lvdOpt.constraints.evalConstraints(x,true,evtToStartScriptExecAt,true,[])' returned NaN when evaluated;
 FMINCON cannot continue.

Error in fmincon (line 623)


Error in lvd_executeOptimProblem (line 26)


Error in FminconOptimizer/optimize (line 78)


Error in LvdOptimization/optimize (line 53)


Error in ma_LvdMainGUI>optimizeMissionMenu_Callback (line 601)


Error in gui_mainfcn (line 95)


Error in ma_LvdMainGUI (line 42)


Error in matlab.graphics.internal.figfile.FigFile/read>@(hObject,eventdata)ma_LvdMainGUI('optimizeMissionMenu_Callback',hObject,eventdata,guidata(hObject))


Caused by:
    Failure in initial nonlinear constraint function evaluation. FMINCON cannot continue.

Error using waitforallfiguresclosed (line 9)
Error while evaluating Menu Callback.

I guess it's related to 2BImpactPoint{Lat,Long} constraints. Btw, am I using then correctly? I've put the lat/long where I want the impact to happen in there. Since there's no thrust/atmosphere on the event it happens, I've assumed the Two-body constraints are the correct ones

[Arrowstar]

21 minutes ago, vitorboschi said:

 

Found another one while optimizing this mission: https://www.dropbox.com/s/59fp4n0j85tohik/Mun impact mission3.mat?dl=0

Error using optimfcnchk/checkfun (line 242)
Supplied function '@(x)lvdOpt.constraints.evalConstraints(x,true,evtToStartScriptExecAt,true,[])' returned NaN when evaluated;
 FMINCON cannot continue.

Error in fmincon (line 623)


Error in lvd_executeOptimProblem (line 26)


Error in FminconOptimizer/optimize (line 78)


Error in LvdOptimization/optimize (line 53)


Error in ma_LvdMainGUI>optimizeMissionMenu_Callback (line 601)


Error in gui_mainfcn (line 95)


Error in ma_LvdMainGUI (line 42)


Error in matlab.graphics.internal.figfile.FigFile/read>@(hObject,eventdata)ma_LvdMainGUI('optimizeMissionMenu_Callback',hObject,eventdata,guidata(hObject))


Caused by:
    Failure in initial nonlinear constraint function evaluation. FMINCON cannot continue.

Error using waitforallfiguresclosed (line 9)
Error while evaluating Menu Callback.

I guess it's related to 2BImpactPoint{Lat,Long} constraints. Btw, am I using then correctly? I've put the lat/long where I want the impact to happen in there. Since there's no thrust/atmosphere on the event it happens, I've assumed the Two-body constraints are the correct ones

Yeah, I see the issue now.  You're not hitting the body so the constraint sort of freaks out since there is no impact.  I would recommend just propagating to the impact point directly in LVD and setting your latitude, longitude, and altitude constraints for that point as desired.