ラベル 屋内位置情報システム(IPS) の投稿を表示しています。 すべての投稿を表示
ラベル 屋内位置情報システム(IPS) の投稿を表示しています。 すべての投稿を表示

2020-12-26

機械学習によりIPSの位置測位精度を改善する


お知らせ

 屋内測位システム『TPC_IPS Ver1.0』を2022/4/1にリリースしました。

 同製品に関する質問またはデモを希望されるお客様はこちらよりお申し込みください。

 尚、外部のIPS/RTLSと連携して動作するIPSアプリケーション・テンプレート『QuickIPS』及び 『TPC_IPS Web API』 も順次リリースを予定しています。


  弊社では Raspberry Pi とビーコンを利用した IPS(Indoor Positioning System / 屋内位置測位システム ― 屋内のモノの位置を推定するシステム)を開発しており、昨年、独自のアルゴリズム・TCOT(二円指向三点測位)に基づくシステムのプロトタイプを本ブログと YouTube にて紹介しました。

 TCOTを含む三点測位系の位置推定は、フィンガプリント方式に比べ事前のデータ蓄積・データ更新が不要な点が大きなメリットですが、反面、測位精度が低いのが弱点です。

 今回、Raspberry Pi(以下、端末と呼ぶことがあります)とビーコンをテスト環境に敷設し、予めビーコンと端末の位置座標と、端末が取得したビーコンのRSSIをデータベースに記録(これを「フィンガプリント」と言います)し、そのフィンガプリントデータを機械学習にかけてることにより、測位精度がどの程度向上するのかを検証しました。

 機械学習ツールは多くありますが、今回はノープログラミングで利用できる Orange と、Pythonの機械学習ライブラリとして有名な scikit-learn を使用し、それぞれで得た推定位置の結果を matplotlib によりプロットしています。


テスト環境

 テスト環境は当社事務所にAplix社製ビーコン54台とRaspbery Pi 端末13台を下図のように配置し、構築しています。端末13台は4mを辺とする正方形の4頂点上に配置し(これをグリッドと呼びます)、さらに各正方形の中心にも端末を配置しています。位置測位の対象となるビーコンは図の[R]と[B]の両方に配置しています。

 



データと特徴量について

 フィンガプリントを記録するデータベーステーブルには多くのフィールドがありますが、機械学習で使用する特徴量には端末の名称(下図のN1T、N2T、N3T・・・)、各端末が取得したRSSIに基づき算出したが端末からビーコンまでの距離(N1R、N2R、N3R・・・)を取り、目的変数(ラベル)はビーコンの位置座標(ax, ay)となります。 

データベーステーブルに記録されたフィンガプリント(一部)をExcelで表示


機械学習による位置推定

 

TCOTによる位置推定

 機械学習に入る前に、当社の二円指向三点測位(TCOT)により算出した推定位置を  matplotlib によりプロットした結果を以下に提示します。

図1:TCOTによる位置推定のプロット


 各矢印の始点が実際のビーコンの位置、終点がTCOTにより算出された推定座標となります。 

 以下では今回使用する機械学習のツールについて説明すると共に、TCOTで使った同じデータを機械学習に適用し、どの程度、推定位置が改善するかを見ていきます。

 

Orange Data Mining による位置推定

 今回使用した機械学習ツールの1つが Orange Data Mining で、スロベニアのリュブリャナ大学が開発提供するオープンソースのデータマイニングツールです。どなたでも無料ダウンロードして使用することができます。
 本ツールでは、データ読み込み、モデル定義、予測、出力までの流れを GUI で組み合わせていくことにより、ノープログラミングで機械学習を実行できます。

 操作画面のサンプルは以下のようになります。

 今回は 数多くある機械学習の手法の中のk近傍モデル(kNN)を用いてビーコン位置の推定を行いました。kNNでは、あらかじめ教師となるデータを収集し、データは全て数値に変換されます。次に運用データ(機械学習の教科書では、"テストデータ"と呼ばれます)をkNNに渡すと、各テストデータが最も近接する教師データに分類され、それが持つ目的変数(ここでは教師データのxとy座標)を返してきます。

 下図が Orange kNNの返してきたビーコンの推定位置をプロットしたものです。予め教師データを作成するというコストはかかりますが、図1のTCOTに比べると推定位置の誤差は改善されいます。

Orange kNN で指定した主なパラメータ:

  • k:1
  • メトリック:Manhattan
  • Weight:Distance

注:
kNNは教師データに基づき分類を行うアルゴリズムであり、本例では教師が持つ目的変数(x、y座標)に分類されます。従って、上図でビーコンが座標(0.5,0.5)に位置する場合でも、アルゴリズム的には座標(0, 0)が正解値となります。


scikit-learn による位置推定

 次に、Google が提供するオープンソースの Python 用機械学習ライブラリ scikit -learn を使用します。

 ここでは Orange Data Mining と同様に k近傍法(最近傍法)を採用します。ビーコン座標の予測モデル関数として KNeighborsClassifier、KNeighborsRegressor の二つを使います。

 

KNeighborsClassifier による位置推定

 ここでは K近傍法のクラス分類となる KNeighborsClassifier 関数を使い、教師あり学習によりビーコンの位置を推定します。ラベル(分類クラス、目的変数)は X座標、Y座標 の多クラスを与えます。

パラメータ指定:

nbrs = KNeighborsClassifier(n_neighbors=1, metric='manhattan', algorithm ='brute', weights='distance')
nbrs.fit(teacherData, teacherXYLabel)
prediction = nbrs.predict( testData )


パラメータ指定:

  • k:1
  • アルゴリズム:brute
  • メトリック:manhattan
  • Weights:distance


 プロット結果は Orange とほぼ同等となりました。ただ、Orange と scikit-learn で同じ kNNを使いながら、個々のビーコンの推定座標に違いがありました。kNNは比較的単純なアルゴリズムなので Orange と scikit-learnで同じ結果を返すものと思っていたのですが、少し意外でした。この理由は、Orange では指定できない、brute(総当り) にあるのかもしれません。

 

KNeighborsRegressor による位置推定

 ここでは K近傍法の回帰分析となる KNeighborsRegressor 関数を使うことによって、教師あり学習により位置を推定します。ラベル(分類クラス、目的変数)として X座標、Y座標 の多クラスを与えます。

パラメータ指定:

nbrs = KNeighborsRegressor(n_neighbors=1, metric='manhattan', algorithm ='brute', weights='distance' )
nbrs.fit( teacherData, teacherXYLabel )
prediction = nbrs.predict( testData )

