2018-04-10

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

 Raspberry Pi を監視端末し、iBeacon を取り付けた製品(以下、ビーコン)の存否確認を行う「定位置ビーコン監視モデル」については以前紹介しました。このモデルはビーコンが移動しないことを前提としていました。
 今回は Raspberry Pi 端末(以下、「端末」、「監視端末」と呼ぶことがあります)により、移動するビーコンをスキャンし、位置を把握する「室内移動体位置監視モデル」(日本語では屋内位置情報システム、英語では Indoor Location (Tracking) System、Indoor Positioning System (IPS) 等と呼ばれています)について考えます。これにあたり、端末上でビーコンを監視し、 RSSI の取得、距離算出、ログ保存、データベース更新を行うアプリのプロトタイプも作成します。

 定位置ビーコン監視モデルに関する記事:

モデル

移動するビーコンの位置を把握するシステムモデルといっても、様々なものが考えられます。

例:
  1. 屋内ゲームでプレイヤーの持つスマホに自身(と他のプレイヤー)の位置を表示する(ゲーム機端末タイプ)
  2. 老人ホームや介護施設で入居者や患者の位置を管理者が把握する(高頻度スキャンタイプ)
  3. 工場の組立工程にある製品の位置を管理する(高頻度スキャンタイプ)
  4. 倉庫や保管場所にある製品の位置を把握する(低頻度スキャンタイプ)
  5. モノ・人の位置をリアルタイムに把握する(リアルタイムスキャンタイプ)
上記4のタイプは上記2、3のタイプに比べると、それほど頻繁にビーコンが移動することはなく、保管場所の変更など、稀に製品の移動が発生します。常時移動しないので、Raspberry端末からスキャンを実行して位置を特定する頻度は低くても良く、よってリアルタイム性を重視しないことを想定しています。
 これに対して、上記3、4のタイプは人や製品の位置をできるだけ迅速に把握する必要があるため、端末からのスキャンを頻繁に行うことを想定しています。
 5の「リアルタイムスキャンタイプ」は可能な限りリアルタイムな位置情報が必要とされるものです。
 移動体の位置監視システムはそのタイプにより仕様も運用方法に変わってきますが、本稿では、 高頻度及び 低頻度スキャンタイプについて考えます。

ドローンフライト制御モデル

市販のドローンの多くはGPSを搭載しており、屋外では自身の位置を認識しますが、GPS信号の受信状態が悪い或いはできない屋内、ビル近辺、谷間等では、GPSによる位置計測ができないことがあります。 このような場合、ビーコンによりドローンの位置を把握し、フライトを制御する「ドローンフライト制御モデル」があります。 プログラムにより制御されたドローンで深夜に無人のビルや工場を巡回監視したり、撮影したりする用途が考えられます。

システム概要

 本モデルでは、監視端末をグリッド上に規則的に配置し、複数の端末が取得した同一ビーコンのRSSIにより端末とビーコン間の距離を算出し、その位置を推定することを目標とします。

監視端末のグリッド配置

ビーコンの位置を特定するにあたり、RSSI 等の情報を取得する Raspberry Pi 端末を碁盤の目状に10m間隔で配置するものと仮定します。すべての端末が常時あるいは一定間隔でビーコン信号をスキャンします。端末の座標はデータベースの端末テーブルに予め登録します。すべてのビーコンは赤枠内部に配置するものとします。

【図1:端末のグリッド】


位置情報更新ロジック

各Raspberry Pi監視端末は ビーコンスキャンを実行してRSSI(受信信号強度、Received Signal Strength Indication) を取得し、このRSSIに基づき端末とビーコン間の距離を算出します。その後、アプリケーションサーバを介してデータベースサーバ上にある各ビーコンの距離テーブルの距離データを更新します。距離テーブルには、ビーコン毎に3つ(または4つ)のレコードを保持しており、レコードには最もビーコンに近接する Raspberry端末3台のIDとビーコンまでの距離が記録されています。
 例えば、下図左上にビーコン(青)がありますが、このビーコンに最も近接する端末は Pi2、Pi5、Pi6であることから、このビーコンに従属する距離テーブルの3つのレコードには、これらの端末の ID と ビーコンと端末間の距離が記録されています。
 Pi1~Pi16までの Pi監視端末は常時スキャンを行い、Pi2、Pi5、Pi6以外の端末も図上のビーコンを検知しますが、ビーコンが移動しない限り距離が最小となる(最も近接する)端末は Pi2、Pi5、Pi6のままです。
 次にビーコンが矢印の位置に移動したとします。この時、距離が最短となる端末は、Pi12、Pi15、Pi16 となるため、3つのレコードは3つの端末IDとその距離情報により更新されます。

ビーコンの位置を算出 ― 三点測位

 上述のように、データベース上の距離テーブルには、端末IDと、端末⇔ビーコン間の距離が記録された3つのレコードがあり、端末テーブルには各端末の座標が保管されています。これらのレコードを元にビーコン位置をプロットすると、端末を中心にした3つの円が表示されます。3つの円が重なったエリアの中心にビーコンがあると推定されます。 この中心位置を求めるのが三点測位と呼ばれるもので、本システムモデルでは主としてこの手法を用いてビーコンの位置を特定することを最終目標とします。
Plotly により、3つの端末からビーコンまでの距離をプロット

考慮すべき課題 

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

1. RSSI の精度

次稿で詳述しますが、RSSI は端末とビーコン間の距離が数十センチの場合は、そこそこの値が計測できますが、1mを超えると各種干渉を受けて急激に劣化し、あるタイミングでRSSIを取得して距離を算出しても、実際の距離とは全く異なる値が出てくる可能性があります。
 また、RSSIはその精度の低さに加え、端末付属のBLEデバイス、端末の設置場所、時間帯、ビーコン個体等々、さまざまな条件の影響を受けます。
RSSI は位置特定の基本となる最重要な要素ですので、RSSIの値を補正する手法が必要となります。本モデルでは、この手法についても考えます。

2.三点測位

RSSIによりビーコン間の距離が算出されると、前述のように三点測位によるビーコンの位置推定が可能となります。ただこの手法も3つの円が交わらないと機能しないため、その場合は単にエラーとするだけではなく、代替の手段を考えなければなりません。

 次稿では実際に RSSI を測定し、それから算出される距離と実際の距離を比較どの程度の誤差が発生するのかを見ます。さらに、小社で考案するRSSI・距離の3つの補正方法とその検証結果についてのも述べます。


(亀)


IPS関連のBlog記事



iBeaconよる位置測位調査(IPS)サービス 

土屋企画では iBeacon 利用した屋内位置測位調査(IPS)サービスを提供しています。 本サービスは貴社の社屋や施設にお伺いし、当方のIPS によりどの程度の精度でビーコン位置の計測をできるのか調査するものです。

詳細につきましては、こちらをご覧ください。

2017-12-30

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

 前稿前々稿では iBeacon を使用した商品の存否確認に関するモデル(定位置ビーコン監視モデル)について記しました。これらのモデルは iBeacon を使用するため、その電波の到達範囲は0m~100m程度であるため、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関連リンク

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関連リンク