›

Rotating acceleration data into horizontal plane

torbenreestorbenrees
edited October 2017 in General
Hello,

I've been using a 6 axis MetaWear RG situated on the back of a horse to stream acceleration data at 200Hz and gyro at 50Hz. Using this data I've been able to design an Android app capable of distinguishing between different gaits (e.g., trot, gallop, etc) as well as providing real-time analysis of the particular gait. My device is of course reporting the accelerations in the reference frame of the board but despite this I have been able to get some really useful results.

Being attached to the horse's back the board is rotating quite a lot sometimes 8-10 oscillations per second but never beyond say 45 degrees in X or Y. Also, it is common for the device to shift away from the initial alignment during riding and so the X and Y samples start to pick up a gravity bias. This rotation means that my acceleration data contains a fair bit of distortion and I am seeing patterns in the acceleration that are mainly just patterns of rotation (interesting in themselves but not what I want here).

To get further I really need some way of knowing the absolute orientation of the board at any given moment and then rotating the measured acceleration vector into the horizontal reference frame of the horse. By which I mean, Z axis defined by gravity and the X axis defined by the longitudinal axis of the horse's body (which basically aligns with the x axis of the board due to how it is mounted). 

To get to the point my questions are: 

1. Will a board with sensor fusion give me the information I need to rotate/transform the acceleration vector into the reference frame described above?
2. If so, can you use on-board processing to rotate/transform the acceleration values into the required reference frame before streaming rather than having to do it on the phone?
3. What sampling rate(s) can I use for quaternions or Euler angles?
4. If the answer to 2 is 'yes' could I stream rotated acceleration samples still at 200 Hz?

Many thanks for any assistance

Torben

Comments

  • EricEric
    The sensor fusion algorithm provides linear acceleration (i.e. acceleration with gravity removed).  Is this sufficient to handle the the alignment issue, which would remove the need to adjust the frame of reference.

    The algorithm calculates absolute orientation and represents it as quaternions or Euler angles.

    No, you will not be able to use the on-board processing to manipulate data from the IMU and sensor fusion algorithm together.

    See the below table for sensor fusion sampling frequencies:
  • torbenreestorbenrees
    Hi Eric,

    Do we define 'absolute orientation' as orientation with respect to the reference frame defined by gravity and magnetic north?

    What is the difference between absolute and 'relative' orientation (as mentioned in the IMUPlus mode)? I'm guessing that relative simply omits the rotation around Z axis and defines the smallest rotation required to get the board back to level?

    If I were to use the NDoF or IMUPLus mode at 100Hz would I be able to simultaneously stream acceleration values at 200Hz?

    Removing gravity won't solve the alignment issue because I want to have all the accelerations detected by the board represented in the 'horse' reference frame (Z axis defined by gravity and X defined by the longitudinal axis of the horse). Therefore I need to be able to rotate the acceleration vector accordingly.

    By the sound of it I can take the raw acceleration values and use the orientation quaternion (or it's inverse?) to perform the rotation from board reference frame to absolute reference frame (as defined above) or 'relative' frame. Depending on your answer to the above I might then need to rotate again around the Z axis to get to the 'horse' frame.

    Thanks again for your help

    Torben

  • EricEric
    Absolute orientation calculates the direction of magnetic north.  Relative orientation depends on how the sensor is placed initially.  This should not matter if you're simply calculating relative change from q to q'.

    No, the algorithm requires the sensors be operating at specific frequencies.
This discussion has been closed.