Arrowstar
-
Posts
2,561 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Everything posted by Arrowstar
-
Hi everyone: I'd like to announce the (pre-)release of KSPTOT v0.12. This is a pre-release edition. The application may be unstable, features will be missing, and no source code is included. The principle new feature in KSPTOT 0.12 is Mission Architect, which I've been showing off for a while now. The download link for this pre-release is here: KSPTOT v0.12 Pre-Release 1 I would encourage everyone interested in testing the new software to please go ahead and do so. All I ask is that if you find bugs or have feature requests, you please let me know in this thread so I can handle them. Mission Architect is accessible from the main KSPTOT GUI by going to Tools -> Mission Planning -> Mission Architect. Okay, enough of the serious talk: go at it, everyone, and let me know what you think! Also, to everyone who posted above, I will get to responding to you shortly. -
Ah. My problem isn't so much the SoI transition problem, I have that fairly well figured out. It's more the general case of "modify these delta-v locations and vectors to achieve such and such an objective subject to these constraints." How would I go about formulating an analytical gradient to a problem such as this? Cool. Mind if I send you a PM with the .m file functions?
-
Thanks! I look forward to hearing about what you think of them. As a heads up, Mission Architect is still under heavy development and has not been release yet. It's coming in v0.12. Err, what? No, KSP handles the trajectory of each spacecraft independently. So I got the optimizer viewer window set up this evening. It's pretty slick. Here's a screenshot: Barring no major bugs, I suspect the only thing between me and an initial pre-release is some more investigation into why the code runs as slowly as it does in some places. I suspect it has to do with finding SoI transitions downward in the celestial body hierarchy (Sun -> planets, planet -> moons). In any event, this calls for some SCIENCE (and a profiler)!
-
It's a computational simplification they made. Maybe not the most accurate, but it's good for 99% of all cases. Thanks guys, this is what PMs are for.
-
KSP TOT is using a two-body model of gravitation. In Mission Architect, that model is exactly the same as Kerbal Space Program's model, including SoI radii. In every other function, local gravity fields around a central body (such as Kerbin around the Sun) are assumed to be "small", by which I mean to say "can be approximated as infinitesimal." In neither case am I using N-body gravity, the purpose of the tool being to model orbits in KSP. The KSP TOT solutions are a near approximation of the motion with mathematical simplifications included to ease calculations and CPU run time. They are correct enough for most mission/maneuver planning purposes. If a third body shows up, it only becomes relevant if it's part of the problem. That is, if it's a destination or departure point, it's included in the calculations. If it's not, them it's ignored, and rightly so. Does that answer the question? Also, billeinstein and diomedea, while I appreciate the conversation, let's make sure we stay on topic here, please. EDIT: And here's a nice image of the optimizer observer mock up I put together tonight:
-
Diomedea, could you repeat your question? I can try answering it then.
-
Oh, apologies for the confusion. No, Mission Architect uses the same SoI radii that KSP uses. There was a bug in the way the intersects were being calculated (particularly when the s/c orbit was hyperbolic), and I fixed that. It's the rest of KSPTOT that uses the infinitesimal SoI radius assumption. I should note, for the record, that this idea of a zero-sized SoI is not my own idea. It's how orbital mechanics is taught in classrooms, and for good reason. Dealing with spheres of influence is a royal pain in the neck. Not worrying about them simplifies your problem, and the math/logic behind your problem, considerably.
-
I made some good progress today on the Mission Architect tool. I managed to squash a (serious) bug that was preventing some SoI transitions to be found. I stumbled across it while planning a direct Kerbin-Ike misson. In any event, everything works great now. I also have plans for additional speed improvements across the MA application in general. It involves a bit of rework with the way data is stored, but the code should be much faster afterwards. My goal for tomorrow is to get this speed improvement implemented (the current data storage technique is pretty slow guys). After that, I'll get the GUI for the Optimizer progress page (let's you watch the mission optimizer work) going. Hopefully will finish this last item this weekend. Might be ready for a test pre-release next week. Here's a nice picture of my trip to Ike:
-
Thanks! Let me know if I can help with any questions.
-
Would need to look at the time break down, but MATLAB is doing the gradients in parallel. MATLAB is doing finite differencing; there is no analytical gradient for this problem. Optimization variables for this run is a true anomaly for departure burn and the right ascension, declination, and magnitude of the burn (better than three rectilinear components for optimization). I agree that I probably just screwed it up somewhere. I vectorized the functions that convert to and from Keplerian orbital elements to position/velocity vectors. These are fairly complex functions with a fair bit of logic in them, plenty of room for error. If you'd like to take a look, shoot me a PM and I'll send you what I've got.
-
Okay, so, KSP and KSP TOT both work off two fundamental principles of motion: the two body gravity assumption and the patched conics approximation. The former says that only one planet/moon can affect your spacecraft at a time, and the latter dictates how you move between the influence of gravity sources. So far so good. Where KSP TOT differs from KSP is that the I'm using a patched conics approximation in which the sphere of influence has radius of zero. That is, the SoI size is always assumed to be small as compared to the next largest SoI up the celestial body hierarchy. In the real world, this is actually an okay assumption. But in KSP, where the game is scaled, some of the differences do start to show through, as you've found. So what about the solutions KSP TOT gives you? They're excellent for the zero-sized SoI problem. For the KSP simulation, the non-zero SoI size problem, they are good approximations. However, as you've found, you will have to adjust the solution to find the real solution. It's not too hard, so I'm not too concerned with people needing to do this. Luckily, Mission Architect does not have this same zero-sized SoI limitation: I'm building it from the ground up to act just like KSP. So far it's worked well, and the solutions you get from the maneuver planning codes in KSP TOT will make good first guesses for maneuvers in Mission Architect, just like they are good first guesses in KSP proper. Hope that helps. On that front, I didn't get all that much accomplished today in MA. I had hoped to vectorize a lot of my math... and I did. But it turns out that the overhead from doing that was actually worse than just running the for-loops I was avoiding with compiled code. Also, the resulting vectorized code was horrible. Though it worked, it was not elegant in any way, shape, or form. I'm happy that I'm ultimately abandoning that approach, because it wasn't pretty to work with or maintain. So I'm stuck at about 6.2 seconds per optimization iteration, and the average mission optimization seems to be about 15-20 iterations. Call it about two minutes per optimization. This'll have to do for now, though there is some additional disk read/write that I'm going to try to eliminate in the future, and that will help some. Tomorrow's tasks are to fix up a few bugs with the Mission Optimizer window and get started on the Optimizer display. This latter feature will show, in real time, the result of the optimization and will hopefully let users cancel it cleanly if needed. Hope that sounds good.
-
Kurt, I'm in the middle of running to work, and your question has a bit of a long answer, so I'll get to it tonight. Anyway, quick update on the Mission Architect development. Yesterday I finished up the major part of the Optimizer GUI and integrated it with the rest of Mission Architect. Using it, I was able to plan a mission from low Kerbin orbit to low Duna orbit, directly inserting into a 100x100x3 deg inclination orbit using only two burns. This is similar to what I showed before, the difference being that the optimizer code is now running in MA and not in a stand alone script. Anyway, the take away here is that Mission Architect works! Unfortunately, it works kinda slowly. The various optimizer runs take about 4 minutes for ten iterations of the optimizer, and you could see anywhere from 10-50 iterations per optimization run. Given that, yesterday I spent a long time optimizing code and pursuing means to get things running faster. Right now I'm vectorizing the code that coverts between orbital elements position/velocity. This means that, ultimately, I will be able to remove the for loop I've got in the main propagator ("go to this time step, then this, then this") and just pass in a vector of time steps in one command and I'll get out all the orbits in one command. This should greatly increase run time speed. Other ideas I'm pursuing are parallelization of the optimizer code (very easy as MATLAB can do this for you), and experiments show a 2-fold decrease in run time when computing objection function gradients in parallel; and compiling some basic MATLAB code into MEX files that execute at about 100 times the speed of the function they replace. Unfortunately, you can only compile a subset of MATLAB functions into MEX files, so you have to pick what you pull out for compilation carefully. My goal is to get optimization down to 3 seconds per iteration on average. Right now, best I've ever seen is 6.4 seconds per iteration, but that's without massive parallelization. I think once I couple those two with whatever compiling I can pull off, I will make it, easy. In any event, progress has been made and things are happening, but the past few days have been more about putting the pieces together and making sure they work well than developing new features, hence there being nothing to share. Oh, nice side effect of all this optimization: since the code I'm working on is low level stuff used everywhere in TOT, all tools/functions should see an increase in speed. Yay!
-
You will be able to set a constraint on the minimum/maximum distance to target that the optimizer should hit. The whole optimization process is likely going to be a three part thing the user will have to do: minimize the distance to target unconstrained, just to get in the SoI; minimize distance to target, but constrain the radius; and then minimize fuel usage. The first two are needed to direct the optimizer towards the correct solution. Once you are close, then constrain the optimizer more (with orbital parameters and the like) and tell it to minimize fuel usage. This "walking in" of the solution will likely be necessary for complex missions, and it's also what we do in the "real world". Cool, I'll keep doing them. The strategy is whatever you design it to be. In my picture, the inclination is actually targeted all the way from Kerbin. I know it doesn't look like it, but the final maneuver is really just a circularization burn (set SMA = desired, ecc = 0). No inclination was changed in the Duna SoI at all. If you want to change the inclination more, you can set constraints on the final orbit to have a high apogee and low perigee. Then go ahead and place a maneuver at apogee to do the inclination change, and add it to the things that the optimizer solves for. Should work out well enough. Does that answer your questions?
-
So good news. Tonight I got the optimizer code mostly working. It's not hooked up to the GUI yet, but I've got it running nicely in an external script. I developed a new objective function that really helped a lot. Instead of minimizing fuel usage, it attempts to minimize the distance to a particular target body. This works great if you seed it with a good initial guess (which will basically be a requirement for Mission Architect). Where do those "initial guesses" come from? Well, luckily, the rest of KSP TOT has an entire suite of analysis tools designed to find optimum maneuvers! So what I did was find a Kerbin-Duna window using the KSP TOT porkchop plot, plug that burn into Mission Architect, add a coast to Duna SoI, and a circularization burn. Then Mission Architect modified the coast to the burn true anomaly and the departure burn vector and got this: Look at the final spacecraft state there. I was aiming for a ~100 km altitude circular, equatorial orbit. It did pretty well. What do you guys think?
-
This is very much how things are already working. I only have four different types of events: coasting, dv maneuver, set state, and mass dump, each with their own set of multiple implementations that all work the same way. The last one is what you're talking about: it gives the analyst the ability to add/subtract mass from the current stage. Typically you'd use it when staging or when accounting for contingency prop you might want to take along, but there's no reason why you couldn't enter in negative values to "subtract" and make the s/c heavier. This is allowed.
-
So yes, that information exists. But honestly, it's not very good at estimating the delta-v needed to insert into orbit, as what it's actually measuring is delta-v needed to stop at the planet, just outside it's SoI. It's how you enter orbit is critical and will dictate the amount of delta-v needed for the mission. That all said, the porkchop plot can be made to optimize on arrival+departure C3 energy, which is more along the lines of what you're talking about. See the options on the main GUI menu bar for more details. Let me know if you have any questions, I'm having to type this real fast this morning, so not a lot of time for detailed explanation.
-
In a manner of speaking, yes. Perhaps not the soonest departure, but definitely the fastest transfer. If you specify propulsion residual constraints (that is, how much prop you have left over), you can force it to keep some fuel in reserve, as well. Is this what you meant? Update on MA progress. Tonight I have a standalone script running a very basic optimization on a simple Kerbin/Mun transfer. Actually, we can hardly call it an optimization. All I'm doing is asking the optimizer to find is the delta-v of a vector that, in an unconstrained fashion, minimizes mass usage. Without constraints, it should result in a 0 m/s delta-v burn. Still working out quirks in the system, but everything looks good so far!
-
Hi everyone, Here's what I've been up tonight. The basic mission plan display/edit/propagate is effectively complete. Thus, tonight I started on the other major functionality of KSP TOT Mission Architect: the optimizer. Thus, I present the Mission Optimizer: So here's the basic idea. It's easy to put together a mission script, but harder to get it to do what you want. For example, say you want to go to the Mun. You can either muck around with delta-v vectors and true anomaly of the burn, or you can tell Mission Optimizer "hey, I'd like to go to the Mun" and, if you word the question correctly, it should figure it out. Looking at the GUI, it's three parts from left to right. The first is the objective function. This is the "what are you trying to achieve" part. Most of the time, we'd like to maximize spacecraft mass (thus saving fuel), minimize transfer duration, or similar things. These two objectives I've listed here will probably be the only two that come with Mission Architect initially. All objective functions are evaluated at the end of the event you specify for them. Below the Objective are the Variables. If "Objective" is the what, then "Variables" are the how. These tell the optimizer what to vary (hence the name, variables ) in order to achieve the objective. Here the Mission Optimizer, events in the mission script are varied. This could be the target true anomaly of a coast, the delta-v vector of a burn, or both. Finally, on the right we have constraints. Constraints allow for you to make sure the optimizer doesn't do things you want it to avoid, or find solutions which are mathematically possible but not physically realizable. Like objective functions, constraints are evaluated after the event that goes along with them. Savvy planners will use the optimizer in stages to achieve various stages of the mission sequentially. Trying to setup everything at once will be a hassle and the optimization code will probably not like it either. Want to fly by the moon to get to Duna? Set up the Mun flyby first, then target Duna, and so on. As a note, this is just the GUI design. I'm going to start the actual optimization code tomorrow, though that may just be architecture and the like. There will be separate structures for the objective function, variables, and constraints, all of which need to be worked out in a manner that allows all of them to work together nicely. Oh dear. So how does that all sound?
-
Tavert: Okay, no worries. Feel free to try with a different version of MATLAB if you think that would help. If not, then don't worry about it. Thank you for trying! My "injection burn" do you mean the "insertion burn"? That is, the burn needed to stop at a particular planet/moon? Afraid I can't help there, it's not calculated because the insertion orbit isn't calculated. There's a long reason why not, but basically it comes down to too many unknowns in the math to get it working correctly. As an alternative, I would suggest getting your ejection burn set up, then make some assumptions on what you think your hyperbolic arrival orbit will look like at your destination. Then, go to the Optimal 2-Burn Orbit Change application, plug that in as the starting orbit, and plug in your desired final orbit. Do some studies and see what you get for delta-v. Let me know if that helps or not.
-
Thanks! Yep, Mission Architect should be quite good at what you just described. Totally. The other applications in KSP TOT, an option exists to "Upload a Maneuver" to KSP directly, if you have the KSPTOTConnect plugin running with KSP. This will create a maneuver node in the game. Just have MechJeb execute the node you create via upload. Viola. (Right-click on any text box with maneuver/burn information and click "Upload Maneuver" or some such thing to actually do this.) Made some good progress last night. Mission Architect is now capable of adding/editing/removing events from the mission list and propagating through them all. The output window is mostly working and plotting has been improved a bit. Next up will be the optimizer, followed by general 2D plotting of useful quantities w.r.t. time (mass, orbital elements, etc). We might be go for a pre-release after that gets done (maybe by the end of this weekend - we'll see). There will be bugs, to be sure, best way to squash them is to give this to others and let them have at it. I got a few PMs over the last two days - if you're still waiting to hear back from me, I'll get back to you tonight.
-
Hey everyone! Tonight I want to share what I've been working on for the last week. It's really bugged me for a while now that, while KSP TOT has lots of great features and algorithms, none of those things really talk together. Thus, to date, KSP TOT is a great maneuver planner, but what it's not is a great mission planner. This goes beyond just the basic engine burns; considerations such as propellant margins and mission duration are also important for the KSP (and real life) mission designer. When I started KSP TOT awhile ago, I set out of offer the premier KSP mission design software available from anyway. On the whole, it's been a resounding success. But as I noted above, it can go farther. Thus, tonight I present what I'm calling the KSP TOT Mission Architect. Mission Architect is designed to be a full-up mission planning suite that leverages all the other tools KSP TOT makes available. It will allow the KSP mission planner to see the full scope of the mission they will execute, from initial parking orbit to final destination. A few features to point out: On the left of the window, above, is the mission event list. The mission event list includes all the events that Mission Architect will propagate through. Events include coasts (propagating without engines running), maneuvers (adding delta-v), and mass dumps/staging. As the event list is updated, Mission Architect automatically recomputes the impact of the changes on the mission. To add events, simple select the event type from the drop down box. A window will appear, prompting for details of the event. Provide them and the event is added to the list. To edit an event, just double-click the entry mission event list. It's quite slick. Next to the mission event list is the state summary. The initial and final states and shown, and viewing state summaries at other points in the mission will be possible, too. In addition, a full reporting and graphing suite will be available. Finally, on the right is the orbit view. This segment works like the rest of KSP TOT, but as orbits here can extent over multiple bodies and spheres of influence, some additional GUI work was needed (read: arrow buttons) so users can flip between them all. Some other features that I haven't started yet, but plan to include: 1) Auto Lambert targeting of orbits; 2) Optimizer integration for meeting mission objective and satisfying mission constraints; and 3) Some nice plotting and reporting tools. From above, here's an example of what the Insert Coast dialog box looks like: Most of the past week was spent designing and implementing a super flexible scheme for propagating through events of all types, be they coasts, dv maneuvers, or whatever. Friday and today I implemented the GUI as you see it. I'm hoping to have a good chunk of it done by the end of the weekend. Mission Architect will be the primary release feature of KSP TOT v0.12. Right, so, questions/comments? I'm eager to know what you all think of Mission Architect. I think it's going to be pretty nifty, and I'm looking forward to giving it to the larger KSP community soon!
- 4,944 replies
-
- 1
-
-
- ksptot
- mission planning
- (and 3 more)
-
[1.2.0] Precise Node 1.2.4 - Precisely edit your maneuver nodes
Arrowstar replied to blizzy78's topic in KSP1 Mod Releases
It'd be pretty cool to have a porkchop plot in KSP directly. However, regex, if you're going to go down the rabbit hole of trying to get maneuver nodes from your porkchop plot, please be aware that this is a non-trivial task. KSP TOT is capable of something similar, but it did take me a long time to figure out, something on the order of a month or so. I don't want to discourage you (I think it's a neat idea), but you should be aware of what you're getting into before you start. -
Hi! I've considered implementing DSM code, but decided against it because in most cases the ballistic trajectories TOT already gives you are good enough (in short, not enough unique utility). Thanks for the suggestion, though! (Though I should point out that if you would like to PM me with a link to some working DSM maneuver code, I'll certainly take a look again.)
-
Thanks! I really do like hearing that people enjoy using something that I've poured hundreds of hours into over the past year. Makes me all warm and fuzzy inside. At the moment, I don't actually have this math in KSP TOT. Not that I couldn't (there an analytical solution if you know how to set it up properly), but no one's ever asked before. I would use the rendezvous planner, target the Mun, and then in KSP, change the delta-v just a bit using a maneuver node editor plugin (in prograde direction and time) until you get what you want. The fly by maneuver sequencer should be able to help with this. Give it a go and let me know what questions you have. I'm running to work at the moment; I'll investigate tonight. Remind me if I don't get back to you by tomorrow.
-
Great! Let me know how it goes.
