I want to determine if/how to perform a sensor Residuals vs. Reference Analysis (also called an RvR run) using Orekit. Such an analysis is necessary for new sensors to be calibrated. The goal is to validate the sensor information and modeling decisions and get a general sense of the sensor performance.
Using a high-accuracy reference ephemeris from a calibration class satellite, an RvR run generates measurement residuals.
I am using the following paper as a reference, specifically Section 3.4.
ODTK has a built-in RvR run feature. Does Orekit have such a feature? If not, does anybody have any recommendations to help me build one?
Thank you for your time. I would greatly appreciate any feedback, comments, or corrections.
Yes it is possible to perform such analysis using Orekit. It is an ephemeris-based orbit determination. In other words, it is an “orbit” determination for which the dynamical model is an Ephemeris propagator instead of a NumericaPropagator and the orbit estimation is disable to only estimate measurement parameters.
I promise I did look through that code before sending my prior reply! I suppose I should have asked how the residuals of the azimuth and elevation could be converted to residuals of the right ascension and declination.
I know azimuth and elevation can be converted to right ascension and declination so long as you know the observer’s latitude, longitude, and the local sidereal time. I can perform this conversion and then use the code you’ve provided to perform the RvR run. However, I’d like to consider my analysis in terms of the original measurements.
Does Orekit have a feature that can convert the residuals of the azimuth and elevation to residuals of the right ascension and declination? Is there a standard that you are aware of?
I’m reposting here a ResidualsHandler that I posted a few years ago on the forum: ResidualsHandler.java (3.8 KB)
It’s single-satellite, I have a multi-satellite version if needed.
It does point 1, 2 and 3 of @lirw1984 method and outputs a Map<ObservedMeasurement<?>, EstimatedMeasurement<?>> ready for performing point 4. (So the name is not adapted…)
It seems to be a question that comes back once in a while, shall we add a similar handler directly in the library?