主なパラメータ指定:

  • k:1
  • アルゴリズム:brute
  • メトリック:manhattan
  • Weights:distance

  KNeighborsClassifier 関数と同一のプロット結果となりました。

 

参考リンク:
k近傍法
2.4 アルゴリズム1 k-最近傍法

今後の課題

 今回、いくつかの方法でビーコンの位置推定を試みました。scikit-learn のkNN関数で指定したパラメータは、GridSearchCV により得られた最適解を使用していますが、特徴量スケーリングの改良などにより位置推定の精度をもう少し上げられるかも知れません。ニューラルネットワーク(MLPClassifier)も試してはいるのですが、まだ良い結果を得られていません。今後はMLPClassifierを含むその他のエスティメータも試用していく予定です。

 また、エスティメータ以前に、取得したデータを見るとRSSIの振れ幅が大きい端末があり、この振れ幅が位置推定に悪影響を及ぼしていると思われます。この振れ幅を抑えるハードウェア的なアプローチの検討の方がより重要かもしれません。


Varista について

 Webで上でプログラミング無しで利用できる機械学習ツールに Varista があります。以前に無償版を試用してみたのですが、上記の同じデータをアップロードできず、しばらく放置していました。年末、ダメ元で Varista に問い合わせたところ、思いがけず迅速・適格な回答を貰い、アップロードができるようになり、位置推定の結果(CSVファイル)を取得できました。そのファイルをプロットしたのが下図です。 

 Varista は決定木ベースのアルゴリズムを使用しており、設定可能なパラメータが多数あります。今回はほぼデフォルトのまま使用しましたが、上述の kNN と遜色ない結果が得られました。 このことから IPS では決定木関連のアリゴリズムも有望と思われます。

Varistaの「エキスパート」画面 ― 多数のパラメータを設定できる

 Varista には API は無いようですが、WebからテストデータをPostすると、即結果を返してくれるようなAPIがあればウレシイ、というユーザもいるのではないでしょうか。


 2021/01/05追記(亀)


(亀)

IPS関連のBlog記事

土屋企画のIPS製品について/IPS product of TPC

2020-11-11

東京ドームのような広い場所で少ない受信機によりビーコンのおおよその位置を推定する

  IPS(Indoor Positioning System、屋内測位システム ― 屋内で人・モノの位置を把握するシステム)には、三点測位、フィンガプリント、AoA/AoD、GMM、機械学習等々、様々な方式があり、測位の精度を競い合っています。ネットを検索すると関連の記事や論文が多数見つかります。

 ただ、すべてのシステムの要求仕様が、誤差1m未満の精度を求めているわけではなく、位置は大雑把にわかれば良い、その代わり(ビーコン信号の)受信機を減らしたい、というモノもあります。
 例えば、老人ケアセンターであれば、入居者の存在確認(施設から黙って抜け出していないか)が最重要で、位置については大体の位置を把握できれば十分ということもあります。
 また、大規模な工場、資材置場、倉庫などで、フォークリフトや運搬機などの大きな機材にビーコンを取り付けてその所在地を把握するようなシステムでは、誤差1mの精度は要求されないことも多いでしょう。

 今回は、東京ドームかそれ以上に広いエリアにあるビーコンのおおよその位置(エリア)を、できるだけ少ない受信機(Raspberry Pi)で推定する方法について考えて見みます。
 尚、このエリアは障害物がほとんど無い、大規模な工場や倉庫のような場所を想定しています。

受信機の配置を考える

 下図でピンクが受信機(Raspberry Pi)でブルー(B)がビーコン(iBeacon)です。ビーコンは枠内にあり、ビーコンの信号を遮る障害物はほぼ無いもとします。

【グリッド】


 この時、ビーコンの「おおよそ」の位置を把握するためには、受信機をどの位の数、配置すればよいでしょうか? 結論から言うと、それはユーザの求める推定位置の精度、「おおよそ」に依存します。 基本的にエリア内の受信機が多ければ多いほど、推定位置の精度は上昇します。 今回は受信機の数を少なく抑えて、「おおよそ」の位置を把握する(精度は重視しない)というテーマで考えていきます。

グリッドについて

 上図をグリッド(但し、ビーコンは除く)と呼びます。 受信機(ピンク)は正方形の4つの角と中心に置きます。 この正方形の一辺の長さをグリッドサイズと呼びます。広大なエリアをカバーする場合、複数のグリッドを置くことになるので、グリッドサイズが大きければ大きいほど、使用する受信機の数は減少します。

使用ビーコン

 使用するビーコンの信号の最大到達距離は100m以上とします。ちなみに、Aplix社のビーコン信号最大到達距離は100m丸紅情報システムズ社のビーコンは150mとWebサイトに書かれています。

グリッドサイズ50m

 ビーコンが受信機から離れれば離れるほど、受信機はそのビーコンの信号を検知できない(非検知)可能性が高くなります。 すべての受信機がビーコンを検知しない可能性が最も高いのは図の4つのビーコンの位置です(検知困難地点)。ここでビーコンBについて考えます。ビーコンBは受信機A、B、Cから25mずつ離れていますが、障害物が無い場所ではA、B、Cのいずれもがビーコン信号を受信する可能性は高いです。各受信機がビーコンから信号を受信すると、信号の強度(RSSI)からビーコンまでの距離を算出します。 受信機を円の中心とし、算出した距離を半径とする円周上近辺にビーコンが存在すると推定されます。ここでは3つの受信機が信号を受信しているので、3つの円が交わった黄色のエリアにビーコンが存在すると推定されます。


グリッドサイズ150m

 次にグリードサイズ150mのビーコンB(検知困難地点)について考えます。このケースでは受信機からビーコンBまでの距離は75mです。75m離れていると非検知の可能性が高まります。ここでは受信機AがビーコンBを検知できず、受信機BとCが信号を検知したと仮定します。このとき受信機BとCを中心とする円の交差する黄色エリアにビーコンBがあると推定されます。


グリッドサイズ200M

 最後にグリッドサイズ200mのケースです。この場合、受信機A、B、CからビーコンBまでの距離は100mとなります。100mとなると受信機がビーコンの存在を検知しない可能性がさらに高まります。下図では、ビーコンBを検知した受信機がCのみだったと想定しています。この場合、ビーコンはCを中心とする円の円周付近上にあると推定されます。
