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

[Chris Wozny]

Felix,

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. I don't know why I didn't realize viewing the
Euler angles would show this issue in a plot, doh! If that is the
case, I believe I'm having the Issue 93 problem on github which was
mentioned in a previous thread where it is only to be used for small
adjustments and not changes such as BODY_TO_IMU_THETA of 90 degrees
like I attempted.

- Chris

On Sat, Feb 18, 2012 at 5:46 AM, Felix Ruess <address@hidden> wrote:
> Hi Chris,
>
> the attitude estimation algorithm itself (ahrs int_cmpl_quat uses
> quaternions for representing rotations internally) has no problems with
> gimbal lock.
>
> But we also always calculate the "other" attitude representations (in that
> case from the quaternion). So we always have the attitude as quaternion,
> euler angles and rotation matrix representations. E.g. to display the
> attitude in euler angles, (displaying quaternion values is not very
> intuitive;-) and to be able to use other parts that don't take quaternions
> as input yet.
>
> This is why you can use the normal fixed wing stabilization/guidance which
> only takes euler angles as input.
> So it's not a "quaternion method taking Euler angles as input", it's
> just that for fixed wings there is no control written using the quaternions
> representation directly.
> That is what I was trying to say in the previous mail.
>
> If you start to convert the attitude representation from a quaternion to
> euler angles, you will get discontinuities at +-180deg (+-90deg for pitch),
> that is just a property of euler angles representations and nothing you can
> do about it.
> The only "real" solution to properly avoid this problem is to not use euler
> angles (except for things like displaying it for the user) and write the
> control using quaternions as well.
>
> Cheers, Felix
>
> On Sat, Feb 18, 2012 at 10:55 AM, Chris Wozny <address@hidden> wrote:
>>
>> All,
>>
>> After tirelessly analyzing the data from some "flights" today, I've
>> determined that some (if not all) of the issue I'm having is coming
>> from gimbal lock. At such a high angle of attack, I'm seeing phi and
>> psi values rolling over from positive 180 to -180 degrees and vice
>> versa very rapidly. My understanding was that complementary
>> quaternions "solved" the gimbal lock problem. From the commit logs, it
>> looks like Felix and Christophe both put a lot of work into this and
>> wanted to see if either of you saw gimbal locks at all? I know Felix
>> mentioned that any quaternion method taking Euler angles as input can
>> run into these singularities, but I just wanted to double check since
>> the almighty wikipedia says the quaternions are an alternate to Euler
>> angle solutions and are not intertwined. At this point, I have a
>> feeling that the only solution to this problem would be to mount the
>> Lisa board (with IMU on it) in a perpendicular fashion to the
>> fixed-wing VTOL aircrafts' chord line.
>>
>> Best,
>> Chris
>>
>> On Fri, Feb 17, 2012 at 5:42 PM, Chris Wozny <address@hidden> wrote:
>> > All,
>> >
>> > I've run into a peculiar situation with my PD gains for pitch on my
>> > elevons in AUTO1. I'm using Lisa/M 1.0 on the dev branch. The
>> > deflection I'm receiving to counteract the motion of the aircraft in
>> > pitch is correct (i.e. PITCH_DGAIN is correct.) However, the
>> > proportional gain is the opposite of what it should be doing i.e. when
>> > I'm pitched lower than my set point, the elevons pitch further down
>> > instead of trying to pitch the aircraft back up. The obvious
>> > correction to me would be to flip the sign on the PITCH_PGAIN, but the
>> > range on the numbers is only negative and zero, so I don't know how
>> > that would work. Does anyone know how to flip the effect of the
>> > PITCH_PGAIN? The pitch and roll commands in MANUAL work properly so I
>> > don't think it could be a reversal of the servos that would fix it
>> > (especially since the PITCH_DGAIN works properly.) Finally, the servos
>> > do not hold their commanded position in AUTO1 and overshoot when going
>> > from the commanded pitch/roll back to neutral. I've included the logs
>> > of the flights, the airframe configuration, and even the video of the
>> > (attempted) flight which the logs correspond to. Has anyone seen this
>> > type of behavior from their aircraft?
>> >
>> > Video of (Attempted) Flight
>> > http://www.youtube.com/watch?v=i9y_Nh8QQYY
>> >
>> > Video of Commanded Input in AUTO1
>> > http://www.youtube.com/watch?v=uDeERiqehjU
>> >
>> > Airframe Configuration
>> > http://ece.arizona.edu/~cwozny/mini_vertigo_az_high_aoa.xml
>> >
>> > Flight Data/Log
>> > http://ece.arizona.edu/~cwozny/flight_03_filmed.data
>> > http://ece.arizona.edu/~cwozny/flight_03_filmed.log
>> >
>> > I hope everyone has a good weekend!
>> >
>> > Cheers,
>> > Chris
>> _______________________________________________
>> Paparazzi-devel mailing list
>> address@hidden
>> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel