How to "Target" Geostationary Orbits

[Bashkire]

Hello,

Firstly, my apologies if that has been answer elsewhere, and it it has I would appreciate a link to the thread, but I am reluctant to skim through 113 pages of topics for my question, and the search function has shown me how to get into geostationary orbit, but not over a specific part of the planet.

My problem, if you cannot see it in the small paragraph above, is simply thus:

I wish to set up a satellite network around Kerbin. Now I have my basic communication satellites orbiting the planet at various inclinations, but of course they will not be able to communicate to the KSC or other parts of the planet if there is no line of site. To solve this issue, I have decided to put 4 geostationary satellites (command communications satellites) at 90 degree intervals around the planet, 1 over the KSC, and spacing them from there.

When I try to place my satellite over the KSC, I find that it is infuriatingly troubling to get it into position. I am either too far behind it at it lurks on the "horizon" of the planet, or it is too far in front. Either way, I have a very inefficient satellite.

Can anyone explain, preferably with pictures (or even better, a short video) but this is not essential, how one would go about setting these 4 satellites up? If it helps, I have installed the MechJeb 2.0.7 mod to help my accuracy in my endeavors.

Thank you all, and I look forward to hearing your suggestions!

[K^2]

I don't think there is a very good way to do this by the numbers, but a way to adjust position is this.

1) Place satellite in geo-stat.

2) If it's too far ahead, raise the orbit somewhat.

3) If it's too far behind lower the orbit.

4) Once satellite is over desired position, return satellite to geo-stat.

This might take a few iterations if you overshoot. You might also want to adjust the altitude in several steps to reduce how much you overshoot by. This is not an exact science without some sort of ground tracking. But you should at least be able to make corrections this way, and that should allow you to place the satellite where you want with some effort.

[Macenzie]

The only way I have managed it is to put the craft into a near geo-stat orbit and warp until KSC is about to be directly under me, then burn the apoapsis to geo-stat (and finally circularise). Like K^2 says there isn't really an exact science to this~

[Aphox]

Like K^2 says there isn't really an exact science to this~

Oh, there is. It just requires a lot of math that nobody wants to do.

[Syhrus]

Oh, there is. It just requires a lot of math that nobody wants to do.

KSP in a nutshell there.

[corvus2606]

get into a low parking orbit and stay there until you are on the exact opposite side of the planet from where you want your final orbit to be, then do your burn to raise your apoapsis to geo height, then once you get to the apo, circularise and you should be pretty well above where you want to be.

[Aphox]

Here, I found this.

http://forum.kerbalspaceprogram.com/entry.php/447-Dividing-geosynchronous-orbits

I searched a bit for this but is there any math to launching geostationary probes that are in specific intervals of each other? I'd like 4 comsats that are roughly equal distance from each other orbiting on a geosynchronous orbit over the equator of a body. Is there is any math behind this or is it just easy enough to eyeball?

It wasn't long ago I was asking this very question. There are some awesome people here who helped, so hopefully I wont steer you wrong.

What I do is take all four probes with me. I move to the geosynchronous orbit and circulize it. I then look at how long it takes to make a complete orbit (I use Engineer Redux but there are other ways).

I divide that value by 4 (or however many probes you are launching) and then burn pro-grade until my new orbit is exactly that amount above the orbit time. Sorry, I think I'm getting confusing. As an example, if the orbit time is 4 hours, I would burn a new orbit that takes 5 hours; if the original is 6 hours, I would burn a new orbit that takes 7.5 hours, and so on. (Don't circulize this orbit, it will end up sort of egg shaped with the periapsis lying along the orbit you want)

Then, I release a probe just before what ends up being the periapsis and have the probe circulize it's orbit which brings it's orbit time back down to the original amount (4 or 5 hours in this example). Then as my main ship moves through its longer orbit, I release another probe when it returns to the periapsis and follow the same steps. When done, I end up with four probes each spaced 1/4 of the whole orbit from one another.

