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:
- 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
