Tilt Compensation works not for all axis

Forums Technical Support for BerryIMU Tilt Compensation works not for all axis

This topic contains 8 replies, has 2 voices, and was last updated by  Cas Theeuwes 1 month ago.

Viewing 9 posts - 1 through 9 (of 9 total)
  • Author
    Posts
  • #6904

    Cas Theeuwes
    Participant

    Greetings,

    I have Python-BerryIMU with filter working on a Raspberry Pi 3B. I did not change any calculation, only added some code to visualize a compass rose.

    Calibration for Hard Iron Distortion has been implemented.

    This gives a reasonable heading, but the needed Tilt Compensation does not work properly.

    That is to say, there is good compensation for pitch at 0 and 180 degree, but no compensation at all for Roll at these headings.

    At 90 and 270 degree, there is good compensation for roll, but no compensation at all for pitch.

    At headings in between, the Tilt Compensation works as expected; only for this tilt over East-West axis.

    I made a movie to show this behavior on monitor compass rose; North at Top:
    https://www.dropbox.com/s/soohlv2pa7fz51a/20171016_183057.mp4?dl=0

    I checked roll and pitch values; these are OK under all circumstances.
    I have two BerryIMUs , and they both give the same result.
    This result I also get with the “simple” version of the Python-BerryIMU.

    What could be going on?

    The goal is to have full Tilt Compensation at every heading, because the compass is for a USV boat.

    Thanks in advance for help on this.

    Regards,
    Cas Theeuwes

    #6905

    Mark Williams
    Keymaster

    I just downloaded the code from the git repo and it works for me for both pitch and roll.

     

    Can you download the code again and testing berry-simple.py without any modification;

    git clone https://github.com/mwilliams03/BerryIMU.git

     

    The values are in the last two columns.

    Mark --OzzMaker.com --
    BerryIMU --
    PiScreen - 3.5" TFT for the Rasspberry Pi

    #6907

    Cas Theeuwes
    Participant

    Hello Mark,

    I just downloaded the last version berry-simple.py, but result is the same.
    I give you here some “print” results during heading kept near 0 degree, then with a roll of about 30 degree clockwise (so compensated heading shift to 339 degree). Maybe that gives an explanation? :

    Loop Time | 0.19| [1;34;40mACCX Angle -27.09 ACCY Angle -0.47 [0m
    [1;31;40m GRYX Angle 51.35 GYRY Angle -28.77 GYRZ Angle -272.60
    [1;35;40m CFangleX Angle -27.41 [1;36;40m CFangleY Angle -0.25 [1;32;40m
    HEADING 29.12 [1;37;40m tiltCompensatedHeading 339.03

    Loop Time | 0.19| [1;34;40mACCX Angle -28.11 ACCY Angle 0.10 [0m
    [1;31;40m GRYX Angle 51.76 GYRY Angle -28.55 GYRZ Angle -273.27
    [1;35;40m CFangleX Angle -27.67 [1;36;40m CFangleY Angle 0.05 [1;32;40m
    HEADING 28.12 [1;37;40m tiltCompensatedHeading 337.06

    Loop Time | 0.23| [1;34;40mACCX Angle -27.06 ACCY Angle 0.98 [0m
    [1;31;40m GRYX Angle 52.41 GYRY Angle -28.42 GYRZ Angle -274.67
    [1;35;40m CFangleX Angle -27.04 [1;36;40m CFangleY Angle 0.66 [1;32;40m
    HEADING 28.02 [1;37;40m tiltCompensatedHeading 337.71

    Loop Time | 0.19| [1;34;40mACCX Angle -28.13 ACCY Angle 0.90 [0m
    [1;31;40m GRYX Angle 52.74 GYRY Angle -28.49 GYRZ Angle -275.64
    [1;35;40m CFangleX Angle -27.56 [1;36;40m CFangleY Angle 0.78 [1;32;40m
    HEADING 27.19 [1;37;40m tiltCompensatedHeading 336.38

    Loop Time | 0.19| [1;34;40mACCX Angle -27.47 ACCY Angle 1.58 [0m
    [1;31;40m GRYX Angle 53.24 GYRY Angle -28.61 GYRZ Angle -276.44
    [1;35;40m CFangleX Angle -27.30 [1;36;40m CFangleY Angle 1.21 [1;32;40m
    HEADING 30.01 [1;37;40m tiltCompensatedHeading 334.62

    Loop Time | 0.19| [1;34;40mACCX Angle -27.36 ACCY Angle 0.58 [0m
    [1;31;40m GRYX Angle 53.46 GYRY Angle -28.50 GYRZ Angle -277.27
    [1;35;40m CFangleX Angle -27.25 [1;36;40m CFangleY Angle 0.88 [1;32;40m
    HEADING 29.13 [1;37;40m tiltCompensatedHeading 339.29

    Loop Time | 0.19| [1;34;40mACCX Angle -27.30 ACCY Angle 1.11 [0m
    [1;31;40m GRYX Angle 53.81 GYRY Angle -28.47 GYRZ Angle -277.71
    [1;35;40m CFangleX Angle -27.14 [1;36;40m CFangleY Angle 1.03 [1;32;40m
    HEADING 27.08 [1;37;40m tiltCompensatedHeading 335.95

    Loop Time | 0.19| [1;34;40mACCX Angle -27.12 ACCY Angle 1.04 [0m
    [1;31;40m GRYX Angle 54.06 GYRY Angle -28.62 GYRZ Angle -278.24
    [1;35;40m CFangleX Angle -27.03 [1;36;40m CFangleY Angle 0.98 [1;32;40m
    HEADING 28.22 [1;37;40m tiltCompensatedHeading 337.51

    Loop Time | 0.19| [1;34;40mACCX Angle -27.84 ACCY Angle 0.83 [0m
    [1;31;40m GRYX Angle 54.49 GYRY Angle -28.78 GYRZ Angle -279.08
    [1;35;40m CFangleX Angle -27.34 [1;36;40m CFangleY Angle 0.83 [1;32;40m
    HEADING 28.47 [1;37;40m tiltCompensatedHeading 336.81

    #6911

    Mark Williams
    Keymaster

    that doesn’t look right. berryimu-simply from the git repo works with the IMU up the correct way. This is when the skull logo is facing down.

    Here is a video I just took;
    https://www.dropbox.com/s/fqjjjns270nxc9s/IMG_0723.MOV?dl=0

    Mark --OzzMaker.com --
    BerryIMU --
    PiScreen - 3.5" TFT for the Rasspberry Pi

    #6912

    Cas Theeuwes
    Participant

    Yes, my skull logo is facing down as well.
    I also changed to an other PI-3B, bus same result.

    To get same screen output as you have, I added a simple print line.
    Made 2 movies:
    – To show that I did not change anything from berryIMU-simple, but only added some pygame code for making a compass rose.
    – To show that roll and pitch is not both being compensated, with print output.

    https://www.dropbox.com/sh/8gpylbenpswsy1y/AABdA_NwbWJ_AHHrhm0MoRlza?dl=0

    Is it possible that there is a faulty batch of berryIMUs somehow? As I have 2 who behave the same, that seems unlikely.

    Could the magnetic field in my house (big apartment with lots of steel in it) be responsible of this behavior? But that seems also unlikely, considering untilted headings are OK and the compensation works perfectly well in east-west direction.

    #6913

    Mark Williams
    Keymaster

    Mmmm.

    lets check the mag.

    Right after this section;
    ACCx = readACCx()
    ACCy = readACCy()
    ACCz = readACCz()
    GYRx = readGYRx()
    GYRy = readGYRy()
    GYRz = readGYRz()
    MAGx = readMAGx()
    MAGy = readMAGy()
    MAGz = readMAGz()

     

    Can you add this line and show me what the raw mag values look like.
    print (” MAG XYZ RAW %i %i %i —– ” %(MAGx,MAGy,MAGz)),

     

     

    Mark --OzzMaker.com --
    BerryIMU --
    PiScreen - 3.5" TFT for the Rasspberry Pi

    #6914

    Cas Theeuwes
    Participant

    OK, see movie.
    So this is excluding the calibration calculations on them.

    https://www.dropbox.com/s/lkjm5mkurdn4zrb/20171017_195543.mp4?dl=0

    #6917

    Mark Williams
    Keymaster

    Everything looks right, so I am at a loss why it isn’t working.

    can you please add the the raw ACC,GYR and MAG values to your current print out… using;

    print (” ACC XYZ RAW %i %i %i —– ” %(ACCx,ACCy,ACCz)),
    print (” GYR XYZ RAW %i %i %i —– ” %(GYRx,GYRy,GYRz)),
    print (” MAG XYZ RAW %i %i %i —– ” %(MAGx,MAGy,MAGz)),

    Redirect to a file and then do the movement you did in the first video, where it works for roll and not for pitch.    Then attached it to this forum.. or send it to make @ ozzmaker.com.

    If I have the raw data, I may be able to see where it isnt working.

    Mark --OzzMaker.com --
    BerryIMU --
    PiScreen - 3.5" TFT for the Rasspberry Pi

    #6920

    Cas Theeuwes
    Participant

    Ok, thanks.
    Files are rather long, so I sent them to you (mark @) direct.

Viewing 9 posts - 1 through 9 (of 9 total)

You must be logged in to reply to this topic.

Blip, blop, bloop…