PakledHostage

I believe it is Kerbin\'s surface to the Mun\'s core. This assumption works in all of my calculations. From what I understood from November\'s discussion, Unity\'s limitations force KSP to calculate the Mun\'s orbital speed as if it were an infinitesimal mass orbiting Kerbin at the Mun\'s orbital radius. If I understood HarvestR\'s comments correctly, then the Mun isn\'t 'on rails' in the game in the sense that its position could be propagated at any arbitrary speed. Instead, it orbits at the same speed as a spacecraft. Edit: Also for reference, a solar day on Kerbin is 6 hours and 50.8 seconds long. This can be verified by watching Kerbol set from the surface.

From one nerd to another: Nice work!

I started my burn 6 minutes and 57 seconds after Kerbol first crested the horizon, as viewed from my 150 km high parking orbit. I burned for 3 minutes and 8 seconds to place my spacecraft into a hyperbolic trajectory with eccentricity 1.539 and periapsis of 158.1 km. My objective was to cross Kerbin\'s SOI at 1607 m/s, retrograde to Kerbin\'s orbit about Kerbol. My actual burn put me into a 13.533 million km by 7.070 million km orbit about Kerbol, which I easily trimmed into a 13.533 million km by 7.000 million km orbit. The only tricky part about planning all of this was that the angular position of the hyperbolic periapsis moves by 14 degrees during the burn, and this has to be accounted for. As for the return to Kerbin, I calculated the timing of the burn by ded-reckoning. I added up the orbital periods of the 2 transfers and the 7 orbits at 7 million km and then worked out what fraction of an additional orbit at 7 million km I\'d have to wait before starting my burn to return home. I\'m glad you brought this up. It is 'easy' if you know Kerbol\'s mass and radius but what if you don\'t know either value? How would you know what they are? The orbital altitude shown in the game is the altitude above Kerbol\'s surface, not the distance to Kerbol\'s centre of mass. The distance to Kerbol’s centre of mass is dependent on Kerbol\'s radius and Kerbol is big enough that its size matters. In the case of your calculation above, you only know the Mun\'s orbital period because someone else has calculated Kerbin\'s mass for you before hand. What if they were wrong? What if the radius you’re using is wrong? Why not try, as I suggested in your Ideas for experiments while in orbit thread, to calculate both the mass and radius simultaneously? In the case of Kerbol, solving for both simultaneously is the only thing you can do and you need both to figure out the length of Kerbin\'s year.

It does, and it doesn\'t. Adding the 600 km radius cause Vincent\'s and Vanamonde\'s numbers to agree, but the orbital speed of the Mun IS a bit slow in the game. The speed used in the game would be correct if the Mun had insignificant mass relative to Kerbin\'s mass (i.e. like a spacecraft), but when you account for the Mun\'s significant mass, the Mun should be orbiting about 4.9 m/s faster than it is. That being said, there was an extensive discussion about this back in November where HarvestR pointed out that, even though this isn’t related to 2-body vs. n-body physics, the 542.5 m/s value used in the game is a limitation of Unity and we\'re stuck with it.

Like so many things in the Kerbol system, Minmus is extremely dense. (So are our beloved Kerbals... Coincidence?) This too would affect the radius at which it becomes spherical. I found an article that derives the potato radius of a celestial object. It shows that the radius at which a body can be expected to be spherical is a function of the body\'s density and the properties of the materials that it is composed of. Minmus has a reference radius of 60 km (i.e. the radius that the altimeter is referenced to). It has a mass of about 4.23x10^19 kg. That gives it an average density of roughly 46700 kg/m^3. That\'s 9 times greater than the density of Earth! I think we need to just suspend our disbelief and accept that Minmus is mostly spherical.

The gravitational parameter includes Kerbin\'s mass. What if you don\'t know Kerbin\'s mass? Now you\'ve got two unknowns: mass and radius. Maybe your Kerbals have accurately surveyed Kerbin from the ground and have found it to have a radius of 600 km, but why not verify this value by another method now that they\'ve achieved space flight? Try calculating Kerbin\'s mass and radius without knowing either value to start. Do you get the expected value for Kerbin\'s radius? How far are you off? How can you improve the accuracy of your experiment?

