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

[1greywind]

Hello.

@Arrowstar I finally started to learn LVD Looks like KSP TOT now rivals feature list of GMAT

I studied "Eve: The Final Frontier" tutorial, made few launch scenarios for two stage rockets. But when I started to think, how to use data from LVD in KSP. So I wrote the kOS program, that ingests JSON file with event data from LVD to guide craft flight.

Unfortunately results that I observe in KSP do not match the predicted result in LVD. For example: https://www.dropbox.com/s/72kki2ztnlcpcvn/lvd_launch_problem.zip?dl=0 this ZIP contains:

launch - the kOS program
2.craft - craft that I use (single stage rocket)
1.json - single event launch scenario (throttle to 100%, pitch 45 dergee, fly for 30 seconds then kill throttle)
30_seconds_flight_at_45_degree_pitch.mat - same scenario for LVD

In KSP craft stats after 30 seconds of flight are:
Apo: 93 km, airspeed: 1472 m/s, altitude: 12.8 km

LVD predicts:
Apo: 161 km, airspeed: 1466 m/s, altitude 18.98 km

Looks like I either messed up something in my .mat file (drag probably?) or something is not right...

I use KSP 1.7.3 with kOS 1.1.5. and KSP TOT 1.6.3

To launch rocket in KSP you should:

1. Copy "launch" and "1.json" to "your_ksp_dir/Ships/Script"
2. load 2.craft
3. place it on KSC launch pad
4. Open kOS terminal
5. Type "switch to 0."
6. Type "run launch("1.json")."
7. Watch the rocket fly

@Arrowstar please help me to me to resolve this problem

 

[Drew Kerman]

37 minutes ago, 1greywind said:

drag probably

I've had a quick look and I'm 99% sure its this. You're using the default Cd the entire time and flying through the entire lower atmosphere which requires drag calculation updates every 1km to be more accurate. Also not sure if your surface area is accurate but you can determine that with this wiki article if you didn't already. (hey @Arrowstar I've just noticed there's no prominent link to the wiki on the first post).

Drag updates is a wiki article I haven't done yet because I'm still trying to determine a best practice for it. I think I have the basics down tho so I'll work on getting that written up today

 

[Drew Kerman]

On 8/4/2019 at 6:56 PM, Arrowstar said:

atmospheric pressure, atmospheric density, atmospheric temperature, and drag coefficient

so the first two seem pretty straightforward.

Is atmospheric temperature just the outside air temp that I can pull from a thermometer part?

I'm going to need some hand-holding in which values to use and how to get the drag coefficient. Tho maybe someone on the kOS reddit can help I will ask there now too

[1greywind]

1 hour ago, Drew Kerman said:

I've had a quick look and I'm 99% sure its this. You're using the default Cd the entire time and flying through the entire lower atmosphere which requires drag calculation updates every 1km to be more accurate. Also not sure if your surface area is accurate but you can determine that with this wiki article if you didn't already. (hey @Arrowstar I've just noticed there's no prominent link to the wiki on the first post).

Drag updates is a wiki article I haven't done yet because I'm still trying to determine a best practice for it. I think I have the basics down tho so I'll work on getting that written up today

 

Thank you for the link. I'll try to follow this guide. Unfortunately it doesn't look like solid solution  I think there should be simpler way to determine drag properties in game. Can we get drag force from KER and use it to calculate surface area (from the formula like F(drag) = SurfaceArea*DragCoeficent*SomeFunction(airSpeed))?

[Drew Kerman]

8 minutes ago, 1greywind said:

 I think there should be simpler way to determine drag properties in game

Let us know if you find anything. I haven't seen any other suggestions but yours, and I'm not sure if that works

[CraigCottingham]

2 hours ago, Drew Kerman said:

I'm going to need some hand-holding in which values to use and how to get the drag coefficient. Tho maybe someone on the kOS reddit can help I will ask there now too

kRPC will return the drag coefficient at the given moment in flight, but according to the documentation it requires Ferram to be installed. I'm going to take that as meaning that KSP doesn't have the wherewithal to do so on its own.

[Drew Kerman]

6 minutes ago, CraigCottingham said:

kRPC will return the drag coefficient at the given moment in flight, but according to the documentation it requires Ferram to be installed. I'm going to take that as meaning that KSP doesn't have the wherewithal to do so on its own.

