Brilliance and Poverty HTML5 - Access to Sensors
Recently I saw an article on Habré and was very surprised that it was generally located on a resource for IT specialists . But I was even more shocked by the fact that no one in the comments pointed out the obvious blunders described in that article. Habr, what happened to you? When did it all go wrong?
Eh you, pseudo-IT-specialists.
DeviceOrientationEvent - as the name implies, this is a device orientation change event. Not a DeviceCompassEvent, not a DeviceGiroscopeEvent, but a DeviceOrientationEvent.
Values for DeviceOrientationEvent are calculated by the browser (in practice, values are taken from the operating system) based on many parameters. Values are calculated based on data from the compass, gyroscope and accelerometer. But do a simple experiment. Put a smartphone (tablet and similar devices equipped with appropriate sensors) on the table, turn on any demonstration of the DeviceOrientationEvent and bring the magnet to the device. Obviously, the gyroscope and accelerometer do not change their readings since the device does not move, but when the magnet is moved, the demonstration program will react to this. This proves that the compass plays a dominant role in the formation of the values of the DeviceOrientationEvent (and perhaps in general it plays a crucial role, since the values of other sensors are not taken into account). Yes, I apologize, but I do not develop the OS and browsers and I do not know how these or other values are specifically formed. But having conducted such an experiment, we can assume that this is just data from a compass, without any processing (compassneedscalibration still hints at this).
')
And the data coming from the gyroscope and accelerometer can be obtained using DeviceMotionEvent. DeviceMotionEvent.acceleration and DeviceMotionEvent.accelerationIncludingGravity contain accelerometer data, and using DeviceMotionEvent.rotationRate you can get data from the gyroscope.
Unfortunately, such a confusion with the names of the sensors is only the tip of the iceberg, which makes it impossible to fully use the sensors. The underwater part of the iceberg is that it is not always possible to obtain exact data acquisition times. That is, the sensor itself makes measurements every 100 ms (conditional for example, since different sensors have their own times). Further API interferes (OS, browser, etc.) and introduces a random error in time. Thus, the program written by us receives data not every 100 ms, but 100 + n ms, where n is a random number. And while it is not possible to find out the real time of each measurement. Unfortunately, this circumstance did not give me the opportunity to create several applications related to indoor navigation (navigation inside buildings where GPS does not work) and correction of the values received from the GPS receiver.
Another example of the problem of the lack of exact time in the values obtained. Values from a GPS receiver also come with a random delay. At the same time, the GPS receiver knows and reports in its NMEA messages the exact time of each measurement, but after processing by several APIs this information is lost. Probably, the creators of these APIs limited the amount of information for the sake of simplification, but at the same time they unwittingly limited users. An example when this created many problems: forum.openstreetmap.org/viewtopic.php?id=31779
Also, the problem is that if there is no physical sensor, the event values will be zero and will not be updated. What if the device really lies on an ideally horizontal surface and does not move, or maybe the system just slows down and did not have time to send the necessary data yet?
I doubt that the creators of various APIs read this text, but I will still write my request to them: please make sure that you can receive raw data from sensors (nmea messages from a GPS receiver in particular) or at least receive exact times for each measurement. And the presence of the sensor, too, would somehow check.
And soon there will be (I still hope that there will be) modular devices (Project Ara, OpenBlocks, etc.). There will be much more different sensors, arrays of identical sensors will appear and the existing method of obtaining data on sensors and obtaining data from sensors will become not viable. But this is a topic entirely for another article.
Eh you, pseudo-IT-specialists.
DeviceOrientationEvent - as the name implies, this is a device orientation change event. Not a DeviceCompassEvent, not a DeviceGiroscopeEvent, but a DeviceOrientationEvent.
Values for DeviceOrientationEvent are calculated by the browser (in practice, values are taken from the operating system) based on many parameters. Values are calculated based on data from the compass, gyroscope and accelerometer. But do a simple experiment. Put a smartphone (tablet and similar devices equipped with appropriate sensors) on the table, turn on any demonstration of the DeviceOrientationEvent and bring the magnet to the device. Obviously, the gyroscope and accelerometer do not change their readings since the device does not move, but when the magnet is moved, the demonstration program will react to this. This proves that the compass plays a dominant role in the formation of the values of the DeviceOrientationEvent (and perhaps in general it plays a crucial role, since the values of other sensors are not taken into account). Yes, I apologize, but I do not develop the OS and browsers and I do not know how these or other values are specifically formed. But having conducted such an experiment, we can assume that this is just data from a compass, without any processing (compassneedscalibration still hints at this).
')
And the data coming from the gyroscope and accelerometer can be obtained using DeviceMotionEvent. DeviceMotionEvent.acceleration and DeviceMotionEvent.accelerationIncludingGravity contain accelerometer data, and using DeviceMotionEvent.rotationRate you can get data from the gyroscope.
Unfortunately, such a confusion with the names of the sensors is only the tip of the iceberg, which makes it impossible to fully use the sensors. The underwater part of the iceberg is that it is not always possible to obtain exact data acquisition times. That is, the sensor itself makes measurements every 100 ms (conditional for example, since different sensors have their own times). Further API interferes (OS, browser, etc.) and introduces a random error in time. Thus, the program written by us receives data not every 100 ms, but 100 + n ms, where n is a random number. And while it is not possible to find out the real time of each measurement. Unfortunately, this circumstance did not give me the opportunity to create several applications related to indoor navigation (navigation inside buildings where GPS does not work) and correction of the values received from the GPS receiver.
Another example of the problem of the lack of exact time in the values obtained. Values from a GPS receiver also come with a random delay. At the same time, the GPS receiver knows and reports in its NMEA messages the exact time of each measurement, but after processing by several APIs this information is lost. Probably, the creators of these APIs limited the amount of information for the sake of simplification, but at the same time they unwittingly limited users. An example when this created many problems: forum.openstreetmap.org/viewtopic.php?id=31779
Also, the problem is that if there is no physical sensor, the event values will be zero and will not be updated. What if the device really lies on an ideally horizontal surface and does not move, or maybe the system just slows down and did not have time to send the necessary data yet?
I doubt that the creators of various APIs read this text, but I will still write my request to them: please make sure that you can receive raw data from sensors (nmea messages from a GPS receiver in particular) or at least receive exact times for each measurement. And the presence of the sensor, too, would somehow check.
And soon there will be (I still hope that there will be) modular devices (Project Ara, OpenBlocks, etc.). There will be much more different sensors, arrays of identical sensors will appear and the existing method of obtaining data on sensors and obtaining data from sensors will become not viable. But this is a topic entirely for another article.
Source: https://habr.com/ru/post/269669/
All Articles