Недавно я увидел статью на Хабре и очень удивился, что она вообще находиться на ресурсе для 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 и т. п.). Разных датчиков станет значительно больше, появятся массивы одинаковых датчиков и существующий способ получения данных о датчиках и получения данных с датчиков станет не жизнеспособен. Но это тема совсем для другой статьи.

Комментарии (16)


  1. Naissur
    28.10.2015 11:34
    +1

    Ещё один пример проблемы отсутствия точного времени в получаемых значениях.

    Это сделано в целях безопасности. Например, Philips проводили эксперимент с Ambient Light Events — в торговом центре установили источники освещения, варьирующие интенсивность света по определенённым паттернам (на частотах, не различаемых людьми) в разных залах. Для определения своего местоположения пользователи могли воспользоваться приложением, которое использовало точные значения датчика освещённости.

    www.youtube.com/watch?v=zvG97aOfAJM — интересная лекция на тему сенсоров в целом.


    1. Etrorini
      29.10.2015 00:13

      Надеюсь, вы говорите о технологии Li-Fi. В ней используются относительно высокие частоты. В моем планшете (не думаю, что в других кардинально по другому) частота данных от датчиков составляет всего 10 Гц (+-5 Гц колебания вносимые системой в случае если система не занята другими расчетами). Т. е. если бы были метки времени, то можно передать 5 байт в секунду, а без меток — ну раза в 2 меньше. Что в обоих случаях очень мало и что не мешает использовать такой способ передачи данных. И цели безопасности не объясняют отсутствие меток в данных GPS приемника.


  1. tangro
    28.10.2015 11:52
    +7

    Хабр, что с тобой случилось? Когда всё пошло не так?

    В момент разделения Хабра на Хабр и Гиктаймс. Количество глаз, просматривающих статью упало в разы и, соответственно, количество обнаружаемых ошибок тоже. 2 года назад мне к опубликованной статье приходило по десять приватных сообщений об ошибках в коде и тексте, я их исправлял. Сегодня — одно-два, а чаще всего вообще не приходят. В итоге имеет существенное падения качества статей.


    1. Ivan_83
      28.10.2015 12:35
      +3

      Может у тебя ошибок меньше стало?)

      Дело не в разделении хубра на 2, 3… а в том, что писать тут ради палок не интересно.
      Сейчас система устроена так, что если хочешь тут комментировать то нужна карма, а карму можно получить только за публикации, а публикации это труд, который не плохо бы оплачивать реальными деньгами.
      Но раз деньгами не платят, а только бусами, то создаётся ощущение что это проявление не уважения: работай чтобы иметь право высказаться.

      У хубра есть внутренний план на желаемое количество публикаций в сутки, чтобы ресурс не превращался в болото окончательно, сейчас он добивается за счёт платных блогов и вытаскивания лучшего из худшего из песочницы и всяких переводов/перепостов новостей.


      1. coocheenin
        28.10.2015 13:00
        -2

        Писать за деньги? По-моему, вы ошиблись сайтом.


        1. DrPass
          28.10.2015 14:05
          +2

          И тем не менее, это не мешает Хабру быть не общественным проектом а-ля Википедия, а вполне себе коммерческим. Я не говорю, что это плохо или хорошо, это абсолютно нормальная схема монетизации. Кто-то покупает за реальные деньги крохотные пиктограммки в социальной сети. Кто-то тратит своё время на то, чтобы поднять себе числовой параметр на сайте, отдав владельцу сайта свою вполне реальную работу. Кто-то не думает про этот числовой параметр, а просто хочет поделиться с широкой аудиторией своим материалом.


      1. aktuba
        28.10.2015 13:34
        +1

        Эмм… Так есть-же ППА (http://habrahabr.ru/ppa/).


        1. Aingis
          28.10.2015 13:51
          +2

          Во-первых, не всем доступно. Случайная блокировка — и прощай ППА. Во-вторых, это такие смешные копейки, что только унижает пишущего.


        1. BubaVV
          28.10.2015 15:16

          И очень заметная часть контента, пригодного доля ППА, переползла на Гиктаймс


      1. tangro
        28.10.2015 20:58

        Может у тебя ошибок меньше стало?)

        Нет, я даже специально делал чтобы проверить или найдутся. Ну, опечатку в «ться» могут заметить, но ошибки в коде — уже нет. А было время.


    1. igordata
      28.10.2015 14:23
      +9

      Гиктаймс так вообще превратился в агрегатор новостей, который не смотря на XXI век на дворе, работает вручную усилиями авторов, которые имитируют человеков, пишущих статьи.

      Я знаю людей, которые ничего не пишут только потому, что не хотят нахватать минуса в свою нулевую карму, ибо минусуют сейчас просто по несогласию, и без всякой аргументации. А те, кто аргументируют — не минусуют. А те, кто согласен — просто кивают и проходят мимо, ибо с их точки зрения не о чем говорить. Получается, несогласные тыкают в карму, чем согласные. А расширение аудитории с занижением планки приводит к тому, что на ресурсе тусят люди, которым сложное — сложно, а непонятное — не понятно. Зато просто и понятно читать новости. При этом мнение они имеют.

      В итоге карму активно плюсуют за перепост новостей (за перепост новости плюсуют карму, Карл!), а переводы — жутко напряжная вещь, которая даёт меньше плюсов, чем новости в расчёте на трудозатраты. За новости вообще не минусуют, ибо это ж просто новости, правда.

      Кроме всего прочего плюсы получают статьи, объясняющие прописные истины, или просто констатирующие некие факты. Эти статьи понятны широкой аудитории, и соотв. получают плюсов больше, чем непонятные, и рассчитанные на специалистов. В результате, засилие слабой аудитории, для которой обращение к некоему методу js уже тянет на статью.

      Отлично, что в итоге? — Агрегатор новостей, наполняемый вручную людьми, которые эмулируют деятельность людей, которые когда-то постили статьи.

      Ну хрен знает…

      А на Гиктаймс я например не могу писать в принципе, у меня там минусовая карма, и я не могу выбрать в какой хаб постить хотя бы ту же новость — мне нельзя с отрицательной кармой. =) В итоге я не пишу ничего, а только комментирую, а одну новость размером в два абзаца я притащил на Хабр именно потому, что туда я её запостить не мог, и не поделиться ей тоже не мог.

      Т.е. на ГТ я ничего не могу, и не пишу про свой компик под HTPC, собранный из десктопных компонентов, без ноутбучных всяких усечённых штук, но при этом малюсенький и без единого вентилятора, т.е. без шума без пыли. Управляется пультом. Я перепробовал штук шесть-семь различных пультов. Хочу об этом написать. Хочу года три уже. Но не пишу. Это же не Хабровый формат, где я комп собрал ( о боже поглядите, он комп собрал из деталек ). А на ГТ я писать не могу и не хочу даже. Я пользуюсь медиацентром на три харда, который не видно не слышно, и мог бы написать о том, какой пульт чем хорош. А есть ещё страшно признаться, bat-файл которым я удобно до жути копирую фотки с фотика. Но я боюсь и стесняюсь обо всей этой лабуде писать. Это же такие простые вещи. Но такие удобные. При этом на ГТ для меня и этого моего барахла дорога закрыта на веки вечные.

      Ну да хрен с ним с компом. У меня не великие знания, и делиться особо нечем. Но повторюсь, есть же и другие люди, которые просто молчат, потому что не любят негативный отклик.

      Ладно. Хватит ныть. Пора работать. Всем хорошего дня.


      1. ivanych
        28.10.2015 21:01
        +1

        С языка сняли.


      1. anatolikus
        29.10.2015 04:23

        А я бы с удовольствием почитал про компик.


        1. igordata
          29.10.2015 19:32
          +1

          Соберу волю в кулак и запилю.


    1. Etrorini
      28.10.2015 22:54

      Мне целых 4 пришло.

      Все ошибки исправлены.


  1. HomoLuden
    29.10.2015 17:39

    Это доказывает, что компас играет главенствующую роль в формировании значений DeviceOrientationEvent (а может и вообще — исключительную роль, т. к. значения других датчиков не учитываются). Да, прошу прощения, но я не разрабатываю ОС и браузеры и не знаю, как конкретно формируются те или иные значения. Но проведя такой эксперимент, можно предположить, что это просто данные с компаса, без какой либо обработки (compassneedscalibration ещё на это намекает).


    С ориентацией ситуация такова:
    1. Компас является «Датчиком Первичной Информации» для ориентации (в горизонтальной плоскости). Это означает, что он сразу измеряет углы ориентации. Есть погрешность, но она не накапливается, т.к. измерения компаса не интегрируются.
    2. Гироскоп и акселерометр выдают, соответственно, скорость и ускорение. Они не являются ДПИ для ориентации* (звездочка в следующем пункте). Их показания интегрируются для получения угловых и линейных координат. Стало быть, накапливают ошибки.
    3. По акселерометру определяются тангаж и крен, т.е. углы в двух вертикальных плоскостях и в этом смысле акселерометр является ДПИ.
    4. Из вышенаписанного следует, что компас будет играть главенствующую роль, пока некий алгоритм не детектирует аппаратный сбой компаса. Например, если задетектировали наличие значительного магнитного возмущения (магнитуда напряженности или еще как-то), то можно присвоить компасу низкий приоритет. Но это усложнение используется лишь в специальных реализациях (для БПЛА, напр.).