但し、100mになると元々低いRSSIの精度がさらに低くなるため、円周の外側と内側に大きく逸脱して存在する可能性が高くなります。下図で黄色エリアがドーナツ型なのはそれを表しています。

 

  尚、受信機とビーコン間の距離が100mある場合、どの受信機にも検知されない可能性も十分ある点にもご留意ください。

受信機からビーコンまでの距離について

 RSSIの精度はもともと低いので、それを元に算出される距離の精度も低いです。特に30m以上になると、RSSIが「0」(RSSI測定不能)になったり、値が想定される値とはまったく違ったり、あるいは信号自体が検知されないことが普通にあります。 
 下図はAplix社のビーコン2台と丸紅情報システムズのビーコン3台のRSSIの計測結果です。この時は、Aplix社のビーコンの1台は25m以上になると検知されないことが多く、丸紅はより頻繁に検知されましたが、RSSIは想定される値と大きく異なっています。
 RSSIまたは距離の精度を上げるには、なんらかの補正が必要となります。

※RSSIが継続的に0になる、或いはRSSI補正が不能なほどRSSIの精度が低い状況では、グリッドサイズの短縮を検討しましょう。

BLE 5 対応ビーコンの到達距離

 上述のAplix社と丸紅社のビーコンは BLE4 の規格に準拠していますが、現在は BLE5 の対応のチップも Nordic Semiconductor 等からリリースされています。 BLE5対応ビーコンの信号到達距離は、"理論的は"BLE4対応ビーコンの4倍となります。2020年11月現在、BLE5に準拠した長距離ビーコン(Long range beacon)で技適を取得している製品は市場にありませんが、今後対応製品が発売されると、障害物が少ないところであれば400m超のビーコン探知が可能になるとものと期待されます。

人や障害物が少なからず存在するエリアについて

 繰り返しとなりますが、上記は障害物がないエリアを想定しています。人が多くいたり、壁や棚などの障害物がある場合、適切なグリッドサイズは4m~15m程度になります。また、人が密集する展示場やイベント会場、金属製の背の高い棚が多く置かれている倉庫などでは、IPSによる測位がそもそも困難・不能なケースもあります。


NuckyT



IPS関連のBlog記事

土屋企画のIPS製品について/IPS product of TPC

2019-07-12

iBeacon/Raspberry Pi による室内移動体位置監視モデル 3 ~ 二円指向三点測位の拡張(TCOT)と測定結果 ~

[English page]

お知らせ

 屋内測位システム『TPC_IPS Ver1.0』を2022/4/1にリリースしました。

 同製品に関する質問またはデモを希望されるお客様はこちらよりお申し込みください。

 尚、外部のIPS/RTLSと連携して動作するIPSアプリケーション・テンプレート『QuickIPS』及び 『TPC_IPS Web API』 も順次リリースを予定しています。


 前稿では 碁盤目状(正方形型)に配置した Raspberry Pi (以下、端末、と言うことがあります)により iBeacon(以下、ビーコン、と言うことがあります)の信号強度(RSSI)を測定し、「二円指向三点測位」という方法でビーコンの位置を算出しました。

 本稿では前稿の「二円指向三点測位」を拡張し、正方形型に限定されず端末を自由に配置できるようにし、費用対効果(費用対測定精度)を上げ、またシステム導入施設・場所の状況に合わせた端末配置を行えるようにします。

旧版の二円指向三点測位のイメージ


 前稿の二円指向三点測位(以下、旧版、と呼びます)では端末を正方形型に配置し(図1のA~I)、ビーコン(図1のB)のRSSIを測定して端末とビーコン間の距離(=半径)を算出しました。通常の三点測位では3円が重なっていないとエラーとなりますが、本測位モデルでは C1 と C2 (図では E と F)で x 座標を、C1 と C3(図では E と B) で y 座標を算出することにより、ビーコン(B)の位置と推定しました。

図1:二円指向三点測位(旧版)のイメージ
Image of 2 circles-oriented trilateration (old ver)
 なお、旧版の二円指向三点測位については前稿を参照してください。

二円指向三点測位の拡張(TCOT)


 旧版の問題の一つは、端末が常に正方形型に配置されて、位置測定に関わる各端末が水平、及び垂直に存在することを前提にしていた点です。このことは保守及びコスト面の問題につながります。
 そこで今回は端末を柔軟に配置できるように二円指向三点測位を拡張(この拡張版を以後、TCOT と呼ぶことがあります)してみました。

TCOTのイメージ

 TCOT について説明します。図2は図1の各正方形の中心部に一つずつ端末を追加したものです。13個ある端末(A~M)のうち、ビーコン(B)を最も近距離に感知した端末は、より近距離に感知した順に E(円C1)、K(円C2)、B(円C3)だったとします。

 このとき、C1とC2に着目します(二円指向)。センタ無の正方形型配置のときは、C1 と C2 から x 軸(横軸)のみを算出しましたが、今回は 円C1 と 円C2 が垂直に位置しないため、この時点で x 軸を決定してしまうのは抵抗があります。そこで、円C1と円C2の交わった青いエリアをビーコン位置の候補とします。
 次に円C3とその半径により、青いエリア内からビーコンの位置を特定します。円C3が青いエリアまで届いていないため、青いエリア内で円C3に最も近いの地点をビーコンの位置と決定します。
 C1とC2で候補エリアを、C3がそのエリア中から最終座標を決定する、というのがTCOTのおおまかなイメージです。
図2: 二円指向三点測位拡張版 (TCOT)

グリッドタイプ


 端末の配置型をグリッド、或いはグリッドタイプと呼びます。

図3:グリッドタイプ

Grid type

 「正方形+センタ型」は端末の増加を抑えつつ、測位の精度向上を目的とします。例えば、16mの「正方形型」で測位精度が出ない場合、8mグリッドに変更するのは費用的且つメンテ的にも大変なので、各正方形の中心に端末を追加することによって、測位精度向上を図ります。

 「正三角形型」がグリッドはシステム導入場所の形状に合わせて使用します。

 TCOT は「正方形+センタ型」や「正三角形型」に対応しますが、1つのグリッドタイプに限定されず、端末を自由に配置できるように設計されています。
 尚、本稿では、正三角形型は取り扱いません。
 TCOT の計測結果を記す前に、今回行ったテストのシステム構成概要を記しておきます。

システム構成概要

