Arrowstar

Ah, so, the SoI check it only performed once per coast evaluation, nominally. Of course, if you do transition SoIs on a coast, then after said transition occurs, another check is performed on the new body you're orbiting around. The SoI check is a few operations in sequence: 1) Sanity checks: is my periapsis sufficiently above the periapsis of the target body and my apoapsis sufficiently below the apoapsis of the target body that I would never intersect their SoI? (if yes, skip SoI check) 2) orbital plan check: some calculations are done with respect to the angular separation of the angular momentum vectors: small separation means the bodies are nearly co-planar and more likely to intersect, but large separation means that there are only two probable locations that an SoI transition would occur (the nodes of the orbit). It's hard to explain without showing the math, but basically, the more co-planar the orbits are, the more likely it is that the SoI check continues; 3) My new "distance between bodies at arc endpoints" check, above; and finally 4) The actual SoI check: minimize the distance between the spacecraft and the celestial body's SoI boundary. If that distance goes to 0, you've transitioned. If it remains above 0, there is no transition. There is where I use the optimizer and where things get CPU expensive. All the rest of those steps occur very, very quickly. And that's basically the gist of it.

You are correct. It only checks for the immediate children of the central body the spacecraft is orbiting around (or, we could also say, the immediate peers of the spacecraft).

Hi everyone, some good news here. While I wait for RadarManFromTheMoon to get back to me about finishing up some great improvements on KSPTOTConnect (should be done tomorrow I hope?), I've been looking at the speed at which Mission Architect runs when there are many events in the event script, say for example fifteen events. The big slow down with cases such as these is the need to search for SoI transitions. If you leave Kerbin's SoI, there's a chance you could hit Duna, or Jool, or Eve, or where ever. Even if you stay within Kerbin's SoI, you might still hit the Mun or Minmus. In each of these cases (and many others!), the spacecraft's existing orbit needs to be checked for SoI transitions, and if such a transition exists, it needs to be handled. Now, a few updates ago I implemented a system by which the SoI transition checker would only check for SoI transitions where the spacecraft was between the periapsis and apoapsis of the celestial body being checked. This was a great improvement and led to some sweet accuracy and speed improvements. However, there's another factor here that wasn't accounted for at that time: the celestial body in question may be no where near the spacecraft within that interval! In the current version of Mission Architect, SoI transition searches are run regardless of this factor, resulting in many wasted calls to an optimizer. In the upcoming version of KSP TOT and Mission Architect, I've resolved this. What I'm doing is comparing the distance between the spacecraft and the celestial body at the end points of the (small) interval where the spacecraft is between the periapsis an apoapsis. If the minimum of those distances is greater than some fraction of the celestial body's semi-major axis, the SoI check is aborted without going to the optimizer. In my tests, this results in a speed up of roughly x2. It's not the order of magnitude increase I was hoping for, but it's still pretty cool! Neat, huh?

I'm actually hoping it'll be fairly accurate once you get the correct ballistic coefficient into the equation. We'll see! Not at all. As I said, I'm just happy that people use KSP TOT enough to care about feature requests. It's kind of a small user community we have here. Thanks, I definitely appreciate the sentiment! Everyone likes to be appreciated after all.

This is basically it. More generally, it has to do with the fact that any time you change any event prior to the aerobrake maneuver, you would have to recompute the aerobrake. Want to slide add a deep space maneuver to lower delta-v somewhere? Recompute. Want to adjust your initial orbit based on what your launch vehicle actually accomplished? Recompute. And so on. I foresee something like that just getting tedious and hard to use effectively. Here's what I'm going to do. I'll work on the approximation for v1.1.8. You can test it out and we can decide if it's worth having around (that is, does it do a decent job of predicting the effects of atmospheric drag or not). If it doesn't, we'll revisit all of this. I am fairly confident that it will work, though. Btw, I really do appreciate your taking the time to lay out this idea for me. It's definitely nice to know that there are folks who are invested enough in my software that they're willing to go to bat for changes they want to see. I don't really like the idea of accepting money for KSP TOT, hence no Donate button. Give to a local charity what you would give to me if you'd like to give anything at all. And you can donate your time with the KSP TOT wiki, whenever I get around to creating that (hopefully soon, just need a Github repo with my code on it...).

