Simscape Multibody: 6DOF joint has a degenerate mass distribution on its follower side.

I have been working on a simulink model for attitude control of a solar sail spacecraft. The top-level model is illustrated below:

The spacecraft orientation is controlled by 4 triangular vanes located at the tips of the solar sail, and these vanes are commanded through a rotation around the corresponding solar sail diagonal. The 4 angles that define the rotation of each vane have been labeled 'control angles' in this model. The control angle is zero when the vane is in the same plane as the solar sail. Visual representation of the mechanical system is below:

The simmechanics implementation of this mechanical system is also represented below:

We can observe that the entire system is connected to the world frame via a 6DOF joint, because I want to simulate the free motion of the spacecraft in deep space. We can also observe two inputs to this system:

• torque: this is the final torque that acts on the spacecraft (disturbance and control) and actuates the top level joint to reflect the movement of the entire spacecraft
• control angles: this is a 4x1 vector containing the 4 control angles of the vanes. Note that the control torque resulting from the actuation is modelled separately in a simulink block and applied on the 6DOF joint, however this input is necessary here for 2 reasons: 1) because I want to study the effects of the torque produced by the angular acceleration of the vane on the attitude of the entire sailcraft; and 2) because I want the vanes to move in the Mechanics Explorer animation

The outputs included in this screenshot are the sail attitude and rotation rate, with a transport delay to avoid algebraic loops.

The connection between the vane and the sail is modelled by a revolute joint whose input is motion and whose torque is automatically calculated. The vane model and the joint properties are illustrated below:

The simulation runs without a problem (which means that there aren't any mismatches in reference frames for the base and follower of any joints in the model) until I try to connect the control angles output of the Actuation Model block (in the top level model) to the control angles input of the Vanes Saicraft Model.

What I have tried:

1. Input some dummy control angles that come from outside the loop. Using the SignalEditor block I have even replicated the control angles produced by the loop and set that as input to the sail model. The simulation did not crash anymore if the angles came from outside, even though the actual signals were roughly the same. This makes me think that the problem is not sudden variations of the control angles.
2. Changing the inertia properties of the sail. For now, the sail's inertia is a custom inertia, where I provide the inertia matrix and mass, but I tried to change it to "Calculated from geometry" as well. Vane's inertias are calculated from geometry. This did not fix the issue. The whole system is very light as well, and to make sure this is not the issue, I added a payload of 100kg connected to the 6DOF joint as well. Issue still not fixed.
3. Giving initial conditions to the revolute joints (position 0 and velocity 0). The error was still thrown.
4. Playing around with the solver. I have tried multiple variable-step solvers (initially the simscape recommended ones) as well as fixed-step solvers with very small step sizes. The error was still there.
5. Searching the MATLAB forum for other questions with similar title. I tried the solutions in here, here, here and here. It did not solve the problem.

I have a few years experience with simulink but I have only started working with Simscape Multibody 2 weeks ago. At this point I am not sure if I am missing something in the assembly of the sail, if I am trying to solve a problem that simscape cannot compute, or if I am using the joint actuation incorrectly. The library also provides blocks for torques and forces, but even after reading through the documentation I did not understand the difference between using those and just applying the motion/force/torque as input on the joint. Do you think using any of these force/torque blocks would make a difference?

Any tips and advices are greatly appreciated.

Thanks,

Irina

[Yifeng Tang]

Do you have a screenshot from the Diagnosis window? I wonder if it complains about algebraic loop at the very beginning.

And what does it look like inside "diagonal 1 & 2"? Degenerate mass error usually happens when a mass is missing between two joints.

[Irina-Stefana Bulgaru]

The screenshot for the diagnosis window is below. You are right, it does complain about the loop, and this is the reason why I added the two delays at the outputs of the 6DOF. The screenshot below is what happens when the delays are removed. With the delays, I only get the "degenerate mass distribution" error, without the algebraic loop warning.

The screenshots for Diagonal 1 and Diagonal 2 are below. As you can see there are no joints in here, so I don't think I have two joints connected in series. There is a diagonal solid between the 6DOF and the Vanes revolute joint.

[Yifeng Tang]

I agree. I don't see anything obviously wrong from the screenshots. Are you able to share the model? The geometry looks generic enough. But if the controller is proprietary, you can maybe make it dumber? As long as we can reproduce this error it's OK.

[Irina-Stefana Bulgaru]

Sure, the model and initialization script can be found here.

The controller is not a problem, at this moment it still needs tuning, and the allocation needs some work too. Even if the error is resolved, the system will most likely not stabilize yet anyway, it is work in progress.

If you would like to see how the simulation runs without the error, simply break the link between the Control Alocation Block and the Vanes Sailcraft Model and connect the Make Dummy Angles block to the Vanes Sailcraft Model instead.

Answer 1

[Yifeng Tang]

Thanks for sharing the model. It looks to me the problem here is still the algebraic loop. I tried two ways to break it and both seems to allow the simulation to run without a problem.

1. Use a "First Order Hold" block

2. Or, use first order transfer functions and a small time constant

You only need one of them. Both can be physically justified as some sensor or actuator delay in the system.

At the same time, I would agree that the "degenerate mass" error wasn't helpful in finding a solution to the problem, as mass was clearly present on the F side of the 6-DOF joint. Looks like the algebraic loop makes the system of equations resemble those of a degenerate case :(