Комментарии 55
Некорректно сравнивать wifi позиционирование с GPS, то есть, фактически indoor с outdoor.
Корректнее сравнить с iBeacon-based (BLE) a еще лучше с гибридами, типа Mpact.
Корректнее сравнить с iBeacon-based (BLE) a еще лучше с гибридами, типа Mpact.
Спасибо за комментарий.
Согласен, что позиционирование в indoor и outdoor — это большая разница, есть много своей специфики.
Идея была больше не сравнить, а скорее провести аналогии с GPS, так как и там и там в основе используется трилатерация, а с GPS многие хорошо знакомы.
BLE постараюсь рассмотреть после HALO.
Так как я специалист по Wi-Fi, а не по позиционированию в целом, с радостью выслушаю все замечания к тексту.
Согласен, что позиционирование в indoor и outdoor — это большая разница, есть много своей специфики.
Идея была больше не сравнить, а скорее провести аналогии с GPS, так как и там и там в основе используется трилатерация, а с GPS многие хорошо знакомы.
BLE постараюсь рассмотреть после HALO.
Так как я специалист по Wi-Fi, а не по позиционированию в целом, с радостью выслушаю все замечания к тексту.
Отлично. Вы изучали уже существующие исследования в этой области? (не вижу никаких ссылок)
например, вы смотрели вот эту статью — http://injoit.org/index.php/j1/article/download/15/9
например, вы смотрели вот эту статью — http://injoit.org/index.php/j1/article/download/15/9
Основной опыт — это реализованные проекты по Wi-Fi (а так же систем wIPS) с сервисом позиционирования, которые, конечно, были сделаны в соответствии с материалами производителей ( у Cisco, к примеру, достаточно хорошие материалы по позиционированию). Так же на данный момент у меня развернут стенд в том числе с HALO модулями, поэтому все предположения стараюсь воспроизводить и проверять на стенде. Плюс к этому тут чуть-чуть добавлено физики распространения сигнала.
В следующей статье постараюсь исправить упущение и укажу источники информации, возможно опишу стенд.
С этой статьёй не знаком, почитаю, спасибо.
В следующей статье постараюсь исправить упущение и укажу источники информации, возможно опишу стенд.
С этой статьёй не знаком, почитаю, спасибо.
Ваша ссылка имеет довольно косвенное отношение к теме и опубликована в сомнительном молодом журнале национального масштаба.
Для расширения кругозора и систематизации знаний лучше почитать обзор вроде этого.
Для расширения кругозора и систематизации знаний лучше почитать обзор вроде этого.
это то что у меня выдал google по запросу «Wi-Fi Proximity»
я для поиска научных статей пользуюсь google scholar, присутствия публикации в ieee каталогах (xplore например) лично для меня, как и большинства других исследователей, более чем достаточно. Если у вас есть время проверять каждый источник на масштаб и возраст, могу этому только позавидовать.
oпубликована в сомнительном молодом журнале национального масштаба
я для поиска научных статей пользуюсь google scholar, присутствия публикации в ieee каталогах (xplore например) лично для меня, как и большинства других исследователей, более чем достаточно. Если у вас есть время проверять каждый источник на масштаб и возраст, могу этому только позавидовать.
присутствия публикации в ieee каталогах (xplore например) лично для меня, как и большинства других исследователей, более чем достаточноИмея прямое отношение к «другим исследователям», я бы не рискнул говорить за большинство…
Если у вас есть время проверять каждый источник на масштаб и возраст, могу этому только позавидовать.Как Вам наверняка известно, знание ключевых конференций и журналов в своей области — один из непосредственных результатов обучения в аспирантуре. Учёный, работающий в определённой теме, как правило может оценить качество той или иной статьи просто по названию журнала/конференции. Эта способность вырабатывается годами, но в конечном итоге сильно экономит время.
Я никогда не слыхал про International Journal of Open Information Technologies, поэтому и решил проверить — тем более, что Вы сослались на конкретную статью как обязательную к изучению. Как оказалось, это открытый журнал национального масштаба, про который не знают ни IEEE, ни ACM, ни Springer, ни даже Elsevier. Отношения к мировой науке он имеет очень мало, поэтому вряд ли имеет смысл тратить время на его чтение, и уж тем более цитирование.
я бы не рискнул говорить за большинство…
извините, имел в виду свой круг, а не исследователей вообще.
не знают ни IEEE, ни ACM, ни Springer, ни даже Elsevier.
тоже, кстати, не показатель. в перечисленных вами изданиях тоже иногда откровенная ерунда.
смысл тратить время на его чтение, и уж тем более цитирование.
ваше право, но ценный материал иногда может оказаться где угодно, на каком-либо форуме, или на хабре… я думаю ориентироваться надо на контент а не на статус издания
Вы правы, и у именитых издателей встречается ерунда, и на хабре встречаются жемчужины знаний.
я думаю ориентироваться надо на контент а не на статус изданияТем, у кого есть время штудировать все-все-все публикации по теме я могу только позавидовать :)
Тем, у кого есть время штудировать все-все-все публикации по теме я могу только позавидовать :)
:)
скажем так, «все-все-все» изучать все таки иногда приходится — в случае если надо доказать novelty.
например если планируется статья про супер-пупер изобретение, а про него уже кто-то написал (неважно где, даже не в крутом издании)
Не берусь оценивать предыдущую ссылку, но за вашу ссылку спасибо. Статья интересная и обстоятельная, обязательно прочитаю!
провести аналогии с GPS, так как и там и там в основе используется трилатерацияСтрого говоря, аналогию между GPS и Wi-Fi позиционированием проводить нельзя, потому что в их основе лежат фундаментально разные принципыЖ GPS оценивает расстояния используя время распространения сигнала, тогда как описанный в посте метод для Wi-Fi оценивает расстояния по силе сигнала. В физической модели затухания сигнала (FSPL) куча параметров, которые вовсе не константы и зависят от кучи нюансов, начиная от количества и материала стен и потолков, и заканчивая температурой и влажностью воздуха — собственно, Wi-Fi позиционирование не взлетает во многом из-за этого.
Да, наверно не стоило ссылаться на GPS. Хоть они и используют трилатерацию, формула расчета расстояния действительно кардинально разные. Если в GPS время распространения сигнала всегда постоянная и формула получается линейная, то в Wi-Fi сила сигнала уменьшается нелинейно и зависимость квадратичная. То есть увеличение расстояний на точность GPS позиционирования не влияет, а вот на точность Wi-Fi позиционирования влияет очень сильно.
Согласен про наличии большого числа нюансов в физической модели затухания сигнала, постарался какую-то часть их как раз описать. Хотел бы еще добавить, что еще очень сильно влияет большое количество переотражений сигнала в помещении (чего почти нет на улице). А так же речь идет про смартфоны, то влияет сам человек, который держит телефон в то в левом заднем кармане, то в правом переднем, в руке, у левого/правого уха, что на местоположение сматрфона не влияет, а показания на точках меняться могут кардинально.
Согласен про наличии большого числа нюансов в физической модели затухания сигнала, постарался какую-то часть их как раз описать. Хотел бы еще добавить, что еще очень сильно влияет большое количество переотражений сигнала в помещении (чего почти нет на улице). А так же речь идет про смартфоны, то влияет сам человек, который держит телефон в то в левом заднем кармане, то в правом переднем, в руке, у левого/правого уха, что на местоположение сматрфона не влияет, а показания на точках меняться могут кардинально.
Я не очень верю в применимость BLE. Это всё требует создания и установки приложения, а кто из абонентов его будет ставить в проходных местах вроде ТРЦ? Остается узкая ниша складов, где работники ходят с корпоративными устройствами.
Я тоже думал над этим. Шанс имеют те, чьи приложения уже стоят на смартфонах.
1. Банк «Тинькофф». У многих есть мобильное приложение данного банка. Только есть одна незадача — отделений у банка нет! А так заходишь в ТРЦ, проходишь мимо отделения банка, а тут тебе предложение заманчивое от банка!
2. Какие-то известные приложения должны запартнерится с известными сетями. К примеру фейсбук с икеей (ашаном). Приложение фейсбука стоит у всех. Все ездят в икею(ашан). Заходишь в икею (ашан)- и тут тебе сразу предложения на смартфон!
Такие вот мысли…
А отдельное приложение писать, которое потом еще надо скачивать, это конечно малореальный сценарий…
1. Банк «Тинькофф». У многих есть мобильное приложение данного банка. Только есть одна незадача — отделений у банка нет! А так заходишь в ТРЦ, проходишь мимо отделения банка, а тут тебе предложение заманчивое от банка!
2. Какие-то известные приложения должны запартнерится с известными сетями. К примеру фейсбук с икеей (ашаном). Приложение фейсбука стоит у всех. Все ездят в икею(ашан). Заходишь в икею (ашан)- и тут тебе сразу предложения на смартфон!
Такие вот мысли…
А отдельное приложение писать, которое потом еще надо скачивать, это конечно малореальный сценарий…
Google разработал свой аналог iBeacon, eddystone, где в качестве id передается сразу URL- то есть приложение будет использоваться стандартное — обычный браузер. Не удивлюсь если в одной из следующих версий Android функция распознавания вещания eddystone будет стандартной системной фичей. Другое дело, что для этого все еще нужно держать включенным Bluetooth — я вот по привычке его всегда отключаю, хотя и знаю что BLE батарею особо не жрет. Wifi же включен почти всегда.
Не думаю, что FSPL — корректная модель. У той же Cisco в Prime вы рисуете карту, расставляете «стены» из разных материалов, учитываете материал межэтажных перекрытий и так далее. А дальше MSE, получая сырые данные от контроллера (МАС точки и клиента, уровни сигнала и шума), упорно занимается расчетами и другой хитрой математикой. Не даром там внутри полно кода, написанного на матлабе(!), можете сами разобрать и посмотреть.
Спасибо за комментарий. Не вижу противоречий между моими словами и вашими.
Я не говорю, что MSE считает именно по этой формуле. Но в основе своей, конечно, имеет именно её ( логарифмическую составляющую).
Каждая стена, прорисованная на карте Prime имеет определенное затухание в dB (конкретное значение есть в документации), эти данные добавляются в формулу.
Так же при создании карты выбирается RF Model (Walled Office, Drywall office, Outdoor Open Space...), я полагаю, другими словами это определенный коэффициент, который так же добавляется в формулу FSPL.
Насколько я помню, Prime учитывает высоту потолков (высоту подвеса точки), но не материал межэтажных перекрытий, так как планы этажей там плоские (по крайней мере в версиях до 3.0), а не объемные.
Я не говорю, что MSE считает именно по этой формуле. Но в основе своей, конечно, имеет именно её ( логарифмическую составляющую).
Каждая стена, прорисованная на карте Prime имеет определенное затухание в dB (конкретное значение есть в документации), эти данные добавляются в формулу.
Так же при создании карты выбирается RF Model (Walled Office, Drywall office, Outdoor Open Space...), я полагаю, другими словами это определенный коэффициент, который так же добавляется в формулу FSPL.
Насколько я помню, Prime учитывает высоту потолков (высоту подвеса точки), но не материал межэтажных перекрытий, так как планы этажей там плоские (по крайней мере в версиях до 3.0), а не объемные.
Я к тому, что скорее всего там не просто формула, где добавляются dB в FSPL, а мегабайты аналитического кода со сложной математикой, которые они там развивают уже лет 10 как.
Да, это интересно. Но опять же, в любом случае, независимо от кода, погрешность с увеличением затухания стремительно увеличивается.
У меня коллеги разрабатывают RTLS как раз (на основе zegbee), если получится, я поговорю с программистами, что у них там в коде…
У меня коллеги разрабатывают RTLS как раз (на основе zegbee), если получится, я поговорю с программистами, что у них там в коде…
и независимо от кода все описанные проблемы имеют место быть
> Сигнал затухает не с линейной, а с логарифмической зависимостью.
Не с линейной, но и не с логарифмической. Представьте себе фронт волны. Это расширяющаяся сфера с центром там, где антенна. Сигнал размазывается по этой сфере. Площадь сферы пропорциональна квадрату радиуса. Принимающая антенна может выхватить из этой сферы кусок постоянной площади, то есть полученный сигнал в первом приближении обратно пропорционален квадрату расстояния.
Не с линейной, но и не с логарифмической. Представьте себе фронт волны. Это расширяющаяся сфера с центром там, где антенна. Сигнал размазывается по этой сфере. Площадь сферы пропорциональна квадрату радиуса. Принимающая антенна может выхватить из этой сферы кусок постоянной площади, то есть полученный сигнал в первом приближении обратно пропорционален квадрату расстояния.
Я думаю, что вы говорите, скорее про EIRP — эффективную изотропную излучаемую мощность, внутри этой формулы как раз есть коэффициент усиления антенны, который определяет, как рассеивается сигнал. Вы конкретно говорите о абсолютном изотропном излучателе.
А FPSL — это уже о затухании конкретной волны в определенном направлении. Собственно формула FSPL явно говорит о логарифмической зависимости.
https://en.wikipedia.org/wiki/Free-space_path_loss
FSPL = 32.4 + (20log10(2,400)) + (20log10(x))
Как я писал, чтобы вычислить конкретный уровень сигнала, нужно рассчитать EIRP ( который содержит коэффициент усиления антенны) и вычесть из него FSPL
А FPSL — это уже о затухании конкретной волны в определенном направлении. Собственно формула FSPL явно говорит о логарифмической зависимости.
https://en.wikipedia.org/wiki/Free-space_path_loss
FSPL = 32.4 + (20log10(2,400)) + (20log10(x))
Как я писал, чтобы вычислить конкретный уровень сигнала, нужно рассчитать EIRP ( который содержит коэффициент усиления антенны) и вычесть из него FSPL
Господа, вы просто используете разные единицы измерения — Вт и дБм. В приведенной формуле слагаемое «20log10(x)» и есть затухание как квадрат расстояния. 10log10(x^-2) = -20log10(x). Логарифм тут от перевода в дБ, а двойка при нем — от квадрата расстояния.
Там по ссылке как раз написано, что «Free-space path loss is proportional to the square of the distance between the transmitter and receiver». А логарифм, как справедливо заметил ниже Korogodin, появляется при выражении этого затухания сигнала в децибелах.
Думается мне бигдата тут вполне могла бы помочь.
- Пользователи ставят себе приложение для навигации по ТЦ.
- Приложение постоянно мониторит мощности сигналов до ТД, показания акселерометра и компаса.
- По большому числу замеров данные усредняются и составляется карта, где для каждой точки определены уникальные наборы мощностей сигналов до ТД.
- По показаниям приборов легко можем найти точку на карте.
Плюсы:
- Простая математика.
- Не требуется ручное конфигурирование. Система настраивается сама.
- Поддержка 3D картографии.
- Быстрая адаптация к изменениям.
- Не требуется каки-либо телодвижений со стороны ТЦ. Работать будет в любом помещении, где есть куча ТД.
По большому числу замеров данные усредняются и составляется картаЯ наблюдал ещё такую проблему, разные телефоны дают разный уровень сигнала, но главное один и тот же клиент находясь на одном и том же месте может «выдавать» разный уровень сигнала, если клиент положил телефон в карман, то сигнал может упасть в 3 раза (что эквивалентно перемещению на десятки метров от ТД), если клиент развернулся стоя на одном месте, то сигнал падает ещё больше, даже если клиент не шевелится, сигнал может сильно плавать (видимо от недалеко проходящих людей и ещё чего-то).
А для ML нужны непротиворечивые данные, по которым можно построить закономерности.
Да, все это имеет место быть.
У всех телефонов же разные антенны, не уверен, что они передают в служебных пакетах их характеристики (что могло бы немного облегчить расчет).
По поводу того, где держит телефон человек — это действительно очень сильно влияет. Я вот думаю, что в этом случае ситуацию может чуть поправить AoA: данные об углах у нас не должны меняться и клиент теоретически не должен уж сильно «скакать» с места на место при перемещении телефона от левого уха в правый карман.
У всех телефонов же разные антенны, не уверен, что они передают в служебных пакетах их характеристики (что могло бы немного облегчить расчет).
По поводу того, где держит телефон человек — это действительно очень сильно влияет. Я вот думаю, что в этом случае ситуацию может чуть поправить AoA: данные об углах у нас не должны меняться и клиент теоретически не должен уж сильно «скакать» с места на место при перемещении телефона от левого уха в правый карман.
А вот еще один проект похожей направленности.
Возникла необходимость отследить потоки мигрантов по Европе. Во временных лагерях для мигрантов (от Греции до Германии + Балканы) раздают бесплатный интернет. Возникла идея раздавать интернет через Captive Portal и заносить данные указанные при регистрации в общую базу вместе с MAC address-ом. Затем можно просто отслеживать появление этих устройств на ТД других лагерей.
На практике применить не удалось но может быть темой для исследования (не обязательно применимо к мигрантом, можно следить за посетителями сети фастфуда например :) )
Возникла необходимость отследить потоки мигрантов по Европе. Во временных лагерях для мигрантов (от Греции до Германии + Балканы) раздают бесплатный интернет. Возникла идея раздавать интернет через Captive Portal и заносить данные указанные при регистрации в общую базу вместе с MAC address-ом. Затем можно просто отслеживать появление этих устройств на ТД других лагерей.
На практике применить не удалось но может быть темой для исследования (не обязательно применимо к мигрантом, можно следить за посетителями сети фастфуда например :) )
А для этого обязателен Wi-Fi вообще на телефоне? Может быть достаточно идентификатора телефона или SIM карты, перемещение которых отслеживать?
Для Wi-Fi, в принципе, чтобы отслеживать потоки, не обязательно даже делать CP и заносить данные, можно отслеживать MAC адреса ( для этого клиентам даже не надо подключаться к сети, достаточно отправить пару probe request-ов. К этому можно еще добавить DHCP profiling и HTTP profiling и тоже добавлять к данным о MAC адресе ( тип устройства, тип ОС..)
Для Wi-Fi, в принципе, чтобы отслеживать потоки, не обязательно даже делать CP и заносить данные, можно отслеживать MAC адреса ( для этого клиентам даже не надо подключаться к сети, достаточно отправить пару probe request-ов. К этому можно еще добавить DHCP profiling и HTTP profiling и тоже добавлять к данным о MAC адресе ( тип устройства, тип ОС..)
Тоже думал о применимости компаса, акселомтра в тандеме с BLE: достаточно несколько реперных точек ( а не ровный слой по всему зданию) и начинаем считать.
Предлагаю посетить музей русского импрессионизма. Нам там удалось добиться неплохих результатов используя HALO и BLE.
Пока правда есть проблемы рядом со стенами и в зонах неудачной обвески точками доступа, но планируем перекрыть эти места с помощью BLE.
Пока правда есть проблемы рядом со стенами и в зонах неудачной обвески точками доступа, но планируем перекрыть эти места с помощью BLE.
НЛО прилетело и опубликовало эту надпись здесь
Правильно ли я понимаю, что трилатерация применяется к данным полученным из Probe request?
Как тогда быть с iOS9 устройствами, которые подставляют в Probe случайный MAC адрес?
Как тогда быть с iOS9 устройствами, которые подставляют в Probe случайный MAC адрес?
Я полагаю, что уровень сигнала замеряется для каждого пакета, который услышала точка. Другое дело, что далеко не все точки слышат каждый пакет клиента, так как он передаётся на определенном канале, а точки слушают в основном каждая свой.
Probe request используются только в весьма определенных обстоятельствах, а именно в момент активного сканирования беспроводной среды. В Probe request может быть указан какой-то конкретный SSID, тогда точки с этим SSID возвращают probe response, либо не указан SSID, тогда все точки, что услышали этот запрос, возвращают параметры всех имеющихся SSID.
Что касается iOS9, то полагаю, что это может иметь значение для неассоциированных устройств, тогда действительно будет сложнее отслеживать положения устройств, которые не подключились к беспроводной сети.
Probe request используются только в весьма определенных обстоятельствах, а именно в момент активного сканирования беспроводной среды. В Probe request может быть указан какой-то конкретный SSID, тогда точки с этим SSID возвращают probe response, либо не указан SSID, тогда все точки, что услышали этот запрос, возвращают параметры всех имеющихся SSID.
Что касается iOS9, то полагаю, что это может иметь значение для неассоциированных устройств, тогда действительно будет сложнее отслеживать положения устройств, которые не подключились к беспроводной сети.
Я не уверен, что точка может замерять уровень сигнала для каждого пакета. По крайней мера я встечался только со случаями обработки Probe request.
К тому же ассоциированное устройство вроде как больше не должно посылать что либо другим точкам.
Как тогда будет работать трилатерация?
К тому же ассоциированное устройство вроде как больше не должно посылать что либо другим точкам.
Как тогда будет работать трилатерация?
Беспроводной адаптер точно собирает служебную информацию для каждого пакета, которая включает в себя date and
time stamps, a channel stamp, signal stamp, and a noise stamp. В анализаторе пакетов эта информация находится в отдельном заголовке, типа Radiotap Header. Если это делает клиентский адаптер, то точка доступа это наверняка может делать и скорее всего делает при необходимости.
Probe request посылается клиентом в самом начале общения с точкой, далее этот тип management фрейма не используется, поэтому замерять уровень сигнала только этих пакетов бесполезно для позиционирования.
Да, это известная проблема, которую я немножко затронул в статье. Во-1, к примеру, точка Cisco (да я думаю большинство) небольшую часть времени тратит на сканирование всех каналов. Можно не попасть на пакет клиента. Поэтому используют дополнительное радио, которое все время занимается только тем, что сканирует каналы, но опять же, приходится перебирать каналы. Чуть проще, когда требуется позиционировать только подключенных клиентов, перебирать каналов приходится в этом случае меньше ( к примеру только 1-6-11 в диапазоне 2.4 ГГц).
Я этот вопрос постараюсь раскрыть в следующей статье, вместе с описанием FastLocation.
time stamps, a channel stamp, signal stamp, and a noise stamp. В анализаторе пакетов эта информация находится в отдельном заголовке, типа Radiotap Header. Если это делает клиентский адаптер, то точка доступа это наверняка может делать и скорее всего делает при необходимости.
Probe request посылается клиентом в самом начале общения с точкой, далее этот тип management фрейма не используется, поэтому замерять уровень сигнала только этих пакетов бесполезно для позиционирования.
К тому же ассоциированное устройство вроде как больше не должно посылать что либо другим точкам.
Как тогда будет работать трилатерация?
Да, это известная проблема, которую я немножко затронул в статье. Во-1, к примеру, точка Cisco (да я думаю большинство) небольшую часть времени тратит на сканирование всех каналов. Можно не попасть на пакет клиента. Поэтому используют дополнительное радио, которое все время занимается только тем, что сканирует каналы, но опять же, приходится перебирать каналы. Чуть проще, когда требуется позиционировать только подключенных клиентов, перебирать каналов приходится в этом случае меньше ( к примеру только 1-6-11 в диапазоне 2.4 ГГц).
Я этот вопрос постараюсь раскрыть в следующей статье, вместе с описанием FastLocation.
Несмотря на известные проблемы и специфики распространения вай-фай сигналов, использование алгоритмов для мультилатерации даёт вполне подходящие результаты РТЛС. Также немаловажным являются антенны и wi-fi модуль принимающего устройства в целом. К примеру, алгоритм Левенберга-Марквардта с комбинацией фильтров дает точность до 3 метров.
Насколько я понимаю, та же Cisco использует мультилатерацию, так как говорит, что желательно иметь 4 замера. При этом явно указывает, что позволяет добиться в 90% случаев точности 10м и в 50% случаев точности 5м. Могу еще сказать, что похоже Cisco возлагает надежду на AoA. Про алгоритм Левенберга-Марквардта с комбинацией фильтров не могу ничего сказать, к сожалению, посмотрю, спасибо!
Низкая точность Cisco судя по всему связана с тем, что установка устройств делается с учетом требований к wi-fi покрытию, а не RTLS. Они действительно ставят на AoA и HALO модули, где можно достичь намного выше точность. Но лично я не верю в успех этого направления потому, что если CMX само по себе довольно дорогое решение, то покрытие с помощью HALO будет скорее всего на порядок дороже. Если интересно, то вот как мы решили эту проблему у нас в Leantegra (https://youtu.be/jrllaPylG7Q). Принимающие устройства расставлены по углам комнаты, положение мышки = реальное положение человека, который идет с телефоном в кармане, “круги” — приблизительное расстояние к принимающему устройству рассчитанное на основе RSSI значений.
Заявленная точность у Cisco обеспечивается с учетом планирования покрытия под позиционирование (основное требование — в каждой точке пространства должен быть сигнал -75dBm и более от трех точек доступа), то есть точек будет в раза два больше, чем обычно.
Навес HALO ( модуль и антенна) в GPL стоит около 1000$ и точка должна быть модульная, серия 3ххх, то есть дорогая. При этом для достижения точности 1м требования к покрытию остаются!
Видео занятное, посмотрю и почитаю, спасибо!
У меня сейчас стенд развернут с HALO, я следующей статьёй постараюсь разобраться с ним…
Навес HALO ( модуль и антенна) в GPL стоит около 1000$ и точка должна быть модульная, серия 3ххх, то есть дорогая. При этом для достижения точности 1м требования к покрытию остаются!
Видео занятное, посмотрю и почитаю, спасибо!
У меня сейчас стенд развернут с HALO, я следующей статьёй постараюсь разобраться с ним…
Возможно, заставить работать навигацию по такому принципу с высокой точностью получится, если создать подробную модель затухания сигнала для конкретного набора ТД и конкретного здания. Т.е. нужно, перемещаясь по известным траекториям, решать обратную задачу — задачу идентификации модели — оценивая параметры модели с учетом многолучевости (такой термин применяется в спутниковой навигации для описания эффекта переотражения). Делать это один раз на этапе отладки системы и затем использовать настроенную модель.
А что с позиционированием по технологии Bluetooth? Я как-то раз случайно поймал рекламный пакет МТС через такой передатчик))) Интересно узнать как с этим дела в России, потому что в теории самые новые датчики на последних версиях Bluetooth очень мало энергии потребляют и их можно оптом закупать в отличие от Wi-Fi?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Почему не взлетает позиционирование на основе Wi-Fi