world-based yaw?

[mark-hahn]

I have a tilted 6050 chip in my bot but I need the yaw value referenced around the gravity vector. In other words I need a world-based yaw. I see world-based acceleration but nothing world-based for ypr. Am I missing something simple? I assume it would be some math on the quaternion.

Actually I would be happy with a fixed rotation on just one axis since my sensor is fixed in my bot and is only rotated on one axis. I noticed the orientation stuff for the dmp but it seems to be fixed to 90 degree rotations, in other words flipping the axes around. I need a 60 degree rotation.

This is a bit of a duplicate of #637 but I've figured out this simpler shorter way of asking.

[jrowberg]

World-based yaw requires a magnetometer, which allows full 9-DOF sensor fusion. Gravity provides world reference for the accelerometer anywhere on the planet, and the gyro is entirely relative anyway, but the only way to establish a common heading reference is with a compass. Without that, you have to pick an arbitrary heading value as your virtual north/zero starting point.

[mark-hahn]

Let me try to ask the question a simpler way. Imagine a box on the floor with a 6050 inside at a 60 degree tilt. I want to be able to turn the box 90 degrees (yaw) and have a computer be able to tell it has turned 90 degrees. How do I do this?

[ZHomeSlice]

Quaternion math should handle that.
The yaw is calculated using quaternions while the pitch and roll are calculated using accelerometer. With the default examples.
Gimbal lock usually happens when you get close to 90° with roll and/or pitch.
This is the only way I was able to get the yard to fail with wild rotations at odd angles

Z

[mark-hahn]

the pitch and roll are calculated using accelerometer

Seems odd. Do you mean gyroscope? I'll check out the examples/

[mark-hahn]

Ah, I think I finally got it (although I thought I had it several times before). I just need to get the yaw relative to the chip and rotate that vector to give me the yaw relative to the world. Helper_3dmath has the rotate(Quaternion *q) function. So I would use it something like this ...

  mpu.dmpGetQuaternion(&q, fifoBuffer);
  q.rotate(rotation_q);
  mpu.dmpGetGravity(&gravity, &q);  // should this be before rotate?  I can just test to see what works  
  mpu.dmpGetYawPitchRoll(ypr, &q, &gravity);  // I now have the raw relative to the world

If the above is correct, then all I need to do is figure out the rotation_q quaternion to use. Luckily I know the exact rotation of my chip around the X axis so I can calulate a fixed rotation_q. After checking out a half-dozen google searches I think I hit the jackpot. This stackoverflow question is "rotating a quaternion on 1 axis?" and the answer has code with a function Quaternion Quaternion::create_from_axis_angle which is exactly what I need.

I'll test this out. If it works then this post should help others with tilted chips. I have googled on and off for days and the tilted chip question has been asked often with no answers.

[ZHomeSlice]

When you succeed, please share your code so we can create additional helper functions math functions.
Glad I can help.
Z

[mark-hahn]

I'm baffled but happy. Weirdness follows ...

1. Baffled: The rotation operation didn't work. The result of the rotation was unchanged. It is as if getProduct and getConjuate did nothing. But I can see the code for those should clearly do something. Here is my code ...

    Quaternion rotq = Quaternion(0.7660f, -0.6428f, -0.0000f, -0.0000f);  // rotq: rotation quaternion for -80 on X axis
    mpu.dmpGetQuaternion(&q, fifoBuffer);                    // q: quaternion from dmp
    Quaternion rq = rotq.getProduct(q);                      // standard rotation math: result = rotq q rotq'
    rq = rq.getProduct(rotq.getConjugate());                 //   rotq q rotq' did nothing!  rq (result) == q

2. Happy: I got the correct results by just re-arranging the results with no rotation operation. After the ypr calculation the yaw was correct and the correct roll value was in the pitch variable, except for reversed signs. I posted an issue about this weird interchange of pitch/roll and signs here: The pitch and roll do not match the axes in the 6050 chip docs #643

Oh well. All is good that ends well. I'll use what works and just continue to be baffled.

[mark-hahn]

For lurkers who also have tilted chips: There is no need to do anything special if you have a tilted chip. The sample code works for any chip orientation.

I found out why my results were so screwed up in the first place that caused me to think a tilted chip was a problem. If the chip is not tilted then numbers stabilize in 0.5 seconds. If the chip is tilted the stabilization time is much longer. In my case it takes 7 seconds (!) to get usable numbers. I assume the more the chip is tilted the longer it takes and my chip is tilted 80 degrees.

I just now found this out after spending many days doing experiments that sometimes worked and sometimes gave horrible results. The amount of time I waited to start the test was the difference and I just figured that out by pure luck.

But a tilted chip is a problem after all for my product. The user will turn my bot on and expect it to work right away. Seven seconds is an eternity. I guess I'll have to put up a box on the phone screen saying "warming up" until the numbers stabilize.

[ZHomeSlice]

Note that the functions:

    mpu.CalibrateAccel(6);
    mpu.CalibrateGyro(6);

are used to calibrate the chip with it as flat as possible. This sets the offsets

Use
mpu.PrintActiveOffsets();
to get the calibrated offsets

What calibration does is find the point where there is no acceleration in any of the 6 axes with gravity below the Z-axis

Now use the resulting offsets to replace the following numbers

  mpu.setXGyroOffset(51);
  mpu.setYGyroOffset(8);
  mpu.setZGyroOffset(21);
  mpu.setXAccelOffset(1150);
  mpu.setYAccelOffset(-50);
  mpu.setZAccelOffset(1060);

your chip will be calibrated except for minor deviations caused by temperature changes.

Z

[mark-hahn]

Thanks. That is what I have been doing. I did suspect calibration problems but after many trials I'm pretty sure my calibration was good all along. I used a bubble level clamped to my PCB with the chip. I found that the tiniest deviation of the bubble changed the results and the bubble in the middle gave the best results.