gwbres
commented
2 weeks ago 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" optionThe 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.txtPlease 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 339One 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
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
MetaFileas 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_keplerianare 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.