Hello Community,

I have seen, that there is a orientation.h, that is able to provide quaternion and euler data.
Does anybody know how this is calculated and why the Virtual XDK Application doesn't use it.
As far as I saw it is calculated but afterwards only the Gyro, Accelerometer, .... data is sent to the application.

BR,
Florian 
0 (0 Voti)
[XDK-Toolbox] Orientation.h, Quaternion and Euler Data
Risposta
28/05/15 4.05 come risposta a Florian Dittrich.
Hi Florian,

seems like you're making progress with your libGDX project.

I have modified your thread title a little bit to clarify the intend of your thread for other a bit more.

As I couldn't find any file named "orientation.h" as described by you, I have to assume that you are either talking about this file: "AssemblyU2DCSharp_Assets_Model_Orientation.h" which is a derived file from the unity project.
Otherwise the only things I was able to find that are connected to the keywords "quaternion" or "euler" are  "Xdk.cs" or "*GaugeController.cs" which are Asset files of the Unity project. 

Could you may clarify about which file you are talking so I can investigate further into this? 

Regards,
Florian (writing from Manuels account)
0 (0 Voti)
[XDK-Toolbox] Orientation.h, Quaternion and Euler Data
Risposta
28/05/15 6.40 come risposta a Manuel Cerny.
Hi Florian,

I think, I have been a little unclear. The orientation.h File is from the XDK Toolbox and is a virtual sensor that provides quaternion and euler data by combining BMI160 and BMM150. That's all I know so far.

Because I am having trouble implementing the Sensor fusion in libGDX it would be great if I can just use this data and do the rotation. One Problem is, that I am currently using the DSM_demoSensorMonitor, which is not very easy to change in the way that I can now send orientation data instead of Accelerometer, Gyroscope and Magnetometer.

Nice to know would be, if the calculation of the orientation values is exact enough to be able to perform a rotation, that is nice to see for the user. Also I think information about the delta time between the sensor events is requiered to properly rotate the model. Did you set that manually within the Virtual XDK application?

As I have seen in the release notes of Version 2 of the Virtual XDK that it uses this virtual orientation sensor data, I am quite confident, that this is the right way to go in my point of view.

Thanks for your help and best regards,
Florian

 
0 (0 Voti)
[XDK-Toolbox] Orientation.h, Quaternion and Euler Data
Risposta
28/05/15 8.34 come risposta a Florian Dittrich.
Hi Florian,

sorry to bother you with all my problems, but I am really confused at the moment.

I just wanted to add the orientation values within the DSM_demoSensorMonitor Code but I am receiving the following Error while flashing.

c:/xdk-workbench/armgcc/bin/../lib/gcc/arm-none-eabi/4.7.4/../../../../arm-none-eabi/bin/ld.exe: region RAM overflowed with stack

The line that is triggering that error is the following:

_orientationReturnValue = orientationInit(xdkOrientationSensor_Handle);

I don't really want to do alot of changes in the C Code, what I'd like to do is simply add the orientation sensor values to the others and send it via WIFI to my application. I was hoping this is not as a big deal as it seems now.

Is there a way to increase the RAM size?

BR
Florian
0 (0 Voti)
[XDK-Toolbox] Orientation.h, Quaternion and Euler Data
Risposta
29/05/15 14.20 come risposta a Florian Dittrich.
Alright I managed to solve my problems, but new ones are arising :)

I solved the RAM problem by throwing out all the calculation of avg, int, min, max that where inside the DSM_demoSensorMonitor Code. I don't really use that data so that's OK for me.

Now I calculate the euler data using the virtual orientation sensor. I decided to use the 

orientationReadEulerValueInDegree(orientation_eulerData_tp eulerValueInDegree);

Function.
So what I do is the following:

orientation_eulerData_t _orientData = {0.f, 0.f, 0.f};
orientationReadEulerValueInDegree(&_orientData);

It seems, that the heading/yaw values are in the interval of [0,360] the values for pitch in the interval of [-90, 90] and the values for roll in the interval of [-180,180]. Does that make sense or am I missing anything here?
Also do frameworks like Unity or libGDX expect these values if I pass "Degree" values?

BR,
Florian
0 (0 Voti)
[XDK-Toolbox] Orientation.h, Quaternion and Euler Data
Risposta
05/06/15 0.48 come risposta a Florian Dittrich.
Hello florian.dittrich,

my apologise for being so late with this reply. It took me a bit longer to reply as I had to forward your questions with the second level support first, to confirm what I thought.

It seems, that the heading/yaw values are in the interval of [0,360] the values for pitch in the interval of [-90, 90] and the values for roll in the interval of [-180,180]. Does that make sense or am I missing anything here? 

Your assumption is correct and the heading/yaw values are in the inverals you mentioned. If you look into the VirtualXDK Demo, you'll recognize that these intervals are expected and processed to animate the VirtualXDK animation which is displayed in the middle.

Also do frameworks like Unity or libGDX expect these values if I pass "Degree" values? 

