Solver decreases step-size at certain anomalies

3 visualizzazioni (ultimi 30 giorni)
Quirin
Quirin il 13 Lug 2024
Commentato: Sam Chak il 17 Lug 2024
Hey hello there!
So i have the following Issue. I am simulating the attitude (orientation) of a satellite via simulink. My initial conditions are usually a spinning satellite that gets slowed down. And when i reach small turn rates (derivative of the magnetic field is very low) my simulation breaks down and my step size decreases so drastically that it takes almost 30min to simulate 1s. And that cant be right somehow.
My tolerance settings are:
Absolute Tolerance: 10*e-8
Relative Tolerance: 10*e-6
Maybe they are low, but they work for most of the time with reasonable step sizes. (as one can see in the graph below)
This is how the step-size graph looks like for an edge case where i get the solver exceptiosn with error control but only for "short" time frames that still take minutes to compute.
At those time intervals the derivative of the magnetic field approaches 0 (1st graph below) and starts to do weird stuff. But when i tell the derivative that it should be 0 when close to 0 the simulation slows down even faster and my magnetic field derivative just starts to flicker (2nd graph).
Are there any general things one has to consider? Does stuff like this happen often in simulations?
Any Ideas how to fix this?
Some more additional Information:
Simulation Overview:
So what the simulation basically does is. It tries to bring the angular velocity of the satellite close to zero. This is done by "measuring" the magnetic field of earth and then trying to align the satellite with earths magnetic field (as it can be roughly assumed constant). This is done via this logic:
Here the graph of my angular Velocity around the x-Axis and the Angular Acceleration Graph when those anomalies occur:
(The Angular acceleration graph is zoomed in on the y-axis as otherwise one would only see the spikes and the angular velocity graph is zoomed in a lot in both axis)
One can clearly see that the Angular Velocity first runs smoothly and then for some reason flattens out until increasing not so smoothly.
If you need more information i will gladly provide them.
Thanks for your Help :)
  4 Commenti
Sam Chak
Sam Chak il 13 Lug 2024
Since there are no division by zero terms, I guess it must be due to the incorrect modeling of B-dot control system.
Ensure that the B-dot controller is correctly modeled according to the standard equation that satisfies the Lyapunov Stability condition.
Quirin
Quirin il 15 Lug 2024
I tried changing the controller. Especially the derivative Block but thet didnt seem to work. I will try other things and if i find something that works i wil update you

Accedi per commentare.

Risposte (1)

Sam Chak
Sam Chak il 15 Lug 2024
Regarding the issue with the rapid zero-crossing, it appears to be caused by the Derivative block used to compute the time derivative of the magnetic field vector in the satellite body frame.
Inspecting the Scope connected to the output port of the Derivative block reveals that the time derivatives of the magnetic fields are rapidly changing, resulting in discontinuities that cause the Simulink solver to take numerous small steps, thus slowing down the simulation. This behavior is unexpected, as the magnetic fields do not typically change so rapidly in reality.
It would be prudent to investigate the behavior of the magnetic fields further. Examining the Scope connected to the input port of the Derivative block shows that the magnetic fields appear as expected at first glance. However, upon closer inspection, a staircase-like response can be observed, which explains the rapid changing responses despite their small magnitudes.
Tracing the root cause in a step-by-step manner suggests that the staircase-like responses are caused by the Rate Transition blocks. Disabling these blocks and rerouting the signals may resolve the simulation issue. Nonetheless, whether the performance is satisfactory or not, it is advisable to review the control design or consider adding an additional active control scheme to improve the overall performance.
  2 Commenti
Quirin
Quirin il 16 Lug 2024
Modificato: Quirin il 16 Lug 2024
Thanks for your answer!
I also have those issues without the rate transition blocks (i actually never used the rate transition blocks, they are "artifacts" becasue i thought i could move on to simulate the model more realistically until i found this issue)
Regarding the derivative block being the issue, i dont think thats the case as i used a different implementation (that i found here: AAUSAT3 p.108) to calculate the derivative of the magnetic field:
This works surprisingly good. But oscilations can still be observed which casue the solver to slow down drasically (1st 3 signals from derivative Block): (Gain = 1)
When i adjust the gain in the gain Block of the new implementation the behaviour can be changed. Decrease in gain yields shorter times in which the step-size decreases and increasing the gain has the opposite effect. Which is i think due to the fact that the derivative is not approximated well enough anymore and the controller is worse at trying to keep the magnetic field in satellite frame as constant as possible. This can also directly be observed by the behaviour of the actual derivative.
Following Diagram: (Gain = 10)
(Adjusting the gains does not seem to affect the overall responses for almost stationary systems but it can reduce the oscillatory response of the system.) (And i have also no idea why this different implementation seemingly works so well. At least visually.)
My guess right now is that there is something fundamentaly wrong in the design of the whole system or within the error tolerances or solver selection.
Sam Chak
Sam Chak il 17 Lug 2024
My guess right now is that there is something fundamentaly wrong in the design of the whole system
@Quirin, Thanks for you update. It could be the case. To verify that, replace your magnetorquers or B-dot controller with a simple reaction wheel control scheme. If the system doesn't stabilize, then the satellite model is incorrect. If the system stabilizes, then the previous B-dot controller model is incorrect.

Accedi per commentare.

Categorie

Scopri di più su Aerospace Applications in Help Center e File Exchange

Prodotti


Release

R2024a

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!

Translated by