Switch to ANISE for ECEF (IAU Earth) computation

[ChristopherRabotin]

Following our conversation from https://github.com/orgs/nyx-space/discussions/310, I'm proposing switching to ANISE for the computation of the Earth centered Earth fixed (ECEF) position and velocity. Note that, in my experience with deep space navigation, we typically use only the "IAU Earth" or the augmented "ITRF93" frames: both are Earth centered Earth fixed frames, but they are more rigorously defined. The IAU Earth frame uses the precession, long term and short term nutation parameters defined here. The ITRF93 frame is a frame reconstructed from the actual observations of the stars: it is more precise than the IAU Earth frame, but that precision is rarely needed for Earth orbiting spacecraft.

One of the main issues with the work I present here is that ... I've not been able to test it! I wasn't sure where to find some test code. This proposed change modifies the signature of the functions to require the addition of an Almanac.

In this specific case, because all of the GNSS spacecraft orbit the Earth, all you need to do is load the planetary constants kernel file (either version 08 or version 11, the Earth data did not change in between these). I recommend simply specifying the Almanac using a MetaFile as done here: https://github.com/rtk-rs/gnss-rtk/pull/16/files#diff-cbd16a2b1fdb7e2f39b676831dfaee5250000b403a9f1fcfcbfede424d7cbf73R220 .

Let me know if you have any questions! I'd like to test this together if possible because I want to check that my inputs to try_keplerian are correct, especially when it comes to the units.

P.S.: Sorry for the extra stuff that may have changed due to formatting, I've got a bunch of fixes done automatically for me because I'm too lazy to execute the formatting tool.

[gwbres]

To clarify one topic, as it may not be obvious: RINEX Navigation (therefore, this contribution), provides Orbital positions when navigating without SP3 files. So it is one of the possible navigation scenarios (what the user provides), equally important, and whether it is real time or post processed does not matter (SP3 is not adapted to real time unless you have prediction, as discussed on other occasions).

we typically use only the "IAU Earth" or the augmented "ITRF93"

This still applies, ITRF93 - and newer - are prefered in SP3, because that scenario targets ultimate accuracy

One of the main issues with the work I present here is that ... I've not been able to test it! I wasn't sure where to find some test code. [..] I'd like to test this together if possible because I want to check that my inputs to try_keplerian are correct, especially when it comes to the units.

All previous tests of kepler2ecef have been removed. They consisted in comparing our results to the ones obtained with python::georinex working from the same input. It was very tedious to set up, is not an ideal test scenario either. The current state is our best state ever (resulting from all my testing and external contributions as well), it was manually verified by actual navigation with rinex-cli, it is not self tested within the library.

As a library this is unacceptable, but if the feature is taken care by ANISE in the future, it can remain as is

I had to patch the proposal to pass compilation.
I simply commented out the SP3 option from rinex-cli::navigation, it fails because it uses the nyx::Cosmic kernel.
Could you simply rework the includes so they do pass ?

If you use the commented out proposal, we have 3 CI navigation related tests that faill on the same error:

cargo test --all-features # all this topic comes with "navigation" option

The proposal forbids navigation with SP3, if you deploy rinex-cli -p (post processed navigation) without SP3, we see the almanac is downloaded in a few millisecs, and it eventually fails on try_keplerian

./target/release/rinex-cli \
   -f test_resources/CRNX/V3/ESBC00DNK_R_20201770000_01D_30S_MO.crx.gz \
   -f test_resources/NAVV3/ESBC00DNK_R_20201770000_01D_MN.rnx.gz \
   -P GPS -p | tee logs.txt

Please note that V0.17 (sbas branch) will have a scripts/example database, that vastly helps getting started at deploying basic tasks like this

rinex/src/navigation/ephemeris.rs l362
Result::unwrap()  MissingFrameData : action "retrieving gravitational paramaters", data: "mu_km3_s2" frameUid 339

One way to understand what happens would be to debug print the quantities being passed as input

Sorry for the extra stuff that may have changed due to formatting, I've got a bunch of fixes done automatically for me because I'm too lazy to execute the formatting tool.

I have no problem with that, is that VS Code that you use? it even formats the Cargo.toml files

[ChristopherRabotin]

