MEMS Libraries problems

[Pajaka]

Hi,

I'm facing several problems while using the MEMS1 package. I have designed a custom board with the L552 mcu and LSM6DSO32 and LIS3MDL sensors on the same SPI bus. The board has a WiFi connectivity, an SD card and a plethora of user IO. The firmware is written in C++ (no STL, no RTTI, no exceptions) and uses ThreadX. All of the ThreadX functionalities are wrapped into thin classes. My goal is to estimate a 3D orientation using MotionFX. I'm also using MotionMC and MotionAC and the results of calibration are stored on the SD card. I'm using the latest CubeIDE.

• My first problem is that I'm forced to use XCUBE-MEMS1 v9.3.0. When I try to use the v9.4.0 I get several Multiple definition of ***. First defined in YYY. problems. Simply put, when using 9.4.0 I cannot link multiple MEMS1 packages into a single project.

• I was not able to pass the Accelerometer calibration (MotionAC) in dynamic mode. My workflow was the following:

1. Init MotionAC and its knobs. Set the algorithm frequency Falg.
   1. Poll the IMU data.
   2. Memcpy the data into a MAC_input_t structure.
   3. Update the timestamp with HAL_GetTick.
   4. Hard coded delay of 1/Falg seconds.
   5. Repeat 2-5 until the *is_calibrated is 0x01.

I first tried to follow the written instruction in UM2182. Then I tried to follow the graphical instructions. I found those to be quite different, yielding different orientations but whatever. Then I tried to run the 6 point tumble. Again no success, until I found some thread on this forum where the op said that the input to the MotionAC_Update function should in fact be an array of 6 MAC_input_t structs. I tried this approach and it worked somehow - I don't have any means of validating the results yet. Why isn't this explained in the guide? Can someone please explain it to me? One curious thing is that this method works even without setting the timestamp variable (which one of the 6 point should hold the timestamp anyway? all of them? first one? the same timestamp?).

• My (so far) last problem is with the MotionFX library. My program is divided into several threads. There is an SD card thread which loads the wifi settings and the calibration constants (biases and 3x3 matrices for magnetometer and accelerometer). This thread then starts an IMU init thread which of course inits the SPI and the sensors registers. When the calibration settings parsing fails, this thread spawns two new threads - one for mag calibration and one for the accelerometer calib. When these threads are finished, the results are again stored on the SD card and a Fusion thread is finally launched. And here I'm facing a drift problem in horizontal plane (yaw). I'm reading the IMU data at 104 Hz, the magnetometer is updated at 20 Hz. I'm using an INT triggered DMA transfers. I have written an OpenGL app in C++ that visualizes the board's orientation - rotations done usingquaternions from the MotionFX output struct and are being perfomed inside the Shader program. No matter how I rotate the board there seems to be a cumulative drift in the horizontal plane. I say cumulative because it can be unwinded, when rotating in an oposite direction. I suspect the magnetometer to be the cause of this although It'd been calibrated. I tried to alter all of the MotionFX knobs and I wasn't able to mitigate this problem. Some of the settings have very little effect on the problem. I will post links to my videos below showing the problem. (is my question too long now so I cannot and links?).

[Petr S]

Above mentioned example datalog formats will help me to simulate your data in our application and see if the problem is in your data (HW) or in your code.

BTW in X-CUBE-MEMS1 v9.6.0, which should be released in about a month or slightly more, you'll find the MotionFX and MotionMC libraries corrected in terms of visibility of variables and functions. Then you should be able to combine them in one application.

[Pajaka]

I went through my IMU initialization code and found that I left the Gyro's HighPass filter on from the previous project, which didn't really require the Gyro - so no problems observed there. Then I had to dig deeper into the Application note to see the HP filter settings and I of course did not follow these steps in my fusion project - didn't know about the App note. The HP is a FIR filter, I suppose, and a pretty large one (lot of bins), I suppose. The Application note states that the HP filter requires up to 45s for its output to reach 99% of the final value (page 13, table 13). A FIR filter this long would produce a significant phase delay (which again is not addressed in either the Datasheet or App. note) which can distort the measurements. This information should be present in the Datasheet I believe.

As for the data logs - I found a problem with my data visualization application and it needs addressing first. I will post these Logs later, but I managed to get it working at a decent level.

[Petr S]

No need to send datalogs if it will more or less work after all your fixes 😉