スキップしてメイン コンテンツに移動

簡単にできるIoT~振動の測定①


先日(といっても随分経ってしまっていますが…)とある方から、M5StickCというデバイスをいただきました。それで、どんなことができるのかと試してみたことを紹介します。

M5StickC


このデバイスは親指(より少し小さい?)くらいのサイズですが、中にESP32-PICOというモジュールが搭載されていて、WiFiやBluetoothの通信ができます。また、MPU6886というモジュールも載っていて、加速度、ジャイロ、(デバイス内部の)温度センサーが使えます。液晶画面やボタンもついています。要するに、いくつかのセンサーと、操作や通信をする機能がコンパクトにまとまっているデバイスです。

そして、このデバイスのいいところは、デバイスを制御するためのソフトウェアを作るのも非常に簡単ということです。ネットワークにつながる部分が既に作り込まれていて、少し追加で設定するだけで、すぐにWiFi(そしてWiFiを経由してインターネット)との接続も可能です。

この手の電子工作モジュールがよく売られているSWITCH SCIENCEでも扱っています。

何を作るか

機械などに取り付けたセンサーから得られるデータを、クラウドに収集して分析して、人の行動の参考にしたり、他のシステムを動かしたり、機械のコントローラーにフィードバックして自動制御したり、というのがよくあるIoTの全体像です。M5StickCを使えば、このようなIoT的なシステムが簡単に構築できることが期待できます。

とはいえ、このデバイスでどんなデータを取得したら役に立つのか、というのは意外と難しい話です。昨今、ノーコード/ローコードで、プログラマでなくてもプログラミングができる!ということがよく言われます。しかし、システムを作る上で難しいのは、コードを書くところよりも、何を作るかを決めるところです。これはプログラマやエンジニアでも上手くできる人が少ないですし、ユーザー企業で現場の業務をよく知っている人ならできるというわけでもないです。課題をよく吟味して、業務やビジネスがどう変化すると良いのかを全体最適の視点から捉えないと、間違ったものを作ってしまいます。

本来は、課題があって、それから手段が検討されるわけですが、今回は手段が手元にあって、そこから何ができるか考えています。完全に間違いパターンです。そのため、実際に役に立つかどうかは分かりませんが、よくあるIoTの課題である、ネットワークに接続されていない設備の稼働状況を監視したい、というものを漠然と想定してみます。
設備の稼働状況を見るのには、電気の流れや使用電力の変化、計器の変化を監視するケースがありますが、今回は振動に着目してみます。設備の特徴から考えているのではなく、もちろん手元のM5StickCに加速度センサーがあるからです。

物理的に動く設備には多かれ少なかれ振動が発生します。うちにあるサーキュレーターも稼働中に触ってみると振動が感じられますし、風力の違いによって振動も変わるようです。そこで、その振動をM5StickCの加速度センサーで捉えることで、稼働状況を監視できるのではないか、という仮説を立てました。

どれくらいデータを取るのがいいか

振動データはクラウドに送って分析できるようにします。そうすると、デバイスからインターネット経由でデータを送る通信が発生しますが、あまりたくさんのデータを通信するのも、通信の回数が多くなるのも大変です。そこで、一定の時間おきに、ごく短い時間の振動データをサンプルとして取得して送ることにします。

機械の状態変化を、どのくらいの時間おきに取ればいいかは、どんな機械をどのように使っているかによります。うちのサーキュレーターの稼働状況を監視するには、10分に1回、どうなっているか見れば十分です。また、振動データは10分間ずっと取得するのではなく、ごく短い時間のデータでも、どれくらいの振動が起きているか分かるのではないでしょうか。

ただ、どれくらい細かくデータを取るのが良いかは、精緻に考えると難しそうです。ひとまず簡単に考えてみます。うちのサーキュレーターはそんなに回転しないと思いますが、もし1分間に3000回転する機械が、回転ごとに振動を起こすとしたら、50Hzになるでしょうか(正確なところは僕には分かりません…)。50Hzだと20ミリ秒に1回の振動があるので、それより細かく振動データを取らないと、振動を検知できません。今回は、5ミリ秒ごとに振動データを取ってみます。あまり細かすぎるとセンサーが対応できなくなる可能性もありますが、センサーの仕様を調べてみると低電力モードでも2ミリ秒(500Hz)に対応できるようなので余裕があります。

