Skip to content
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

Support estimation of spacecraft parameters (Cr, Cd) #94

Closed
ChristopherRabotin opened this issue Dec 11, 2022 · 1 comment · Fixed by #350
Closed

Support estimation of spacecraft parameters (Cr, Cd) #94

ChristopherRabotin opened this issue Dec 11, 2022 · 1 comment · Fixed by #350
Labels
Kind: New feature This is a proposed new feature Priority: high Status: Design Issue at Design phase of the quality assurance process Topic: Orbit Determination

Comments

@ChristopherRabotin
Copy link
Member

ChristopherRabotin commented Dec 11, 2022

High level description

Operations require the estimation of the coefficient of reflectivity and coefficient of drag. The purpose of this ticket is to support Cr/Cd estimation.

Requirements

  • Support estimation of Cr and Cr

Test plans

  • Generate lots of tracking data with a given Cr value (e.g. 0.5), then run the filter assuming that the Cr is different (e.g. 1.5), and ensure that the filter eventually converges onto the correct Cr value
  • Repeat for Cr

Design

Reporting

In some software, it's the difference in Cr which is reported: I don't think that's necessarily a good approach because then the analyst needs to compare that difference with the original value. Hence, I think it's better for the analyst to have direct access to the estimated Cr throughout the duration of the tracking arc.

State estimation

One of the architecture choices with Nyx is that all computations use fixed size vectors and matrices. This is convenient because it enables compile-time dimension checking. This should be kept.

To support the estimation of Cr and Cd, I think that the ODProcess should define for each run (or at initialization?) what ought to be estimated. From the derivation of the Kalman filter, I think that setting a given row of the prefit residual to zero (and its associated sensitivity data to zero) is sufficient to lead to a zero correction on that specific row of the estimated state. Therefore, the computation of the prefit and the sensitivity should be aware of what state data ought to be estimated. I think that the measurement noise must also be nulled to not bias the Kalman gain in anyway.

This approach would introduce the fact that the estimated state is not necessarily a State in the sense of being able to be propagated... unless these extra parameters have a simple nil function for the dynamics s.t. \let x in R, f(x) = 0, ensuring that the remain constant The propagation is required for covariance mapping.

@ChristopherRabotin
Copy link
Member Author

ChristopherRabotin commented Aug 10, 2024

Woop! This finally works! It's a bit finicky: too much SNC and the estimation is too slow, and too little and the filter wants to change the Cr more than the rest of the state.

        === Estimate @ 2024-03-02T16:48:00 UTC -- within 3 sigma: true ===
state total mass = 100.000 kg @  [Earth J2000] 2024-03-02T16:48:00 UTC  position = [4286.256943, -7309.175639, -904.437275] km  velocity = [5.058772, 7.135588, 0.882780] km/s  Coast
sigmas [0.000007 km, 0.000028 km, 0.000018 km, 0.000000 km/s, 0.000000 km/s, 0.000000 km/s, 0.012413 , 0.000000 , 0.000000 ]

[Earth J2000] 2024-03-02T16:48:00 UTC   sma = 24505.359491 km   ecc = 0.724953  inc = 7.053285 deg      raan = 0.008919 deg     aop = 0.016153 deg      ta = 300.173664 deg
Cr = 1.1603972559704543 +/-0.11141240529255109
EXP:    [Earth J2000] 2024-03-02T16:48:00 UTC   sma = 24505.359932 km   ecc = 0.724953  inc = 7.053285 deg      raan = 0.008914 deg     aop = 0.016156 deg      ta = 300.173666 deg
RMAG error = 0.082818 m VMAG error = 0.135248 mm/s
test orbit_determination::spacecraft::od_val_sc_srp_estimation ... ok

Image
Image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Kind: New feature This is a proposed new feature Priority: high Status: Design Issue at Design phase of the quality assurance process Topic: Orbit Determination
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant