If I'm understanding you correctly, the quaternions are used
internally which would mean the problem I'm having isn't coming from
the gimbal lock problem.
Yes and no: You can't get gimbal lock in the actual attitude estimation (with int_cmpl_quat).
But again, this is not the case for the control...
I don't know why I didn't realize viewing the
Euler angles would show this issue in a plot, doh!
As I said the fw control uses the euler angles as input, so it has exactly the same problems as you when you view the plot, e.g. that you have discontinuities from +180 to -180 deg, etc.
I hope the difference/issue is a bit more clear now?
If that is the case, I believe I'm having the Issue 93 problem on github which was
mentioned in a previous thread where
I very much doubt that. int_cmpl_quat handles all BODY_TO_IMU_x angles properly as it should.
If it really does not, you have indeed found a very subtle bug. But in my tests it worked with every orientation I threw at it.
it is only to be used for small adjustments and not changes such as BODY_TO_IMU_THETA of 90 degrees
like I attempted.
Originally that was true, but as said, now float_dcm is the only one that still has this limit.
Did you check if the attitude estimation is ok? Try to isolate the problem and verify that subsystems work before moving to the next.
To me this all really sounds like the control is having issues, because you are using it around the singularities of the euler angle representation and it can't properly deal with it.
But I doubt that as well, as the attitude will be wrong initially, but quickly rotate to the correct one again.
Also this is easy to check, as long as your attitude estimation is fine, you don't have to look for the problem there...
if it's not ok, well.. first this has to work properly before you can even consider looking at the control.
Cheers, Felix