Correct motor mix parameters for Electrohub spider quad w/ MW Flip

joshuabardwell

Senior Member
Mentor
I have been doing some research to try to come up with correct motor mix parameters for the Electrohub spider quad. The MultiWii Flip that FT recommends has an X-quad configuration built in, and the Electrohub spider quad is perfectly flyable with this configuration, but it does have some undesirable flight characteristics that leave me wondering whether they're the result of the default motor mix not being right. Specifically, the default motor mix for an X quad assumes the motors are equidistant from the CG, and that they are arranged in a square. If any of these assumptions don't hold (and neither of them hold for an X quad), unintended flight characteristics will result.

I should disclaim all of this by saying that I am very much a beginner at multirotors, flight controllers, and MultiWii specifically. But I have a strong background in programming, computers, electronics hobby-ing, and so forth. So I think I may be qualified to take the somewhat-inscrutable instructions found on the Internet and translate them into a form that others can use.

Everything in this thread is based on this post. http://polakiumengineering.org/custom-multiwii-motor-mixes/

To make a motor mix, the first thing you do is map out the X/Y coordinates of your motors on a Cartesian plane, with the copter's CG at the origin (0,0) point. The simplest way to do this is to measure the distance between your front motors and divide it by two. Do the same for your back motors. You now have the X coordinates for the motors.

One way to find the Y coordinate is to measure the distance from the CG and the motor, treat that as the hypotenuse of a triangle, and use that combined with the previously-measured X coordinate to solve for the remaining side via the Pythagorean Theorem. This involves square roots and math, which many don't like. Another way is to set the craft face-first on a table and measure from the table, straight up the center-line to the CG. This wouldn't work with all motor configurations, but it will work with any X-quad configuration, including a spider quad.

Now that you have the X/Y coordinates of each of the motors, assign positive and negative signs as appropriate. Front-left motor is -X/+Y. Front-right motor is +X/+Y. Back-left motor is -X/-Y. Back-right motor is +X/-Y. This is just high school geometry. Finally, you need to scale the measurements down to a zero-to-one scale so that the largest measurement is 1 and the other measurements are proportional to that. The easiest way to do this is to divide each measurement by the largest measurement. Incidentally, an implication of this is that it doesn't matter at all what units you have measured the distances in, since the units will cancel out in this step.

Now that you have your scaled coordinates, you are 2/3 of the way there. Next, you need your yaw coordinates. For the yaw coordinates, the first thing to know is that the sign will determine which direction the FC believes the motor is spinning. CW motors get a negative sign. CCW motors get a positive sign. The magnitude of the yaw parameter should be equal to the (scaled) X parameter. I don't know the details of why this is, but this causes the quad to yaw around its CG instead of some other point in front of or behind the CG.

Now that you have all three parameters for all four motors, you put that all together in the correct syntax for MultiWii, which is:

Code:
motor[n] = PIDMIX(-X,-Y,YAW_PARAMETER);

For a quad, there will be four of these statements--one for each motor. The motors are numbered 0-4. These motors map to motor positions as follows:

0 = rear right
1 = front right
2 = rear left
3 = front left

Note that the X and Y parameters each have a negative sign in front of them, which means you invert the sign of the coordinates. For the yaw paramter, the sign is determined by the direction of the motor, and the magnitude is equal to the absolute value of the X parameter.

Now that I have explained it all, here is a spreadsheet I made that does all the work for you. ;)

MW motor mix.png

... and here is a link to the spreadsheet itself.

PLEASE NOTE: I have not tested these parameters yet, so use them at your own risk. Your quad's measurements and CG are probably different from mine, so take the time to measure and plug them into the spreadsheet. Also, I don't promise that I haven't made a mistake in the spreadsheet's syntax that produces incorrect results.
 

joshuabardwell

Senior Member
Mentor
How to modify the MW sketch to push these parameters to the FC is the next step. The instructions in the link above are out-dated and there is an easier way. More to come tomorrow...
 

jhitesma

