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

[DBowman]

4 hours ago, Arrowstar said:

1. You need to change the view frame to be centered around Mars.  LVD: View -> Edit View Settings -> Find "Trajectory View Frame" -> click Properties under it and select "Mars."

Ah! awesome! now I see that I am launching due North  man... (assuming planet blue arrow out the top is N) during the big coast to Ap roll and yaw angle both seem to flip between 0 and 360 randomly, I guess that doesn't really matter, but at the Ap burn they are both somehow set to 180, which I guess explains the "retrograde burn", I'm upside down and going backwards for some reason.

Setting roll to constant 90 in initial steering model and having "continuity" checked only seems to effect the first event duration. After that I see roll = 90 in the graph but the trajectory starts heading North. I'll take another look at the example you gave me. Not going polar should also help the prop consumption...

I set roll angle to 89.99 on all my steering models, it stopped the flipping, at the end of the coast to Ap the yaw sets itself to 180 even though the steering model box says  RPA 89.99, 188.7, 0.0

Edited December 13, 2020 by DBowman
clarify

[Drew Kerman]

12 hours ago, Arrowstar said:

I'm not sure I completely understand.  Can you give me an example?

if warp factor is set to 1000x then one click = 1000s. It would just be easier for stepping through things one. bit. at. a. time. to really make note of position/change, etc then have it all fly by in animation

[Arrowstar]

13 hours ago, DBowman said:

Ah! awesome! now I see that I am launching due North  man... (assuming planet blue arrow out the top is N) during the big coast to Ap roll and yaw angle both seem to flip between 0 and 360 randomly, I guess that doesn't really matter, but at the Ap burn they are both somehow set to 180, which I guess explains the "retrograde burn", I'm upside down and going backwards for some reason.

Setting roll to constant 90 in initial steering model and having "continuity" checked only seems to effect the first event duration. After that I see roll = 90 in the graph but the trajectory starts heading North. I'll take another look at the example you gave me. Not going polar should also help the prop consumption...

I set roll angle to 89.99 on all my steering models, it stopped the flipping, at the end of the coast to Ap the yaw sets itself to 180 even though the steering model box says  RPA 89.99, 188.7, 0.0

By the way, you can show your vehicle's attitude/steering in the view area of LVD by: View -> Edit View Settings -> checking "Show S/C Body Axes."  The convention for all LVD axes display is that red is the x axis, green is the y axis, and blue is the z axis.  In LVD, the x axis of the vehicle is the "pointy end" that thrust is generally along.

[Arrowstar]

5 hours ago, Drew Kerman said:

if warp factor is set to 1000x then one click = 1000s. It would just be easier for stepping through things one. bit. at. a. time. to really make note of position/change, etc then have it all fly by in animation

Got it.  So it's sort of easy to implement, but there is a catch.

The slider's step size is obviously manually adjustable.  However, when you tap the arrow buttons on the slider, the slider snaps to the next increment, it does not just add the increment amount to the current value.  As an example, if my slider goes from 0 seconds to 10 seconds and I want an increment of 1 second, a slider value of 1.25 will jump to 2 seconds, not 2.25 seconds.  Does that make sense?

There's not much I can do about this without really hacking the way the MATLAB control works.  Is this behavior acceptable?

[Arrowstar]

