3D Motion Problem in a Specified Movement

[dogusyuksel]

Hello,

It seems to me that there is an issue about the usage of MPU-9250.

I motioned Thingy and I observed its movement on the app. In all movement combination, SDK finds Thingy' s location perfectly (I can see it on the app) except one movement.

Now, I am trying to explain this problematic movement.

I put the Thingy (on its bigger surface) on a table in the way that for example "Nordic Semiconductor" text is seen right to me when I look to the Thingy on the table from above. I put the thingy like I said (on a flat surface) and without removing Thingy from the table surface, I turned it to clockwise and counterclockwise. This movement occurs very problematic results and I can see it on the app, its location is not stable and it jumps. Then, I put the Thingy on its other (smaller) surface on the table and I follow the same procedure and again the result is problematic just when I exactly do the SAME movement (clockwise and counterclockwise).

This situation really bad for our future project and I cannot overcome it by myself. I don't know actually MPU driver causes this problem, or your SDK or is it a real problem also.

Could you please help me about that.

Thanks.

Here are my steps while testing the issue:

• We get Thingy52 and we use your code in this repository under the path: project\pca20020_s132\arm5_no_packs\ble_app_thingy_s132_pca20020.uvprojx.
• I use Keil and I can build the project with no error or warning
• I use NRFGostudio to program the device. While doing that, I use the hex file that my Keil generated to program application part and I use the soft device s132 hex file under the path: sdk_components\softdevice\s132\hex
• Then I download the app Thingy app to Android and iPhone (results same)
• Then I motion the thingy and observe its motions on the app. My observations are just like mentioned above.

[koffes]

Hi dogusyuksel.

Thank you for contacting us. The sensor fusion (that is the algorithms that fuse the accelerometers, magnetometers and gyros to a device attitude) are part of a precompiled library related to the MPU-9250. We do no sensor fusion in the code that we have contributed on top. The sensor fusion is also difficult to perform due to the HW design of the Thingy:52 itself. The battery and other components are situated close to the MPU, as is the speaker which in practice is a magnet. These cause hard and soft iron distortions which influence the magnetometer. These have been calibrated out as best possible in firmware. There are also currents running close to the MPU which will generate weak magnetic fields. If possible, use the raw accelerometers and gyro values. These should be stable, but will not give you a heading relative to magnetic North.

[dogusyuksel]

Hello,

Thank you for your kind reply.

Your explanations are very clear and reasonable I think. By the way, we designed another card (by using your open-source documents, HW and SW projects) and we observed the same problem. In our design, there is no speaker but there is a battery holder close to MPU so it could also affect the MPU. I mean, we will never know the source of the problem then (by the way I also create a ticket at dev-zone with the name "3D Motion Problem in a Specified Movement" and I share some additional video, photos, and explanations).

Should I contact MPU manufacturer, maybe they have some idea about this problem (if this is a problem)?

Or maybe I keep this method to find the position and as an extra, I use magnetometer raw data to re-stable the direction. Is that possible and sensible? What are your suggestions?

Thank you.

[koffes]

Thank you for the detailed feeback in the Devzone post: https://devzone.nordicsemi.com/f/nordic-q-a/36351/3d-motion-problem-in-a-specified-movement I have watched the video. In the beginning where Thingy is rotated around the X (roll) and Y (pitch)-axis (as indicated on the PCB), I expect the results to be good since the sensor fusion gets good absolute information from the accelerometers (as observed). However, when rotated around the Z (yaw) axis, there is no difference in the data coming from the accelerometers. (X and Y are constant at 0 and Z always gives 1 g). This means that the sensor fusion may only in practice use the gyros and magnetometers to give you the heading. In the design you have made, as you pointed out, I expect the battery holder and battery to also affect the magnetometers. I'm sorry that I cant assist you in detail, but here are some possible solutions if you want more accurate attitude data:

• On your own HW, check the documentation in the MPU SW library, and try to calibrate the magentometer.
• Disable the magnetometer in FW and use only the accelerometers and gyros for sensor fusion. This will not give absolute heading relative to the Earth's magnetic field.
• If you are C-savvy, you could use the low level MPU drivers, get the raw data from all sensors and run a different sensor fusion algorithm on the nRF52.