Some guy in the desert
Mentor
Great stuff! Can't wait to see how it does in the air, I wouldn't be surprised if it solves the little issues you're having.
 

finnen

Senior Member
I just scratch built a spider quad based on the electrohub dimensions, and I'm waiting for my flip 1.5 to show up. Subscribing to this! I'll try without mods first, but then I'm jumping into the code to see if I can modify the motor mix. I work as a programmer, so that should be fine, but I wasn't sure of the math, now that you gave that to me, I should be fine.
 

Craftydan

Hostage Taker of Quads
Staff member
Moderator
Mentor
Interesting . . .

The numbers in the yellow box are reversed in sign from the sheet . . . why?

Why are the yaw values less than 1/-1 for the rear two motors?

You've based this all on measuring off your CG . . . which shouldn't be a random point. How did you determine your ideal CG?

(I'm not being critical of your work here -- it's very good! -- just wanting to flush out whys and hows in the details :) )
 

Balu

Lurker
Staff member
Admin
Moderator
I was just working at trying to figure this out myself. :)

This assumes that the flight controller is located at the center of gravity, right?

One thing that I can't get my head around is that the center of thrust and the center of gravity should align. The calculated mixing is supposed to do that? But that also means that some of the motors will not run in their full range of speed, because they are "tuned down"?
 

joshuabardwell

Senior Member
Mentor
The numbers in the yellow box are reversed in sign from the sheet . . . why?

The syntax template indicates that the Cartesian X and Y values must be negated. I don't know why, but an examination of the #define statement for PIDMIX() would be the next place I would look. Somewhere down the line, there is an algorithm that needs the negation of the Cartesian X and Y value.

Why are the yaw values less than 1/-1 for the rear two motors?

The site I was reading off of said that if your quad is not symmetrical across its diagonal axis, then using 1/-1 for the yaw parameters will cause it to yaw around a point that is behind its CG--approximately where the lines between the front and back motors would intersect. In other words, a yaw input would result in both a yaw and a translation. Setting the yaw values equal to the magnitude of the X coordinate causes the quad to yaw around its CG. Again--I don't know why this is, but that's what the page said.

You've based this all on measuring off your CG . . . which shouldn't be a random point. How did you determine your ideal CG?

I don't think it actually matters where the CG is as much on a multirotor like it does for a fixed-wing. Some motors will just spin faster than other motors to adjust the craft's attitude, because they have a longer lever arm, and therefore generate more torque. If you desire to keep your motors spinning exactly the same speed, then physics would dictate that your CG be at a point equidistant from all of your motors. In other words, draw a circle, with all your motors on the circle, and put the CG at the center of the circle. Note that if you have arms of uneven length, this is NOT the same as drawing an X through your motors and putting the FC at the center of the X.

My impression is that the most important thing is that your FC be located at the CG point. Otherwise, yaw input will result in the FC detecting both yaw and translation. Really, I put the FC where the Flite Test guys said to, and then just adjust my battery position on the camera tray to put the CG right under the FC.
 

joshuabardwell

Senior Member
Mentor
This assumes that the flight controller is located at the center of gravity, right?

I believe that's right.

One thing that I can't get my head around is that the center of thrust and the center of gravity should align. The calculated mixing is supposed to do that? But that also means that some of the motors will not run in their full range of speed, because they are "tuned down"?

This is true, but only because the motors are not equidistant from the CG in a typical spider quad configuration. If you were to draw a circle that put all the motors on the circle, and put the FC in the center of that circle, then all motors would be equidistant from the FC. Then adjust your battery position so that the CG is directly under the FC. Now your quad's mix parameters would all be either 1 or -1, and it would fly just like an X quad.

I don't know enough about how motor mixing works to say whether the motors would not use their full speed range or not. But the bottom line is that, if your motors are not equidistant from your CG and your FC, then something needs to change to account for that. If you want to avoid this scenario, set up a pure X quad (or + quad) with the FC and CG dead center.

