Quaternion Output?

[da40flyer]

Hello, Does this library output the game rotation vectors as quaternions?

Please excuse my ignorance, I am relatively new to coding.

My goal is to find a way to just output the game rotation vectors as a W, X, Y, Z quaternion. I have been scouring the web for days looking for info and so far have been unsuccessful in finding anything.

I appreciate any help you can provide.

[ericalbers]

Yes, the game rotation output is a quaternion

[da40flyer]

I sent you an email to your listed junk@ericalbers.com address....

[SL06]

Hi, thanks for sharing your program. The ICM-20948 report game rotation vector (6 axis squat style) and rotation vector (9 axis squat style) but they are not equivalent to the MPU9250 quaternion. GRV and RV are signed value, but standard Quat. Does anyone now's how to transform RV to quat ? I could not found the answer on the web. Thanks

[SL06]

Forget my previous comment. Game rotation vectors are 6 axis quaternion. Rotation vectors are 9 axis quaternion. I am using MPUTeapot to test the quaternions. Quat9 take few seconds to calibrate, you have to turn the sensor in figure 8, and stabilized faster than the MPU9250. Thanks for your work.

[SL06]

HI,

I have not used the code since a while but I will try to help you...

If you want 9 axis rotation vector, you want the quaternion from INV_SENSOR_TYPE_ROTATION_VECTOR

If you want 6 axis rotation vector, you want the quaternion from INV_SENSOR_TYPE_GAME_ROTATION_VECTOR (gyro + acc only,mag result not used)

Both should print 4 floating point quaternion - see here for GRV. If you have trouble with RV printout,try to modify the RV code with GRV code.

case INV_SENSOR_TYPE_GAME_ROTATION_VECTOR:

memcpy(event.data.quaternion.quat, data, sizeof(event.data.quaternion.quat));

event.data.quaternion.accuracy_flag = icm20948_get_grv_accuracy();

sprintf(eamessage, "Quaternion: (%f,%f,%f,%f)", event.data.quaternion.quat[0], event.data.quaternion.quat[1], event.data.quaternion.quat[2], event.data.quaternion.quat[3]);

Serial.println(eamessage);

Regards,

Sylvain

Le 24 févr. 2021 à 13:08, gunar.kroeger notifications@github.com a écrit :

inv_icm20948_dmp_get_9quaternion returns a quaternion with only 3 long integers? how is that supposed to work?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ericalbers/ICM20948_DMP_Arduino/issues/2#issuecomment-785268817, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIWMIQJLPH6G5CAQGCVVVI3TAU6BJANCNFSM4KSXUF4A.

[gunarkroeger]

Sorry, I found out how the value is used and deleted my post. One other question I have is that the quaternion it is flickering sometimes. I found that it is actually happening with the sensor values directly from the dmp:

[gunarkroeger]

This is the Game Rotation Vector I'm getting from the library. Any idea why it has these problems?

[SL06]

it look like some data are corrupt.

How do you get the data ? Is it transmits wireless or print ?

To see if the data is valid. check if w^2 + x^2 + y^2 + z^2 = 1 (or very close to…)

Le 24 févr. 2021 à 17:01, gunar.kroeger notifications@github.com a écrit :

This is the Game Rotation Vector I'm getting from the library. Any idea why it has these problems? https://user-images.githubusercontent.com/22892870/109071399-94c0fd80-76eb-11eb-94e1-4125b3be4b88.png — You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ericalbers/ICM20948_DMP_Arduino/issues/2#issuecomment-785413336, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIWMIQLNYJLXZ3XEVU3KHDTTAVZKDANCNFSM4KSXUF4A.

[gunarkroeger]

it's directly printed through the serial line, and other data is not corrupt. The magnitude of the quaternion is always 1, except when it glitches, where it got as high as 8.9999. The glitches are happening with 2 different nrf52 + icm20948 boards. Can you confirm that you see smooth values in your setup?

[SL06]

I am using the nrf52 + icm20948.

I have the nrf52832 dev board and now using C++ with Segger development studio.

I remember that I had some occasional glitch at one point but they seem to have disappeared. At some point, I had in my program a line to check if quat magnitude equal 1 to discard corrupt data, but that line is not necessary anymore.

Not sure what causes your problem. Could be a timing problem... Check if adding delays at some critical step help. Could be a data transmission problem… Check baud rate / different port ?

Sylvain

Le 24 févr. 2021 à 17:13, gunar.kroeger notifications@github.com a écrit :

it's directly printed through the serial line, and other data is not corrupt. The magnitude of the quaternion is always 1, except when it glitches, where it got as high as 8.9999. The glitches are happening with 2 different nrf52 + icm20948 boards. Can you confirm that you see smooth values in your setup?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ericalbers/ICM20948_DMP_Arduino/issues/2#issuecomment-785419438, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIWMIQIWVB5W6RLZFGHGMYLTAV2XJANCNFSM4KSXUF4A.