I can't give you support specifically for Unity or libGDX as I'm not an expert on these frameworks myself, though looking into their documentation and the unity source code of the VirtualXDK demo, it seems to be Degree values.

Hope that helps,
Florian

0 (0 Voti)
[XDK-Toolbox] Orientation.h, Quaternion and Euler Data
Risposta
05/06/15 15.10 come risposta a Manuel Cerny.
One more thing I forgot to mention yesterday:

If you want to see some more data in the VirtualXDK app, you can click on the settings tab after you're connected to the XDK and then click on the SD Card icon. That'll show you a hidden menu with some more data.
0 (0 Voti)
[XDK-Toolbox] Orientation.h, Quaternion and Euler Data
Risposta
08/06/15 11.34 come risposta a Manuel Cerny.
Hi Florian,

thanks for your help so far. I changed the sensor method from euler to quaternion and I am transmitting those values now. I couldn't find a way to use the euler values because on one axis the model was jumping at one point due to the [-90;90] interval.

I tried to change the demoSensorMonitor code so that the quaternion values are transmitted. Now I succeeded to show a nice behaviour of my 3D Model, but there is still some weird stuff going on. I'm not sure if you can help me with this, but I am a little lost right now so I just try it :)

What I did in the C cod is, I added 

        struct {
            int32_t w; /**< w axis data */
            int32_t x; /**< x axis data */
            int32_t y; /**< y axis data */
            int32_t z; /**< z axis data */
        } wxyz;

in the CMN_common_ch.h to have a data structure for the quaternion data.
Within the for loop in the DTA_SendSensorsDataTimerHandler method I added the following:
if (_code == 0x0400) {
                uint8_t _dataRec[DTA_CODE_LENGTH + DTA_FOUR_DWORD_LENGTH];
                dtaPrepareSendBufferForDWORDData(_dataRec, _code,
                    s_sendingElementTableInt[i].dataPtr);
                dtaFlushDataBufferToConnectedDevice(_dataRec,
                DTA_CODE_LENGTH + DTA_FOUR_DWORD_LENGTH);
            } else {
                printf("X: %d, Y:%d, Z:%d\r\n",
                                    s_sendingElementTableInt[i].dataPtr->i.xyz.xAxisData,
                                    s_sendingElementTableInt[i].dataPtr->i.xyz.yAxisData,
                                    s_sendingElementTableInt[i].dataPtr->i.xyz.zAxisData);

                uint8_t _dataRec[DTA_CODE_LENGTH + DTA_THREE_DWORD_LENGTH];
                dtaPrepareSendBufferForDWORDData(_dataRec, _code,
                                    s_sendingElementTableInt[i].dataPtr);
                dtaFlushDataBufferToConnectedDevice(_dataRec,
                DTA_CODE_LENGTH + DTA_THREE_DWORD_LENGTH);
            }

 

where the sensor with the code = 0x0400 is the orientation sensor.
Now the problem that occasionally I receive the same values for different sensors. Which means the values that are received look like this:

ENV_TEMPERATURE, P0: 30.91 °C; 
ENV_PRESSURE, P0: 975.1 hPa; 
ENV_HUMIDITY, P0: 42.0 %RH; 

LIGHT, P0: 30.91 Lux; 

ORIENTATION, P0: 0.3091 ; P1: 0.9751 ; P2: 4.2E-4 ; P3: 2013.2659 ; 

ENV_TEMPERATURE, P0: 30.91 °C; 
ENV_PRESSURE, P0: 975.1 hPa; 
ENV_HUMIDITY, P0: 42.0 %RH; 

LIGHT, P0: 30.91 Lux;

As you can see, the actual values that are transmitted are the same for the different values. But they are divided by different values.
Usually the XDK is supposed to send data for each sensor respectively. But sometimes it collects the data of more than one sensor and sends them together. Whin this happens I receive the wrong values, but I don't know why. I assume that the buffer that is sent gets overwritten, but I couldn't find a way to prevent this so far.

I think it is a problem that I am sending 4 values with the quaternion data instead of 3 for all the other sensors. I know it is difficult to give advice without seeing the whole code, but maybe you have an idea.

Thanks in advance,

BR,
Florian

Edit:
Here is also the dtaPrepareSendBufferForDWORDData Method:

static void dtaPrepareSendBufferForDWORDData(uint8_t buffer[], uint16_t code,
        multiData_tp sensorData) {
    if (code == 0x0400) {
        memset(buffer, CMN_NUMBER_UINT8_ZERO,
        DTA_CODE_LENGTH + DTA_FOUR_DWORD_LENGTH);
        SWAP_16_MEMCPY_MACRO(&buffer[0], code);

        SWAP_32_MEMCPY_MACRO(&buffer[2], sensorData->i.wxyz.w);
        SWAP_32_MEMCPY_MACRO(&buffer[6], sensorData->i.wxyz.x);
        SWAP_32_MEMCPY_MACRO(&buffer[10], sensorData->i.wxyz.y);
        SWAP_32_MEMCPY_MACRO(&buffer[14], sensorData->i.wxyz.z);
    } else {
        memset(buffer, CMN_NUMBER_UINT8_ZERO,
        DTA_CODE_LENGTH + DTA_THREE_DWORD_LENGTH);
        SWAP_16_MEMCPY_MACRO(&buffer[0], code);

        /* Fill the sensor values */
        SWAP_32_MEMCPY_MACRO(&buffer[2], sensorData->i.xyz.xAxisData);
        SWAP_32_MEMCPY_MACRO(&buffer[6], sensorData->i.xyz.yAxisData);
        SWAP_32_MEMCPY_MACRO(&buffer[10], sensorData->i.xyz.zAxisData);
    }
}