Another approach might be to build a spider-quad, but move the front motors inwards. This would result in the motors still being in a square relative to each other, as the default X-quad mixes assume. You would need to move your FC and CG back to keep them at the center of the square, but all other complications should disappear. If I was building my Electrohub today, this is what I would try. But for now, I already soldered all my ESC's and motors together, and it would be a bit of a pain to change.
 
Last edited:

Craftydan

Hostage Taker of Quads
Staff member
Moderator
Mentor
The syntax template indicates that the Cartesian X and Y values must be negated. I don't know why, but an examination of the #define statement for PIDMIX() would be the next place I would look. Somewhere down the line, there is an algorithm that needs the negation of the Cartesian X and Y value.

Fair enough . . . it's a convention the board is using. I'd suggest you add a note about it in the post above, but you've just said it here . . .

The site I was reading off of said that if your quad is not symmetrical across its diagonal axis, then using 1/-1 for the yaw parameters will cause it to yaw around a point that is behind its CG--approximately where the lines between the front and back motors would intersect. In other words, a yaw input would result in both a yaw and a translation. Setting the yaw values equal to the magnitude of the X coordinate causes the quad to yaw around its CG. Again--I don't know why this is, but that's what the page said.

hmmm . . . I'm thinking this might be wrong.

First off, laterally this is a pure torque. Sure, there's internal forces involved, but the rigidity of the frame will counter and cancel these internal forces . . . keeping them internal. While a Torque has a source location, it's effect is axial, not positional -- so long as the frame remains rigid, the motor torques will vector add through the CG without any consideration of moment arm. the upward force of the motor has moment on the CG, the torque *IS* a moment on the CG, regardless of placement. the non-CG rotation they talk about would require a lateral force to move the CG laterally . . . a pure torque can't do that.

now I was wondering if this correction was for the difference in moment arms from the motor's positions, but for that, the logic appears to be backwards. The motor with the shortest moment arm will need the stronger correction to counter it's opposite. Might still be convention on the correction parameters, but I think this number might be inversed.

I don't think it actually matters where the CG is as much on a multirotor like it does for a fixed-wing. Some motors will just spin faster than other motors to adjust the craft's attitude, because they have a longer lever arm, and therefore generate more torque. If you desire to keep your motors spinning exactly the same speed, then physics would dictate that your CG be at a point equidistant from all of your motors. In other words, draw a circle, with all your motors on the circle, and put the CG at the center of the circle. Note that if you have arms of uneven length, this is NOT the same as drawing an X through your motors and putting the FC at the center of the X.

true -- these boards can compensate over a wide variety of CG placements -- but it's not without a cost. Ideally the motors will balance on their own at a fixed RPM (with only dynamic corrections for balance). Why would this ideal matter? balancing motor loading for one (too far off and one or more motor might start running hotter), and range of correction -- to counter off-balance with a motor you'll bend it's correction to one side, reducing the remaining correction and command available for movement.

Building a little out of balance in this manner will still work and won't cost you much, but it still isn't free. the closer you build to balanced, however, the more the board is free to use it's correction range fly as opposed to making corrections . . . yielding a better flight envelope.

As for finding that ideal CG, I prefer the weighted average method -- but it requires you picking an origin before you know where your CG is . . . so now we have two origins -- one for finding the CG (I like picking along the center-line, aligned with the rear motors) and one for balancing the motor mix (at your ideal CG). It's not hard, but as you've demonstrated it involves juggling numbers and coordinates. On the bright side, the weighted averaging will work with unmatched motor sizes and KV's . . . assuming you have motor data . . .

My impression is that the most important thing is that your FC be located at the CG point. Otherwise, yaw input will result in the FC detecting both yaw and translation. Really, I put the FC where the Flite Test guys said to, and then just adjust my battery position on the camera tray to put the CG right under the FC.


Yup! with the gyro on the CG all it gets is twist when the frame banks, and the farther it gets form the CG the more that twist gets traded for linear motion. too much and the vibe and noise on the frame drowns out signal the gyro's twisting.