looks like kOS has been able to do drag coefficient even before the new atmo variables were exposed:

 

[1greywind]

21 hours ago, Drew Kerman said:

looks like kOS has been able to do drag coefficient even before the new atmo variables were exposed:

I used log_atm.ks to profile my launch vehicle (2.craft) draft coefficient and with some changes (setting initial Cd=3, Cd=2 at 1 km altitude and Cd=1 at 5 km altitude) LVD now gives more reasonable match with KSP reality.

But  when I try to modify scenario to something more complex - for example single stage to orbit with the same craft, the LVD and KSP results show large mismatch. It is very sad, that you need to manually modify Cd in LVD scenario to make result compatible with KSP.
What about modelling Apollo or Soyuz reentry in RSS + FAR? When we also need to account for changing lift value?

[Curveball Anders]

I know the power of the porkchop plot but I often find myself fiddling with it just to get best arrival date vs dV.

Possibly because I don't plan too much into the future I'm always ending up trying to create a "Mars Express"-ish thingy.

As in not really bothering about when to launch and travel time, I just want to get a simple graph showing arrival date vs dV.

I assume that the data is there, behind the porkchop (or actually has to be) but it's not always very obvious due inconsistent axis

Would it be possible to get a plot like that for the lazy and inpatient player?

[csatlos]

Hi everyone,

I seem to be having some issues getting KSP TOT to run. I was away for a while and was running 1.5.7 so I decided to upgrade to 1.6.3. I installed the new MATLAB runtime 2017b but whenever I try to start KSP TOT, i see a spinning cursor for about 1-2 seconds and then it disappears and the application doesn't load. A look at Windows Task Manager reveals that the process does spawn but then dies shortly thereafter each time I try to launch.

A log file is created on launch but it's empty so no clues about any errors. I've tried reinstalling the runtime to no avail and have also tried v1.6.4 pre-release 3 with no luck.

I'm not even sure where to start trouble-shooting due to a lack of errors and logs. Anyone have any ideas? Thanks!

[Gilph]

On 8/19/2019 at 12:02 PM, csatlos said:

Hi everyone,

I seem to be having some issues getting KSP TOT to run. I was away for a while and was running 1.5.7 so I decided to upgrade to 1.6.3. I installed the new MATLAB runtime 2017b but whenever I try to start KSP TOT, i see a spinning cursor for about 1-2 seconds and then it disappears and the application doesn't load. A look at Windows Task Manager reveals that the process does spawn but then dies shortly thereafter each time I try to launch.

A log file is created on launch but it's empty so no clues about any errors. I've tried reinstalling the runtime to no avail and have also tried v1.6.4 pre-release 3 with no luck.

I'm not even sure where to start trouble-shooting due to a lack of errors and logs. Anyone have any ideas? Thanks!

I would look at your path environment variable for the path to the matlab runtime directory. I had many duplicate lines from other installations and cleaned up a lot, including removing the old matlab runtime entry.

[csatlos]

8 hours ago, Gilph said:

I would look at your path environment variable for the path to the matlab runtime directory. I had many duplicate lines from other installations and cleaned up a lot, including removing the old matlab runtime entry.

I checked my environment variables (both user and system) and there is only one entry for MATLAB which is the path to the current install.

Thanks anyways for the tip! Not sure what else I can try due to a lack log files.

[Gilph]

17 hours ago, csatlos said:

I checked my environment variables (both user and system) and there is only one entry for MATLAB which is the path to the current install.

Thanks anyways for the tip! Not sure what else I can try due to a lack log files.

Hi...have you checked the event logs? Windows treats the .exe for TOT differently from a security perspective because it doesn't have a publisher. If Windows were not running it because of security issues, there may be some messages in the Security event logs. 

[csatlos]

6 hours ago, Gilph said:

Hi...have you checked the event logs? Windows treats the .exe for TOT differently from a security perspective because it doesn't have a publisher. If Windows were not running it because of security issues, there may be some messages in the Security event logs. 

Thanks for the idea but unfortunately nothing in the event log. It did give me an idea to double-check Norton Security logs but no dice there either.

I also tried uninstalling MATLAB to see if I would get the error about the runtime being missing and sure enough I did. Then when I reinstalled MATLAB, I'm back to no errors and no log entries.