製品名 説明
iBeacon Aplix社製 MyBeacon® Pro MB004Ac-DR2、50台(補正用固定ビーコンを含む)
Raspberry Pi Zero W/WH(受信機) 小型コンピュータ、iBeacon が発する信号の受信端末として13台を使用。node.js 参照
SQLite 3 データベース、node.js 参照
Python 3/sym.py 開発プラットフォーム、Raspberry Pi がデータベースに記録した情報をもとに、二円指向三点測位(TCOT)を実行するプログラムを開発。
node.js
  • 開発プラットフォーム、iBeacon からの信号受信、加工、データベースへの書き込みを行うプログラムを開発。本プログラムは Raspberry Pi 上に常駐し、PC等のクライアントのリクエストに応じて上記処理を実行する。
  • plotly と連動して Raspberry Pi、ビーコンの位置情報をプロットするプログラムを開発。本プログラムはサーバ上に常駐し、PC等のWebクライアントのリクエスト応じて上記処理を実行する。
plotly.js node.js 参照
Fabric PC等クライアントから複数の(本テストでは13台の) Raspberry Pi に対して一斉にコマンドを実行するツール。  


計測テストの結果


写真1:計測テストの現場
 今回は上述のグリッドタイプで「正方形型」と「正方形+センタ型」を対象にして、グリッド幅をそれぞれ 4m、8m、16m、32m* に設定してテスト測定を実施しました。
 「正方形型」については二円指向三点測位の旧版を、「正方形+センタ型」については二円指向三点測位の TCOT を適用しています。
 旧版では 41個のビーコンを、TCOT では 37個のビーコンを計測対象としています。旧版と TCOT で個数が異なっている理由は、TCOT では4個を補正用ビーコン(固定ビーコン)として追加使用しているためです。

 下の2つの図がその結果で、ビーコンの実際の座標と計測された座標の誤差に関する値を数値及びグラフで表しています。

 個々のビーコンの実際の位置座標と、計測された座標の誤差(Distance error)は下記の式で算出しています。

Distance error = |actual_x - estimated_x| + |actual_y - estimated_y|

 actual_x, actual y がビーコンの実際の座標、estimated_x, estimated_y がシステムにより算出された座標です。この値が0であれば、実際の座標と計測された座標が一致していることを示します。個々のビーコンの誤差を求め、その平均値(Error Ave)、最大値(Error Max)、エラー率を表示しています。尚、最小値は旧版、TCOT 共に おおよそ 0 となったので、省略しています。

 エラー率(Error rate)は下記の式で求めています。

Error rate = Error Ave / (Grid distance *2)

 この数値は、誤差の平均値をグリッド距離(水平+垂直)で割って誤差率を算出しています。この数値が小さいほど、グリッド距離に比してビーコン位置が良り正しく算出されていることになります。

図4: 旧版/9端末/正方形型で実行時の誤差
Distance errors when using old ver, 9 terminals, square grid + cnter
* 32mグリッドは16mグリッドのデータを転用し、B, D, E, F, H の端末を除外して4つの端末のデータのみを使用して座標を算出しています。

 上図は二円指向三点測位の旧版を使用していることに留意してください。


 誤差率はグリッド幅が広くなるに従い低くなります(改善する)が、32mグリッドでは高くなります(つまり悪化します)。これは今回のテスト環境では、ビーコン信号と端末間の距離が30m位になると、もともと精度が低いRSSIがさら劣化することを示唆しています。
図4: TCOT/13端末/正方形型+センタ で実行時の誤差


* 32mグリッドは16mグリッドのデータを転用し、B, D, F, H, J, K, L, M の端末を除外して5つの端末のデータのみを使用して座標を算出しています。


 上図は二円指向三点測位の拡張版 TCOT を使用していることに留意してください。

 正方形型と旧版による測位よりも、正方形 + センタ型と TCOT(ver01) による測位の方が計測精度が向上しています。

 下図は旧版と TCOT(図では ver01) を比較したグラフです。 


 赤線は改善率を示しています。旧版に比し TCOT(ver01) が 15%~30%超改善していることがわかります。

個別プロット

 上記のTCOTにより取得・生成されたビーコンの位置情報データをプロットしたファイルを、以下に公開しました。 TCOTは旧来の三点測位とは異なり、3円が交わらなくても位置座標を算出しますが、このプロット図ではTCOTが結果が可視化されています。

二円指向三点測位バージョン
(TCOT ver. used)
グリッドタイプ
(Grid type)
グリッドサイズ
(Grid size)
ダウンロード
(Download)
旧版(Old) 正方形(Square) 4m × 4m 4mGrid_R9I_old.pdf
旧版(Old) 正方形(Square) 8m × 8m 8mGrid_R9I_old.pdf
旧版(Old) 正方形(Square) 16m × 16m   16mGrid_R9I_old.pdf
旧版(Old) 正方形(Square) 32m × 32m   32mGrid_R9I_old.pdf
TCOT(ver01) 正方形+センタ(Square + center) 4m × 4m 4mGrid_R13c_ver01.pdf
TCOT(ver01) 正方形+センタ(Square + center) 8m × 8m   8mGrid_R13c_ver01.pdf
TCOT(ver01) 正方形+センタ(Square + center) 16m × 16m 16mGrid_R4Ir_ver01.pdf
TCOT(ver01) 正方形+センタ(Square + center) 32m × 32m 32mGrid_R5c_ver01.pdf


全ビーコン一括プロット(2020/7/27追記)

 上記の個別プロットとは異なり、本プロット図にはすべてのビーコンの実際の位置とTCOTにより算出された推定位置が表示されます。
 TCOTには個別プロットと全ビーコン一括プロットの機能があります。

凡例:●→● の矢印の出元のは実際のビーコンの位置、矢印先のは推定位置、は補正用固定ビーコン


TPC IPS (Protoype)


 上記のテストを自動化するため、TPC IPS の屋内測位システムのプロトタイプを開発しています。TPC IPS は大きく分けて FetchB と TCOT という2つのモジュールで構成されます。

FetchBについて


 FetchB は アプリケーションサーバ上に配置され、Raspberry Pi(受信機、RP)にビーコンのスキャンを行なわせ、RPが取得したUUIDやRSSI等のデータをデータベースに記録します。

 FetchB は1回の実行で多数の RP に対してコマンドを実行することができます。


TCOTについて


 TCOT は FetchB によりデータベースに記録されたビーコン情報を抽出し、上述の二円指向三点測位に基づく座標計算を行い、各ビーコンの座標を出力あるいはプロットします。 以下の動画では TPC IPS の TCOTモジュールについて解説しております。



