今週はIoTの演習です。 目次 7.1 IoTとは？ 7.2 IoTプラットフォーム 7.3 ThingSpeakにデータを送信する 7.4 ThingSpeakからデータを受信する 7.5 応用 7.6 実習 7.1 IoTとは？ 少し前から、普通の新聞等でもIoTという言葉をよく聞きますね。これは Internet Of Things の略で、モノとモノがインターネットを通じて通信することで構築されるシステムのことです。ここでいうモノとは、コンピュータと通信機能が搭載された物であればなんでもよくて、家電製品や監視カメラ、センサーを搭載したデバイスなどのことです。 インターネットは、その黎明期には電子メールやWWW、電子商取引などに使われるネットワークとして認識されており、人と人、あるいは人とモノの間のネットワークというイメージでした。IoTはそれを拡張して、モノとモノもインターネットにつなげると色々な可能性があるよ、ということなのです。 IoTは、概念としては全く新しいものではないのですが、マイコンや無線通信のデバイスが安価で小型になったこと、大量のデータを処理することがクラウドコンピューティング技術の進歩によって容易になったこと、AIが進歩したことなどにより、様々な応用分野が現れ広く認知されたというべきでしょう。語呂(語形？)が良かったことも流行った一因だと思います。 所詮は流行り言葉なので、IoTという言葉自体はすぐに消えていく運命にありますが、技術それ自体とそれがどのように応用可能であるかは、きちんと理解しておく必要があります。この演習では特に、IoTがどのように応用可能であるかに焦点を当てて学修していきます。 IoTで何が実現できるのか IoTを活用すると、どんなことができるのでしょうか。製品をベルトコンベア式に生産する工場を考えてみましょう。工場には生産目標があり、そのための生産計画があります。順調に生産が行われていれば利益が出るのですが、ベルトコンベアや生産設備に故障が起こると生産がストップして損が出ます。最適解は故障が起こる直前で生産設備の部品を交換することですが、生産設備の数が多いのでなかなか難しいです。また、問題が発生した時に、どこが壊れたのかが即座にわかると嬉しいです。そのために、多数ある生産設備にセンサーをつけて、機器の状態をサーバに逐一送ることが考えられます。例えば、機器の温度を測ったり、機器から発生する音を録音したりして、そのデータを蓄積するわけです。蓄積されたデータを解析することによって、温度が何度になったら故障の前兆であるとか、機器からどんな音がし始めたら故障の前兆であるかなどのことが分かるかもしれません。 要するにIoTは、監視作業や計測作業の自動化、少し面倒な作業の単純化などをやる仕組みということですね。監視作業や計測作業の自動化をすれば、当然膨大なデータが蓄積されます。これを世の中ではビッグデータなどと呼んでいて、そのデータを解析し問題の最適化を行うためにAIを使ったりするというわけです。そいういう文脈では、IoTとビッグデータとAIはセットで語られることが多くなっています。 この演習では、データの分析・解析及び最適化については扱いません。モノとモノとが通信するというところだけを取り出して演習をしてみたいと思います。 7.2 IoTプラットフォーム IoTプラットフォームというのは、IoTのエッジデバイスを管理したり、エッジデバイスからデータを集めるインターフェイスを提供したり、集めたデータを加工したりすることを助けてくれるシステムです。IoTにおけるエッジデバイスとは、センサなどを搭載して情報を収集する役割を持つデバイスのことです。 ここでは、ThingSpeakというIoTプラットフォームを使います。11/22(月)の開発論の授業でも、ThingSpeakへのデータのアップロードを行ったことと思います。 https://thingspeak.com/ ThingSpeakは、IoTのエッジデバイスから情報を収集してデータを視覚化したり、他のWebアプリなどにデータを渡す中継基地のような役割をはたしたりしてくれます。 上記の図を見ると分かるように、エッジデバイスとThingSpeakの間は、モノとモノがインターネットを使って通信します。 ThingSpeakは無料で使用することができますが、いくつか制約があります。 1日あたりの送信データが8,200以下 データの送信は15秒以上間隔が必要 チャネル数は最大4つまで プライベートチャネルは最大3つまで この中でも特にデータの送信間隔に注意してください。データを送信する際には30秒くらいの間隔を開けるようにするのがよいでしょう。 通信プロトコル エッジデバイスとThingSpeakの間はhttpsを使って通信します。httpsは、SSLを使ってhttp通信をします。SSLとは、TCP通信を暗号化し通信経路における情報の盗み見、改竄などを防ぐためのプロトコルです。 httpsはhttpをSSLの上に載せただけなので、プロトコルとしてはhttpということになります。現在広く使われているhttpのバージョンはHTTP/1.1です。これ以降httpと言えばHTTP/1.1のこととします。 httpはクライアントサーバ型のシステムにおける通信を規定しています。今回の場合、クライアントはエッジデバイスで、サーバはThingSpeakです。 httpには8つのメソッドがあります。しかし、実際に使われるのはGETとPOSTの2つです。 GETは、クライアントがURI(URL)を指定してサーバにリソースの要求をする際に使います。 POSTは、クライアントがURI(URL)を指定してサーバにデータを送信する際に使います。サーバはデータ受信後にクライアントにデータを返すことができます。 エッジデバイスからThingSpeakにデータを送る際にはGETメソッドを使います。データを送信するのだからPOSTメソッドでは、と思いますよね。実はGETメソッドを使ってもサーバにデータを送ることができます。 上記のURLの?以降はGETパラメータと呼ばれている情報で、サーバ側ではこの情報を取り出して使うことができます。GETパラメータは正式にはクエリと呼ばれる部分ですが、一般的にGETパラメータと呼ばれているので、ここでもそのまま使います。?以降の部分は&で区切られています。上記の例の場合、以下の3つのパラメータがあります。 api_key=APIキー field1=2 field2=5 これらをキーバリュー形式のデータだと思うと、api_keyやfield1、field2の部分はキーにあたり、APIキー、2、5が値(バリュー)にあたります。 GETパラメータで渡されたデータは、もちろんサーバ側できちんと取り出しのための処理をしなければいけません。ThingSpeakはそれをよいようにやってくれるという訳です。 […]

