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?).

[Pajaka]

Here are the videos:

Weird rotations on startup - sometimes

Drifting error

I can post the Code if necessary.

I'm also curious about the Kalman algorithm implementation and I'm for the time being only interested in the 3d Orientation. Afaik, the predict step usually uses the gyroscope measurements to predict the internal states (orientation). Then the prediction is corrected in the update step using accelerometer (for roll and pitch) and magnetometer (for yaw). And this is where I'm lost in the ST's implementation as there are no separate functions to input data from these sensors - all is done through the MFX_input_t struct. But the IMU and the Magnetometer are not synchronized and are sampling at different frequencies. So I'm calling the update function with an old magnetometer data.

[Petr S]

1. There is a new X-CUBE-MEMS1 package version v9.5.0 on ST web pages, maybe the first issue with multiple definitions is already solved in that version, otherwise please send your project. Also inside STM32CubeMX PC application there is this updated version which I suggest you to use for generation of the code for your HW and inside that implement your functionalities.

2. I strongly recommend to follow the steps done in AccelerometerCalibration FW application in X-CUBE-MEMS1 package. Both the 9-point and 6-point calibration works well there and you'll practically see how to handle data including the timestamp. You can observe the data and library outputs graphically in Unicleo-GUI PC application.

3. For MotionFX and MotionMC issues I suggest to study the SensorFusion FW application (or for MotionMC separately you can use MagnetometerCarlibration FW application). As said, these FW applications work well and you can use them as reference of correct data handling and observe results in Unicleo-GUI.

[Pajaka]

Hi, thanks for your reply. I tried to use the v9.5.0 package and I get the same errors: ../Middlewares/ST/STM32_MotionMC_Library/Lib\MotionMC_CM33F_wc32_ot_hard.a(motion_mc.o):(.bss+0x3e4): multiple definition of `magProcBuff'; ../Middlewares/ST/STM32_MotionFX_Library/Lib\MotionFX_CM33F_wc32_ot_hard.a(motion_fx.o):(.bss+0xc): first defined here .

And as for the second and third problem, I've always found the ST's example code a bit convoluted so I tried to avoid it as much a possible. I guess I'll have to dig a bit deeper then.

[Petr S]

You're right, there is really a conflict with the magProcBuff array that needs to be fixed in next release. Currently there is at least the hard iron magnetometer calibration implemented in MotionFX which you can temporarily use instead of MotionMC till next X-CUBE-MEMS1 release.

[Pajaka]

I seem to have found a cause of my third problem - the cumulative drift. It is in fact caused by LSM6DSO32 gyroscope operating in HIGH-PERFORMANCE mode. When I set the ODR to LSM6DSO32_GY_ODR_104Hz_NORMAL_MD, the problem goes away. The accelerometer can be left at HP mode. I expected the IMU would work the best, accuracy, drift, and offset wise, when in high-perfomance mode, although there isn't any comparison table of the power modes in the datasheet whatsoever.

I went through the AccelerometerCalibration example again and I'm maybe ever more confused now. In the example, the AC_Data_Handler function handles the calibration process. There is a call to the MotionAC_manager_update function and right after it a MotionAC_manager_get_params call. The uint8_t is_calibrated is not tested to be set at all. Then the params are blindly sent over to the serial port. I tested a similar piece of code in my system and unless the is_calibrated flag is set to 1, the calibration output is all zeros, both the bias vector and the SF_Matrix. When I try to apply an acc correction, the resulting acc vector is zero obviously (multiplied by a zero matrix). Shouldn't the library output an EYE matrix as its SF_Matrix at least even when the calibration hasn't been successfully finished?

[Pajaka]

I have tested multiple ODR settings - I always set the ACC and GYRO to the same ODR to have the data synced so I can read all 6 register pairs starting from OUT_L_G at once. No matter which ODR I set, the orientation estimate always drifts in a horizontal plane when the Gyro operates in HP mode. Can you please elaborate? I have also tested my second identical unit, which was prone to a more profound drift. When I set the gyro to operate in normal mode, the drifting is almost negligible, but still there. It turned out that this IMU, for some reason, cannot operate above 104Hz ODR reliably, not mentioning the gyro HP mode problem.

[Petr S]

Could you please send me your datalogs including timestamp, input and your output data? If you send it in the format as you can see in the attachment it will speed up my analysis.

• Please send one datalog which doesn't work for your MotionAC application, I'll try to replicate it in the AccelerometerCalibration application.
• Then please send the datalog with GYRO set to normal mode, again including all other input and output data for replication in MotionFX application.
• And then the same datalog with GYRO set to HP mode.

[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 ;)

[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.