お知らせ
屋内測位システム『TPC_IPS Ver1.0』を2022/4/1にリリースしました。同製品に関する質問またはデモを希望されるお客様はこちらよりお申し込みください。
同製品のカタログのダウンロードはこちらをクリックしてください。
尚、外部のIPS/RTLSと連携して動作するIPSアプリケーション・テンプレート『QuickIPS』及び 『TPC_IPS Web API』 も順次リリースを予定しています。
前稿（18/4/10）では室内移動体位置監視モデルに関する概要について記しました。本モデルは倉庫、施設、工場のような環境で、移動する多数のモノや人に iBeacon（以下、ビーコン）を取り付け、それらモノや人の位置を把握することを目的とします。
図1
図の端末（ピンク）はビーコン（青）からの信号を検知し、信号のRSSI（後述）から距離を算出します。端末⇔ビーコン間の距離が各円の半径となります。各端末はビーコンとの距離（半径）しか算出できないため、複数の端末の距離データを使用してビーコンの位置を算出します。ビーコンが移動すると、最小の半径を持つ端末（TOP3）が替わるため、替わった端末（図ではPi12/15/16）が算出する距離データにより、その移動先の位置(After)が算出されます。
今回はビーコンの位置算出の要になるRSSIに関して小社で行ったテストについて記します。
今回はビーコンの位置算出の要になるRSSIに関して小社で行ったテストについて記します。
RSSIと距離について
RSSI(Received Signal Strength Indicator) はビーコンから発せられる信号の強度を示す数値で、ビーコンから離れるに従ってその強度は規則的に減衰します。ビーコン信号を受信する端末 ― ここでは Raspberry Pi（以下、RP、監視端末、端末と呼ぶことがあります）― はビーコン信号のRSSIを測定し、その減衰度により自身とビーコン間の距離を算出します。この信号強度は理論的には距離の二乗に反比例して減衰するのですが、実際には様々な電波干渉があるため、ビーコン⇔端末間の距離が長くなればなるほどRSSIのばらつきは大きくなり、その精度は劣化していきます。
図2
|
|
例：ビーコン信号強度グラフ（Aplix 社のサイトより）
|
上図は、端末⇔ビーコン間の距離が1m を超えるとRSSIが急激に劣化し、ただ単にRSSIを測定してそれから距離を算出したのでは、実際の距離とはかけ離れた値となる可能性があることを示しています。
本稿ではいくつかの環境で RSSIを測定します。さらに、その測定結果をもとに、RSSIの補正方法も考えてみます。
本稿ではいくつかの環境で RSSIを測定します。さらに、その測定結果をもとに、RSSIの補正方法も考えてみます。
システム構成
実際に行ったテストについて記す前に、今回の開発・テストで使用したデバイスとシステム構成について説明します。
ビーコンと端末
今回はテストでは、ビーコンには Aplix 社製 MyBeacon 汎用型ビーコン 、Gimbal社製 Series 10、Onix等を、ビーコンを監視する端末には Raspberry Pi Zero W/WH/3B/3B+ を使用しました。
ビーコンは1つのメーカーに限定したほうがシステム開発も保守も簡単ですが、1メーカーへの依存はリスクを伴います。最終的には複数メーカーのビーコン運用に対応したシステムを開発するため、いくつかのテストでは、複数のメーカーのビーコンを用いました。
端末は安価で定評も実績もある Raspberry Pi を使用しています。RPには多くの機種があり、信号受信アンテナの設置位置や無線チップも異なる（最新の3B+ではBCM2837B0、その他はBCM2837）ので、こちらも1つの機種限定したほうが簡単ですが、将来的な入手の容易性、拡張性、柔軟性を念頭に複数のシリーズを使用しています。
ビーコンは1つのメーカーに限定したほうがシステム開発も保守も簡単ですが、1メーカーへの依存はリスクを伴います。最終的には複数メーカーのビーコン運用に対応したシステムを開発するため、いくつかのテストでは、複数のメーカーのビーコンを用いました。
端末は安価で定評も実績もある Raspberry Pi を使用しています。RPには多くの機種があり、信号受信アンテナの設置位置や無線チップも異なる（最新の3B+ではBCM2837B0、その他はBCM2837）ので、こちらも1つの機種限定したほうが簡単ですが、将来的な入手の容易性、拡張性、柔軟性を念頭に複数のシリーズを使用しています。
システム構成概要
ビーコンから送信される信号はRaspberry Pi で受信・加工され、アプリケーションサーバを介して、データベースに書き込まれます。今回はデータベースに SQLite を使用しましたが、多数の端末を使用する場合はマルチユーザ利用に適した MySQL や PostgreSQL 等を使用する方が良いと思います。
図3
|
| システム構成図 |
プロトタイプについて
今回テストで使用したプロトタイプは tpcbeaconhost.js、tpcbeaconinfo.js と tpclocation.js で node.js 下で動作するアプリケーションです。これらは相互に連携しながら各ビーコンの信号取得、端末⇔ビーコン間の距離算出、補正、データベース更新を担います。
表1
| モジュール名 | 用途 |
| tpcbeaconsampler.js | 端末にインストール。アプリケーションサーバからのリクエストに応じて、検知したビーコン信号を基にデータを作成し、アプリケーションサーバに送信する。 |
| tpcbeaconinfo.js | ・アプリケーションサーバ上に配置。各端末に対してリクエストを送信。端末から受信したデータを必要に応じて再加工し、データベースを更新する。 ・端末のリクエストに応じて、端末やビーコンに関する情報を送信する |
| tpclocation.js | ・アプリケーションサーバ上に配置。tpcbeaconinfo.js が記録したデータベース上の情報を基に、距離（半径）の補正やビーコン位置の算出を行う。 ・plotly.jsを利用した端末とビーコン位置のプロット（下図10参照）。 ・上記の処理はアプリケーションサーバ上のスケジュール、またはユーザのリクエストに基づき実行。 |
RSSI 測定テスト
ビーコンメーカーのAplix社は RSSI に影響する要因として、以下を上げています[1]。
- Beaconの送信出力、アンテナのゲイン、放射パターン
- 受信側スマートフォンの感度、アンテナの向き等
- スマートフォンOS内の処理(Bluetoothスタックの振る舞い他)
- 周囲環境(建材、人体等)による反射・吸収・回折
このように RSSI値は様々の要因に影響を受けるため、端末が信号を受信しても、理論値と実測値は異なります。以下のテストは、RSSIがどの程度環境の影響を受けるのかをテストし、「考察」では補正方法についても簡単に記載しています。
※Apple社ビーコン補正の適用について
以下の文章中、「Apple社ビーコン補正」が「有」或いは「無」といった表記をしていますが、これはビーコン導入時に iPhone等によりビーコンから1ｍ離れた地点で RSSI を測定し、その測定値の平均により補正を行ったか、行わなかったとを意味します。このビーコン補正はApple社の Getting Started with iBeacon (PDF)の「Calibrating iBeacon」の項に基づき行っています。
※ RSSI の距離変換
RSSIは信号強度を対数で示した数値ですが感覚的に把握し難いため、本稿では多くの場合、距離に変換して表記しています。RSSI≒距離と考えて頂いて結構です。
テスト1 1つのビーコンのRSSIを24時間測定
目的
固定した1つの端末と1つのビーコンを使用し、RSSIの精度、時間帯による変動をチェック
条件
- 1つのビーコンを1つの端末で24時間測定。
- 端末による1回のスキャン時間は5秒間。24時間で約1万7千のスキャンを実施。1回のスキャンで収集されるデータは平均34件、RSSIはスキャン毎に平均している。また、下図でRSSIは距離(m)に変換している。
- ビーコンと端末間の実際の距離：4.5m
- ビーコンと端末は固定してあり、移動しない。
- テスト中、ビーコンと端末の間、またはその周辺の人、モノの移動は最小限にする。
- Apple社 ビーコン補正：有
結果
以下の2つ図は、データベースに記録されたデータをプロットしたもの。
【散布図1：時間経過と計測距離の変化】
|
|
RSSI はメートルに変換し縦軸に、横軸は計測時間 |
|
|
横軸に距離、縦軸に発生件数を棒グラフ化。 |
平均(AVG)：2.75m
標準偏差(SD) ：0.88m
最大(MAX)：9.96m
最小(MIN)：0.93m
標準偏差(SD) ：0.88m
最大(MAX)：9.96m
最小(MIN)：0.93m
考察
- 端末⇔ビーコン間の実際の距離は4.5mだが、測定値では2.75m（平均値）で、かなりの乖離がある（実際の距離とは異なる）。また、最大値と最小値の差も大きい。
- 日中は距離の偏差が大きく、夜間に小さい。これは夜間は人間の発するWiFi等の電波による干渉が少ないためと推定される。また、日中は夜間に比し、値が上振れする。
- 以上のことより、距離の精度を上げるためには、時間に連動した応じた補正が必要。
テスト2 複数端末で複数ビーコンのRSSIを測定
目的
- 端末の個体差はどの程度あるのか
- BLEデバイスが異なると、RSSIに顕著な違いは発生するのか
条件
- 各端末によるビーコンスキャンは10秒間、1回のみ。
- 各端末が収集したデータは平均で50件弱。RSSI(表のaveRssi)は平均値。また、下表でRSSIを距離(Ave)に変換している。
- 端末(下図のPi1、Pi5-Pi8)から1m(Dist)の所にAplix(AP)10個とGimbal(GI)20個を配置。ビーコンは多数のため、端末との距離をできる限り1ｍに保つため格子状のプラスチックケース等に収納した。尚、Pi5 は 3B にBLEドングルを装着したもので、内臓BLEは無効化してある。
図4
- ビーコンと端末は固定してあり、移動しない。
- テスト中、ビーコンと端末の間、またはその周辺の人、モノの移動は最小限にする。
- Apple社ビーコン補正：無
* Dist：端末⇔ビーコン間の実際の距離。
* RP： Raspberry Pi 端末、Pi1/6/7/8は Zero W、Ri5 は 3BにBLEドングルを装着したもの。
* Ave： RSSI(aveRssi)より算出した端末(RP)⇔ビーコン間の距離（単位：m）。
* SD：Aveの標準偏差
* aveRssi：全ビーコンがRSSIの平均
*Sample num：ビーコンから受信のデータ件数（平均）。各ビーコンから約46件づつ受信。
* Summ.：総平均
考察
- 同種の端末で同環境でテストしても、RSSIの値に差がでる。また、Pi5は BLEドングルを使用しているが、他端末の値との差が大きい。
- 上述のビーコン補正を行わないと、実際の距離は1mであっても計測されるRSSIに対応する距離は全くかけ離れた値になることがある。
- 以上、端末間でもRSSIの値に差異があるため、端末単位の補正が必要。
テスト3 ビーコンとメーカーによるRSSI(距離)の差異
目的
ビーコン間、メーカー間でどの程度RSSIに差があるのかを調査条件
 |