EDIT: This will work for any circular orbit. In case you don't already know, the Kerbal Wiki will give you the distance needed to orbit in a geosynchronous manner for each of the planets.

[K^2]

Dividing the orbit is easy enough. But if you want a particular satellite in particular location, you still have to do it by eye. Yes, there are transfer burns that will shift your geostat by a fixed angle, but you are still figuring out the angle pretty much by eye, so it doesn't make that much difference.

[Macenzie]

Oh, there is. It just requires a lot of math that nobody wants to do.

I'm here to fly rockets and make explosions not count! D:

[Reblet]

Another way to nicely spread out satellites, is to use the target function.

Put the first satellite in geosync orbit and the second one in a low parking orbit. Then from your second sat, click the first one in the map view and choose 'set as target'. Next, set up a maneuver node to raise your apoapsis to the geosync orbit. You will now get two markers that show the location of both satellites at closest approach. Adjust your node until they're spaced out as you'd like them to be (in your example, 90 degrees apart), burn at the node, circularize at apoapsis and you should have your satellites in the desired spacing.

If you're not being particularly conservative with launching satellites you can simply launch the first one into any geosync orbit as a 'marker'. If you then want a satellite over a particular area, figure out the angle between the marker location and the target area, and separate your satellite and marker at an equal angle. If you're not too worried about precision, this is fairly easy to do just by eye.

Reblet

[capi3101]

If I'm doing the math right, check the distance between satellites once you've got them roughly in position. You'll want a distance of 4,057,025 kilometers between them (or as close as that as you can manage); that should put them exactly 90 degrees apart from one another. Of course, each one will need to be in a circular orbit at a mean altitude of 2,868,750 km and moving just a smidgen faster than 1009 m/s. Target function will help with the distance between satellites as Reblet mentioned.

[Bashkire]

Thank you very much, guys! Apologies for the late reply, but I've been fairly busy of late with that horrible thing called "life."

Cheers for all the suggestions! Not to put them into practice!

[shand]

what i did was launch a horribly inefficent launch straight up to AP then circularise (ends up with a geostationary just behind KSC), then use mechjeb to launch to RV with that one, but shift the launch angle by your disired difference (90, 60, 30, whatever) once they are in orbit try to match the orbital period.

in ksp its (virtually) impossible to have precise geostat, stationkeeping is required, a drift of 0.5 degree per orbit soon adds up as you time warp to jool

[inkychris]

I have done the calculations for this. Essentially you want to leave at 180 degrees from where the target (eg. KSC) is going to be after the time it takes to Hohmann transfer between the low Kerbin orbit and the geostationary orbit. Both by calculation and simply placing a node (mechjeb helps) the time taken from node to geostationary can be found.

I used a 100km orbit to start and the time was 1h 23m, so you want to calculate the angle Kerbin has rotated in that time.

Kerbin period is 6h so 360/6=60. 60x(1+23/60)=83 so the KSC will have rotated 83 degrees since you left your node and have reached geostationary. Since you want to leave 180 degrees from where KSC will end up, we want to leave 97 degrees behind KSC. This will mean the probe position will have rotated 180 degrees in 1h 23m, when KSC has done 83 degrees, the 2 line up and you simply circularise. Job's a gooden. If like me you are using mechjeb and the coordinates, make sure to be aware that as you rotate counter-clockwise (at low Kerbin orbit), when above the KSC your west value will be 74, it will reduce down to 0, then back up to 180 and back down again. Without knowing this I was burning at the 'wrong' 170 degree mark, so if you use 100km orbit, warp past KSC then to 170 upwards, then past 180 it will come back down to 170, this is when you burn. If you want angles then add and subtract from this point.

With the angles, mechjeb is useful as you can bring up surface info coordinates and leave at 170 degrees west (KSC is at 74) but if you didn't have that you could use time based methods, which again after some calculation I found with a 100km orbit to be leaving 523 seconds which is 8m 43s. You need to be careful with this though as if you place a node above KSC then warp to t- 8:43, the KSC will have rotated and you'll need to readjust accordingly until you're happy with the margin of error. I might have a go at the time based method when setting a node with the probe above KSC then calculating the error and a true departure time but that would just be effort...

