Javascript 120Hz devicemotion events for high end inertial applications

[lukes3315]

Browsers only sample sensor data at a varying 67Hz (drops down to 1Hz sometimes), which makes the readings unusable for high end use cases...
We need a robust 120Hz steady sampling rate for our human inertial navigation technology. iOS and Android do have this natively, but apparently current browser technology does not offer the same quality as the native sampling... Sadly :(

[tobie]

Thanks for your input. This is addressed by the spec for sensors which support periodic reporting mode.

Which particular sensors would you need to poll at 120Hz?

Why 120Hz and not 1KHz or 67Hz?

What are you aiming to achieve with this? E.g. is this a latency issue, are you filtering the data and need a number of data points to do so? etc.

What are the precise use cases you're targeting?

Thanks for your input.

[lukes3315]

We would need:

• Accelerometer
• Gyroscope
• Magnetometer

And if possible:

• Barometer

Well 120Hz is sufficient granularity for our application. 67Hz is not granular enough, 1Khz, iOS and Android will not let you poll at such a high frequency. But if you want to have a sample rate of 1Khz that isn't an issue as long as it is adjustable.

We are working on an indoor location technology based on inertial navigation. The current issue is the inconsistency in the data points, for example:
Timing between samples seems to be inconsistent and inaccurate.

Check us out:
www.navisens.com

[tobie]

Thanks for this added information.

[tobie]

@lukes3315

I have a couple of options for this, please LMK which are acceptable.

1. polling at 120 Hz, getting roughly two data points together each time requestAnimationFrame is called?
2. polling at 120 Hz, getting only the latest data point when requestAnimationFrame is called (this is good for latency, not so much if you want all data point, e.g. for filtering)?
3. polling at 120Hz, receiving updates at 120Hz via event observers.

[tobie]

Expecting feedback from Navisens shortly, see: https://twitter.com/navisens/status/824627997797801985.

[lukes3315]

Hi Tobie,

We think there should be two acquisition methods supported:
1/ Polling sensor samples where you request 1 to N samples
which are then received at each polling loop
2/ Passing a callback function to receive 1 to N samples (preventing polling
for each individual sample).

Having the option to batch N samples would allow for a tradeoff between low latency
and greater efficiency depending on the application.

[lukes3315]

Please feel free to reach out if you need more information.

[tobie]

Thanks, @lukes3315.

What do you mean by "polling loop"? I'm also not sure what you mean by option 2 either. :-/

Maybe code examples or f2f would be helpful?

[tobie]

Had a meeting with Luke (@lukes3315) and Ash (@adonikian) of Navisens. Navisens does indoors positioning without touching the GPS, relying instead on motion sensors in users' mobile phones. It collects readings on the device an sends them to remote servers for analysis where it notably corrects for drift using machine learning.

Currently, Navisens is available as native apps. The current max sampling rate of the DeviceOrientation API (~60 Hz) isn't enough for their requirements.

They's ideally need 120 Hz, but could work with 100 Hz.

The sampling intervals need to be consistant. And it's critical that no samples are lost. [Ed: I'd love to understand more about about why that's important.]

Latency, on the other hand, is less an issue, as the readings as sent to a server for analysis anyway.

The kind of API they have in mind would allow them to set the size of the sample batch they want to work with and get an event every time the batch is full so they can send the data over to their servers for analysis.

[Ed: it would be useful to get a better understanding of the kind of analysis that's being done on the readings to justify the high sampling rates requirements and the necessity of not dropping samples and have an idea of the batch sizes.]