Hey, I'm curretly using the MotionApps Library by Jeff Rowberg, but I'm encountering an issue, that you can verify yourself (unless it's my sensor to be defective), when reading the euler angles/ ypr coming to the serial monitor, if I try to slide back and forth the breadboard where the MPU is on. Specifically, if I imagine my mpu to be an aircraft, if I slide it along the plane tip direction (roll axis) , i read changes in the pitch angle. But if i read the raw gyro data, there is no change in angular velocity of the pitch (so it shouldn't be caused by a precarious mpu connection), suggesting that the pitch angle in this library is calculated using also the acceleration along that axis. Is this a compromise used to turn gyro readings to angles? Is this avoidable or I'm the ony one experiencing it?
Both pitch and roll are calculated from the accelerometer data. The gyro measures rotation rates, not angles, and so a reference to the "down" direction is required to set the angle origin.
See this tutorial: How_to_Use_a_Three-Axis_Accelerometer_for_Tilt_Sensing-DFRobot
So from that link I undestand that gravity is used to find pitch and roll,and gyro integration is used for yaw, but then why is that an horizontal accelaration with my hand, causes a pitch angle bump in the serial plotter graph? I see how the acceleration vector changes, but wouldn't the library account for that?
The method assumes that the only acceleration acting on the sensor is gravity, which points directly down.
Any other acceleration violates that assumption and introduces an error into the calculation. Under certain circumstances (like turning), the gyro data can help to correct that error. The method gives only an approximate 3D orientation and is not very accurate.
3D orientation sensors that are accurate enough for commericial aircraft navigation cost $50,000 and up.
The method assumes that the only acceleration acting on the sensor is gravity, which points directly down.
I see. Would a Kalman filter or something similar be a solution for the problem, or the library already uses one? (the scope is a PID controller)
No filter can correct such systematic errors from one sensor, especially a dirt cheap, long obsolete, noisy (and probably counterfeit) sensor like the MPU-6050.
Modern consumer grade IMUs are more accurate, less noisy and perform somewhat better than what you have, especially using the Mahony or Madgwick filters.
The 9DOF versions include a magnetometer, which defines yaw and also helps to correct the problem with acceleration.
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.