Extracting location data from acceleration values acquired from LSM6DSL

[N ORhan]

Hi everyone.,

We are working on a medical device that will work for rehabilitation of patients who has upper extremity diseases. We have to know the exact location of the device in real time and send it to PC via bluetooth. We will not have a chance to do 6 point calibration because device will move only in x-y plane (on a flat table). So far, first i calibrate the accelerometer as taking 4000 samples, getting median of these samples and subtracting these medians for all measured data samples. I can get around +-1 g for all axes when i do orientation of STEVAL-MKI178V2 accordingly. First of my questions is that, would you suggest any other calibration method for this application which requires precision as much as can be done?

(At that point, I want to mention here non-calibrated, steady accelerometer data values are (-0,441 g), (-0,380 g), (0,582 g) for x,y and z axis respectively. Does these steady state offset values make sense? I could not understand why this values are much far from the expected values such that 0, 0 and 1 g for x,y and z axis respectively.)

My second problem is that when i push STEVAL-MKI178V2 for example 4 cm, i can get position results around 4 cm well but when i pull the device back to the starting point i get lower than 4 cm. If my computations and numerical integrals were wrong, i wouldn't get right result for pushing, right? Why can i not get the right displacement result for pulling device back to the stating point?

I'm working on to improve my algorithms but looking forward to get help and suggestions from experts around here as well.

Thank you.

[After Forever]

So you want to solve the positioning problem just using the LSM6DSL? An Inertial navigation system?

That's a hard problem that requires very precise (I would say military grade) gyro and accelerometer sensors and well-designed digital signal processing (DSP) algorithms. [ Click on Show More to see the second part of the post ]

Can you describe the problem you are trying to solve with a little bit more details?

There might be other suitable solutions for an indoor positioning system, like using the WiFi signals. See, for example, these projects:

https://github.com/schollz/find

https://github.com/dmsl/anyplace/

[N ORhan]

Thank you for your answer @After Forever​ . My device resembles an optical mouse which we can track the position relative to initial position of the device. I can not get an optical mouse sensor so far, so i decided to implement positioning by using accelerometer + gyro in which LSM6DSL includes. I have not fused gyro data with accelerometer yet. I have to see on the computer screen, the device position which will be driven by hand in an area which spans about 1 m2(square-meters). I will have a map on the screen which simulates the area of interest. Up to now ,i can get very close position data at relatively high speeds but when its about very low speeds, nearly all my position data are wrong and absurd.

[After Forever]

Aha, so it's not an indoor positioning system, forget about the links then (:

So, you are moving your device on a flat, table-like computer screen. And you want to know the precise location of the device on the screen. Hmm, maybe I'm not seeing something obvious, but why not to use a screen with a touch sensor, and your device as a stylus pen. Then the computer attached to the screen can precisely know the device's position using its touch sensors.

There two types of touch sensors, capacitive and resistive. The latter is more accurate and doesn't require a special capacitive stylus.

[N ORhan]

Oh sorry, i think i explained in a wrong way :) Device will not flow on the screen, it will be driven on a flat surface on the table and its position data will be sent to the PC via Bluetooth.I have to process the data on the MCU and then send to the application that runs on the PC (like a piece of map of the area device is floating on).

[After Forever]

No worries.