以上



(土屋)



IPS関連のBlog記事

土屋企画のIPS製品について/IPS product of TPC

2019-04-02

WiFi APによる中継と、複数Raspberry Piと複数APの登録・接続

 屋内位置情報システム(IPS)を構築する際には、ビーコン信号を Raspberry Pi (以下、RP と呼ぶことがあります)などのワイヤレスの受信機で受信し、さらにそこから WiFi を介してサーバに送るといった状況が発生します。
受信機と有線LAN間を結ぶのモノが WiFiアクセスポイント(以下、AP と呼ぶことがあります)です。
 APは通常、LANケーブルにより有線ハブに接続されていますが、LANケーブルの引き回しが困難なこともあります。その場合、親機のAPのみをLANケーブルで有線ハブに接続し、子機APは親機APへの中継器として使用します。

 今回、中国TP-LINK社の TL-WR802N(写真)を使用し、どのように中継器を構成ができるのかテストしてみました。ちなみに、この製品の電力要件は 5V/1A で、Micro USBケーブルを介してモバイルバッテリと接続して稼働するため、LANケーブルの敷設と電源供給が難しい屋外でのテストで威力を発揮します。
 あるAP と RP 等のデバイスの間隔が離れすぎてしまいAPがデバイスのWiFi信号を十分な強度で拾えないような場合、他のAPを中継器として使用します。
屋外でのIPSテスト。Raspberry Pi (RP) と TL-WR802N、共にモバイルバッテリだけで1日は十分稼働する。

 また、本稿の後半では、多数の RPと AP を効率的に登録及び切り替えする方法について考えます。

WiFi の中継タイプ

 TL-WR802N は以下のいずれの中継タイプであっても、子機AP2~4を経由して親機AP1に接続することができました。ただ、設定時にはブラウザから接続できなくなったりすることも多く、モードを変更するとそれまで行った設定が飛んだりで、癖がある製品であるように思いました。
 尚、上の写真のように障害物の無い環境では、AP間は70m程度の距離があっても電波を送受信できました。未検証ですが、下表の直列型にすれば70m×5で350mはWiFi通信できるものと推定されます。

WiFi中継タイプ イメージ
直列型
スター型
折衷型
注:通常、AP1 は有線ハブに接続され、RPを社内LANに接続する。

NetworkManager の nmcli による WiFi接続と管理

 小社では Raspberry Pi のネットワークインタフェース設定には NetworkManager を採用したため、ここでは NetworkManager による WiFiアクセスポイント(AP)接続の登録方法と切替方法についてご紹介します。
 ※屋内位置情報システム(IPS)で RP などの受信機と APを多数運用する場合、一括管理できる仕組みも併せて考慮する必要が出てきます。

