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システムには Ubisense や Zebra といった製品が以前から市場にあり、高い評価を得ていますが、大変高価です。海外IT関連メディアは AirTag を "Game Changer" と呼んでおり、今後 UWB を使用した新たな IPSシステムが市場に現れるものと期待されます。

（亀）

IPS関連のBlog記事


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

By 時刻: 0 件のコメント:
ラベル: , , , , , , , , ,

2017-12-30

Androidを使用した多数移動体位置監視モデル

　前稿と前々稿では iBeacon を使用した商品の存否確認に関するモデル（定位置ビーコン監視モデル）について記しました。これらのモデルは iBeacon を使用するため、その電波の到達範囲は0ｍ～100ｍ程度であるため、iBeacon（あるいは iBeacon を取り付けた商品）がその範囲を超えて出ていってしまうと、当然のことながらビーコン監視端末は iBeacon の存在を認識できなくなります。
　今回は前二稿とは趣を変え、モバイル端末を物品に取り付けることによってその位置を適時把握するモデルを考えるとともに、そのモデルに則したプロトタイプを作成・試用してみました。

多数移動体位置監視モデル

　本モデルでは、数十～数百、数千の移動する商品、物品、人などの物体に モバイル端末を取り付け、地図上にその所在地を表示しています。

　下図のように、モバイル端末のインターネット接続にはMVNOが提供する移動体通信網を使用し、端末はGPSにより得られた自身の位置情報をアプリケーションサーバ経由でDBサーバに送ります。DBサーバは送られてきた端末の位置情報を保存します。また、各端末の位置の地図上表示も、PC等のブラウザからアプリケーションサーバを介して行います。

多数移動体位置監視モデルの概要図
図1 ― モデル概要

通信端末について

　当初、上図端末には Raspberry Pi  等のシングルボードコンピュータを使用する予定だったのですが、検討を進めていくうちにコスト増のモデルになり得ることがわかりました。

　具体的には、まず、ラズパイにSIMドングルやGPSモジュール（ドングル）を載せる必要が出てくるわけですが、実用面を考慮するとユーザに容易にシャットダウンしてもらうための電源On/Offスイッチ、電源供給が遮断された場合に備え、UPSも準備する必要があります。

　これらのモノは全て自前で調達して設定しなければならないため、価格、性能評価や設定の労力、携帯性、収納性等がネックとなります。ラズパイは途中まで設定やテストを行ったのですが、結局 Android 端末を使用することにしました。
　Android であれば All-in-One で低価格（￥5千前後～）で入手でき、携帯性・耐衝撃性(移動時にコネクタ/ケーブル類が外れる可能性がほぼ無い)に優れ、電源周りで気を遣うことがなく、安定性・信頼性も実績十分です。
今回のテストに使用した Android フォントタブレット
今回使用したAndroidフォンとタブレット、OUKITEL社(写真左から3/4番目は￥5千/台で購入できた)

移動体通信会社（MVNO）

　本モデルでは多数の Android 端末を使用してインターネット通信を行うため、通信費用はできるだけ抑制したいところです。最近は格安MVNOの登場で、1GB程度のデータ量であれば月額￥500程度で利用できるので、後述のようなシステム仕様であれば1端末月額￥500で運用可能と思われます。
　ただ、今回作成・テストするプロトタイプシステムでは、IoT 通信に特化したデータ通信サービスを展開する SORACOM を試用してみることにしました。
　SORACOM を採用するメリットは主に2つあります。一つは少ないデータ量の通信では費用を低く抑えられること、もう一つは SORACOM API を通じてSIMを制御したり、通信状況を取得することができる点です。SORACOM の実際の使用感については後述します。

システム構成とプロトタイプ開発

　これまでの経緯より、モバイル端末には Android、モバイル通信には SORACOM を使用することに決めました。アプリケーションサーバ（App Server）とデータベースについては、前者を node.js + express.js、後者を FileMaker Server 16 としました。Google Maps API は アプリケーションサーバが Android から取得した位置情報をもとに住所情報を取得する際、またPC/タブレット等でAndroidの位置を Google Map 上に展開する際に使用します（図2参照）。
Android 端末によるデバイス位置管理システムの構成
図2 ― システム機能概要

ハイブリッドアプリとアプリケーションサーバの仕様と処理分担