I would try to find some other solution than a magnetometer. Every metallic object (the operator's wrist watch, or finger-ring, a smartphone on the table, etc.) will be affecting its accuracy. [ Click on Show More to load the rest ]

You mentioned "mouse". This may be another crazy idea: If the "table" is under your control, you could put a small camera under your device, and a light source, then print specially encoded little marks on a banner and put it on the table (under a glass, for example), then use the camera under the moving device to decode the marks on which it currently stands to find out its position.

The marks should be some type of 2D barcode. Data Matrix, for example. You should be able to encode 16 bits of information in a 10x10 dots of Data Matrix. Or use color encoded barcode for more bits on sq. mm.

https://en.wikipedia.org/wiki/2D_barcode#Matrix_(2D)_barcodes

https://en.wikipedia.org/wiki/Data_Matrix

[N ORhan]

Thank you for your suggestions but this would be a huge cost for my project to be implemented. We don't have a budget to use relatively expensive hardware such as camera. Position data should be acquired for as low price as possible.

[Eleon BORLINI]

​Hi, I see that the purpose of the project is to implement a dead-reckoning along x-y plane with the only LSM6DSL axl. I agree with you that the two fundamental focuses are a good calibration and a good procedure. If you cannot perform 6 point calibration, you should at least try to minimize the z component of the g vector along x and y axis by measuring it e.g. in 0° orientation (in plane), then in 180° orientation and finally subtracting the obtained offset to your output value (a 4 point calibration instead of 6 point one). You could in same way apply an HP filter to cancel the low frequencies component (e.g. offset), obtaining same result as a 4 point calibration. It's also important for you to know the maximum frequency of the movements you'd like to detect or measure, to select the opportune ODR. Btw, averaging the measures as you are doing will help you to minimize the calibration error for sure.

It's not so simple to implement your integration algorithm using the axl alone. It should be much more convenient to use also the gyro. You can refer to the below linked Design Tip, p.4

Another technique which can be of help in controlling the integration error is known as Zero-Velocity-Update (ZVU): when the modulus of the acceleration is 1g and the output of the gyroscope is near 0, then it is assumed that the velocity is zero, and the corresponding integrator is reset to 0. If all the conditions are met in the above code, this instruction is executed: velhp(i,:)=[0,0,0].

(Btw, the output of the axl is strange, 0.7g resultant intensity... did you select the right mg/LSB conversion in correspondence with your FS?)

https://www.st.com/content/ccc/resource/technical/document/design_tip/group0/11/71/fd/92/1d/fe/47/d6/DM00513638/files/DM00513638.pdf/jcr:content/translations/en.DM00513638.pdf

[N ORhan]

Thank you so much @Eleon BORLINI​ for your helpful answer. The point that i couldn't understand is that after eliminating the median of 4000 samples, i have around +1g for all axes when i rotate evaluation board accordingly. But initial raw data are (-7468, -8312, 8275) for x,y and z components for +-2g full scale. I have three STEVAL-MKI178V2 board and getting same results for all. What can be the problem?

Secondly, i get good position results at high speeds but when it is slower and at constant speeds, i get wrong and absurd position results. What is your suggested algorithms for slower and constant speeds? I think it requires advanced DSP algorithms, doesn't it?

[Eleon BORLINI]

You're welcome N ORhan. Just some question from my side to better understand... you say that if you rotate your devices and you subtract the median to your measures, data are ok (you get 1g): shouldn't you obtain something around 0g after the subtraction of the median?

The value of the initial data is however strange... Assuming the right concatenation of the two x 3 AXL output registers and the correct big/little endian selection, which is the digital interface you use for data acquisition (SPI or I2C and at which speed)? Are you in continuous or FIFO mode? Did you maybe try to use BDU mode to check if you can get a more reliable result?​ Consider also that, just after power-up, if you are using high ODRs the first few samples should be discarded (see the below attached AN). Btw, you could check if, setting an appropriate offset in regs X_OFS_USR, Y_OFS_USR, Z_OFS_USR (p.25 of the AN), you could set the initial offset to zero, and check how the outputs evolve after some rotation/acceleration.

About the fact that you get worse position results at low or constant speed, I think it could be due to the fact that low frequencies movements have less zero-crossing (and sign changes) than high frequency movements, so the functions that describe these movements stay positive or negative for longer time and, in the same time frame, they can accumulate more error in the integration (and double integration) calculation. Btw, I add a paper about pedestrian dead-reckoning: for reference: is there the possibility for you to use also the gyro data?

https://www.st.com/content/ccc/resource/technical/document/application_note/group0/26/07/3f/bf/12/55/47/62/DM00402563/files/DM00402563.pdf/jcr:content/translations/en.DM00402563.pdf

https://www.cambridge.org/core/services/aop-cambridge-core/content/view/53AE4D2B78493491AC12A521FF22CE73/S0373463314000344a.pdf/a-pedestrian-navigation-system-based-on-low-cost-imu.pdf