Wifi 接続の登録方法

 NetworkManager を使って WiFi AP (SSID) を登録する方法は以下の 3 とおりがあります。 尚、以下、AP と SSID はほぼ同義に使用されていることがあります。

  1. GNOME を使う(GUI)

     GNOME が利用できる環境では、GUI によりAP(SSID)を設定できます。NetworkManager インストール時に GNOME をインストールしなかった場合は、以下のコマンドを実行することにより、GNOME をインストールします。
    sudo apt-get install network-manager-gnome
    コマンド実行後に Raspberry Pi を再起動すると、画面上部に以下のアイコンが表示されるようになります。

     新規に接続を作成する場合は、上記の NetworkManager アイコンをクリックします。現在の接続状態と、利用可能な AP の一覧が表示されますので、その中から接続したい AP を選択します。

     たとえば、tpctp1 に接続したい場合は、以下のように選択します。
     利用可能一覧に AP が表示されていない場合は、その他のネットワークを選択すると、さらに接続可能な AP が表示されますので、そのなかから選んで接続します。


     この要領で接続をすると、多くの場合は AP の DHCP 機能により IP が割り振られることになります。
     固定 IP を振り直したい場合は、NetworkManager アイコンを右クリックし、「接続を編集する...」メニュー項目を選ぶと、登録済の接続情報の一覧が表示されますので、そのなかから変更対象の接続を編集します。


  2. nmcli コマンドを使う

     GNOME を使用しない場合は、nmcli コマンドで接続管理ができます。
     基本的には以下のシナリオで作業を行います。

    1. 既存の AP に接続要求

      以下のコマンドを実行することにより、任意の AP に接続
      nmcli d wifi connect SSID password PASSWORD
      (赤字部分が指定したい SSID とパスワード)
      上記の指定情報をもとに接続が試行されます。接続に成功すると接続設定ファイルが /etc/NetworkManager/system-connections/ ディレクトリ配下に作成されます。
    2. 上記で作成された接続ファイルに固定 IP アドレス、および DNS サーバの IP アドレスを設定

      以下のコマンドを実行することにより、1. で作成された接続設定ファイルに固定 IP アドレスと DNS サーバの固定 IP アドレスが登録されます。
      nmcli connection mod SSID 802-11-wireless-security.key-mgmt wpa-psk 802-11-wireless-security.psk PASSWORD ipv4.method manual ipv4.addresses "192.168.3.10/24" ipv4.gateway "192.168.3.1" ipv4.dns "192.168.3.100"
      赤字部分が編集対象となる SSID とそのパスワード )
      ここでは、固定IP アドレスとして 192.168.3.10、デフォルトゲートウェイが 192.168.3.1、DNS サーバが 192.168.3.100 であることを想定しています。
    3. 再接続による変更内容の反映

      接続設定ファイルを書き換えが終わったら、一度接続を停止し、再度接続することにより、変更内容を反映させます。
      nmcli connection down SSID
      nmcli connection up SSID

  3. シェルスクリプトで一括登録する

    使用する Raspberri Pi(RP) 端末と WiFiアクセスポイント(AP) の台数が少数であれば、GNOME で簡単に設定を行えますが、その数が数十台になると GNOME で一台一台、設定および管理するのは時間的、労力的に厳しくなります。

     そこで前述の nmcli コマンドにより、自動接続および接続ファイル生成を繰り返し、複数の Raspberry Pi に複数の AP を登録するシェルスクリプトを作成して実行するようにします。

    以下のシナリオで作業を行います。

    1. 事前に登録対象の SSID と パスワードを格納した設定用のファイルを準備

      ここでは、タブ区切りで SSID およびパスワードの組み合わせを記述したファイル(ssid.txt)を用意します。
      たとえば、このように記述します。
      ssid.txt
      tpctp1    111111
      tpctp2    222222
      tpctp3    333333
      

    2. 一括 SSID 登録シェルスクリプト (tpccon.sh) を準備

      事前に、引数として渡す Raspberry Pi の固定 IP アドレス、デフォルトゲートウェイ、DNS サーバの IP アドレスを記述しておきます。
      以下の 4~6 行目の ip、gateway、dns 変数の内容を任意のものに書き換えます。

      tpccon.sh
      #!/bin/sh
      
      ip="192.168.3.10"
      gateway="192.168.3.1"
      dns="192.168.3.100"
      
      sh delcon.sh
      sh _subcon.sh $ip $gateway $dns

    3. 既存の接続ファイルを削除するためのシェルスクリプト(delcon.sh)

      すでに登録済の接続ファイルが存在する場合、接続コマンドを実行する度に、「MySSID 1」、「MySSID 2」、「MySSID 3」のような同じ SSID に番号が付番されたファイルが生成されてしまいます。

      このため、後々の接続管理を容易にするために、事前に既存の接続ファイルを削除するためのシェルスクリプト(delcon.sh)を用意します。
      前述の ssid.txt ファイルに登録されている SSID を順に読み込み、その名前がついている接続を削除します。

      delcon.sh
      #!/bin/sh
      
      # delete access point files
      
      DATA=`cat ssid.txt`
      
      while read line
      do
          ssid=${line% *}
          sudo nmcli connection delete $ssid
          sudo nmcli connection delete "$ssid 1"
          sudo nmcli connection delete "$ssid 2"
          sudo nmcli connection delete "$ssid 3"
          sudo nmcli connection delete "$ssid 4"
          sudo nmcli connection delete "$ssid 5"
      done << FILE
      $DATA
      FILE

      このサンプルスクリプトでは、1~5 までの冗長な接続ファイルが存在する可能性を考慮して固定で 5 まで強制的に削除するようにしています。存在している接続ファイルの一覧を取得して、それらを全て削除するようにすると良いのですが、今回は手抜きをしました。

    4. SSID を自動登録するためのシェルスクリプト(_subcon.sh)

      1. の ssid.txt に指定されている情報を順に読み出し、SSID を登録するシェルスクリプト(_subcon.sh)を作成します。
      このシェルスクリプトは呼び出し元の tpccon.sh の引数を取るため、サブスクリプトとして動作します。このため、便宜的に先頭にアンダスコアを入れてあります。

      _subcon.sh
      
      #!/bin/sh
      
      ip=$1
      gateway=$2
      dns=$3
      
      # version
      ver=`sudo NetworkManager -V | cut -c 1`
      
      # create available access point files
      sudo nmcli d wifi rescan
      
      DATA=`cat ssid.txt`
      
      while read line
      do
          ssid=${line% *}
          pwd=${line#* }
          sudo nmcli d wifi connect $ssid password $pwd
      
      
          if [ $ver -lt 1 ]; then
              sudo nmcli connection mod $ssid 802-11-wireless-security.key-mgmt wpa-psk 802-11-wireless-security.psk $pwd ipv4.method manual ipv4.addresses "$ip/24 $gateway" ipv4.dns "$dns"
          else
              sudo nmcli connection mod $ssid 802-11-wireless-security.key-mgmt wpa-psk 802-11-wireless-security.psk $pwd ipv4.method manual ipv4.addresses "$ip/24" ipv4.gateway "$gateway" ipv4.dns "$dns"
      
          fi
      
          #reload and activate the connection
          sudo nmcli connection down id $ssid
          sudo nmcli connection up id $ssid
      
      done << FILE
      $DATA
      FILE
      

      これで一括 SSID 登録シェルスクリプトの準備が整いました。

    5. 一括 SSID 登録シェルスクリプト (tpccon.sh) を実行

      tpccon.sh を実行することにより、既存接続の削除→接続登録の順で全自動で処理が実行されます。
      sh tpccon.sh
      上記を実行すると、1. で定義した ssid.txt の一番最後に登録されている AP(SSID)に接続されます。
    6. TeraTermによる一括登録
      端末一台を設定するのであれば、ターミナル上で上記のコマンドを実行します。複数台の端末に対し同時に AP 登録したい場合は、TeraTerm などの一括コマンド発行ができるツールを使用して tpccon.sh を実行します。
    7. 登録状況の確認

      登録済みの接続と接続状態を知るには以下のコマンドを実行します。
      nmcli d wifi list

    8. なお、接続ファイルの実体は、/etc/NetworkManager/system-conntections ディレクトリ配下にあります。 以下のように、/etc/NetworkManager/system-conntections に tpctp1、tpctp2、tpctp3 の接続ファイルが正しく作成されていることが確認できます。

      【重要】
      使用する OS のバージョンにより、インストールされる NetworkManager のバージョンが異なることがあり、またこのバージョンの相違によって指定方法も異なるという問題があります。
      このため、一様のコマンド実行では、端末によっては設定ファイルの書き換えができないというトラブルが発生する可能性があります。

      現時点で当方が把握している情報としては以下のものがあります。

      バージョン 0.9.10.0 --- ipv4.addresses オプションに IP アドレスとゲートウェイアドレスをセットにして記述する必要あり
      バージョン 1.6.2.0 --- ipv4.addresses オプションに IP アドレス、 ipv4.gateway オプションにデフォルトゲートウェイアドレスを個別に指定する必要あり

      このため、上記のスクリプトでは、バージョンの番号別にオプション設定が切り替わるように記述してありますので、現時点では NetworkManager のバージョンが混在する環境でも動作するようになっています(今後さらにコマンド仕様が変更される可能性があります)。

Raspberry Pi の接続 

起動時の接続

 電源を投入すると、前回のシャットダウンまで接続されていた AP に接続されます。
このとき、そのAP への接続に失敗すると、NetworkManager によって他の登録済みの AP に自動接続されます。

接続先の変更

 Raspberry Pi 端末の接続先を変更したい場合は nmcli connection up コマンドを使用します。
nmcli connection up tpctp1

 複数の Raspberry Pi の AP(SSID) を一括して変更するには、TeraTerm などの接続ツールを使って複数の Raspberry Pi にログインし、以下のブロードキャスト(一括)コマンドを発行すると良いと思います。
 以下は、接続済みの端末に向けて tpctp2 という接続名の AP に一括接続切替をするためのコマンドです。
sudo nmcli connection up tpctp2
 ※ TeraTerm などのツールを使って接続切替要求を発行する場合は、sudo を付ける必要があります。TeraTerm では接続済みの端末のうちいくつかを選択(限定)して、ブロードキャストコマンドを実行することもできます。

検討課題

 iPhone では WiFi AP 毎に『自動接続』をOFFできますが、これに相当する nmcli コマンドが見当たりません。テストを行っている場合等、特定の AP のみに接続を限定したいことがあると思うのですが...。connection down というコマンドがありますが、これはAP への接続を停するだけで、iPhoneで言うところの「『自動接続』をOFF」にはならないため、電波状況によっては接続が復活してきてしまう模様です。

(亀)




2018-08-09

iBeacon/Raspberry Pi による室内移動体位置監視モデル 2 ~ RSSI・距離補正と三点測位について ~


お知らせ

 屋内測位システム『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(Received Signal Strength Indicator) はビーコンから発せられる信号の強度を示す数値で、ビーコンから離れるに従ってその強度は規則的に減衰します。ビーコン信号を受信する端末 ― ここでは Raspberry Pi(以下、RP、監視端末、端末と呼ぶことがあります)― はビーコン信号のRSSIを測定し、その減衰度により自身とビーコン間の距離を算出します。この信号強度は理論的には距離の二乗に反比例して減衰するのですが、実際には様々な電波干渉があるため、ビーコン⇔端末間の距離が長くなればなるほどRSSIのばらつきは大きくなり、その精度は劣化していきます。

図2
例:ビーコン信号強度グラフ(Aplix 社のサイトより)


 上図は、端末⇔ビーコン間の距離が1m を超えると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つの機種限定したほうが簡単ですが、将来的な入手の容易性、拡張性、柔軟性を念頭に複数のシリーズを使用しています。


システム構成概要

 ビーコンから送信される信号は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]
  1. Beaconの送信出力、アンテナのゲイン、放射パターン
  2. 受信側スマートフォンの感度、アンテナの向き等
  3. スマートフォンOS内の処理(Bluetoothスタックの振る舞い他)
  4. 周囲環境(建材、人体等)による反射・吸収・回折

 このように RSSI値は様々の要因に影響を受けるため、端末が信号を受信しても、理論値と実測値は異なります。以下のテストは、RSSIがどの程度環境の影響を受けるのかをテストし、「考察」では補正方法についても簡単に記載しています。

