Re: Sensors API - Motion

Hi Filipe,

You can combine the values of multiple sensors quite easily, like I am
doing in https://sensor-compass.appspot.com/

You can add a "?filter=value" to the url: Any value from 0 to 1 uses
complementary filter with the value representing the trust of the
gyroscope. Thus 0 (or "a") will only use the accelerometer, 0.98 (or "c")
will use the default value for the complementary filter, and 1 (or "g")
will use the gyroscope alone. For the more precise Kalman filter use "k".

Combining these in software is of course not the most efficient way, but it
allows for creating new use-cases. There are plans to expose higher level
sensors (fusion sensors) at a later point, such as an orientation sensor
and a compass sensor, but we need to get the low level ones right first.

Cheers
Kenneth

On Mon, Nov 28, 2016 at 11:59 PM Menard, Alexis <alexis.menard@intel.com>
wrote:

> Hi,
>
> Well you have https://w3c.github.io/accelerometer/ and
> https://w3c.github.io/gyroscope/
>
> You can play with it already on Android today, I believe it should work on
> Tango. Grab the Chrome Canary on the Play Store, hits about://flags and
> enable the Generic Sensor flag. You can already play with the two above +
> ambient light sensor.
>
> Thanks.
>
> On Nov 28, 2016, at 2:52 PM, Felipe Nascimento de Moura <
> felipenmoura@gmail.com> wrote:
>
> Interesting Menard.
>
> I understand and agree with your points.
> So, it would indeed be better in a separated sensor API.
>
> What would you suggest for the names?
> Anyways, I got this cellphone with all the sensors for Tango, and can only
> play around with it using java (or unity) for now. I'm looking forward to
> seeing this API available on the web as soon as possible! I see a LOT of
> potential for that.
>
> Thanks.
>
>
> On Mon, Nov 28, 2016 at 8:18 PM, Menard, Alexis <alexis.menard@intel.com>
> wrote:
>
> Hi,
>
> This doesn’t sound like a great idea IMHO. Native APIs have them separated
> and I think it’s for a great reason. They provide different type of data
> which may or may not be useful together depending on what you try to
> achieve. You have devices not shipping without an Accelerometer (yet they
> provide you orientation events with some other way) so that means that the
> API would look broken in some way. What I should return as a property value
> when I can’t get it from the given sensor : 0 which is semantically
> incorrect (you can have 0 x, y acceleration value for example).
>
> As an implementation point of view it seems inefficient to pull the data
> from the accelerometer if nobody uses what you call translateX, Y, Z. This
> has impact on battery life for example. The naming also gives me issue,
> accelerometer values doesn’t stick with Orientation IMHO, especially when
> writing a game and using the motion sensors as controllers.
>
> Thanks.
>
> On Nov 23, 2016, at 7:56 PM, Felipe Nascimento de Moura <
> felipenmoura@gmail.com> wrote:
>
> Hello.
>
> I have two things to discuss about the Sensors API. (will send them in two
> different e-mails).
> Here goes the first:
>
> *Motion capabilities*
> I've tested and played around with Tango Project from Google, and it is
> quite impressive, very accurate and so far, very reliable.
> They are focused on Java and Unity and I was talking to them about a move
> for the Web. It is in their roadmap...but there is nothing defined up to
> now.
> My suggestion is (as simple as possible):
>
> `simply add motion to Device Orientation API`
>
> This way:
> window.addEventListener("deviceorientation", handleOrientation, true);
>
> Would provide us an object with:
> - absolute (for orientation),
> - alpha, beta, gamma (for rotation),
> - translateX, translateY, translateZ (for movement/navigation)
>
> I believe that, with that addition (from devices that do have support for
> those sensors) Web Developers would already have enough power to create A
> TON of things involving WebGL, Canvas, SVG and even regular HTML pages and
> CSS.
>
> Note that *translate(X/Y/Z)* would be relative to the position in the
> starting point (set as 0, as soon as the page becomes interactive).
> They would be expressed in *inches*.
> Values for *translateZ* are positives when motion is toward the backface
> of the device (in its starting point).
> Values for *translateY* are negative when moving down and positive when
> moving up (in relation to its starting point).
> Values for *translateX* are negative when moving left and positive when
> moving right (in relation to its starting point).
>
> I'm not sure how far have the discussions gone by now, about these new
> sensors, but I think we should be ready for them (as they are, actually,
> already here in some devices).
> As this platforms and tools evolve, I see a web API approach as something
> fundamental.
>
> I see implications for this in devices like watches, glasses, cellphones
> and tablets in a very near future.
>
> Please let me hear your thoughts about it.
> Thanks.
>
> *--*
>
> *Felipe N. Moura*
> Web Developer, Google Developer Expert, Founder of BrazilJS
> <https://braziljs.org/> and CTO at Nasc <http://nasc.io/>.
>
> Website:  http://felipenmoura.com / http://nasc.io/
> Twitter:    @felipenmoura <http://twitter.com/felipenmoura>
> Facebook: http://fb.com/felipenmoura
> LinkedIn: http://goo.gl/qGmq
> ---------------------------------
> *Changing  the  world*  is the least I expect from  myself!
>
>
>
>
>
> --
> [ ]s
>
> *--*
>
> *Felipe N. Moura*
> Web Developer, Google Developer Expert
> <https://developers.google.com/experts/people/felipe-moura>, Founder of
> BrazilJS <https://braziljs.org/> and Nasc <http://nasc.io/>.
>
> Website:  http://felipenmoura.com / http://nasc.io/
> Twitter:    @felipenmoura <http://twitter.com/felipenmoura>
> Facebook: http://fb.com/felipenmoura
> LinkedIn: http://goo.gl/qGmq
> ---------------------------------
> *Changing  the  world*  is the least I expect from  myself!
>
>