Brief update: In LVD, the buttons in the Set Initial State dialog box for setting the initial throttle model and steering model will now prompt for the type of model you want to use.  If you select a new model type, the old model is overwritten (so long as you don't cancel out of the box) with the default version of the new model.  If you select the existing model type, it will populate with current values as expected.  The type selection dialog boxes now also have their default selection set to the currently selected model type for both steering and throttle.

[Arrowstar]

And in other news, apparently this is a thing you can do in MATLAB.

I may add an option for textured celestial bodies...

EDIT: Yeah, this is going to have to be a thing.

Edited December 14, 2020 by Arrowstar

[Drew Kerman]

18 hours ago, Arrowstar said:

Is this behavior acceptable?

Yea, precision in this case is not the goal and you have the text box for that. Also a related UX suggestion - if it's possible to assign the scrollbar arrows tooltips, have one pop up containing the current warp factor setting so people make the connection on the behavior

16 hours ago, Arrowstar said:

I may add an option for textured celestial bodies...

OMGGGGGGGG that's awesome now I don't have to use ground stations to try and figure out what part of the planet my ship is over Will it work in Mission Animator as well?

[Arrowstar]

27 minutes ago, Drew Kerman said:

Yea, precision in this case is not the goal and you have the text box for that. Also a related UX suggestion - if it's possible to assign the scrollbar arrows tooltips, have one pop up containing the current warp factor setting so people make the connection on the behavior

Roger, I'll keep the default implementation then.  Done for next release.

And yes, I can add a tooltip.  Good thought.

Quote

OMGGGGGGGG that's awesome now I don't have to use ground stations to try and figure out what part of the planet my ship is over Will it work in Mission Animator as well?

Yeah, it's turning out even sweeter than I thought it would.  Red triangle is KSC, white triangle is 0,0 (lat/long).

No idea about Mission Animator.  Maybe?  I haven't gotten that far yet.  I'll add it to the to do list.

By the way, if anyone knows where I can get high-res surface imagery of all the stock KSP bodies, please let me know.  I was able to find Kerbin, and maybe outdated maps for Duna and the Mun, but I'm not confident about getting all of them.

[vitorboschi]

59 minutes ago, Arrowstar said:

Roger, I'll keep the default implementation then.  Done for next release.

And yes, I can add a tooltip.  Good thought.

Yeah, it's turning out even sweeter than I thought it would.  Red triangle is KSC, white triangle is 0,0 (lat/long).

No idea about Mission Animator.  Maybe?  I haven't gotten that far yet.  I'll add it to the to do list.

By the way, if anyone knows where I can get high-res surface imagery of all the stock KSP bodies, please let me know.  I was able to find Kerbin, and maybe outdated maps for Duna and the Mun, but I'm not confident about getting all of them.

I have never used this tool, but https://github.com/Sigma88/Sigma-Cartographer but seems able to get them straight from KSP. It's used by https://kerbal-maps.finitemonkeys.org/

[Arrowstar]

54 minutes ago, vitorboschi said:

I have never used this tool, but https://github.com/Sigma88/Sigma-Cartographer but seems able to get them straight from KSP. It's used by https://kerbal-maps.finitemonkeys.org/

THANK YOU!

Yes, this is perfect.  I'm generating the map data now.  Thank you!

[Arrowstar]

Alright, here's some more eye candy.  I've got all of the high detail textures in for all the KSP bodies (aside from the Sun and Jool, which don't have textures).  This is Kerbin and the Mun, as viewed from the Kerbin-Mun two body rotating frame.  You can see both bodies rotating and the sunlight moving around them.  Pretty neat, huh?

I'm going to put out a pre-release tonight, I think, so people can play with this.

[Arrowstar]

Hi everyone,

Tonight I've compiled KSPTOT v1.6.7 pre-release 8.  Sorry for the much larger download size of this file.  Turns out the high res planet textures take up a fair bit of space.  I'm going to try to get that down in the future somehow, but I'm still exploring that at the moment.

Here's the change log:

• LVD: Fixed bug with Adjust Variable dialog getting a weird axes in the background sometimes.
• LVD: Optimization variables are now sorted by event number before optimization so they appear in order in the optimization UI.
• LVD: Having the Update View Limits option checked in the View Settings now retains the existing view direction, it just updates the axis limits.
• LVD: Added ability to display a semi-transparent atmosphere overlay in the View Settings.
• MA/LVD: Added a new astro calculator to find radius/velocity/FPA from sma/ecc/true anomaly.
• MA: Mission Animator UT time entry field now has a context menu for entering time as date/time. It also attempts string evaluation.
• LVD: Added angle equations to steering and throttle UIs.
• LVD: Users can now set the type of throttle model and steering model in the initial state, as well as their corresponding parameters.
• Celestial bodies can now display a surface texture instead of the color gradient used previously.
  • Warning: This will only apply to new MA and LVD mission cases because the data is stored in the data structure that contains data from the bodies.ini files.  Since MA and LVD cache their celestial body data, those existing data structures will not have the data necessary to display the surface textures that now ship with KSPTOT.  A potential "update" path is currently being looked at to add the surface textures to existing cases if the body name and ID match what's in the shipped bodies.ini file.
• MA/LVD: Added flight path angle graphical analysis tasks and constraints.
• MA: Mission Animator time slider step size is now fixed to warp rate.:

EDIT: I found a small bug and am re-uploading the pre-release.  Please hold off until I edit this post again.  Thanks!

EDIT 2: Alright, give it 10 minutes and then it should be good to go.  Note that I did write a rudimentary update function for adding in the textures to existing LVD and MA mission plans.  If you experience issues with this, please let me know.  Thanks!

Edited December 15, 2020 by Arrowstar

[DBowman]

Hi, sweet work with the textures.

I have a hand crafted MAV trajectory that I can tweak within limits and see on the order of 5% prop use efficiency, the optimizer only sets the "get Ap pitch" and final circularization pitch and duration.  if I push it too far the termination conditions don't happen at the right time and I have to rejig it manually. It's okay for now. I treid again with linear tangent, it cheerfully gives me a burn at 89 degrees all the way, I cannot figure how to tune the parameters so it's close. But the pitch program version is okay for now.

Topic shift to Ceres. I'm trying to cross check KSPTOT porkchop against ATK STK and looking at UT it looks like they match, but the year seems odd. I have some independently derived EC trajectories, someone else did via ATK STK,  with 180 day transit for 77 km/s total at UT 2466168.5, which they say is 15-Jan-40. https://www.aavso.org/jd-calculator will spit out the UT when prompted with 15-Jan-40. I did a porkchop plot and I can see that UT is right on a chop, and measuring by eye the x axis I can see trajectories like theirs (caveat they have departure and arrival orbits but your pork chop is just from "plant to planet"?) but the year in the tooltip is 6758, at 365.25 d/y shouldn't it be 6752? How do you work the "enter UT as date/time" I cannot get it to accept anything that is not interpreted as seconds. Any chance to have it show "regular" dates (also)? there is a screenshot here: https://drive.google.com/file/d/1zn3a2lxUGm0HyLrfLfr_ZecfByOElgrL/view?usp=sharing

[Arrowstar]

7 minutes ago, DBowman said:

(caveat they have departure and arrival orbits but your pork chop is just from "plant to planet"?)

Yes, this is correct.

Quote

but the year in the tooltip is 6758, at 365.25 d/y shouldn't it be 6752?

KSPTOT uses 365 civil days of 24 hours per day when using "Earth time."

Quote

How do you work the "enter UT as date/time" I cannot get it to accept anything that is not interpreted as seconds.

KSPTOT uses seconds from an epoch as the internal time system.  Everything ultimately gets interpreted that way.  KSPTOT doesn't actually care about years, or days, or hours, etc.  Just the seconds past epoch is what matters.  The behavior you're seeing is correct.

Quote

Any chance to have it show "regular" dates (also)?

There are places where UT seconds are shown with their date, like on the main KSPTOT UI.  But generally "dates" aren't very interesting, and certainly not useful for astrodynamics.  Remember, KSP itself doesn't really do dates and KSPTOT is primarily written for KSP. 

You'll get used to working with the universal time (UT) seconds at some point.

[DBowman]

1 hour ago, Arrowstar said:

You'll get used to working with the universal time (UT) seconds at some point.

I have no problem with that! (well it's a bit tedious when you consider all the shiny math deriving the plot itself, maybe the data tip should have the UT seconds also? but I can do the KSPTOT date to UT seconds conversion no problems) With 365 days the KSPTOT year matches the UT seconds of the other tool. So that is excellent.

Can I ask what the porkchop does re the inclination of E & C? I'd assumed, and am really hoping it respects the inclinations and isn't simplifying to coplanar.

[Arrowstar]

1 minute ago, DBowman said:

Can I ask what the porkchop does re the inclination of E & C? I'd assumed, and am really hoping it respects the inclinations and isn't simplifying to coplanar.

It's solving Lambert's problem for each combination of departure and arrival date.  It runs computes both the type I and type II solutions and uses the one that minimizes delta-v for each departure/arrival combination.

[Drew Kerman]

@Arrowstar I can't use the included bodies.ini file because I have Kopernicus messing with Kerbin's atmosphere and spin rate. I tried to generate a new .ini but the texture feature was not included in the file. I placed the Kerbin texture lines in myself and that works but was not able to adjust the rotational offset. I tried using surfTextureZRotOffset but not sure if that's what that is for as it didn't seem to make any difference. I made sure to not only reload the .ini file after editing but also never saved my LVD file after load which means it would again convert it to the new .ini data. Here is the discrepancy:

LVD:

Where the trajectory is supposed to end, plugging the lat/lng into my online map

Ahhh, I was just about to post this and had another thought. Did some experimenting and yup, I see what's happening now. The surfTextureZRotOffset is working as intended, each time I edit it and load up LVD the default view of Kerbin changes as the texture is rotated. I didn't really pay attention before just loaded straight up into my case file. So okay the conversion is not using the currently-loaded .ini file it's converting based on the .ini data already in the case file. So then you're either a bit off on the offset calculation to account for a different body rotation speed or forgot to account for that altogether during the update.

[Arrowstar]

1 hour ago, Drew Kerman said:

Ahhh, I was just about to post this and had another thought. Did some experimenting and yup, I see what's happening now. The surfTextureZRotOffset is working as intended, each time I edit it and load up LVD the default view of Kerbin changes as the texture is rotated. I didn't really pay attention before just loaded straight up into my case file. So okay the conversion is not using the currently-loaded .ini file it's converting based on the .ini data already in the case file. So then you're either a bit off on the offset calculation to account for a different body rotation speed or forgot to account for that altogether during the update.

Right, so you've mostly got it.  The entry "surfTextureZRotOffset" in the bodies.ini file should basically be set to the central longitude of the texture you're using (or is it the opposite of the longitude... I'm not sure lol).  In any event, yes, that parameter is only read once when the bodies.ini file is loaded.  Once you create an LVD case file, the parameter is basically fixed because the celestial body information is cached in the case file.

I guess  I don't understand the bit about the calculation being off.  Everything looks okay on my end.  Do you have an example?

EDIT: If you grabbed PR8 download before I fixed the "bug" (in actuality, it was something I did intentionally to make sure things were working as intended but forgot to revert at first), then you might be having an issue.  Try downloading PR8 again and see if that helps maybe.

Edited December 15, 2020 by Arrowstar

[Drew Kerman]

11 hours ago, Arrowstar said:

Try downloading PR8 again and see if that helps maybe

nope, still an issue

11 hours ago, Arrowstar said:

Do you have an example?

you mean you want the actual LVD case file? You can grab it here. Images in my prev post demonstrate the issue. When I plug in the lat/lng from the Final State position it shows up on my Kerbin map where I planned for it to be, but in LVD the trajectory *appears* to end too far east due to the improper texture position.

I use Kopernicus to change my Kerbin rotation to 21651s (it's the slower original Kerbin rotation period before the 6hr synodic day change in v1.0.5)

Edited December 16, 2020 by Drew Kerman

[Arrowstar]

16 minutes ago, Drew Kerman said:

I use Kopernicus to change my Kerbin rotation to 21651s (it's the slower original Kerbin rotation period before the 6hr synodic day change in v1.0.5)

The rotational period in your LVD MAT file is 21600 s for Kerbin.  Could that be the issue?

EDIT: If I correct the MAT file's rotation period to what you set and then plot the coordinates of the pin that you showed on your KSA tracker map into a ground station in your MAT file, it looks like things line up at first glance.

Edited December 16, 2020 by Arrowstar

[Drew Kerman]

5 hours ago, Arrowstar said:

Could that be the issue?

Possibly? I thought this issue sounded familiar so I did a search for 21651 and turns out I actually raised this question last year:

If you follow the posts after you asked for a MAT file and I provided one but I don't see a response referencing it. Seems we both let this one fall through the cracks! So for this entire time has my .ini file exported from KSP failed to report the proper rotperiod?

[vitorboschi]

Hey @Arrowstar, I'm trying to plan a mission that will take place a lot of time in the future, but the ship is already in orbit now. The problem is that when I get its orbital parameters, the epoch is really far away from the first maneuver, which is making the script take a long time to propagate due to this wait.

Question: Is there any tool (or method) inside KSP-TOT that let me change the epoch while calculating the correct true anomaly to keep the same orbit?

If there's another workflow that allow me to plan a mission far in the future, that would help me too.

 

Thanks!

[Arrowstar]

5 hours ago, Drew Kerman said:

Possibly? I thought this issue sounded familiar so I did a search for 21651 and turns out I actually raised this question last year:

If you follow the posts after you asked for a MAT file and I provided one but I don't see a response referencing it. Seems we both let this one fall through the cracks! So for this entire time has my .ini file exported from KSP failed to report the proper rotperiod?

Right, okay.  So assuming you made your bodies.ini file from KSPTOTConnect, then the 21600 seconds is correct.  That is pulling directly from the "rotationalperiod" parameter inside KSP itself.  I know you mentioned that Kopernicus should be updating the rotational period to 21651 seconds.  Could you verify that's actually happening correctly, that your definition of rotational period and Kopernicus' definition of rotational period are the same (both should be sidereal day lengths), and that you created your bodies.ini file using KSPTOTConnect?

37 minutes ago, vitorboschi said:

Hey @Arrowstar, I'm trying to plan a mission that will take place a lot of time in the future, but the ship is already in orbit now. The problem is that when I get its orbital parameters, the epoch is really far away from the first maneuver, which is making the script take a long time to propagate due to this wait.

Question: Is there any tool (or method) inside KSP-TOT that let me change the epoch while calculating the correct true anomaly to keep the same orbit?

If there's another workflow that allow me to plan a mission far in the future, that would help me too.

 

Thanks!

Create a new mission in Mission Architect or Launch Vehicle Designer (MA will be faster), copy the state prior to the propagation into the initial state, propagate for your desired amount of time, and then copy the resultant final state back into your original MA or LVD mission case file as its initial state.

Alternatively, in LVD, once you've done this you can use a Set Kinematic State action event to just jump time and orbit and whatnot forward to the resultant state above instead of using it as an initial state.  If you want to do this or not depends on what you're trying to accomplish and is a bit more complex, yes.

[Drew Kerman]

3 hours ago, Arrowstar said:

Could you verify that's actually happening correctly, that your definition of rotational period and Kopernicus' definition of rotational period are the same (both should be sidereal day lengths)

Ah, so here is the root of the problem then? I guess I am actually changing Kerbin's synodic rotation rate. Here's the patch I use:

  @Body[Kerbin]
  {
    @Properties
    {
      // return Kerbin to old pre-v1.0.5 rotation period
      %rotationPeriod = 21651
    }
  }

I know Kopernicus is working because the new default is 6hrs to match sidereal rotation and the sun will stay in one place if I forward time. Using Hyperedit I can increment the game UT on a week/day/hour basis and clicking repeatedly on the Day+ button the date increases but the sun position does not change after disabling this patch. When I restart the game with my patch again enabled, clicking the Day+ button makes the sun move across the sky. As I noted in my original post, I made this change so sunrise/sunset times would change from day to day.

My understanding of sidereal vs. synodic time however is still not that great in application so maybe I'm just barking up the wrong tree on this issue?

[vitorboschi]

@ArrowstarThanks for the info about orbit epoch! That worked out!

 

Now, I think I stumbled upon a bug:

Matrix dimensions must agree.

Error in TwoBodyPropagator/propagate (line 72)


Error in LaunchVehicleSimulationDriver/integrateOneEvent (line 171)


Error in LaunchVehicleEvent/executeEvent (line 162)


Error in LaunchVehicleScript/executeScript (line 293)


Error in ma_LvdMainGUI>propagateScript (line 180)


Error in ma_LvdMainGUI>runScriptMenu_Callback (line 1635)


Error in gui_mainfcn (line 95)


Error in ma_LvdMainGUI (line 42)


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

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

This happen when opening my LVD mission. Could you take a look at the .mat? Here's the link: https://www.dropbox.com/s/zc2cbiqzt9xn8am/lvd-moho-mission.mat?dl=0