3D Motion Problem in a Specified Movement

RE: 3D Motion Problem in a Specified Movement

dogus — Sun, 16 Sep 2018 15:48:24 GMT

Hi,

Yes, that is OK. Thank you.

RE: 3D Motion Problem in a Specified Movement

Bjørn Kvaale — Wed, 12 Sep 2018 12:54:24 GMT

Hi,

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

RE: 3D Motion Problem in a Specified Movement

dogus — Wed, 05 Sep 2018 10:44:24 GMT

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.

RE: 3D Motion Problem in a Specified Movement

dogus — Thu, 09 Aug 2018 12:41:45 GMT

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.

RE: 3D Motion Problem in a Specified Movement

Mathew — Wed, 01 Aug 2018 04:04:19 GMT

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.

RE: 3D Motion Problem in a Specified Movement

dogus — Mon, 30 Jul 2018 07:18:26 GMT

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

RE: 3D Motion Problem in a Specified Movement

Mathew — Fri, 27 Jul 2018 21:41:47 GMT

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.

RE: 3D Motion Problem in a Specified Movement

dogus — Tue, 17 Jul 2018 07:06:15 GMT

Hello,

If you say so then we can close the case. I will share my test result on github.

Thanks.

RE: 3D Motion Problem in a Specified Movement

Hung Bui — Mon, 16 Jul 2018 14:46:11 GMT

Hi Dogus,

Seems that you got some help from our R&D directly on github. I guess we can close the case here.

RE: 3D Motion Problem in a Specified Movement

dogus — Mon, 16 Jul 2018 06:24:15 GMT

Hello,

OK, thank you. We are waiting for your reply.

RE: 3D Motion Problem in a Specified Movement

Hung Bui — Fri, 13 Jul 2018 15:22:39 GMT

Hi,

Thanks for the video report. I have forwarded the report to our R&D. Will get back to you when we hear from them.

RE: 3D Motion Problem in a Specified Movement

dogus — Fri, 13 Jul 2018 09:03:25 GMT

Hello,

First of all, thank you for your reply.

I did not test this problem with another Thingy but we test it with another device that we produced by using your open source documents (our designed card photos in the link) and with our card, the result is same, problematic.

In the link, I added the Thingy PCB photo that product version information can be seen clearly.

I also add a video to the link. In this video, we moved the Thingy and there is no problem until second-20. With the movement at that second, you can see what I mean. Then, we put the Thingy on the table on its smaller surface and did the same movement again and it is still problematic. If you just look at the difference between frames at second-33 and second-46 (I also add these frames to the link) you can clearly see our problem.

The link: https://www.dropbox.com/sh/prdz4jtk80pbm6f/AAANt1KdzRZN3Eqf1RKKk_Z5a?dl=0

RE: 3D Motion Problem in a Specified Movement

Hung Bui — Thu, 12 Jul 2018 14:30:26 GMT

Hi,

I don't really see a problem when trying to do the same here. Have you tested on other thingy ?

Could you read the thingy version on the sticker on the PCB ?

Have you updated the firmware (should be automatically from the app) ?

Could you capture a screenshot video when you do that to show the problem ?