2019年7月1日月曜日

大量のセンサーデータの可視化にKibana+Elasticsearchが最適だった話

第52回のIoTLTで話した内容を、改めて記載します。

センサーの測定値を数分おきに取得していたんですが、2年ほど動かしていると結構な量になりまして、CSVに変換してExcelでグラフにしようとすると描画まで強烈に待たされるようになってました。何かいい方法はないかと困っていたところ、同じく3月のIoTLTで発表のあったKibanaを使って可視化をがんばる話を聞き、これは良さそうと思って試しました。

Kibanaについて

Kibanaは全文検索エンジンElasticsearchのフロントエンドとして動くWebアプリなので、Kibanaを使うにはElasticsearchも合わせて使います。Elasticsearchにどんどんデータを溜め込み、ブラウザ経由でKibanaに接続してグラフを設定します。

基本機能はオープンソースになっていて無料で使えるのもありがたいです。

Linuxだと環境構築がすごく楽

たまたま持て余していたPCにLinux (Ubuntu 18.04) を載せて動かしています。公式に記載のaptを使った手順に従うと、光の早さで構築できました。最初はもともと入っていたWindows 10で動かそうとしたのですが、特にKibanaのZipパッケージはNode.jsのモジュールがまるっと入っており(KibanaはNode.jsのWebアプリとして動作する)、解凍で何年も待つくらい遅くてあきらめました。

数万件のセンサーデータからのグラフ描画が速い

まずElasticsearchが全文検索エンジンなので、溜め込んだデータの中から特定の条件にマッチするデータの抽出が非常に速いです。さらに、すべての時系列データを描画するのではなく、細かい範囲ごとに最大最小や平均などでデータを間引きしてから描画するので、長期間の動きをサクッと確かめることができます。

データの追加について

今手元で生成され続けているデータは、コマンド出力結果そのままのテキストだったりバイナリ生データだったりするので、Elasticsearchに投げ込むには一手間加えてJSONにする必要があります。今この部分はNode.jsを使って変換しています。これはNode.jsが使い慣れているだけで、実際はどの言語を使ってもいいと思います。

ちょっと困っているところ

グラフをディスプレイに表示し続けるとテレメトリーのようでかっこいいのですが、無料枠ではこの表示中も編集可能でロックはできません。ライセンス購入になると一気にいい値段になってしまうようで二の足です。

2019年4月15日月曜日

技術書典6のふりかえり

技術書典6で机をいただいたので、展示とPDFの頒布を行ってきました。どちらかと言えば本を売るよりもMaker Faire気分で、作ったものの自慢に出てました。

被チェック数

前回の2倍以上の数になっていて驚きました。サークルカットにわかりやすい画像を設定したせいかな、と思っていましたが、いくつかのニュースサイトに掲載されていることに気付きました。

それぞれあからさまに「自分で作るゲームボーイのカートリッジ」と書いてくれていました。ありがたい限りです。開催中も「お友達から買ってくるように言われた」という方が3人くらいおられまして、興味を持ってもらえるのは嬉しいけど参考になるだろうか?と若干不安です。

チップチューンのみなさんからの期待

もともとは「できそうだから」という軽い気持ちで作っていた自作カートリッジなんですが、LSDjを動かすためのカートリッジが年々減っているなかのポッと出てきた新作、かつ日本語で対応できるとのことで湧き上がっているとうかがいました。思わぬ方向からの援軍にモチベーションが高まりますね。

今後の課題

  • もう少し展示に気を遣う
  • そろそろ量産できそうかな
  • M3にも出てみようかな
  • ゲームボーイカラーの対応

お持ちいただいたゲームボーイカラーだと、起動ロゴ以降アプリケーションが動作しませんでした。旧ゲームボーイ用カセットということで動いてくれないものか…と期待していたのですが、一筋縄ではいかなさそうです。

2019年2月24日日曜日

ゲームボーイの自作カートリッジでLSDjが動くようになった

ゲームボーイのカートリッジを自分で作り、技術書典に本を出してから、LSDjが動くといいねという話をよく聞いていました。やっと動くようになったのでつまずいていた点を記載します。

マイコンの容量を増やす

今までの基板ではSTM32F407を使っていました。1MBのFlashを持っているのですが、これだと前述の512KBのROMイメージと128KBのRAM領域を確保できなかったので、ROM容量の多いSTM32F427(2MB)/STM32F413(1.5MB)の2種類を試しました。パッケージサイズは同一でピンアサインもほぼ同一です。

STM32F413でもROM/RAMの領域を確保でき、ソフトの起動を確認できました。413は427に比べてQSPIが載っているので、外部Flashを活用するならこちらのほうがいいのかもしれません。でも2MBの427は大して単価もかわらないのに容量がでかいのでもう全部これでいい気がしています。

MBC5の動きに対応したコードを追加する

今までも動いてはいたんですが、上記のように実装を間違えていて、音がぶつぶつと途切れるようにしか鳴らないし全くテンポどおりに動かない(超遅い)動作になっていました。リンク先のドキュメントと、もとのコード(コメントアウトになっているところ)を見てて気付きました。