- ビーコンはAplixを20個、Gimbalを49個、1つの端末を使用。ビーコンを丸テーブルの円周上に配置。その上部に天井から吊るした端末と各ビーコン間の距離が1mになるようにする。
- 端末によるキャン時間60秒×5回を1セット。1セット終了後90度テーブルを回転させ、計4セット（60秒×5回×4セット）を実行。これは端末アンテナとビーコンの位置などにより、RSSIの値が異なることを想定し、値を丸めるために実施。
- 計20回のスキャンで端末が受信したデータ数は1ビーコン平均で約3600件。RSSIはスキャン毎に平均。下図ではRSSIを距離(m)に変換している。
- ビーコンと端末間の実際の距離：1m
- スキャン中、ビーコンと端末は固定してあり、移動しない。
- テスト中、ビーコンと端末の間、またはその周辺の人、モノの移動は最小限にする。
- Apple社ビーコン補正：無
結果
表3
| Aplix | Gimbal | |
| AVG(平均距離) |
0.4m
|
0.19m
|
| SD(標準偏差) |
0.11m
|
0.08m
|
| MAX(最大距離) |
0.6m
|
0.4m
|
| MIN(最小距離) |
0.2m
|
0.1m
|
| Data Num(データ数) |
3618件
|
3606件
|
考察
- ビーコン個体についても計測値に差があり、最小値と最大値については3倍～4倍もの差がある。
- AplixとGimbalの平均値で約2倍の差がある。
- 以上のことから、個々のビーコンに対する補正と、ベンダー（ビーコンシステム）別の補正が必要。
以上、時間帯、端末個体、端末種類（ビーコンシステム）、ビーコン個体、ビーコン種類（ベンダー）により、RSSIとそれに基づく距離が大きく異なることが判りました。
以下ではこの誤差を補正できるか否かを小社で開発したプロトタイプシステムを使用して検証します。
RSSI・距離補正 (18/09/24加筆)
上述のように、RSSI 或いはRSSIから算出されるビーコン⇔端末間の距離は、そのままでは信頼性の低いものです。三点測位等によりビーコンの位置（座標）を取得するには、この距離を補正し、精度を上げる必要があります。Apple社ビーコン補正
上述のようにApple社のドキュメント「Getting Started with iBeacon (PDF)」に「Calibrating iBeacon 」の一項があり、ここに重要事項として RSSI の補正方法が記述されています。これによると、- iPhone等をビーコンから1m離し、ビーコン信号を最低10秒間測定。測定に際しては当該デバイスを縦向きし、（手のひら等で）上半分を遮らないこと。
- 図のように、デバイスとビーコンとの距離を等間隔に保ちながら、30cmのライン上でゆっくりと上下に動かす
 |