Edited June 9, 2013 by inkychris
realised mistake that I hadn't understood yet

[Mars Mullo]

I have done the calculations for this. ...... effort...

Wow... chris... very detailed .. thanks.. but I had to draw this while reading it to try understand your description... I get it now but sheesh .. that is really hard to explain and you did a good job.

[FennexFox]

I might use resonance orbit function of Mechjeb.

Edited October 18, 2014 by FennexFox

[Plusk]

I wouldnt bother with being super precise about geostationary. Floating point will get you anyway. Ive spent hours manualy synchronizing my relay, achieving 6:00:00:01 h orbital period with 0.2something mm/s relative velocity. After 2.5 years of karbal time 3 of the satelites were about 150km offsync. Not a big deal, just sloppy looking.

Also, using RT you might find this useful: link

[bakanando]

I have done the calculations for this. Essentially you want to leave at 180 degrees from where the target (eg. KSC) is going to be after the time it takes to Hohmann transfer between the low Kerbin orbit and the geostationary orbit. Both by calculation and simply placing a node (mechjeb helps) the time taken from node to geostationary can be found. I used a 100km orbit to start and the time was 1h 23m, so you want to calculate the angle Kerbin has rotated in that time. Kerbin period is 6h so 360/6=60. 60x(1+23/60)=83 so the KSC will have rotated 83 degrees since you left your node and have reached geostationary. Since you want to leave 180 degrees from where KSC will end up, we want to leave 97 degrees behind KSC. This will mean the probe position will have rotated 180 degrees in 1h 23m, when KSC has done 83 degrees, the 2 line up and you simply circularise. Job's a gooden. If like me you are using mechjeb and the coordinates, make sure to be aware that as you rotate counter-clockwise (at low Kerbin orbit), when above the KSC your west value will be 74, it will reduce down to 0, then back up to 180 and back down again. Without knowing this I was burning at the 'wrong' 170 degree mark, so if you use 100km orbit, warp past KSC then to 170 upwards, then past 180 it will come back down to 170, this is when you burn. If you want angles then add and subtract from this point. With the angles, mechjeb is useful as you can bring up surface info coordinates and leave at 170 degrees west (KSC is at 74) but if you didn't have that you could use time based methods, which again after some calculation I found with a 100km orbit to be leaving 523 seconds which is 8m 43s. You need to be careful with this though as if you place a node above KSC then warp to t- 8:43, the KSC will have rotated and you'll need to readjust accordingly until you're happy with the margin of error. I might have a go at the time based method when setting a node with the probe above KSC then calculating the error and a true departure time but that would just be effort...

This is precisely what you are looking for. I realized far too late that Kerbin rotates below you in your transfer orbit. So if you burn 180 behind KSC you'll actually arrive to KTO about 80-120 degrees behind your actual target depending on your initial orbit (depends on initial orbit altitude and eccentricity).

[Jarin]

Stolen from this very handy RemoteTech tutorial. It's not exact, but I've found this to be remarkably useful:

Just note, that's for your current position. The error is compounded by every degree that kerbin rotates in the time it takes you to reach your maneuver node.

[tbarcello]

Yesterday I was researching this issue and came up with this solution. Although it's not for everyone, because not everyone are using the SCANsat mod, but if you are and you are reading this, just achieve any circular orbit and create apoapsis changing node. You then will be able to see the new apoapsis position on the big map of SCANsat. Then drag the maneuver node until it reaches desired position on the map. I placed my station over KSC this way yesterday. Easy and no calculations at all.

[Yasmy]

For kicks, I just calculated a three-burn eyeball method. The eyeball part is the fact that the initial burn is directly over where you want to be in KEO, such as directly over KSC. This is less efficient than a two burn Hohmann transfer, but in practice, only by a small amount (40 m/s delta-v).