音が鳴るようになりました

お知らせ

技術書典6に出ます。前回出展時の本に加筆修正を加えて、第2版として出します。値上げするけど、今まで買ってくれた人はそのままダウンロードできるようにする予定です。「い06」でデモ機と見本誌を用意して展示します。

バッテリーバックアップについて

外部Flashに保存かな〜と考えていたのですが、2MBだと容量の余裕がすごいので内蔵Flashに保存でいいのかもしれません。

2018年12月25日火曜日

enebularはNode-REDの一発デプロイツールとして超便利なのでは

先日ウフルのenebular meetupに参加するので、Node-REDを常時動かすためにherokuにデプロイしてみました。公開されている手順でherokuにNode-REDの環境がサクサクと立ち上がりました。このときに「enebular=IoTをよしなにするツールだと思っていたけど、Node-REDを即デプロイできるツールとしても便利なのでは?」と思いました。

Webhookを受け取る環境をサクッと立ち上げられる

過去にWebhookを受け取りたい場面があり、その都度サーバーの設定をするのは面倒だなと思っていました。その当時はngrokを使いましたが、enebularでWebhookを受け取るフローをつくりそれをherokuにデプロイしておけば、ngrokのようにローカルでプロセスを動かしている必要はないなと。ちょっと試してみました。

入力にHTTP Inputを置き、まずはそのままHTTPの出力につなぎます。こちらの3項にあった「HTTPの入力は本当に入力しかしないので、HTTPの出力につながないとWebhookの発行側がエラーになる」という内容を参考にしています。入力のHTTPを分岐し、とりあえずデバッグで中身を全部出力するようにします。

Webhook発行側に登録するURLは、herokuデプロイ前なら「デプロイボタンの左にある(i)のボタンで表示されるドメイン+HTTP Inputに設定したパス」が使えます。これで動作確認ができれば、そのまま先ほどの手順に従ってHerokuにデプロイしてWebhookを常時待機できるようになります。

2018年12月16日日曜日

なぜnanoloopのカートリッジは基板だけで差し込めるのか

ゲームボーイ用カートリッジのnanoloopは、カートリッジ本体が基板のみで、いわゆるカートリッジらしい樹脂筐体を含みません。nanoloop monoはさらに、カートリッジの端子幅だけしか本体サイズがありません。なぜこれで差し込みに問題ないのか、差し込み時の位置合わせは正確に行えるのかが疑問でした。この理由がわかれば、今自分で作っている基板も他のカートリッジから筐体を借りなくて済むので、調べてみました。

厚みについて

カートリッジと本体側ソケットそれぞれの端子が接していれば動作します。一般的なカートリッジの端子部の厚みを基板に合わせれば動作すると考えました。

2.1mmなので、厚みがおおよそ2.0mmあればおそらく大丈夫だろうと思います。

差し込みについて

厚みがわかったので、差し込み時の位置合わせやガイドについて調べました。カートリッジのふたを開けた状態で差す様子をみると、この状態では筐体(矢印で示している箇所)が位置を合わせているように見えます。

ここで、厚みをおおよそ2.0mmに調整したカートリッジ基板を差し込んでみます。

正しい位置に収まり、カートリッジも正常に動作しました。このときにわかったのですが、位置合わせのガイドとなっているのはカートリッジ筐体ではなく、本体ソケットの突起でした。次の写真は差し込み口を上から見た図です。

正しい厚み・正しい幅の板が上から降りてくるとき、ソケットのガイドに従って差し込まれるので、端子同士がまっすぐ接触するようになっています。

結論

基板厚み2.0mmでカートリッジ基板を製造すれば、筐体なしでもカートリッジは機能する。

機能検証(とカートリッジをもとのゲームに戻す)のために、上で差した基板の厚みを2.0mmにしたものを製造中です。届き次第試します。

2018年12月14日金曜日

AE-TYBLE16にBLE-MIDIを実装するための途中経過

秋月電子通商のBLEモジュール AE-TYBLE16 は、SWDの書き込み端子が出ているのでファームウェアを書き換えられます。NordicのnRF5 SDKのサンプルコードをいろいろ使うだけでも十分できるのですが、興味のあった MIDI over BLE はサンプルがなかったので実装に挑戦しました。アドベントカレンダーに投稿するのに間に合わなかったので、今回は途中経過を記載します。

Nordic nRF5 SDKでサービスの実装が大変

仕様をみると、次のように実装することとあります。

The following service and characteristic are defined:

  • MIDI Service (UUID: 03B80E5A-EDE8-4B33-A751-6CE34EC4C700)
  • MIDI Data I/O Characteristic (UUID: 7772E5DB-3868-4112-A1A9-F2669D106BF3)
    • write (encryption recommended, write without response is required)
    • read (encryption recommended, respond with no payload)
    • notify (encryption recommended)

「このUUIDのサービスとキャラクタリスティックを実装すればいいんだろ」と思っていましたが、この時点でまず大変でした。

