Jump to content

Arrowstar

Members
 View Profile  See their activity

  • Posts

    2,561

  • Joined

  • Last visited

 Content Type 

Everything posted by Arrowstar

  1. Arrowstar
    The hyperbolic excess velocity is basically the speed above the gravitational escape speed at infinite distance from the planet. Give this nice Wiki article a read for more details: https://en.wikipedia.org/wiki/Hyperbolic_trajectory
  2. Arrowstar
    I do actually! I developed a semi-analytic way of computing the flyby orbit and the necessary powered flyby maneuver. It's really quick (because you don't have to solve it numerically), which is why the code runs as quickly as it does.
  3. Arrowstar
    What's a reasonable amount of DV here?
  4. Arrowstar
    I would bet you could pretty easily do Eeloo to Moho with just a Jool gravity assist: Eeloo -> Jool -> Moho. Give that a try maybe? This is a good suggestion. I'll take a look into adding this functionality. EDIT: Implemented for next release.
  5. Arrowstar
    This means that the solver could not find a feasible trajectory. Your problem is most likely one of two things. Either your departure window (upper and lower bounds) is too narrow or your trajectory is too complicated with too many way points and needs to be simplified. It's hard for me to tell with the image you provided unfortunately because I can't see the UI. ------------------------ In other news, with the upcoming release of KSP 2, I have been thinking about how I'm going to support it. I think, at least initially, all I'm going to work on is a new KSPTOTConnect plugin for KSP 2 that handles making the bodies.ini file and user upload of delta-v nodes. Any other functionality will have to be evaluated in the future to see if it's worth the time for me to get it into KSP 2. As always I'm open to suggestions and the like in this regard!
  6. Arrowstar
    There have been images encoded in the background hum of that part of the video in previous videos.
  7. Arrowstar
    Hi everyone, I've built KSPTOT v1.6.10 pre-release 2. This is pretty minor but I had some updates pending that I wanted to make sure I pushed out so they weren't forgotten. On that note, if anyone has any bugs or suggestions to report, please let me know. Here's the change log: LVD: Added new "LVD Console" tool (Tools menu -> LVD Console) that acts like a terminal/console and lets you interact with under underlying LVD data without needing to write a plugin to do it. Some performance improvements due to recompiling some MEX files. That's all I've got. Happy orbiting.
  8. Arrowstar
    The orbital epoch is the time at which the orbit's Mean Anomaly is at. The Initial Epoch is the earliest time that the rendezvous could take place.
  9. Arrowstar
    There should be a tutorial that comes with the main KSPTOT download. You can check that out. That said, I would actually recommend trying to learn Launch Vehicle Designer (LVD). It's basically Mission Architect but way more powerful in literally every way. Feel free to check that one out too!
  10. Arrowstar
    Tonight I've built KSPTOT v1.6.10 pre-release 1. Here's the change log: LVD: kOS control script now also takes with the CSV the orbit elements at the mission time so that it can display orbit element errors as a function of time. LVD: Now supports spherical harmonics gravity for the central body gravity. LVD: Added solar radiation pressure models (spherical and solar sail). Added associated UIs. Added event action to adjust SRP model. Added solar sail orbit raising example. LVD: Fixed bug with using the camera toolbar stuff causing errors and deleting context menus. LVD: Update initial state dialog to be a bit more compact. LVD: Added ability to view Drag Force in main view area. LVD: Added a Lagrange Point geometric point. LVD: Added height of terrain constraint + GA task, as well as height maps for all default bodies from Sigma Cartographer mod for KSP. LVD: Tons of performance improvements. Please let me know if you have any questions or find any bugs! Happy orbiting.
  11. Arrowstar
    I assume you're talking about that video I put up a year or two ago on Vimeo. It actually was pretty easy. In Launch Vehicle Designer, I created a custom reference frame with the spacecraft at the center, the X axis pointing from the spacecraft to KSC, and the Y axis pointing from the spacecraft to the Sun. I then used that reference frame to steer the vehicle, just setting the steering angles to 0 deg right ascent and 0 deg declination. To get that into KSP, I used the LVD function which creates a special CSV file that is read in by a kOS script that comes with KSPTOT. That does the steering in KSP. Let me know if you have any other questions!
  12. Arrowstar
    I believe the only solar sail mod I could find for the most recent version of KSP is Photon Sailor. I don't support the "giant laser from KSC that pushes you along" bit from that mod, but my stuff should handle the actual solar radiation pressure bit just fine.
  13. Arrowstar
    Something I've wanted to do for a while in KSPTOT now is have the ability to model solar radiation pressure (SRP) in Launch Vehicle Designer. This has two applications. First, for those interested in long term Kerbin station keeping problems, SRP is a major perturbation to your orbit. Second, assuming you have a solar sail large enough to make a difference, solar radiation can be used for orbit raising or orbit lowering maneuvers in solar orbit. (I think it can also be used for plane changes if you steer correctly!) This new functionality will be available in the next pre-release of KSPTOT. There are two models of SRP in LVD. The first is the "spherical" model. This model assumes your spacecraft is a sphere with a fixed area facing the Sun regardless of attitude. The material used has a fixed coefficient of reflectivity. The reference solar flux and solar flux reference distance refer to the power per meter squared emitted from the Sun at some arbitrary reference distance from the Sun. For our real solar system, that's 1367 W/m^2 at 1 AU. In the only major solar sail mod I could find, the same reference solar flux was approximately used at Kerbin's SMA distance from Kerbol. The second SRP model is a solar sail model. This model works by applying solar radiation pressure to a flat plate that is oriented in some way w.r.t. the Sun. Notice there are now three coefficients, one each for the three difference ways light can interact with your surface. Absorption does exactly what it sounds like and all the momentum from the light simply transfers directly to the vehicle. Specular and diffuse reflection of light are what allow a solar sail to perform orbit raising/lowering maneuvers because, unlike pure absorption, they transmit some force in the direction of the solar sail's normal vector (the direction out of the plane of the sail). You can set your initial solar radiation pressure model from the Edit Initial State menu accessible from the main LVD window (Scenario -> Edit Initial State). There's a new button available for this. There's also a new event action to let users modify their SRP properties in the middle of a mission, say to model solar sail deployment or retraction. I can't leave without a shot of the new system in action. Here's a solar sail craft in low solar orbit using SRP to raise its orbit, perhaps to head to Moho. That's all I've got for now! Any questions or thoughts?
  14. Arrowstar
    Great, no worries. The next version of KSPTOT is going ship with a spherical harmonics gravity model system and I just wanted to make sure I had grabbed all the coefficients for any stock celestial bodies, if they existed. Since they don't, that makes my life easy. Thanks!
  15. Arrowstar
    @FreeThinker, could you share here what the power output of Kerbol is that you're using for computing the solar radiation pressure on a solar sail? I've dug through the source code a bit but I can't seem to find anything.
  16. Arrowstar
    Sort of along these same lines, does anyone know if Principia ships with a non-spherical gravity model for the various stock KSP bodies?
  17. Arrowstar
    Coming soon to Launch Vehicle Designer (LVD): non-spherical (or "higher order") gravity modeling. If anyone's familiar with the EGM96 or EGM2008 Earth gravity models, this will let you implement those to get realistic gravitational motion at, for example, geostationary orbit. It was pretty easy to implement and definitely works! This image is the longitude time history of a vehicle in geostationary orbit around Earth over the course of about 14 Earth days or so.
  18. Arrowstar
    Oh, the physics can absolutely be predicted, not a problem. The problem is that the system is extremely sensitive to the assumptions you make. If you assume that your maneuvers are all impulsive, then error creeps in because in reality they do take a finite, non-zero amount of time to execute. The fact that you hit Eve's SoI with that assumption means that the error was actually pretty small. Remember, you're basically trying to make one bullet flyby near another bullet at millions of kilometers away and moving many kilometers per second. What you were able to achieve with impulsive maneuvers is not a failure, it's a success of the impulsive delta-v assumption! If you want to get more accuracy out of the LVD tool, it can absolutely be done. (See this video for me flying a powered ascent from the Mun's surface to orbit using nothing but LVD's steering and a kOS script as controls). But then you pay the cost for that accuracy: you need to get your mass modeling right, you need to get your engine thrust and Isp right, and you need to execute the maneuver in KSP exactly as you execute it in LVD. If you can do all that, like I showed the video, then LVD can pretty much fly your vehicle wherever you want, however you want, exactly as you want!
  19. Arrowstar
    You really would think this would be easy, yep lol. It does make me kinda happy that it's just as much of a pain in KSP as it is in real life though!
  20. Arrowstar
    As a professional astrodynamicist, not only can I confirm this, but we also spend forever getting our engine and mass models perfect so we actually get the accuracy we need. Mass modeling in particular is almost as much work as the trajectory design problem lol, but making sure that your vehicle's mass is modeled correctly and making sure that that engine models (thrust and specific impulse, especially for start up and shutdown transients) are accurate is hugely important to actually getting the vehicle to where you want it to be.
  21. Arrowstar
    That's probably as accurate as you can expect to be with impulsive delta v all the way from Kerbin. For more accuracy, you need to model the mass and engine of the spacecraft and use finite duration burns. You just can't achieve it with the impulsive delta v manuevers.
  22. Arrowstar
    To be clear, did you figure it out?
  23. Arrowstar
    In the sequential events list box, select the event whose maneuver you want to upload, then right click it and select "Upload Impulsive Delta-V Action to KSP."
  24. Arrowstar
    Okay, after looking at your screenshots I do think we're running into the limitations of the "Zero Radius SOI" assumption. As I said, MFMS does not model the fact that Kerbin or Eve have finite sized spheres of influence, and this can and will have a noticeable impact on the solution. MFMS was designed for quick studies of the multi-gravity assist trade space and not for higher fidelity dynamics simulation (which you'll need LVD for, as I previously mentioned). I think at this point you're just running into the limits of the tool. If you'd like, you can get a bit more fidelity by importing your MFMS sim into LVD very easily: In MFMS, click the Save Results to File for LVD button. Select a name and location to save the file and save it. Open up Launch Vehicle Designer from the main KSPTOT GUI. In LVD, File -> New Mission Plan from MFMS Output Optimization -> Optimize Mission to get all the various bits of the trajectory to line up. The result from the optimization in LVD will be a continuous mission plan with higher fidelity that you can use in KSP. You can get even more fidelity out of it if you put in your vehicle's masses, stages, tank information, engine information, etc, and then convert the impulsive delta-v to finite burns. That's an advanced step, though, so one thing at a time. Let me know if you have any questions!
  25. Arrowstar
    Okay thanks. What happens if you adjust the time of the maneuver a bit forwards or backwards? Keep in mind that MFMS is using a zero radius SOI assumption for Kerbin, so the timing may need a bit of tuning to work in KSP's finite radius SOI simulation. EDIT: Okay, so I tried it myself in KSP. When I put in your initial orbit exactly and then uploaded the maneuver node, it was close but not perfect. However, I noticed that when I removed the node, did some time warping, and then re-uploaded the node, it was way off. At this point something has probably shifted with the underlying orbit, which is why things went wrong. Not having the correct RAAN (LAN), argument of periapsis, and inclination can really throw off the way the maneuver works, even if they're only off by a bit. The only solution to your problem is to reoptimize your departure closer to your departure date, or to import the simulation into Launch Vehicle Designer (LVD), which can handle a higher fidelity dynamics model with real finite SOI sizes. There's a much bigger learning curve to using LVD, though, but it can definitely accurately model your spacecraft's very well.
×
×
  • Create New...