Search the Community

Showing results for tags 'orbital mechanics'.

More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • General
    • Announcements
    • The Daily Kerbal
  • General KSP
    • KSP Discussion
    • Suggestions & Development Discussion
    • Challenges & Mission ideas
    • The Spacecraft Exchange
    • KSP Fan Works
  • Gameplay and Technical Support
    • Gameplay Questions and Tutorials
    • Technical Support (PC, unmodded installs)
    • Technical Support (PC, modded installs)
    • Technical Support (PlayStation 4, XBox One)
  • Add-ons
    • Add-on Discussions
    • Add-on Releases
    • Add-on Development
  • Community
    • Welcome Aboard
    • Science & Spaceflight
    • Kerbal Network
    • The Lounge
  • International
    • International
  • KerbalEDU Forums
    • KerbalEDU
    • KerbalEDU Website
  • KSP Pre-release
    • 1.2.9 Pre-release Branch
    • 1.2.9 Pre-release Modding Discussions
    • 1.2.9 Pre-release Bug Tracker


  • Developer Articles

Found 11 results

  1. (Inspired by Interplanetary How-To Guide by Kosmo-Not) I proudly present to you the Nexus's Orbital Calculator It does a lot of calculations for you automatically. You only have to input the data. It has a: Orbit Calculator Hohmann Transfer Calculator Interplanetary Transfer Calculator And more... Works for both stock KSP and Real Solar System Download for free by clicking on the link below (I'm open to constructive criticism and suggestions)
  2. I've taken on the project of writing an interplanetary trajectory optimization tool and a comparison of algorithm efficiency for the problem at arbitrary starting points. Looking further into the problem, however, I have a question that I can't seem to answer. When you optimize an interplanetary trajectory in a patched-conics approximation like KSP, how do initial and target orbit influence the problem? Specifically, I understand how the 'interplanetary' part works. Given the position of two planets, you can calculate the orbit that will intersect one position at one time (the departure date) and the position of the other at another time (the arrival date) easily by cranking through Lambert's Problem for the solar orbit case. However, how do you account for leaving the orbit of the start planet and arriving in orbit of the destination planet? Put another way, how do you calculate ejection angle or the optimum burn to leave/enter the patched conic gravity well?
  3. I'd like kOS to calculate the velocity at periapsis for me with the apoapsis height, periapsis height and apoapsis velocity as variables. However, if one is using the specific orbital energy v2/2 - µ/r = constant, you must know the standard gravitational parameter. I could hardcode the values into my script for every celestial body, but I want it to be as general as possible (if you decide to alter the default masses with mods etc). How do I get rid of the dependency of µ in my formula?
  4. Incredible new space sim/survival/orbital mechanics/multiplayer game. Early access is coming out next week. Looks absolutely fantastic! Any KSP players dream come true. Check it out, and spread the word!
  5. Suppose two countries with all of the technologies we expect to have by the year 2150 exist on Ganymede and Europa. They cover the whole of their moons. They have giant vertical underground farms to sustain themselves and huge solar fields with almost 100% efficiency (virtually no energy (light, heat, vibration, etc.) is missed or wasted). They have mining running down to the cores. They have big cities like on Earth, mostly underground. And they go to war with eatchother. No prisoners. No survivors. No slaves. Total annihilation. How is it fought? What are the advantages of Europa over Ganymede?
  6. I'm a newbie in career mode and have hit a roadblock in attempting to fly by and gather scientific data near the Mun - I've followed Scott Manley's tutorials on how to do this, but I'm doing something stupid because I can't succeed - after achieving a stable orbit around Kerwin, I place a manuever node 90 degrees ahead of my target (Mun) - no matter how I try, I cannot get a projected orbit to get closer to the Mun than 2429.6 km - no matter how many ways I try to do it (ahead of it, behind it, near it), the closest approach miraculously stops at 2429.6 km - also, the application is so sensitive as I increase the projected orbit near the Mun that I instantly "pop" into a totally different orbital arrangement (is that the effect of the Mun's sphere of influence?), but still keeps me 2429.6 km away from it - and finally, is there a way to zoom in on the projected near encounter of the Mun in map view? Mine remains centered on my spacecraft and when I try to zoom in the "spaghetti" of orbits near the Mun I only zoom in on my spacecraft so it is impossible to analyze what my projected path(s) are doing very easily. Sorry for all the questions - I love the application but I'm up against a "wall" that's preventing me from advancing - the issues are exactly the same in sandbox as well as career mode. Thanks in advance for anyone's assistance/suggestions.
  7. how does mission control calculate where you will end up and how map calculates this. like for translunar injection how do you know how your orbit is by not using map mode
  8. Hey guys, understand this is a bit of an ask but I've come to the end of my tether with trying to calculate these. If any of you are nerdy enough to give these a go I'd greatly appreciate it.
  9. Last week there was a thread created that discussed the basic requirements of deltaV required to get into various positions of the moon. Other than the launch variables the statement was made or asked if deltaV tables was the best way to handle this. I looked at the from an energy perspective, first off I need to add that the classic formula for calculating delta-V between two circular orbits is - SQRT(u/r0) for the first burn (r is r0 in this case in the wiki image, ignore the v = ) r can either be an apoapse or periapsis and SQRT(u/r1) - (r is r1 in this case in the wiki image) for the second burn. r can either be an periapsis or apoapse The perfect energy requirement equal to the is close to this at in the case of the lowest and highest eccentricities (e = 1) but in the middle ranges it is considerably different. The basic problem is that elevation of a circular orbit neccesarily requires two burns. During small burns the change of velocity is small and as a consequence little momentum is lost. In changing to very eccentric orbit much momentum is lost, but the dV required to establish the second orbit is small fractional to the energy required to create the transfer orbit. At minimum escape velocity its zero. In eccentricities (e) of transfer orbits around 0.7 (e.g a geosynchronoous from LEO transfer) have substantial inefficiency because considerable momentum is lost as the satellite slows to its apoapse at which it needs to burn. So for example a station keeping burn is perfectly efficient, and also a escape orbit (minimal) is perfectly efficient (but because of N-body problems more or less a theoretical exercise) The energy requirement works within tolerances if the correction factor for eccentricity is provided dV (total)/((1-e)+LN(1+e^1.9)), up to about e=0.75 but becomes inaccurate after this. Its not perfect. I tested this with a number of orbits, a is irrelevant the error is a function of e. This means without using a table one has a minimum requirement for a single step energy plot of knowing e as well as initial radius and final radius. Its not hard to calculate e but in creates also a two step operation. Ergo the OP is correct, the two step dV plots are as simple as any other means of plotting the dV requirements of an orbital change.
  10. FYI found a very early access indy game on steam called Celestial Command, which is a space game which uses Newtonian orbital mechanics and the Unity engine, reminds me of early KSP quite a bit, though it is not the same kind of play, being top down 2D/3D. It is a resourcing / crafting / trading / pew 'em up game and looks like it is being built with multiplayer in mind though I have only tried single player so far. Gameplay is, like KSP, engaging for mechanical types. You mine asteroids/moons/planetismals in orbit to trade the ores, make fuel and also build your ship out of the same ores. The structure of the ship and thruster placement etc all matter for the flight physics as does mass distribution including cargo. Its very early days, so is cheap, thought some might enjoy. It occurred to me this game owes a lot to KSP and probably wouldnt even exist if KSP had not made it possible for gamers to engage with orbits and, in that sense, Squad would probably be justified in considering it a sincere form of flattery! Gameplay screeny to give some flavour.
  11. Can anyone recommend some good resources on the mathematics of orbital mechanics? I'm comfortable calculating Hohmann transfers (including alignment angle, dV budget, etc.), I can calculate dV for stages and total craft, but I'm having a hard time figuring it out past there. I'd love to be able to calculate the dV required for plane changes the new trajectory from a gravity assist the launch window for non-Hohmann transfers porkchop plots map out a spiral transfer for low thrust engines and plan re-entry trajectories. I expect some of these problems have known simple solutions, and some will require numerical integration. I'm comfortable setting up and solving either method. My background: I'm a chemical engineer. I'm comfortable solving ODEs (ordinary differential equations) and PDE (partial differential equations). I don't usually work in multi-dimensional calculus, but I do understand the basics of dot and cross products. There was a point in time in college where I was better with those. My trig is pretty good, but my calculus in cylindrical or polar coordinates isn't great. I usually use MathCAD for complex problem solving but don't have access to it right now. So I usually set up Eularian integrators in excel when I can't work out exact solutions. With a little work I could make it run Runge-Kutta instead. I've read the wikibooks articles on orbital mechanics, as well as these links