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.
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.
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.
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!
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.”
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.
Hi there, dear Orekit Developers,
I know it’s a longer time since you discussed this topic. However, I just detected this entry and think it’s anyway a sustainable subject, so I briefly wanted to share a thought about it: When developing, I also repeatedly encounter these kind of considerations, and when it came to ‘LVLH’, I remember that I always had to look up how it actually was defined. It is different with denoting a frame as RTN which rather uniquely describes the definition of the coordinate axes of the orbital frame: radial/(along-)track/normal). Once I wanted to have X towards velocity, and to give it the right name I chose (for myself) the term VNR for it (I personally can also live with RTC or VCR, too, i.e. Cross instead Normal). VNR actually just exchanges axes names versus RTN and so is not really a gain. But also again, it is fully self-explanatory, and on a simple basis, the sequence always being in accordance with XYZ. By contrast, for the use of LVLH it came for me also to a point where I experimented with using the “LVLH” name also as the identifier for the Local horizontal or Tangent Coordinate system, LTC, of a ground station connected tangently with the ellipsoidal Earth model, which of the latter I originally learnt to denote LTC. Actually, also LTC is insufficient when one wants to immediately recognize its axes definitions, what in turn lead me to rather using ‘ENU frame’ (East-North-Up) instead of the former two descriptors LVLH or LTC.
As you certainly realized already, I want to contribute just another factor of experience on this topic, and that for me mnemonics is an important factor in using abbreviations for coordinate frames while developing or operating, and I personally deem it a reachable goal to some extent. So I wonder: what had to be done in future in order to find a consistent way to eliminate less useful redundancy and have clear definitions (for developers) instead? Is it a way that standardization should aim for here? What I certainly want to say is that LVLH appears to me as a rather practically unfortunate choice of a name for the orbital rotating frame, which is the root-cause in my view that lead to the existing historical diversity in defining axes directions for the very same frame identification name. Thus, unfortunately, the same applies similarly to LVLH_CCSDS, lacking the same immediate recognition factor when it comes to the question which axis is which. As a plus, I see the CCSDS complement at least makes it traceable, of course, and so I think too it’s basically a good idea to add. And this supports to use always additional names instead of renaming/replacing old ones, just for sake of maintaining legacy interfaces and use cases and to help avoiding even more confusion. Probably, there may be applications (projects) that simply require to use LVLH / LVLH_CCSDS; so finally, I agree with the other above mentioned, that in case there is a more general identifier like LVLH to be selected/adopted, documentation (project or applied standard reference) certainly is inevitable. Hope I, as being an FD engineer, could contribute some valuable thoughts here. Best regards, Frank.
I understand your concerns and agree clear naming is paramount to avoid confusion. Orekit is however a library aimed at supporting existing conventions, it is not a standardization committee so we cannot impose our own names. All we can do is continue what we have already done: pile up several alternative names for the same things, like QSW/LVLH or VVLH/LVLH_CCSDS.
We could add ENU if needed. It is not often used in orbits (rather for ground or close to ground receivers), but I have seen it used once for satellites (by someone who came from ground receivers background).