That's a fairly good strategy and it genuinely is amazing the slop in the build and setup these boards will compensate for, but if you want that extra edge of cleanliness, getting the cg at the ideal balance point and the board over the CG and the corrections better matching the motor positions is the way to do it :)
 
Last edited:

joshuabardwell

Senior Member
Mentor
Fair enough . . . it's a convention the board is using. I'd suggest you add a note about it in the post above, but you've just said it here . . .

You mean like this? ;)

Note that the X and Y parameters each have a negative sign in front of them, which means you invert the sign of the coordinates.

First off, laterally this is a pure torque. Sure, there's internal forces involved, but the rigidity of the frame will counter and cancel these internal forces . . . keeping them internal.

I honestly am out of my depth here and am just repeating what I read at this page. My interpretation was that the yaw mix parameters could result in the board giving both roll and yaw output in response to a yaw input. Else the described behavior, of the quad "swinging wide" on yaw input wouldn't be possible.

Building a little out of balance in this manner will still work and won't cost you much, but it still isn't free. the closer you build to balanced, however, the more the board is free to use it's correction range fly as opposed to making corrections . . . yielding a better flight envelope.

Yes. I have been playing around in GeoGabra and have come up with this:

quad_geometry.png

Note the difference between the "ideal" CG (the motor-circle-center) and the CG I have chosen. This graphic is slightly wrong somewhere, as the distance between the front and back motors is a few inches shorter than the measured distance on my quad, but it's not too far off, and it gets the point across. It might have been better to place the FC further forward on the board, but I couldn't have known that at the time I started building. Frankly, I'm not sure it would be very easy to move the CG that far forward given the quad's current configuration.
 

joshuabardwell

Senior Member
Mentor
... thinking some more about the "yaw" question. If a motor was far forward of the CG, then it would need to give less yaw input to effect a given torque than a motor closer to the CG. Maybe the statement, "The craft will 'swing wide' as if it was yawing around a point farther behind it," means simply that the yaw gains will be wrong, rather than it will physically translate through space as if it was pivoting around a point other than its physical CG. What the actual effect on handling would be, I don't know. It would be relatively easy to test this, though. Perhaps take a symmetrical quad (for standard reference) and change the yaw gains, and only the yaw gains, for the rear motors, from 1 to 1.5 or something like that. Then, in acro mode, hover, and input yaw only and see what happens.
 

joshuabardwell

Senior Member
Mentor
Okay. I have re-done the diagram and am sure the numbers are right this time. I'm not sure where the error was introduced before. This diagram shows that the place the FT guys said to mount the flight controller is nearly dead-on the center of the circle inscribed by the motors.

quad_geometry.png

Please bear in mind that the lines in the above diagram are NOT the location or length of the arms. The lines are from the FC to the motor. Especially for the front arms of the spider quad, the actual arms are at a different angle that is not actually relevant from the perspective of the flight controller.

I feel confident saying that, if you build the ElectroHub as the FT guys indicate in their build video, you should get pretty similar numbers to what's shown here. For reference, I have my flight controller mounted 1.5" forward of the 180-degree point on the ElectroHub. I am using the base of the "forward" arrow on the case of the Flip (purchased from RTFquads) as the FC's location for the purpose of this diagram.

Here is the motor mix that results from this diagram.

MW motor mix.png
 
Last edited:

joshuabardwell

Senior Member
Mentor
Okay. Once you have worked out the right parameters for the mix, how do you upload it to your FC? The answer is here:

http://www.multiwii.com/wiki/index.php?title=Config.h#Individual_Mixing

There are other sets of instructions that involve manually editing defs.h, but this method seems to be simpler. I can't really add anything to what's already in the above link, so I'll just leave it here. One gotcha is that, if you create the "filename.h" file inside your MW Flip's sketch folder, but you don't re-open the MW Flip's main sketch, then the Arduino environment won't recognize that the new .h file is present. You must save the .h file and then re-open the MW Flip's main sketch, at which point the .h file should show up as a tab in the Arduino IDE.

The only thing left to do is flash and fly. Maybe tomorrow.
 
