ドラゴンレーダーを作る

みなさん今日も物探ししてますか？物探しって大変ですよね。見つからないとイライラしますし精神衛生上もよくないですね。物探しにも程度があって、近くの鍵から遠くのドラゴンボールまで、そういえばドラゴンボールを探すのにドラゴンレーダーってありますね。あれ便利ですよねー、というわけで作ってみました。

今とある案件で作成しているデバイスがあるのでそれを使います。そのデバイスはESP32マイコンとGPSモジュール、LoRaモジュールを搭載しています。ドラゴンレーダーを作ろうとしたら現状ではGPSは必須になると思いますが、GPSで取得したデータをどうやって転送するかという問題があります。３Gなどの通信回線使えばできますが、月額のランニング費用がかかりますし、圏外では利用できません。そのためこのデバイスはLoRaモジュールを使って、LoRaでデータを転送するようになっています。これで環境次第ですが見通し5kmぐらいは通信ができるようになります。

何だ、RFIDが出てこないじゃないか、という問題がありますが、でもほら、RFIDとLoRaは周波数的にはご近所さんだし、えへ。

イメージ図がこちらです。

ドラゴンボール側はGPSで位置情報を受信して、LoRaで送信します。ドラゴンレーダ側はGPSで受信した位置情報と、LoRaで受信したドラゴンボールの位置情報をBLEでスマホに転送します。スマホは Chromeブラウザの Web Bluetooth API を使用してドラゴンレーダに接続してデータを受信し、座標の計算などは javascript を使用することでアプリをインストールすることなく実行できるようにしました。

それでは実験します。ドラゴンボールは名護マルチメディア館（２Fの窓際）に置きます。ドラゴンレーダーとスマホを持って、車で移動しながら測定しました。

１箇所目はこのあたり。ドラゴンレーダーはこんな感じ。

ドラゴンレーダーの表示は進行方向が上で、Nが北の方角になります。下に数字が表示されていますが、上から順番にドラゴンレーダーの位置情報（緯度、経度）、スピード（ノット）、進行方向（度）、ドラゴンボールまでの距離（ｍ）です。黄色の丸がドラゴンレーダーから見たドラゴンボールの相対位置になります。緑の円は中心から250mごとに描かれていて、一番外側の円で1kmの距離になります。

２箇所目

３箇所目、辺野古の交差点

どうでしょう？結構いい感じに表示されていますね。今回はドラゴンボールとドラゴンレーダーで直接通信していたのでせいぜい5kmほどの距離までしか受信できませんが、LoRaを中継する機械をなるべく高いところに設置すればかなり広範囲でも利用できます。

これで物探しもグッと楽になりますね！？

そうそう、鍵など屋内の物探しはRFIDの方が便利ですよ（強引）。

MANICAモバイルのゲート機能を試してみる

安価にRFIDを導入できるAndroidアプリで簡単に入出庫・棚卸しが可能なMANICAモバイルですが、ゲート機能が追加になりましたので試してみました。

ゲート機能とは、Androidアプリを使用せずにRFIDゲートにタグを読ませるだけで、あらかじめ登録しておいた入庫／出庫の処理を自動で行う機能です。

ゲート自体はまだ出来てないのですが、Webフックで機能しますのでMANICAコレクタを使用して代用できます。

まずはハヤト管理者にゲートを払い出してもらいます。そうするとユーザのメニューに「ゲートの管理」という項目が追加されます。ここでゲートの設定をします。

ゲート名と、読み取ったときの処理（入庫か出庫か）を選択します。入庫のときは保管場所も選択できます。さらにゲートの場所をマップ上から設定できます。今回の図の設定ではゲートで読み取ったら、「名護マルチメディア館の倉庫１に入庫」という処理になります。

実際のゲートを準備します。MANICAコレクタは様々なリーダが使えるので何でもいいんですが、とりあえずそのへんにあるもの使います。

ゲートと言ってもただリーダとアンテナ置いただけです（笑。よく言えばテーブルスキャナ的な。

このゲートをMANICAモバイルのゲートとして使用できるようにMANICAコレクタの設定をします。

MANICAモバイルのゲート機能はPOST対応なんですが、現行のMANICAコレクタ（バージョン2.1.1以下）はGETのみの対応なのでPOST対応に修正しました（次期バージョンの標準機能になります）。

テスト用の物品を準備します。

今回は特別にドラゴンボールを準備しました。単なるテストにこんな大事なものを使うなんて何て贅沢なことをしてるんでしょうか。画面ではステータスが出庫になっています。これからドラゴンボールが届いて、入庫させようとそういう流れです。

というわけでドラゴンボールが３つだけ届きました。

早速読取り！
結果！

見事３つのドラゴンボールが入庫処理されました！

MANICAコレクタでも十分機能するのですが、こういう読取りのさせ方をする場合、読み取ったときに何個読み取ってるのかがわからないととても不安な状態になりますので、読取り数の表示機とかが必要になるわけですね。そのあたりの試作的なものは以前の記事「MANICAモバイル用のゲートを作る　その１」に記載しておりますのでご覧ください。

棚卸しパッケージをクラウド化してみる