| Apple社の上記ドキュメントより |
- 上記の測定の実行中に rssi の測定値を収集し、その平均値をベンダーが提供する方法によりビーコン本体に登録する
この方法は、ビーコンが固定されていてiPhone等のデバイスが移動する環境では良く機能するのかも知れませんが、小社が想定する端末が天井などの高い位置に固定され、その下に多数のビーコンが配置される環境では良い結果が得られませんでした。
また、ビーコンの数が多いとその測定値を集計・平均し、登録する作業もかなりの時間を要します。
補正テストの環境
今回小社では下図のような補正テスト環境を用意し、端末とビーコン間のRSSIを測定し、補正テストを実施しました。当初は端末（図のa～i）の間隔を10mと想定していたのですが、その場合、測定値と実際の距離の乖離が大きく、今回は端末の間隔を各4ｍにしました。図のように端末は壁のすぐそばに設置されていたり、壁により隔てられており、環境は悪条件に属すると思います。ただ実際の運用環境も良い条件に無いことが想定されるため、悪条件下でのテストを実施しました。
 |
| 図5：テスト環境 |
凡例：
a～i：Raspberry Pi 端末 ― ビーコンを探知し、RSSIを測定
Fix：固定ビーコン、端末下1ｍに固定された補正用ビーコン
B：測定対象となるビーコン
青点線：壁または窓、電波伝搬の障害となる
ビーコン： Aplix 社製 MyBeacon 汎用型ビーコン ― テストを単純化するため、今回は他社の製品を使用していません。
監視端末： Raspberry Pi Zero W/WH/3B/3B+
その他：上図3のシステム構成に準じる
次に小社で考案した3つの補正方法を提示した後、各方法毎にテスト結果を記します。
まず下図のように、円卓テーブルの円周上にビーコンを並べ、Rapberry端末から各ビーコンの距離が1ｍとなるように配置します。その後スキャンを数十秒から数分行い、次に円を90度回転させて再スキャン、さらに90度回転してスキャンというようにスキャンを計4回行い、ビーコン毎に平均した値をデータベースに登録します。
ビーコンと端末間の距離（d）は以下の計算式を使用して求めますが、式内の RSSI@1meter がデータベースに登録された各ビーコンの値となります。
Apple社のように1台1台、ビーコン本体に値(RSSI@1meter)を登録するのではなく、一括スキャンし、一括してデータベースに登録ができ、ベンダーのサービスに依存しない点が本方法のメリットです。
注：RSSI@1meter は、TxPower とか Measured Power 等と呼ばれていて、名称は統一されていません。1m地点でのRSSIを TxPower と呼ぶのは、やや違和感があります。
式1を展開して n を求めると以下のようになります。
本補正法では、この n を使用して補正を実施します。
まず、アプリケーション（tpclocation.js）は、図のように近接する2つの固定ビーコン間で n を求めます。
次に各端末（tpcbeaconhost.js）がスキャンにより取得した未補正のRSSIを使用し、ビーコンに最も近接する端末（No1端末、図ではF1）を特定します。No1端末を特定すれば、その近接端末（図のb、d、f、h）が特定できます。端末bからビーコンBまでの距離(d)は、上記の式1を使用して以下のように求められます。
同様に端末d、f、hからビーコンBまでの距離も求めます。
尚、三点測位を行う場合は、最も距離の短い3つの端末の座標と距離(半径)データを使用します。
注：
No1端末の対角線上にある端末のデータの使用、及び三点測位については、稿を改めて述べたいと思います。
表4
残念なことに、未補正のデータが一番実際の値に近いという結果です。結果が悪いのは上述のようにデバイスが壁に近すぎたり囲まれていて、干渉が大きく影響しているためと思われます。また、「DBビーコン補正」は RSSI@1meter の値の取得時の端末と場所が実際の端末（a～i）と異なることも要因と思われます。「端末補正」は RSSI@1meterを基に算出した端末係数を異なる距離に存在するビーコンに適用することに無理があるかもしれません。
領域補正については指数表示になるほど実際の距離とかけ離れています。これは伝搬損失係数 n に異常値が発生しているためです。そこで、nが異常値となった等いくつかの条件下では、領域補正を適用せず、未補正の数値を使用するようにアプリケーションを変更した結果が以下となります。
表5
調整により実際の距離に大分近くなりました。
しかし、当方のテストではRSSI・距離の補正後も「理想」のようきれいに3円が交わることは少なく、補正されたデータでプロットしても、様々なパターンが出現します。上図の「現実」がその例で、プロットパターンは当社が認識している範囲で15になります[2]。このような3円がきれいに交差しないプロットパターンの場合、「単純に3円の交点から幾何中心を求める」だけのプログラムは破綻する（またはエラーを返す）ことになります。
小社でも当初は上記の式4を含め、15のプロットパターンに対応した式をそれぞれ用意し、ソースコードに落とそうとしたましたが、ソースを書き始めると工数的に厳しいことがわかりました。次に発生頻度の高いプロットパターンにのみ対応させ、発生頻度の低いパターンについては「汎用処理」をなんとか捻り出すことにしました。汎用処理は後回しにして、いくつかのプロットパターンに対応したテストプログラムを用意して実行しましたが、ビーコン座標の算出の結果は良いものではありませんでした。
そこで次に考えた苦肉の策が、上記「汎用処理」とその拡大適用（すべて或いは多くのプロットパターンに適用する、という趣旨）で、これが以下の「二円指向三点測位」です。
y座標についても上表のルールに準じて、C1 と C3 を使用の座標とで算出します。
下図が上述のロジックに基づき作成したプログラム「tpclocation.js」 により端末が送ってきたデータを補正・描画したものです。● が「二点指向測位」による算出された座標、■が実際の座標です。
凡例
Teminal: 使用した端末名
x: x座標, y: y座標
Distance: 端末からビーコンまでの距離（半径）
Acual（■）: ビーコンの実際の位置
Calc.（●）: 二円指向三点測位に基づき算出されたビーコンの位置
Gap: | Actual.x - Calc.x | + | Actual.y - Calc.y | 、誤差（Distance error）
平均誤差 (Average distance error)：2.36m
最大誤差 (Maximum distance error)：6.03m
さて、今回提示した二円指向三点測位は端末を正方形状に配置することを前提にした測位モデルでしたが、次回は正方形のセンタに端末を付加することにより、測位精度の向上を目指します。このセンタ端末と他の端末には角度が付くため、二円指向三点測位は拡張することになります。
また、端末間の距離を4mから、8m、16m、32mとしたとき、どの程度の誤差で測位できるのかも検証します。 詳しくは［次稿］をご覧ください。
^[2]Intersection of 3 circles calculator (13のプロットパターンを表示)
Talk:Trilateration/Archive 1 (Wikipedia で「Trilateration」 が「Multilateration」に統合された理由、C++のソース等)
a～i：Raspberry Pi 端末 ― ビーコンを探知し、RSSIを測定
Fix：固定ビーコン、端末下1ｍに固定された補正用ビーコン
B：測定対象となるビーコン
青点線：壁または窓、電波伝搬の障害となる
使用デバイス
ビーコン： Aplix 社製 MyBeacon 汎用型ビーコン ― テストを単純化するため、今回は他社の製品を使用していません。
監視端末： Raspberry Pi Zero W/WH/3B/3B+
その他：上図3のシステム構成に準じる
次に小社で考案した3つの補正方法を提示した後、各方法毎にテスト結果を記します。
DBビーコン補正
前述のように Apple社の補正方法は今回のモデルでは今一つの結果で、測定値（平均）の登録にも労力と時間を要します。本補正方法は、このApple社の方法を応用したものです。まず下図のように、円卓テーブルの円周上にビーコンを並べ、Rapberry端末から各ビーコンの距離が1ｍとなるように配置します。その後スキャンを数十秒から数分行い、次に円を90度回転させて再スキャン、さらに90度回転してスキャンというようにスキャンを計4回行い、ビーコン毎に平均した値をデータベースに登録します。
 |
