-
-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GNSS #298
GNSS #298
Conversation
Signed-off-by: Guillaume W. Bres <guillaume.bressaix@gmail.com>
Signed-off-by: Guillaume W. Bres <guillaume.bressaix@gmail.com>
Typical GNSS specs define the flattening and the semi-major axis. I had to search for the semi-minor axis radius. I used one of your formulas (M+m)/2, to obtain the polar radius, which is rarely given |
Signed-off-by: Guillaume W. Bres <guillaume.bressaix@gmail.com>
I presume the best thing to do, would be to propose new [Frame] constants, similarly to But I don't know if it can relate to the existing NaifID system. I'll let you take a look at the current state, and let me know what your ideal solution is |
What is the current behavior of ANISE, when two Orbits are considered and they do not have the same shape ? |
If the frames of two different orbits have different shapes, it should only affect the computation of the latitude, longitude, and altitude because all of these are computed with respect to the geoid. The equality between two orbits does not look at the shape of the frames, only the orientation and center. |
Signed-off-by: Guillaume W. Bres <guillaume.bressaix@gmail.com>
Signed-off-by: Guillaume W. Bres <guillaume.bressaix@gmail.com>
Signed-off-by: Guillaume W. Bres <guillaume.bressaix@gmail.com>
moved to rtk-rs/gnss#8 |
Signed-off-by: Guillaume W. Bres <guillaume.bressaix@gmail.com>
Summary
I would like ANISE to propose options to deal with GNSS orbits.
In GNSS navigation, we resolve (x, y, z, dt) by gathering (sv_x, sv_y, sv_z, sv_dt) from 4 satellite vehicles.
(sv_x, sv_y, and sv_z) are streamed over radio signal by each individual vehicle and expressed in ECEF with specific Ellipsoid shape that is tied to each constellation.
This proposal adds new methods to attach reference Frames, defines a few constant values to build the most common Ellispoid shapes, and a few macros to build
Orbits
from (sv_x, sv_y, sv_z) directly, in the correct coordinate systemArchitectural Changes
Minor modifications to Frame, Ellipsoid and Orbit structures
New Features
No change, but all of this could be wrapped in a
gnss
feature if you'd like toImprovements
No change
Bug Fixes
No change
Testing and validation
I have no idea how to test that, other than updating my applications to actually use it
Documentation
Ellipsoid definitions come with a link to standard specs