I completed this challenge because I think it is a good demonstration that it is already possible to put together an inter-planetary mission with the game in its current state. I didn\'t encounter the Kraken or any other navigational anomalies during my flight. I flew it using only stock components, patched conics and some good old-fashioned ded reckoning. I didn\'t have to resort to using MechJeb. To be fair, I have encountered the Kraken in the past but it seems to prey mostly on more complex ships. I haven\'t encountered it when using simple spacecraft without ASAS or SAS. For what it is worth, it seems to me that the Kraken causes control reversals in one hemisphere of the navball while leaving the other half unaffected. The SAS and ASAS can\'t handle that and cause the ship to spin out of control. On the one occasion where I encountered it, I was able to stop the spinning by hand through a combination of really concentrating on applying the correct control input (which required some luck to get it right) and turning off the SAS. Ever since that time, I\'ve tried to minimise my manoevering while outside Kerbin\'s SOI. Back on topic, the Kerbal scientists have recovered the Kerbolar Solar Flare Experiment package from my mission\'s capsule and are analysing the samples as of this writing. The results of the mission\'s second objective are already available. The second objective of the mission was to verify Kerbol\'s mass and radius. My Kerbals had previously determined that Kerbol has: Mass: 1.757 x 10^28 kg Radius: 65400 km These values were confirmed during this most recent mission by recording certain key parameters during the transfer down to 7000000 km, during the seven orbits at 7000000 km altitude, and again on the transfer back to Kerbin\'s orbital altitude. The length of Kerbin\'s year was also confirmed as 106 days, 12 hours, 32 minutes long. Below are my screen shots: Edit: Clarified paragraph about my experience with the Kraken

Check out BoolyBooly\'s Shoot for the Sun! challenge.

Good idea! The range of available sub-points are limited to a range of longitudes roughly 173° wide on the Kerbin-ward side of Minmus, but it is still better than a telescope on Kerbin\'s surface.

Kerbal physicists theorise that there are thousands of parallel Kerbal universes, with more being created every day. In my Kerbal’s parallel universe, the map view is displayed on the wall at mission control. The trajectory on it is computed from data acquired from ground radar stations and onboard IMUs. The data isn’t accurate enough to usefully predict an orbital trajectory beyond the next celestial body encounter. The trajectory display has to be updated as the mission progresses and orbital trim burns need to be accomplished to keep the mission on course. (This is the same reason I don’t use MechJeb; it provides more accurate orbital parameters than could be determined from the data that my Luddite Kerbal’s instruments can provide.) My Kerbal’s civilisation is also rather cash strapped. While they value space exploration, they don’t have the financial resources to fly large numbers of missions. And public support for the space program would dry up if their Kerbal astronaut heros were always being killed in mission failures. I\'m kinda chuffed that, while I have only flown four missions to Minmus (one to Minmus orbit, one to Minmus landing and two fly-by missions), I haven’t aborted or lost a single Minmus mission. Careful planning has made this possible. The objective for this fourth flight to Minmus was to fly a “grand tour†of Kerbin’s system of moons and return to Kerbin with minimal fuel burn. Starting with a fresh persistence file, the plan was: - Wait in a 200 km high circular parking orbit until 1:19:39:00 MET. - While waiting, adjust the orbit so that the centre of the Mun’s disk crests the horizon as close as possible to 1:19:39:00 MET. - TMI burn at the instant that the Mun’s disk crests the horizon. Burn at 100% throttle to 2871 m/s at 201.5 km. This results in a 200.3 km x 11180 km orbit about Kerbin that intercepts the Mun’s SOI. - Trim the trajectory for a 295.6 km Munar periapsis. - Munar periapsis at 2:00:52:00, at 615.5 m/s. - Munar gravitational assist results in a 7753 km x 54964 km orbit about Kerbin - Minmus fly-by at 3:14:14:00 This trajectory relies upon the Mun and Minmus being separated by an angle of 77.7 degrees at the time of Munar periapsis. An error of ±7.5 minutes here results in an error of ±1 degree, which would have to be corrected with an orbital trim manoeuvre. Given that my Kerbal astronomy is probably only accurate to this tolerance, I figure this degree of error is inevitable. Here are the screen shots: Arriving at the Mun 6 minutes 35 seconds earlier and about 7 m/s faster than planned. Arriving at Minmus 34 minutes earlier than planned. The mission expended aprox 70 m/s Delta-V between the end of the TMI burn/trim and re-entry. The TMI burn was sufficient only to yield a 11180 km Kerbin apoapsis. About ½ of the Delta-V used post-TMI was required to lower the Kerbin periapsis to a sub-atmospheric altitude after passing Minmus. Presumably this Delta-V is sufficiently small that it could be achieved with the EVApacks™ that are being proposed for v0.16… Maybe Jeb is has an interesting EVA trip in his future? (What are you doing? Jeb?) Edit: Fixed broken links to screenshots.

