Re: [Paparazzi-devel] Incorrect Proportional Pitch Deflection, Correct Derivative Pitch Deflection

[Chris Wozny]

Felix,

This makes much more sense now. The AHRS uses quaternions, but the
control system uses Euler angle's which is why I'd still run into
singularities in the control system. Are there any plans to write a
control system using quaternions or do the "new" or "adaptive" control
schemes have a way to combat singularities? I have a feeling I know
the answer since you'd need a more exotic non-linear controller.
Unfortunately I only have basic knowledge of automatic control theory
from an undergraduate course. The attitude estimation looks correct
when I look at the PFD except for the times when issue 132 comes into
play, but I've learned to start up the autopilot in the proper
orientation. Thank you for the responses (and I'm sure at times my
questions must be tedious)! My colleagues are attempting to use the
GINA autopilot project from Berkeley/UMD and the community isn't
nearly as helpful as everyone here is!

Best,
Chris

On Sun, Feb 19, 2012 at 9:50 AM, Felix Ruess <address@hidden> wrote:
> Chris,
>
>> 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.
>
> The only other possible problem I can think of right now is the
> initialization of the attitude
> estimation: https://github.com/paparazzi/paparazzi/issues/132
> 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