Meithan

I have a simple question. Suppose I'm orbiting a planet and I want to change my orbital inclination. Is there a way to determine the position of the ascending and descending nodes of my orbit without using mods? I can't target the planet I'm currently orbiting. On Kerbin, I can use the Mun since its orbital plane coincides with Kerbin's equator, but is there another way that works in general?

I remember one incident when I was just learning to rendezvous and dock, and still found it very hard. I spent maybe 1 hour with the stressful rendezvous and approach, and after much effort finally got the "docking ports" touching -- but the damned thing wouldn't dock! After some minutes retrying it, I realized my mistake: what I put on my ship were not docking ports, but just radial attachment points! Doh!

Here's the direct link to the last graph: http://i.imgur.com/4HVffEp.png It comes from the fact that I'm including the mass of empty fuel tanks in the calculation. Adding more fuel also adds more tank mass which you have to carry. And in KSP most fuel tanks have an empty mass equal to 1/8th the fuel they carry (or 1/9th their mass when full). Yep, it's great. And has a lot of options to "share" the produced graphic.

Sure. I started with the Rocket Equation and first solved for total mass as a function of desired delta-v: I can show you the detail if you want, but I think you already arrived at a similar expression. I then set up the equation for two different engines, equated the total mass, and solved numerically for delta-v for several payload masses. Edit: I forgot: I used gnuplot to make the graph. It's a free/open-source plotting software for Linux.

Al menos uno. ¿Nadie más? Igual nadie ve el hilo jeje.

I use MechJeb (v2.0) for the large pool of (customizable) data metrics it can display while in-flight. I almost never use the autopilot. Not because I consider it cheating or anything like that, but simply because I like flying things myself. The exception was when I placed a ring of satellites in keosynchronous orbit, which requires very precise orbits. I didn't want to spend fifteen minutes per satellite tweaking the orbits, so I used MechJeb to perform the circularization burns to a high precision. Even then, MechJeb refused to correct the orbital inclination of two of them, so I ended up doing it manually. I have a general policy when there's an easy, automatic, almost-cheesy way of doing something and a more complicated, "more correct" way: learn first to do it the hard way, for you'll learn the nuts and bolts in the process and develop a profound understanding of how it works. Then, when you've mastered it, you earn the right to use the easy, automated way. And if it ever happens that the automated way doesn't work any more, you can always fall back to the "manual" mode (like I did for my keosynchronous satellites).

Hola. Quería ver si hay jugadores mexicanos de KSP. Yo vivo en la Ciudad de México. ¿Alguien más?

That's exactly what I was planning for my manned mission to Duna. I already launched one LV-N powered tug taking a lander to Minmus and back, and I felt bad for deorbiting it upon Kerbin return -- such a waste of perfectly good hardware. Now I revised the design and it's meant to be launched once and re-fueled in orbit after each mission. I already got one prototype docked to my orbital fuel depot in low Kerbin orbit.

Wow. Great stuff! It seems that above 10 tons payload and 2000 m/s delta-v, the LV-N is the king pretty consistently if the required minimum TWR doesn't exceed 0.7 (Kerbin-relative), which is plenty for an interplanetary stage.

To complement the single-engine comparison of the LV-N and LV-909, I've calculated the delta-v at which the LV-N becomes a better choice than the LV-909, as a function of payload: The red curve is the delta-v (with its scale on the left) while the blue curve is the corresponding total ship mass (scale on the right).

Very interesting comments. Yes, TWR considerations is something I haven't included in the previous analysis, and as you say it's something that can be an important aspect of mission design. I've been designing a Duna manned mission (which must return of course!) and the lander mass is about 20 tons. Wanting something around 200 kN thrust so the burns don't take forever, I ran the numbers comparing 3-4 LV-N engines vs. a single LV-T40 or LV-T45. If I recall correctly, I think the LV-Ns were the better choice.

Expanding on JUDUFU' analysis, I think it's important to include the payload mass, since in the end the point of a spaceship is pushing something other than itself and a bunch of fuel. The following plots show the total ship mass (including a fixed amount of payload) as a function of desired delta-v. Right now I compared only the LV-N and the LV-909, since they have comparable thrusts. It's also just one engine at the moment. I'm considering the mass of the empty fuel tanks in the calculations, taken as 1/8th of the fuel mass they carry (true for all rocket fuel tanks except the tiny ones). For comparison, in the first plot I set the payload to zero, so this one is an engine pushing itself and its own fuel: One sees from this plot that the LV-909 is a better choice if the desired total delta-v is below about 6400 m/s, as found by JUDUFU. If you want more delta-v, you need to take more fuel, and the LV-N becomes a better choice. As many have pointed out, this is because the larger engine mass has less of an impact since it represents a smaller fraction of the total ship mass. Let's see what happens when we start adding useful payload. With a 1 tonne payload, this is the result: The delta-v at which the LV-N becomes a better choice is now smaller, at around 4200 m/s. The exponential nature of the rocket equation really shows in the curve for the LV-909. If we increase the payload to 2.5 tonnes, we get this: The LV-N is a better choice at around 2700 m/s, which starts to become too low for some interplanetary missions. If you need to take 2.5 tonnes of payload to one of Jool's moons, the LV-N will definitely be a better choice. Cranking the payload up to 5 tonnes, we obtain: Now the LV-N is a better choice at around 1700 m/s. You might pull off a no-return mission to Duna with this much delta-v. The high Isp of the LV-N definitely starts to pay if you need to go farther. If you need 5000 m/s for your mission with this payload, you'd need a spacecraft twice as heavy if you used the LV-909 instead. Of course, what I'm not considering is that as your spacecraft starts becoming more massive, you'll want more thrust too. So the LV-N will be adding its mass multiple times, which will make the graphs worse for it.

