W3C home > Mailing lists > Public > public-device-apis-log@w3.org > July 2019

Re: [sensors] Allowing data batching when poll frequency < sensor frequency (#13)

From: Rob Manson via GitHub <sysbot+gh@w3.org>
Date: Tue, 30 Jul 2019 03:13:57 +0000
To: public-device-apis-log@w3.org
Message-ID: <issue_comment.created-516242982-1564456436-sysbot+gh@w3.org>
Heya - I can see this has been added as a Level 2 issue and just wondering if there's any progress on this?

It seems like all these issues are related to this issue (#13) :
- #98 
- #89 
- #63 
- #42 

And possibly:
- #12 
- #106

Unfortunately the periodic (monotonic) feature/discussion that @tobie referred to in #98 seems to have disappeared - https://github.com/w3c/sensors/issues/98#issuecomment-206515815

There's quite a few use cases that would benefit from having access to the full data set of readings provided by the Accelerometer. But at the moment extra load on the main browser thread (e.g. 3D rendering) can block `onreading()` updates and once they're gone there's no way to recover the lost readings at all.

One well known use case where the full set of readings is important is for inertial navigation style algorithms (as discussed in #98). @tobie you asked a couple of questions in this comment https://github.com/w3c/sensors/issues/98#issuecomment-279981550
```
The sampling intervals need to be consistent. And it's critical that no samples are lost. 
[Ed: I'd love to understand more about about why that's important.]
```
and
```
[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.]
```

For Inertial Navigation, SLAM/VIO and a range of other use cases the accelerometer data readings are integrated so their values add up over time to update the current velocity which is then combined with the time slice to define a motion vector. Happy to provide pointers to algorithms here if you want more detail.

This approach has it's own problems because it's a double integral so it's well known that over time errors build up and drift can become a major issue. 

There are a lot of ways to work around this double integral problem, but if you don't have all of the readings because some are just missing then this approach is not usable at all.

All of the discussions in the issues I listed above kinda dance around this point - but none seem to have completely covered it 8)

It would be great to hear if there has been any recent movement on any of this?

-- 
GitHub Notification of comment by robman
Please view or discuss this issue at https://github.com/w3c/sensors/issues/13#issuecomment-516242982 using your GitHub account
Received on Tuesday, 30 July 2019 03:14:00 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 30 July 2019 03:14:00 UTC