Геолокация внутри помещений на базе iBeacon. Решение Aruba Meridian

[Marwin]

Триангуляция при использовании Meridian происходит непосредственно на устройстве, а соответственно существенно зависит как от софта Meridian, так и от драйверов для Bluetooth адаптера. Любые проблемы хотя бы в одном из этих компонентов, либо в их взаимодействии приводят к сильному снижению качества навигации на конкретном устройстве

А воз и ныне там… Делали аналогичное приложение пару лет назад. Не взлетело в том числе по этой причине

[w32blaster]

Мы тоже делали, и тоже не взлетело и по той же причине )

[igorbezr]

Идеальной для вендора была бы ситуация, когда разброс моделей устройств на руках у пользователей минимален, а производители Bluetooth чипов взаимодействуют с разработчиками решения. Насколько я понимаю, именно такая ситуация складывается с продукцией Apple и именно поэтому базой для решения был выбран iBeacon, а не Eddystone.

[Jef239]

Ну на мой непрофессиональный взгляд все довольно просто. Такая навигация сильно зависит от достоверности уровня приема, показываемого драйвером. Те 2 Дб отличий, указанных в вашей таблице 1 — достаточно для ухудшения навигации.

Грубо говоря, на iOS у вас BLE откалиброван и он говорит 3.5 метра до одного маяка 7.2 метра до другого, 10.5 метров до третьего. И это дает схождение сфер от маяков в правильной точке. А на Андроид у вас получается 3 метра до первого маяка, 6.7 метров до второго и 9.7 метров до третьего. И это не сходится вообще или сходится не там.

Мораль — для навигации на андроид надо определять уровень сигнала на расстоянии метр и изменять значение в базе. Тогда iOSовская навигация будет лажать, но на конкретном андроиде станет лучше.

Ну или делать приложение, калибрующее сигналы на конкретном андроиде. Если это возможно, конечно.

P.S. Нету там триангуляции, только трилатерация.

[dmagin]

В статье про трилатерацию какая-то дремучая математика приведена (и в английской Вики тоже). Неужели так и считают до сих пор? Оставлю тут на всякий универсальный метод расчета координат точек по расстоянию до маяков.

1. Определяем базис маяков на основе квадратов расстояний (квадрансов) между ними. Это почти матрица Кэли-Менгера, только надо квадрансы поделить на (-2). Обозначим ее Gm (а вообще — это матрица скалярных произведений между маяками, мажорный грамиан).
2. Находим обратную к ней: Lm = /Gm (это мажорный лапласиан). Теперь у нас есть два взаимных метрических тензора. Можно считать координаты.
3. Дистанционные координаты точки записываем в виде ди-координат: di(P) = [1; -q(A)/2, -q(B)/2, -q(С)/2]. Здесь q(A)/2 — квадрат расстояния от точки до маяка A и т.д.
4. Умножением мажорного лапласиана Lm на ди-координаты находим взаимные (би-) координаты точки:
   bi(P) = Lm di(P). Важно, что они включают в себя барицентрические координаты:
   bi(P) = [w(P); b(A), b(B), b(С)].
5. На основании барицентрических координат можно найти любые типы координат (например, декартовы) проекции точки, если таковые известны для маяков — просто как взвешенную сумму координат маяков, где веса маяков — это b(A), b(B) и b(С).
6. Норма точки (свертка ди- и би- координат) будет отражать ее высоту над плоскостью маяков (точнее квадрат высоты с минусом).
   Данный метод универсален для пространств любой мерности.

[Jef239]

Не знаю, не математик, мы в высокоточном GPS делаем нечто, более похожее на триангуляцию. То есть считаем направляющие косинусы, потом составляется матрица и решается методом Холецкого.

[igorbezr]

К сожалению, остаётся не ясным, какая именно математика работает внутри данного решения. Из общения с вендором и инженерами в community Aruba известно лишь, что ПО сканирует эфир и последовательно определяет три маячка с самыми мощными сигналами, после чего работает только с ними. Как именно происходит вычисление координат точек знают только программисты Meridian. При этом задержка при позиционировании составляет около двух секунд.
К слову, вышеописанная последовательная выборка начинает сильно усложнять планирование расположения маячков, если помещение является многоуровневым (например, ТЦ с галереями над атриумом). Вполне возможна ситуация, когда на галерее второго этажа устройство принимает сигналы с двух маячков галереи и одного-атриума, что может приводить к «телепортации» вычисленной позиции между этажами.

[Krey]

Проблема не в рассчете координат по расстояниям, это прекрасно делает и та дремучая математика. Проблема в том что падение RSSI редко отражает реальное расстояние и сильно прыгает даже в статических условиях.

[alex_min]

Проблема не нова, на точность определения позиции по RSSI маяков влияет несколько факторов. Речь сейчас только об android:
1. Приемные тракты смартфонов разных моделей не калиброваны, разница даже усредненных показаний RSSI от одного маяка в одной точке на разных моделях Android смартфонов достигает 15-18dBm. Диаграммы направленности антенн и в маяке и в смартфоне имеют неравномерности в несколько dB, что само по себе вносит ошибку.
2. Смартфон захватывает не все BLE пакеты, методика сканирования «тайна великая есть», в любом случае повлиять на нее софт может крайне ограничено. Т.к. маяки обычно работают на 3-х каналах(37,38,39) то и RSSI от одного маяка из-за этого все время плавает, его надо усреднять. И даже при настроенном на работу на одном фиксированном канале уровень в измерителе плавает в пределах 2 dB.
3. Как правило в Android смартфонах чипы для wifi и Bluetooth единые. Работа Wifi вносит свою «лепту». Если записать графики RSSI пакетов от одного маяка при включенном и выключенном Wifi в смартфоне, то можно увидеть «много интересного и познавательного» — и средний уровень RSSI меняется прилично (я получал 5-6 dB разницы) и «выбросы» получаются большими.
4. Диапазон 2.4 ГГц хорошо поглощается, но и неплохо переотражается, поэтому точная картина мощностей в помещении будет сложной.
Все это не дает получить гарантированную точность лучше 4-8 метров (разумеется в зависимости от плотности установки маяков).