[dogusyuksel]

Hello,

Thank you for your kind and detailed explanations. I will try your solution recommendations and inform you about my results.

Best regards, Dogus.

[dogusyuksel]

Hello,

I want to share my some tests and results.

I tried the code with; changing "inv_set_compass_bias" function parameter and open/close with the different combination of "inv_enable_vector_compass_cal" and "inv_enable_magnetic_disturbance" functions in the drv_motion.c. But I got the same problematic result. Also, in the DevZone answers, someone suggested changing "s_compass_pdata" array. I tried it also and the result is the same. (I think these tries are related with your first suggestion).

I also tried to get raw data and fuse them with a different algorithm in PC side but the raw data that Thingy sends to PC, is also problematic. (I think these tries are related with your third suggestion)

By the way, we cannot do your second suggestion because the heading is so important for our project.

Then I considered that my Thingy has a different problem. I mean it might be affected too much by environmental effects (iron effect maybe I don't know) and I have only one Thingy but our custom designed card. So I re-overview our code in the meantime and its code is same with Thingy original code in the motion driver side. The result is also problematic.

As I mentioned before, our card is very small and its one side is battery holer completely. I mean, it could be also affected by environmental effects. As a result, we ordered an MPU9250 module (external) to test with the same driver (code). If it works, then our designed cards (and Thingy I think) are affected too much and we will try to change our HW design. Also, I ordered another extra compass module. I will test it under the same conditions, if the additional compass works fine, we will add this additional compass to our design and we will use its raw data.

Is that logical solution by the way? What do you think?

Thanks.

Dogus

[koffes]

I find it strange that the PC-side fusion does not provide decent results. What software are you using? Some of the PC-fusion software have comprehensive calibration routines for magnetometers. (Some present you with a graphical 3D sphere on screen, and you have to rotate the MPU to cover the entire surface. This gives the algorithm data to calibrate the magnetometer for all attitudes). Can you check that the PC fusion algorithm gets new data at the right and/or high enough rate?

I think you have a good plan there. Make sure to follow the PCB design guidelines in the MPU9250 manual. Note that on the webpages of Invensense, the MPU9250 is no longer recommended for new designs.

[dogusyuksel]

Hello,

Thank you for your answer.

Actually, we did not focus on the fusion algorithm on the PC side because when we observe the raw data on PC side, we saw that magnetometer values are still jumping (we tested it by just simply converting magnetometer raw values to heading).

As a result, we focused on iron effect. Now, I am trying this process with different compass and external MPU9250 module (I try to separate the MPU from the board to test if it is affected by iron effect or not). After my tests, I will share my results.

Thanks.

[dogusyuksel]

Hello,

I finished my tests and here are my results;

I used the AK8975 3-axis electronic compass that mostly used with MPU6050 IC. I used it and only it alone and I tried to see stable magnetic north (in degree). While doing this, I was sure that PCB won't affect the compass because In this way, I tested it on different environments (I positioned the compass to a specific direction on my working desk and my friend's working desk) and the results are NOT SAME. Also, I downloaded a compass app to my phone and I tried the process with it. It was also affected by environmental factors.

So, what should I do? How can I overcome it? Please help me.

Thanks.

[koffes]

Hi @dogusyuksel. That the other options you have tested also struggle to obtain consistent results highlights the challenging nature of this issue. This ticket is now outside the scope of Thingy:52 so I will take the liberty of closing this issue. If you desire an accurate absolute magnetic heading I would suggest looking at more advanced options. Some vendors of IMUs sell encased units with e.g. USB or serial interface where care has been taken not to have any ferrous metals nearby. Some come with a software suite that allows for calibration of iron effects and storing the results to the IMU. Another option would be to use multiple magnetometers and do some form of averaging or voting between them. I would advise against looking at the raw values. A complete unit with a built-in attitude estimator will give you better heading results.

[dogusyuksel]

Hello,

Thank you for your feedback and help.