3D Motion Problem in a Specified Movement

[dogus]

Hello,

(I also create an issue over Thingy SDK GitHub page - #29)

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.

[Mathew]

Hi Dogus,

I don't purport this to be a solution to the problem as I have not yet had a chance to test either of these myself, however if you are willing to give anything a try, I suggest giving each of the following a go:

Firstly change the following in 'drv_motion.c':

static platform_data_t s_compass_pdata =
{
    .orientation = { -1,  0,  0,
                      0,  1,  0,
                      0,  0, -1}
};

to this:

static platform_data_t s_compass_pdata =
{
    .orientation = { 0, 1, 0,
                     1, 0, 0,
                     0, 0,-1}

and see if the behavior persists.

Secondly, comment out the compass calibration function in 'drv_motion' as shown below:

/* Compass calibration algorithms. */
//err_code = inv_enable_vector_compass_cal();
//RETURN_IF_ERROR(err_code);

and see if the behavior persists.

Both of these attempt to prevent the quaternion from making a sudden 'step change' which may be directly related to the compass.

[dogus]

Hello,

Thank you for your interest and reply. 

I already 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. But I got same result.

Then I considered that my Thingy has a different problem. I mean it might be too much affected by environmental effect (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 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 out 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?

Also, with your reply, I tried your first suggestion and the result is, unfortunately, the same. 

Thanks.

Dogus

[Mathew]

Hi Dogus,

Decreasing the 'compass_interval_ms' to 10ms (100Hz is the maximum rate the compass can be read) and increasing the 'motion_freq_hz' to at least 100Hz results in much improved performance.

You can see I've hard-coded these values in the function below (found in m_motion.c) to prevent the configuration stored in flash from being used:

static uint32_t m_motion_configuration_apply(ble_tms_config_t * p_config)
{
    uint32_t err_code;
    drv_motion_cfg_t motion_cfg;

    NULL_PARAM_CHECK(p_config);

    motion_cfg.pedo_interval_ms    = p_config->pedo_interval_ms;
    motion_cfg.temp_interval_ms    = p_config->temp_interval_ms;
    motion_cfg.compass_interval_ms = 10;//p_config->compass_interval_ms;
    motion_cfg.motion_freq_hz      = 100;//p_config->motion_freq_hz;
    motion_cfg.wake_on_motion      = p_config->wake_on_motion;

    err_code = drv_motion_config(&motion_cfg);
    APP_ERROR_CHECK(err_code);

    return NRF_SUCCESS;
}

I recommend re-enabling the inv_enable_vector_compass_cal function also. Now that the compass is being read at a faster rate, the automatic calibration of the compass occurs much more promptly once the device has started moving in a figure-8 pattern.

[dogus]

Hello,

Thank you for your answer.

I tried what you said and the results are really better in comparison with previous results. It is really good. But unfortunately, the same problem continuous. Jumping angle is decreased but still, it jumps and I can say that this problem still come up in my almost every try.

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.

[dogus]

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.

[Bjørn Kvaale]

Hi,

It seems you received help on the github forum, so I will close the case if that is ok with you.

[dogus]

Hi,

Yes, that is OK. Thank you.