Last edited:

joshuabardwell

Senior Member
Mentor
Well, folks, I'm sorry to say that something is not right in my process. With the above settings, the quad yaws to the right, pitches forward, and rolls to the right. I will double check my process to see where my mistake is, although I thought I was pretty meticulous to begin with.

EDIT: I found a mistake. It looks like I entered a positive Y coordinate for the back left motor, when it should be negative. Let's see if that fixes it.

EDIT: Awesome. It's definitely flying better now, although it's a little hard to pin down exactly what's different, because there's a bit of wind now. Basically, it seems to respond to roll input better--translating directly to the side, vs. having unwanted front or back travel in addition to side travel. There is some very small unexpected yaw, but I think that may just be the result of the wind. I won't know for sure until I try it out on a calm day, or indoors.
 
Last edited:

joshuabardwell

Senior Member
Mentor
Okay. Here is the correct code.

Code:
motor[3]=PIDMIX(1,-0.6229,-1); // Front Left				
motor[1]=PIDMIX(-1,-0.6229,1); // Front Right				
motor[2]=PIDMIX(0.8552,0.7688,0.8552); // Back Left				
motor[0]=PIDMIX(-0.8552,0.7688,-0.8552); // Back Right

Put that into a file named "my_spider_quad_mix.h" (or whatever you care to call it). Put that file into the same sketch folder as your MW Flip's .ino file. Then, in config.h, un-comment this line and change the filename to whatever your .h file is.

Code:
// #define MY_PRIVATE_MIXING "filename.h"

That's it!

Since the geometry of the FT spider quads should be pretty much the same for everyone who follows the build video, and since the FC location I (and the FT guys) chose pretty much lines up exactly with the center of the motor circle, I think these mix parameters should work for most people who build an FT Electrohub spider quad. Place the CG about 1.5" forward of the rear of the Electrohub, which corresponds to the screw-holes marked in the attached image. For the FC, I am using the center of the base of the "forward" arrow as the nominal FC location, as indicated in the attached image. So place the FC with the base of the arrow against the indicated line, and with the center of the arrow along the center-line of the Electrohub (note: this is NOT the center of the case). Then move your battery forward or back to place the CG of the quad in the same location.

9-4-2014 2-46-43 PM.png

9-4-2014 2-48-11 PM.png

If you choose to use this file, please take all necessary precautions before flying. If these parameters are substantially wrong, the quad may flip out. Treat this as a brand new maiden. Start with just barely getting light on your skids and work your way up to more aggressive flying.
 

joshuabardwell

Senior Member
Mentor
I have put some more thought into why there is a need for motor mixes at all. The issue appears to be that, if one motor is farther out from the CG than another motor, then the farther motor needs to go through a longer arc to produce an even change in pitch or roll. So imagine that the back-left (BL) motor is 6" from the CG and the front-left (FL) motor is 12" from the CG. If you roll the quad, the front motor has to go through twice the distance of the back motor in order to keep the pitch the same. If both motors go the same arc distance, the net effect will be a pitch to the rear.

But wait? Shouldn't the gyro detect the unwanted change in attitude and correct for it? I think so! And I think that this is part of why copters can fly acceptably even if the motor mixes aren't ideal. But detecting the unwanted change in attitude and correcting it takes time, and the effectiveness is dependent on the quality of the PID gains. Proper motor mixing helps to avoid the unwanted change in attitude in the first place, minimizing the work that the PID algorithm has to do. With proper motor mixing, the motor that is 12" out from the center will thrust twice as hard as the one that is 6" from the center, meaning that, nominally, they will pass through the same arc distance in the same amount of time. In reality, there will still be some work for the gyro to do, but it'll be minimal.