データの取得数は、コンピューターの世界では2のn乗が都合が良いので、256個とします。5ミリ秒ごとに256個データを取ると、時間にして約1.28秒間のデータになるはずです。1秒以上のデータが取れれば、1秒に1回動く時計のような機械でも動きが検知できる可能性が高いです。
ところで、このデータを1年間集め続けるとどうなるでしょうか。10分につき256個のデータが蓄積されるので、1日で36,864個、1月で1,105,920個、1年で13,455,360個のデータが集まることになります。世の中でビッグデータと言われるほどのものではありませんが、ちょっとしたデータ量にはなります。1年分のデータをExcelに記載すると、だいぶ動きが重くなるでしょう。

どこにデータを集めるか

さて次は、データを蓄積する場所についても考えてみます。クラウド上でデータを扱う方法はいくつもありますが、今回は簡単に実現したいので、Googleスプレッドシートに書き込んでみます。Google App Script(GAS)という仕組みでデータを受け取る口を作ることができて、そこから受け取ったデータをスプレッドシート内に自由に配置できます。

また、データを集めたあとに、どのような分析をすると、設備の状態を判断することができるのかは、データを集めて試行錯誤しながら検討することになります。取得したデータを眺めてみる際にも、スプレッドシートにはグラフを作る機能や、数式を扱う機能があるので、便利です。

ひとつ問題があるとしたら、データ量です。Googleスプレッドシートには、ひとつのファイルに500万セルまでしか保持できないという制限があります。今回、1年間で13,455,360個のデータが集まるという計算があったので、1年分の振動データはスプレッドシートに入り切りません。ただ、今回は試しに作ってみるだけなので、1年間も運用しません。まずは簡単に実現することを優先して、Googleスプレッドシートを使います。

設計メモ

ここまでのところを図にまとめてみます。
いよいよ、これから作り始めよう!というところですが、前置きが長くなってしまったので、つづきはまた次回とします。

このブログの人気の投稿

簡単にできるIoT~振動の計測②

  前回 は、何を作るかを考えて、設計メモにまとめました。 簡単にできるIoT~振動の測定① 先日(といっても随分経ってしまっていますが…)とある方から、M5StickCというデバイスをいただきました。それで、どんなことができるのかと試してみたことを紹介します。 M5StickC このデバイスは親指(より少し小さい?)くらいのサイズですが、中にESP32-... まだプログラミング自体には触れていませんでしたし、大まかな設計をしただけですが、ここまで意外と考えることが多かったと思われるかもしれません。ですが、どう作るかよりも、何を実現するかの方が重要です。本来はもっと何を実現するかを模索するのに時間をかけるべきだと思います(そのためにシステムを試作することも含めて)。 さて、今回はさっそくこれを作ってみます。作る方法はネットでいろいろな人が教えてくれるので、それらを参考にすれば、すぐに作れます。 データを受け取って蓄積する側を作る まずは、Googleスプレッドシートに以下の図のような表を作り、M5StickCから受け取ったデータを書き込めるようにします(図では既にデータが蓄積されています)。 A列「gasCodeVer」:一応、動かしているスクリプトのバージョンを記録 B列「receiveTime」:データを受け取った時刻(receivedでないのはご愛嬌) C列「dataNum」:いくつデータが取れているかを記録 D列「data1」以降:加速度データ そのために、以下のことをします。 Googleドライブでスプレッドシートを作る 「ツール」→「スクリプトエディタ」からスクリプトエディタを開く Apps Scriptでスクリプト(コード)を書く 「デプロイ」→「新しいデプロイ」→「種類の選択」→「ウェブアプリ」からデプロイ 基本的なやり方は下の参考ページ(前半部分)を見れば、すぐに分かります。実際に手元で出る画面と少し違うところがあるかもしれませんが、だいたい一緒かな、という緩さをもって見ていくと良いと思います。 [M5Stack] M5Stackで取得したデータを、Google スプレットシートへ書き込む M5StackはWi-Fi機能との連携が特徴の一つとなりますが、やってみたくなるのがクラウド連携だと思います。そこで、今回は、Go...

