mixer saturation handling

[wynn4]

trafficstars

For multirotor research platforms that are likely heavy and slow, there seems to be a problem with how the current mixer handles saturation. In the plot below of the raw motor outputs, the copter was hovering pitched slightly into the wind (5 mph) and a strong yaw command was given via RC. This lead to motor 3 saturating and the other motors going to zero (crash). This was a 450 size platform with 10" props and mass of 1.41kg.

Talking with @superjax , the code that drives this behavior is here in mixer.cpp

// saturate outputs to maintain controllability even during aggressive maneuvers
  float scale_factor = 1.0;
  if (max_output > 1.0)
  {
    scale_factor = 1.0/max_output;
  }



  for (int8_t i=0; i<8; i++)
  {
    // Write output to motors
    if (mixer_to_use_->output_type[i] == S)
    {
      write_servo(i, unsaturated_outputs_[i]);
    }
    else if (mixer_to_use_->output_type[i] == M)
    {
      // scale all motor outputs by scale factor (this is usually 1.0, unless we saturated)
      unsaturated_outputs_[i] *= scale_factor;
      write_motor(i, unsaturated_outputs_[i]);
    }
  }

Perhaps this type of mixer is still appropriate for really powerful and aggressive quadrotors and maybe there should be a param for setting which saturation scheme to use depending on the type of platform you're flying. In the situation that caused this failure, I wasn't trying to do anything crazy or aggressive. I was just trying to yaw to face north while hovering, and as I said there was a 5 mph headwind.

Hardware configuration Firmware version: v1.0.0 Sensors: IMU, barometer, magnetometer Board: Flip32

[superjax]

We have two ideas for fixing this:

1. Don't allow more than 10% deviation from desired command (saturate scale_factor to 0.9)
2. Don't allow throttle input higher than 0.9 and don't do any output scaling.

@dpkoch, do you have any ideas or input?

[korken89]

Another way to handle it is to implement a feature similar to "AirMode" in BetaFlight, it does adaptive handling of saturation. Practically scaling or boosting throttle if it will saturate the torque commands on the high or low end, always(-ish) keeping the system in a controllable configuration. Not quite MPC constraints good, but quite close.

Good video about it: https://www.youtube.com/watch?v=d2nRrVENEYM

[superjax]

@korken89 That's awesome! Thanks for sharing that.

That video spoke mainly about the low-throttle situation. We've typically had issues at high throttle (because we are typically carrying way too much stuff), is the same logic applied at high throttle?

[korken89]

Yes, in betaflight I believe it is only in the low end, but the same idea works fine on the high end. :) Usually the issue is that throttle saturates the torque commands, which is why this method came to mind.

[bsutherland333]

This would be a good thing to resolve, if it hasn't been done already.