| 図6：DBビーコン補正の事前スキャン |
ビーコンと端末間の距離（d）は以下の計算式を使用して求めますが、式内の RSSI@1meter がデータベースに登録された各ビーコンの値となります。
 |
| 式1：RSSIより距離を算出する式 |
Apple社のように1台1台、ビーコン本体に値(RSSI@1meter)を登録するのではなく、一括スキャンし、一括してデータベースに登録ができ、ベンダーのサービスに依存しない点が本方法のメリットです。
注：RSSI@1meter は、TxPower とか Measured Power 等と呼ばれていて、名称は統一されていません。1m地点でのRSSIを TxPower と呼ぶのは、やや違和感があります。
端末補正
上述のテスト2では、ほぼ同一条件で1m離れたビーコンの信号を測定したにも関わらず、端末によってその算出距離にはかなりの差がありました。また、端末の個体差だけではなく、時間帯、設置場所によっても電波は様々な影響を受けます。そこで配置した端末から1mの場所に補正専用のビーコン（固定ビーコン）を配置し、実際の距離である1mを測定距離で除して係数化します。例えば、端末Aでこの固定ビーコンのRSSIを測定し、そこから算出された距離が0.5mであれば、1m÷0.5mで 2 が端末係数となります。この値を端末Aが受信したすべてビーコンの信号対して適応します。領域補正
3つ目の補正方法が領域補正です。上述の式1に n という係数がありますが、この n は伝搬損失係数（Path-loss index）と呼ばれ、理想的な環境では2となります。しかし、電波は干渉、減衰、回折、反射、吸収の影響を受けるため、端末とビーコンの配置場所により変動します。式1を展開して n を求めると以下のようになります。
 |
