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

2018-05-24

PostgreSQL 10 インストール時の不具合解消方法

Windows Server に PostgreSQL 10 インストール時に 「Error with Configuration or permission 」という警告が出る場合の対処方法


 Windows Server 2012 環境に最新版の PostgreSQL 10 (10.4) をインストールしてみたのですが、途中で以下の警告メッセージが表示されてしまいました。

PostgreSQL 10 インストール時に発生した警告メッセージ

 警告ダイアログには、「ログを見ろ」とあったので確認してみたところ、権限設定で失敗していた模様です(文末参照)。

 そこで、以下の方法で不具合の対応をしてみました。
  同様の不具合でお悩みの方はダメ元で試してみるとよいかもしれません。

 ※インストール失敗理由については文末の「不具合の原因」のセクションをご覧ください。

PostgreSQL 10 インストール失敗の対応方法

  1. 上記の警告メッセージが発生してもいったんは最後までインストールする
    内部的にはインストールはエラーとなるため、 このままでは PostgreSQL サーバの起動はできません。
  2.  コントロールパネルの「プログラムのアンインストールまたは変更」から PostgreSQL をアンインストールする
  3. アンインストール後に残ったインストールフォルダより、\data\pg10 までたどり、pg10 フォルダのセキュリティより、Users グループに「変更」権限を付与する
    PostgreSQL 10 の \data\pg10 フォルダの Users アクセス許可に「変更」権限を付与
  4. もう一度、Postgres 10 をインストールして成功すれば終了

不具合の原因


 結論から述べると、PostgreSQL 10 を Windows にインストールした際に、以下のメッセージが出た場合は、権限設定エラーが発生した可能性が高いということになりました。

「Problem running post-install step. Installation may not complete correctly
 Error with configuration or permissions. Please see log file for more information.」

 以下が、不具合の調査結果になります。

1. インストールログファイルの特定
 PostgreSQL 10 のインストールログは、PostgreSQL 10 インストールディレクトリ直下の logs フォルダにあります。この中の PostgreSQL-installLog.log を確認します。

2. PostgreSQL-installLog.log の中から "Error with configuration or permissions" という文字列を検索してみます。

  エラー文字列の付近を調べてみると、どうやらデータベース初期化時にエラーを起こしていたらしいことがわかります。

Initializing Postgres DB with:
  E:\PostgreSQL\pg10\bin\initdb -U postgres -A md5 --encoding UTF8  -D "E:\PostgreSQL\data\pg10" --pwfile="E:\PostgreSQL\pg10\.pgpass" > "E:\PostgreSQL\data\logs\pg10\install.log" 2>&1 ERROR: Unable to Initialize PG. see logfile: E:\PostgreSQL\data\logs\pg10\install.log

Error running init-pg10
Script stderr:
 Program ended with an error exit code

Error with configuration or permissions. Please see log file for more information.
Problem running post-install step. Installation may not complete correctly
 Error with configuration or permissions. Please see log file for more information.

 3. エラーが発生したコマンドをコマンドプロンプトから走らせてみる

  ログテキスト(赤色)より、ログファイルへのリダイレクト部分を取り除いたコマンド文字列を走らせてみました。

E:\PostgreSQL\pg10\bin\initdb -U postgres -A md5 --encoding UTF8  -D "E:\PostgreSQL\data\pg10" --pwfile="E:\PostgreSQL\pg10\.pgpass"

 すると、以下のように \data\pg10 のディレクトリの権限を変更しようとして Permission denied が返されたことがわかりました。

PostgreSQL コマンドによるデータベース初期化時に Permission denied が返る
4. Users グループに「変更」権限を与えてみる
 権限エラーということで、pg10 フォルダの Users グループに「変更」権限を追加します。
 上記のコマンドプロンプトのスクリーンショットの解説では、以下の記述があります。

データベースシステム内のファイルの所有者は"Administrator"となります。このユーザがサーバプロセスも所有する必要があります。

 インストール実行時の Windows ユーザは Administrator でしたので、権限の書き換えは問題なくできると思われたのですが、実際はそのようにならなかったため、Administrator がデフォルトで所属している Users グループを採用しました。
 恐らく、他ユーザでインストール中にもこの方法で対応できると思います。

PostgreSQL 10 の \data\pg10 フォルダの Users アクセス許可に「変更」権限を付与
5. 先ほど失敗したコマンドをもう一度走らせてみる
 3. のコマンドをもう一度走らせます。
 ご覧のとおり、エラーが解消されましたね。