　Android の GPS から経緯度情報を引き出すには、Android Studio 等でネイティブアプリを作成するか、HTML5/Cordova 等によりハイブリッドアプリを開発することになりますが、今回は iOS 等への対応も視野に入れ、ハイブリッドアプリを採用することにしました（上図の tpcgeo.apk、以下、tpcgeoアプリ）。tpcgeoアプリはアプリケーションサーバに経緯度情報を送信するだけの単純なモノです。Google Maps API を介した住所情報の取得やデータの加工、データベースの更新といった多くの処理は、アプリケーションサーバ上の tpcgeo_server.js と tpcsql.js（前回記事参照） が担います。
　Android 側にあまり仕事をさせないのは、通信量を抑えるというコスト上の理由と、外部で使用するモバイル端末から送信する情報の量は必要最低限にするというセキュリティ上の理由によります。

プロトタイプのテスト

　上記の仕様に従ってそれぞれのアプリケーションを作成し、Android とアプリケーションサーバに必要なアプリケーションやファイルをインストールした状態で、SORACOM SIM（SORACOM Air/Global plan01s）の導入を行いました。図2のように2つのサーバにも必要なシステムをインストールし、テスト開始です。

まず、データベースを起動し、次にアプリケーションサーバで node.js/express.js 上で動作する tpcgeo-servers.js をコマンドプロンプトから起動します。

アプリケーションサーバで tpcgeo-server.js を起動
図3 ― アプリケーションサーバのプロンプトで tpcgeo-server.js を起動

次に、Android 上で tpcgeoアプリ を起動し、位置情報を送信する回数（Requests）と送信間隔（Interval、ミリ秒で指定）を指定します。下図では、10秒間隔で20回、自身の位置情報を送信するように設定されています。“Start”をタップすると、位置情報のアプリケーションサーバへの送信が開始されます。

tpcgeo 実行画面 (Android)
図4 ― Android でハイブリッドアプリ＝tpcgeo 実行画面

アプリケーションサーバ上の tpcgeo-server.js が Android から位置情報を受信すると、Google Maps API に位置情報を送り、その戻り値として住所情報を取得します。そして必要なデータ加工を行った後にデータベースへの書き込みを行います。これらの処理が成功すと、tpcgeo-server.js を実行するプロンプト画面には以下のような実行履歴が表示されます。

プロンプト画面に表示される tpcgeo-server.js の実行ログ
図5 ―  tpcgeo-server.js のプロンプト上に表示される実行履歴

　プロンプトに update[OK] が表示されている場合、FileMaker データベースの位置データ（下図のLatitude、Longitude、Altitude等、白地のフィールド）の更新が成功したことを意味します。
Tpc Geo 端末管理画面(FileMaker)
図6 ― 端末の位置情報等を表示する FileMaker アプリ
オレンジの部分は SORACOM API から取得する SIMの状態、課金情報等。 

　各端末の位置は、PC等のブラウザで Google Map 上に表示できます。

各端末の位置が Google Map 上に展開される
図7 Windows Edge で Google Map 上に表示した各端末
データベースから取得した各端末の位置情報に基づき、Google Maps API を介して地図上に端末をマッピング

　赤地のマーカ（端末名）をクリックすると、詳細がポップアップ表示されます。

ピンのクリックによって住所情報をポップアップ表示
端末の所在住所等詳細がポップアップ表示される


SORACOM Global について

　前述のように今回は通信にSORACOM社の提供する SORACOM Air/Global plan01s というサービスを利用しました。本サービスに必要な費用は SIM 1枚当たり、以下のとおりです(2017/12/30現在)。
  • 初期費用(SIM本体含む)：US$5
  • 基本料金：US$1.8/30日
  • データ通信料：US$0.2/MB
ご覧のように初期費用が約500円と非常に低いため、本サービスは多くの IoT/M2M システムのテスト環境構築には適していると思われます。
　ただ、今回の Android ベースのプロトタイプ・システムに類似したシステムを“常時”稼働させようとすると、通信量が想像以上に発生し、月額￥500 の MVNO に比べると割高になると考えられます。
　その理由は Android OSとその付属アプリが予期しない多くの通信を行うからです。No root タイプの Firewall を導入して不要な通信を遮断・監視しようとしても、Firewall を回避して発生する通信が発生するため、これがかなりの量に及びます（なお、Android の Firewall については、NetGuard の開発者・M66B さんが BBS 上で参考になるレスを書いています）。
　
　では、常時稼働ではなく、限定的に稼働するようなシステムではどうでしょうか？たとえば、Android 端末が 1カ月の 80％は社内や倉庫内にあり、その間通信を必要としないケース、あるいは特定時間帯、特定期間にのみ通信を必要とするケース。これらのケースであれば、SORACOM のほうが割安となる可能性があります。というのは、SORACOM API を使用することにより、特定の時間、あるいは特定の条件下で SIM のサービスを停止させたり、一定の通信量を超過した場合は管理者にメールや SMS で通知を行うシステムを構築できるからです。