I wouldn't necessarily recommend this method, particularly if setting up a multi-spacecraft constellation. Like I said, I'm just doing this for kicks. I like equations as much as I like explosions. I just figured some people might like a method which is easy to eyeball. As a warning, I haven't fired up KSP yet to test this out.

The method is the following:

1) From circular LKO, perform burn 1 to raise your apoapsis to some radius r1.

2) Orbit an odd number of half orbits, ending up at apoapsis.

3) Burn 2 brings the periapsis up to KEO altitude.

4) Orbit an odd number of half orbits, ending up directly above your original maneuver location.

5) Circularize into KEO.

There are 3 free parameters here to play with: the number of complete orbits before the final half orbits in steps 2 and 4 above, and the number of times Kerbin rotates during the process. Call those integers n, m, and l, respectively. Picking n, m and l, you can solve for r1, the apoapsis for your initial burn, to make sure you end up back over your starting location. Basically, solve for the value of r1 such that the time for (n+1/2) orbits in the initial transfer orbit plus the time for (m+1/2) orbits in the second transfer orbit equals the l times the orbital period of Kerbin, so that Kerbin has rotated an integer number of times by the time you get to KEO after also orbiting Kerbin an integer number of times (n+m+1).

Begin in a circular orbit at altitude 80.000 km above Kerbin sea level.

Perform the first maneuver directly over the location you wish to be in KEO above.

Burn delta-v1 of 622.94 m/s to raise your apoapsis to 2312.348 km altitude.

Orbit 1 and a half times to apoapsis.

Burn delta-v2 = 470.65 m/s at apoapsis to raise the periapsis up to KEO altitude of 2868.741 km.

Orbit 0 and a half times to apoapsis directly over your target location.

Burn delta-v3 = 44.99 m/s at apoapsis to create a circular orbit with period 21599.912 seconds.

Total cost: 1138.58 m/s.

Equivalent 2-burn Hohmann transfer cost = 1099.34 m/s.

Here's my matlab code if anyone wants to play with it. If you don't have matlab, it shouldn't be too hard to make the same code work in Octave, which is free software.

% Released under the MIT License.
% Copyright 2015 by the person known as Yasmy on the ksp forum.
function r1 = find(n,m,l,altitude)
mu = 3.5316e12;
T = 21599.912;
R = (mu * (T/2/pi)^2)^(1/3);
Rk = 600000;
r0 = altitude*1000 + Rk;

F = @(r1)(l*T*sqrt(8*mu)/pi - (2*n+1)*(r0+r1).^(3/2) - (2*m+1)*(r1+R).^(3/2));

[r1,fval] = fsolve(F,(r0+R)/2);

if (r1 < r0) || (r1 > R)
disp('nice solution not found');
else
dv1 = sqrt( mu/r0) * (sqrt(2*r1/(r0+r1)) - 1);
dv2 = sqrt(2*mu/r1) * (sqrt(R/(R+r1)) - sqrt(r0/(r0+r1)));
dv3 = sqrt( mu/R ) * (1 - sqrt(2*r1/(r1+R)));

fprintf('Begin in a circular orbit at altitude %.3f km above Kerbin sea level.\n', altitude);
fprintf('Perform the first maneuver directly over the location you wish to be in KEO above.\n');
fprintf('Burn delta-v1 of %.2f m/s to raise your apoapsis to %.3f km altitude.\n', dv1, (r1-Rk)/1000);
fprintf('Orbit %d and a half times to apoapsis.\n',n);
fprintf('Burn delta-v2 = %.2f m/s at apoapsis to raise the periapsis up to KEO altitude of %.3f km.\n',dv2,(R-Rk)/1000);
fprintf('Orbit %d and a half times to apoapsis directly over your target location.\n',m);
fprintf('Burn delta-v3 = %.2f m/s at apoapsis to create a circular orbit with period %.3f seconds.\n',dv3,T);
fprintf('Total cost: %.2f m/s.\n',dv1+dv2+dv3);
fprintf('Equivalent 2-burn Hohmann transfer cost = %.2f m/s.\n', sqrt(mu/r0)*(sqrt(2*R/(r0+R))-1) + sqrt(mu/R)*(1-sqrt(2*r0/(r0+R))));
end
end

