3D Simulation Problems with MPU9250

[Onur]

Hello,

I would like to touch on some problem we encountered when using the MPU9250 sensor.

Our goal in the project is to simulate the movements of the MPU9250 sensor in 3D. In other words, if the sensor is moving, we want to simulate the same movements. We used Thingy52 for this purpose before. Since we have encountered a different problem, we have tried to adapt open source Thingy52 codes and algorithms to our project which is also using Nordic nRF52. (for more information about encountered problem: https://devzone.nordicsemi.com/f/nordic-q-a/36351/3d-motion-problem-in-a-specified-movement)

Firstly, we can only achieve this success if the sensor and screen are initially facing a certain direction. In other conditions, we observe that the simulation and the sensor moves in different axes.

 

Detailed explanation:

• In the first case, our demo card and we are looking north and the screen is facing us. Result, the simulation runs smoothly.
• In the second case, our trial card and we are looking at one of the intermediate angles other than the four main directions and the screen is facing us. Result, the simulation turns at the right angles, but on the wrong axis.

 

When we were working with Thingy52, we had not encountered this problem. With Thingy52, the simulation always moved correctly, regardless of starting position.

Since we could not obtain any quaternion generation algorithm in Thingy52 codes, we did this calculation with the Mahony quaternion calculation algorithm. I wonder that what kind of quaternion calculation algorithm does Thingy52 use for a simulation regardless of starting position?

 

Secondly, Thingy52 was not affected by the soft iron effect in our tests. However, when our device is exposed there are noticeable changes on simulation. For example, when we bring closer a phone or tablet to the MCU, we see that the simulation on the screen rotates even when the sensor is not moving. How does Nordic solve this problem?

Finally, when we make a 360 degree rotation on one axis, we observe that it rotates on more than one line, rather than rotating on a fixed line. Although the simulation shows the correct point again when it completes each full lap, it is also experiencing a rotational movement outside of the axis he normally turns into and is becoming obsolete again during the lap.

We want to continue to use Nordic MCU, so we need to solve this problem.

 

Could you please help me about that.

 

Thanks,

Onur

 

[awneil]

I can't see that this has anything to do with the Nordic MCU at all ?

There is something wrong in your code - you need to debug your code to find it, and fix it!

https://www.avrfreaks.net/comment/2418156#comment-2418156

It sounds like you have a calibration problem - ie, not properly calibrating your starting position.

[Onur]

Hello,

Thank you for your reply.

Of course I understand.

The reason we chose  Nordic MCU was the presence of a built-in bluetooth module. Therefore, it is a very advantageous MCU for us.

We were able to solve the initial position and the axis shift problem by calibration, so we have a system that works very well. However, we continue to have problems with soft iron effect. Electronic devices (mobile phones, tablets, etc.) that approach the device, and even the iron that comes near test board, affect the operating performance. It works very sensitive about this topic. On the other hand, we did not encounter this problem when working with Thingy52. We use the same DoF sensor as Thingy52. Although Thingy52 has a speaker(so it has a magnet too), it does not experience this problem. We have no idea how to solve this problem with calibration. 

How did Thingy52 overcome this problem?

Is the different hardware design or did you work with InvenSense on this problem?

We couldn't get through this problem. Could you please help?

Thanks,

[awneil]

Again, the "soft iron effect" has nothing at all to do with the microcontroller you use - it is entirely down to the sensor and how you have deployed it in your design.

You will need to contact the sensor manufacturer for support in the application of their sensor.

Onur said:

Thingy52 has a speaker(so it has a magnet too)

Are you sure?

Perhaps its a piezoelectric or MEMS speaker ...

Onur said:

Is the different hardware design

The Thingy design is public - have you looked?

[Onur]

Yes, your design is open source and We have already made a design by taking sample from yours. Photos of our design are available at the link below.

Link: https://www.dropbox.com/sh/prdz4jtk80pbm6f/AAANt1KdzRZN3Eqf1RKKk_Z5a?dl=0&preview=our_design_back.JPG

https://www.dropbox.com/sh/prdz4jtk80pbm6f/AAANt1KdzRZN3Eqf1RKKk_Z5a?dl=0&preview=our_design_front.JPG

However, at the end of the detailed tests, we saw problems in 3D motion in this product. After that we've noticed the same problems at Thingy52. Therefore,  we created the issue in the link below, but we could not conclude. (https://devzone.nordicsemi.com/f/nordic-q-a/36351/3d-motion-problem-in-a-specified-movement). So we decided to take sensor fusion algorithms from a open source algorithm, not from the Invensense’s closed libraries. (Sample open source project link: https://github.com/kriswiner/MPU9250) We have examined the especially calibration parts of the code we have shared above in detail and we have added multiple calibration steps to magnetometer, gyroscopeand accelometer. We must say that  we have not seen any problems in our calibration codes. Because, after calibrating our product, it works exactly as we want unless there is an external effect. However,  when an external effect added, our sensor is naturally affected and the 3D object that we see on the screen is slipping.

The last thing we want to ask you is: this problem was not encountered when we use Thingy52. Can you give us an idea to guide us to solve this problem? Or is it necessary to create an issue with Invensense? We want to take your idea.

Test videos with Thingy52 and our new design at the point affecting the magnetometer in the wall:

www.dropbox.com/.../AACvTHUUfCIZ8xxdyqOunDbCa

[awneil]

Onur said:

your design

It's not my design.

https://devzone.nordicsemi.com/backstage/f/welcome-to-the-devzone/30115/how-to-know-the-respondent-is-nordic-employee-or-not

Onur said:

we've noticed the same problems at Thingy52

Onur said:

this problem was not encountered when we use Thingy52

I'm confused - was it seen on the Thingy, or wasn't it?

[Onur]

These are different problems. The first one is the problem that we encountered at Thingy52 and our own design in the first two photographs. We created our designs in these photographs by taking Thingy52 as a model.

https://www.dropbox.com/sh/prdz4jtk80pbm6f/AAANt1KdzRZN3Eqf1RKKk_Z5a?dl=0&preview=our_design_back.JPG

https://www.dropbox.com/sh/prdz4jtk80pbm6f/AAANt1KdzRZN3Eqf1RKKk_Z5a?dl=0&preview=our_design_front.JPG

We  created an issue for the problem that we encountered in our designs in photos and Thingy52, but we could not reach the solution.

(https://devzone.nordicsemi.com/f/nordic-q-a/36351/3d-motion-problem-in-a-specified-movement)

For this reason, we have re-organized our project by taking other open source software instead of Thingy52 open source software. ( open source software that  we used in reorganized project: https://github.com/kriswiner/MPU9250)

In reorganized project, we encountered a different problem than before. This is the second problem and we have never seen the second problem in Thingy52 tests. Second problem is about high sensor sensitivity against external effect like phones, tablet, even irons.

You can see this effect in videos: 

https://www.dropbox.com/home/Nordic%20Issue

The reason we mentioned two problems was to specify all the stages we had progressed from beginning to end.The problem we are looking for solution at the moment is only the second one.

Thanks,

Onur

[Einar Thorsrud]

Hi Onur,

Regarding how it is used in the Thingy:52, I am not aware that there have been any specific HW measures for handling external effects. Both the hardware files and firmware source code for the Thingy:52 is available so that you can compare with your design. However, I suggest you contact Invensense regarding this, as MPU9250 is their product. They should have far more knowledge about it than us.

Einar