Simscape Multibody: Zero crossing in control loop

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 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. The attitude and rate of the spacecraft are sensed from thie joint.

We can observe from the first image that there are two inputs to the Vanes Sailcraft Model:

• 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 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 subsystem model and the joint properties are illustrated below:

Lastly, the control angles calculation includes 4 transfer functions to break the algebraic loop in the model, and allow some small delay, as recommended in this answer.

The problem that I have is the very long simulation time at the beginning of the simulation, and the frequent oscillations in the system's angular rate, measured at the 6DOF joint. This rate is used to calculate the control torque, which will of course in turn oscillate in a similar manner. An example is illustrated in the plots below:

I do not understand why this is happening and why it ceases all of a sudden at around t=1500 seconds. I made some attempts to fix this, but I was unable to do so. What I have tried:

1. Add some stiffness in the 6DOF joint so that the system does not "vibrate" anymore, and chatter is reduced. It did not solve the problem however, and another reason why I don't think the 6DOF joint is the problem is that the attitude measurements are correct and smooth:

2. Follow this tutorial to determine the source of the oscillations and reduce the zero crossing. However, I got stuck on the first step in the "Identify and Modify Elements That Cause Zero Crossings" section, where the sscprintzcs(simlogRef) command shows zero crossings in the model, even though the Step-size-over-time plot clearly showed multiple zero crossings at the beginning and somewhere around timestep t = 6600 s.

3. Play with the solver (the default one I was using is ode23t, but i also tried other ones) to reduce step time and relax relative tolerance. This resulted in very long simulation times and did not fix the issue either. Maybe I didn't try the right combination of parameters, I am open to advice on how to tweak the solver better to fix this.

4. Change the Simulink-PS converter parameters in the Vane subsystem and try different time constants for the filter that calculates the first and second derivatives for the motion of the joint. What I noticed is that if I changed it to a bigger value (so that the signal is much smoother), the beginning of the simulation does not produce oscillations anymore, but after roughly t=1000s the simulation becomes incredibly slow and I could not see anything significant on the graphs to help me realize what's going on.

I suspect the problem is the way the control angles are passed to the SIMSCAPE model, and the way the derivatives are calculated. On the other hand, there is some piece of code in my model that I am afraid may trigger zero crossings, but I am not sure. This code is in the Vane Control Allocation block, where I calculate what force is required from each vane based on the desired torque calculated by the controller. A sneak peek is in the screenshot below:

As we can see, the forces in turn will oscillate the same way the demanded torque will, and this will affect the determination of the control angles which are fed into the SIMSCAPE model. I have tried adding a deadband for the desired torque or error tolerance for measured rate, but this resulted in a behaviour that was not desirable.

If any advanced debugging is required on your side, the model and associated script are uploaded in my repository.

Any tips and advices are greatly appreciated.

Thanks,

Irina

Answer 1

[Juan Sagarduy]

Hi Irina

It looks like you are allocating the angles in a closed loop (sign dependent) and then forcing a kinematic behaviour on the joints.

I believe this is the source for these numerical problems.

I can have a look during the week to the model you sent.

Br Juan

[Irina-Stefana Bulgaru]

Thank you, Juan, that would be very helpful.

[Juan Sagarduy]

Hello Irina

I managed to run the model quite well in the end. The function for vane allocation seem to be ok.

In this set-up, I have discretized the controller just to avoid that the actuation signals become unreasonably fast, which would not be the case in reality.

I also limit the max step size for the plant in the Simulink solver (ode23t). Rel and abs tolerances are set to 1e-3. With this changes, the models runs in 22-24 seconds.

I attch 21a and 20b versions in this message.

Best of Luck / Juan

[Irina-Stefana Bulgaru]

Thank you, Juan. Indeed, with these fixes make the model run without the oscillations. This has been very helpful.

Just as a follow-up question, I was wondering what is the difference between adding a pulse generator plus a trigger block (what you did) and adding a zero-order hold in the actuation signal? The zero-order hold is another attempt i made at fixing this model before I got your answer, but it was unsuccessful. I also noticed that you latched the input signals for the controller, is that a "must have" and should have been done when I added the zero-order hold?

[Juan Sagarduy]

Hi Irina

Well, I think that the triggered subsystem can be a bit more effective computationally but results obtained shall be consistent with both approaches. It is more familiar for people working in the embedded world.

When using triggered subsystems in a closed loop control like this, the algebraic loop is broken by latching the input signals. So it has the effect of a unit delay in a way.

I am glad I could help.

Good luck / Juan