Jump to content

Arrowstar

Members
 View Profile  See their activity

  • Posts

    2,560

  • Joined

  • Last visited

 Content Type 

Everything posted by Arrowstar

  1. Arrowstar
    I have another neat feature that I was able to squeak into KSPTOT Mission Architect today and I would like to discuss tonight. This new feature is called "Coast to Function Value" and it allows you to do some crazy things. In essence, it allows you to determine when a particular function (we'll get to this) has a particular value and then coast to that time. The functions that are available is basically anything that is available in Graphical Analysis. In fact, a part of the work I did today was to set up for merging all the data providers in Mission Architect so that I can reference them outside of just Graphical Analysis. More on that in a future post. In the example below, I wanted to coast my spacecraft to the relative node between my spacecraft and this other spacecraft. You can do this by coasting to where the relative crosstrack position between the two spacecraft is 0.0 km. To do this, we create a new Coast event. Notice on the left box, in the Coast to Function Value Parameter area, how the function is set to Relative Pos. of Ref. Spacecraft (Crosstrack), and the Function value is set to 0.0 km. The Ref. Spacecraft is Test Spacecraft, which is shown by the black dotted line. Notice how my spacecraft's red line goes right up to the black dotted line, and then stops. So the way this works is that I essentially use a root finder to look for the point where the function value matches the desired value. There's a maximum propagation time that the solver searches up to. The code uses a series of Coast to Delta Time events internally to do the search. If the solver can't find the find the desired value, it will propagate to the maximum propagation time and throw a warning. In the past, if you wanted to do this, you would have had to use the optimizer and hope it could find something. Now, no more! The only Graphical Analysis task/function that can't be coasted to is the Distance Traveled function, because there is some funniness with the way that's computed. But everything else works. The next revision I want to do is to update the constraints in the optimizer to use the same data providers that Graphical Analysis uses, too. We'll see how much work that takes, but should be possible. So what do you guys think of all this? Pretty neat, huh? I'm happy with how it turned out so far.
  2. Arrowstar
    Yet another "I'll just leave this here" post.
  3. Arrowstar
    See the edit to my post for what's going on.
  4. Arrowstar
    Can you check to make sure the mission file you gave me for the first problem is correct? I don't see any issues when I look at the plot. What UT does the issue occur at (not MET)? EDIT: Nevermind, I see it. It's a data resolution thing. The second point you have a data point at is the periapsis. So the altitude is "jumping" because you're starting to swing around the planet and the graphing just doesn't have enough resolution there. Add in more points per coast in Script -> Execution Settings if you need more resolution. I missed something when I created the pre-release. This is a bug I'll fix very soon. Thanks for pointing it out! EDIT: Issue resolved for next release.
  5. Arrowstar
    What event terminates at the start of that jump?
  6. Arrowstar
    Hi everyone! Good news! I have a new pre-release of 1.5.7 for people to play around with and take a look at. Here's the feature set, all of which are in Mission Architect: Includes the updated RIC components for relative spacecraft position. These show up in the optimizer and Graphical Analysis. Includes the new launch trajectory estimation tool within the Set State event. Includes the ability to optimize your "Set State" events directly from within the Mission Optimizer. This includes in the Set State Directly (the old Set State stuff) and the new Launch Estimator parameters. A handful of other very minor fixes/things. One bad point: this pre-release is extremely hot off the press. I think I've got everything more-or-less tested, but it would be great if people could take a look and see if it's doing anything noticeably stupid or wrong anywhere. I literally just wrote the optimizer stuff for the normal Set State parameters a few hours ago... There will be one more feature pre-release before v1.5.7 drops officially. The goal of that will be to introduce some new "landing" functionality that I've wanted to get into Mission Architect for some time. These features are really twofold and include: A new "Landing" event. This is going to be fairly simplistic and just fix your spacecraft to the body frame of your central body, at whatever latitude, longitude, and altitude you call it at, for a user-specified period of time. This is a good place to use the new "launch" stuff afterwards! Two new graphical analysis tasks and optimizer constraints: vertical speed and horizontal speed. These will be available for general use, but I'm envisioning using them mostly for setting up landing burns with the normal finite duration delta-v events. One question: would there be interest in me building a feature to display a translucent atmosphere sphere around the central body in the Mission Architect display window on the right if the user selects the option to do so? Or would that be useless? Let me know! Anyways, what do you all think of all this?
  7. Arrowstar
    Okay, so you can actually do this now without having to optimize the initial state. Say you want to go to Duna from Kerbin: Use the porkchop plot and Compute Departure button to find the basic departure plan. On the Compute Departure window, find the top textbox that shows the outbound hyperbolic orbit. Locate the hyperbolic excess velocity vector components in that box, as well as the magnitude. In Mission Architect, set up a new mission and use whatever initial orbit you want. Add coast and DV maneuver. Optimize the coast and DV maneuver with no objective function (satisfy constraints only) and set four constraints, one for each of the excessive velocity vector components you grabbed in step (2) plus the magnitude. Push Optimize. Go through the normal "target a body to land on" sequence from here. You can get your hyperbolic departure orbit from after step (6), so basically the parking orbit is only fictitious if you don't want to use it. Launching into that hyperbolic orbit is up to you, though, MA can't do that for you.
  8. Arrowstar
    I'm not entirely sure what you're asking, but I think... Yes? :-)
  9. Arrowstar
    So just as a warning, this only injects you into a circular parking orbit. The math for anything else is beyond the scope of what I'm trying to achieve here, and I would like to keep it simple for users. Most people inject into circular parking orbits anyway, so it's applicable in many cases. And if it's not, then you can set the state directly. I am working on setting up optimization variables for the "set state directly" part of the UI. Should have a pre-release version with all this to play with by the end of this weekend.
  10. Arrowstar
    Correct. The trajectory it provides is reasonably realistic but it is only an approximation. If you have a rocket that you know something about, you can use that knowledge along with information about launch site and desired altitude to see roughly what your rocket might do, and more importantly what kind of orbit you might end up in. It's just another way to get a mission started without having to know exactly what orbit you'll be in once you get to space. This helps you figure that out.
  11. Arrowstar
    It is! I'll have a pre-release out at some point soon and you can try it out then. ---------------------------------------------------------------------------------- And I'll just leave this here.... The next version is getting another cool feature.
  12. Arrowstar
    You can certainly try it in full screen mode! Let me know what you find. :-) I've had issues in the past is all, but that was a long time ago.
  13. Arrowstar
    The epoch is whatever is specified by the mod designer. It doesn't matter too much, KSPTOT can figure out celestial body positions before and after any epoch. :-)
  14. Arrowstar
    I have a couple small new features I want to share with the KSPTOT user community tonight. The first is that I've completely revamped the way spacecraft relative motion is computed in KSPTOT Mission Architect. Previously I used what's called a recti-linear coordinate system when computing the prograde/normal/radial components of the position of the Reference Spacecraft relative to your spacecraft. This means that, for example, a reference spacecraft in the same circular orbit but 10 degrees behind would appear to be located in a position which was negative in both "prograde" and "radial" positions. When you think about it, this makes no sense: the reference spacecraft is really along the prograde direction, it's just behind a bit. My solution to this is to completely redevelop the way these coordinates are presented. First, they've been renamed to a more industry-standard "radial/in-track/cross-track". In-track is like prograde and cross-track is like normal, as a conversion. Second, I now use a curve-linear coordinate system (that I'm proud to say I developed myself after I found no one else had a textbook chapter or research paper devoted to the subject) to present these quantities. This means that, for example, you can now show charts like this using Graphical Analysis: The Station is located at 0,0 in this plot, and the orange trace is my spacecraft. I approach from below and behind, pop up from in front to trend backwards, and then ultimately approach from the top (where the presumed docking port is). These variables are available in the Mission Optimizer so you can optimize on them as well. In addition, there is an "inverse" plot available where your spacecraft is the center of the plot and the reference spacecraft moves around it. But I like this version, personally: it shows the motion of my spacecraft better in my opinion. The MAT file that produced this plot will be a new Mission Architect example in the next release. Next, a smaller announcement. Mission Architect will now have a new event type called "Docking." This is very simple: all it does is set your spacecraft position and velocity (and central body) to that of the selected Other Spacecraft for the set period of time that you denote. After that period of time, other propagate and maneuver events can then modify the orbit as usual. You can see the docking event in use below. The idea is that you could use the new data types I showed above to get close to the station (and in my example, I get to within 10 meters), and then use the Docking event to fix your position at the station to simulate being docked there. "Undocking" occurs after the event. This new event type is compatible with all existing Other Spacecraft in existing MAT files you might have and also allows you to still consume or convert resources just as you would with a standard coast. And there we are, that's all! Thoughts?
  15. Arrowstar
    Thanks for the heads up, I agree. Resolved for next release (it was an easy fix).
  16. Arrowstar
    Alright, let me know if this pre-release resolves the issue. Perfect! Glad to hear it!
  17. Arrowstar
    Okay, the issue is that you are targeting the departure without giving KSPTOT any information about the orbit epoch and mean anomaly. These are in that compute departure screen. If you provide them, KSPTOT can adjust the departure accordingly. What this means is that KSPTOT is just using the optimal departure time without full info about your orbit. So of course you're going in an unexpected direction, KSPTOT doesn't know where you are! :-) Fill in those two fields accurately and try again. It should be better. Keep in mind that you'll only get full accuracy of you plan the maneuvers in Mission Architect. All of the other interplanetary maneuver planning tools are approximate only. :-)
  18. Arrowstar
    Can I see some screenshots of KSPTOT inputs and outputs? I'll take a look and see what the issue is. I'm not sure about the year and day thing in MJ, because I haven't used MJ in a long time. I suspect that it still is. The moving the burn time before or after Pe is still applicable if you don't use Mission Architect to further refine your mission plan. Glad to hear you got it fixed!
  19. Arrowstar
    The issue is that you don't have a body called "Sun" in the bodies.ini file. If you do a find/replace of "Ciro" for "Sun" and then restart KSPTOT and reload the file, it should work. This is a requirement of the software. There's a note in the header of the bodies.ini file that comes with KSPTOT that reads:
  20. Arrowstar
    So you get errors from trying to create the bodies file or errors when trying to load/use the bodies file afterwards? If the latter, can I see the file please? Thanks!
  21. Arrowstar
    Hey there, KSPTOT author here. I'm not sure what GPP is but if you post over on the other thread or PM me we can talk about it. Thanks!
  22. Arrowstar
    No worries! Basically the departure code is designed to give a quick and easy maneuver plan for estimating DV requirements and for execution of you have high thrust to weight. If you don't have this, you'll need to break up the depature burn into a series of burns. This more complicated approach should be modeled on Mission Architect. Basically you would create the burn in MA as shown in the departure screen, the right click on the burn and click "split burn" or something like that. You'll then need to use the optimizer on the burns and itermediate coasts to target whichever body you're going to. Okay, so that's a fairly long explanation, but it's the gist of it anyway. I suppose the big take away is that modeling multi burn departures with low thrust engines is hard. :-) Let me know if you have any questions!
  23. Arrowstar
    You can certainly turn it back on, it still works well in most cases. :-)
  24. Arrowstar
    Yes I did. I found that turning it off by default improved things a bit without too much of a hit to run time. :-)
  25. Arrowstar
    Glad to hear it!
×
×
  • Create New...