※Apple社ビーコン補正の適用について
 以下の文章中、「Apple社ビーコン補正」が「有」或いは「無」といった表記をしていますが、これはビーコン導入時に iPhone等によりビーコンから1m離れた地点で RSSI を測定し、その測定値の平均により補正を行ったか、行わなかったとを意味します。このビーコン補正はApple社の Getting Started with iBeacon (PDF)の「Calibrating iBeacon」の項に基づき行っています。
 ※ RSSI の距離変換
 RSSIは信号強度を対数で示した数値ですが感覚的に把握し難いため、本稿では多くの場合、距離に変換して表記しています。RSSI≒距離と考えて頂いて結構です。

テスト1 1つのビーコンのRSSIを24時間測定


目的

 固定した1つの端末と1つのビーコンを使用し、RSSIの精度、時間帯による変動をチェック

条件

  1. 1つのビーコンを1つの端末で24時間測定。
  2. 端末による1回のスキャン時間は5秒間。24時間で約1万7千のスキャンを実施。1回のスキャンで収集されるデータは平均34件、RSSIはスキャン毎に平均している。また、下図でRSSIは距離(m)に変換している。
  3. ビーコンと端末間の実際の距離:4.5m
  4. ビーコンと端末は固定してあり、移動しない。
  5. テスト中、ビーコンと端末の間、またはその周辺の人、モノの移動は最小限にする。
  6. Apple社 ビーコン補正:有

結果

 以下の2つ図は、データベースに記録されたデータをプロットしたもの。

【散布図1:時間経過と計測距離の変化】
RSSI はメートルに変換し縦軸に、横軸は計測時間

横軸に距離、縦軸に発生件数を棒グラフ化。
平均(AVG):2.75m
標準偏差(SD) :0.88m
最大(MAX):9.96m
最小(MIN):0.93m

考察

  1. 端末⇔ビーコン間の実際の距離は4.5mだが、測定値では2.75m(平均値)で、かなりの乖離がある(実際の距離とは異なる)。また、最大値と最小値の差も大きい。
  2. 日中は距離の偏差が大きく、夜間に小さい。これは夜間は人間の発するWiFi等の電波による干渉が少ないためと推定される。また、日中は夜間に比し、値が上振れする。
  3. 以上のことより、距離の精度を上げるためには、時間に連動した応じた補正が必要。

テスト2 複数端末で複数ビーコンのRSSIを測定


目的

  1. 端末の個体差はどの程度あるのか
  2. BLEデバイスが異なると、RSSIに顕著な違いは発生するのか

条件

  1. 各端末によるビーコンスキャンは10秒間、1回のみ。
  2. 各端末が収集したデータは平均で50件弱。RSSI(表のaveRssi)は平均値。また、下表でRSSIを距離(Ave)に変換している。
  3. 端末(下図のPi1、Pi5-Pi8)から1m(Dist)の所にAplix(AP)10個とGimbal(GI)20個を配置。ビーコンは多数のため、端末との距離をできる限り1mに保つため格子状のプラスチックケース等に収納した。尚、Pi5 は 3B にBLEドングルを装着したもので、内臓BLEは無効化してある。
    図4
  4. ビーコンと端末は固定してあり、移動しない。
  5. テスト中、ビーコンと端末の間、またはその周辺の人、モノの移動は最小限にする。
  6. 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.:総平均

考察

  1. 同種の端末で同環境でテストしても、RSSIの値に差がでる。また、Pi5は BLEドングルを使用しているが、他端末の値との差が大きい。
  2. 上述のビーコン補正を行わないと、実際の距離は1mであっても計測されるRSSIに対応する距離は全くかけ離れた値になることがある。
  3. 以上、端末間でもRSSIの値に差異があるため、端末単位の補正が必要。

テスト3 ビーコンとメーカーによるRSSI(距離)の差異


目的

ビーコン間、メーカー間でどの程度RSSIに差があるのかを調査

