Odd values from accelerometer & gyroscope

Home Forums Forums Technical Support for BerryIMU Odd values from accelerometer & gyroscope

Viewing 5 posts - 1 through 5 (of 5 total)
  • Author
    Posts
  • #7094
    Peter
    Participant

    Hello,

    I have a question on your library uploaded in github. When I compile and run your code (“gyro_accelerometer_tutorial01_angles”) to read acc & gryo data from LSM9DS1, I get an identical value from all three axes of my accelerometer (and the same phenomenon for my gyro) while the values from my magnetometer look okay, that is, different values for different axes.

    The value changes with time but still the three components of acc and gyro have the same value even though I move or rotate the sensor. I did not modify the code and just compiled it as it is. Could you please tell what could possibly cause this?

    Thank you so much.

    Best regards,

    Peter Lee

    #7098
    PeterP
    Participant

    Hi Peter, can you please show me the output of

    i2cdetect -y 1

    Peter --OzzMaker.com --

    #7105
    Peter
    Participant

    Hi, Peter,

    This is what I get by issuing the command “i2cdetect -y 1” to my raspberry pi 3:

    0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
    00:          — — — — — — — — — — — — —
    10: — — — — — — — — — — — — 1c — — —
    20: — — — — — — — — — — — — — — — —
    30: — — — — — — — — — — — — — — — —
    40: — — — — — — UU — — — — — — — — —
    50: — — — — — — — — — — — — 5c — — 5f
    60: — — — — — — — — — — 6a — — — — —
    70: — — — — — — — —

    The I2C device addresses for the LSM9DS1 seem to be correctly assigned to 0x1c and 0x6a, respectively. And I tried “i2cdump -y 1 0x6a” to check the register addresses for the accelerometer and the gyro and the output is:

    No size specified (using byte-data access)
    0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
    00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 68    ……………h
    10: a0 00 44 b8 00 2d 00 03 8e ff 3d ff 0b 00 38 38    ?.D?.-.??.=.?.88
    20: 38 80 00 00 00 00 00 07 cd ff 2e 00 f7 0f 00 00    8?…..??…??..
    30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    …………….
    40: 74 51 a0 25 2a ab e4 40 80 c0 35 02 9b 7a 04 1f    tQ?%*??@??5??z??
    50: 39 1b 48 81 82 80 89 a8 92 0d 42 c1 70 4e 08 bd    9?H???????B?pN??
    60: 38 30 80 01 07 00 95 8b 92 21 a1 e1 88 47 24 20    80???.???!???G$
    70: 61 71 00 00 80 68 68 07 02 03 01 00 00 40 c0 00    aq..?hh????..@?.
    80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    …………….
    90: 00 00 00 80 00 00 02 60 a0 ff 2d ff 0c 00 00 00    …?..?`?.-.?…
    a0: 00 00 00 00 00 00 00 00 cb ff 2d 00 f9 0f 00 00    ……..?.-.??..
    b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    …………….
    c0: 00 00 00 00 02 3c 24 4c 1c 22 00 00 00 00 00 00    ….?<$L?”……
    d0: 00 00 00 00 ff 01 00 00 00 00 00 00 00 00 00 00    …..?……….
    e0: 07 00 00 00 07 00 00 00 00 10 00 00 00 00 00 00    ?…?….?……
    f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0    ……………?

    The register addresses for the accelerometer output run from 0x28 through 0x2d, as described in the datasheet of the sensor. But the block read still fails to work correctly. Any comments?

    Thanks,

    Peter Lee

    #7108
    PeterP
    Participant

    I get the same output as above (i2cdump) on a working IMU.

    +Are you trying to red the register using something like this?
    sudo i2cget -y 1 0x6a 0x28
    +Have you tried without anything else connected to the i2c bus?
    +What about the python code, does it also fail to work?

    Peter --OzzMaker.com --

    #7110
    Peter
    Participant

    I just ran an example code included in the BerryIMU library without any modifications to the code to get those results. I looked over the code written in C and found that the I2C read operation in the code calls another library function named “i2c_smbus_read_i2c_block_data.” For some reason I don’t understand that function does not seem to work properly, a similar python code works though.

Viewing 5 posts - 1 through 5 (of 5 total)
  • You must be logged in to reply to this topic.

Blip, blop, bloop…