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

[vitorboschi]

2 hours ago, Arrowstar said:

It loads fine for me.  Do you have any error messages?

@Drew Kerman

Opens fine here too, although there are no events other than the default one. The vehicle seems to be there though

[Drew Kerman]

@Arrowstar oh sunofa*** when I went to check for errors I opened an error log I saved from a previous problem that was underneath the *actual* error log file, which is indeed empty. This was coupled with the fact that I thought I had actually built an ascent in this file not just the vessel data. But I guess I didn't? Okay. Sorry

@vitorboschi thx for the dbl-check

[Arrowstar]

2 minutes ago, Drew Kerman said:

@Arrowstar oh sunofa*** when I went to check for errors I opened an error log I saved from a previous problem that was underneath the *actual* error log file, which is indeed empty. This was coupled with the fact that I thought I had actually built an ascent in this file not just the vessel data. But I guess I didn't? Okay. Sorry

@vitorboschi thx for the dbl-check

It's all good.

[Drew Kerman]

On 12/6/2020 at 9:37 PM, Arrowstar said:

LVD: Added a linear tangent steering model to the available options in LVD.  This is a great way to get an optimal ascent from the surface of a body to space, as the linear tangent steering law is actually derived directly from optimal control theory.  As of now, only "pitch" type angles can use this steering.

so is this only really usable for bodies without atmosphere?

OH!! Also I forgot to remind you that the Integration Step Size global control is not what I had in mind. What I was asking for was a way to globally set the step size for the integrator output

Edited December 9, 2020 by Drew Kerman

[Arrowstar]

6 hours ago, Drew Kerman said:

so is this only really usable for bodies without atmosphere?

OH!! Also I forgot to remind you that the Integration Step Size global control is not what I had in mind. What I was asking for was a way to globally set the step size for the integrator output

1. You can use it on bodies with an atmosphere, yes, but the underlying theory was derived using a 2D, flat plane, atmosphere-less model.  It'll still work and do what it does, it probably just won't be globally optimal like it is in the context in which it was originally derived.
2. There's no way to control the step size of the integrators internally, so what I'm doing is globally setting the integrator step size output.  MATLAB is smart enough to still take the large steps if it can, and it uses an efficient, specialized interpolation scheme to get data at the requested time steps if the user so chooses.  Any additional processing time you see when doing this is going to be due to creating the objects that hold state information for each time step.

[DBowman]

13 hours ago, Arrowstar said:

There are a few issues with your file:

1. Your radius constraint numbers look like altitudes.  Make it an altitude constraint instead.
2. Your objective function is minimizing total vehicle mass when it should be maximizing it.
3. Remove the "coast in orbit" event until you've got your ascent locked down.  It's just adding propagation time to the process.
4. I don't think your vehicle has enough thrust or propellant mass to make this trajectory work.  You may want to look into that.
5. I adjusted the minimum altitude the integrator tolerates to -1000 km because you were crashing during optimization so often.
6. I added two events: an initial open-loop pitch over and a final fixed pitch rate event after the linear tangent steering. 
7. I also adjusted the fmincon finite difference step size.  I had to play with this to get a decent idea of what it should be, but I think I got it nailed down now.

Anyway, I fixed up your ascent.  Take a look at the new MAT file here.  Keep in mind that what I did is only one way to do it, and you should play around to see if you can find a better way. 

Let me know if you have any other questions!

So many problems! Thanks for looking at it for me.

re #4 rocket equation and references for LMO mean thrust and prop should be okay or close, but that's why I want to simulate with gravity and aero.

I've been playing around with the .mat you provided. I cannot get it to not push Ap out to 450 km before driving it back down again, which tells me it's way off optimal, the pitch control seems to vary only slowly at first, but my gut says pitch over hard early and ease back the rate of change. 

The graph of Dynamic pressure doesn't start till t=270, which is about where it  get out of the atmosphere (atmoHgt=180) - seems odd. There are no errors in the log about troubles computing dynamic pressure.

Maybe I'll go back to trying a piecewise linear pitch program? 

