Hello, with which MPU6050 libs for ARM core (M0, M3, M4, if possible with Kalman filter) and without the use of the interrupt pin do you have the best experience? I am polling just in loops of 50-100ms delays, so I think I can do without the interrupt pin. And essentially, just stabilized (filtered) yaw, pitch, and roll values have to be determined and used (the sole acc and gyro values are rather uninteresting instead for my purpose).
no good experiences and advices anyone?
You need a magnetometer for stable yaw values. The MPU6050 does not have one.
You need a magnetometer for stable yaw values. The MPU6050 does not have one.
A magnetometer is actually no option because of (randomly!) heavy electromagnetic and ferromagnetic noise.
I also do not nead actual magnetic compass heading, just (relative) yaw angles which can be initialized arbitrarily to 0° or what ever at start, and providing rather stabile yaw by just very small drift.
I know that there are many gyroscopes, even quite simple ones and even for LEGO Mindstorms, no 6D or 9D but just 1D or 2D, and they can read yaw quite reliably.
So how to do it with the MPU6050?
they can read yaw quite reliably.
Then they use some other external reference for yaw. A gyro alone cannot determine the yaw angle.
The accelerometer is useless as an external yaw reference.
jremington: Then they use some other external reference for yaw. A gyro alone cannot determine the yaw angle.
no, the ones I mean don't use external references, and of course they can retrieve relative yaw anglex by their gyros, e.g. for LEGO:
https://shop.lego.com/de-DE/EV3-Gyrosensor-45505 https://www.generationrobots.com/en/401183-gyroscopic-sensor-for-lego-mindstorms-nxt.html http://www.mindsensors.com/44-accelerometer-gyro https://www.dexterindustries.com/manual/imu-sensor/
all can retrieve the yaw angle (e.g., for navigating a robot car) though.
so if they can , why can't a MPU6050?
why can't a MPU6050
Because it is mathematically impossible to use a rate gyro and an accelerometer to determine the absolute yaw angle. There is no yaw origin reference.
This is a very simple concept.
sorry, you’re wrong, all the Lego gyros can calculate yaw angles, just by Gyro values.
Perhaps they are not stabilized against accelerometers, but they still can.
Nonetheless, by evaluating addionally accelerometers one can retrieve at least the horizontal gyro rotation fraction (== yaw) in case the sensor has been tilt, just like for pitch and roll.
The yaw starting angle can be initiaized at program start by an arbitrary value, like Lego does it, too; the follow-up yaw angles are then relative to this one, as already stated.
So how to retrieve the yaw angle by a MPU6050 by which lib, and even when not Kalman-filtered?
(Anyway, the raw or sole gyro + acc values may be Kalman-filterd though)
sorry, you're wrong
Good to know, and I wish you the very best of luck with your project!
jremington: Good to know, and I wish you the very best of luck with your project!
yes, just think about it: Even simple LEGO (and 3rd party) 1D Gyrors can detect rotation around their vertical (z) axis, which is yaw when held horizontally, e.g. for robot cars driving on the ground. I already have built such tribots to move them straight or drive curves of certain degrees since lots of years ago.
Youtube Video: https://www.youtube.com/watch?v=CBzUYdzsOQA
Now the MPU6050 has a 3D Gyro, so it must be able to retrieve the rotation round it's horizontal forward (x), it's horizontal sidewards (y), AND around it's vertical (z) axis.
As long as held horizontally and not tilt, the rotation round the vertical (z) axis again is = yaw, just like for the LEGO 1D gyros: ==> Which lib does retrieve that (z-axis) rotation dimension?
and when tilt forward or sidewards, that can be detected by it's accelerometers to recalculate the yaw part or fraction: ==> which lib also retrieves this recalculated, transformed yaw rotation value? (notice that e.g. for +80° pitch then mainly the gyro x-axis detects yaw)
So as long as the MPU6050 really is featuring 3D gyros and 3D accelerometers, it should be possible to retrieve pitch, roll, and yaw as well, not just pitch and roll like e.g. by Lauszus' Kalman lib - : but which one provides that actually?
Now the MPU6050 has a 3D Gyro, so it must be able to retrieve the rotation round it's horizontal forward (x)
. No, because the gyro detects the [u]rate of rotation[/u], not the angle. You can integrate rotation rates to accumulate a relative change in yaw, from some starting yaw value.
You cannot obtain the absolute yaw angle, which is based on knowing where the North pole is.
About rotation rate (= speed): as always, integrating the rotation speed over time, you'll get the angle - nothing new to me actually. It's always done that way, even for the LEGO 1D gyros. (edit: I see that you edited your post meanwhile)
So if roll and pitch can be calculated out of those gyro values and calculated gyro angles, it should be able to that also for yaw, as already stated.
And you are always confusing (relative) yaw with (absolute) compass heading, although I never asked for absolute compass headings! As stated and shown, even simple LEGO 1D gyros can retrieve those relative yaw angles! But @jremington, with confidence: I asked who actually knows such libs, and not who has no idea about it.
So @all: which libs do that yaw+pitch+roll calculations actually well, according to experience, possibly without using the interrupt pin?
See reply #2
jremington: See reply #2
OMG, that's rediculous - please stay away and let people answer who understand something of the matter!
@all the rest: which libs do that yaw+pitch+roll calculations actually well, according to experience, possibly without using the interrupt pin?
dsyleixa, I agree with you about what you wrote about 3D gyroscopes and calculating yaw angles as well, and I have to disagree with jremington's statements that it shoudn't be possible. Unfortunately I have no personal experiences with the MPU6050 though. Having said that, I want to show you a link about a lib which claims to calculate both yaw, pitch, and roll, but as stated, I can't say anything about trustworthiness or interrupts if yes or no: https://github.com/jarzebski/Arduino-MPU6050/blob/master/MPU6050_gyro_pitch_roll_yaw/MPU6050_gyro_pitch_roll_yaw.ino I hope that might help you further, or some other people can comment on this perhaps!
tito-t: ... Having said that, I want to show you a link about a lib which claims to calculate both yaw, pitch, and roll, but as stated, I can't say anything about trustworthiness or interrupts if yes or no: https://github.com/jarzebski/Arduino-MPU6050/blob/master/MPU6050_gyro_pitch_roll_yaw/MPU6050_gyro_pitch_roll_yaw.ino I hope that might help you further, or some other people can comment on this perhaps!
thanks for your hint, I just tried it out. Unfortunately the example sketch MPU6050_DMP6 does not compile for me, neither for my Due, nor for my M0, and nor for my M4. (No board manager issues, because different other sketches still compile for these boards very will without issues).
So thanks again, but I'm afraid that some other libs are required instead ... :-/
Presumably you've seen https://playground.arduino.cc/Main/MPU-6050
MarkT: Presumably you've seen https://playground.arduino.cc/Main/MPU-6050
please help me - where is that supposed to calculate yaw, pitch and roll? All I can see thers are sole gyro and sole accel values, no sensor fusion, no Kalman filtering, and no 3-dim coordinate system transformations from local sensor to global aeronautic orientation. Notice that e.g. for pitch=0 and roll=0° then the gyro z axis is significant for yaw, whilst for pitch=+80° then mainly the x axis becomes more significant to yaw. Same for e.g. roll=80°, then the y axis becomes most significant to yaw. So the problem about 3D coordinate system transformations is not trivial, and additionally the raw sensor values surely will have to be filtered (some are using extended Kalman filters to accel and gyros against gaussian and non-gaussian noise and high pass filters to eliminate drift).
This might help https://forum.arduino.cc/index.php?topic=501334.0.
It is possible to determine angle of offset by using acceleration, I have my MPU 6050 sitting on a X/Y table that is kept level by taking acceleration converted angles and turning them into torque values for the X/Y servos.
It is possible to measure the X/Y/Z, MPU6050 Gyro and Accelerometers, drift rate and offsets (the Z axis must be physically aligned to the North Pole during calibration), which I have done on a RPi in Python, and apply those drift rates and offsets to the accelerometers, which, for the Z axis accelerometer gets rid of the earths rotation value. Using the Z axis accelerometer positioned so that the accelerometer is not detecting any acceleration (N-Pole aligned) and the X/Y are allowed, by being on a stable platform, to be gravity aligned, a local coordinate system is realized; +X+Y, -X+Y, -X,-Y, +X-Y, and Yaw can be determined from the acceleration vectors. The Z axis can be torqued so that any felt acceleration is zeroed out, keeping the Z axis pointed to the North Pole. The position on the Earth Geodesic can determined by Trigonometry, using the meridian coordinate system and then converted to Lat and Lon. With Lat and Lon increments you can, also, determine Yaw, negating the need for a Z Axis measurement.
I have posted the Python code I use to develop XY angles from acceleration, here in these forums, in the past. I figured someone has ported the code to CPP by now; shrug
I know it is not the instant answer solution to your issue but it is what I got. I, should, in a few months look to make my X/Y platform into a X/Y/Z platform, with Z stabilized to the North Pole but I am working on something else at the moment.
thank you for your post, as I understand it's theoretically possibe to achieve the functionality I wish to have. At some point it sounds as if you use different x,y,z, coordinate axis designations than I did, but in principle that makes no difference of course. longitudinal =x transverse = y vertical = z
As stated, again: I do not need absolute magnetic compass headings, just relative ones to an arbitrary start value.
So far I am using this lib for pitch and roll: https://github.com/TKJElectronics/KalmanFilter/tree/master/examples
Unfortunately it does not show yaw yet, and so a different lib is desired for download and install.