当社で販売しております「棚卸しパッケージ」ですが、おかげさまで大変ご好評いただいております。このパッケージは、無償でご提供しております「MANICA EXCEL TOOL」をベースに棚卸しの機能をエクセルのマクロで追加し、ハンディリーダ用の専用アプリとのセット製品になっています。

エクセルなので基本的にはスタンドアロンでの運用となります。が、「Googleスプレッドシート」などエクセルのようなクラウドのアプリもありますね。こっちで動くとカッコいいかなーと考えたところ、そういえば棚卸しパッケージではハンディとPCの通信自体はそんなに大したことをしていません。じゃそれをWebとの通信にしちゃえばよくね？ということでやってみました。

Googleスプレッドシートには、Google Apps Scriptというマクロ的なのがあって、これがなんとWebAPIとして公開できるようになっています。ここに棚卸しパッケージのハンディとのやり取り部分を実装して棚卸しパッケージのフリをすることでハンディのアプリそのままに動かそうという目論見で試しました。

こんなイメージ

で、やってみたらこれまたいろんなハードルがあって思ったより相当大変だったんですが何とか動きました。

スプレッドシートで棚卸しパッケージと同じ内容でデータを作ります。

ロケーションのデータも作成

ハンディを起動します。ハンディはデータの送信先を作成したGoogle Apps ScriptのAPIにしただけで、特に大きな修正は入れていません。

棚卸し画面に移動して、マスタダウンロードをします。

キター！ロケーションの情報が表示されました。
部屋Aを選択すると

物品が３個あります。モニタのタグを読むと

この状態でデータ送信ボタンを押します。

するとスプレッドシートの棚卸しの部分にデータがアップロードされました。

これで【棚卸しだけ】をやるのであればスプレッドシートでも問題なく利用できます。ICタグを探す探索機能なども実装できそうです。

しかし問題点もいろいろわかりました。通信がWebAPIなのでサーバ側からハンディに任意のタイミングでデータが送信できない　とか　棚卸しパッケージの通信ではSJISでBASE64エンコード使ってたりしますが、これが Google Apps Script ではそう簡単に実装できないとか。

どう進めていくかはもう少し検討が必要ですかね。

ItemTestを使ってxSpanをDirectionモードで動かしてみた

前回はSpeedway Connectを使ってxSpanを制御してみました。今回はItemTestを使ってxSpanを制御してみようと思います。ItemTestはImpinjが出しているテストツールで、上記ページからダウンロード可能です。

今回使ったもの

• Impinj xSpan
• ItemTest (v1.14.0)

セットアップ

ダウンロードしたzipファイルを解凍し、exeを実行し、ウィザードを進めれば、セットアップが完了します。

初期設定～読取

1. アプリを起動し、メニュー左上の「Reader Settings」をクリック
2. 「New」ボタンをクリックし、xSpanのIPアドレスを入力
3. 追加されたリーダの「Configure」ボタンをクリックすると、「Field of View」や「Age Interval」「Tag Population」などConnect同様の項目が設定可能
4. OKを押してメイン画面に戻って「Direction」タブを選択
5. 「Start」ボタンを押すとタグ読取が開始

6. 「Stop」ボタンを押すとタグ読取が終了

ログファイル

左下のLog fileのところに、ファイル名を入力しておくと、Start～Stop間で読まれたタグの情報が下記フォルダにCSVファイルとして出力されます。

C:\Program Files (x86)\Impinj\ItemTest\log

出力例はこんな感じです。

// 2019/11/29 22:08:14
// Sector2=True, Sector3=True, Sector4=False, Sector5=False, Sector6=False, Sector7=False, Sector8=False, Sector9=False, Mode=Mode 0 : Max Throughput, Power=30, FieldOfView=Narrow, AgeInterval=4, UpdateInterval=2, EnableSendUpdates=False, TagPopulationLimit=50, ReaderName=192.168.0.91
1575032894605449,Entry,E280117000000209839C2903,2,OK,FirstSeenSector=2,FirstSeenTime=1575032894605449
1575032894639373,Entry,30147A24C415FD81F4500001,3,OK,FirstSeenSector=3,FirstSeenTime=1575032894639373
1575032897771621,Entry,30352E22B81F6D9400000014,3,OK,FirstSeenSector=3,FirstSeenTime=1575032897771621

それぞれの列の意味は多分下記のようです。

• 1列目はTimestampっぽいのですが、16桁あります。先頭10桁がUnix Timeのようです。
• 2列目はEntry（タグが範囲に入った）かExit（範囲から出たか）です。
• 3列目がタグID（EPC）です。
• 4列目が読まれたSectorです。
• 5列目がTag Population Statusで読取範囲にタグが多すぎると正しく推定できずエラーになるそうです。
• 6列目が最初に読まれたSectorです。
• 7列目が最初に読まれたTimestampっぽいのですが、例のごとく16桁あり、先頭が10桁がUnix Timeのようです。

Tag Population Statusについては、XARRAY AND XSPAN GATEWAYS DEPLOYMENT AND BEST PRACTICESに下記記載がありました。タグ読取数が設定したTag Populationを超えると、User Overflowに、High Performance Modeの場合、50タグを超えると、System Overflowとなり、正しく方向を推定できないそうです。