| 式2：伝搬損失係数 n の算出式 |
本補正法では、この n を使用して補正を実施します。
まず、アプリケーション（tpclocation.js）は、図のように近接する2つの固定ビーコン間で n を求めます。
図7
次に各端末（tpcbeaconhost.js）がスキャンにより取得した未補正のRSSIを使用し、ビーコンに最も近接する端末（No1端末、図ではF1）を特定します。No1端末を特定すれば、その近接端末（図のb、d、f、h）が特定できます。端末bからビーコンBまでの距離(d)は、上記の式1を使用して以下のように求められます。
 |
| 式3 |
同様に端末d、f、hからビーコンBまでの距離も求めます。
尚、三点測位を行う場合は、最も距離の短い3つの端末の座標と距離(半径)データを使用します。
注：
No1端末の対角線上にある端末のデータの使用、及び三点測位については、稿を改めて述べたいと思います。
補正テストの結果
以下が上記3つの補正方法による測定結果です。テスト環境は図7の通りで、各端末の直下に測定対象となるビーコンBを3つから4つ配置しています。本来であれば、ビーコンを分散させるべきですが、テスト結果の評価を容易にするために、このように配置となっています。データは実際の距離が1mと4mとなるものを抽出し、平均値で示しています。表4
| 実際の距離 | 未補正 | DBビーコン補正 | 端末補正 | 領域補正 |
| 1m | 0.62 | 1.95 | 2.32 | 2.68 |
| 4m | 2.75 | 8.05 | 18.86 | 1.59E+28 |
残念なことに、未補正のデータが一番実際の値に近いという結果です。結果が悪いのは上述のようにデバイスが壁に近すぎたり囲まれていて、干渉が大きく影響しているためと思われます。また、「DBビーコン補正」は RSSI@1meter の値の取得時の端末と場所が実際の端末（a～i）と異なることも要因と思われます。「端末補正」は RSSI@1meterを基に算出した端末係数を異なる距離に存在するビーコンに適用することに無理があるかもしれません。
領域補正については指数表示になるほど実際の距離とかけ離れています。これは伝搬損失係数 n に異常値が発生しているためです。そこで、nが異常値となった等いくつかの条件下では、領域補正を適用せず、未補正の数値を使用するようにアプリケーションを変更した結果が以下となります。
表5
| 実距離 | 未補正 | DBビーコン補正 | 端末補正 | 端末補正 (未調整) | 領域補正 (調整有) |
| 1m | 0.62 | 1.95 | 2.32 | 2.68 | 0.98 |
| 4m | 2.75 | 8.05 | 18.86 | 1.59E+28 | 3.63 |
調整により実際の距離に大分近くなりました。
二円指向三点測位（19/02/07加筆、19/05/10下表図等一部修正）
通常の三点測位では、下図の「理想」のように3円が交差する状態で、以下の方程式によりその接点を求め、さらにその幾何中心を以て目標物（ここではビーコン）の位置とします。
式4
r12 = (x - x1)2 + (y - y1)2
r22 = (x - x2)2 + (y - y2)2
r32 = (x - x3)2 + (y - y3)2
図8
しかし、当方のテストではRSSI・距離の補正後も「理想」のようきれいに3円が交わることは少なく、補正されたデータでプロットしても、様々なパターンが出現します。上図の「現実」がその例で、プロットパターンは当社が認識している範囲で15になります[2]。このような3円がきれいに交差しないプロットパターンの場合、「単純に3円の交点から幾何中心を求める」だけのプログラムは破綻する（またはエラーを返す）ことになります。
小社でも当初は上記の式4を含め、15のプロットパターンに対応した式をそれぞれ用意し、ソースコードに落とそうとしたましたが、ソースを書き始めると工数的に厳しいことがわかりました。次に発生頻度の高いプロットパターンにのみ対応させ、発生頻度の低いパターンについては「汎用処理」をなんとか捻り出すことにしました。汎用処理は後回しにして、いくつかのプロットパターンに対応したテストプログラムを用意して実行しましたが、ビーコン座標の算出の結果は良いものではありませんでした。
そこで次に考えた苦肉の策が、上記「汎用処理」とその拡大適用（すべて或いは多くのプロットパターンに適用する、という趣旨）で、これが以下の「二円指向三点測位」です。
二円指向三点測位
このテストモデルでは、碁盤の目状に Raspberry端末を配置します。各端末はビーコン信号をスキャンしてRSSI等の情報をデータベースサーバへ送ります。サーバはビーコン⇔端末の距離（半径）が短いと認識した最上位1~3の端末を特定します。端末が増えた場合でも、上位3つの端末の情報を使用します。
図9
例えば、あるビーコンとの距離が最も短かった端末がC1、2番目がＣ2、3番目がＣ3だったとします。この時、サーバはビーコンのx座標を求めるにあたって、C3端末を考慮せず、C1端末とC2端末の情報のみで算出します。算出方法は下表の通りです。
表6
| 状態 | 距離区分 | x 座標の算出時の条件 | x座標算出式 | イメージ |
|---|---|---|---|---|
| 1.分離 | A.遠隔 | 2円が一定の距離を超えて分離し、C1の半径(C1r)がC2の半径より小さい | C1x + C1r |
|
| B.近接 | 2円が一定の距離以内で分離している | C1x + d/2 |
|
|
| 2.交差 | C.C2円周中心内 | 2円が交差し、C2の円周がC1の中心を超えることは無い | C1x +C1r- d/2 |
|
| Ce.C2円周中心内・極小 | 上記Ｃと同条件で且つ、C2半径に比したC1半径が一定の比率以下（C1の半径が非常に小さい） | C1x+c1r |
|
|
| D.C2円周中心外 | C2の円周がC1の中心を超える | C1x |
|
|
| 3.包含 | D.C2円周中心外 | C2がC1を包含する | C1x | 
|
y座標についても上表のルールに準じて、C1 と C3 を使用の座標とで算出します。
二円指向三点測位のテスト
テストの際は、図9のように端末4台とビーコンを配置しました。図9の「B」の地点には、固定ビーコンも含めて4~5台のビーコンがあり、固定ビーコンを含め計40台のビーコンを使用しました。端末と同位置に見えるビーコンは、端末の直下1mに配置しています。図7のように端末とビーコン間には壁や窓があり、電波はかなり悪い状態と推定されます。下図が上述のロジックに基づき作成したプログラム「tpclocation.js」 により端末が送ってきたデータを補正・描画したものです。● が「二点指向測位」による算出された座標、■が実際の座標です。
図10
 |
