Jump to content

Arrowstar

Members
 View Profile  See their activity

  • Posts

    2,557

  • Joined

  • Last visited

 Content Type 

Everything posted by Arrowstar

  1. Arrowstar
    I had a spare 15 minutes floating around, so I took a look at your MAT file today (but haven't had a chance to dig into the pictures you sent). My advice would be to set your objective function to minimize the distance to Minmus at event 9 and then optimize the coast time of event 7 to be whatever your desired stay duration is +/- one half revolution around the Mun. Without looking, I'm guessing that you're not hitting some orbit angle perfectly and that's throwing off the departure time or true anomaly or whatnot. In any event, when going to other bodies, minimizing the distance to those bodies and optimizing the coast duration prior to the burn is almost always a good idea. Give that a go for now. I'll try to dig into more in a week or two. Happy orbiting!
  2. Arrowstar
    So thanks for sharing this. I'm not going to be able to take a look until early January, unfortunately. I didn't have a chance to get to it today and the holidays are always a busy time for me. Keep working at it and if you're still struggling I'll definitely provide a helping hand after the end of December.
  3. Arrowstar
    Hi everyone, Tonight I have prepared the 4th pre-release of KSPTOT v1.6.1. This release is LVD-focused and addresses a few bugs and adds a few neat features I have been spinning around in my head for a bit now. Adds "stopwatches" to LVD. These are timing devices that can be turned on and off. They will tick upwards when on and not tick when off. Useful for measuring the duration between two non-consecutive events. Added ability to add/subtract mass to a tank as an event action. The LVD Graphical Analysis tool now has the ability to show the mass of an individual tank, the status of stages and engines, and stage dry mass. Fixed the "UI" tweaks that @Drew Kerman mentioned a few days ago. Some other bug fixes, including everything that's been reported to date. The next thing I'm working on is attempting to incorporate a new, potentially faster integrator into LVD for the purposes of speeding up the simulation. In any event, at this rate, v1.6.1 will not drop until after the New Year, so I'm happy to get out this pre-release before then. Please let me know what bugs you find or issues you uncover. Happy orbiting. Can I see you MA .mat file? That would help me address your issue. Btw, keep working at it: I will be pretty busy today and tomorrow but hopefully I can take a look Thursday.
  4. Arrowstar
    Is there anything you're needing in the next release to continue working?
  5. Arrowstar
    UI Tweaks: noted for next release. Thanks! Bug: In my 10+ years of using MATLAB I have literally never encountered this error. Luckily fixing it was easy after some Googling, but even in my own MAT files I've never seen it before now. Good find I guess lol! SRBs and thrust curve: yes, that sounds right about the behavior of the throttle for the SRBs with the max throttle setting. However, note that the max throttle setting is universal (no way to change it at the moment, though I could add that), so if you adjust the throttle model, you still won't be adjusting the max throttle setting. If that's okay, then you're all set.
  6. Arrowstar
    Not so much a side effect of the per event step size as it is the way I have to do things. Each event has to start from the place where the previous event ended, regardless of how many data points are included between events.
  7. Arrowstar
    Regarding LVD: it's set up this way because the integrator function is far, far better at interpolating between data points to get the user set output than any interpolation scheme I could come up with after the fact in Graphical Analysis. The data output is just better from the integrator, which is why I'm having it do the interpolation. Regarding MA: Yeah, the whole "number of data points per coast" thing is a bit hack-ish, I'll agree. The reason it's set up like that is because of the way the two body orbit propagation math is set up. It was the most straight forward way to do it at the time, but if there's interest, I could always look at trying to change that to a "number of data points per second" sort of thing. Can I see the MAT file? Most likely there are some event action-generated state log entries in there. Also, the final event of one event becomes the initial event of the next event (with a different event label internally) so that you and the software can see where the event transition took place. That's probably the rest of them.
  8. Arrowstar
    Thanks! I'm glad you like it. Regarding mods (and assuming you're just referring to Launch Vehicle Designer): FAR: Yes, essentially. You'll just need to update your drag coefficient at regular intervals during ascent. Realistic Rescale and OPM: yes, just create a new bodies.ini file using the KSPTOTconnect plugin. See the OP for instructions. KOS: not directly, but there are ways to get the attitude out of LVD using the Graphical Analysis tool, so you can pull those profiles and then make kOS execute them. Regarding the consumption of consumables other than propellant: yes but not directly. You can create a tank for say oxygen, and then create an engine (call it oxygen consumer) connected to that tank. Set the thrust very very low (1E-20) and then determine the mass flow rate out of the tank you want. Then solve for Isp: T=mdot*g0*Isp Isp=T/(mdot*g0) Plug in the very low thrust and this Isp into the engine profile (both sea level and vacuum spots) and make sure the engine state is active. This will model mass flow from the oxygen tank like in KSP. Late know if you need help with this.
  9. Arrowstar
    Sounds good. By the way, if you have already downloaded the pre-release, please go ahead and redownload. I found a bug that I needed to correct.
  10. Arrowstar
    Hey everyone, I'm happy to share tonight the 3rd pre-release of KSPTOT v1.6.1. The change log for this pre-release is fairly extensive! All changes are within Launch Vehicle Designer. Added constraints for all steering angles and throttle. Added "non-sequential events", which are events which can execute at any point during the mission (between specified script events). Useful for changing pitch profile rate at specified altitudes, jettisoning stages when tanks are empty, and the like. Added a throttle model which will hold the vehicle at a specified thrust to weight ratio. Added an option to set the output step size for each event. Some optimization performance enhancements. A few bug fixes here and there. Happy orbiting.
  11. Arrowstar
    Oh yeah, it's just that constraint UI. Right now it's set up under the hood to handle only the constraints that are present in Mission Architect. Those have a different data structure than the constraints in LVD, and there's a bridging data structure I use so that I can call MA constraints directly in LVD. But when I create new constraints that are LVD-specific, I'll need to probably copy that UI and have it handle the new constraint data type. It's probably not that awful, and I'm just being dramatic, but it's the one part of it that's really a hassle. The rest of the work is very straight forward.
  12. Arrowstar
    I added in a Thrust to Weight throttle model tonight. It'll be in the next pre-release. Note that it's a bit CPU intensive, because it has to determine the throttle setting at every time step to maintain the desired thrust to weight, so use sparingly. Yeah these are coming in the next pre-release too. I've had them on my TO DO list for a while, just haven't gotten around to all the awful UI work that they'll require. But conceptually they are very straight forward.
  13. Arrowstar
    If you set a rate via a model action at time t, that rate takes effect at time t. However, because it's a rate, you won't see it on the actual value of the throttle until some time after t. Example: T=0, throttle is 100, rate is 0 T=1, throttle is 100, rate gets set to -1 T=2, throttle is 99, rate is still -1 Does that make sense?
  14. Arrowstar
    Since dynamic pressure is a play between atmosphere relative speed (squared) and air density, you might investigate your altitude and speed independently to see if there's anything going on. Also check to see if you see that same behavior in KSP somehow. It's possible (though I would think unlikely) that there's an issue with the atmosphere model or the way dynamic pressure is computed in KSPTOT.
  15. Arrowstar
    I would need to see altitude, body relative velocity, and dynamic pressure all on top of each other to fanthom a guess. If I was going to speculate though, I would say it's probably due to the vehicle either losing a bit of altitude or the altitude rate decreasing for a short while.
  16. Arrowstar
    How about just one tweet right before or after your first reference to "ArrowstarTech" stating that, and then it'll be on Twitter for all time and citable in the very unlikely event it's needed. You can not worry about it after that I think.
  17. Arrowstar
    So the curves you want are thrust vs. propellant remaining? It's do-able from a technical sense, but it does involve changing the way engines work. non-trivially. I wish I had known about these curves when I writing the engine code for the first time lol. I'll see what I can do but it won't be right away. This is an issue of focus. The enter key only closes the window with the save/close button if the window itself has focus. If you're in a textbox or some other UI widget, that widget will intercept the enter key push and do with it what it normally does. Not much I can do about that as it's how Windows (or at least MATLAB's UI system) works. I'll take a look! I did notice that the pitch profile in the Excel file was all out of wack (lots of up and down), so that'll be something to look into. Check if the repeated values are occurring at the end of events. If they are, then those are the actions being executed. Each action creates a new state log entry in memory so that it can be tracked ("this action created this state log entry"). MA actually does this too (duplicate time entries) for impulsive delta-v events, but it's not as evident there because there's only going to be one duplicate entry. Anyway, you can use your favorite spreadsheet program to filter out duplicate entries if you're outputting Graphical Analysis data to CSV. As of the next pre-release, which will come when I get enough new features to justify it (or if you really need it, next time I can compile it), it does have this ability now. Each event has an entry for integrator output step size. Set to a positive number, this will give you a data point every N seconds. Set to a negative number or zero, the current behavior of only providing the integrator's native output will be retained. As I said, you can set this output step size independently for each event. That's fine, no worries. If you could, though, please note somewhere (even if it's just an asterisk somewhere) that it's a fictional company. I know it seems obvious, but with the donations thing, I want to make sure that there's no confusion if the IRS were to ever see anything that that is not business income (and therefore I don't owe self-employment taxes lol). Thanks!
  18. Arrowstar
    Okay I'll see what I can do! Okay, so if this is what you're after, then it already exists in LVD! For each engine you create, you can set the minimum and maximum throttle. For SRBs, set the minimum throttle to 100%. This will do what you want. The minimum and maximum allowable throttle setting for each engine overrides the throttle model setting. Sounds good.
  19. Arrowstar
    So this has to do with the nature of double precision and rounding. You'll notice if you grab the final end time from Step 1, add 0.000001 second or so, and then paste into the box in Step 2, it will do what you expect. It's because, under the hood, the string value of the number isn't quite the double precision numerical representation in memory, but it's close. ------ Anyway! I have a new pre-release build for you. This adds to LVD: Actions to change drag and lift properties during a mission; Escape and enter key bindings for (hopefully all) LVD UI dialog boxes; and Dynamic pressure termination conditions, optimization variable, and graphical analysis task (which also shows up in MA because I'm cool like that). Here's the link to KSPTOT v1.6.1 pre-release 2. Go ahead and take a look and tell me what you think. By the way, did I miss anything from all the posts over the past day or so? There have been more than a few of them.
  20. Arrowstar
    So... there's no reason why I couldn't have a throttle model that does what you're talking about, but at the moment I haven't coded one up like that. It would involve some UI changes, too, so it's not super trivial, but I think it's doable if you think it'll be useful to you? Yes, this is intentional. I realize in KSP that you can set the thrust limiter on engines, but in general there's only one throttle for the whole craft, so I chose to make LVD work the same way. I don't have an event action to change the min and max thrust on an engine, but I could, and that would sort of be similar. Thoughts?
  21. Arrowstar
    Oh got it. Yeah, the idea is that when you change some aspect of the vehicle state, it will remain that way and continue propagating. So if you change the throttle model, it will keep that throttle model for all time, until you change it again. If you change the state of a stage or engine, that stage or engine keeps that state until you change it in the future.
  22. Arrowstar
    Events are made up of two things: a termination condition and actions. The event starts at the state from the end of the previous event and propagates until the termination condition is reached. Once it is, propagation terminates. Actions are then executed to change whatever it is you want to change. So actions always execute at the end of their event. This is bizarre, but if you can ever figure out how to replicate it, please let me know, because it looks like something that might need to be fixed.
  23. Arrowstar
    Okay, first things first. I took a look at your MAT file and I think everything is working fine. I determined that the time which T2W = 1.2 is 74604178.1055479 seconds UT, and then plotted throttle vs. time. Looks like it hits 71% at about the time you were thinking. I did notice that you don't change the throttle model at lift off, so it will just continue to accelerate at 100%/s/s until it hits 100%, at which point it will saturate and plateau as it did. It's impact is variable, but it is large enough generally that I went to the effort to be able to turn it off. If you have any thoughts after using LVD for a bit, definitely let me know. I'm open to changing the default. So this is embarrassing... I could have sworn there was an action to change drag area and Cd, but apparently there isn't. I'll add this for the next pre-release. For now, for you, since your vehicle is a cylinder with no side boosters, it's not a big deal. You would be correct here. And once you're out of the atmosphere, it doesn't matter at all.
  24. Arrowstar
    Yes, it's actually degN and degE... I'll update that. Thanks for pointing that out. I'll add it to the TO DO list. I went back and forth on this one. On the one hand, most events probably don't need it. On the other hand, I foresaw a bunch of people trying to understand why their vehicle wasn't transitions to the new SoI if it defaulted to off. It could go either way, of course, but for now I think I'll leave it defaulted to on and if future use suggests that it's better off, then I'll default it to off. It's going to be one of those things where the user base will show what the better path forward is. It should be possible to use the existing throttle model to approximate this. If you can plot the mass flow rate of the engine while it's spooling using the MM patch equations, and then divide that by the 100% throttle mass flow rate, that will give you the effective throttle setting over time during the spooling. Fit the spooling to effective throttle to a quadratic and there you go. Alternatively, as I'm a big proponent of not worrying about minor details, just use a linear ramp on your throttle during the spooling period (from 0 to 100%?) and call it good enough. I'll take a look at your MAT file, thanks!
  25. Arrowstar
    Right, glad you have a chance to take a look! Yes, LVD works best with parallel optimization. The derivatives compute much faster when in parallel mode. If you denied those firewall alerts, be sure to allow them, as the main MATLAB session communicates with the parallel workers via TCP/IP. Thanks for letting me know these are goofed up. I'll take a look. Body Fixed just means that the state of the vehicle is provided relative to the spinning surface of the planet. Longitude, latitude, and altitude have definitions identical to Earth, and you can look up what the latitude and longitude of the KSC is either from Mission Architect (it's hard coded as a ground target/station in new MA sessions) or from some other tool/mod within KSP. Just leave the velocities at 0 if you're launching starting from a fixed (to the surface) state. You can, though realize that that was meant more for aero-braking. If you're using FAR, you can get Cd from that I think. Otherwise, a bullet has a drag coefficient of about 0.3, and a rocket is sort of bullet shaped, so you could use that. The default, 2.2, is meant for objects in the upper atmosphere only. Note that you can update your drag coefficient and area as event actions. So I had a hard think about fuel types in LVD before implementing what I have now, and I concluded they were not necessary. In KSP, tanks really only hold one type of fuel anyway (exception being LOX/Fuel, but it may as well be one type because it's always provided in the exact ratio needed by the engines), and so the easier way to implicitly specify what propellant a tank holds is by the assigned engine. A few tips for you while you work: The single biggest driver of launch vehicle performance is your initial pitch over rate. Make sure to have a few (4 or 5 at least) "pitch profile" segments in there so your optimizer can adjust the pitch rate as needed. Set bounds of no more than a few deg/sec on those pitch rates. Don't use the acceleration terms to start. Also make sure you have continuity on your angles specified (that check box on the bottom of the steering model dialog). Don't worry about modeling any roll right now, you can add that in later. Body relative yaw is specified as 0 degrees pointing north, 90 degrees is east. Do use the body relative steering roll/pitch/yaw for most of your flight, at least at first. You can go to body-relative aero angles eventually too. Maybe most importantly, don't jump into the optimizer right away. Try to get a trajectory that sort of makes it to space just by changing numbers yourself at first. The optimizer is better suited to honing in on a trajectory than finding one from scratch (which it probably can't do). Keep asking questions! Enjoy EDIT: I checked the 2 stage to orbit and GTO LVD examples and they both look fine. Not sure what's going on on your end. If you see a warning about script execution time being exceeded, it may just be that the first run usually takes a fair bit more time than the subsequent runs due to MATLAB's JIT compiler doing its thing. Either just open and close an event to rerun things, or increase the max allowed run time in Settings -> Integration Settings -> Max Script Prop Time. EDIT2: Try redownloading the KSPTOT release on the OP. It should have updated example files... could be that I forgot to update in the ZIP file at some point or something. Btw you are using the latest pre-release, right?
×
×
  • Create New...