[Drew Kerman]

6 hours ago, Arrowstar said:

There's no way to control the step size of the integrators internally, so what I'm doing is globally setting the integrator step size output.  MATLAB is smart enough to still take the large steps if it can, and it uses an efficient, specialized interpolation scheme to get data at the requested time steps if the user so chooses.  Any additional processing time you see when doing this is going to be due to creating the objects that hold state information for each time step.

sorry, I guess I should have just tried it to see! What threw me was the default setting of 1 instead of -1 so I thought that was the current value, which matches up to the integrator's Initial Step Size

[Drew Kerman]

okay @Arrowstar work with me here on this ascent plan, due to launch in early Feb 2021, I want to try a direct injection to 300km circular orbit. I have everything setup for staging and for the initial launch, which will roll the rocket from 45° to 90° (can't launch 90° due to how its launch platform is setup). I don't bother actually rolling it in the script I just know based on game testing it takes ~10s to complete the roll so I have it fly straight up for that time. From that point I want to start pitching over. Although you said the tangent steering model wasn't best for an atmosphere, could I use it to just get an initial ascent path? Then from there make note of the alt/pitch and manually create several pitch events that recreate it with some leeway in optimized values and let the optimizer go to work? How should I set up the constraints? I know I would want an objective function to maximize LF/O but should I use ap/pe constraints or an altitude + ecc constraints? Speaking of objective functions, it's possible to have more than one but you can't change the optimization type for each? So I can't have maximize LF/O and minimize ecc objective functions? Finally, still not completely sure how to use the Scale Factor for constraints - is that based mainly off the Jacobian Heatmap or do you have some intuitive approaches to it? Thanks

[Arrowstar]

9 hours ago, DBowman said:

So many problems! Thanks for looking at it for me.

re #4 rocket equation and references for LMO mean thrust and prop should be okay or close, but that's why I want to simulate with gravity and aero.

I've been playing around with the .mat you provided. I cannot get it to not push Ap out to 450 km before driving it back down again, which tells me it's way off optimal, the pitch control seems to vary only slowly at first, but my gut says pitch over hard early and ease back the rate of change. 

The graph of Dynamic pressure doesn't start till t=270, which is about where it  get out of the atmosphere (atmoHgt=180) - seems odd. There are no errors in the log about troubles computing dynamic pressure.

Maybe I'll go back to trying a piecewise linear pitch program? 

The dynamic pressure issue is because your Mars body has no temperature curve, so the temperature is assumed to be 0 K all the way through.  This means that your density curve is 0 (and actually I'm guessing there's a divide by zero in there somewhere because of it), and hence, no dynamic pressure.

[Arrowstar]

47 minutes ago, Drew Kerman said:

okay @Arrowstar work with me here on this ascent plan, due to launch in early Feb 2021, I want to try a direct injection to 300km circular orbit. I have everything setup for staging and for the initial launch, which will roll the rocket from 45° to 90° (can't launch 90° due to how its launch platform is setup). I don't bother actually rolling it in the script I just know based on game testing it takes ~10s to complete the roll so I have it fly straight up for that time. From that point I want to start pitching over.

You can use the attitude interpolation to model the roll in 10 seconds directly without having to use roll rates or anything like that.

Quote

Although you said the tangent steering model wasn't best for an atmosphere, could I use it to just get an initial ascent path? Then from there make note of the alt/pitch and manually create several pitch events that recreate it with some leeway in optimized values and let the optimizer go to work?

The linear tangent steering model will still work fine for an atmosphere, it just wasn't derived for that sort of flight.  Whether or not it's better than piecewise linear is up to your specific case.  You can still use (and I might recommend) an initial pitch over rate to get the linear tangent steering away from the discontinuity at 90 degrees pitch, and then a final pitch rate to target the insertion orbit and maybe null out some pitch rate later.

Quote

How should I set up the constraints? I know I would want an objective function to maximize LF/O but should I use ap/pe constraints or an altitude + ecc constraints?

I would actually use altitude / flight path angle / velocity magnitude (speed) constraints for your orbit insertion now that I have FPA in there.  They just behave so much better than SMA/ecc or rA/rP.

Quote

Speaking of objective functions, it's possible to have more than one but you can't change the optimization type for each? So I can't have maximize LF/O and minimize ecc objective functions?

The optimizer will only attempt to maximize or minimize the amalgamation of all of your objective functions according to the method you pick (sum, RSS, etc).  You can't do what you described, it's not how optimizers work sadly lol.  Typically you would pick eccentricity and make it a constraint and then max prop remaining, or pick prop remaining and make it a constraint and minimize eccentricity.  I would do the former.

Quote

Finally, still not completely sure how to use the Scale Factor for constraints - is that based mainly off the Jacobian Heatmap or do you have some intuitive approaches to it? Thanks

You can use the Jacobian heat map thing, that is one way to do it.  You can also just scale it by the magnitude of the desired constraint value.  Honestly there is no one right way to do it.  I talked with the folks at UCSD (University of California San Diego) who wrote SNOPT (industry standard gradient optimizer, it's great) and they basically said that there's no right or wrong way to scale, you just have to try out different techniques for your problem.  The only advice I can give is, if nothing else, try to make your scale factor such that constraint values are between -1 and 1.  Otherwise you have to just play with it.  Welcome to real world trajectory design, where we spend almost as much time making the optimizer work as we do designing the trajectory lol.

Oh, something I'll add about the linear tangent steering in general: if you find your pitch angles going very negative, that means that you probably need to stop burning, coast for a bit, and then pick up your insertion burn later.  Doing things in one long burn isn't necessarily optimal, even if linear tangent steering does come from "optimal control theory."  This is because you still define the controls, and as it turns out, throttle is a control too! 

[DBowman]

8 hours ago, Arrowstar said:

The dynamic pressure issue is because your Mars body has no temperature curve, so the temperature is assumed to be 0 K all the way through.  This means that your density curve is 0 (and actually I'm guessing there's a divide by zero in there somewhere because of it), and hence, no dynamic pressure.

I coded a pitch program by hand. Pitch hard, Pitch gently till Ap hits 250, coast till at Ap alt, optimize pitch and time for circularizing burn constrained by semi major axis. That gets a 700 kg vehicle up with 740 kg of leftover prop from 4-ton initial, so I figure it's putting into orbit double the mass it needs to, so probably 2-ton of initial prop is enough. Maybe even better if/when I figure out how to optimize the pitch segments. Seems like one advantage of the linear tangent stuff is a smaller number of optimization params, and that they are more naturally linked by partial derivatives?

Time to try out the plugins! Can you tell which of these I don't need to fill out for aero to work? (I'm guessing I need molar mass (at 0 km))

atmoTempAlts = 0.00000000000
atmoTempTemps = 0.00000000000
atmoTempSunMultAlts = 0.00000000000
atmoTempSunMults = 0.00000000000
latTempBiasLats = 0.00000000000
latTempBiases = 0.00000000000
latTempSunMultLats = 0.00000000000
latTempSunMults = 0.00000000000
atmoMolarMass = 0.0

 

[Arrowstar]

1 hour ago, DBowman said:

I coded a pitch program by hand. Pitch hard, Pitch gently till Ap hits 250, coast till at Ap alt, optimize pitch and time for circularizing burn constrained by semi major axis. That gets a 700 kg vehicle up with 740 kg of leftover prop from 4-ton initial, so I figure it's putting into orbit double the mass it needs to, so probably 2-ton of initial prop is enough. Maybe even better if/when I figure out how to optimize the pitch segments. Seems like one advantage of the linear tangent stuff is a smaller number of optimization params, and that they are more naturally linked by partial derivatives?
 

In an ideal world, yes, that's true.  However, the linear tangent stuff is super sensitive to small changes in its terms, so what you make up for in few optimization variables might be lost because of those sensitivities.  You'll just have to play and see how it works for you.

Quote

Time to try out the plugins! Can you tell which of these I don't need to fill out for aero to work? (I'm guessing I need molar mass (at 0 km))

atmoTempAlts = 0.00000000000
atmoTempTemps = 0.00000000000
atmoTempSunMultAlts = 0.00000000000
atmoTempSunMults = 0.00000000000
latTempBiasLats = 0.00000000000
latTempBiases = 0.00000000000
latTempSunMultLats = 0.00000000000
latTempSunMults = 0.00000000000
atmoMolarMass = 0.0

At the very least you need the two temp ones on the top and the two "atmoTempSunMult", plus the molar mass, yes.

[DBowman]

1 hour ago, Arrowstar said:

In an ideal world, yes, that's true.  However, the linear tangent stuff is super sensitive to small changes in its terms, so what you make up for in few optimization variables might be lost because of those sensitivities.  You'll just have to play and see how it works for you.

At the very least you need the two temp ones on the top and the two "atmoTempSunMult", plus the molar mass, yes.

okay thanks, do you know what these represent? some googling => "something to do with scattering" 

(from Kerbin)

atmoTempSunMultAlts = 0.00000000000,8.81521972656,16.05038867188,25.72923437500,37.87944140625,57.44012500000,63.90271875000,70.00000000000
atmoTempSunMults = 1.00000000000,0.30000001192,0.00000000000,0.00000000000,0.20000000298,0.20000000298,1.00000000000,1.20000004768
 

https://github.com/KSP-RO/RealSolarSystem/blob/master/GameData/RealSolarSystem/RSSKopernicus/Mars/Mars.cfg

has some data for Mars, do you have a better source?

[Drew Kerman]

On 12/10/2020 at 10:22 AM, Arrowstar said:

You can use the attitude interpolation to model the roll in 10 seconds directly without having to use roll rates or anything like that.

Oh I know, I just don't really see the point of doing that. I figured doing the roll in LVD wouldn't have any major effect on the outcome and it doesn't have inputs for engine vector or fin steering steering limits so it can't actually tell me how long it will take the rocket to roll (future feature? eh, maybe at least for engine gimbal but either way not a big deal IMO). So why bother when the rocket will be otherwise heading straight up anyway? if it were pitching while rolling, that may be another thing. Please correct me if my assumptions are wrong!

No comment on your other tips, I will work to apply them and update you on progress when I hit a wall at some point

[Arrowstar]

13 hours ago, DBowman said:

okay thanks, do you know what these represent? some googling => "something to do with scattering" 

(from Kerbin)

atmoTempSunMultAlts = 0.00000000000,8.81521972656,16.05038867188,25.72923437500,37.87944140625,57.44012500000,63.90271875000,70.00000000000
atmoTempSunMults = 1.00000000000,0.30000001192,0.00000000000,0.00000000000,0.20000000298,0.20000000298,1.00000000000,1.20000004768
 

https://github.com/KSP-RO/RealSolarSystem/blob/master/GameData/RealSolarSystem/RSSKopernicus/Mars/Mars.cfg

has some data for Mars, do you have a better source?

As I mentioned before, if you use the File -> Create Bodies.ini File From KSP (or whatever the exact wording is) menu item in the main KSPTOT window, this will create the bodies file from data directly in KSP.  This is the preferred way to generate bodies.ini files.  Give this a go and tell me how it works for you.

2 hours ago, Drew Kerman said:

Oh I know, I just don't really see the point of doing that. I figured doing the roll in LVD wouldn't have any major effect on the outcome and it doesn't have inputs for engine vector or fin steering steering limits so it can't actually tell me how long it will take the rocket to roll (future feature? eh, maybe at least for engine gimbal but either way not a big deal IMO). So why bother when the rocket will be otherwise heading straight up anyway? if it were pitching while rolling, that may be another thing. Please correct me if my assumptions are wrong!

No comment on your other tips, I will work to apply them and update you on progress when I hit a wall at some point

Roll isn't important for thrust, so you are free to ignore it if you'd like!  It's not a problem.

And no, engine gimbal or fin steering will never be in LVD.  Those are 6-DOF things and I just don't have the experience (or the desire) to incorporate that sort of analysis. Sorry!

[Arrowstar]

I know I've been talking a lot recently about using radius, velocity, and flight path angle, as opposed to SMA, eccentricity, and possibility true anomaly, as insertion state constraints in Launch Vehicle Designer.  It did occur to me the other day that most LVD users probably don't know how to compute flight path angle and probably don't know how to get radius and velocity from an SMA/eccentricity/true anomaly combination either.

I've thus added a new astrodynamics calculator to handle these calculations for you. It will be available in both MA and LVD under the Tools -> Astrodynamics Calculators menu item of each.

Enjoy!

[DBowman]

5 hours ago, Arrowstar said:

As I mentioned before, if you use the File -> Create Bodies.ini File From KSP (or whatever the exact wording is) menu item in the main KSPTOT window, this will create the bodies file from data directly in KSP.  This is the preferred way to generate bodies.ini files.  Give this a go and tell me how it works for you.

I recall, since I need Mars you are thinking RSS or Copernicus data will be okay? I've no idea how suitable their temp & sun mult data is. I have Mars (alt,temp) data, but not yet sun mult

[Arrowstar]

4 minutes ago, DBowman said:

I recall, since I need Mars you are thinking RSS or Copernicus data will be okay? I've no idea how suitable their temp & sun mult data is. I have Mars (alt,temp) data, but not yet sun mult

I mean, it's worth a shot.  Otherwise you'll need to get the data from somewhere else.

That said, can I ask why you need Mars data directly that RSS might not be suitable for?  Please tell me you're not using KSPTOT for something other than KSP... the warranty is definitely not good for that lol.

[DBowman]

1 hour ago, Arrowstar said:

I mean, it's worth a shot.  Otherwise you'll need to get the data from somewhere else.

That said, can I ask why you need Mars data directly that RSS might not be suitable for?  Please tell me you're not using KSPTOT for something other than KSP... the warranty is definitely not good for that lol.

I just want to get a sanity check on the ascent + aero-effects, I thought RSS might not be as sensitive to some parameters are LVD. NASA papers always reference a "protected" sw package that only gov employees "with a good reason" can get access to. One of those cases where you have an idea and keep following the loose ends.

[Drew Kerman]

7 hours ago, Arrowstar said:

Sorry!

no problem it was just an idea I had as I was typing my response, never actually even considered it before

[Arrowstar]

3 hours ago, DBowman said:

I just want to get a sanity check on the ascent + aero-effects, I thought RSS might not be as sensitive to some parameters are LVD. NASA papers always reference a "protected" sw package that only gov employees "with a good reason" can get access to. One of those cases where you have an idea and keep following the loose ends.

Okay,  that's fair.  To be honest, knowledge of the Martian atmosphere is pretty thin in the scientific community compared to our Earth models, even today.  I would assume that whatever RSS has implemented is probably close enough to truth (or at least, our best knowledge of the truth today) that it'll due for your purposes.  Remember, the Martian atmosphere is only 1% of the density of Earth's.  It's not irrelevant, but it's also not nearly as big of a driving factor when it comes to ascent as Earth's atmosphere is.  I wouldn't worry about super high atmospheric fidelity too much.

Is the protected software package you're referring to a Mars atmosphere model?

3 hours ago, Drew Kerman said:

no problem it was just an idea I had as I was typing my response, never actually even considered it before

Yeah, no problem.  Modeling steering torques on a vehicle is actually a  whole separate type of analysis.  In the real world, we split the trajectory design up into two parts: the low fidelity 3 degree of freedom (DOF) trajectory, which is optimized (think LVD); and the high fidelity 6 DOF trajectory, which takes the trajectory targets from the optimized 3DOF trajectory and uses guidance routines to steer using actuators. 

Actually modeling the 6DOF actuators involves implementing guidance algorithms and control system models that I just don't know enough about to make it feasible.  It's also not super relevant, since most KSP players wouldn't then go and implement those same control systems and guidance software in KSP anyway.  (6DOF simulations tend to be very vehicle specific in this way, whereas 3DOF sims are pretty agnostic once you get past thrust, isp, and masses.)

Good question though!

4 hours ago, DBowman said:

I just want to get a sanity check on the ascent + aero-effects, I thought RSS might not be as sensitive to some parameters are LVD. NASA papers always reference a "protected" sw package that only gov employees "with a good reason" can get access to. One of those cases where you have an idea and keep following the loose ends.

Btw, I keep an RSS bodies.ini file for myself for testing.  You're welcome to play with it.  Here's the relevant Mars portion if you want to see what they did for their atmosphere model:

[Mars]
epoch = -31542641.784000002
sma = 227949699.961976290
ecc = 0.093261103
inc = 24.692724269
raan = 3.351911063
arg = 332.102265530
mean = 169.391312794
gm = 42828.310000000
radius = 3375.800000000
atmoHgt = 125.000000000
atmoPressAlts = 0.00000000000,1.00000000000,2.50000000000,4.00000000000,5.50000000000,7.15200000000,8.50000000000,10.00000000000,12.00000000000,14.00000000000,16.00000000000,18.00000000000,20.00000000000,22.00000000000,24.00000000000,26.00000000000,28.00000000000,30.00000000000,35.00000000000,40.00000000000,45.00000000000,50.00000000000,55.00000000000,60.00000000000,65.00000000000,70.00000000000,75.00000000000,80.00000000000,85.00000000000,90.00000000000,95.00000000000,100.00000000000,105.00000000000,113.00000000000,125.00000000000
atmoPressPresses = 1.14497005939,1.05023002625,0.92174899578,0.80806797743,0.70759099722,0.61049997807,0.54065597057,0.47173500061,0.39252200723,0.32582300901,0.26977300644,0.22277100384,0.18344900012,0.15063199401,0.12331800163,0.10064800084,0.08188779652,0.06641159952,0.03878010064,0.02219690010,0.01248379983,0.00693851989,0.00382772996,0.00209900993,0.00114502001,0.00061980402,0.00033288001,0.00018108400,0.00009842960,0.00005285560,0.00002801030,0.00001463420,0.00000752905,0.00000250968,0.00000000000
atmoTempAlts = 0.00000000000,7.15200000000,14.25000000000,22.00000000000,40.00000000000,53.00000000000,66.50000000000,71.00000000000,78.60000000000,85.00000000000,95.00000000000,108.00000000000,115.00000000000,125.00000000000
atmoTempTemps = 194.75000000000,193.60000610352,197.89999389648,189.60000610352,165.60000610352,157.89999389648,156.50000000000,154.60000610352,159.00000000000,153.89999389648,145.00000000000,137.19999694824,127.59999847412,118.30000305176
atmoTempSunMultAlts = 0.00000000000,7.15200000000,17.00000000000,62.00000000000,76.00000000000,93.00000000000,106.00000000000,125.00000000000
atmoTempSunMults = 1.37000000477,1.00000000000,0.28999999166,0.00000000000,-0.18000000715,0.00000000000,-0.10000000149,0.25999999046
latTempBiasLats = 0.00000000000,0.66322511576,1.57079632679
latTempBiases = 2.00000000000,0.00000000000,-18.00000000000
latTempSunMultLats = 0.00000000000,1.04719755120,1.57079632679
latTempSunMults = 64.00000000000,34.00000000000,4.00000000000
atmoMolarMass = 0.043480000
rotperiod = 88642.684800000
rotini = 25.000000000
bodycolor = gray
canBeCentral = 1
canBeArriveDepart = 1
parent = Sun
parentID = 0
name = Mars
id = 11

 

[Drew Kerman]

@Arrowstar just thought up a feature request for the Mission Animator - tie the scroll buttons to the warp factor. So a single click = warp factor. Pressing play/stop works okay but does also always advance two steps instead of one. If it's not simple to tie in the scroll button the play/stop method works fine, but only for advancing forwards. I know you can scrub with the scrollbar, but depending on the scale of the timeline getting tiny movements can sometimes be difficult. Also can the "sec" field allow for using the UT time dialog?

Edited December 12, 2020 by Drew Kerman

[DBowman]

19 hours ago, Arrowstar said:

Is the protected software package you're referring to a Mars atmosphere model?

Btw, I keep an RSS bodies.ini file for myself for testing.  You're welcome to play with it.  Here's the relevant Mars portion if you want to see what they did for their atmosphere model:

 

NASAs POST2 - I guess giving away hypersonic trajectory simulators is not the done thing.

Thanks for the RSS bodies.ini and your inputs.

I managed to put together a .mat that gets into a 250x250 LMO with aero effects. I put some graphs and the .mat here (https://drive.google.com/file/d/1qaKIbTivOiqO-_CpD4lk8BKI5d9s9SGt/view?usp=sharing)

• Good things: 700 kg dry + 2-ton prop gets up with 47 kg prop left over. maxQ 170 Pa. Without the first event 10 km vertical it's 250-ish so aero acts like I'd expect.
• My bads: you can see after attaining Ap=205 km it decays a few km, the Ap is attained too early. The optimizer should be able to fix this right? 
• Weird: look at the burn at Ap I had to make it optimize a pitch around 180 degrees, which sounds to me like retrograde burn, but it has a prograde effect. What is pitch exactly relative to? I assumed it was the ground radially beneath you? Oh and what's up with the LVD GUI? Sun and Mars? That happened after I set the vehicle initial state to be Mars not Sun. It's not important, but the plot with the planet and trajectory is cool.

I feel like I can massage the .mat to get better performance out of it. My plan is to have "optimizer pitch rate and fixed target" events so there is just one thing in each even t for the optimizer to tweak.  Prefixed with an  "optimize pitch rate and target altitude" event. I kinda feel like I'll have to hand craft the parameters to be "close" and then the optimizer tunes from there? But maybe that means I only get a local optima?

Any and all advice or inputs gratefully accepted. cheers!

 

[Arrowstar]

2 hours ago, DBowman said:

My bads: you can see after attaining Ap=205 km it decays a few km, the Ap is attained too early. The optimizer should be able to fix this right?

It should be possible, yes.

Quote

Weird: look at the burn at Ap I had to make it optimize a pitch around 180 degrees, which sounds to me like retrograde burn, but it has a prograde effect. What is pitch exactly relative to? I assumed it was the ground radially beneath you? Oh and what's up with the LVD GUI? Sun and Mars? That happened after I set the vehicle initial state to be Mars not Sun. It's not important, but the plot with the planet and trajectory is cool.

1. Pitch is relative to the plane whose normal vector is the position vector of the spacecraft.
2. 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."

Quote

I feel like I can massage the .mat to get better performance out of it. My plan is to have "optimizer pitch rate and fixed target" events so there is just one thing in each even t for the optimizer to tweak.  Prefixed with an  "optimize pitch rate and target altitude" event. I kinda feel like I'll have to hand craft the parameters to be "close" and then the optimizer tunes from there? But maybe that means I only get a local optima?

I'm sure you can squeak out some extra performance from your trajectory.  Remember to add an objective function to your optimization at some point.  And yes, you often do have to "handcraft" your optimization variables initially to get them close and then the optimizer can run from there.  There's an "Adjust Variables" item in the optimization menu that can help here.

Edited December 13, 2020 by Arrowstar

[Arrowstar]

10 hours ago, Drew Kerman said:

@Arrowstar just thought up a feature request for the Mission Animator - tie the scroll buttons to the warp factor. So a single click = warp factor. Pressing play/stop works okay but does also always advance two steps instead of one. If it's not simple to tie in the scroll button the play/stop method works fine, but only for advancing forwards. I know you can scrub with the scrollbar, but depending on the scale of the timeline getting tiny movements can sometimes be difficult.

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

Quote

Also can the "sec" field allow for using the UT time dialog?

Done for next release.