Thanks for the clarification! I understand that there isn't any streaming going on between MA and KSP. In the scheme you're describing, there are only two points in time at which data is passed along, correct? This would be the point at which MA "exports" an orbit to KSPTOT via KSPTOTConnect, and the point at which KSPTOTConnect transmits the new orbit back to MA post-aerobrake. Does that sound correct? If so, it would still be infeasible I think. Consider all the time you'd have to wait for KSP to finish propagating from the exported orbit to the end of the aerobrake maneuver. Now image doing that ~10000 times during the course of a normal script optimization run. It would quickly become prohibitive. I can see doing something like this if it was just to propagate an orbit through the atmosphere one time, but unfortunately I have to use the same method to propagate during optimization as I do during the normal "single shot" propagation. Thanks for going back and forth with me on this. I admit I may not still have my head fully around your idea, so if it sounds like I'm missing something still, please point it out. And, if so, please do address my concern about mission optimization. Thanks! Unless I'm wildly off the mark with what I wrote above, I think I'll be pursuing the approximation method. Either way, it sounds like v1.1.8 is going to be the aerobraking update! Thanks. Please do let me know if they have any questions (or flat out think I'm wrong ). In other good news, I added the ability to record Mission Animator animations to .avi files this evening. I must say, it works lovely. And as this was last "feature" I wanted to get into Mission Animator, pending feedback after the v1.1.7 release, Mission Animator is feature complete! Woot!

Okay, so I took a the files you sent. In the Kerbin case, which I think was the one you're most interested in, it's not so much that MA thought you landed and took off as it is that MA just connected the final point of the first coast with the point representing the state you set afterwards. That it happened to go through the planet is a coincidence. Anyway, it looks like both you and MA did what you were supposed to do, and the visual peculiarity that you saw is just that. Let me know if that helps!

Got it! Thanks for taking the time to put together a detailed description. Unfortunately I still don't think it's feasible to pull off, mainly because of the time required to go from starting the KSP orbit propagation to ending it. The mission optimizer and related functionality has to perform a large number of function calls per second to finish in a reasonable time, and the added time to communicate with KSP and wait for a result to come back would be prohibitive. The other issues are surmountable I think, but that one isn't as far as I can tell. That said, I'm definitely game to try out a new aerobraking maneuver type (using the approximation I described earlier) for v1.1.8. I'd be happy have you test it out for me if you're up to it. Thanks, I'll take a look! Ah! So that document actually doesn't compute the longitude correctly because it assumes that inertial X is aligned with body X at t = 0. That's not the case for most KSP planets and moons. If that's what SCANSat and the others are using, then it would appear there is a flaw in their code. Okay, so try setting up your inbound orbit into Jool such that it has a RAAN of +180 degrees of what it is now. That may help. If not, try playing around with the inbound RAAN more. You should eventually be able to get Pol on the "right side" as it were. If you have a MAT file you want to upload, I'd be happy to take a look as well. The Multi-Flyby Maneuver Sequencer finds the delta-voptimal transfer orbit, not the time optimal (shortest) transfer orbit. If you want the MFMS to find a shorter maneuver, try lowering the maximum duration of the leg you want to shorten. Let me know if that helps. If not, take some screenshots and post it here so I can more specifically see what you're doing.

Another teaser. I added the ability to show the spacecraft defined in the Mission Architect "Other Spacecraft" dialog box. I think it looks pretty neat, and I'm sure you could do some interesting visual analysis with it, as well.

Okay, I understand what you're looking for. As great as it sounds, I'm not sure that trying to run MA and KSPTOTConnect next to each other would be a great idea. Trying to optimize a mission plan would be a nightmare in network lag (compared to the speed of other calculations), for example. It also just feels... clumsy, maybe that's the right word? I think it's just the idea of having to have people use KSP and KSPTOTConnect to use what's otherwise a nominally off-line only tool that bothers me. However. What you're really after is just aerobraking calculations, right? Okay. Go ahead and take a look at this document. It turned up in a bit of Googling that I did just now and describes an analytic model for approximating delta-v due to drag during an aerobraking maneuver. I would certainly be open to investigating adding something like this to Mission Architect. A few caveats: 1) Users would be required to provide the C_d * A for their spacecraft, though I could provide a small calculator for this if you try some experiments in KSP and provide the relevant data; 2) I would be modeling the delta-v due to drag as a point delta-v. Therefore the trajectory modeled would only be reasonable outside of the atmosphere. This is because the drag affects your spacecraft at all times while you're in the atmosphere, but a point delta-v only affects the spacecraft at one instant. 3) I'd have to add atmospheric scale heights to the bodies.ini file (and get KSPTOTConnect to spit it out when you ask to build a bodies.ini file from KSP itself), but that shouldn't be too much work. How would this work for you? I'm looking at moving to Github whenever it becomes feasible for MATLAB code to be hosted there. I think the upcoming version of MATLAB, R2014b, should have native Git support, and if it does (and I decide to pick up said version of MATLAB), I'll create a repo. We can add the wiki there. Can you link me to the post where the admit that? I need some context... Great! Here's another screenshot that I thought turned out nicely. Also, I'm delighted to announce that since Mission Animator is coming along so nicely, I'll (probably) be releasing an early working version (what you see here, basically) with v1.1.7 (instead of waiting until v1.1.8 and disabling it in the mean time)! Good times!