条件


  1. ビーコンはAplixを20個、Gimbalを49個、1つの端末を使用。ビーコンを丸テーブルの円周上に配置。その上部に天井から吊るした端末と各ビーコン間の距離が1mになるようにする。
  2. 端末によるキャン時間60秒×5回を1セット。1セット終了後90度テーブルを回転させ、計4セット(60秒×5回×4セット)を実行。これは端末アンテナとビーコンの位置などにより、RSSIの値が異なることを想定し、値を丸めるために実施。
  3. 計20回のスキャンで端末が受信したデータ数は1ビーコン平均で約3600件。RSSIはスキャン毎に平均。下図ではRSSIを距離(m)に変換している。
  4. ビーコンと端末間の実際の距離:1m
  5. スキャン中、ビーコンと端末は固定してあり、移動しない。
  6. テスト中、ビーコンと端末の間、またはその周辺の人、モノの移動は最小限にする。
  7. Apple社ビーコン補正:無

結果

※上のグラフで[0.2,0.25]は、距離が0.2m~0.25mと測定されたAplixビーコンが3台あったことを示す。

表3
 AplixGimbal
AVG(平均距離)
0.4m
0.19m
SD(標準偏差)
0.11m
0.08m
MAX(最大距離)
0.6m
0.4m
MIN(最小距離)
0.2m
0.1m
Data Num(データ数)
3618件
3606件

考察

  1. ビーコン個体についても計測値に差があり、最小値と最大値については3倍~4倍もの差がある。
  2. AplixとGimbalの平均値で約2倍の差がある。
  3. 以上のことから、個々のビーコンに対する補正と、ベンダー(ビーコンシステム)別の補正が必要。

 以上、時間帯、端末個体、端末種類(ビーコンシステム)、ビーコン個体、ビーコン種類(ベンダー)により、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と想定していたのですが、その場合、測定値と実際の距離の乖離が大きく、今回は端末の間隔を各4mにしました。
図のように端末は壁のすぐそばに設置されていたり、壁により隔てられており、環境は悪条件に属すると思います。ただ実際の運用環境も良い条件に無いことが想定されるため、悪条件下でのテストを実施しました。

図5:テスト環境
凡例:
a~i:Raspberry Pi 端末 ― ビーコンを探知し、RSSIを測定
Fix:固定ビーコン、端末下1mに固定された補正用ビーコン
B:測定対象となるビーコン
青点線:壁または窓、電波伝搬の障害となる


使用デバイス


ビーコン: Aplix 社製 MyBeacon 汎用型ビーコン  ― テストを単純化するため、今回は他社の製品を使用していません。
監視端末: Raspberry Pi Zero W/WH/3B/3B+ 
その他:上図3のシステム構成に準じる


次に小社で考案した3つの補正方法を提示した後、各方法毎にテスト結果を記します。


DBビーコン補正

 前述のように Apple社の補正方法は今回のモデルでは今一つの結果で、測定値(平均)の登録にも労力と時間を要します。本補正方法は、このApple社の方法を応用したものです。
 まず下図のように、円卓テーブルの円周上にビーコンを並べ、Rapberry端末から各ビーコンの距離が1mとなるように配置します。その後スキャンを数十秒から数分行い、次に円を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ビーコン補正端末補正領域補正
1m0.621.952.322.68
4m2.758.0518.861.59E+28

 残念なことに、未補正のデータが一番実際の値に近いという結果です。結果が悪いのは上述のようにデバイスが壁に近すぎたり囲まれていて、干渉が大きく影響しているためと思われます。また、「DBビーコン補正」は  RSSI@1meter の値の取得時の端末と場所が実際の端末(a~i)と異なることも要因と思われます。「端末補正」は RSSI@1meterを基に算出した端末係数を異なる距離に存在するビーコンに適用することに無理があるかもしれません。

 領域補正については指数表示になるほど実際の距離とかけ離れています。これは伝搬損失係数 n に異常値が発生しているためです。そこで、nが異常値となった等いくつかの条件下では、領域補正を適用せず、未補正の数値を使用するようにアプリケーションを変更した結果が以下となります。

表5
実距離未補正DBビーコン補正端末補正端末補正
(未調整)
領域補正
(調整有)
1m0.621.952.322.680.98
4m2.758.0518.861.59E+283.63

 調整により実際の距離に大分近くなりました。

二円指向三点測位(19/02/07加筆、19/05/10下表図等一部修正)

 通常の三点測位では、下図の「理想」のように3円が交差する状態で、以下の方程式によりその接点を求め、さらにその幾何中心を以て目標物(ここではビーコン)の位置とします。

式4
r1 =  (x - x1)2 + (y - y1)2
r2 =  (x - x2)2 + (y - y2)2
r3 =  (x - x3)2 + (y - y3)2


図8

 しかし、当方のテストではRSSI・距離の補正後も「理想」のようきれいに3円が交わることは少なく、補正されたデータでプロットしても、様々なパターンが出現します。上図の「現実」がその例で、プロットパターンは当社が認識している範囲で15になります[2]。このような3円がきれいに交差しないプロットパターンの場合、「単純に3円の交点から幾何中心を求める」だけのプログラムは破綻する(またはエラーを返す)ことになります。
 小社でも当初は上記の式4を含め、15のプロットパターンに対応した式をそれぞれ用意し、ソースコードに落とそうとしたましたが、ソースを書き始めると工数的に厳しいことがわかりました。次に発生頻度の高いプロットパターンにのみ対応させ、発生頻度の低いパターンについては「汎用処理」をなんとか捻り出すことにしました。汎用処理は後回しにして、いくつかのプロットパターンに対応したテストプログラムを用意して実行しましたが、ビーコン座標の算出の結果は良いものではありませんでした。
 そこで次に考えた苦肉の策が、上記「汎用処理」とその拡大適用(すべて或いは多くのプロットパターンに適用する、という趣旨)で、これが以下の「二円指向三点測位」です。

二円指向三点測位

 このテストモデルでは、碁盤の目状に Raspberry端末を配置します。各端末はビーコン信号をスキャンしてRSSI等の情報をデータベースサーバへ送ります。サーバはビーコン⇔端末の距離(半径)が短いと認識した最上位1~3の端末を特定します。端末が増えた場合でも、上位3つの端末の情報を使用します。

図9


 例えば、あるビーコンとの距離が最も短かった端末がC1、2番目がC2、3番目がC3だったとします。この時、サーバはビーコンの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円周中心内・極小 上記Cと同条件で且つ、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記事

土屋企画のIPS製品について/IPS product of TPC