which MPU6050 libs for ARM core (with Kalman filter?) and without Intr usage ?

Using Arduino Sensors
#6

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?

#7

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.

#8

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)

#9

sorry, you're wrong

Good to know, and I wish you the very best of luck with your project!

#10

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. |500x285

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.

|500x319

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?

#11

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.

#12

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?

#13

See reply #2

#14

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?

#15

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!

#16

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 ... :-/

#17

Presumably you've seen https://playground.arduino.cc/Main/MPU-6050

#18

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).

#19

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.

Good luck.

#20

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. |500x319 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.

#21

that's really weird that no one knows a working yaw+pitch+roll lib for the MPU6050 and an ARM core MCU... :-/

#22

dsyleixa: |500x319

As stated, again: I do not need absolute magnetic compass headings, just relative ones to an arbitrary start value.

Unfortunately it does not show yaw yet, and so a different lib is desired for download and install.

If you are using a MPU5060 you have the ability to calculate your relative heading. I am not going to tell you how to do it. Your image you post is the clue.

Look at your image. Your image represents a X, Y, Z 3D coordinate system. Think of a XY graph plot on a piece of paper. Actualy, just do that now, draw a vert and horz line on a sheet of paper with the lines intersecting at a 90 degree angle. Where the lines intersect that is the relative current position. If you plot a dot on the +X+Y of 1 unit up and one unit over. Now plot another point 2 units up and 2 units over, and 3 units up and 3 units over, and 4 units up and 4 units over... You should end up with a line that from +X,+Y is at 45 degrees, which is your relative heading.

The mpu6050 gives you +/- Accelerations. Those accelerations are your direction of travel vectors that can be used to determine relative heading. It's just simple math, You can do it yourself.

#23

sorry, I can't, I need a lib to retrive yaw, pitch, and roll, incl. filtering, I don't understand anything of the raw values and the Kalman and quaternions and Euler angles and sensor fusion and whatever. And BTW, for horizontal positions or 90° rotated, the accelerations are not helpful for yaw at all, just specific and vaying gyro values, and only for in-between tilt values the vectors have to be somehow composed for sensor fusion - but how or by which transformations is absolutely beyond me. There are libs which provide pitch and roll, but no yaw unfortunately, and some claim to provide yaw, too, but don't compile at all for my ARM boards. I really cannot understand why a really working lib doesn't already exist. :-/

#24

I really cannot understand why a really working lib doesn't already exist

See reply #2: You need a magnetometer for stable yaw values. The MPU6050 does not have one.

The MPU6050 library developers understand this simple point.

#25

jremington: See reply #2: You need a magnetometer for stable yaw values. The MPU6050 does not have one.

The MPU6050 library developers understand this simple point.

first I just need simply yaw, and that must be possible. I told you dozens of times why a magnetometer wouldn't work for my purposes, so don't keep posting over and over the same nonsense!