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

[Arrowstar]

8 minutes ago, Tacombel said:

Still fighting with it. Now i am trying to get my first encounter. i mus be doing something wrong because it is being difficult.

 

Are you using Mission Architect?  If so, you can save what you're working on as a MAT file and send it to me and I can try to help.

[Arrowstar]

On 4/2/2019 at 3:05 PM, Drew Kerman said:

LVD case file

Was going through and checking plots with the GA tool and Dynamic Pressure comes up as 0 across the entire mission time. I'm able to see dynamic pressure graphed okay on other case files so don't know what I did to this one

Your Kerbin atmosphere curves are empty again, which means that the default pressure / density of the atmosphere, 0.0, is being returned.  This is causing the dynamic pressure to be computed as 0.0.

[Drew Kerman]

2 hours ago, Arrowstar said:

Your Kerbin atmosphere curves are empty again, which means that the default pressure / density of the atmosphere, 0.0, is being returned.  This is causing the dynamic pressure to be computed as 0.0.

oh that's annoying - especially because I just opened up the bodies catalog and everything else has proper atmo curves figures...

[salajander]

Couple of quick questions that I think I saw answered somewhere in the last 135 pages, but I can't find it. I'm trying to use the Mission Planner to set up a Minmus rescue mission. I've added a ground station for the to-be-rescued kerbal, and I've got the optimizer set to end up in a low periapsis right over the correct lat/long, but I'd like to also:

1) Make sure we'll have comms with Kerbin when landed, as this is an unmanned rescue

2) Make sure we're arriving and landing during the daytime (e.g., sun at least higher than some angle above the horizon, ignoring local terrain)

Thanks!

 

[salajander]

Also, btw, I managed to get KSP TOT running inside a docker container on my Mac - thanks again for the linux port!

[Drew Kerman]

3 hours ago, salajander said:

1) Make sure we'll have comms with Kerbin when landed, as this is an unmanned rescue

Setup your ground stations and orbiting relays Other Spacecraft) and then use the Comm. Network Analysis under Tools

3 hours ago, salajander said:

2) Make sure we're arriving and landing during the daytime (e.g., sun at least higher than some angle above the horizon, ignoring local terrain)

that would be the Solar Beta Angle constraint, I believe. You can also use the Mission Animator for approximations - the shading there is accurate to the current sun position

@Arrowstar I have a new one for you. LVD case file. If I try to add a non-sequential event for a target TWR, an error gets tossed to the log. Happens with just a bare-bones non-sequential event with event termination only, no actions.

Also now that the TWR thrust model is in, shouldn't you change the TWR event termination to remove the sea level constraint? That worked fine initially since it was put it at my request to throttle up to a certain TWR prior to takeoff

Edited April 6, 2019 by Drew Kerman

[salajander]

Hi,

1 hour ago, Drew Kerman said:

Setup your ground stations and orbiting relays Other Spacecraft) and then use the Comm. Network Analysis under Tools

Hm, no way to set up constraints in the optimizer ahead of time? It'd be unfortunate if the optimizer found a solution for my lat/long/altitude specifications that ended up without line-of-sight to Kerbin. Also, I have the extra stations enable in KSP for the full DSN, not just the Tracking Station at KSC, so I'm really just interested in line-of-sight with Kerbin. Presumably I could add a few ground stations to fake it enough.

1 hour ago, Drew Kerman said:

that would be the Solar Beta Angle constraint, I believe.

I had thought so, but Solar Beta Angle is just the angle between the spacecraft's orbit and the sun. It doesn't tell you if your spacecraft is actually in sunlight or not. At least, as far as I understand it, which is not much.

1 hour ago, Drew Kerman said:

You can also use the Mission Animator for approximations - the shading there is accurate to the current sun position

Oh, thanks, I always forget about the Animator. That might help to at least check if what I got from the optimizer is ok or not.

 

Edit: Animator's showing it coming in on the dark side, naturally! Eyeballing things in the map view made me think as much. Ah well.

Edited April 6, 2019 by salajander

[Drew Kerman]

9 hours ago, salajander said:

Hm, no way to set up constraints in the optimizer ahead of time?

ah, no it can't be used with the optimizer, and there's no Line of Sight constraint either. So you'll have to do the comm analysis, see where things are and plan other constraints around that

9 hours ago, salajander said:

I had thought so, but Solar Beta Angle is just the angle between the spacecraft's orbit and the sun. It doesn't tell you if your spacecraft is actually in sunlight or not

Oh, well if that's the case then unfortunately there's no Eclipse constraint either

Sounds like quite the challenge. Good luck!

[Drew Kerman]

