Line 35 of your code sets a 400ms delay between readings of the MPU. That's forever compared to any motion that would be caused by the unbalanced prop om the motor.

Try two things:

Without changing anything else, remove the propellor and see it that makes any difference.
Change line 35 from 400 to 10 and see if the errors look different.

 

I am totally baffled by your code. The wire library is used to communicate with I2C devices. The encoder in the video certainly is NOT such a device. I am amazed that it works at all. Perhaps I missed something. In fact, my misunderstanding is only explained by missing something.

The video creator posted a link to the code he was using. His code does exactly what I expect. He uses the two pins to trigger two separate interrupts. In their associated interrupt service routines (ISR), he increments or decrements a counter.

Here is his code. See how much it differs from the code you posted. Perhaps you could try it?

volatile unsigned int temp, counter = 0; //This variable will increase or decrease depending on the rotation of encoder  
   
    void setup() {
    Serial.begin (9600);
   
    pinMode(2, INPUT_PULLUP); // internal pullup input pin 2
   
    pinMode(3, INPUT_PULLUP); // internalเป็น pullup input pin 3
    //Setting up interrupt
    //A rising pulse from encodenren activated ai0(). AttachInterrupt 0 is DigitalPin nr 2 on moust Arduino.
    attachInterrupt(0, ai0, RISING);
   
    //B rising pulse from encodenren activated ai1(). AttachInterrupt 1 is DigitalPin nr 3 on moust Arduino.
    attachInterrupt(1, ai1, RISING);
    }
   
    void loop() {
    // Send the value of counter
    if( counter != temp ){
    Serial.println (counter);
    temp = counter;
    }
    }
   
    void ai0() {
    // ai0 is activated if DigitalPin nr 2 is going from LOW to HIGH
    // Check pin 3 to determine the direction
    if(digitalRead(3)==LOW) {
    counter++;
    }else{
    counter--;
    }
    }
   
    void ai1() {
    // ai0 is activated if DigitalPin nr 3 is going from LOW to HIGH
    // Check with pin 2 to determine the direction
    if(digitalRead(2)==LOW) {
    counter--;
    }else{
    counter++;
    }

 

MPU 6050 works perfectly well when it has low frequency vibration such as vibrating with my hand. However, the angle readings are jumping all over the place **(can be 90 degrees difference-A lot)** when I turn on the microbrushless motor (high frequency small vibrations) . Any ideas on how to solve it ?

Use a soft foam pad for attaching the gyroscope to your rig. Best pads are special ones for model helicopters (for F3C class helicopters). Maybe you must add some digital filter routines for smoothening the gyroscope readings, for example FIR for simplicity.

 

Line 35 of your code sets a 400ms delay between readings of the MPU. That's forever compared to any motion that would be caused by the unbalanced prop om the motor.

Try two things:

Without changing anything else, remove the propellor and see it that makes any difference.
Change line 35 from 400 to 10 and see if the errors look different.

I HAVE FINALLY SOLVED THE PROBLEM. I got a secret code from the web that can handle vibration and it works extremely well on any circumstances no matter how hard the vibration is and I even swing it so violently with the motor at max power with a lot of vibration.

 

It was never about hardware. It's all Software

 

What I don't see in your code is any reference to quadrature.h or whatever encoder library you are using.

 

I HAVE FINALLY SOLVED THE PROBLEM. I got a secret code from the web that can handle vibration and it works extremely well on any circumstances no matter how hard the vibration is and I even swing it so violently with the motor at max power with a lot of vibration.

Why is it “secret code”? Can’t be too secret if you found it online. Could you post it here for future members who are having the same problem. After all, this is a forum in which we share solutions.

This time, use code tags, please.

 

Nobody here has addressed one of the encoder basics: Encoder resolution and speed. If the encoder resolution is 256 full quadrature cycles per revolution then it can generate 1024 edges per revolution. At one revolution per second (60 RPM) that is less than 1 millisecond per edge. If an edge takes 100 us to process then slightly less than 600 RPM will be the maximum speed you can deal with. And that assumes perfect 50% duty cycle encoder signals, which they aren't, so the max allowable speed drops down a bit more.

Take your own encoder resolution and motor speed to figure out what you need from the processor, then see if your processor and code can do that. If it can't then use a faster processor, or add a dedicated quadrature encoder chip.

 

Thus far I have not seen any hint about any application description, or any requirements for the motor/encoder package. That affects what is done a whole lot. Or maybe this is somebody just playing with a motor encoder setup to learn.
And "secret software" has a nasty smell to it.

 

Thus far I have not seen any hint about any application description, or any requirements for the motor/encoder package. That affects what is done a whole lot. Or maybe this is somebody just playing with a motor encoder setup to learn.
And "secret software" has a nasty smell to it.

See this guy's other threads!
This is not about a motor rotor position detection but about a "propeller pendulum" !
https://forum.allaboutcircuits.com/...ller-pendulum-to-balance-horizontally.190719/

(Otherwise using an MPU in place of the encoder wouldn't be possible.)

 

OK, I looked at that thread and lost interest.
(added comment): it would have been a courtesy to us if the TS had described the application earlier.