# Controlling Unity 3D cube with remote gyroscope

This probably will go into conceptual things as well, but what I would like to do is take a Raspberry Pi (with a Sense Hat), transmit the gyro values to Unity, and effectively have a 1-1 realistic representation of orientation changes.

I have no problem transmitting values from the Pi to Unity (though learning about hidden firewall rules was fun), however I am lacking some understanding of how to transform raw gyro values to something representative in Unity.

I have not calibrated the Sense hat recently, but know that is something that should be done.

For example, I am transmitting the pitch/roll/yaw values from the Pi (resting normally, these are about: 100.30272132022793, 351.3885231076573 354.9306950697191).

I have a cube gameobject that I've flattened out and set to the origin.

My question is basically, what is the best way to translate raw values from some anonymous object to the Unity coordinate system, and have it rotate appropriately? I don't necessarily want its position to change, just rotation.

Screenshot for reference. Raspberry Pi sending gyro data is on the left, Unity is on the right. Tabletop (flattened cube) is what I'd like to rotate to simulate a ball balancer.

• Do you also have an accelerometer or magnetometer you can use to correct for drift in the gyroscope reading, via sensor-fusion? What coordinate system are your output values in? We'll need details on that coordinate system to be able to accurately convert it to Unity's. – DMGregory Apr 13 '20 at 23:04
• Regarding the coordinate system I'll need to dig further (raspberrypi.org/documentation/hardware/sense-hat), but there is an accelerometer I can also query. – the_e Apr 13 '20 at 23:10
• There is a magnetometer as well, is this figure what you're looking for in terms of the coord system? deviceplus.com/wp-content/uploads/2017/06/image6.jpg – the_e Apr 14 '20 at 2:28
• That helps. What specific API are you getting these angle values from? – DMGregory Apr 14 '20 at 2:30
• Notice that this method disables the accelerometer and magnetometer. For a more accurate/stable orientation estimate, it looks like you want to useget_orientation() or get_orientation_degrees() instead. – DMGregory Apr 14 '20 at 13:14

I find the documentation a little under-defined, in terms of how to interpret the numbers coming in from the various methods.

From this diagram it looks like you might be able to set...

Dictionary<string, float> orientation = ReadOrientationDegrees();

transform.localEulerAngles = new Vector3(-orientation["pitch"],
orientation["yaw"],
-orientation["roll"]);


Here I've negated two of the axes, based on the direction of the arrows in the diagram above, which are opposite the direction of positive rotation in Unity. But it's possible the diagram is not indicating the sign, and the arrow directions are just incidental.

Edit: apparently that is the case. Ignore the minus signs

Test this out, and if it's not behaving as expected, update your question with specific test cases, eg..

• When I orient the sensor like this [insert photo]

• The orientation I read is: (yaw: ####, pitch: ####, roll: ####)

• I transform that to the Unity Euler angles (x: ####, y: ####, z: ####)

• And the object looks like this in scene [insert screenshot]

• But I expect it to look like this [insert screenshot]

With a good sampling of such test cases, we should be able to identify where the mismatch arises.

• Will do, thank you so much!! Perhaps it will also make a good case for getting them to update their documentation as well :) – the_e Apr 14 '20 at 17:45
• It turns out that the negations weren't needed. That transform works perfectly (I was delaying a bit because I made my cube look a little bit more Pi-like to make sure I had orientations all set correctly). – the_e Apr 17 '20 at 13:20