Building the ISS LVLH frame in ECEF/ITRF coordinates

Question

I am trying to calculate the International Space Station (ISS) LVLH (Local-Vertical-Local-Horizontal) base vectors expressed in the ECEF/ITRF frame at a given time. The point is then to calculate the rotation matrix to rotate vectors in ECEF to LVLH (and vice-versa).

I have a procedure to do that, but I am not sure if it is done properly. So that's why I am asking help here to check what I am doing, presented next.

The ISS LVLH frame is defined as in the following picture:

Lets consider a specific time: 2019-Mar-24 00:31:53.135444 UTC.

First, the Skyfield library in Python is used to get the ISS position and its velocity vector for a specific time using the ITRF_position_velocity_error method of the sgp4lib.EarthSatellite class :

Longitude (deg), Latitude (deg), Altitude (km) : 55.34071583, 0.10055032, 408.59435164
Position unit vector (ITRF) : R == (0.56869428, 0.82254713, 0.00174319)
Velocity unit vector (ITRF) : V == (-0.47416977, 0.33092048, -0.81587662)

(The used TLE is :
1 25544U 98067A 19083.06129885 -.00367384 00000-0 -62017-2 0 9991
2 25544 51.6362 64.4008 0003657 146.0534 252.6576 15.52294152162032)

Then the LVLH X-Y-Z base vectors are calculated with :

Z = - R / ||R||
Y = Z X V
EDIT: should be : Y = Z X V / ||Z X V||
X = Y X Z

Which, in this case gives the values:

X = (-0.47480547, 0.33000101, -0.81587857)
Y = ( 0.67167383, -0.4631578 , -0.57821957)
Z = (-0.56869428, -0.82254713, -0.00174319)

Then, calculating the rotation matrix and inverting it is straightforward.

Is this method correct ?

Thanks in advance for the help.

Answer 1

Is this method correct ?

Not quite. You are assuming that $\hat r$ and $\hat v$ are orthogonal. A quick check shows that this is not quite the case. The ISS's orbit is not quite circular.

This means that while your $\hat y$ points in the right direction, it is not a unit vector. You can make it a unit vector by dividing by the magnitude. Then you can calculate $\hat z = \hat x \times \hat y$. Unfortunately, this also will not be a unit vector due to the vagaries of floating point arithmetic, but it will be very close.

Answer 2

Looks right to me to a first approximation.

One useful sanity check is that X comes out close to V (because the orbit is close to circular and thus V was already almost perpendicular to R to begin with).

Another is to note that the ISS was about to cross the equatorial plane (the ITRF $z$ coordinate of R is almost zero) and moving in a direction a little further south than southeast: V forms an angle of 54.67 degrees with this plane. This is larger than the 51.6° orbital inclination because the ITRF is co-rotating eastward with the Earth. The velocity unit vector expressed in an inertial frame would have a slightly larger component towards local east and would thus form a more acute angle with the equatorial plane.

However, I believe you'll have to compensate for this "aberration" effect to get the correct Y and then X. (Consider a LEO satellite in a circular polar orbit at the moment it crosses the equatorial plane from south to north. It will have the north celestial pole right in front of it: X = (0, 0, 1). But its V in terms of the ITRF will point a bit W of due north because the ITRF keeps moving eastward by roughly half a km/s above the equator, the precise value depending on the satellite's altitude.)

Answer 3

The main problem I see is that the included image does not actually define what we need to know. It shows where the axes are oriented with respect to the shape of the station, but says nothing about where any of those directions point. Even working with a spin-stabilized spacecraft or a spinning planet, there is no necessary relationship between the axis of one body's rotation and the axis of orbital revolution about the other body. With a three-axis control system like a group of CMGs provide, the satellite operator can choose whatever direction they want at any time. There's nothing that defines what relationship is actually commanded in practice, whether it has to do with +Z matching ±R, ±V, ±R$\times$V, or pointing at the center of the sun, the star Arcturus, the operator's house, or anything else.

The comment claiming LVLH is "well defined" is incorrect. Different references label the same axes with different letters, causing two things which both say they are LVLH to disagree. Even if two references agree on which direction is vertical, and which letter goes with it, any two perpendicular directions in the horizontal plane are just as valid as any other choice.

For example, if you use STK, its online help defines LVLH as

• the X axis is along the position vector $+\vec{R}$ (position)
• the Z axis is along the orbit normal $+\vec{R}\times\vec{V}$ (orbit normal)
• the Y axis is toward velocity $\vec{Y}=\vec{Z}\times\vec{X}$

If instead you use FreeFlyer, its online help defines LVLH as

• Z-axis: Vector pointing in the opposite direction to the position vector (points to center of Earth)
• Y-axis: Vector pointing in the opposite direction to the orbit normal (the orbit normal is the cross product of position and velocity)
• X-axis: Vector perpendicular to the y- and z-axes, forming a right-handed coordinate system

To get STK to give you what FreeFlyer calls LVLH, you have to ask for not LVLH, but VVLH ("Vehicle Velocity, Local Horizontal") instead.

Trying to find what the ISS in particular uses led here and here. The first of those says LVLH on the ISS usually means +Z = -R and +X towards +V, but sometimes they yaw 90 degrees (but doesn't say whether that turns +X into +Y or -Y) into an alternate LVLH, and sometimes they point X perpendicular to the orbit plane and let Z point wherever it happens to land. The second says the transition from +Z nadir to near-inertial depends on solar angle from the orbit plane, but also even that is too simple, as in so-called LVLH they actually fly slightly off in order to cancel drag torque.

If you want to know where something is, based on its position relative to the body axes of the ISS, the letters "LVLH" alone are simply not enough.