To those who asked, "if I motor mix like this, doesn't it mean that some of my motors will never spin up fully?" The answer may be yes. But the fact is that even if your motor mixes were 100% all the way around, the motor would STILL not spin up, because they gyro would spin it down as soon as it detected the unwanted change in attitude. So if you really want to get 100% from all your motors in all conditions, you need a perfectly symmetrical configuration. But of course, there are reasons why we build spider quads and T copters and so forth instead of square quads. And anyway, my Electrohub is not particularly high-performance, and it has a TWR of 3.2:1. I hover at around 40-45% throttle, and seldom go above 60%. I think I can afford to spare a little thrust on some of my motors. On the other hand, if you were trying to build an ultra-acrobatic quad that squeezed as much thrust as possible out of its motors, a symmetrical layout would be better.

EDIT: And, under the right circumstances, the motor WILL go to 100%, if there is a case where the desired change in attitude requires one motor to move faster than another. So the motor mixes are not like hard limits on your RC servo channels or anything like that. They're just a starting point for how fast to spin the motors to produce only the desired change in attitude.
 
Last edited:

joshuabardwell

Senior Member
Mentor
I have given some more thought to the correct value for the yaw parameter. It seems to me that one purpose of the yaw parameters is to make sure that yawing does not induce un-wanted pitch or roll. Therefore, it seems like the approach of setting the yaw magnitude equal to the roll parameter is not correct. Rather, it seems like the yaw magnitude should be equal to the distance between the motor and the CG (e.g. the hypotenuse of the triangle formed by the pitch and roll parameter.
 
Last edited:

joshuabardwell

Senior Member
Mentor
I am more and more convinced that setting the yaw magnitude equal to the distance from the CG to the motor is the correct approach. For the pitch and roll axis, the magnitude of the parameter is proportional to the motor's distance from the CG along that axis. If we take pitch as an example, imagine looking at the quad from the side. We want the quad to pivot around the CG, therefore the motor that is further out must move farther than the motor that is closer in. If we take the same principle for yaw, and imagine looking down at the craft from the top, the relevant parameter is the distance from the CG to the motor, which is the same as the hypotenuse of the triangle formed by the X,Y coordinates of the motor.

I really have no idea why the instructions I read said to set the yaw gain equal to the roll parameter. This seems totally wrong.

Here are the original numbers, with yaw magnitude equals roll magnitude:

Code:
motor[3]=PIDMIX(1,-0.6229,-1); // Front Left				
motor[1]=PIDMIX(-1,-0.6229,1); // Front Right				
motor[2]=PIDMIX(0.8552,0.7688,0.8552); // Back Left	
motor[0]=PIDMIX(-0.8552,0.7688,-0.8552); // Back Right

And here are the new numbers:

Code:
motor[3]=PIDMIX(1,-0.6229,-1.1781); // Front Left				
motor[1]=PIDMIX(-1,-0.6229,1.1781); // Front Right				
motor[2]=PIDMIX(0.8552,0.7688,1.15); // Back Left				
motor[0]=PIDMIX(-0.8552,0.7688,-1.15); // Back Right
The new numbers produce yaw magnitude that is nearly equal for the front and back motors. For the front motors, the gain has gone up by 0.15. For the rear motors, it has gone up by about 0.30. It will be interesting to see the effect that this has on the craft's yaw performance.
 
Last edited:

walkman1269

Junior Member
I'm also working on a dead cat electrohub with multiwii. I have ver 2.3 quadx loaded on a ez3 pro from whitespy (rtfq) and the polakium engineering said about line 750 in output tab? I found the default motor(0) .... at like 1038....
#elif defined( QUADX )
motor[0] = PIDMIX(-1,+1,-1); //REAR_R
motor[1] = PIDMIX(-1,-1,+1); //FRONT_R
motor[2] = PIDMIX(+1,+1,+1); //REAR_L
motor[3] = PIDMIX(+1,-1,-1); //FRONT_L

do I modify these to fit the geometry that I calculate... or I add this after the y4, Y6 ETC.? I have the deadcat that the Josh's and Peter built in the video. Would your numbers work if I have the CG aligned with flight controller.
 

walkman1269

Junior Member
oops nevermind about the line 750 comment I found your description about using the #define MY_PRIVATE_MIXING "filename.h" above I skipped around a little and missed it.