Edited August 24, 2015 by Yasmy

[Scarecrow88]

get into a low parking orbit and stay there until you are on the exact opposite side of the planet from where you want your final orbit to be, then do your burn to raise your apoapsis to geo height, then once you get to the apo, circularise and you should be pretty well above where you want to be.

Actually you will need to be slightly west of directly opposite as by the time you have coasted up to apo, the planet will have revolved below you.

[SanderB]

I just make a maneuver node to the desired apoapsis, take the number of minutes to get there and take that as the exact number of degrees that my post-maneuver apoapsis needs to be to be ahead of KSC in order to be above it within a margin of 5 degrees.

[eddiew]

I approve of the attempt to rationalise and standardise geostationary insertions, but... any effort to go for geostationary in KSP is inherently flawed and doomed to frustration because it forgets to account for:

a) the long time periods involved in KSP

the (impossible) precision required to really, really be stationary relative to the planet

c) the absence of out-of-focus station keeping

In short, anything you place, even precisely to a few metres, will still change its relative position over time. Send a probe to Jool on timewarp, and 'suddenly' your nicely placed geostationary satellite above KSC is half way around the planet. If you had 4 in formation, they could be all clumped up together and therefore useless. Your only option would be to give the satellites a check every few in-game weeks and nudge them around; until they ran out of fuel.

For those looking to build comms networks, a loose collection of Molniya orbits works out much better. Here the basic premise is to have satellites on widely spaced, highly eccentric orbits and operate under the statistical average that 'one of them' will be high in the sky 'somewhere' over KSC at any given time. The more eccentric the orbits, the less likely it is that all of them will simultaneously be found at periapsis and unreachable, and the more likely they are to be contactable from the ground. A handful of pseudo-random elliptical orbits generally provides coverage that is so close to being perfect that you don't worry about it - and you don't have to deal with orbital drift. At an extreme, go polar, and put the AP somewhere between Mun and Minmus, and the PE at 71km. You'll get many days of accessibility on that side of the planet for every 5-10 minutes of blackout.

Once such a network is up, it stays up. It may occasionally have 5 minutes of down time, but for the vast majority of its existence it will be reachable

(Also, brilliant necro - but in fairness, this sort of thing is still relevant )

[GoSlash27]

(Also, brilliant necro - but in fairness, this sort of thing is still relevant )

It will definitely be useful when the new update drops.

We had a challenge a few months ago to accomplish this very thing.

http://forum.kerbalspaceprogram.com/threads/121635-KASA-Preferred-Vendor-challenge-2-is-up!

The way I did it definitely took some mathing.

http://s52.photobucket.com/user/GoSlash27/slideshow/KSP/Vendor%20challenge%201

1) Launch the satellite into a convenient periodic parking orbit*.

2) Track the satellite from the ground at KSC and mark the time of it's passage overhead.

3) The satellite's longitude is now a function of time.

4) Compute the transit time between the parking orbit and KSO.

5) Compute the transfer window backwards.

5a) Compute how far Kerbin will rotate in the transit time

5b) Compute the satellite's longitude at transfer (180°-rotation)

5c) Compute the time to initiate transfer

6) ???

7) Profit!

This can be put into a spreadsheet once you've got the process sorted out.

*periodic parking orbit: An orbit that passes overhead KSC an integer number of times per day. I used 10 times per day (once every 36 minutes) so that the math was easier.

Best,

-Slashy

*Edit* very simple procedure for parking a kerbostationary sat directly overhead KSC:

1) Launch into a parking orbit at 101,306m altitude

2) Mark the time that it passes overhead KSC from a guidance unit on the ground.

3) Burn for transfer to KSO 26m 23s later. Ap 2,868,723m , maneuver costs 650 m/sec

4) circularize at Ap. Maneuver costs 424 m/sec.

Edited August 24, 2015 by GoSlash27