[gunarkroeger]

Interesting. I am using C++ but with the PlatformIO + VS Code. It is not an issue with the Serial. the baudrate is actually not relevant for the nrf52 bc it is actually USB. and the rest of the data, like headers, never arrive corrupted. It could be an issue with i2c, but my colleague in another country has the same problem with different computer, different everything. So it must be code. I enabled the mag, acc, gyr and the game rotation vector only, all at ODR 5 (200Hz). Maybe it cannot keep up when polling so fast? At some point we need to use the interrupt correctly, but the code was commented out in this library and I'm not totally sure how to implement it.

[SL06]

Are you using the nrf52 development board?

USB communication is done in serial mode
You have to set the UART baud_rate And also the terminal baud rate.
ex : NRF_UART_BAUDRATE_1000000

If you transmit a lot of data and the BR is to low, buffer might get full and cause errors.

What computer are you using mac PC …?

Le 24 févr. 2021 à 17:31, gunar.kroeger notifications@github.com a écrit :

Interesting. I am using C++ but with the PlatformIO + VS Code. It is not an issue with the Serial. the baudrate is actually not relevant for the nrf52 bc it is actually USB. and the rest of the data, like headers, never arrive corrupted. It could be an issue with i2c, but my colleague in another country has the same problem with different computer, different everything. So it must be code. I enabled the mag, acc, gyr and the game rotation vector only, all at ODR 5 (200Hz). Maybe it cannot keep up when polling so fast? At some point we need to use the interrupt correctly, but the code was commented out in this library and I'm not totally sure how to implement it.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ericalbers/ICM20948_DMP_Arduino/issues/2#issuecomment-785427848, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIWMIQNOTP4YNLN75H4WWFTTAV42TANCNFSM4KSXUF4A.

[gunarkroeger]

I'm using the Adafruit ItsyBitsy. The baudrate argument is just being voided in the Serial initialisation bc the board uses native USB instead of a serial2usb converter. I reduced the ODR and the issue happens less often. It seems to be a problem with i2c not being fast enough, at least the way it is implemented now. I read on another issue here that they had to change to SPI bc i2c was not fast enough for 200Hz ODR.

Calling the inv_icm20948_poll_sensor function is taking a lot of time and is not consistent (from 1.6ms to 5ms). I wonder if it is waiting for new data when it is still not available bc the interrupts are not being used.

[SL06]

Do you have short I2C connector length ? I normally work at 60Hz - 7 wireless sensor sending data to a central.

Not sure that I can help you at this point ...

Closing computers for the evening….

A+

Sylvain

Le 24 févr. 2021 à 17:58, gunar.kroeger notifications@github.com a écrit :

I'm using the Adafruit ItsyBitsy. The baudrate argument is just being voided in the Serial initialisation bc the board uses native USB instead of a serial2usb converter. I reduced the ODR and the issue happens less often. It seems to be a problem with i2c not being fast enough, at least the way it is implemented now. I read on another issue here that they had to change to SPI bc i2c was not fast enough for 200Hz ODR.

Calling the inv_icm20948_poll_sensor function is taking a lot of time and is not consistent (from 1.6ms to 5ms). I wonder if it is waiting for new data when it is still not available bc the interrupts are not being used.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ericalbers/ICM20948_DMP_Arduino/issues/2#issuecomment-785440359, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIWMIQNYMYBPQFMYU66WQSLTAWABHANCNFSM4KSXUF4A.

[SL06]

Hi again, NRF52 have internal pul-up resistor for their line. You might want to be shure that its in use (if needed) with I2C (TWI) or SPI

To know more , look at https://devzone.nordicsemi.com/f/nordic-q-a/36357/nrf52832-twim-pull-up-value https://devzone.nordicsemi.com/f/nordic-q-a/36357/nrf52832-twim-pull-up-value . Do a search on pull-up resistor on their site and post an new question if necessary.

What program/language on your computer do you use to communicate with nrf52 to communicate through USB ? I have a NRF52840 doogle with true USB port that I want to use.

Sylvain

Le 24 févr. 2021 à 17:58, gunar.kroeger notifications@github.com a écrit :

I'm using the Adafruit ItsyBitsy. The baudrate argument is just being voided in the Serial initialisation bc the board uses native USB instead of a serial2usb converter. I reduced the ODR and the issue happens less often. It seems to be a problem with i2c not being fast enough, at least the way it is implemented now. I read on another issue here that they had to change to SPI bc i2c was not fast enough for 200Hz ODR.

Calling the inv_icm20948_poll_sensor function is taking a lot of time and is not consistent (from 1.6ms to 5ms). I wonder if it is waiting for new data when it is still not available bc the interrupts are not being used.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ericalbers/ICM20948_DMP_Arduino/issues/2#issuecomment-785440359, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIWMIQNYMYBPQFMYU66WQSLTAWABHANCNFSM4KSXUF4A.