TRI motor pitch calculation wrong?

[Hamburger]

Hi,
while it works, I think the calculation for pitch in the motor code is wrong. It says:

Code: Select all

  #ifdef TRI
    motor[0] = rcCommand[THROTTLE] + axisPID[PITCH]*4/3 ; //REAR
    motor[1] = rcCommand[THROTTLE] - axisPID[ROLL] - axisPID[PITCH]*2/3 ; //RIGHT
    motor[2] = rcCommand[THROTTLE] + axisPID[ROLL] - axisPID[PITCH]*2/3 ; //LEFT

For pitch movement, this gives equal thrust factor part for rear and combined front motors (just opposite direction to induce pitch movement).
Now this would create movement around geometrical middle of roll-axis (rear motor and projection of front motors on roll axis, to be precise).
But what we want is the rotation point to be at the center of gravity. That is at 2/3 from rear motor, not 1/2!
This means that with current code we pitch around a point that lies behind the COG, right?

If this force distribution should be based on geometry and rotation point should be the COG, then the code must read

Code: Select all

  #ifdef TRI
    motor[0] = rcCommand[THROTTLE] + axisPID[PITCH]*4/6 ; //REAR
    motor[1] = rcCommand[THROTTLE] - axisPID[ROLL] - axisPID[PITCH]*1/6 ; //RIGHT
    motor[2] = rcCommand[THROTTLE] + axisPID[ROLL] - axisPID[PITCH]*1/6 ; //LEFT

What do you think?
Hamburger

[Felch]

I tested your correction and at least on my Tri it works. Somehow it looks like tri is now better controllable.

[Hamburger]

I tested your correction and at least on my Tri it works. Somehow it looks like tri is now better controllable.

thanks for testing and feedback.
I could not find any other piece of code where geometry is taken into calculations. but maybe Alex did it deliberately this way with good reason?
Hamburger

[Centurian]

I remember thinking a bit about this early on but have not revisited it... by the same logic should the rolls be divided by 2 to sum the absolutes to 1 as well or the pitches should be doubled to sum to 2?

I'll be playing with this to see.

Will be intersting to hear alex's take on this.

[Hamburger]

I remember thinking a bit about this early on but have not revisited it... by the same logic should the rolls be divided by 2 to sum the absolutes to 1 as well or the pitches should be doubled to sum to 2?

Will be intersting to hear alex's take on this.

thanks for sharing your thoughts. I think with roll it does not really matter because you would only linearily and equally scale the input with a uniform factor. But with the pitch it is about considering geometrically based distribution.

Just for a moment, consider a TRI where you fold the two front arm so far back that they are perpendicular to the center i.e. COG. In my opinion the center of pitch-rotation should still be the COG, not the geometric means (somewhere halfway to the rear motor in this case).

I concurr, interesting to hear Alex.
Hamburger

[Alexinparis]

As I said previously to you Hamburger, I did not follow exactly the ideal proportion just to ease flips with my tricopter,
but I agree there should more empirical tests to conclude.

The ideal proportions are generally not exactly respected in the code (not only for TRI), but surprisingly it doesn't affect a lot the attitude.

[tobias.tanke]

Since many people already are using the multiwii software for tricopters I assume it works well. The problem is that when I look at the mix for tricopters (in version 1.9) it doesn't make any sense to me - here it is:

Code: Select all

    motor[0] = PIDMIX( 0,+4/3, 0); //REAR
    motor[1] = PIDMIX(-1,-2/3, 0); //RIGHT
    motor[2] = PIDMIX(+1,-2/3, 0); //LEFT

My tricopter have the motors separated by 120 degrees and the arms are equally long. I also have CG in the point where the three arms intersect. This is the geometry that the code is supposed to work for, right?

I use 1 as the distance between the left and right motor. That means that the contribution in torque from the left and right motors in the roll-axis are 0.5 each but with opposite signs. Just as a reference for the roll-axis:

• Max torque on roll = 1*0.5 - (-1*0.5) = 1
• Torque balance on roll = 1*0.5 + (-1*0.5) = 0

The units here doesn't really matter its just about proportions. My idea is that you want to balance the torque on both sides of CG so you get a rotation around CG and not some other point. If I do the same calculation for pitch using the mix in version 1.9 you get:

• Max torque on pitch = (4/3)*0.58 - (-2*(2/3)*0.29) = 1.16
• Force balance on pitch = (4/3)*0.58 + (-2*(2/3)*0.29) = 0.39

I calculated that the distance between the front motors and CG in the pitch-axis is 0.29 and the distance to the rear motor is 0.58 (twice as long). The max torque tells us that it might be more "touchy" in pitch-axis than in roll-axis. The torque balance tells that the rotational center will be in front of CG.

I did some calculations and came up with this mix:

Code: Select all

    motor[0] = PIDMIX( 0,+1, 0); //REAR
    motor[1] = PIDMIX(-1,-1, 0); //RIGHT
    motor[2] = PIDMIX(+1,-1, 0); //LEFT

And if I apply the same checks as before for the pitch-axis with the new mix I get:

• Max torque on pitch = 1*0.58 - (-2*1*0.29) = 1.16
• Torque balance on pitch = 1*0.58 + (-2*1*0.29) = 0

I guess I'm wrong since most people seems to be happy with the current mix, but I can't understand why it should be as it is... Please could anyone explain to me?

[tobias.tanke]

And another question about the mix: When the rear motor is tilted the force in the pitch-axis decreases.

Wouldn't it be a good idea to increase the speed of the rear motor the more the motor is tilted?

I guess that the PID-regulation for the different axis will take care of this and balance things up to get the proper behaviour. But it is easy to take this knowledge about the tricopters design in the mix-code. If one want to avoid trigonometric functions I guess a linear approximation for this might be good enough!?

Decreasing the depdency between pitch and yaw must improve the stability of the PID-regulation and thus the control of the tricopter.