0 (0 Voti)
[XDK-Toolbox] Orientation.h, Quaternion and Euler Data
Risposta
08/06/15 14.41 come risposta a Florian Dittrich.
Hey Florian,

I'm more than happy to help you and get your problem solved. Though, as you said, it's hard for me to give any kind of support without seeing the complete source code. Therefore I would like to ask you to upload your project here or somewhere else.

If there are any concerns about your source code, you can also PM me with a link to your files.

Is this a viable option for you?

- Florian
0 (0 Voti)
[XDK-Toolbox] Orientation.h, Quaternion and Euler Data
Risposta
09/06/15 6.51 come risposta a Manuel Cerny.
Hi Florian,
thank you for the offer, I am going to look for a way to upload my code somewhere. 
How can I send you a private message in here? Or can you send me your email address, then I can send it to you directly.

BR,
Florian
0 (0 Voti)
[XDK-Toolbox] Orientation.h, Quaternion and Euler Data
Risposta
22/06/15 19.47 come risposta a Florian Dittrich.
Hi,

I guess I went too quick with offering PM's as there's no private message support yet.
Send it to CENSORED

- Florian
0 (0 Voti)
[XDK-Toolbox] Orientation.h, Quaternion and Euler Data
Risposta
23/06/15 12.52 come risposta a Manuel Cerny.
Hi Florian,

I'm almost done with my libGDX project, but there are a few things left, that I can't figure out.

One thing is the following. When I startup the XDK and start my Application, the XDK is usually displayed facing the right side of my screen. But when I move it around a little (only if I move it around) it soon switches to face the top. Like moving around the Z-axis around 90 degrees.

I have printed the euler values that arrived at my client application and the output is the following

Yaw             Pitch                 Roll
  Z                    Y                        X
0.4511385, 0.6364403, -7.180535

0.4511385, 0.6369051, -7.180535
8.508702, 3.5748239, -6.7360106
14.142345, 5.7854166, -6.7360106
22.651892, 7.9943585, -5.890626
27.814293, 8.830098, -4.950272
16.242878, -32.10538, 70.08937
16.242878, -32.10538, 70.08937
16.242878, -32.10538, 70.08937
16.242878, -32.10538, 70.08937
17.482374, -36.27209, 68.90205
17.482374, -36.27209, 68.90205
19.653822, -42.26289, 67.34811
18.299496, -42.555466, 66.96495
11.136309, -26.437838, 71.7005
7.180535, -15.310559, 72.92897
0.9022211, -4.337137, 72.108116
0.9022211, -4.337137, 72.108116
0.9022211, -4.337137, 72.10811

when I restart the application the XDK faces the top, so after this "jump" it stays like this. Is that some sort of calibration?

BR,
Florian
0 (0 Voti)
[XDK-Toolbox] Orientation.h, Quaternion and Euler Data
Risposta
24/06/15 19.18 come risposta a Florian Dittrich.
Florian,

I would wonder if that's some sort of calibration, but I'm not sure if I understood you right. 
So let my try to rephrase what you have described:

When you start the application, the first values you receive indicate that the XDK is facing right side up, once you move it a little the values normalize and you get the right orientation, is this correct?

What I'm trying to find out and wondering is to see if it's a problem on your libGDX project where your Android application is experiencing some problems or if the sensors auto calibrate after they have been started.

I tested it with the VirtualXDK app for iOS that is shipped with the Demo and couldn't replicate what you've described.

- Florian
0 (0 Voti)
[XDK-Toolbox] Orientation.h, Quaternion and Euler Data
Risposta
25/06/15 6.35 come risposta a Florian Harr.
Well I don't actually see it with the values, more with the 3D application. See the screenshots below.
Between these two screenshots I was just moving it around a little and placed it back at the same position and orientation.

BR,
Florian
0 (0 Voti)
[XDK-Toolbox] Orientation.h, Quaternion and Euler Data
Risposta
01/07/15 4.47 come risposta a Florian Dittrich.
Florian (that's like talking to myself :) ),

Thanks for the screenshots, that makes it a lot clearer for me. 
Here's my guess:
It looks to me like this is a software error where your variables aren't initalized properly and have strange "random" values when you start the app and ones you turn the XDK and these variables are "overwritten" the orientation is good again.

Can you double check that?

For the XDK there shouldn't be any calibration or such things. Each of the sensors has a internal filter (see datasheet for more info), but that seems very unlikely that these two problems are connected.

- Florian
0 (0 Voti)