Different LVLH conventions

Orekit development
#1

Hi all,

While working on the upcoming CCSDS ODM V3 standard, I stumbled upon conventions differences in the LVLH (Local Vertical, Local Horizontal) definition.

What we used up to now, is consistent with the definition used by Vallado’s book section 3.3.3 and in AGI STK help, i.e. the X axis is radial (pointing away from central body) and the Z axis is aligned with orbital momentum. This local orbital frame is therefore the same as QSW, RIC (Radial, In-track, Cross-track), RTN (Radial, Transverse, Normal) and Gaussian coordinate system.

However, it seems to me everyone else is using a different convention for LVLH. This alternative convention sets Z to nadir and Y opposite to momentum (hence X is towards velocity). This definition is used in CCSDS standard through SANA registry, it is used in Wertz books, is used in FreeFlyer and is in fact also already supported in Orekit under the name VVLH. Vallado states other definitions for LVLH exist (but the alternative he cites is not exactly this one).

I think that it is better to be consistent with standards like CCSDS rather than only other software. Indeed, I guess that as AGI will implement ODM V3 they will probably adopt this convention too (I have not asked them yet). So I think I should rename VVLH into LVLH and remove the old definition of LVLH.

What do you think?

#2

In my own experience I’ve seen many definitions of LVLH similar to the ones you mention. It seems each group adopts the definition of the text book or software they use. As you mention the confusion is already widespread in the community. I think renaming a constant would cause more confusion for Orekit users as now we would need to search our code and documentation and update it. Perhaps a better route would better route would be to add to the documentation for the local orbital frames from your original post. Describe the confusion that exists and provide a guide of if you’re coming from this text book or software then this is the mapping between the Orekit local orbital frames and the names you’re used to.

In the end though I think the best thing is clear definitions of frames, which Orekit already does well.

Regards,
Evan

3 Likes
#3

As Ewan, I think that changing the name VVLH into LVLH would bring a lot of confusion for Orekit users. If someone used LVLH with a previous Orekit version, the axes would change in the new version ! Why not creating a new LVLH constant called for instance LVLH_CCSDS (actually equal to current VVLH). It is not very elegant but it would not break anything.

#4

You are right.

I will therefore keep LVLH and add LVLH_CCSDS.

I will also deprecate VVLH. Indeed, I cannot find anymore where I found the definition of VVLH, which seemed awkward since the first ‘V’ stands for velocity but the frame is not aligned with velocity at all!

#5

The American National Standard ANSI/AIAA S-131-2010, Astrodynamics - Propagation Specifications, Technical Definitions, and Recommended Practices, closely follows Vallado’s book in most ways, because Vallado chaired the committee that wrote it. When it comes to define the LVLH coordinate system, however, it gives several different options, and says “The use depends on the particular organization. Consistency and documentation are the important requirements.”

AGI follows Vallado’s book closely because he’s worked there since 2004. VVLH (Vehicle Velocity, Local Horizontal) comes from AGI’s documentation. Its X axis coincides with velocity when velocity and radial vector are perpendicular, which Vallado’s book calls “along track” (RSW) rather than “in track” (NTW). You might consider adding these as additional names, rather than deprecating VVLH.

The design question for Orekit is, do you want to try to pick just one convention and enforce it, or is the goal is to support whatever convention the user might prefer? I lean towards giving multiple options, with plenty of documentation, as Evan said “provide a guide of if you’re coming from this text book or software then this is the mapping between the Orekit local orbital frames and the names you’re used to.”

1 Like
#6

Hi Ryan, I was not aware of that standard. That’s nice to know about.

#7

OK, I will not deprecate VVLH, and add it is kept for compatibility with STK.
I will however add a warning that the name is misleading: none of the vectors is perfectly aligned with velocity.

Orekit is a low level library, it should comply to the upper layer requirements and conventions. So we try to propose multiple choices when possible. When there are conflicts, and in particular naming conflicts, some workaround has to be found. I will use Sébastien’s suggestion and add a LVLH_CCSDS constant.

1 Like
#8

Sounds good, thank you. More warnings are always useful!