We're updating the issue view to help you get more done. 

Punch list for multi-spacecraft simultaneous estimation

Description

Open Items

  • Process noise as reported in the EKF MATLAB file is zero for test case EKFS_SpacecraftNavigation_MultiSat_TdrsAndUser

  • In the estimation report file, consider grouping each spacecraft's dynamic parameters (CR, CR) together with its state parameters. In other words, report Aqua.X, Y, Z, VX, VY, VZ, CD, TDRS.X, Y, Z, VX, VY, VZ, CR.

    • Currently all non-PV parameters for all satellites are grouped together at the end of the state vector like Aqua.X, Y, Z, VX, VY, VZ, TDRS.X, Y, Z, VX, VY, VZ, Aqua.CD, TDRS.CR

Closed Items

  • Attempting to estimate Cd, Cr, or both yields a "Normal matrix is singular" error.

    • Ask SES for test script SpacecraftNavigation_MultiSat_TdrsAndUser_Cd_Cr

    • Confirmed fixed in 12/9/20 daily build

  • GMAT crashes when attempting to estimate Cd and Cr in a flight date test case

    • See test case DoNotDistribute/SpacecraftNavigation_Multisat_AquaTD6_Cd_Cr

    • Confirmed fixed in 12/21/20 daily build

Environment

None

Activity

Show:
John McGreevy
December 3, 2020, 7:24 PM
Edited

Re: SpacecraftNavigation_MultiSat_TdrsAndUser_Cd_Cr

When mapping the STM elements from the Spacecraft object to the ESM (in EstimationStateManager::MapObjectsToSTM()), the drag elements are ending up in the wrong column in the ESM STM.

John McGreevy
December 11, 2020, 8:46 PM
Edited

Re: SpacecraftNavigation_Multisat_AquaTD6_Cd_Cr

In the SRP and drag force models, the force model is incorrectly calculating the row index of the Cr/Cd state when calculating the A matrix for the Spacecraft. They get the index correct for the first Spacecraft, but not for subsequent spacecraft in the PropagationStateManager. This leads to the STM having values in the wrong row/column.

Assignee

John McGreevy

Reporter

Steven Slojkowski

Labels

Development Build

None

Fix versions

Priority

P1
Configure