-
Notifications
You must be signed in to change notification settings - Fork 59
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Should unit option's behavior be defined in the Generic Sensor API? #62
Comments
I see the following three buckets:
Specifically related to device orientation, based on what I see in the awesome Device Orientation API article by @richtr a conversion is possible between various representations assuming the platform provides an extra bit of information that the So I guess my conclusion is we should define a default unit for each concrete sensor and also raise an error if the unit required is not supported. The latter behaviour should be defined in the Generic Sensor API spec. Can we learn something from Johnny-Five or other platforms -- how they're handling the third case where the platform may not support all the unit options? |
Accelerometer
Barometer
Button
Color (WIP)
Compass
{
point: "NorthEast by East",
abbr: "NEbE",
low: 50.63,
mid: 56.25,
high: 61.87,
heading: ...same as present heading
}
Encoder (WIP)
Gyroscope
JoystickThis only represents a single "stick", not to be confused with a gamepad.
Light (WIP)
MotionThis is not for detecting the device's own motion, it detects external environment
Proximity
SensorGeneric, works with any analog or digital sensor.
Temperature
* Gyroscope had an unfortunate early design mistake, that forced us to put the x, y, z rates in their own property. This will be fixed for eventual 1.0 release (by replacing the present ** Joystick directions can be inverted at initialization with a constructor option object property: *** Both the full name and abbreviation are exposed to (hopefully) cater to intuition.
No such problem exists. All sensors of a "kind" (accelerometer, barometer, compass, etc) produce at least the minimum required data. Using that data, we compute the rest, eg. an accelerometer is only going to produce x, y, z (if available) measurements in g-force values, so we compute the other property's values from that value. Similarly, most temperature sensors only produce a value in celsius, so the F and K are always computed from C. Back to platforms... A platform can either interface with a sensor, or it cannot; specifically, if a sensor interface is I2C, then it works with platforms that have I2C support—otherwise it simply does not. Ideally, Johnny-Five supports enough commercially available models of a "kind" to make it easy to swap between them based on the platform's capabilities. |
Typical example is of course Fahrenheit vs. Celsius degrees, but it becomes more interesting with more complex examples such as quarterions, rotational matrices or Tait-Bryan angles for device orientation.
If we were to specify a behavior in the the generic spec, I'd imagine each implementation of the spec would need to define a default unit. Constructing the sensor object would raise an error if the required unit was not available.
The text was updated successfully, but these errors were encountered: