2023-02-10 12:23 PM
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.
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?).
2023-02-10 12:35 PM
Here are the videos:
Weird rotations on startup - sometimes
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.
2023-02-15 02:12 AM
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.
2023-02-15 03:18 AM
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.
2023-02-16 02:32 PM
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.
2023-02-17 10:41 AM
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?
2023-02-17 11:43 AM
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.
2023-03-06 11:32 PM
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.
2023-03-06 11:35 PM
2023-03-06 11:35 PM