営業マネジメントを整える①

(以前、noteに書いた記事をこちらに転載します) 【注意】この一連の記事では、具体的にどのアプリがいいか、ということは書きません。営業マネジメントの考え方をベースに、どのような観点からアプリを検討するか、ということを書きます。 さて、どのようなアプリ、システムを導入するにしても、まずはそれで「何をしたいのか」という目的が大事です。 これまで導入していなかった営業支援アプリを、いま導入したいと考える事業者には、何かしら営業活動を変えていきたい、という想いがあると思います。 では、どう変えたいのか。事業者によって、いろいろな表現が出てくると思いますが、多くの場合、営業支援アプリは「営業マネジメントを整える」ために導入されます。 ここでいう、自社の「営業マネジメントが整っている」というのは、どういうことでしょうか。このシリーズ記事では、「営業マネジメントを整える」方法を説明しながら、営業支援アプリの役割を改めて確認することで、アプリを選ぶ際のヒントを示していきたいと思います。 営業マネジメントは、なんとかして「to be」に近づけること そもそも、なんで営業活動をやっているのか、と言ったら、商品やサービスを売りたいからですね。でも、なんで売りたいのか、と言ったら、お金が欲しいから、ということでもあるのですが、根本を考えていくと、会社や事業のありたい姿、あるべき姿を実現するためです。 何もしないでいる状態(as is)と、あるべき姿(to be)には差分(Gap)があるから、営業活動によって、その差分を埋めていくわけです。 経営の話をするときに、よく出てくる図 営業活動は、この「to be」に近づく活動、ということですね。 そして、マネジメントというのは「なんとかする」ということなので、営業マネジメントは、なんとかして「to be」に近づけること。 それが整うということは、営業活動によってホントに「to be」に近づいているか、確かめられて、もっと近づけるように工夫できる状態になっている、ということです。 トップダウンとボトムアップを統合する この「to be」は、会社や事業のありたい姿、あるべき姿である、ということをさきほど書きました。ということは、営業マネジメントの出発点には、会社や事業の未来をどうしていきたいかを明確にすることがあります。そして、その未来に向かって、...

営業マネジメントを整える②

(以前、noteに書いた記事をこちらに転載します) 営業マネジメントを掘り下げながら、それぞれのマネジメントレベルで営業支援アプリに必要な機能が何かを示していくことで、いろいろ考えるヒントにしたい、というシリーズ記事の第2回です。 前回、「営業マネジメントを整える」というのは、営業活動によってホントに「to be(ありたい姿/あるべき姿)」に近づいているか、確かめられて、もっと近づけるように工夫できる状態にする、ということだと書きました。 営業マネジメントを整える① さて、どのようなアプリ、システムを導入するにしても、まずはそれで「何をしたいのか」という目的が大事です。これまで導入していなかった営業支援アプリを、いま導入したいと考える事業者には、何かしら営業活動を変えていきたい、という想いがあると思います。... そしてそれは、 「to be」→「経営計画」→「営業活動」→「結果」 というつながりを、上手くコントロールすることでもある、という話を、以下の図を出しつつ、しました。 今回も出てくる難しい図 なので、この図をひとつずつ説明していきたいと思います。 まずは「to be」→「経営計画」のつながり 図の一番上には「経営計画、売上目標」と書いています。営業活動をしていくにあたって、これを明確にしましょう、というのは、当たり前のことだと思いますよね。基本的に、このシリーズ記事で書くことというのは、全部、当たり前のことを当たり前にやる、という話でしかないです。ただ、それが意外と難しいので、改めて確認することは大切かなと思います。 この経営計画は、「to be」→「経営計画」というつながりの最初の部分ですから、「to be」に行き着くための計画です。この「to be」の反対は「as is」で、現状のまま進むとこうなる、というものです。 つまり逆から考えると、「to be」というのは、現状のままではない、と言えます。 経営の話をするときに、よく出てくる図、再び 現状維持を目指している組織においては、この「to be」と「as is」のギャップが小さくなります。そのような組織では、営業支援アプリを基盤としながら営業マネジメントをしていく必要が、あまり...