I\'m glad to hear that some others are finding my posts in this thread useful and interesting! I\'ve learned a lot about the design of gravitationally assisted trajectories in the last week and I\'m working on a more efficient and robust algorithm for getting to Minmus via Munar gravitational assist. First hand experience with this kind of thing really gives me an appreciation for the guys who plan the trajectories of real missions! It\'s what I love about KSP. Anyway, my new trajectory will involve a burn into a 200.3 x 11180 km orbit about Kerbin which will cause the spacecraft to fly by the Mun and arrive at Minmus about 42:35:00 after TMI. It will require a small burn (~7 m/s) perpendicular to the initial orbital plane along the way, but overall it requires lower Delta-V to get to Minmus than a direct transfer from LKO. My new trajectory is also more tolerant of small timing/burn orientation errors than my first draft. I\'ll post back once I have a chance to fly the new trajectory over the weekend. Edit: Corrected a spelling mistake.

Bob only sounds great once it is splashed down.... Then it would be Omega bobber.

There is one rather critical piece of information missing from my write-up that you\'d need if you wanted to re-create my mission: You need to start with a fresh persistence file then be in position in orbit to make your TMI burn at 1:19:23:00 MET. The tricky part is that the Mun must also be cresting the horizon as viewed from your 200 km high parking orbit at that time. The TMI burn needs to start the instant the centre of the Mun crests the horizon. I estimate that the tolerance is about ±1 minutes but I don\'t know for sure because I\'m limited by the accuracy of my Kerbal astronomy. This plan probably also won\'t work if you use a spacecraft that has a substantially different thrust-to-mass ratio than my spacecraft.

This idea has been my puzzle for the last few days. Having flown two previous missions to Minmus, I was looking for a new challenge. I spent some time on the weekend planning and I flew the mission this evening. Here are the results: I flew a 'grand tour' of Kerbin\'s system of moons. I didn\'t enter orbit around any of them. I just did fly-bys. I planned my trajectory such that I\'d reach Minmus near the descending node. That way I would minimise the out-of-plane manoeuvres required and use less fuel. Per the requirements of this challenge, my initial TMI burn resulted in a 200.3 km x 11893 km orbit about Kerbin. This resulted in the boys entering the Mun\'s SOI just shy of 5 hours after the TMI burn. The resulting Munar periapsis was within 200 km of the surface. From there, they were ejected into an inter-moonar trajectory that intercepted Minmus about 17.5 hours later. An orbital trim manoeuvre was required enroute between the Mun and Minmus to lower the Minmus periapsis, but otherwise the original TMI burn was sufficient to reach Minmus. Another burn was required as I neared Minmus periapsis to prevent the mission from escaping Kerbin\'s SOI, and to return it instead to Kerbin. Interestingly, reaching Minmus this way actually used more fuel than I used during my previous two missions to Minmus. In those missions, I bypassed the Mun and went there directly from LKO. In this case, the gravitational assist from the Mun was sufficient to put the spacecraft on a Kerbin escape trajectory. That energy had to be dissipated with an ~200 m/s burn at Minmus periapsis if the mission was to return to Kerbin. Had I entered Minmus orbit from my inter-lunar trajectory, I would have required even more Delta-V (on the order of 300 m/s). That\'s substantially more than when I\'d previously entered Minmus\' SOI from a highly elliptical orbit about Kerbin. Screen shots are attached: Starting with a fresh Persistence file... We really do need an in-game display of UTC/Julian date (or whatever the Kerbal equivalents are). I burned a bit of fuel setting myself up for the return to Kerbin. I wanted retrograde hyperbolic trajectory with a fairly low periapsis at Minmus. I think my next project will be to design a Munar gravity assisted trajectory to Minmus that requires a lower net Delta-V (i.e. sum of accelerations and decelerations) than the elliptical transfer directly from LKO. Having thought about it a bit, I think it should be possible with some minor tweaks to this trajectory. PH. Edit: Added paragraph explaining what my next project will be.

Ideas like yours were what I was thinking about when I posted above that some good ideas get proposed each time this topic comes up. Your suggestion would reduce the amount of computation required to predict the spacecraft\'s motion and would ensure that the planets remain in their intended orbits, but it would still require orders of magnitude more computation than what is required for the current system of patched conics. There are a handful of relatively simple equations that predict an object\'s motion in a 2-body system. The game relies on these relatively simple 2-body equations for time warp and updating the map display. There is no similar set of equations for the system of n gravitational attractors that you are suggesting.