Addendum to my previous post @Arrowstar about the TWR error - I thought to get around the event termination issue by graphing out the TWR and seeing what MET it reached 2.5, which was ~54s. So I made a non-sequential event with a termination of 54s and defined its start point as the first sequential event so it would fire 54s into the mission. It does not fire, however.

Also, I had an optimization issue that gave the following result in the log after 0 iterations:

Quote

Optimization stopped because the relative changes in all elements of x are less than options.StepTolerance = 1.000000e-10, but the relative maximum constraint violation, 4.996417e-02, exceeds options.ConstraintTolerance = 1.000000e-10.

I manually tweaked the values I was optimizing to widen the initial objective function value and then it was able to work okay but that made me wonder if that's what the Perturb Optimization Variables menu option is for?

Edited April 6, 2019 by Drew Kerman

[salajander]

1 hour ago, Drew Kerman said:

Sounds like quite the challenge. Good luck!

Ending up doing a small correction burn to come in prograde instead of retrograde, and ignoring the longitude constraint. I'll orbit at the right inclination and wait for the stranded kerbal to rotate around in a day or so.

[Arrowstar]

11 hours ago, salajander said:

Hi,

Hm, no way to set up constraints in the optimizer ahead of time? It'd be unfortunate if the optimizer found a solution for my lat/long/altitude specifications that ended up without line-of-sight to Kerbin. Also, I have the extra stations enable in KSP for the full DSN, not just the Tracking Station at KSC, so I'm really just interested in line-of-sight with Kerbin. Presumably I could add a few ground stations to fake it enough.

I had thought so, but Solar Beta Angle is just the angle between the spacecraft's orbit and the sun. It doesn't tell you if your spacecraft is actually in sunlight or not. At least, as far as I understand it, which is not much.

Yeah, unfortunately comm links can't be used as an optimization constraint.  They're really CPU intensive to compute and binary on/off types of things don't really work well with optimizers that need smooth gradients to figure out which way to go.  This is the same reason why eclipses aren't a constraint you can use either.  They are either on or off (there or not there) and optimizers just don't work well with that.

Good thoughts about using Mission Animator, though!  That should be accurate as I do model the position of the Sun directly in that.

35 minutes ago, Drew Kerman said:

Addendum to my previous post @Arrowstar about the TWR error - I thought to get around the event termination issue by graphing out the TWR and seeing what MET it reached 2.5, which was ~54s. So I made a non-sequential event with a termination of 54s and defined its start point as the first sequential event so it would fire 54s into the mission. It does not fire, however.

Also, I had an optimization issue that gave the following result in the log after 0 iterations:

I manually tweaked the values I was optimizing to widen the initial objective function value and then it was able to work okay but that made me wonder if that's what the Perturb Optimization Variables menu option is for?

I'll take a look at the TWR error later today if I can.  Thanks for the report!

And yes, that is what the Perturb Optimization Variables feature does!  You give it a percentage and it computes that percent of the width between the upper and lower bounds of every variable and modifies them by up to that much (the actual amount changed is random for each variable each time).  It's a good way to give the optimizer a little nudge if it needs it to home in on a solution.

[Arrowstar]

15 hours ago, Drew Kerman said:

I have a new one for you. LVD case file. If I try to add a non-sequential event for a target TWR, an error gets tossed to the log. Happens with just a bare-bones non-sequential event with event termination only, no actions.

Also now that the TWR thrust model is in, shouldn't you change the TWR event termination to remove the sea level constraint? That worked fine initially since it was put it at my request to throttle up to a certain TWR prior to takeoff

Issue resolved for next release.

So I could remove the "Sea Level" part of it, but honestly it's both arbitrary and doesn't change all that much for most altitudes where you care.  Unless a use case arises where the local gravitational acceleration at the current altitude is important, I'm inclined to just leave it as is.  The only thing I could think of is if you were very high above Jool or the Sun and falling directly into it and wanted to exactly counteract the pull of gravity to "hover" there.  Then local T2W would be important.  That's all I can think of off the top of my head.

[Arrowstar]

Hi everyone!

I have a brief announcement regarding a new feature coming to KSPTOT in v1.6.3.  In the course of putting together the Eve tutorial for Launch Vehicle Designer, I realized that in order to determine how big my vehicle needed to be in order to complete the mission, I needed to do a bunch of rocket equation-based math that turned out to be not so simple.  This inspired me to write a solution that I am happy to introduce to you as the new "Vehicle Sizing Tool (VST)"!

