new facet srp effector module

[leahkiner]

• Tickets addressed: New facetSRPEffector module #1332
• Review: By commit
• Merge strategy: Merge (no squash)

Overview

This new faceted solar radiation pressure dynamic effector module is created to utilize the two new modules recently added to the repository: facetedSpacecraftModel and facetedSpacecraftProjectedArea. The original facetSRPDynamicEffector module is complicated in that it contains several different calculations which are now isolated and checked in these new modules. This new SRP module now perform a compact SRP calculation that does not include any auxiliary calculations.

Description

This module computes the aggregate force and torque acting on the spacecraft due to impinging photons from the Sun. The inertial Sun state information must be subscribed to the module SpicePlanetStateMsgPayload input message. The module assumes the spacecraft is modeled as a collection of facets, where the facet geometry information is passed as a vector of FacetElementBodyMsgPayload input messages to the module. The facet geometry information is required to be provided in the spacecraft body frame. This SRP module does not make any assumptions regarding whether the facets are rigid or articulate. The facetedSpacecraftModel module can be connected upstream and used to transform the facet geometry data from the facet frames to the spacecraft body frame. This upstream module can also be used to configure articulating facets.Finally, this SRP module also requires the sunlit area of all facets to be pre-computed and connected to the module vector of ProjectedAreaMsgPayload input messages. This information can be passed to the SRP module by connecting the facet geometry information to the facetedSpacecraftProjectedArea module upstream.

Verification

The module unit test verifies that the module correctly computes the aggregate SRP force and torque acting on the spacecraft due to impinging photons from the Sun. The test sets up a simulation with a faceted spacecraft modeled as a cubic hub with two attached circular solar arrays. Six square facets represent the cubic hub and four circular facets represent the two solar arrays. The test varies the initial state information of the spacecraft, the initial state information of the Sun, and the Sun illumination factor.

Documentation

RST documentation is added for the new module.

Future work

N/A

[leahkiner]

@codex review

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 4a975ac706

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[schaubh]

Nice PR. Mostly small stuff to address.

[schaubh]

just some minor stuff now.

[schaubh]

sunVisibilityFactor is only updated when sunEclipseInMsg is linked and written, but it is never reset to full sunlight before that optional read. If the module is reused/reset after previously reading an eclipse value, or if the optional message is linked but unavailable for a cycle, the previous illumination factor can continue scaling the force and torque. The older facetSRPDynamicEffector defaults the eclipse factor back to 1.0 before reading the optional message; this module should do the same in Reset() and/or at the start of each computeForceTorque() call.

Also, input messages can be disconnected, then reconnected. We should set the default 1.0 value before checking if sunEclipseInMsg is connected and written.

[schaubh]

r_SB_B.normalized() is used without checking that the Sun-spacecraft vector has nonzero norm. If the Sun state is accidentally left at the spacecraft position, for example both default to the origin during setup, this produces NaNs that then propagate into the spacecraft dynamics. The upstream projected-area module already guards this case and logs an error; this effector should similarly check the norm before normalizing and return zero force/torque with a clear BSK error.

[schaubh]

The setup guide uses messaging, simIncludeGravBody, np, test_sim, task_name, and eclipse_msg, but the import/setup snippets only import three simulation modules and never define the optional eclipse message before subscribing to it. Since this is the primary new-module user guide, copying the documented steps will raise NameErrors. Please add the missing imports/context or make the snippets self-contained enough to run.