（亀）


IoT/M2M関連リンク

By 時刻: 0 件のコメント:
ラベル: , , , , , ,

2017-11-14

FMクライアントからサーバ上のODBC/node.js経由でデータベースをCRUDする

　FileMaker（以下、FM）から FileMaker Server （以下、FMS）上のデータベースに接続し、SQLクエリでデータを CRUD する場合に考えられる方法は、通常は以下の2つです。

  1. FM クライアント機に ODBC を入れて、SQL を実行スクリプトステップを使用する
  2. FM クライアント機に ODBC は入れず、ODBCはサーバにのみ入れ、サーバサイドスクリプトで SQL を実行スクリプトステップを使用する

　1. のデメリットは、全てクライアントにODBCを入れる必要があり、保守が面倒なこと、
　2. のデメリットは、サーバサイドスクリプト内はデバッガが使用できず、またクライアントで実行する場合と動作が異なることがあること、です。
また、「\"」のエスケープが面倒で醜いというのは両者に共通した欠点と思います。

　さて、上記の2つの方法のデメリットを回避する方法として、サーバに ODBC/node.js と当方で開発した tpcsql.js を置き、FM クライアントから FMS に対して SQL を発行して CRUD する方法をご紹介します。

　以下で詳述のデータベースサーバ側でクエリ文を待ち受けする Node.js スクリプト tpcsql.js は、以下のページより無償ダウンロードいただけます。

tpcsql.js を使った CRUD テスト方法

以下、環境構築の方法を記します。

注：
  • cURLを使用するため、FileMakerクライアント は Ver.16 以降が必須となります。
  • FMSは Ver16　でのみ検証を行っています。 　
  1. FMS 16 の Admin Console で ODBC/JDBC を有効にします。

  2. FM 付属の FileMaker ODBC ドライバを、サーバにインストールします。
    クライアントへのODBCのインストールは不要です。
  3. FMS サーバ環境に Node.js をインストールします。
  4. 上記のサイトより、tpcsql.js をダウンロードし、サーバ 上の任意の場所に配置します。
  5. tpcsql.js に付属の Readme.txt に従って、Node.js 関連パッケージ群をインストールします。
  6. コマンドプロンプト画面から、node tpcsql.js と入力し、Enter キーを押下します。
    以下のようなメッセージが画面に表示されたら、クエリ待ち受け状態となります。

    ここでは、Web サーバのデフォルトポート 80 で待ち受けしますが、すでに他の Web サーバが稼働中の場合は、tpcsql.js に記載されているポート番号を変更（例： 80→8080）し、再起動してください。
  7. 付属のサンプルファイル「TpcQueryTester10.fmp12」 をFMSに配置し、公開します。
    FMクライアントからアクセスできるように、必要に応じて、ファイヤウォールの設定を変更します。
  8. FMクライアントを起動し、上記7で公開したTpcQueryTester10.fmp12 を開きます。
    ログイン情報は tpcsql.js に付属のドキュメントを参照してください。
  9.  [URI]フィールドの hostname の部分を FMS16 のホスト名、または IP アドレスに変更し、“Go”ボタンを押してみてください。

    上記で、[odbcDriver]、[host]、[uid]、[pwd]、[database]フィールドは、FMS16 側から見た場合の設定をあらかじめ入力してありますので、そのまま “Go”で実行できます。
  10. 以下のようにクエリ結果が [result]フィールドに戻ってきたら成功です。
  11.  Data テーブルには 1000 件分のテストデータがあらかじめ登録されています。
    クエリ内容を変更することによって、CRUD 操作をお試しいただけます。
　本稿では データベースは FileMaker Server を使用していますが、MySQL や SQL Server など、ODBC対応であれば他のデータベースでもここに記載した方法は使用できると思います。

tpcsql.jsの他のプラットフォームでの利用

　当初、tpcsql.js は Raspberry Pi 等で iBeaconの情報を収集・加工し、リモートのデータベースをSQLで簡単にCRUDするという M2M な利用を意図して企画したのですが、「FMクライアントから使えたら便利かも？」と思い、公開することにしました。
　もともと、FMのサーバサイドで「SQLを実行」がサポートされているので、「？」な方もいらっしゃるかと思いますが、「役にたったよ」という方が現れたらウレシイです。
　尚、tpcsql.js のラズパイでの利用は、稿を改めてご紹介できればと思います。


（亀澤）

IoT/M2M関連リンク
By 時刻: 0 件のコメント:
ラベル: , , , , ,
登録: 投稿 (Atom)