The use of the tool is very straight forward.  Every mission can be broken up into logical phases that have some set maneuvers.  These maneuvers define the delta-v requirements for that phase.  For example, to ascend from Kerbin to low Kerbin orbit, a delta-v map might show 3400 m/s required.  This is one mission phase. The next might be a transfer to the Mun (1170 m/s) and the final might be that required to land on the Mun (580 m/s).

Every phase uses a number of discrete rocket stages to meet the user-defined required delta-v.  Each stage has its own engine specific impulse, mass fraction, and desired thrust to weight ratio.  (The latter is important if you want to understand how much thrust is needed to get off Kerbin, but also useful if you're in deep space and you just don't care about needing high thrust engines as well.) 

When you tap the "Run Sizing Analysis" button, the the code will attempt to minimize the total mass of the rocket while meeting the delta-v for each stage and the required stage mass fraction.  I came up with an intelligent methodology that provides decent initial guesses for the solver, so unless the vehicle or mission is completely infeasible, it should generally come up with a solution.

The outputs include mass data on the full vehicle as well as each stage.  The masses shown should be taken as targets for the designer as they develop their vehicle.  In addition, the delta-v, required thrust to meet desired thrust to weight, and stage burn time are also computed and provided. 

The first build of KSPTOT with the VST included will be the next v1.6.3 pre-release, which should get pushed out sometime this weekend.  Some future enhancements I have my eye on are the ability to compute stages with side-mounted boosters (think SLS or the Space Shuttle), as well as the standard KSP asparagus staging set up. 

What do you all think?

[Drew Kerman]

1 hour ago, Arrowstar said:

What do you all think? 

sounds kewl, look forward to being able to try it out... sometime... haha. Seems a bit much for what I'm doing now but eventually...

[salajander]

23 hours ago, Arrowstar said:

Yeah, unfortunately comm links can't be used as an optimization constraint.  They're really CPU intensive to compute and binary on/off types of things don't really work well with optimizers that need smooth gradients to figure out which way to go.  This is the same reason why eclipses aren't a constraint you can use either.  They are either on or off (there or not there) and optimizers just don't work well with that.

Good thoughts about using Mission Animator, though!  That should be accurate as I do model the position of the Sun directly in that.

I was thinking about this, and I have a possible feature request. Could you add elevation to celestial body to the optimizer? For my purposes above I'd probably want to make sure the elevation of the sun was greater than, say, something like 20 degrees.

Also, the default Comm Analysis only has the KSC ground station. I'm running with "Enable Extra Groundstations", as I don't want to have to set up a bunch of LKO relay sats. This changes the requirements from line-of-sight to KSC to just line-of-sight to Kerbin. Would it be possible to add either the actual extra groundstations or an option in the comm analysis for just LoS to Kerbin?

Thanks! 

[Arrowstar]

59 minutes ago, salajander said:

I was thinking about this, and I have a possible feature request. Could you add elevation to celestial body to the optimizer? For my purposes above I'd probably want to make sure the elevation of the sun was greater than, say, something like 20 degrees.

Also, the default Comm Analysis only has the KSC ground station. I'm running with "Enable Extra Groundstations", as I don't want to have to set up a bunch of LKO relay sats. This changes the requirements from line-of-sight to KSC to just line-of-sight to Kerbin. Would it be possible to add either the actual extra groundstations or an option in the comm analysis for just LoS to Kerbin?

Thanks! 

1) Sure, this could be done.  Elevation with respect to the local horizontal plane? 

2) I'll check this afternoon to be sure but this functionality should already be in there.  If you use the Spacecraft -> Ground Targets menu, you can add ground station locations.  I believe these will show up in the Comm Network Analysis tool.

[salajander]

5 minutes ago, Arrowstar said:

1) Sure, this could be done.  Elevation with respect to the local horizontal plane? 

Exactly. Then I could ensure I'm in daylight; I'd still run the graphical analysis for possible eclipses, but just knowing the sun is above the local horizontal (by some amount) is a very good start.

8 minutes ago, Arrowstar said:

2) I'll check this afternoon to be sure but this functionality should already be in there.  If you use the Spacecraft -> Ground Targets menu, you can add ground station locations.  I believe these will show up in the Comm Network Analysis tool.

Right. I could add them (or at least enough of them to get coverage) each time I started a new mission, but I was hoping to have them added by default. Unless I'm not seeing some way to save ground stations across missions?

[Arrowstar]

4 minutes ago, salajander said:

Exactly. Then I could ensure I'm in daylight; I'd still run the graphical analysis for possible eclipses, but just knowing the sun is above the local horizontal (by some amount) is a very good start.

Right. I could add them (or at least enough of them to get coverage) each time I started a new mission, but I was hoping to have them added by default. Unless I'm not seeing some way to save ground stations across missions?