PostgreSQL コマンドによるデータベース初期化成功


 よって、今回の不具合の原因は data\pg10 フォルダの権限不足によるものでした。


※ Everyone を追加してから、フルコントロール権限を割り当てても同様に動作しますが(実験済み)、Everyone を重要なフォルダに割り当てたり、高度な権限を与えたりすることはサーバのセキュリティリスクを高めることになりますのでお勧めはしません。


参考リンク:
Re: BUG #14541: Getting error while installation

(亀)


2018-04-10

iBeacon/Raspberry Pi による室内移動体位置監視モデル1 ~概要~

[English page]

お知らせ

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

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

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


  本稿では Raspberry Pi 端末(以下、「端末」、「監視端末」と呼ぶことがあります)によりビーコンをスキャンし、その位置を測位する「室内移動体位置監視モデル」について考えます。このモデルは製品ベンダーによって、あるいはシステムの用途によって、「屋内測位システム」、「資産管理システム」、 Indoor Location (Tracking) System、Indoor Positioning System (IPS)、Asset Tracking System、Realtime Location System(RTLS) 等と呼ばれています。 当ブログではこのモデルを示す用語として IPS を主に使用します。

要求属性 属性説明
測位対象数 測位対象が多いか、少ないか 少数|多数
移動頻度 測位対象の移動頻度 高頻度|低頻度
移動速度 測位対象の移動速度 高速|低速
測位精度 要求される測位精度 高精度|低精度
リアルタイム性 測位要求から測位実行迄の時間 リアルタイム|非リアルタイム*1
測位対象 測位対象となるモノ ビーコン|携帯端末
Appデバイス 測位結果を表示するデバイス 管理端末|携帯端末*2
*1:非リアルタイムの場合、約1分迄の時間差は許容する
*2:管理端末は主にPC、携帯端末も可

 サブモデルには以下のようなものがあります。
  1. 屋内ゲームでプレイヤーの持つスマホに自身や他のプレイヤーの位置を表示する
    属性:少数|高頻度|高速|高精度|リアルタイム |携帯端末|携帯端末→ 屋内GPSモデル

  2. ホッケー等屋内スポーツで、選手の位置をPC等に表示しする
    属性:多数|高頻度|高速|高精度|リアルタイム|ビーコン|携帯端末 → ホッケーモデル(フィンランド Quuppa 社の動画

  3. 病院、介護施設で患者や入居者の位置をスタッフが把握する
    属性:多数|高頻度|低速|低精度|非リアルタイム|ビーコン|管理端末→病院モデル

  4. 工場の組立工程にある製品の位置を管理する
    属性:多数|高頻度|低速|低精度|非リアルタイム|ビーコン|管理端末→工場工程モデル

  5. 倉庫や保管場所にある製品の位置を把握する
    属性:多数|低頻度|低速|非リアルタイム|ビーコン|管理端末→倉庫モデル

 サブモデルにより IPS の仕様や運用方法も変わってきます。当社で開発中の TPC_IPS は上記の3~5のサブモデルを利用対象としています。

[コラム]ドローンフライト制御モデル

 市販のドローンの多くはGPSを搭載しており、屋外では自身の位置を認識しますが、GPS信号の受信状態が悪い或いは受信不能な屋内、ビル近辺、谷間等では、GPSは機能しません。 このような場合、IPSによりドローンの位置を把握し、フライトを制御するケースが考えられます。これによりプログラムにより制御されたドローンが物品を輸送したり、深夜に無人のビルや工場を巡回監視したり、撮影することができます。

 ただ、iBeacon(BLE4ビーコン)による IPS はその測位誤差が1メートル以上と大きいため、オフィスなどでのドローン制御は難しいと思います。 
 この点、BLE5.1AoA対応ビーコンや Ultra Wide Band(UWB)タグを用いたシステムであれば、測位誤差が1m~10㎝までに抑えられるため有利です。

 IPS の導入にあたっては、そのシステムがどの程度の測位精度を求めるのか、という点が重要です。

システム概要

 下図のように監視対象とするエリアを正方形で区切り、各正方形の頂点に監視端末(Raspberry Pi、図のピンクのマーク)を配置して、ビーコン信号をスキャンします。図の青いマークがビーコンで、これらが人やモノに取り付けられて移動します。Raspberry Pi の間隔、つまり各正方形の辺の長さは、障害物や人の多い場所や、高い測位精度が求められる環境では狭くします。 逆に障害物や人が少ない場所や、測位精度を重視しない環境では広く取り、端末の台数を減らすことができます。

【図1:Raspberry Pi監視端末の配置】
運用環境では監視端末を正方形状に配置できないことも多い

 各Raspberry Pi は常時ビーコン信号を受信し、その情報をアプリケーションサーバに送ります。サーバはこの情報を基に三点測位を行い、各ビーコンの位置を算出します。

 ビーコンの位置測位を行う手法はいくつかありますが、今回は三点測位を利用します。
図1の全ての監視端末(Raspberry Pi1 から Pi16) は常時ビーコン信号の読み取り(スキャン)を行っています。 ビーコン信号は発信時に最も強い強度を持ちますが、空間を伝搬するとその距離に応じて減衰していきます。各 Pi はこの信号強度、RSSI(受信信号強度、Received Signal Strength Indication)を取得するので、このRSSIの減衰の度合いからビーコンと端末(Pi)間の距離を算出します。

 下図の「Before (移動前)」の所には端末 Pi2、Pi5、Pi6 を中心とする円がありますが、それぞれの円の半径がビーコン迄の距離となります。三円測位では円の円の交わった点、あるいは3円が重なったエリアの中心をビーコンの位置であると推定します。 Pi2、Pi5、Pi6以外の端末もビーコンを検知しますが、最も近接する端末がこの3つの端末であり、近接する端末の RSSI の精度が高いため、この3の端末の円を基にして三円測位を行います。

 次にビーコンが「After」の位置に移動したとします。移動したことにより、距離が最短となる端末は Pi12、Pi15、Pi16 となりました。この時はこれらの最も近接する端末の円(端末⇔ビーコンの距離)を使用して三点測位を行います。 



考慮すべき課題

 一見簡単にビーコンの位置が特定できそうですが、そこまで辿り着くのは大変です。 その理由は以下の通りです。

RSSI の精度

 RSSI は端末とビーコン間の距離が数十センチの場合は、そこそこの精度で距離を計測できますが、1mを超えるとマルチパス(多重波伝搬)等の影響を強く受け、信号が公式の通りには減衰せず、RSSIに基づき算出した距離は実際の距離とは大きく異なる、ということが非常に頻繁に発生します。

三点測位の問題

 上記のようにRSSIに基づく距離は信頼性が低いため、三円測位の3つの円が交わらず、三円測位が破綻するということも多々発生します。この場合は単にエラーとするだけではなく、代替の手段を考えなければなりません。

 次稿では実際に RSSI を測定し、それから算出される端末とビーコン間の距離と実際の距離の誤差について考えます。さらに、小社が考案するRSSI・距離の補正方法と、三点測位の拡張についても記します。

2018年4月以降の改良点とIPS市場の動向

 本稿の公開は2018年4月ですが、その後新たな製品や技術がリリースされ、小社でも新たな手法の開発と検証を続けています。最後にこれらについて簡単に触れておきます。

測位方法

次稿(2018/08/09公開)と次々稿(2019/07/12公開)ではRSSIと距離補正や、三点測位を行うプロトタイプを開発してテスト・検証した結果を記しています。 しかし、RSSI 及び RSSI に基づく三円測位は測位精度に限界があります。 この点、機械学習を使用した測位は学習を行う手間がありますが、三円測位に比べ測位精度を上げることが可能です。この機械学習による測位精度についても、プロトタイプシステムを作成、テスト・検証を行い記事(2020/12/26公開)を書いています。

BLE5.1 AoA/AoD

2019年1月にBLE5.1 AoA/AoD の仕様が公表されました。これにより、BLE5.1対応端末(センサー)はビーコンの距離に加えて、ビーコンの存在する方向(角度)を取得することが可能になり、測位精度が1m以下になると期待されています。ただ、仕様公開から2年以上経った現在、主要ベンダーからは BLE5.1 対応の発信機及び受信機(センサー)はリリースされていません。

UWB

2021年4月末、Apple社から AirTag が発売され、iPhone 11/12 を使用すれば AirTag の測位を高い精度で行えるようになりました。この測位に使われている技術が UWB という技術で、誤差10㎝の測位が可能と言われています。UWB を使用した IPSシステムには UbisenseZebra といった製品が以前から市場にあり、高い評価を得ていますが、大変高価です。海外IT関連メディアは AirTag を "Game Changer" と呼んでおり、今後 UWB を使用した新たな IPSシステムが市場に現れるものと期待されます。

(亀)

IPS関連のBlog記事


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