Jump to content

Arrowstar

Members
 View Profile  See their activity

  • Posts

    2,557

  • Joined

  • Last visited

 Content Type 

Everything posted by Arrowstar

  1. 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.
  2. 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.
  3. Arrowstar
    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?
  4. Arrowstar
    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.
  5. Arrowstar
    I'm not sure I completely understand. Can you give me an example? Done for next release.
  6. Arrowstar
    It should be possible, yes. Pitch is relative to the plane whose normal vector is the position vector of the spacecraft. 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." 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.
  7. Arrowstar
    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? 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! 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
  8. Arrowstar
    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.
  9. 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!
  10. Arrowstar
    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. 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!
  11. Arrowstar
    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.
  12. Arrowstar
    You can use the attitude interpolation to model the roll in 10 seconds directly without having to use roll rates or anything like that. 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. 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. 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. 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!
  13. Arrowstar
    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.
  14. Arrowstar
    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. 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.
  15. Arrowstar
    It's all good.
  16. Arrowstar
    It loads fine for me. Do you have any error messages?
  17. Arrowstar
    There are a few issues with your file: Your radius constraint numbers look like altitudes. Make it an altitude constraint instead. Your objective function is minimizing total vehicle mass when it should be maximizing it. Remove the "coast in orbit" event until you've got your ascent locked down. It's just adding propagation time to the process. I don't think your vehicle has enough thrust or propellant mass to make this trajectory work. You may want to look into that. I adjusted the minimum altitude the integrator tolerates to -1000 km because you were crashing during optimization so often. I added two events: an initial open-loop pitch over and a final fixed pitch rate event after the linear tangent steering. 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!
  18. Arrowstar
    This is why I created a function to generate a bodies.ini file straight out of KSP. Load KSP, get into the Flight Scene (where you can see a vehicle, maybe on the launch pad), and then in KSPTOT: File -> Create New Bodies File from KSP. It pulls in all the relevant information for the solar system you're working with and then creates the text file for you so that you don't have to. I'll take a look.
  19. Arrowstar
    You cannot replace a solar system in an existing mission because the various bodies that are in that solar system are referenced by various parts of the mission internally. So yes, in general you do need to make sure that you get your solar system in order before starting a mission, or you will be starting over. Now, that said, there is technically a way to edit parameters of the solar system using plugins (LVD: Plugins -> Manage Plugins). For example, you can create a new plugin, set it to run prior to propagation, and then (for example) put the following code in it to adjust Jool's radius: lvdData.celBodyData.jool.radius = 6000; Run this one and then turn off the plugin, as the changes will be permanent in memory. The various data structures are viewable through the "Show Plugin Data Explorer" button. Plugins are written using MATLAB code and are executed by MATLAB like any other code in KSPTOT. You can technically rewrite the whole solar system this way, including adding and removing bodies, but I'd caution you against doing this too extensively. Plugins are unfiltered MATLAB code (with a few exceptions to make sure nothing malicious runs on a computer and deletes files or things like that). They can corrupt your MAT file if you don't know what you're doing.
  20. Arrowstar
    Could I ask a favor from a few people who use KSPTOT regularly? I'm looking to decide whether or not its worth upgrading to MATLAB R2020b, which is the latest release. The biggest driver here is performance in Launch Vehicle Designer. Here's what I need: Download the KSPTOT v1.6.7 PR7 R2020b package. Navigate to the following page: https://www.mathworks.com/products/compiler/matlab-runtime.html Download from (2) the R2020b (9.9) MCR package for your operating system. Install the just downloaded MCR package. Open the R2020b PR7 package, unzip to a directory, and run the executable for your operating system as normal to start KSPTOT. Open LVD. Open the "lvdExample_TwoStageToOrbit.mat" file in LVD. Tap control-p a few times until the script run time shown in the information window stabilizes (should be 5-6 times at least). Paste those times here in a post. Repeat steps 5-9 with the R2017b KSPTOT v1.6.7 PR7 package (previously posted a few days ago). The same MAT file used in step (7) should work for both versions of the pre-release. Please also post your operating system, CPU model, and amount of RAM if you could, please. What I'm after is trying to see if there's any appreciable speed up or slow down in script execution time between the two versions. If we see a good speed up, then it might be worth jumping versions. If not, then it's probably not worth the time and resources to upgrade MATLAB. Thanks for your help, everyone!
  21. Arrowstar
    A few things: The error you see is because the bodies.ini file is missing the parentID line for a body. You need to add that: "parentID = 0" most likely, but just grab whatever you're using for the ID of the Sun. You can load bodies files from the main KSPTOT File menu. There's no need to hack them or whatnot. Yes, LVD and MA cache their celestial body data so that changes the user makes to what's in memory at any given time don't disrupt the current mission plan.
  22. Arrowstar
    Okay, take a look now.
  23. Arrowstar
    Ah, right. Well, stand by a bit longer then lol.
  24. Arrowstar
    Okay, try downloading PR7 again and see if it works. I've updated the Windows binary.
  25. Arrowstar
    Alright, I'm working on what is hopefully a fix and I should have a new build of PR7 up soon-ish for you to test.
×
×
  • Create New...