Hey @jniffene

I fixed the sign of the powerInternalMechanics -- by default the universal joint was using the opposite reference frame as the rest of our joints. However I still cannot figure out why there is:

• a non-zero pitch constraint force
• a non-zero yaw internal mechanics force*

*Note that we manually calculate this using as total force - actuation force - constraint force. The actuation forces are as expected. The total force does not have an obvious value when observing qualitatively. The constraint force and yaw is not obvious either, so i can't tell if the issue with the yaw internal mechanics force is related to the total or constraint force values.

Either way, I really can't figure out what is going on here that would result in this force output. All of the other joints have the expected force values. Maybe there is something in our pre-processing?

I do not think we are missing any kind of rotational transformation. I tested this out by back-calculating the angular positions of the PTO if the constraint force was limited to yaw, but the results are non-sensical. So I don't think we're missing anything. TBD on what the problem here is

@jniffene I looked into this problem further and don't have a solution yet. I don't think the discrepancies described above are any of our doing. The position, velocity, acceleration, have appropriate values for the universal PTO. I still see that forceConstraint has a very small non-zero value in pitch (~1e-6), and forceInternalMechanics has the same in yaw (~1e+0).

Maybe this is due to how the multiple body system is solved numerically and it retains some very small discrepancies in those quantities? I have some matlab office hours on thursday this week that I will attend and bring this up

I have a meeting with Mathworks next week to better understand this universal joint block. I will update more after that meeting.

I discussed with the Simscape team today and they're helping me understand the behavior of the constraint torque and damping torque in the universal joint.

Attaching a zip file of the test case for reference:
RM3_test.zip

@akeeste Do you think we need to include the Run from Simulink feature for this block?
Also, should we add a description of the new block and its related inputs to the user guide for clarity?

@akeeste Do you think we need to include the Run from Simulink feature for this block? Also, should we add a description of the new block and its related inputs to the user guide for clarity?

The WEC-Sim GUI was removed in #1474, so I removed it from here as well. We don't call our specific PTO/Constraint types in our documentation, except for this screenshot: https://wec-sim.github.io/WEC-Sim/main/user/code_structure.html#pto-blocks

I can update that figure.

The constraint force and internal mechanics forces here require special handling due to how they're output, but for this particular joint I think those are likely of lower importance for a user than having the joint that allows the correct motion. I suggest we merge this with that understanding so that the joint is available to use. It can be updated in the future.

From Mathworks:
"The universal joint is effectively two revolute joints stacked together. Because you are using the default value of Base for the resolution frame, then the second revolute joint is being resolved through the first and shows up as the non-zero value in the Base. If you switch the frame to Follower like below, then you will get zero for Ry [constraint force] and non-zero for Rx [constraint force].... So the “first” revolute joint shows zero constraint torque since its not possible, but the “second” is then resolved through the “first” and then into the base frame"

Thank you @akeeste!

@jniffene I believe in our last reviews this PR was otherwise ready to go aside from understanding the force output. Since we more information on that and can confirm that the block is working correctly, I will merge this PR.

@akeeste we discussed this PR during our morning checkin, it's ready for a merge.