- From: Kenneth Rohde Christiansen <kenneth.christiansen@gmail.com>
- Date: Thu, 09 Mar 2017 12:25:04 +0000
- To: tobie@sensors.codespeaks.com, public-device-apis@w3.org
- Message-ID: <CAEC208tyHS+-Xo6dLYesV2=dHWYpX9o_u_UgEwwnx0JoD-u9dw@mail.gmail.com>
Hi there, I gave it a shot and wrote an explainer doc to the motion sensor subject, thus an introduction to low-level and high-level motion sensors, their relation, inner workings and common use-cases. I attached it to this email, so if it doesn't get through for some reason, please tell me. Cheers Kenneth On Tue, Mar 7, 2017 at 12:59 PM Kenneth Rohde Christiansen < kenneth.christiansen@gmail.com> wrote: > Having looked into the problem domain for a while now, I agree. There are > no real good resources or books explaining how all these sensors work > together, it is all very thinly spread out, with some mention to low and > high pass filters, Kalman, complementary filter etc here and there. I even > reached out to some of the Android experts who have written about this > before and their knowledge seemed superficial at best. > > Having written code doing actual fusion, I now have a much better > understanding, but this has taken quite a while and most developers don't > have the luxury and time to dig so deep into that area as I have done. > > I think that a well written introductory part would be very beneficial and > the information would cascade down into articles written around the > subject, and that will benefit the web community (though not limited to) as > a whole. > > I will happily help Tobie with this, and I also think it makes a lot of > sense having all the motion sensors in one spec. > > Cheers > Kenneth > > > On Tue, Mar 7, 2017 at 12:15 PM Tobie Langel <tobie@sensors.codespeaks.com> > wrote: > > > My thinking is we have two distinct audiences at play here with their own > > preferences and requirements: > > > > * Browser implementers > > * Web developers > > > > Catering to both the audiences extensively in the same document may not > > work out (history lesson, but I'd be happy to be proven wrong). > > Both audiences seem to completely lack domain expertise, so I think this > should prove highly beneficial to all involved, myself included. :) > > The feedback for the introductory part to the generic sensor spec was > quite positive, so I'm willing to give this a try and fold it out into > an explainer doc if necessary. > > > The concrete specs at https://www.w3.org/2009/dap/#sensors are geared > > toward browser implements. They're concise, assume certain level of > > domain expertise. Granted, they're not good references for web developers > > or to be used as learning resources. > > > > Couple of ideas: > > > > * Start an explainer document for Motion Sensors (or "Motion Sensors for > > Web Developers" document) that bring together all the informative content > > in a form digestible to web developers. This doc would inform the > > normative spec work (because of Priority of Constituencies). > > > > * Produce (semi-automatically) "Sensors Snapshot" document similar to > > https://www.w3.org/TR/css-2017/ updated as new concrete sensors emerge. > > > > This would allow us make progress on the Rec Track on more mature > > concrete sensors as we keep adding new high-level motion sensors in the > > future. > > I think the explainer doc is only a very small part of the reason why > having these specs defined together is important. And these reasons > still stand whether or not the explainer part is spec-contained. > > If the only concern with this approach is W3C process, we can figure out > ways around that as needed, but we certainly shouldn't let that dictate > how and what we deliver. In the priority of constituencies, editors are > at the bottom of the pile. So is the process by which they get > organized. > > --tobie > >
Attachments
- text/html attachment: explainer.html
Received on Thursday, 9 March 2017 12:25:49 UTC