That isn\'t an easy answer to give because my orbital trajectory planning utility is written in VB and has a GUI interface. Much of the processing time required to produce the data for a plot like the ones on the previous page is dedicated to updating the GUI. And I don\'t have time to port my physics library to something more computationally efficient. Sorry. Even so, I think it is something of a moot point... This topic pops up from time to time (I am not sure why this old thread was revived again yesterday), only to get beaten back down. Each time, good ideas are proposed but the response is always the same: It doesn\'t fit with the game\'s current architecture. The Unity engine is too limited. At this point, I tend to agree with BoolyBooly. Aspects like orbital perturbations, correct orbital velocity of celestial bodies and Lagrange points aren’t simulated, but we know about those limitations and we can work around them.

As a benchmark for your challenge, several members of the community have managed to hand-fly a Pod-2LFT-LFE stack into orbit. By my figures, that stack has a Delta-V of 4537 m/s. I don\'t know of anyone who\'s managed to reach orbit with this stack after adding a parachute. Adding the chute lowers the Delta-V of the stack to 4291 m/s. Presumably this is an indication that the limits of what is possible is somewhere between 4291 m/s and 4537 m/s? I\'d be interested to be proven wrong on this one. Also, DayBlur posted in the Mini-challenge: max altitude with this supplied spacecraft that he was working on calculating the optimal profile for an orbital launch. I\'m sure many of us are looking forward to reading his results.

I agree with Temstar. Why not play around with some of the ideas now already? It gives us something to do and it is fun to think about. I never would have believed how small a stock rocket I could get out to planetary distances and back to Kerbin if I\'d never tried it. And what I learned about orbital mechanics in the process can be applied when planets are finally added, even if the parts are rebalanced between now and then.

I\'m happy you\'ve proven me wrong too! I have the same sextant. It’s brilliant. Now back on topic... Sorry mods.

It only moves along a straight line because Minmus\' orbit is circular. An analemma\'s shape is defined primarily by the eccentricity and obliquity of the observer\'s orbit. Obliquity causes the north-south motion (declination), while eccentricity causes the east-west motion (equation of time). Sorry if that\'s too much detail... I can\'t help it; I\'m a navigation geek. (I suspect that I\'m the only member of the KSP forum who owns and knows how to use a sextant...)

I think that was Cykyrios\' point... Great video! P.S. As usual, Wikipedia has a good article on this effect. Edit: Added link to Wikipedia Analemma article.

I don\'t think I said it won\'t work... What I tried to say is that I didn\'t think it was worth the trouble. It might be an interesting exercise to figure out how much of a fuel savings we\'d achieve by using a gravity assist from the Mun or Minmus, but I think that is all it would be: An interesting exercise. I don\'t think that the handful of m/s Delta-V that we’d gain would warrant the restricted launch window.

You\'re a man of my own heart. I\'m also trying to maximise the efficiency of my launches and orbital manoeuvres in preparation for when another planet is added to the game. My plan is to fly a few unmanned probes to the planet first to gather information about its mass, the nature if its atmosphere, etc. I figure I should be able to send a probe on a one-way trip from KSC to the new planet using a 7-8 LFT stack (so long as it is within ~2 Kerbin orbital radii of Kerbol). When I\'m ready to fly a manned mission, I\'m hoping to be able to use a combination of crew transfer/rendezvous to minimise the necessary size of my rockets. I\'m also hoping that we\'ll have to make some allowances for re-entry heating by then. If we want to use aerobraking to save fuel (depending on how aggressive we want to be about it, of course), then there should be a cost in the form of needing to carry a heat sheild. If you haven\'t already done so, check out the Mini-challenge: max altitude with this supplied spacecraft challenge, the Shoot for the Sun! challenge as well as the Economy of design challenge. All three are good examples of the type of efficiencies that are possible.

Very interesting write-up, Nibb31! Thanks for sharing.

I disagree. I\'ve compared Delta-V requirements for a few different interplanetary trajectories and it doesn\'t take much more Delta-V to get into an interplanetary trajectory than it does to get to the Mun. And that\'s without the added complexity of a gravitational assist from the Mun or Minmus. For example, getting out to 1.5 times Kerbin\'s orbital radius (i.e. out to 20 million km from Kerbol) from a 100 km high parking orbit above Kerbin only requires ~180 m/s more Delta-V than it takes to get to the Mun from that same orbit. And if the new planet has an atmosphere, then we will be able to use aerobraking upon arrival to save even more fuel. But I think the strongest argument that we won\'t need to use a gravitational assist from the Mun or Minmus to get to any new planets comes from the example set by real-life Mars missions. Curiosity didn\'t require a lunar slingshot to send it on its way to Mars.