Oh got it. No at the moment there's no way to store ground stations across missions. I prefer to have each mission case start as clean as possible.  I only include the KSC because it's always there in stock and it makes a good example for people to add others.

How many ground stations do you add when you start each new case?

[salajander]

10 minutes ago, Arrowstar said:

How many ground stations do you add when you start each new case?

I haven't been adding any, yet, but I expect if I added 2 or 3 more spaced roughly evenly around Kerbin I'd end up with the same coverage as the built-in DSN. Poking around on google and looking at some forums, I think there are maybe 6 other locations actually in the game:

Quote

 

Baikerbanour: 20° 40' 45'' N 146° 30' 4'' W

Crater Rim: 9° 27' 0'' N 172° 6' 37'' W

Nye Island: 5° 21' 49'' N 108° 32' 53'' E

Harvester Massif: 11° 57' 0'' S 33° 44' 25' E

North Station: 63° 5' 42'' N 90° 4' 47'' W

Mesa South: 59° 35' 23'' S 25° 51' 42'' W

 

... but that said, for the "Enable Extra Groundstations" crowd it may be simpler if the terminating ground station could just be Kerbin as a whole.

[Arrowstar]

7 hours ago, salajander said:

... but that said, for the "Enable Extra Groundstations" crowd it may be simpler if the terminating ground station could just be Kerbin as a whole.

There are some technical difficulties with this as the data structures that hold celestial body information really weren't designed to be used with the Comm analysis tool.  The easier "fix" might just be to allow ground stations to exist at the center of celestial bodies.  That would be easier.  I can investigate that, it should have the same effect.

----------------------------

In other news, I have built KSPTOT v1.6.3 pre-release 7 tonight.  Here is the change log:

1. NEW: Vehicle Sizing Tool (initial release)
2. LVD: A fix for errors when using thrust-to-weight related quantities as termination conditions for event.
3. MA/LVD: Added an "celestial body elevation" task for Graphical Analysis.

Please let me me know if you find any bugs or issues, particularly with the new Vehicle Sizing Tool.  Thanks!

Edited April 7, 2019 by Arrowstar

[salajander]

3 hours ago, Arrowstar said:

1. MA/LVD: Added an "celestial body elevation" task for Graphical Analysis.

When I try to add "Elevation Angle of Ref Central Body", nothing happens, and this is logged:

Spoiler

Error using ma_getConstraintStaticDetails (line 761)
Unrecongized Constraint Type: Elevation Angle of Ref. Celestial Body

Error in ma_MissionOptimizerGUI>addConstraintButton_Callback (line 703)

Error in ma_MissionOptimizerGUI>availConstListbox_Callback (line 588)

Error in gui_mainfcn (line 95)

Error in ma_MissionOptimizerGUI (line 42)

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

Error using uiwait (line 81)
Error while evaluating UIControl Callback.

 

[Arrowstar]

1 minute ago, salajander said:

When I try to add "Elevation Angle of Ref Central Body", nothing happens, and this is logged:

  Hide contents

Error using ma_getConstraintStaticDetails (line 761)
Unrecongized Constraint Type: Elevation Angle of Ref. Celestial Body

Error in ma_MissionOptimizerGUI>addConstraintButton_Callback (line 703)

Error in ma_MissionOptimizerGUI>availConstListbox_Callback (line 588)

Error in gui_mainfcn (line 95)

Error in ma_MissionOptimizerGUI (line 42)

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

Error using uiwait (line 81)
Error while evaluating UIControl Callback.

 

Drat I knew I was forgetting something lol.  I'll try to push out a fix tonight.

[Arrowstar]

Okay, fix deployed.  Please re-download the pre-release 7 ZIP file again.  If I missed something, please let me know.  I had to put this together sort of fast so hopefully nothing else is broken.  If it is I'll take a look tomorrow.

[Drew Kerman]

KSA's first rocket to be confirmed by LVD and MA to be orbit-capable, with a comfy margin of error. It will attempt to make such a flight on its first try, no in-game "simulations" done first, later this year.

Spoiler

 

[Arrowstar]

Hi everyone,

I have another pre-release ready to go tonight, KSPTOT v1.6.3 pre-release 8.  The change log for this one is fairly brief:

• MFMS: Added options to include or not departure and arrival hyperbolic excess velocities, as well as constrain those quantities with upper bounds.
• Vehicle Sizing Tool: Cleaned up the default values when you open it.
• Some code refactoring under the hood.

Please let me know if you find any bugs or issues I haven't yet addressed.  I'm thinking we're getting close to an official release here.

Happy orbiting!