Jump to content

Arrowstar

Members
  • Content Count

    2,295
  • Joined

  • Last visited

Community Reputation

1,052 Excellent

3 Followers

About Arrowstar

  • Rank
    Astrodynamicist

Contact Methods

Recent Profile Visitors

5,813 profile views
  1. The reason your propagation is taking so long is because you're coasting for 6 days in low Kerbin orbit. This is a big no-no. Adjust the start time of the simulation forward so that you only have to coast for ~1 or ~2 revs in LKO. EDIT: Also, on event 7, I think you misunderstood what I had written before. Your C3 needs to be positive when you set the kinematic state. Yours was negative and so you were just orbiting Kerbin for many days. Change the bounds to positive 0.001 to positive 10 and the C3 energy to 1 (or whatever) to start. The case runs much more smoothly when you do this
  2. I'm going to need a bit more information. Do you get an error? Can you provide the LVD MAT file and what you're trying to enter (with a step by step process)? Universal elements are probably not a standard element set, it's just what I and some coworkers call them. They are useful for defining hyperbolic orbits. They are the same as the Keplerian orbital elements you found except: SMA is replaced with C3 energy. C3 is a measure, in some sense, of total mechanical energy of the orbit. It is positive when the orbit is hyperbolic and negative when the orbit is elliptical. See
  3. Here's roughly what I would do in this case: Use the porkchop plot function in the main KSPTOT window to figure out your departure and arrival times. Use Kerbin instead of the Mun here. Use Launch Vehicle Designer (LVD) to put together the mission plan starting in low Mun orbit and going out to a Dyna flyby or orbit insertion. I've done step 2 for you as a template you can use for yourself. Take a look at this file in LVD and poke around to see what I did. Basically I just start in Munar orbit, put in a coast to the departure delta-v, and coast outwards to some point in int
  4. Holy moly, the last update... it's the end of an era. Thanks for 10 wonderful years, Squad!
  5. Sorry about the delay, it's been a very busy week for me. The general idea is that at each flyby, you create a flyby periapsis state and then propagate it backwards (to the previous flyby or the Kerbin departure orbit) and forwards (to the next flyby). You then constrain for position, velocity, and time continuity at the points where each forward propagated deep space trajectory meets up with the next backwards one. I call these points "patch points." The flyby state is optimized and defined using universal elements. You generally constrain the C3 to be greater than zero (plus a s
  6. I'm developing on R2021a and I haven't seen this issue before. Weird! Can you verify that "C:\Program Files\MATLAB\MATLAB Runtime\v910\toolbox\matlab\funfun" actually doesn't exist? How far up the path do you need to go before you get to a folder that does exist? Also, when you reinstalled it, did you redownload or just reinstall from the file you had? I see that the MCR has been updated to R2021a Update 2, which could fix the issue maybe.
  7. Yes, you can definitely start in orbit. Just adjust the Initial State of the vehicle as desired. Hi everyone, Tonight I've build KSPTOT v1.6.8 PR9. Here's the change log: LVD: Added an Open Recent Mission item to File menu LVD: Migrated main UI and numerous other UIs to App Designer framework. There are still a number of LVD UIs that still need to be migrated, but this is a start. LVD: Plotting state logs should now be a bit faster due to updated frame rotation behavior. Added UI progress bars when opening all tools from main KSPTOT UI. Resolved bug wit
  8. 1) There is a tutorial for LVD but it's old and probably more than a bit outdated. I wouldn't look too closely at it at this point. 2) I would actually use LVD for what you're trying to do. It has some nice functionality for implementing flybys. Take a look at the example mission case "lvdExample_ToEelooViaJool_BackPropExample.mat". The idea is to use forward and backwards propagation in order to create patch points in deep space that are easier to optimize to. Study that mission file and feel free to ask any particular questions! It's not too hard to put something together actually.
  9. This looks like an issue with the MATLAB Compiler Runtime. If it's repeatable, can you redownload and reinstall the R2021a MCR? Hopefully that will clear up the issue.
  10. Bug fixed for next release! I ended up needing to process the body data in descending order down the solar system hierarchy (Sun, planets, moons, etc) in order to make sure that when the inertial reference frame for the body being processed is figured out, the parent body's data is already there. Thanks for the report!
  11. Hi there! There isn't a manual, but I can get you started: Open up KSPTOT and use the Tools -> Maneuver Planning -> Multiflyby Maneuver Sequencer menu item. This will open up MFMS. First thing I would do is just tap "Compute Flyby Maneuver Sequence" and watch the application go. Take a look at the data it gives you (all of the orbits plus maneuver data). From there, start playing with the waypoints list on the left. There are no hidden menus or anything in MFMS, so what you see is what you get. It's very straightforward once you've spent a bit of time with it. I wil
  12. Hi everyone, Tonight I've built KSPTOT v1.6.8 pre-release 8. This is a pretty big update with a fair number of new things. Here's the change log: LVD: Task list area now has a search box. LVD: Formal continuity constraints are replaced with state comparison constraints for position, velocity, and time. LVD: Event termination conditions now have ref frame awareness. LVD: Halo Orbit Constructor now shows arrival/departure transfer orbits too. LVD: Event actions can now be executed before or after propagation on events. LVD: Constraints can now be evalua
  13. Hi everyone, I want to introduce a few new features in Launch Vehicle Designer. First, the paradigm for event actions is changing a bit. As many of you know, event actions occur after the event has finished propagating. However, I have made a modification which enables the user to select which side of propagation the actions should occur: before the start of propagation or after it (the current behavior). The default selection for this is the current behavior, "Execute Actions After Propagation." Existing mission plans therefore should not require updates. Hopefully this w
×
×
  • Create New...