Jump to content

Arrowstar

Members
 View Profile  See their activity

  • Posts

    2,561

  • Joined

  • Last visited

 Content Type 

Everything posted by Arrowstar

  1. 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.
  2. 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.
  3. 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!
  4. 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?
  5. Arrowstar
    Hi there! It has to be the MCR version specified in the first post. That is R2017b, which is 9.3. Please let me know if you have any more questions!
  6. Arrowstar
    Thanks for the bug reports, guys. KSPTOT v1.6.1 pre-release1 should resolve both of these bugs. There are also some updates to LVD (mostly in the context of the aerodynamics models and some additional performance optimizations). Please let me know if you are still having problems after using this pre-release. Thanks!
  7. Arrowstar
    What's happening is that you found a leftover bit of code from when I was prototyping the application. I didn't really do any testing with other bodies.ini files and so this one escaped me. I'll get out a fix next week for you. :)
  8. Arrowstar
    I just created this bug to address an issue with many nullreferenceexceptions in the KSP.log file: https://github.com/TheProtagonists/TheWorldBeyond/issues/5
  9. Arrowstar
    Thanks! Let me know if you have any questions. Also see Launch Vehicle Designer in the just-released version of KSPTOT. It's like MA, but it works for launch vehicles too. It's not as fast at propagating orbits though, so if you're mostly doing in-space trajectory design work, just stick with MA. MA is also a much more mature tool too, I think at this point I've worked out all of the bugs and kinks.
  10. Arrowstar
    Hi everyone! Great news! Today I'm officially announcing the release of KSP Trajectory Optimization Tool v1.6.0! This is such a huge milestone and I'm glad to have finally made it here. Obviously Launch Vehicle Designer is the biggest news. The last week or so has been chock full of fixing bugs and optimizing code performance and getting those last minute features in that make the new tool usable and hopefully enjoyable. As a fun statistic, I ran a SLOC (source lines of code) count on KSPTOT today and I found that there are 84,172 source lines of code in the entire MATLAB code base! Of these, 13,424 are specific to Mission Architect or Launch Vehicle Designer (they share much common code) and 6068 are specific to the new Launch Vehicle Designer. KSPTOT is a big project. Anyway, as is tradition, let's get to the change log! NEW TOOL: Launch Vehicle Designer! Launch Vehicle Designer (LVD) is a new analysis tool within KSPTOT. It's purpose is to provide an intuitive way to perform simple-to-complex analysis of launch vehicles and their trajectories. It can model staging, atmospheric forces, variable engine thrust and Isp, a number of steering laws, SoI transitions, and a whole host of other activities that one normally carries out in KSP. Also, because of the general nature of the tool, an analyst could actually use LVD for a full end-to-end mission design, from launch, to in space maneuvers, to landing, to splashdown back at Kerbin. Bug Fix: Fixed a bug with Mission Architect's Launch Window Analysis tool. New Feature: Mission Architect can now more intelligently look for SoI transitions using the "Num. SoI Search Attempts" function. New Feature: Mission Architect supports the Orbit Decay mod. MA can now model semi-analytic orbit decay due to atmospheric drag effects. It's a small change log with a lot of new functionality. Finally, per my comment from a few days ago, I did go ahead and create a Ko-Fi account for those who wish to say "Thanks!" via donation. There's a button on the original post that says "Buy Me a Coffee". You can click that button and it will take you to the page to do so. Totally optional and voluntary, but there it is. Anyway, as usual, the download for KSPTOT v1.6.0 is now online and available from the original post. Have fun and happy orbiting!
  11. Arrowstar
    Maybe? I'm not sure what you actually mean by this.
  12. Arrowstar
    Alright, I see what's happening. So here's the deal. The pork chop plot and the Compute Departure function work off what's called the "Local Gravity Well" or "Infinitesimal Gravity Well" assumption. This means that the sphere of influence of Kerbin (in this case) is modeled as having zero radius. The required post-departure state you get from the calculator (in the Sun-centered frame) is correct, but the subsequent required post-burn Kerbin orbit and thus the Kerbin departure burn you're using are approximations due to that assumption. This is the only way to compute things quickly unfortunately. Anyway, they will get you close, as you saw they did, but unless you're aiming for a massive target like Jool, you'll probably miss the SoI by a bit. What you need to do is take that departure burn and either A) tweak is slightly (time, prograde component, normal component, and radial component) to hit Dres (make sure to check that Use button for mean anomaly and epoch), or B) get your initial orbit and that departure burn into Mission Architect and then have Mission Architect tweak the burn to hit Dres. Mission Architect is a higher fidelity orbit analysis tool in KSPTOT that actually models the Spheres of Influence as they are in KSP. If you're feeling adventurous and you have time, go ahead and try Mission Architect. It can provide you with the most fuel efficient burn to get from Kerbin to Dres, and it's burn solution should be spot on. (That is, if you import that burn into KSP, it should look exactly like what it does in Mission Architect and vice versa.) However, like all "real world" orbit modeling and analysis tools, Mission Architect is complex to use. So if you just want to get it done and get playing with KSP, then you're best off just noting the approximations and assumptions that went into the pork chop plot and Compute Departure and then spending time tweaking the burn a bit in KSP itself to get you there. If you can't get an intercept after tweaking the burn at Kerbin in KSP, then get as close as you can and add another maneuver node, half way to Dres, and tweak that one a bit to get you the rest of the way there. It should be a small correction maneuver. If you do want to use Mission Architect, there are a bunch of examples out there, as well as a tutorial in the documentation somewhere. You can also ask me questions here on the forum and I'm happy to help answer them.
  13. Arrowstar
    If you have a stock save file that shows this problem (preferably the issue you screenshot above), then if you can pass that along to me, I'll try to take a look.
  14. Arrowstar
    @nsgallup, my best guess is that because you're not using the option to incorporate your orbit's mean anomaly and epoch, the code is just assuming you'll be at the right place at the right time. Check that box in the initial orbit window that pops up and see if that helps. @Drew Kerman, thanks for the thoughts! In other news, I've been putting the finishing touches on Launch Vehicle Designer tonight. I worked through some major code speed/performance improvements (up to 50% decrease in run time depending on the orbit regime and if engines are firing or not), added a few new event termination conditions related to the ascending and descending nodes, and added some helpful warnings related to maximum mission time and maximum propagation time upper limits. (These checks prevent the code from getting stuck or taking forever and never finishing or finishing too slowly.) I think we're going to be ready to go for a v1.6.0 release by the end of this weekend. I can't think of anything else I need to add, and with the exception of a bug report I received today that I still need to investigate, I think everything is in pretty solid "initial release" state. This has been about two months in the making and I'm very excited to be getting to this point.
  15. Arrowstar
    Hey everyone! I have a question for the KSPTOT community tonight. For a bit now I've been thinking of setting up a Ko-Fi account. Ko-Fi is a bit like a PayPal Donate button, but appears to be a bit more user friendly (and creator friendly). The intent behind this is to give people another way of saying thanks beyond sending me PM notes or leaving messages here in my thread. (The latter two of which, I should point out, I really do appreciate and always give me a warm fuzzy feeling inside when I read one.) I'm asking because I'm not too familiar with how these sorts of things are received by a community and I want to make sure I am not doing something that will be perceived negatively. This is probably a good time to point out that KSPTOT has always been free, is free today, and will always remain free to download and use. It is one of my most enjoyable hobbies and I consider it my gift to the KSP community. KSP has given me so many hours of enjoyment, it's my pleasure to give back in this way. That said, in the past, I have received questions from users over the years about if I accept donations or the like and I've always had to say no because I never liked PayPal and I don't think I produce regularly enough for a Patreon or something like that. My discovery of the Ko-Fi website changes that a bit. Anyway, what are your thoughts? I'm happy to hear opinions either way, positive or negative. And if I don't hear anything, I'll assume no one cares and probably go ahead and give it a whirl anyway lol. Thanks everyone! Happy orbiting.
  16. Arrowstar
    Tonight I added one of that last details to Launch Vehicle Designer I wanted to get in before the first formal release. There is now a "Next SoI transition" event termination condition. I'm thinking that, unless anyone mentions anything or reports a bug, I'll probably create the v1.6.0 build this upcoming weekend. Presumably the bug reports will start coming in then lol.
  17. Arrowstar
    Huh, could you PM me a link then? Maybe I'm looking at the wrong Twitter feed.
  18. Arrowstar
    No worries! Doesn't look like the twitter account has been active for a while though? Are you posting your progress anywhere?
  19. Arrowstar
    Change the branch to "Launch Vehicle Designer." They're all under that branch until I get the code ready to release the stable v1.6.0.
  20. Arrowstar
    Go ahead and execute the maneuver anyway. I played around with it some and initially I saw what you did. However, after I put my spacecraft in the post-burn orbit and timewarped at x50 for about 5 seconds, the intercept with the Mun appeared.
  21. Arrowstar
    Hi everyone, This afternoon I'm pushing out the fifth pre-release of KSPTOT v1.6.0. The major update in this pre-release is the ability for spacecraft to transition SoIs within Launch Vehicle Designer. I had originally left out this capability in order to concentrate on more pressing concerns. However, now that those are resolved, I am including this functionality in LVD. I've tested it reasonably well but, as usual, please report any bugs to me. There are a number of other smaller changes, too. You can read the commit logs on the KSPTOT GitHub for more information. By the way, has anyone tried out Launch Vehicle Designer yet? Any thoughts or feedback?
  22. Arrowstar
    Can you please edit your post with a link to the MAT file so I can take a look? Thanks!
  23. Arrowstar
    Congratulations, you probably just gave me a ton more work to revamp KSP Trajectory Optimization Tool to support this lol. So alright, question: are orbits around local bodies, like Kerbin, computed w.r.t. the body's new rotation axis and equatorial plane? For example, if I tilt Kerbin and then launch due east from the equator, I will be in an equatorial orbit. Is the inclination of that orbit with your mod 0 degrees (because it's measured against Kerbin's new equator) or something else (because it's measured against the universal coordinate system)?
  24. Arrowstar
    Hey! Yes, I saw it earlier. Unfortunately it's more difficult to implement this than it might seem. See, right now KSP has every body's coordinate system exactly parallel. There is no axial tilt. Because of that, I never coded KSPTOT with that idea in mind. Basically to get it right I would have to know the spin axis of each body, compute the rotation between body coordinate systems for each SoI transition (for MA) or local orbit (for MFMS, Compute Departure, and others), and then apply that rotation... everywhere. It's not hard mathematically or anything, but it would require a pretty significant rewrite of code just about everywhere. I'll think about it, but it's not going to be something I look at soon. I'll need to dig into the mod first to see how it works. Thanks for bringing it to my attention though!
  25. Arrowstar
    Hi everyone! Good news, tonight I compiled KSPTOT v1.6.0 pre-release 4. There have a number of important changes in this pre-release from the last one, again all focused on Launch Vehicle Designer. MAJOR FIX to the steering algorithms. They now behave as expected, as far as I can tell. Before the steering laws were just very broken and didn't work right. Also, pitch and angle of attack are now positive "up" so that weird "negative is up" thing is no more. I added the astrodyanmics calculators and celestial body catalog UIs to LVD. These are identical to those in Mission Architect (in fact it's the same function call internally). I tuned the optimization algorithm a bit and I think it runs better now. Fixed some other bugs. Updated the two stage to orbit example MAT file (included in this download). Please give it a try and let me know how it works out. If you find any bugs, definitely report those here or on the github issue tracker. Thanks! Happy orbiting!
×
×
  • Create New...