Servo outputs in AP_MotorsTailsitter.cpp: buggy?

MaxBuzz · July 2, 2022, 2:20pm

I am building a bicopter, which I could make fly yesterday. It has flaps instead of motor gimbaling (the control laws are nearly identical, however), but otherwise it is a standard bicopter (Copter firmware, FRAME_CLASS=10).

And I have two questions now, which seem to qualify as bug reports.

Bicopters have a left motor (function 73), a right motor (function 74), a left motor tilt servo (function 75) and a right motor tilt servo (function 76). However, if the outputs are configured this way, and if servo reversals are set such that they counteract pitch changes, they accelerate yaw changes, resulting in wild yaw spinning. The following video illustrates that. One case was clockwise, another one counter-clockwise, and one can see the flaps actually maximizing yaw rotation speed as much as possible, to their maximum deflection.

To make it work, one needs to set the right motor servo to the left tilt function, and vice versa. Again, same would happen if one uses actual motor tilting instead of flaps.

One more note is that the Complete Parameter List mentions function 75 as TiltMotorFrontLeft and 76 as TiltMotorFrontRight. There is no other choice in the Copter firmware, but the sources also mention function 46 (k_tiltMotorRearLeft) and 47 (k_tiltMotorRearRight) with “rear” instead of “front”. In the same sources, however, function 75 is named k_tiltMotorLeft, without any indication that it is about a front motor.

So it looks like some refactoring was not as smooth as expected: it might possibly be that the effect of tilting a front left motor should be the same as tilting the right motor of a bicopter, but the particular outputs in AP_MotorsTailsitter.cpp have the wrong sign in any case.

Checking that further led me to more confusion. Lines that produce servo outputs are exactly as follows:

github.com

ArduPilot/ardupilot/blob/a7aa77ff86ae36cef393135868b87472f23a7a9c/libraries/AP_Motors/AP_MotorsTailsitter.cpp#L212


      
          
          
    // compensation_gain can never be zero
              // ensure accurate representation of average throttle output, this value is used for notch tracking and control surface scaling
              if (_has_diff_thrust) {
                  _throttle_out = (throttle_thrust + thr_adj) / compensation_gain;
              } else {
                  _throttle_out = throttle_thrust / compensation_gain;
              }
          
          
    // thrust vectoring
              _tilt_left  = pitch_thrust - yaw_thrust;
              _tilt_right = pitch_thrust + yaw_thrust;
          }
          
          
// output_test_seq - spin a motor at the pwm value specified
          //  motor_seq is the motor's sequence number from 1 to the number of motors on the frame
          //  pwm value is an actual pwm value that will be output, normally in the range of 1000 ~ 2000
          void AP_MotorsTailsitter::_output_test_seq(uint8_t motor_seq, int16_t pwm)
          {
              // output to motors and servos
              switch (motor_seq) {

However, in bicopters in particular, and to some extent in dual-motor tailsitters too, one cannot just map the desired pitch/yaw thrust to servos that tilt motors (or that control flaps), since that thrust is a fraction of the motor thrust.

Note that e.g. CoaxCopter does the right thing in a similar place.

github.com

ArduPilot/ardupilot/blob/a7aa77ff86ae36cef393135868b87472f23a7a9c/libraries/AP_Motors/AP_MotorsCoax.cpp#L199


      
          _thrust_yt_ccw = thrust_out + 0.5f * yaw_thrust;
          _thrust_yt_cw = thrust_out - 0.5f * yaw_thrust;
          
          
// limit thrust out for calculation of actuator gains
          float thrust_out_actuator = constrain_float(MAX(_throttle_hover * 0.5f, thrust_out), 0.5f, 1.0f);
          
          
if (is_zero(thrust_out)) {
              limit.roll = true;
              limit.pitch = true;
          }
          // force of a lifting surface is approximately equal to the angle of attack times the airflow velocity squared
          // static thrust is proportional to the airflow velocity squared
          // therefore the torque of the roll and pitch actuators should be approximately proportional to
          // the angle of attack multiplied by the static thrust.
          _actuator_out[0] = roll_thrust / thrust_out_actuator;
          _actuator_out[1] = pitch_thrust / thrust_out_actuator;
          if (fabsf(_actuator_out[0]) > 1.0f) {
              limit.roll = true;
              _actuator_out[0] = constrain_float(_actuator_out[0], -1.0f, 1.0f);
          }
          if (fabsf(_actuator_out[1]) > 1.0f) {

This problem should manifest itself either on higher-than-hover or lower-than-hover thrusts as over-actuation or under-actuation correspondingly.

Before I delve into trial-and-error, could @iampete, @rmackay9, or any other guys, please check whether this analysis makes sense?

iampete · July 2, 2022, 2:30pm

There correct for tilting motors, your using them for elevons.

Your right, it is not implemented in copter but we have lots of options for tailsitters on plane. See:

github.com

ArduPilot/ardupilot/blob/a7aa77ff86ae36cef393135868b87472f23a7a9c/ArduPlane/tailsitter.cpp#L601


      
              if (transition_angle_vtol == 0) {
                  return transition_angle_fw;
              }
              return transition_angle_vtol;
          }
          
          
          /*
            account for speed scaling of control surfaces in VTOL modes
          */
          void Tailsitter::speed_scaling(void)
          {
              const float hover_throttle = motors->get_throttle_hover();
              const float throttle = motors->get_throttle_out();
              float spd_scaler = 1.0f;
              float disk_loading_min_throttle = 0.0;
          
              // Scaleing with throttle
              float throttle_scaler = throttle_scale_max;
              if (is_positive(throttle)) {
                  throttle_scaler = constrain_float(hover_throttle / throttle, gain_scaling_min, throttle_scale_max);

MaxBuzz · July 2, 2022, 5:09pm

I see: this one changes the sign depending on whether the point where we apply the force is above the center of gravity, or below it. In a typical tiltmotor, it is above, in a flapped vehicle it is below. Got it!

I will try to fix the second thing then. It seems like, unlike planes, there are fewer options - but one would also like to account for the additional yaw moment when rolling, which is also not in the Copter’s codebase now.

MaxBuzz · July 24, 2022, 1:47am

@iampete am I right that one cannot currently read the vehicle’s attitude (e.g. pitch) from a subclass of AP_Motors?

Or maybe AC_AttitudeController is a more suitable place to take care of too-high or too-low center of gravity? It seems that quadcopters have decent authority against the impact of the off-center CoG by just using I-terms, but in bicopters pitch is too quick to rotate but has relatively poor authority.

iampete · July 24, 2022, 10:29am

Right, AP_Motors should not need to know attitude. AC_AttitudeControl is the right place for such things. You may have to add some methods so you can pass the right numbers on to motors.

I’m not sure I understand the problem your having, maybe you can explain in more detail?