The only other option I can think of is to run it inside a Windows VM to see if perhaps it's something with my configuration.

[Drew Kerman]

@Arrowstar I have another SOI detection issue. Here is the MAT file. The game detected the SOI transition but MA did not. I did a distance check of the trajectory after loading it in from the game and sure enough (blue line is Mun's SOI boundary distance from the Celestial Body Catalog):

That's output with a default 1000 log entries per coast. It is a very brief encounter lasting 15 minutes. However despite my best attempts I could not get MA to find it. You'll see in the MAT file I have everything maxed out in the search attempt - Stricter SOI Search is enabled, SOI Search Tolerance is at 1.000000E-14 (02 doesn't work either on the other end - to be honest not sure which was the proper extreme value I should be using but 14 took longer to process so I'm guessing that's looking closest) and the Number of SOI Transition Search Attempts is at 100. Increasing the log events to 100,000 also didn't make a difference, nor did attempting to coast to TA over 2 revs (which was used to make the plot above) or using the Next SOI coast event. This could maybe be an issue with the duration of the encounter rather than the distance?

[Drew Kerman]

GOSHDARNIT NEVERMIND

Spoiler

I caught the Kerbin atmosphere bug in action!

1. Open the Initial State
2. Select orbit data from the Active Vessel
3. Save & close
4. Check Celestial Body Catalog and see Kerbin atmosphere curve is flat
5. Create a new file
6. Check Celestial Body Catalog and see Kerbin atmosphere curve is still flat
7. Load a MAT I know has good atmosphere
8. Check Celestial Body Catalog and see Kerbin atmosphere curve is proper
9. Create a new file
10. Check Celestial Body Catalog and see Kerbin atmosphere curve is still proper
11. Open the Initial State
12. Select orbit data from the Active Vessel
13. Save & close
14. Check Celestial Body Catalog and see Kerbin atmosphere curve is flat again

Nothing showed up in the log. I restarted KSPTOT and re-opened MA

1. Check Celestial Body Catalog and see Kerbin atmosphere curve is proper
2. Open the Initial State
3. Select orbit data from the Active Vessel
4. Save & close
5. Check Celestial Body Catalog and see Kerbin atmosphere curve is flat

Still got it. Okay - next I tried using the vessel selector menu of data imported from KSP - I had two asteroids to select from. I tested both individually and both times I imported them the atmosphere of Kerbin went *poof* - actually so does the Sun's atmosphere

Alright I've determined this has actually been an issue with MA for a while now, I just only discovered it when using LVD because that's the only thing I need an atmosphere for at the moment. So what's likely happened is that I would import data in MA, then start up LVD afterwards and that would load in the current celestial catalog based on MA, which would have no atmosphere Kerbin. That's why sometimes I would see it in LVD and sometimes not.

Now, I have some captured asteroids around Kerbin and every time they have an encounter with Mun I save their new orbital data. So I have a bunch of MAT files going back months and I've looked through them to find the most recent one that still had atmospheric data. The creation data for that file is 1/17/19. The next file that doesn't have atmospheres was created on 3/28/19. So that means anything from KSPTOT v1.6.2 pre-release 5 (1/21) to 3rd pre-release of KSPTOT v1.6.3 (3/24) could be where the bug began.

That should be enough info to find it without me having to figure out which build caused the problem. Again - root cause is data import from KSP. Heck, that alone might be enough.

Above is all the effort I originally put into to figuring out the disappearing atmosphere bug when I managed to accidentally recreate it trying to model an aerobrake scenario. Well, when I manually input the data to the Initial State because I thought importing it was the problem, I still saw the atmo vanish! So yea, here are the new repro steps for the bug:

1. Open MA
2. Check Celestial Body Catalog and see Kerbin atmosphere curve is proper
3. Open Initial State
4. Save & close
5. Check Celestial Body Catalog and see Kerbin atmosphere curve is flat

Not kidding, it's that simple and yea it's been an issue since beginning of the year

Edited September 1, 2019 by Drew Kerman
aaauuuugghhhhhhhhhhh

[Drew Kerman]

okay so I rolled back to an earlier release I knew worked so I could import the vessel data and still have an atmosphere. So I'm trying to work out the aerobrake and I'm seeing some weird results. Here is the MAT file.

First, if you open the file and just add a default aerobrake pass as the next event, the trajectory doesn't propagate properly.

To get around that I did

1. Add coast to Pe
2. Change Pe coast to UT coast and roll back an hour
3. Add Aerobrake event, use FAR, default a*Cd
4. Add coast to Ap, note object has been captured

Now re-open the file

1. Add coast to Pe
2. Change Pe coast to UT coast and roll back an hour
3. Add coast to Function Value of 150km with 10000s search
4. Advance script to last event
5. Add Aerobrake event, use FAR, default a*Cd
6. Add coast to Ap, note object has not been captured

Oh snap, I literally just figured it out as I was typing this. It's because I did the Advance Script, which modifies the Initial State. I checked the Celestial Body Catalog and yea, Kerbin's atmosphere is gone again So this is related to my previous issue and it's not just from modifying the Initial State through the dialog box but also by advancing the script itself!

Okay I think I'm done playing around for tonight haha

 

[Drew Kerman]

new day, new mysteries

This was a nice Cd match up to my actual flight profile - except for the green circled part. I can't figure out where that bump in the LVD plot is coming from. It starts with my initial drag value and then at ~200m in altitude jumps to the circled higher value and lasts until 1km, where my first non-sequential drag update event occurs. None of the first four sequential events, which are the only ones to happen before 5km, have a drag update event. If you plot out the Cd in the GA you'll see the bump so it's not an error in my Excel plotting. I went back to an earlier ascent file that is built similarly to this one and found no such Cd bump. I've included both files in this zip. Ascent #8 is the one that has the Cd bump, Ascent #6 does not. I guess something got corrupted somewhere somehow?

Actually, I think I built Ascent #8 completely from the ground up in the latest LVD, but I can't remember for sure. I'm going to rebuild my next ascent this week and see if the behavior persists

Edited September 2, 2019 by Drew Kerman
Actually, I think...

[Drew Kerman]

so I'm analyzing my latest mission and looks like things have gotten much better for modeling the flight in the lower atmosphere. I have a concern about the upper atmosphere though based on this plot:

So before when I posted about the atmosphere density it was just VOID and LVD comparisons. Now I have a third source of data from kOS code that matches up more closely to the VOID data and shows the LVD curve to definitely be off. I'm also wondering about why it gets so chunky even as early as ~7km (you can see it sticking out just above 600g/m^3) whereas the VOID and kOS curves remain smooth. I tried outputting LVD GA data with a 0.1 integrator step and still saw the curve take sharp corners even when I made the rocket fly slower up through the atmosphere.

I'm wondering if the discrepancy is at all significant or just LVD cutting some reasonable corners for better speed in calculations

 

[Arrowstar]

Sorry I've been out of touch recently, all, I've needed a bit of a creative break.  I have been keeping up with the discussion here though.

21 hours ago, Drew Kerman said:

GOSHDARNIT NEVERMIND

  Reveal hidden contents

I caught the Kerbin atmosphere bug in action!

1. Open the Initial State
2. Select orbit data from the Active Vessel
3. Save & close
4. Check Celestial Body Catalog and see Kerbin atmosphere curve is flat
5. Create a new file
6. Check Celestial Body Catalog and see Kerbin atmosphere curve is still flat
7. Load a MAT I know has good atmosphere
8. Check Celestial Body Catalog and see Kerbin atmosphere curve is proper
9. Create a new file
10. Check Celestial Body Catalog and see Kerbin atmosphere curve is still proper
11. Open the Initial State
12. Select orbit data from the Active Vessel
13. Save & close
14. Check Celestial Body Catalog and see Kerbin atmosphere curve is flat again

Nothing showed up in the log. I restarted KSPTOT and re-opened MA

1. Check Celestial Body Catalog and see Kerbin atmosphere curve is proper
2. Open the Initial State
3. Select orbit data from the Active Vessel
4. Save & close
5. Check Celestial Body Catalog and see Kerbin atmosphere curve is flat

Still got it. Okay - next I tried using the vessel selector menu of data imported from KSP - I had two asteroids to select from. I tested both individually and both times I imported them the atmosphere of Kerbin went *poof* - actually so does the Sun's atmosphere

Alright I've determined this has actually been an issue with MA for a while now, I just only discovered it when using LVD because that's the only thing I need an atmosphere for at the moment. So what's likely happened is that I would import data in MA, then start up LVD afterwards and that would load in the current celestial catalog based on MA, which would have no atmosphere Kerbin. That's why sometimes I would see it in LVD and sometimes not.

Now, I have some captured asteroids around Kerbin and every time they have an encounter with Mun I save their new orbital data. So I have a bunch of MAT files going back months and I've looked through them to find the most recent one that still had atmospheric data. The creation data for that file is 1/17/19. The next file that doesn't have atmospheres was created on 3/28/19. So that means anything from KSPTOT v1.6.2 pre-release 5 (1/21) to 3rd pre-release of KSPTOT v1.6.3 (3/24) could be where the bug began.

That should be enough info to find it without me having to figure out which build caused the problem. Again - root cause is data import from KSP. Heck, that alone might be enough.

Above is all the effort I originally put into to figuring out the disappearing atmosphere bug when I managed to accidentally recreate it trying to model an aerobrake scenario. Well, when I manually input the data to the Initial State because I thought importing it was the problem, I still saw the atmo vanish! So yea, here are the new repro steps for the bug:

1. Open MA
2. Check Celestial Body Catalog and see Kerbin atmosphere curve is proper
3. Open Initial State
4. Save & close
5. Check Celestial Body Catalog and see Kerbin atmosphere curve is flat

Not kidding, it's that simple and yea it's been an issue since beginning of the year

Thanks for investigating all this!  I tracked it down very easily tonight with your help.  I think this build should resolve the issue, if you could give it a go?

KSPTOT v1.6.4 Pre-release 5

[Drew Kerman]

1 hour ago, Arrowstar said:

Sorry I've been out of touch recently, all, I've needed a bit of a creative break.  I have been keeping up with the discussion here though.

Cool, cool - pretty much what I figured. I'll keep up my thoughts, just answer whatever whenever

Just gave PR5 a go, and yea looking good so far! I used it on my aerobrake file and the atmosphere was still there after I opened & closed the Initial State and also after I advanced the script.

I have a behavior in LVD I'm not sure is working as intended or not. My engine flames out at 66km via an event that runs until the tank is empty. I then have a following sequential event to coast to space, so target altitude 70km with increasing value selected. I then have a sequential event to coast through space to the atmosphere, so again target altitude 70km but this time set to decreasing value. I understand the current altitude is 70km but the value should be increasing so that event should propagate through apokee and back down to 70km, but it doesn't and stays at 70km heading up

Also, when you put an Aerobrake event in, isn't it supposed to propagate through the entire atmosphere? Because I have the vessel at 150km and put an Aerobrake as the next event and it only takes the trajectory down to perikee

Also I rebuilt my next ascent and I'm not seeing the Cd bump anymore. So yea, no better idea where that came from

Edited September 2, 2019 by Drew Kerman

[Drew Kerman]

@ArrowstarI looked back a few pages but couldn't find where you said you changed the way you were modeling things to produce the double-hump in the dynamic pressure plot. It still appears for me in this design file.

[Arrowstar]

On 9/14/2019 at 2:45 AM, Drew Kerman said:

@ArrowstarI looked back a few pages but couldn't find where you said you changed the way you were modeling things to produce the double-hump in the dynamic pressure plot. It still appears for me in this design file.

This had to do with the interpolation scheme used to get pressure and temperature values.  The old scheme has the double humps and the new scheme does not.  However, the interpolation scheme is stored within the MAT file, so for old files, you'll still see the issue even if I fixed it going forward. 

I can try to fix up your MAT file if you'd like me to.  It'll be a matter of replacing the old scheme with the new.

[Drew Kerman]

8 hours ago, Arrowstar said:

I can try to fix up your MAT file if you'd like me to.  It'll be a matter of replacing the old scheme with the new.

yes please, it will help when I do the flight analysis without having to redo the whole case file. No rush tho, that analysis won't be done until early Oct

[Arrowstar]

On 9/18/2019 at 6:22 AM, Drew Kerman said:

yes please, it will help when I do the flight analysis without having to redo the whole case file. No rush tho, that analysis won't be done until early Oct

Here you go.   I only fixed the interpolation for Kerbin but I figure that should get you off the ground (literally).