I look forward to seeing that code in action. Here's another view of what I've whipped up this afternoon with the Mission Animator. It's coming along nicely, don't you think?

Hey, no worries, the more questions the merrier! Keep them coming (it's not a bother at all). So is it possible? Yes. But is it easy? Not really, no. What you would have to do is find the plane of orbital motion (defined by its orbital angular moment vector) and then determine the great circle on the sphere of Kerbin that represents the intersection of the orbital plane and the sphere. Once you have that, you could write a function that describes the inertial position of your ground station w.r.t. time. Finally, you would find when your position function lands on the orbital plane great circle and back out the time of the crossing from there. As I said, not really easy. Now if you're just interested in when the spacecraft is above the ground station, then just look for when your latitude/longitude match the ground station lat/long and away you go. Let me know if that helps any.

Hi Gaiiden, I think I may have found the longitude issue with Kerbal Engineer. I wasn't able to find the call out for spacecraft longitude, but I was able to find it for impact longitude (whatever that is). Anyway, it shouldn't matter, because if they're not being computed the same the results would be inconsistent, and I have to believe that KER has an internally-consistent longitude calculation. So here it is: //calculate time to impact impacttime = vessel.orbit.timeToPe - timetoperiapsis(impacttheta); //calculate position vector of impact site Vector3d impactpos = radiusdirection(impacttheta); //calculate longitude of impact site in inertial reference frame double impactirflong = 180 * Math.Atan2(impactpos.x, impactpos.y) / Math.PI; double deltairflong = impactirflong - currentirflong; //get body rotation until impact double bodyrot = 360 * impacttime / vessel.mainBody.rotationPeriod; //get current longitude in body coordinates double currentlong = vessel.longitude; //finally, calculate the impact longitude in body coordinates impactlong = normangle(currentlong - deltairflong - bodyrot); Notice that the initial rotation of the body never shows up in the code. It appears the code assumes that at t=0, the body's x-axis is always aligned with inertial x. I suspect that this is the source of the discrepancy. What do you think? (Btw, the code above starts at line ~500 of FlightEningeer.cs in the KER github repo.)

Playing around with lighting and camera settings...

Well, to be honest, couldn't you just do this now? I'm not sure why I'd have to do anything special in MA in order for you to let the game run through an atmosphere and import an orbit on the other side. And there's no need to "export" an orbit if you import your current orbit in KSP in MA first. There is not. You do have to have a known set of initial conditions for the optimizer to work. There are just too many factors in the initial conditions and the odds of you ending up with an "optimal" starting condition that isn't feasible or some such thing is actually pretty good. So just take your best shot at figuring out where you'll roughly be in orbit and go from there. I actually tried sending him a link to this thread on Reddit once but I didn't get a response. I'd love it if Scott did a video on KSP TOT though, would be very cool. Feel free to suggest it to him. I actually have no idea how to do that. I'd be fine with setting one up (assuming I learn how), but I don't think I'd have the time to contribute content, to be honest...

Unfortunately, aerobraking (or aerobreaking ) is not something that could make it's way into MA. Mission Architect uses a patched conics model for its trajectory propagation and that is strictly incompatible with any kind of other force (beyond central body gravity). I suppose I could write an new KSP TOT application for it, but I have no idea how the KSP aerodynamics model works, and I'd only ever want to deal with simple drag and none of that complex lift stuff. Basically it would only be good for high altitude stuff. Eventually something like that should be possible, yes. This is a pretty complicated feature, though, so there's no telling how long the development for something like that would take. But I'll keep it in mind as I'm writing code!

It's a multi-step process: 1) Use the porkchop plotter to find a good pair of departure and arrival dates. 2) Use the Compute Departure button next to the porkchop plot to figure out (roughly) the interplanetary trajectory between Earth and Mars and the departure burn. 3) Once you know when you're leaving and which way to point the engines, fire up Mission Architect and start adding coasts and burns like this: Coast to true anomaly (whatever the burn true anomaly in Compute Departure was). Make sure you have the optimization flag checked. DV_Maneuver: enter the delta-v vector from Compute Departure. Make sure optimization flags are checked. Coast to SoI transition (no optimization) Coast to Periapsis (no optimization, and add +1 rev (you'll see why)) Now, open the Mission Optimizer up (cntl-O). Select the objective function as minimizing the distance to Mars in event 5, the coast to periapsis event. Leave the constraints empty for now. Run the optimizer and let your spacecraft smash into Mars. If you don't see your distance to Duna dropping to ~0 after a bit, stop the optimization, accept the results, and see if any of your variables are against their bounds (MA warns you on the main MA GUI if this happens). If that's the case, widen up those bounds a bit and try optimizing again. If you still can't get it, send me the MAT file (File -> Save Mission As) and I'll take a look. Sadly, it's not this easy. You can only compile MATLAB programs for the version of MATLAB you are running. In my case that's R2013a. Now, luckily for you, I'm considering going to R2014b whenever The MathWorks decides to release it (will be soon, matter of days or weeks I think). If I do, that should help you out I think. Brian, any thoughts to help him out in the mean time?

Yes, as your spacecraft jumps SoI, so does the camera view.

Yes, the graphical analysis tool can be used to do what you're asking. Final preview for the night:

And another sneak peak... if it works... EDIT: The red marker on Kerbin is the KSC. This is a visualization of a mission plan to a geostationary orbit above KSC.

Roger roger, I've replied, so let's see if it gets us anywhere.

Hi guys, Author of KSP TOT here. Can you guys show me where in the Engineer code the spacecraft latitude/longitude is computed? As Gaiiden mentioned, there are some discrepancies between my software and KER. I hesitate to change my code because I appear to match what KSP computes in the SFS file, and because I don't understand the source of the differences. Any help you could provide would be great. Thanks!

Okay, thanks for the data. I seriously don't know what to think. Can you link me to your post on the Engineer thread? I'd like to follow that. Btw, your issue with Graphical Analysis missing the first data point is now resolved and the fix will be in v1.1.7.

Yeah, it is a bit strange that everyone else more or less agrees, but no one agrees with the KSP SFS file except me... maybe it's just a different way of computing it and we're both right. Glad you like it. It'ts very incomplete at this point, but stay tuned for more updates... I'll take a look, thanks! Glad to hear it! It is indeed possible to create one. From the Main GUI, and with KSP and KSPTOTConnect running (in the Flight Scene), File -> Create New Bodies File From KSP. This will poll KSP itself for the bodies information and generate the file for you on the fly. Give it a try and let me know if you have issues. Btw, having any luck with the KSPTOTConnect net code?

Okay, thanks for the information! I guess I can poke around some. Can you try this experiment with MA and ScanSat on a few other bodies so I can get some more data points? Maybe I can pin down where the difference is. I redid the math on your initial case, btw, and my hunch was correct: the difference between KSP TOT and ScanSat is 50 + 180 = initialRotationOfMun + 180 degrees. Given how I match KSP's SFS files, this does suggest that there may be a flaw in the way ScanSat is computing the value... In other news, here's a sneak peak at what's coming in v1.1.8: Version 1.1.7 will hopefully have some contributions from RadarManFromTheMoon that improve the net code of KSPTOTConnect, so that will be released (with all the other bug fixes and enhancements) prior to my finishing and releasing this shiny new thing.