In-plane launch window

Blake

Addon Developer
Addon Developer
Joined
Mar 9, 2009
Messages
295
Reaction score
241
Points
58
Location
Lehi, Utah
Stated simply, I hope, what is the math behind determining when a surface base location is within an orbital plane given that plane's elements (LAN, Inc etc).

Stated another way, the advice when launching for rendezvous with IIS is to pull up the Map MFD and wait for the target orbit line to line up with your base location. That is the time to launch (roughly).

How can this be determined algorithmically given the target orbital elements?

My google skills seem to have failed me in finding this.

Thanks.
 
Thanks, and yes, I want to learn how to do this by hand.

I'll dig into that information.

---------- Post added 06-08-14 at 01:29 PM ---------- Previous post was 06-07-14 at 09:16 PM ----------

Ok, I'm not seeing what I need in those links, but that may just be me. I could also begin reverse engineering the LaunchMFD code, but I think there must be a better way.

Let me explain a bit more what I'm interested in.

I want to add 'flight director' type functionality to some basic controls. For example, given a target inclination you can use the following formula to determine the launch azimuth:

launch azimuth = arcsin(cos(target inc) / cos(latitude))

This is explained here: http://www.orbiterwiki.org/wiki/Launch_Azimuth

You could use the output of that to drive an arrow on an HSI that gives the pilot the proper header to follow to achieve a desired inclination. At least that it my understanding.

The wiki article explains how to refine that formula for more accuracy, but for now that will work--baby steps.

The next step is to know when to launch, and that's what brings up the target plane question.

Given the desired 'inc' and 'LAN' of the target orbital 'plane', and the known latitude and longitude position on the planet surface, is there a formula for determining when that position is passing through the target orbital plane?

The answer may be that it is really hard, and that is why NASA pays out the big bucks to math majors. If that's the case I'll spend some quality time with the LaunchMFD code (which I will likely do anyway).

Thanks for any info.
 
Blake said:
The answer may be that it is really hard, and that is why NASA pays out the big bucks to math majors. If that's the case I'll spend some quality time with the LaunchMFD code (which I will likely do anyway).

I wanted to take a crack at this without reading the links, to see if I can get it right. Turns out that it's not very hard to do. A little bit of spherical trigonometry and you are set.

First we have to find what the launch window's "conditions" are. We have three separate cases.

1st case: The target orbit has a lower inclination than the latitude of the launch site. [math]T.Inc < [/math]
In this case launching in plane with the target orbit is impossible. The best we can do is launch at a 90° heading when the LAN of the target orbit is the same as the LAN of the of the spacecraft (as shown in OrbitMFD from the EQU frame). The resulting relative inclination to the target orbit will be:[math] R.Inc = L.Lat -T.Inc [/math]

2nd case: The target orbit has the same inclination as the latitude of the launch site. [math]T.Inc = L.lat[/math]
This is a best case scenario. We launch at a 90° heading when the LAN of the target orbit is the same as the LAN of the spacecraft (as shown in OrbitMFD from the EQU frame). The resulting relative inclination to the target orbit will be zero.

3rd case: The target orbit has a higher inclination than the latitude of the launch site. [math]T.Inc > L.lat[/math]. In this case we want to launch with a specific launch azimuth when the LAN of the target orbit and the LAN of the spacecraft have a specific difference. Have a look at this pic:
launchwindow2_zpsfe275e2a.jpg

Here we have the orbital plane of the ISS and the landed spacecraft near the time of launch. (the plane of the ISS is about to cross the launch site).
That "shark-fin" in MapMFD is a spherical triangle projected in 2D. In the blue window below you can see a "zoom" of it.

The points A B and C are:
A = Launch site
B = LAN of the target orbit (equatorial)
C = LAN of the landed spacecraft's "orbit" (equatorial)

The angles α β and γ are:
α = Launch latitude [math]L.lat[/math]
β = 180° minus the target inclination [math]180^{o}-T.Inc[/math]
γ = "Rough" Launch Azimuth = [math]acos \left( \frac{cos(T.Inc)}{cos(L.lat)}\right)[/math]

a b and c are also angles, this time one point is at the center of the Earth. If we name the center of the Earth "D" then the angle [math]A \hat{D} B[/math] is the angle a and so on.
What we are interested in is the angle c, which is the difference in LAN at the time of launch. Since we know the angles α β and γ, we can use the spherical law of cosines and solve for c

[math] c = acos \left ( \frac{cos\gamma + cos \alpha cos\beta}{sin\alpha sin\beta} \right)[/math]

Let's try an example with the orbits shown in the pic above. We have a launch latitude of 28.63° and the target inclination is 51.52°
α = 28.63°
β = 180° - 51.52° = 128.48°
γ = [math] acos \left( \frac{cos(51.52^{o})}{cos(28.63^{o})}\right)= 44.853^{o}[/math]

[math] c = acos \left ( \frac{cos(44.853^{o}) + cos(28.63^{o}) cos(128.48^{o})}{sin(28.63^{o}) sin(128.48^{o})} \right)=64.28^{o}
[/math]
So we need to launch when the LAN of the target orbit and the LAN of the spacecraft have difference of ±64.28°.
To find the accurate launch azimuth, you can use the equations from the link from OrbiterWiki.
The rate of the rotation of the landed spacecraft's LAN is 360°/siderial day ~ 0.25° per minute.

There are more things to take into consideration, such as the time the spacecraft needs to reach orbital velocity and also the rate of the nodal regression of the target orbit (if you are flying with nonspherical gravity switched on), but I hope this will do for now.

:cheers:
 
Last edited:
Thanks, that is a lot of great info. I now have some homework to do.

I'll report back how it goes.
 
dgatsoulis gave some good info, but I think you want the hour, minute, and second that you should launch. If so, then what you need is in the link I provided.

As mentioned, there is some additional complexity due to Earth's rotation and finite launch time, but you should be able to at least estimate the geographical longitude of the ascending node given your initial longitude, latitude, and heading.

The key idea here is this paragraph:

The longitude of the ascending node, omega , is measured in celestial longitude, while lambda 1 is geographical longitude. The celestial longitude of the ascending node is equal to the local apparent sidereal time, in degrees, at longitude lambda 1 at the time of engine burnout.

Here is a link to help find approximate sidereal time.
http://aa.usno.navy.mil/faq/docs/GAST.php

Given the desired 'inc' and 'LAN' of the target orbital 'plane', and the known latitude and longitude position on the planet surface, is there a formula for determining when that position is passing through the target orbital plane?

The answer may be that it is really hard, and that is why NASA pays out the big bucks to math majors.

:facepalm:

The people that make the "big bucks" know that you can't always find an explicit solution for what you are trying to find. They know how to use numerical methods to find what they need.

In this case, you have launch time as an independent variable from the info provided. I don't know if you can solve for launch time explicitly.

IMHO, it would at least be easier to advance the launch (or burnout) time in small increments until the resulting LAN is what you need to some small tolerance.

It's okay to work backwards.
 
Last edited:
Noting that there's still a gap between calculating data and displaying in on the flight director, here's how Launch MFD finds angle to the intersection.

And here's the targeting class, which calculates the timeToNode you're looking for, for both in-flight and on-pad situations, including LAN drift calculation due to Nonspherical gravity sources.

I can't be more elaborate - I'm either overworked or looking for a new job (my current status).

The people that make the "big bucks" know that you can't always find an explicit solution for what you are trying to find. They know how to use numerical methods to find what they need.

It appears so. It's more about their CPUs than RAM banks :)
 
Last edited:
Back
Top