Testing showed it is possible to use the accelerometer to measure the vibration from a moving prop. With an optical sensor identifying the phase of the motor (its angle of rotation compared to some arbitrary position - a piece of black insulation tape on the shiny motor can), the vibration can be correlated with a motor position, and so know which part of the motor has the most weight.

The accelerometer is noisy, there is unwanted vibration, including the motor speed controller, possible resonance, and the quad copter frame transmits vibration in different amounts depending on direction (motor pushing into the frame arm has move force than motor pushing frame arm to the side). So the motor must be measured for 30-60 seconds for the pattern to become clear. Sometimes measuring at different speeds helps, too slow and the problem doesn't show up, too fast and there is so much vibration it appears as noise.


This method has been incorporated into a modifed MultiWii V2.0 , and the readquad program on the Bifferboard. For some reason I haven't got around to incorporating this into the GCS - likely because I didn't know if this method would work at all.

It does work, but interpretation and getting a good result requires trial and error. Sometimes a lot of trial and error, but at least the result can be seen and is repeatable.

Putting 5mm x 10mm insulation tape about half way along a blade clearly shows up, and then moving to the other blade clearly shows up as a shift in 180 degrees. In the code I generally only refer to clock hours - degrees has too much resolution to be useful.

Unmodified prop:

Insulation tape on 6 o'clock blade end:

Insulation tape moved to 12 o'clock blade end:

Insulation tape on 6 o'clock at half way:

These screens are accessed by ssh'ing to the Bifferboard, killing the running readquad, and then running readquad again, which puts its output in that terminal. From another window, an awk command prepares a short packet that is fed into netcat and sent to readquad, which triggers the balancing code and disables all the MultiWii code. Every tenth prop rotation, readquad is sent x and y magnitudes for a full rotation. Up to 50 measurements per rotation, with measurements skipped to try to fill the 50 samples without overflowing.

For each  x and y accelerometer pair, readquad  then converts the x and y into an angle, and subtracts it from the motor angle to get a vibration direction relative to the motor. The x and y accelerometer magnitude is used as the vibration magnitude. Angle and magnitude are then recorded over around 30 - 60 seconds of the motor running to build up a picture of the most popular magnitudes and directions, shown as a crude contour in ascii. As I recall, dot is greater than 5% of the data, and hash is greater than 50% of the data (or it is 50% and 95%, must check the source).


Props aren't very well balancing for use on quad. During the most initial testing the quad would twitch and jump at random. Looking around on the forum, this was a prop balance issue and the best method seemed to be trial and error - adding tape to the blades and feeling if it was better or worse than before. This was tested and it sorta worked, but better and worse is hard to compare, making the results erratic.

The solution was to make the issue quantitative by using the accelerometer built onto the quad. In theory, it is possible to sense the push/pull of the unbalanced prop as it rotates. Testing the xxx accelerometer in my quad showed that it could measure 3 axis of accel in 350 useconds. Enough to get many measurements per rotation, and so enough to get some clear data.



Testing for suitability (using old ball mouse optical sensor), measuring the working mouse before it was de-soldered. LED runs at 0.95V and 0.75V, and photo transistor pins 1 2 3, Lit 2-3 is 2.1V, shaded is 4.9V. Lit 1-2 is 2.1V, shaded is 4.3V. Then picked suitable resistors that drove the LED at around 1V, and pulled the transistor output high when the photo transistor was dark, but the reflective case of the motor can was enough to pull the high to low. The weak-pull up in the Arduino turned out to be too strong, it must be much weaker.