| 端末位置(各円の中心)と端末からビーコンまでの距離を tpclocation.js により表示 |
凡例
Teminal: 使用した端末名
x: x座標, y: y座標
Distance: 端末からビーコンまでの距離（半径）
Acual（■）: ビーコンの実際の位置
Calc.（●）: 二円指向三点測位に基づき算出されたビーコンの位置
Gap: | Actual.x - Calc.x | + | Actual.y - Calc.y | 、誤差（Distance error）
結果
40台のビーコンを二円指向三点測位した結果は下記の通りです。平均誤差 (Average distance error)：2.36m
最大誤差 (Maximum distance error)：6.03m
さて、今回提示した二円指向三点測位は端末を正方形状に配置することを前提にした測位モデルでしたが、次回は正方形のセンタに端末を付加することにより、測位精度の向上を目指します。このセンタ端末と他の端末には角度が付くため、二円指向三点測位は拡張することになります。
また、端末間の距離を4mから、8m、16m、32mとしたとき、どの程度の誤差で測位できるのかも検証します。 詳しくは［次稿］をご覧ください。
（土屋）
参考サイト：
^[1]Beaconを使った近距離測位の特性［Aplix社］^[2]Intersection of 3 circles calculator (13のプロットパターンを表示)
Talk:Trilateration/Archive 1 (Wikipedia で「Trilateration」 が「Multilateration」に統合された理由、C++のソース等)
IPS関連のBlog記事
- iBeacon/Raspberry Pi による室内移動体位置監視モデル1 ～ 概要 ～
- iBeacon/Raspberry Pi による室内移動体位置監視モデル 2 ～ RSSI・距離補正と三点測位について ～
- iBeacon/Raspberry Pi による室内移動体位置監視モデル 3 ～ 二円指向三点測位の拡張 ～
- 東京ドームのような広い場所で少ない受信機によりビーコンのおおよその位置を推定する
- 機械学習によりIPSの位置測位精度を改善する
- IPSのテストベッドをつくる際のTIPS ― デバイスの保護とスマート電源
- FileMaker用IPSアプリケーション・テンプレート ― QuickIPS ―
- 人・モノの動きをマップ上で可視化するオブジェクトトラッキング
- 位置情報をUDPで送信 ― TPC_IPS/QuickIPSの拡張