EDIT: I re-posted below.

I don't think I could ever get them so well spaced launching them separately. I mean I'm sure it's possible, but it requires skills beyond my own. No, the trick is using a delivery orbit with a smaller period. See my last post (which has a link to Scott Manley's tutorial -- the clever idea is his).

I used , adapted for six satellites instead of three. I took them all to orbit together attached to a single carrier rocket: Then, I put the carrier rocket on an orbit with an apoapsis at the keosynchronous altitude and the periapsis such that the period of the orbit is exactly 5 hours: On the first apoapsis, I release the first satellite, and it performs a brief burn to circularize and increase its period to 6 h. Five hour laters, the carrier returns to apoapsis, but it's one hour ahead of the first satellite: I then release the second and boost it to keosynchronous orbit, repeating the process for it and the rest. At each apoapsis, the carrier is one hour ahead of the last satellite (one sixth of the satellite's orbit).

How long did it take for them to noticeably drift apart?

I just completed the Clarke Belt Mission. Its objective was placing a ring of six equally-spaced keostationary satellites in orbit. They all have a 6 hour period (to 1 second precision). I used MechJeb to fine-tune the orbits (although I had to manually correct the inclination of two of them for MechJeb would incorrectly determine the ascending/descending nodes it seems).

I get the exact same feeling. I remember my first rendezvous and docking. Man, I was super tense for the whole approach, and then screamed out loud (literally) when the docking rings finally engaged. Now it's just totally second nature.

Yes, it's a typo. Thanks for pointing that out. I'm almost sure the occasional error in my program is due to a sign ambiguity like that. The program juggles around a lot with these equations (going from (rpe,v,r) to orbital parameters, then from orbital shapeto position and velocity vectors given an angle, then back from new vectors to parameters, from a distance to an angle given the orbit shapte, etc.).

Yes, I apologize for this example. As I mentioned, my program's been occasionally calculating incorrect initial conditions from the provided input parameters. It's unfortunate that I chose one of these cases as an example. The sudden change of angular momentum was due to the incorrect position/velocity determination. Please disregard that post. Since then, Specialist290 has been running more tests, doing aerobrakes ingame and comparing to my program's predictions. I still don't know what's causing the bug in my program, but I've found starting the simulation at atmospheric contact seems to be avoiding it. Right now we're trying to determine if the drag calculation in my program can be made more accurate. Edit: here are my calculations, in case you want to check them: Orbit determination from position and velocity vectors

Assuming you're thrusting at periapsis or apoapsis of your current orbit (or that your initial orbit is circular), you can simply subtract the speeds in each orbit computed with the vis-viva equation. The vis-viva equation gives you the current orbital speed when you're at a distance r from the center of the planet/moon and on an orbit with semi-major axis a (which is simply the average of your periapsis and apoapsis distances, a=(rpe+rap)/2): where μ=GM is the "gravitational parameter" of the planet (M its mass, G the gravitational constant) -- it's listed in the KSP wiki article for each celestial body in the game. If your orbit is circular, then a=r, so you get the simpler equation: Example Suppose we're in a 100 km orbit aroun Kerbin and we want to perform a burn so that our apoapsis climbs to the keosynchronous altitude, 2868.75 km. First, it's important to convert those altitudes into distances from the center of Kerbin. Just add 600 km. So the radius of the initial orbit is 700 km and the target apoapsis distance is 3468.75 km. Also, you need them in meters, so multiply by 1000. 1) Compute the orbital speed in the 100 km orbit For Kerbin μ=3.5316000x10^12, so: 2) Compute the speed you would have on the transfer orbit at the point you're doing the burn. The transfer orbit has the same 100 km periapsis (700 km radius), but an apoapsis altitude of 2868.75 km (3468.75 radius). So its semi-major axis is: So, plugging in the vis-visa, with r the radius of your initial orbit: 3) Finally, just subtract these two speeds to determine the required delta-v for the maneuver. You can then repeat the analysis to calculate the delta-v for circularization once you reach the apoapsis of the transfer orbit.

Here's the Eve Express mission spacecraft just after launch and separation in Kerbin orbit, ready to boost to an Eve transfer trajectory. It carries a robotic rover and two reconaissance satellites (one for Eve, the other for Gilly orbit -- hence the booster stage they carry):

Damn, I wish I could read that rendezvous profile. Six burns? I suddenly don't feel so bad about having to mess around a lot with the maneuver nodes to do a rendezvous in KSP.

I just wanted to share this article with you guys: NASA's NEXT ion thruster runs five and a half years nonstop to set new record The news is that their next-generation experimental ion engine has been running continuously for 5 and a half years straight inside a test chamber. Sounds like it's ready to fly! The engine's Isp is 4190 s (wow!), while the thrust is produces amounts to 236 mN -- you read that right, miliNewtons (for comparison, the ion engine in the game produces 500 N of thrust). And you thought the LV-1 was an engine for ants!

Just put two RCS thruster blocks symmetrically around your ship's center of mass (you can see your ship's center of mass in the Vehicle Assembly Building by clicking on the button in the lower left, below the parts). Then, for precise corrections of your orbit, shutdown your main engine (I've accidently hit SHIFT many times, messing things up), and hit R to activate the RCS. You'll see a green light show up on the nav ball. Now point your ship towards the prograde marker and use the key H to thrust forward using RCS and key N to thrust backward. That way you don't have to turn your ship around, just use those two keys until you get exactly the orbit you want. Click on the navball's speed reading and you'll see it toggle between "surface" and "orbit". "Surface" indicates your speed relative to the ground (that is, it corrects for Kerbin's rotation).