[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Paparazzi-devel] Tiltrotor-Project

From: Felix Ruess
Subject: Re: [Paparazzi-devel] Tiltrotor-Project
Date: Tue, 7 Jun 2016 20:37:12 +0200

Hi notoriou5,

The general problem with mixing commands is that if you have multiple at once, the resulting command per motor might be out of range of the motor (too high or low).
This is the problem of saturation and we give roll/pitch/thrust higher priority than yaw (as mentioned in the comments) as we deem the roll/pitch stabilization and thrust more important than yaw such cases.
So first sum up these higher prio commands and then bound the yaw command by the remaining authority.

If you want a stronger effect of your yaw command, set a higher value for YAW_COEF in your motor mixing section.
Depending on how exactly you set things up, you also might want to increase the effect of the yaw command on the tilt servo...
How does your mixing/servo set up look now?

Hope that clears things up,

On Mon, Jun 6, 2016 at 3:49 PM, notoriou5 <address@hidden> wrote:
Hello everyone,

I did not write for a long time but the project moves on.

I checked the orientation of the IMU and everything is fine. The Engines
spin in the right direction and the ATTITUDE_DIRECT Mode does work as well.
So everything seems fine so far.

The only problem is with the yaw command. It seems a bit slow i comparison
with the roll and pitch command.

In the code motor_mixing.c I found the following lines:
    /* first calculate the highest priority part of the command:
     * - add trim + roll + pitch + thrust for each motor
     * - calc max saturation/overflow when yaw command is also added
    for (i = 0; i < MOTOR_MIXING_NB_MOTOR; i++) {
      motor_mixing.commands[i] = motor_mixing.trim[i] +
        motor_mixing.roll_coef[i] * in_cmd[COMMAND_ROLL] +
        motor_mixing.pitch_coef[i] * in_cmd[COMMAND_PITCH] +
        motor_mixing.thrust_coef[i] * in_cmd[COMMAND_THRUST];

The Yaw command is not added directly to the output. First they calculate
saturation and overflow. I do not really understand why this is done. I do
also not understand the Code which is following these lines. Can anyone
please explain to me what the saturation and overflow calculation prevent?
And will I have a quicker respond to my YAW reaction if I add
"+motor_mixing.yaw_coef[i]*in_cmd[COMMAND_YAW]" to the top line and
uncomment all the other ones behind this peace of code?

Already thanks for the help,


View this message in context:
Sent from the paparazzi-devel mailing list archive at

Paparazzi-devel mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]