Concerning the validation of the rotation, ANISE validates the rotations using SPICE, cf. the "PCK" and "BPC" steps from https://github.com/nyx-space/anise/actions/runs/9610037560/job/26519123120 . SPICE is the state of the art of this kind of work and has been used for deep space navigation since 1990 (and ANISE is a modern rewrite of SPICE, with some additional features).

I'm working on the other changes now.

[ChristopherRabotin]

One more step for you before you can test: you need to add the de440s.bsp file to the new data folder in gnss-rtk, which I could not add because Github prevents users from adding git lfs files to public forks. This data folder will be embedded in the built application using https://crates.io/crates/rust-embed. You may find a copy of de440s.bsp at https://github.com/nyx-space/anise/blob/master/data/de440s.bsp .

Eventually, I'll fix nyx-space/anise#262: this will allow you to embedded a much smaller file than this 32 MB file. The DE440s.bsp contains 100 years of planet positions for all of the inner planets and all of the barycenters of the gas giants, which is data you most likely don't need. Once I fix this bug, you can probably just embed the position of the Earth, the Earth Moon barycenter, and the Sun, and for only ten years, so probably bringing down the file to 1 MB or so.

I forgot to mention that I have a linker issue when I try to build rinex-cli, so I can't test the binary with the command you ran. The code builds, it just doesn't link...

[gwbres]

The RINEX lib does not depend on RTK-RS so anything that happens in Rinex::navigation needs to be standalone.

this will allow you to embedded a much smaller file than this 32 MB file [...]
so probably bringing down the file to 1 MB or so.

I'll have to keep track of this.

I will test the new version tonight

[gwbres]

other calculations I did not think of, that can also be replaced, is what happens inside Navigation::elevation_azimuth

[gwbres]

The navigation library works fine now 👀

Surveying without SP3 does deploy (relying on RINEX::Navigation), SV states look correct. The solver seems to fail to truly initiate itself, not a single solution is produced, we always wind up in the new error:

• pvt solver error "physics issue: retrieving gravitational parameter requires the frame Earth J2000 to have mu_km3_s2 defined"

./target/release/rinex-cli \
       -f test_resources/CRNX/V3/MOJN00DNK_R_20201770000_01D_30S_MO.crx.gz \
       -f test_resources/NAV/V3/MOJN00DNK_R_20201770000_01D_MN.rnx.gz \
       -f test_resources/CLK/V3/GRG0MGXFIN_20201770000_01D_30S_CLK.CLK.gz \
        -P GAL -P C1C,C5Q,L1C,L5Q -p

Surveying with SP3 (relying on rinex-cli::navigation::sp3 does not work, as the Almanac fails to be built.
de440s = AstroData::get("de440s.bsp").unwrap() fails. It looks like there is a problem with the rust-embed setup

./target/release/rinex-cli \
       -f test_resources/CRNX/V3/MOJN00DNK_R_20201770000_01D_30S_MO.crx.gz \
       -f test_resources/NAV/V3/MOJN00DNK_R_20201770000_01D_MN.rnx.gz \
       -f test_resources/CLK/V3/GRG0MGXFIN_20201770000_01D_30S_CLK.CLK.gz \
       -f test_resources/SP3/GRG0MGXFIN_20201770000_01D_15M_ORB.SP3.gz \
        -P GAL -P C1C,C5Q,L1C,L5Q -p

[ChristopherRabotin]

Ah, small steps, but we'll get it to work eventually!

For the azimuth and elevation, I can have a look tonight. You may also wish to consider using the ANISE function directly for this: https://docs.rs/anise/latest/anise/almanac/struct.Almanac.html#method.azimuth_elevation_range_sez. Do whichever you prefer. The anise computation is used in deep space planning and the values have been checked by many people.

Concerning the de440s.bsp file not found, have you added that file to gnss-rtk and rebuild? I was not able to add that file because of the github limitations on git lfs. Once the file is added, you need to rebuild because the file is added at build time. If the error persists, can you print the error? Is it that the file isn't found, or is it a decoding error in anise?

[gwbres]

Concerning the de440s.bsp file not found, have you added that file to gnss-rtk and rebuild? I was not able to add that file because of the github limitations on git lfs

Oh ok I did not get that. I just enabled the Git LFS archive

It does not make sense for the solver to ship those files, now that we have ANISE.
And I would argue that you could integrate a default/basic model and all the others (more accurate and heavier) could be downloaded using your infrastructure

[gwbres]

I should not have moved to hifitime-4 until it was released. I made a bad decision and can only be angry at myself.
And this simple bad decision, has pretty much taken all the fun from these projects right now

[ChristopherRabotin]

What is the issue you're getting? I was going to release 4 alpha tonight so I can release anise with it too.

[gwbres]

well. At this point, the only conclusion is to continue the ongoing process, the gain in performance and overall sanitization superceeds any other topic or my personal opinion, and I'm also too bored to bring everything back to hifitime-3.
I'm also just a beginner regarding your ANISE toolbox so my opinion cannot be definitive, and things might evolve as well.
I need to read its documentation and become more familiar prior anything else.

Even if the current deployment requirement remain what they are, it is possible to imagine an "init script" people could run prior initial deployment. It does not facilitate the workflow, but even with that extra step, our ecosystem still remains much easier to grasp than past environments like RTKLIB or NASA solutions

[ChristopherRabotin]

I understand your frustration, sorry, it wasn't my intention. For version 0.4.0, the next version of ANISE, I'm adding that embedded file right now so that you don't have to deal with it. For version 0.4.1, I'll change the embedded file to only cover 11 years (instead of 100) so that it's valid only until 2035.

I was hoping to code this up before work, but I'm out of time. I'll release anise 0.4.0 in 12-14 hours.

[gwbres]

Hello @ChristopherRabotin,

no need to rush anything, I'd rather wait then having to deal with bad decisions.
If maybe you can simply add this file to your gnss_rtk pull request, whatever its size (we'll the final decision when all topics are merged), I could point to your fork temporarily, and we can get rinex:main back up running (i'm working on other topics like RinexQc right now, so it's really not that important)

[gwbres]

I updated everything. Considering we will have a temporary phase where Internet access is required (unrelated topic) ;

Both navigation scenarios now fail to produce anything, because we're getting PhysicsError : retrieving gravitational parameter requires the frame Earth J2000 to have mu_km3_s2 defined

[gwbres]

Until all these topics are not solved, the RINEX crate will be in failure, and it contains many evolutions comparing to its last release.
Because we don't have possibilities to have hifitime 4 + gnss-rtk (due to nyx requirement)

[ChristopherRabotin]

If you enable the "embed_ephem" feature, then you can use this function to load an embedded version of the planetary data: https://github.com/nyx-space/anise/blob/master/anise/src/almanac/embed.rs#L20. Have you tried that approach yet?

[gwbres]

rust_embed does not work.
network access is not vital, we can either deal with that right now by fixing it or it can be dealt with later.
Right now it complains the AstroData does not exist nor the .get() access method.

What is more problematic is this branch does not generate results and currently only you can fix it.
I will try to understand what the problem is in the next few days.

My next move right now is to merge rtk-rs, so we can get our tools back.
This PR will finalize the upgrade to nyx-2.0 but it requires more work

[gwbres]

I'm merging, it's the only option to get RINEX working again.
I've pretty much decided not to go back to hifitime-3, although it leads to a temporary faulty behavior (until this is fixed)

Let me know if you have any questions! I'd like to test this together if possible because I want to check that my inputs to try_keplerian are correct, especially when it comes to the units.

try_keplerian is in failure, you can use this portion of code by running the position solver

./target/release/rinex-cli \
       -f test_resources/CRNX/V3/MOJN00DNK_R_20201770000_01D_30S_MO.crx.gz \
       -f test_resources/NAV/V3/MOJN00DNK_R_20201770000_01D_MN.rnx.gz \
       -f test_resources/CLK/V3/GRG0MGXFIN_20201770000_01D_30S_CLK.CLK.gz \
       -f test_resources/SP3/GRG0MGXFIN_20201770000_01D_15M_ORB.SP3.gz \
        -P GAL -P C1C,C5Q,L1C,L5Q -p

pvt solver error "physics issue: retrieving gravitational parameter requires the frame Earth J2000 to have mu_km3_s2 defined"

I will double check the values we pass forward tonight