Arrowstar

Members
  • Content count

    1,617
  • Joined

  • Last visited

Community Reputation

533 Excellent

1 Follower

About Arrowstar

  • Rank
    Astrodynamicist

Recent Profile Visitors

1,916 profile views
  1. @Kobymaru: The inclination is most likely the problem, yes. I know why they add it, but I wish they wouldn't... it causes issues like what you discovered. The only solution is to create the RSS bodies file like normal and then manually edit the inclinations to be more reasonable in the file. There's nothing much KSPTOT can do for it. I know it's a pain, I'm sorry. 1) Yes, that is expected behavior. When KSPTOT detects that a long Go To UT/DT coast is executing, and the orbit is eccentric, the code automatically splits out each orbit period into its own sub-coast. This is mostly done for graphical purposes (for example, if you go around 100 revs and use 100 states per coast, you would only get one point per rev, so the spacecraft would not appear to be moving). 2) Thanks for the report! I fixed it. Silly typos. In other news, I have an update on the new atmospheric model. I implemented the paper I noted above from U of Texas and it works quite nicely. Here's a someone eccentric orbit running with the orbit decay option on in Mission Architect: Green lines are perigee passes and blue lines are apogee passes. As expected, the spacecraft loses most of its apogee altitude at perigee, when the atmosphere is densest. Also note that perigee doesn't drop much at all, which I would expect too. Fun story, by the way: I was looking at this a few days ago and got stuck on a case where a very high eccentricity broke the algorithm. I ended up grabbing a fellow engineer at work over a break and we deconstructed what the UT author did, figured out they made a "nearly circular orbit" assumption in their math that they didn't mention in the paper, and re-worked the differential equations to eliminate the problem and to be more general. I really do like my job lol. (I did some testing on the raw algorithm yesterday on some cubesat data I found online and it compares reasonably well, so I'm much more confident in this model than the other one that's currently in the Orbit Decay mod.) Anyway, this new algorithm, correction and all, is in the next pre-release, here: KSPTOT v1.5.11 pre-release 4. This build also includes the fix mentioned above. Please give it a spin, all, and let me know if you find any bugs.
  2. The equivalent MA setting is going to be based on the length of the coast. The KSP timewarp is in unites of seconds per second, so if you're running at 30 fps at 1x, you'll get a step (and call to the Orbit Decay mod) every 1/30 seconds. The equivalent setting in MA would be to take the duration of the coast and divide by the number of state log entries. Match the times by varying the number of state log entries and plug in that number into the setting in MA. That all said, I would check to see if you really see any sort of difference between MA (under the new, to be implemented algorithm) and KSP first before you go through the effort. If it's small, I might not bother, since the effort involved in getting the two in sync may be non-trivial. Anyway, no worries about your trip and whatnot, all this will still be waiting for you when you return.
  3. Thanks for the testing! It looks like it's close anyway. However: After I posted that build you tested on, I actually found a better algorithm for analytical atmospheric drag. This one models the change in semi-major axis, the change in eccentricity, and the change in argument of periapsis. I have it implemented in a test script so that I could compare against ISS real world performance and it does reasonably well there given the assumptions I'm making. What this means is that I'm going to be completely removing the code that I just put in (lol) and calling this new algorithm instead. The only other change will be that this new algorithm can't be called in a vectorized fashion, so there will be a slight decrease in coast time calculation performance. Testing shows that it's on the order of a few milliseconds per 1000 state log entries, so I'm not too worried. Stand by until Wednesday or (more likely) Thursday and I'll have that implemented for more testing by you. Your area calculations sound like they're in the ballpark of reasonable, so I'd just stay with what you have there for now. Oh, a note about how the time warp stuff works in the mod (and in MA for smaller number of points per state log): the algorithm computes a change in SMA (and eccentricity and argument of perigee) per unit time. Both the mod and I then compute the total change of the quantity by multiplying by the simulation time step. The smaller the time step, the more actually the model. You'll see things get wonky at high warps in game and low number of state log entries per coast in MA. @Papa_Joe: Take a look at this paper (http://farside.ph.utexas.edu/teaching/celestial/Celestialhtml/node94.html) for how I'm doing the drag effects, particularly equations 10.148, 10.150, and 10.151 (I still need to figure out how 10.149 works and if I need it). These looks like they're a better model than what WhiteCat was doing originally. If you have the time, I'd suggest giving this implementation a go in the mod. I'll have my MATLAB code updated on Github in a few days with my implementation and you could use that as a template/pseudo-code. It's very straight forward.
  4. You know me too well, lol. Anyway, I have an initial implementation of an atmospheric orbit decay model more or less done. To use it, you just create a new coast, check the "Use" box in the Orbit Decay panel, and then put in the correct spacecraft and environments parameters. Some caveats: Like OrbitDecay mod, I'm not messing with the eccentricity of the orbit (yet). I gave it a go, and I know the general trend, but boy it's hard to come up with an analytical model for eccentricity change that can be vectorized to run fast. Well, a simple one anyway. There are lots of models out there but they're all stupid complicated. What this means is that, while the orbits should circularize over time, right now they don't. The unperturbed eccentricity is also the decayed eccentricity. I'm not using the same SMA change formulation that OrbitDecay is. I'm not super happy with how it was implemented there, mostly because (as I stated before), I think it's mostly bunk. Therefore, what I have implemented may not match what is in the mod... and therefore results may be different. Hard to say without really studying the problem. The density assumptions in Orbit Decay mod don't really make sense, so I implemented my own exponential decay model for atmo density above the stock atmosphere altitude. Yet again another thing that won't perfectly match the model in the mod. I've tested it as well as I can but right now things are liable to break in all sorts of unforseen ways. Would definitely appreciate some testing by others. And now, some results: Finally, here's the pre-release with the new build that includes all of this (as well as auto population of Other Spacecraft names): KSPTOT v1.5.11 pre-release 3. Please test and let me know how it all works!
  5. Hey, so I had a look at the OrbitalDecay mod code today and took a shot at writing my own implementation of the atmospheric decay algorithm. The good news is that I get numbers. The bad news is that I'm pretty skeptical that what WhiteCat implemented is even remotely realistic. I found the paper he used and it basically looks like he pulled some equations, put them in C#, and called it a day. Everything in the paper he used was Earth relative and it doesn't seem to make a lot of sense when I think about making things generic across any body. I'm going to keep thinking about it, but it may result in me having to implement the code in a different way then he did to keep things planet-agnostic. If you're interested, here's the paper he used: http://www.sws.bom.gov.au/Category/Educational/Space Weather/Space Weather Effects/SatelliteOrbitalDecayCalculations.pdf
  6. I closed it because it was old and I suppose I forgot about it lol... pretty sure it's do-able, I should be able to get it in in the next few days.
  7. It shouldn't be that hard to add, just wanted to make sure it was still a desired feature.
  8. Hey, you still need/want that atmospheric orbital decay model, right, @Drew Kerman?
  9. Oh, so I just forgot to update the post about that. At the last second, after doing some more testing, I decided that 2 was better because it really seemed to improve the odds of finding the SoI transition, but didn't cost that much more time. So I left it at 2 instead of 1. Anyway, I believe I found the bug in mission animator it was plotting the orbit from one part of the state log, but at the boundary between two SoIs, grabbing the wrong spacecraft position. I have adjusted the code to correct this. I updated the v1.5.11 pre-release 2 ZIP file with the build that has the fix in it. Please test at your convenience.
  10. Alright, want to know what the problem was? This is a plot of the distance of your spacecraft to the Mun SoI over time (horizontal axis is universal time, vertical is distance to SoI). See all those local minima (the bottoms of the valleys)? The SoI transition code was getting stuck in one of them, namely the middle valley. Because that valley is nowhere near the SoI, it was rejecting the whole solution. Luckily, I have a solution. I have added an option to the Mission Architect script execution settings called "Number of SoI Transition Search Attempts" (Settings -> Execution Settings -> Set Num. SoI Search Attempts). Here's what this does. See the plot above? That's a portion of one rev that the code pre-computes in such a way that, if the Mun was going to be intersecting your spacecraft orbit, it would be somewhere in there. We see that it is, in fact. There's margin on those bounds, though, so that nothing gets missed, and for fast periods, like the Mun and your spacecraft here, you will probably get a few local minima. The new setting divides that plot up into a number of equally-sized slices and then attempts to find an SoI transition in each slice, from left to right. The number you provide dictates the number of slices. So, if you say 1 (which is the default), the behavior is unchanged from before. If you say 2, then the first half of that plot gets searched, and then the second half gets searched (so long as an SoI transition was not found in the first half). If you say 10, then the first tenth gets searched, and then so on... Now, one caveat. This will definitely improve search functionality in cases where the solver was running into bad local minima. However, it also involves calling that solver more times, which means that setting this new setting to a number greater than 1 will slow down execution speed. Setting it to the maximum of 100 will probably slow down run time by a factor of at least 10x-20x. Anyway, this new function solves the issue you were seeing. It, as well as the fix for the line of sight issue you reported, are in a new pre-release: KSPTOT v1.5.11 pre-release 2. Please test these fixes out and see if they help! Thanks. (I will take a look at the mission animator stuff you mentioned later!)
  11. So... I did what you instructed and here's what I ended up with: Here's a link to the MAT file shown above so you can take a look and tell me what I did wrong lol. Once we get this sorted I'll compile the next pre-release and you can test out the fix(es).
  12. Okay, maybe I just need some clarification as to when you're restarting MA or creating a new mission plan or reloading the mission plan file or whatnot. That was not clear to me when going through the instructions.
  13. Oh, also, for those interested, I finally figured out how to actually use git and updated the repo tonight for the first time in 3 years lol. New source code is here: https://github.com/Arrowstar/ksptot This is just KSPTOT. KSPTOTConnect is not included there yet.