Pitch and roll values inverted for Euler Angles in MetaCloud

Using MetaMotion R and MetaCloud. 

When I log data as Euler Angles and upload it to the cloud, I am noticing that the roll and pitch values are inverted. I.e. I am rolling the device and the graph readouts are showing these as pitch movements while roll reads 0. For all other outputs (linear acceleration, raw gyro, and raw accelerometer), the axis are correct. I have tested and re-tested many times. 

Any ideas on the issue or a way to re-calibrate?



    • What platform are you running the MetaBase app on?
    • How are you rotating the board?
    • Do you see the same issue when viewing the CSV files stored on your local device?
      • If you compare the locally stored CSV data with its synced version in the cloud, are the pitch and roll values the same?
    • Is there a similar issue when using quaternions?
    • Can you post your euler angles?
    • IOS
    • On a flat surface at the beginning. I then pick it up in the air and roll the left side over the right side, and right side over left a few times; and then pitch the front over the back, and back over the front. I have done tests and made sure I checked the datasheet to make sure I am aligned on the orientation of the board. 
    • Yes, the pitch and roll values in the CSV match the cloud. 
    • I haven't used quaternions because I do not have experience doing so. 
    • I checked my other 2 MetaMotion R's and they are having the same issue. 
    • Links to a pasteboard should be attached
    Any way to recalibrate/reset?

  • The pasteboard link is missing from your latest post.

    You can reset the algorithm by stopping it, changing modes, or resetting the board.  If you're using NDOF, calibrate the magnetometer with random movements like drawing figure 8s.
  • @Chris14

    We did some tests verifying the rotation axes.  It seems that the issue here is just convention for what is pitch, roll and yaw.

    We verified that rotation around each of the physical x, y, z axes corresponded to euler angle values with the same ordering.  This was found to match.

    In the naming convention used in the sensorfusion implementation, rotation around the x, y, and z axes corresponds to pitch, roll, and yaw.  It seems that this contrasts with definitions in other fields where rotation around the x axis is considered roll, and rotation around y is considered pitch.

  • I tried the magnetometer calibration to no avail. 

    Looks like the submit button doesn't work. They are posted below.

    The first one is of the entire data set:

    The second one is to zoom is a little on the area of most action
  • @Matt Yes, it seems that the x and y axis are backwards from the convention. I thought that was the answer we were moving towards. I guess the question would be: @Eric when could this be corrected by? 
  • There is nothing to correct.  As @Matt pointed out, this is simply a difference in convention and the firmware is correctly reading the data registers from the sensor fusion algorithm.  You can post process the data on your end to interpret the data however you want.
  • I am not sure I agree with that. Saying that pitch and roll being inverted the way they are is a difference in convention would be similar to saying that inverting the axes on a standard x-y graph is simply a difference in convention. I think most people would classify that difference as plain incorrect. It seems like it would be simple enough to change the label of the 2 axes.

    Nevertheless, if I do want to interact with the data that comes to the cloud in a way similar to what you described, how would I go about that? I wasn't aware that the Mbient cloud platform was editable from that type of structural standpoint.
  • edited June 2017
    In flight dynamics +X points in the direction you are facing i.e. away from you.  In the 3D Cartesian coordinate system that you use in a math class, the XY plane is rotated 180 degrees so that  +X points towards you.  Which one is the "correct" convention?

    Similarly, DirectX, flight dynamics, and Wolfram Alpha software have different definitions of pitch, roll, and yaw.  The "correct" convention depends on your application or the library that you are using.

    The cloud data is not editable.  What I mean is, since you have to do your own analysis with sensor fusion data (can only graph sensor fusion data), your software can convert the axes to whatever convention you want before it crunches the numbers.
This discussion has been closed.