Недавно я увидел статью на Хабре и очень удивился, что она вообще находиться на ресурсе для IT-специалистов. Но ещё больше меня шокировало то, что никто в комментариях не указал на очевидные грубые ошибки описанные в той статье. Хабр, что с тобой случилось? Когда всё пошло не так?
Эх вы, горе-IT-специалисты.
DeviceOrientationEvent — как видно из названия, это событие изменения ориентации девайса. Не DeviceCompassEvent, не DeviceGiroscopeEvent, а именно DeviceOrientationEvent.
Значения для DeviceOrientationEvent вычисляются браузером (на практике — значения берутся у операционной системы) на основе многих параметров. Значения вычисляются на основе данных от компаса, гироскопа и акселерометра. Но проведите простой эксперимент. Положите смартфон (планшет и тому подобные устройства оборудованные соответствующими датчиками) на стол, включите любую демонстрацию работы DeviceOrientationEvent и поднесите к устройству магнит. Очевидно, что гироскоп и акселерометр не изменяют свои показания т. к. устройство не двигается, но при перемещении магнита демонстрационная программа будет реагировать на это. Это доказывает, что компас играет главенствующую роль в формировании значений DeviceOrientationEvent (а может и вообще — исключительную роль, т. к. значения других датчиков не учитываются). Да, прошу прощения, но я не разрабатываю ОС и браузеры и не знаю, как конкретно формируются те или иные значения. Но проведя такой эксперимент, можно предположить, что это просто данные с компаса, без какой либо обработки (compassneedscalibration ещё на это намекает).
А данные поступающие от гироскопа и акселерометра можно получить с помощью DeviceMotionEvent. DeviceMotionEvent.acceleration и DeviceMotionEvent.accelerationIncludingGravity содержат данные акселерометра, а с помощью DeviceMotionEvent.rotationRate можно получить данные от гироскопа.
К сожалению, такая путаница с названиями датчиков — это только вершина айсберга, не дающая возможности полноценно использовать датчики. Подводная часть айсберга в том, что не всегда возможно получить точные времена получения данных. Т. е. сам датчик делает измерения каждые 100 мс (условно для примера, т. к. разные датчики имеют свои времена). Дальше вмешивается API (ОС, браузер и т. к.) и вносит случайную погрешность во время. Таким образом написанная нами программа получает данные не каждые 100 мс, а 100+n мс где n — случайное число. И при этом нет возможности узнать реальное время каждого измерения. К сожалению, это обстоятельство не дало мне возможности создать несколько приложений связанных с indoor-навигацией (навигацией внутри зданий, где не работает GPS) и коррекцией значений получаемых от GPS приемника.
Ещё один пример проблемы отсутствия точного времени в получаемых значениях. Значения от GPS приемника так же приходят со случайной задержкой. При этом GPS приемник знает и сообщает в своих NMEA сообщениях точное время каждого измерения, но после обработки несколькими API эта информация теряется. Наверное, создатели этих API ограничивали количество информации с целью упрощения, но при этом они невольно ограничили пользователей. Пример, когда это создало много проблем: forum.openstreetmap.org/viewtopic.php?id=31779
Также проблем добавляет то, что при физическом отсутствии датчика, значения событий будут нулевыми и не будут обновляться. А вдруг устройство действительно лежит на идеально горизонтальной поверхности и не двигается, а может просто система тормозит и не успела пока прислать нужные данные?
Сомневаюсь, что создатели различных API читают этот текст, но все же напишу им свою просьбу: пожалуйста, сделайте так, чтобы можно было получать сырые данные с датчиков (nmea сообщения с GPS приемника в частности) или хотя бы получать точные времена каждого измерения. И наличие датчика тоже бы как-то проверять.
А ещё скоро появятся (я все ещё надеюсь, что появятся) модульные устройства (Project Ara, OpenBlocks и т. п.). Разных датчиков станет значительно больше, появятся массивы одинаковых датчиков и существующий способ получения данных о датчиках и получения данных с датчиков станет не жизнеспособен. Но это тема совсем для другой статьи.
Эх вы, горе-IT-специалисты.
DeviceOrientationEvent — как видно из названия, это событие изменения ориентации девайса. Не DeviceCompassEvent, не DeviceGiroscopeEvent, а именно DeviceOrientationEvent.
Значения для DeviceOrientationEvent вычисляются браузером (на практике — значения берутся у операционной системы) на основе многих параметров. Значения вычисляются на основе данных от компаса, гироскопа и акселерометра. Но проведите простой эксперимент. Положите смартфон (планшет и тому подобные устройства оборудованные соответствующими датчиками) на стол, включите любую демонстрацию работы DeviceOrientationEvent и поднесите к устройству магнит. Очевидно, что гироскоп и акселерометр не изменяют свои показания т. к. устройство не двигается, но при перемещении магнита демонстрационная программа будет реагировать на это. Это доказывает, что компас играет главенствующую роль в формировании значений DeviceOrientationEvent (а может и вообще — исключительную роль, т. к. значения других датчиков не учитываются). Да, прошу прощения, но я не разрабатываю ОС и браузеры и не знаю, как конкретно формируются те или иные значения. Но проведя такой эксперимент, можно предположить, что это просто данные с компаса, без какой либо обработки (compassneedscalibration ещё на это намекает).
А данные поступающие от гироскопа и акселерометра можно получить с помощью DeviceMotionEvent. DeviceMotionEvent.acceleration и DeviceMotionEvent.accelerationIncludingGravity содержат данные акселерометра, а с помощью DeviceMotionEvent.rotationRate можно получить данные от гироскопа.
К сожалению, такая путаница с названиями датчиков — это только вершина айсберга, не дающая возможности полноценно использовать датчики. Подводная часть айсберга в том, что не всегда возможно получить точные времена получения данных. Т. е. сам датчик делает измерения каждые 100 мс (условно для примера, т. к. разные датчики имеют свои времена). Дальше вмешивается API (ОС, браузер и т. к.) и вносит случайную погрешность во время. Таким образом написанная нами программа получает данные не каждые 100 мс, а 100+n мс где n — случайное число. И при этом нет возможности узнать реальное время каждого измерения. К сожалению, это обстоятельство не дало мне возможности создать несколько приложений связанных с indoor-навигацией (навигацией внутри зданий, где не работает GPS) и коррекцией значений получаемых от GPS приемника.
Ещё один пример проблемы отсутствия точного времени в получаемых значениях. Значения от GPS приемника так же приходят со случайной задержкой. При этом GPS приемник знает и сообщает в своих NMEA сообщениях точное время каждого измерения, но после обработки несколькими API эта информация теряется. Наверное, создатели этих API ограничивали количество информации с целью упрощения, но при этом они невольно ограничили пользователей. Пример, когда это создало много проблем: forum.openstreetmap.org/viewtopic.php?id=31779
Также проблем добавляет то, что при физическом отсутствии датчика, значения событий будут нулевыми и не будут обновляться. А вдруг устройство действительно лежит на идеально горизонтальной поверхности и не двигается, а может просто система тормозит и не успела пока прислать нужные данные?
Сомневаюсь, что создатели различных API читают этот текст, но все же напишу им свою просьбу: пожалуйста, сделайте так, чтобы можно было получать сырые данные с датчиков (nmea сообщения с GPS приемника в частности) или хотя бы получать точные времена каждого измерения. И наличие датчика тоже бы как-то проверять.
А ещё скоро появятся (я все ещё надеюсь, что появятся) модульные устройства (Project Ara, OpenBlocks и т. п.). Разных датчиков станет значительно больше, появятся массивы одинаковых датчиков и существующий способ получения данных о датчиках и получения данных с датчиков станет не жизнеспособен. Но это тема совсем для другой статьи.
