Configure prescribed motion effector for select effector branching

[leahkiner]

• Tickets addressed: Configure Prescribed Motion for State Effector Branching #932 Configure SpinningBodyOneDOF for Prescribed Motion Branching #933 Configure SpinningBodyTwoDOF for Prescribed Motion Branching #1133 Configure LinearTranslationOneDOF for Prescribed Motion Branching #934 Add prescribed motion effector branching scenario #981
• Review: By commit
• Merge strategy: Merge (no squash)

Description

This PR addresses 5 issues related to adding the capability to connect other state effectors to the prescribed motion module rather than the spacecraft hub.

• The first commit modifies the stateEffector class for attachment of state effectors to the prescribed motion effector.
• The second commit is independent of the purpose of this PR, it removes unneeded variables from the prescribedMotion module.
• The third commit makes the required changes to the prescribedMotion module to enable the new branching capability.
• The fourth commit is also independent of the purpose of this PR, it adds setters and getters to the prescribedMotion module.
• Commits 5-7 configure the spinningBodyOneDOF, spinningBodyTwoDOF, and linearTranslationOneDOF state effectors for optional attachment to the prescribed motion effector.
• Commit 8 adds a new test script called test_PrescribedMotionStateEffectorBranching to the prescribed motion module. Each of these three state effectors are separately attached to the prescribed motion effector and independently verified.
• Commit 9 adds two branching scenarios to the examples folder. The first is a rotational branching scenario called scenarioPrescribedMotionWithRotationBranching. The second is a translational branching scenario and is called scenarioPrescribedMotionWithTranslationBranching.
• Commit 10 condenses the branching scenarios using python lists.
• Commit 11 refactors and cleans up the original prescribed motion test script.
• Commit 12 updates the prescribed motion module documentation to reflect these changes.
• Commit 13 updates bskReleaseNotes.

Verification

A new test script test_PrescribedMotionStateEffectorBranching is added to the prescribedMotion module that checks the changes made in this PR.

Documentation

The prescribed motion module documentation is updated to discuss these new features.

Future work

Other state effectors will be configured for attachment to the prescribed motion effector in the future.

[andrewmorell]

Nice PR! A lot of added functionality and the scenarios demonstrating it are really cool. I like the sequence of calling updateContributions() then addPrescribedMotionContributions() to augment the backsub matrices. I also like how you dual use the same backsub matrices for the dependent state effectors and then the prescribed motion module.

I have two broad recommendations besides the specific code callouts below.

1. Consider being more explicit with inline documentation where new variables are defined in .cpp files since they don't get the nice definitions that variables defined in the .h file do. Your linked papers are great for explaining what math goes on under the hood, but doesn't help someone perusing the code figure out how this math interacts with all of the existing Basilisk architecture choices and frame ambiguity.
2. I feel like these new features could benefit from a guardrail or two that stops you from trying to setup configurations not yet allowed. When I try adding a non-compatible state effector to prescribed motion, I get an indirect error from the dynParamManager during sim initialization. A default error in the stateEffector base class' linkInPrescribedMotionProperties() method that says this combination isn't set up would be cleaner.

[schaubh]

Great PR overall. Thanks @andrewmorell for having gone through this so carefully. I agree with Andrew's comment that we need the same safeguards implemented as he has with his effector branching. This way if an effector is added that doesn't support your feature, then a BSK Error is thrown with a user-readable message as to why this is not working. Should be simple to mimic what Andrew did on his branch.

[leahkiner]

@schaubh I believe this PR is ready to go, I addressed @andrewmorell and your comments.

[andrewmorell]

Changes look good on my side!

[schaubh]

Good to go. Thanks for addressing the feedback and adding the guards against adding an effector which is not compatible.