Read More »

今回はアナログ出力・アナログ入力を扱います。アナログというのは「連続的な」という意味でしたが、ここでは 0 (0V) と 1 (3.3V) の中間の電圧を入出力するという意味です。マイコン、もしくは、 Raspberry Pi では、 0 (0V) か 1 (3.3V) のデジタル信号を扱うのが基本であるため、アナログ信号を扱うには追加の知識や回路が必要になります。 目次 6.1 PWM 6.2 A/Dコンバータ 6.3 MCP3004 6.4 抵抗分圧回路 6.5 光センサ 6.6 実習 6.1 PWM マイコンの世界はデジタルなので、プログラムで電圧を制御するのは、ちょっと難しいことです。そこで、PWMという手法が登場します。 これはデジタル出力を使って擬似的にアナログ出力を実現する方法だと思ってください。 仕組み マイコンのデジタルピンからの出力は、HIGH(例えば3V)かLOW(例えば0V)のどちらかだけです。しかし、0Vから3Vまでの間で電圧を自由に変えたいという場合があります。例えば、LEDの明るさを調整したい場合などです。こういう時には、PWM(Pulse Width Modulation)という方法を用います。 PWMの仕組みを一言で説明すると、HIGHとLOWを素早く切り替えることによって、HIGHとLOWの間の電圧を擬似的に作り出す方法です。以下の図をみてください。 このようにHIGHとLOWを規則的に繰り返す信号を、パルス波と言います。上記の図で示しているパルス波は、ある一定時間で同じパターンを繰り返していますね。このような繰り返しの間隔を周期と呼び、1秒間に何周期あるかを周波数と呼びます。周期の始まりは、LOWからHIGHに変わる瞬間で、周期の終わりは、次にLOWからHIGHに変わる瞬間です。周波数1kHzと言ったら、1秒間に1000回の周期が起こるような波形を意味します。 図で示したパルス波は、1周期におけるHIGH(3V)とLOW(0V)の間隔が、ちょうど1/2ずつになっています。周波数が十分に高い場合，このデジタルピンにかかる電圧は、3V / 2 = 1.5Vとなります。これがPWMです。実際に電圧を変えるのではなくて、擬似的に電圧を変えているのです。 PWMを使った場合にデジタルピンにかかる電圧は，デューティ比(duty ratio) によって決まります。デューティ比とは，1周期の間にHIGHになっている割合のことです。HIGHが3Vの場合、デューティ比50%ならば1.5V，10%ならば0.3Vとなります。 PWMを使用する場合、どのくらいの周波数が必要かは難しい問題なので、あまり深入りしないことにしますが，1Hzではだめなことは明らかです。1Hzということは、HIGHとLOWが同じ時間であるとすると1周期内で0.5秒ずつです。LEDで実験すると単に点滅するだけです。 PWMの周波数は、デジタルピンの用途によって変わるとされています。例えばLEDを使う際に必要な周波数，モータを使う際に必要な周波数という具合です。モータの場合には10kHzから20kH位が適当でしょう。LEDだと、100Hzくらいでも大丈夫だと思います。 PWMを使って電圧を制御するには、パルス波を作り出す必要があります。パルス波は、タイマを使って作ります。非常に微小な時間をタイマによって作りだし，デジタル出力をHIGHにしたりLOWにしたりします。 例えば、1kHzの周波数でPWM制御をしたいとしましょう。1秒間に1,000周期ですから，1周期は1ms(ミリ秒)です。1周期を10段階に分けると、1段階100µs(マイクロ秒)になります。この100µsをタイマを使って作り1単位オンとすれば10%、2単位オンとすれば20%というように、10%刻みでデューティ比が設定できるようになります。 ミニプロジェクトの資料の「実装のためのヒント」に書いたのは、まさにこれと同じことです。高速にオンオフを切り替えることで、中間の電圧を表現できるのです。知らずのうちに、実験でPWMを行っていたということになります。 試してみよう しかし、実際にPWMを使うときはもっと簡単で、 GPIO […]

