Inconsistent output in thrusterStateEffector

[rcalaon]

The output msg THROutputMsgPayload seems to contain some frame inconsistencies in the case where the thruster is attached to a moving body. I’m seeing that the thrusterDirection message variable is the unit thrust direction vector in thruster frame coordinates (say F), but the thrustForce_B message variable is, in fact, the thrust vector in B coordinates. Do we want it like that? I think it would make more sense to express all the vectors in the same frame.

[schaubh]

This is being clarified in the updated thruster documentation. Should be pushed to develop shortly.

[seb-argo]

@schaubh Was the pdf linked in the thruster documentation (this one) ever updated with this new documentation? And if not where can I find the most recent information containing the update mentioned here? The PDF there seems to have last been updated in 2022. I am running into the same confusion with frames when inspecting the code for computation of force and torque in the thruster effector. These lines in particular are a bit confusing:

// Compute the thruster properties wrt the hub (note that B refers to the F frame when extracting from the thruster info)
thrustDirection_B = this->bodyToHubInfo.at(index).dcm_BF * it->thrDir_B;
thrustLocation_B = this->bodyToHubInfo.at(index).r_FB_B + this->bodyToHubInfo.at(index).dcm_BF * it->thrLoc_B;

The comment above leads me to believe that thrDir_B and thrLoc_B are actually in F coordinates, but this conflicts with the following comment in THRSimConfig.h

THRSimConfig
{
    Eigen::Vector3d thrLoc_B;                       //!< [m] Thruster location expressed in body
    // ...
}

Additionally, in BodyToHubInfo.h, the comment on the rotation matrix variable directly conflicts with the naming convention

BodyToHubInfo
{
    Eigen::Vector3d r_FB_B;         //!< position vector of the frame F relative to frame B
    Eigen::Vector3d omega_FB_B;     //!< angular velocity of F relative to B
    Eigen::Matrix3d dcm_BF;         //!< DCM of B relative to F
}BodyToHubInfo;

Any clarification on any of these fronts would be greatly appreciated! Thanks in advance.

[schaubh]

@joaogvcarneiro, you wrote the original thruster state effector. Can you please take a look. The original post is from 2023 and I thought we addressed all this.

[joaogvcarneiro]

I agree that the naming is quite confusing. The reason for this is that thrusters were originally designed to be attached to the hub, which is why their payload information contained hub (B) information. With this change, B can now mean the F frame if the thruster is being attached to a body other than the hub. The reason we didn't change the names at the time was to maintain backwards compatibility.

It might be helpful to think about the B frame as the F frame when it is isolated, i.e., inside the thruster payload. Whenever there's relative frame information (BF), you can assume that the B frame actually refers to the hub. Hopefully, this helps.