Calibration perculiar on Linux

[mungewell]

Partly discussed in issue1, reported here for clarity.

Using the code from this repo: https://github.com/jherico/OculusSDK

The amount of turn (gyro) seems to be able half of that expected. I tried with the 'stable' and '0.3-preview' (the only ones which would compile). The same hardware works on a Windows machine running the official download.

Will continue to investigate.

[mungewell]

Changing (or even removing) the following line pSensor->SetRange(SensorRange(4 * 9.81f, 8 * Math::Pi, 1.0f), true);

does not make any difference. Sensor box still reports a delta of 45' when the board is tilted by 90'. Eventually the reported values will creep to being near correct, presumably when the acceleromters are adjust the sensor-fusion.

The official 0.2.5 SDK shows the same problem on OculusWorld, but does not contain SensorBox application.

[mungewell]

Is there any on PC calibration process that I should be doing? (other than a short push on button to cancel out drift). Any jumpers/EEPROM that need to be set?

[mungewell]

Getting back to this (after being busy with other projects for the past weeks), and still seeing the problem. As it's possible my board is a different batch/design to yours I thought I would confirm some part numbers.

U3 = LSM303DLHC (Compass/accelerometer) = 312 M35 U5 = L3GD20 (Gyroscope) = ADG2 2303 XNAAF also note that Crystal (X2) for STM32 is not fitted.

On reverse side SB2, SB4, SB6, SB7, SB8, SB12, SB14, SB16, SB18, SB19, SB20, SB23 are installed/closed (Others are not/open)

I'm also connected the board to a USB2 interface, if that makes a difference.

Datasheet (http://www.st.com/st-web-ui/static/active/en/resource/technical/document/user_manual/DM00063382.pdf) says: The L3GD20 has dynamically user-selectable full scales of ±250 dps/±500 dps/±2000 dps and is capable of measuring rates

So I suspect it's starting up at 250dps, when the Occulus software is expecting 500dps.

[mungewell]

Glancing around code.... main.c line 317: dataScale.rFrame.gScale = 1000;

peripherals.c line 82: case 1000: //1000 deg/s fullscale is not supported by ST chip, use 500 deg/s instead

So what's happening if my PC is requesting 1000degrees (or not changing the default value)?

[michael-betz]

Hi Mungewell,

sorry I have been quite busy these days and couldn't try to fix the scaling bug.

What you can try to do:

open ./inc/peripherals.h and change the following constant:

#define GYRO_SCALE_FACTOR_500 ( 17.50f / 360 * 2 * PI * 10 )

This is the factor used to convert from the raw gyroscope value to the physical value of [10^-4 rad/s]. The GYRO_SCALE_FACTOR_500 is used if the SDK requests a scale of 500 or 1000. In both cases the sensor is initialized to 500 as it does not support the 1000 scale.

If the scale is really off by a factor of 2 you can try to change it to: #define GYRO_SCALE_FACTOR_500 ( 17.50f / 360 * 2 * PI * 10 * 2) or #define GYRO_SCALE_FACTOR_500 ( 17.50f / 360 * 2 * PI * 10 * 0.5)

Cheers YFL

[mungewell]

I see if I can get a build enviroment setup.... but just looking at those values they seem sensible.

Another though that cross my mind, is whether there is a residue parameter held in the eeprom of your board (from your previous coding) which is being referenced, but never set (hence not in my board). Is there an easy way to dump the contents to compare board configs?

[mungewell]

I double checked with my Windows machine and (at least one of) the STM32F3 boards was working OK, so I took it home to check on the Linux machine. Both cards on Linux showed the same faulty behaviour.

Then I started trying different USB ports, and found one where the Foculus works correctly (but don't know why).

Working simon@bigbox:/storage/OculusSDK$ lsusb Bus 004 Device 006: ID 0d8c:0102 C-Media Electronics, Inc. CM106 Like Sound Device Bus 004 Device 009: ID 2833:0001 <------------------------ Foculus Bus 006 Device 002: ID 03f0:1027 Hewlett-Packard Virtual keyboard and mouse Bus 006 Device 003: ID 03f0:1327 Hewlett-Packard Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

Not Working simon@bigbox:/storage/OculusSDK$ lsusb Bus 004 Device 006: ID 0d8c:0102 C-Media Electronics, Inc. CM106 Like Sound Device Bus 005 Device 004: ID 2833:0001 <----------------------- Foculus Bus 006 Device 002: ID 03f0:1027 Hewlett-Packard Virtual keyboard and mouse Bus 006 Device 003: ID 03f0:1327 Hewlett-Packard Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

The machine in question supports USB2 (as Bus 1) and a USB2 capable device shows up on Bus 1 when plugged into either of the two (tested) sockets. The only thing I can see is that the 'working' port has another device on the same Bus, maybe this device is keeping the bus 'active' or running at a higher speed.