Hello
I've been having issues with a piece of code that I'm writing for my UAV on the STM32F4 discovery board.
The issue is the following: For some reason an addition of a positive number gives a zero or negative result.

// action_potential_X is float
// pitch_scaling_factor = 0.2
// X_group is float

if(action_potential_pitch > 0){
        N_group = action_potential_pitch*pitch_scaling_factor;
        S_group = 0;
    }else if(action_potential_pitch < 0){
        S_group = action_potential_pitch*pitch_scaling_factor;
        N_group = 0;
    }else{
        N_group = 0;
        S_group = 0;
    }


    // Motor outputs
    uint16_t motor0_out;
    uint16_t motor1_out;
    uint16_t motor2_out;
    uint16_t motor3_out;

    // Assign individual motor outputs
    motor0_out = (fabsf(CW_group) + fabsf(N_group) + fabsf(R_group));
    motor1_out = (fabsf(ACW_group) + fabsf(S_group) + fabsf(R_group));
    motor2_out = (fabsf(CW_group)  + fabsf(S_group) + fabsf(L_group));
    motor3_out = (fabsf(ACW_group) + fabsf(N_group) + fabsf(L_group));

    // Update motor outputs
    writeOutput(motor0_out, motor1_out, motor2_out, motor3_out);

You can see here that I went paranoid and put fabsf everywhere even though there are previous checks on ALL the groups for negativity, just in case the compiler was doing something strange (which I think that it is).
The issue is that if I remove the N_group and S_group from the motorX_out assignments then all the motors react uniformly to the input. If I leave them
as it is then motors 1 and 2 (which belong to S_group) do not work until I push the throttle up to about 60%. In other words they behave something like (throttle-60%) . It's as if the S_group is subtracting even though it's supposed to be positive.I've went through the loop with the debugger about 20 times with various values and everything is doing what it is supposed to, but in practice it's not working.

Does anyone have an idea on what is going on? I've been debugging this for about 8 hours now with no luck. The worst part is that the EXACT same thing for roll with the exact same code works no problem, but with pitch I get this issue.

I'm using Coocox IDE with gcc compiler

 

After hours and hours of debugging and sifting through the dissasembly I found out that the issue was not the program at all
but the back motor ESCs which auto calibrated at the beginning to give a 50% deadzone . At least I learned a few ARM assembly instructions...

 

with very very few exceptions, most of posts including a bug claim in the title are just a story about an error or mistake by the TS/OP.
Good that you found the reason.