On Thu, Oct 6, 2016 at 8:16 AM, Simon Wood <simon@xxxxxxxxxxxxx> wrote: > On Thu, October 6, 2016 8:27 am, Frank Praznik wrote: >> > >>> The motion sensor values are 16-bit, so make the value range match. >>> It is hard to reach the upper values, but they can be reached. At >>> least the current accelerometer value of 8192 is very easy to pass. >>> >>> >> >> Are the gyro values intended to be scaled in any way? The current >> min/max values were based on the observed maximum extents of the >> controller at rest. With this change the controller at rest will never >> appear to be turned more than 22.5 degrees in any direction to an >> application which assumes that the logical extents represent the device >> at 90 degrees. > > Don't forget that the _gyro_ values are a 'rate of turn' ie. 'degrees per > second'. > > Since we're asking questions, I'd love to know more about the time > stamping of the accel/gyro data as this could improve AHRS/Kalman > performance significantly. > > In the Move we get two sets of accel/gyro data, what's that about? > Simon > The 8192 value range was for the accelerometer, not the gyroscope. The accelerometer returns force or acceleration, while the gyro as Simon said gives degrees per second. I understand why someone at first glance would think it was a gyro, because it kind of gives an angle. What you see is just the constant offset from the force of gravity. When you rotate the device, it will just move to another axes. If you were to do some vector math, the combined vector should stay constant for slow movements (the gravitation offset should then be dominant over the dynamic data). You could use this to basically calibrate the device, if you normalize to this constant offset. If you really want to measure orientation, you need to look at the gyro which is the first 3 axes. However you need to integrate the values over time to get an angle. You could for example rotate the device, while collection values to get a sense of the value range. The total sum would equal 360 degrees. Again this is a kind of userspace type of calibration. There is a proper way to calibrate the device, but I can't share any on that right now. It needs more work to get additional sensor axes in evdev. It needs more than 16-bit precision (due to precision reasons related to multiplication and adding of an offset). I can't say anything about Move, because I'm not familiar with it and can't disclose anything. I would say pay close attention to the report data, what you want to know is probably hidden in there. -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