今回のようにサービスとキャラクタリスティックでUUIDが異なっていると、「フルサイズのUUIDをいくつも使うぞ」という設定が必要でした。フォーラムのやり方でそれっぽいのを見つけて実装しデバッグすると、ログにメッセージが出ます。「ユーザーが使うメモリの割当を次のように変えろ」というメッセージが出るので、それに従ってリンカスクリプトを修正します。これでやっと電波が飛ぶようになります。

仕様の「encryption recommended」にひっかかる

電波が飛ぶようになったのですが、MacはMIDIポートとして設定してくれません。おそらく仕様の「encryption recommended」が欠けているのが原因のようで、Mac側としてはマウスやキーボードのようにペアリング動作を完了できないとMIDIポートとして設定されないようです。もともとベースにしていたサンプルコードがペアリング処理のないものだったので、ペアリング処理のあるサンプルに移植するのもめんどうだなとなって放置気味になってきたところで今日に至っています。

まとめ

すごく手間なので、Arduino環境でつくるほうに乗り換えようかちょっと考えています。でもペアリングの動きとか後ろ側の動きについてかなり勉強になった感じはするので、なしではないです。

2018年11月12日月曜日

秋月のBLEモジュールでHIDを扱えるようにする

秋月に太陽誘電のBLEモジュール AE-TYBLE16 が販売されています。このモジュールは端子が底面からのみ出ているので、基板実装をしないと扱いづらいのですが、秋月がその基板実装を行った状態で販売しているので非常に扱いやすくなっています。

このモジュールは中のnRF51822に対してあらかじめファームウェアが書き込まれており、電源が入ると独自のサービスを飛ばします。UARTで適切なコマンドを入力すると、その中のキャラクタリスティックにデータが送りこまれると聞いています。

この秋月モジュールは電源・GPIOに加えてSWDIO・SWDCLKが出ているので、JLink等のライターを使用すると自分で作ったファームウェアに置き換えられます。

ファームウェアの書き込み

Before

After

J-LINKから書き込むにあたって、最低限次の配線接続があれば動作します。

  • SWDIO
  • SWDCLK
  • リセット
  • Vref
  • GND

20ピンJ-LINKだと、これに加えて5V供給とUSB-UART変換が使えるのでそれもつないでいます。5V供給をLDOで3.3Vに落とすとモジュール電源とVrefに使えるので、外部電源を容易せずともデバッグができるようになります。当初はブレッドボードにワイヤーを刺していましたが、持ち運びがめんどうなのでユニバーサル基板に実装しました。配線がつながった状態でnrfjprogをつかうと書き込みができるようになります。

nRF5 SDKのサンプルコードを動かす

今回はゲームボーイのカセットに組み込みたいので、nRF5 SDK 12.3.0のうちHID over GATTのマウスサンプルを使いました。

ble_app_hids_mouse/pca10028/s130/armgcc でmakeを実行するとビルドはできますが、サンプルの前提となっている環境と AE-TYBLE16 で異なる箇所があるのでそのままでは動きません。下記を修正しました。

sdk_config.h

  • CLOCK_CONFIG_XTAL_FREQ 255→0
  • CLOCK_CONFIG_LF_SRC 1→0

components/boards/pca10028.h

#define NRF_CLOCK_LFCLKSRCの中身を直す

RTCはモジュールに載っていないので、nRF51822内蔵を使うようにします。

  • .source        = NRF_CLOCK_LF_SRC_XTAL→NRF_CLOCK_LF_SRC_RC
  • .xtal_accuracy = NRF_CLOCK_LF_XTAL_ACCURACY_20_PPM→NRF_CLOCK_LF_XTAL_ACCURACY_250_PPM

components/toolchain/system_nrf51.cとsystem_nrf51422.c

16MHzを32MHzに変更します。

#define __SYSTEM_CLOCK      (16000000UL)→(32000000UL)

ここまで直してNRF_LOGの中身がJLinkRTTのなかに表示されるようになります。APP_ERROR:ERROR:Fatalとだけ表示されるので、マイコンは動いていますがアプリは止まっています。

main.c

ble_stack_initのクロック設定を直します

nrf_clock_lf_cfg_t clock_lf_cfg = NRF_CLOCK_LFCLKSRC;の行は削除。かわりに

    nrf_clock_lf_cfg_t clock_lf_cfg;
    clock_lf_cfg.rc_ctiv = 16;
    clock_lf_cfg.rc_temp_ctiv = 2;
    clock_lf_cfg.source = NRF_CLOCK_LF_SRC_RC;
    clock_lf_cfg.xtal_accuracy = NRF_CLOCK_LF_XTAL_ACCURACY_250_PPM;
を追加。

ここを直すとJLinkRTTにAPP:INFO:HID Mouse Start!というメッセージが表示されて、BLEの電波も飛ぶようになります。

直したけど関係なさそうな箇所

接続はするがペアリングはされない、という状況が起きていて、こういう投稿があったので試してみたら動いたんですが、このブログを書くにあたって再度いちばん最初の段階からやり直してみたら、この変更なしでもペアリングが済んでいて頭を抱えています。