Read More »

ここまで学んできたことを利用して、2週にわたるミニプロジェクトを行います。1週目が構想・実装で、2週目が発表・振り返りです。 目次 課題 発想のためのヒント 実装のためのヒント 1週目から2周目までの宿題 課題 先週までに個別に学んできたことを組み合わせて、日頃感じる問題や不都合を解決するシステムのプロトタイプを作成してください。日頃感じる問題や不都合とは、自分の身近な問題でも社会の大きな問題でもどちらでもよいのですが、共感を得られるものにする(そして共感を得られるような発表をする)ことが大切です。 先週までに学んできたこととは、デジタル入力・デジタル出力・コンソールへの出力(print()関数)・ウェブページへの出力(Flask)です。まだセンサやアクチュエータのことは習っていないわけですが、プロトタイプを作成すればよいわけなので、すでに習ったスイッチやLEDを任意のセンサやアクチュエータに見立てて、今後置き換わる予定であることを前提として話を進めてOKです。 発表会(発表の方法) 2週目の5限の時間に発表会を行います。(2週目の4限の時間は発表前の最終調整にあててよいです。)発表会は2部構成として、第1部はスライドを用いた口頭発表・第2部は展示会方式のデモ発表とします。 第1部の口頭発表は、グループごとに教卓のスクリーンの所まできてもらって、PowerPointやKeynoteで作成したスライドを投影して発表を行います。発表時間は各グループ5分以内とします。どんな問題を扱うか・なぜその問題を扱うのか(その問題が解決するとなぜうれしいのか)・どのようなシステムなのか・仕組みはどのようなものか・スライドでできる範囲のデモ・第2部ではどこでデモ展示を行うか・あればその他必要と思う情報、というようなことから必要なものを選んで5枚程度のスライドにまとめることを想定しています。しかし、発表時間5分以内であればこれに限りません。 第2部のデモ発表は、教室を展示会会場に見立てて、各グループの座席にて展示を行います。展示で示すことは、実機を用いたシステムの動作デモです。デモをする人とデモを見学しに行く人に前後半で分かれて、見学の人は好きな展示を見に行くという方式をとります。第1部のスライド口頭発表でのデモを、第2部の実機デモを見に行きたくなるようにつなげられるとよいと思います。また、今回の質問タイムは第2部でのデモ後の自由対話でのみ行うこととします。第1部の発表を聞いて疑問に思ったことも、この第2部で質問するようにしてください。 発想のためのヒント 問題から考える 作るもののテーマを考えるとき、ついいまできること(シーズ)から考えてしまいがちです。しかし、そうすると、できたものの実用のイメージがわきづらかったりして、それがあったほうがよいという共感を得られにくかったりします。ここは、何を解決したいのか(ニーズ)から考えたほうがよいと言えます。問題から考えるということです。そのほうが説得力があります。 センサがあればできるであろうことの扱い 問題から考えるといっても、まだ対してできることを習っていないために、本当にその問題を解決できるのかがわからなくて、そのテーマで本当によいのか不安に思ってしまうという人もいると思います。その感覚はある意味正しくて、実際の創作活動では、やりたいこととできることが必ずしも一致していなくて、その両側から繰り返し再検討をすることはよくあります。また、最終的にどちらかを妥協して済ませるということもよくありますし、ときには必要なことでもあると思います。(だからこそ、日頃からできることのスキルやツールを増やしておくこと(＝できることの範囲を広げることで，やりたいことをカバーする確率を高めること)は大切なことなのです！) しかし、今回のミニプロジェクトでは、実現できるのかどうかは深く考えないこととすることをポリシーとしたいと思います。もちろん、このセンサを使えばこのようにしてできるはずだという裏付けがあると本来はよいのではありますが、その裏付けがないことを理由に考えたことをあきらめなくてもよいこととします。 センサがあればできるであろうことは、本当に実現できるのかどうかがわからなくても、スイッチの入力をそれに見立ててプロトタイプを作成してOKです。 モータがあれば/ブザーがあればできるであろうことの扱いも同様で、本当に実現できるのかどうかがわからなくても、LEDへの出力をそれに見立ててプロトタイプを作成してOKです。 実装のためのヒント 以下は、必ずしも使わなくてもOKなのですが、より高度なことをしたい場合のヒントです。 オンオフだけではない入力を扱いたいとき スイッチの入力はオンかオフかの二者択一ですが、オンオフの中間の度合いも扱うような入力を持つシステムを構想しているとします。 このようなときには、たとえば「最初にスイッチが押されてから3秒の間に、何回スイッチが押されたかを計測して、その数を度合いとする(最大5)。」という方法がとれます。3秒間の間に5回スイッチが押されたら「〇〇度＝5」が入力されたものとして、3秒間の間に2回スイッチが押されたら「〇〇度＝2」が入力されたものとする、というような具合です。これは、 pref_counter() を使って工夫すると実現できます。 オンオフだけではない出力を扱いたいとき LEDへの出力もオンかオフかの二者択一ですが、オンオフの中間の度合いも扱うような出力を持つシステムを構想しているとします。LEDへの出力の大小は明るさなので、第3回の実験で確認したように抵抗の値を変えれば調節することができますが、プログラムの動作中に変化させたいものとします。 このようなときには、実は第4回の実験4が対処法のヒントになっています。第4回の実験4の種明かしをすると、「オンオフを切り替えているのですが、切り替えが速すぎて点滅が見えずに、点灯しているように見える。」ということです。しかし、その明るさはどうでしょうか？ずっとオンにしているときよりも暗いのではないでしょうか。実は、目に見えない速さでオンオフを切り替えている場合に、オンにしている時間の長さを短くすれば、暗く点灯するように見えます。このことを利用して、オンにしている時間の長さを変化させれば、明るさをプログラムの動作中に変化させることができます。 1週目から2周目までの宿題 1週目には提出物はありません。一方、2週目には発表会を行いますが、加えて授業内課題として「ミニプロジェクト報告書」の提出を課します。 したがって、第2週に向けては、実装・プレゼンとデモの準備に加えて、ミニプロジェクト報告書の下書きを書き進めておくとよいと言えます。Classroomの課題ファイルに見出しを作成してありますので、プロジェクト報告書はその見出しに沿って書いてください。 — by 飯田 周作、沼 晃介、石井 健太郎　専修大学ネットワーク情報学部

Read More »