Rx Sensitivityを設定して、ある程度返信強度の強いタグに絞って推定すればよいのかなとも思ったのですが、Directionモードでは設定できないようです。ItemSenseの場合は確かRx Sensitivityも設定できたような気がするので、方向検知を使いこなすにはItemSenseを使うべきということでしょうか。いずれにしろ方向検知を使いこなすにはいろいろと知識が必要そうです。

Speedway ConnectをxSpanにセットアップしてみた

前回はSpeedway ConnectをRevolutionにセットアップしてみましたが、今回はxSpanにセットアップしてみます。さらに各パラメータについても少し調査してみたので、まとめてみます。

今回使ったもの

• Impinj xSpan
• Impinj Speedway Connect （v2.8.0　トライアル版）

セットアップ

前回同様まずはxSpanのFirmwareを最新にアップグレードし、そのあとにConnectをセットアップしました。

Directionモード

xSpanの場合、Reader ProfileでDirectionが選択可能です。Directionを選択すると、Direction Configurationが設定可能となります。

今回はタグがリーダのField of Viewから抜けて10秒後に通知するようにしてみます。そのために下記のように設定しました。

Tag Age Interval: 10 secs
Send Entry Reports: false
Send Exit Report: true

たとえば、環境によってタグがFOVをチラチラしている場合にはTag Age Intervalを長めにとってあげればよさそうです。タグがFOVに入った時に通知したい場合はSend Entry Reportsをtrueに設定すればよいです。

Filtering Software

上記とは別のパラメータにFiltering Softwareという項目があります。こちらはRead Windowの間に同じタグを読んだ場合はそのタグを読み飛ばすという設定のようです。ようです、というのは設定秒経過させてから読ませてみてもうまく通知されず、もう少し経ってからでないとタグの読取が通知されなかったためです。そのため、パラメータの理解が間違っているかもしれません。（あるいは実験の仕方が）

Read Window: 60 secs

ちなみに読取結果は下記のようなJSON形式（かKey-Value Pairs）で通知されます。

{
 "reader_name": "Impinj RFID Reader",
 "mac_address": "00:16:25:13:08:7B",
 "tag_reads": [{
  "epc": "30352E22B80E2C0800000008",
  "type": "exit",
  "tagPopulationStatus": "ok",
  "firstSeenTime": "2019-11-15T12:17:59.323644Z",
  "lastSeenTime": "2019-11-15T12:18:04.109023Z",
  "firstSeenSector": 3,
  "lastSeenSector": 3
 }, {
  "epc": "30352E22B80E2C0800000008",
  "type": "exit",
  "tagPopulationStatus": "ok",
  "firstSeenTime": "2019-11-15T12:23:09.397258Z",
  "lastSeenTime": "2019-11-15T12:23:18.743426Z",
  "firstSeenSector": 3,
  "lastSeenSector": 3
 }]
}

HTTP POST

最後にこれはトライアル版特有なのかもしれませんが、一度POSTした内容を何回もPOSTしているようです。特有といったのはトライアル版には読取できるタグ枚数が500までという制限があるため、読んだタグを保持し続けているのかもしれません。

今回は10秒間隔でHTTP POSTするように設定しています。

Update Interval: 10 secs

すると、下記のように同じ内容のデータが10秒間隔で通知されてきます。

まとめとこれから

Speedway ConnectをxSpan上で動かしてみました。いくつかパラメータを設定することで、あるタグがいつからいつまでその場に留まったかを通知できることが分かりました。今回は試していませんが、認証機能も持っているため、直接クラウドと連携することも可能です。そういう意味でいわゆるIoTにおけるエッジコンピューティングを担う存在と言えます。今後はパラメータの理解を深め、面白い事例につなげていきたいと思います。

フロントガラスにICタグ貼るだけのETC！？

先日、台北で見かけたトラック、よく見るとフロントガラスにICタグが貼られてました。

街中の市場に停めてあるトラックだったんですが普通にパッシブのICタグが貼られていて、気になって調べてみると、日本でいう所謂ETCの役割を果たすものだったんですね。

何とも合理的で素晴らしいなぁ、さっそく真似したいなぁと思うのですが、日本だとフロントガラスにシール貼るだけで道交法違反になりますのでご注意くださいね（笑

ちなみに、フロントガラスにICタグ貼る系で気になってるのが、ブラジルの事例。
https://www.nfcw.com/2019/09/10/364322/nissan-to-build-rfid-payments-into-all-cars-sold-in-brazil/

新車のフロントガラスに、最初からICタグはった状態で販売してるというのだから驚きです。

高速道路はもちろん、駐車場やガソリンスタンド、それからマクドナルドみたいな飲食系も対応してるみたいで、どこでもドライブスルーだそうです。アイデア次第で、ほんと色んな使いみちありますね！

第２７回 宜野座村まつり

１０月２６日、２７日に宜野座で開催されている宜野座村まつりに出展しています。

ゲスト豪華

もりだくさんの内容

のんびりな展示

近くの方はぜひ遊びにきてくださいねー