CIID Physical computing

Ats
25 min readJun 7, 2020

--

ソフトウェアエンジニアが CIID の IDP コース(13, 14週目)に参加して学んだことをゆるりと共有します。今回(5/25~6/5)は Arduino を使ったディスプレイ以外のインタフェースの勉強でした。初めてのハードウェアのデザインでとても苦労しましたが楽しかったし、満足感も大きかったです。

Photo by Spencer on Unsplash

11, 12週目の記事もあるので良かったら読んでみてください。

Day 56: Introduction to Arduino

今回の授業のために CIID から、一人一つ Arduino のスターターキットを渡されていました。それを開封する時は、子供の頃のクリスマスプレゼントぐらいワクワクしました。そのぐらいこのクラスを楽しみにしてたので、フィジカルコンピューティングの説明、回路の復習と Arduino の基本の授業を受けている間「早くこれで遊ばせろぉ!!」ってなっていました。その中でも、印象に残ったことを共有しようと思います。

what is physical computing?

最近の IoT の流行によりフィジカルコンピューティングへの注目度が増しています。そんなフィジカルコンピューティングは、そもそも下記のように定義されています。

フィジカルコンピューティングでは、人間の身体とその能力を出発点として、人間が物理的にできることを感知してそれに反応し、その入力をアニメーションやサウンド、モーションのような別の形に増幅することができるインターフェースをソフトウェアとハードウェアの両方で設計しようとしています。

特筆すべき点として、「人間の身体を使った入力」と「アニメーションやサウンド、モーションのような別の形に増幅すること」が挙げられます。これらはコンピューターインタフェースと一線を画す特徴です。ウェブやアプリのエンジニアリングでは、基本的にマウスの移動やクリック、画面のタップなどのインプットしかありません。更に、そのフィードバックは画面上で描画されることに終止しており、凝ったフィードバックとしてサウンドのフィードバックがあるくらいかなと思います。対照的に、フィジカルコンピューティングでは、簡単に言ってしまうとインプットとフィードバックの選択肢が広がったと言えると思います。選択肢が広がるということは、その分複雑性が増す可能性があります。しかし、より面白くこだわったインタフェースが作れると思います。なので、コンセプトの段階からコンテキストやストーリーボードを明確にすることが、より良いインタフェースに繋がるんだろうと思いました。

そして、Arduino の創業者の言葉を紹介されました。

If a picture is worth a thousand words, a prototype is worth a million words. — Massimo Banzi

訳すと「百聞は一見に如かず、プロトタイプは万見に如かず」といった感じかと思います。ここのプロトタイプは「Tangible」と言い換えても良いと思います。「ただ見るだけより、実際に動くものを触ることが一番のフィードバック」ということだと思います。この日は課題を作っただけですが、この言葉を体感できたと思います。

ウェブやアプリの開発では、プログラミングしてブラウザで結果を見るだけでした。今回の Arudino を使ったプログラミングは、実際に自分の身体のアクションに対してフィードバックが返ってくるほうがずっと楽しいと感じました。

僕がこの日作ったものを動画で載せて起きます。正しい順序で2つのボタンを入力すると緑の LED が点滅して、それ以降一定の規則で LED が点滅します。ボタンの入力順序を間違えると赤の LED が点滅して、再度ボタンの入力を求めます。ただこれだけしか作っていないけど、とても楽しかったです!

Day 57: Digital and Analog

Photo by Markus Spiske on Unsplash

この日は機械工学出身の僕にとっては大学を思い出すような授業内容でした。久しぶりにアナログデジタル変換回路(ADC)の説明をされ、ADC に関する課題をやっていました。ADC を思い出すためにいろいろ調べたので、この章では自分の復習も兼ねて DAC について説明しようと思います。興味ない人は飛ばして大丈夫です。

Analog to digital converter

Analog to digital converter とは前述したアナログデジタル変換回路(ADC)のことです。基本的に Arduino などのマイコン上では、電気回路からの入力は0か1のデジタルな値で認識されます。しかし、温度センサーや光度センサーなどのセンサーからの入力値は0と1では表せない中間の値(アナログ値)も考慮に入れたくなります。この時に使うのが ADC です。Arduino 上では A0 から A5 のピンが ADC に対応しています。そして、アナログ値を読み込むために analogRead() 関数をを使います。この関数はアナログ値を10 bit である0~1023の数値に変化してくれます。温度センサーを使った、温度の計算方法を例に示します。

int sensorVal = analogRead(A0); // (A)
float voltage = (sensorVal/1024.0)*5; // (B)
float temperature = (voltage - .5)*100; // (C)

(A) でアナログ値である sensorVal を取得します。sensorVal は温度に比例した電圧を返します。(B) で sensorVol : 1024 = voltage : 5 の比を計算してます。1023が正しいと思いますが、誤差とし1024で計算するそうです。(C) はセンサーに依存する計算式です。センサーの名前でググって出てくる計算式通りに計算を行います。

Pulse Width Modulation

一方で、アナログ値を出力したい時があります。しかし、Arduino などのマイコンはデジダル値しか出力できません。しかし、Pulse Width Modulation(PMW)を使うと擬似的にアナログ値を作り出すことができます。Arduino では 3, 5, 6, 9, 10, 11 の 6 個のピンが PMW に対応しています。そして、 analogWrite() 関数を使ってアナログ値を出力します。簡単に説明すると、8 bit である 0~255 の数値を引数にとって、その引数に比例して出力のパルス波の間隔を変更します。かなり端折って説明すしたので、詳しく知りたい方は下記の記事を見ると図解してあって分かりやすいです。

例として、先程の例で取得した温度に応じて LED の明るさを調節するコードを示します。

int ledBrightness = map(temperature, 28, 31, 0, 255); // (A)
ledBrightness = constrain(ledBrightness, 0, 255); // (B)
analogWrite(3, ledBrightness); // (C)

(A) で現在の気温から 0~255 の範囲内で対応する値を map 関数を使って取得しています。 map 関数は比の計算をしてくる関数です。28 と 31 は室温の最小値と最大値を適当に決めてます。(B) で、万が一に (A) の結果が 2~255 の範囲外になった時のために下限値と上限値を決めてます。0~255 の範囲外の値を渡すとバグるらしいですが、どうなるかは知りません。最後に (C ) で HEIGHLOW (デジタル値)以外の値を引数として渡しています。

Day 58: Sensors

Photo by Robin Glauser on Unsplash

この日は、前日のアナログ値を取得するためのセンサーを紹介されました。また、Arduino には大きなコミュニティーが存在しており、そこで開発されたライブラリーをインストールする方法を説明されました。ライブラリーを使えるようになったので、出来ることが格段に増えた感じました。この章では、センサーと応用例について簡単に共有しようと思います。

Photosensor + Piezo

光度センサー(Photosensor)とスピーカー(Piezo)を使って、明るさに応じて音を変える回路とコードを作りました。光度センサーからの値をアナログ値として受け取って、それを出力する周波数に変換してます。コードと実際の動画を載せておきます。

Potentiometer + Servo

可変抵抗(Potentiometer)とサーボモータ(Servo)を使って、回転角度に応じてサーボモータの回転を制御する回路とコードを作りました。可変抵抗から回転角度の値をアナログ値として受け取って、それを出力する回転角度に変換してます。サーボモータの制御は SERVO というライブラリーを使っています。コードを載せておきます。(動画を撮り忘れました。。。)

Good to know

センサーの他に、知っておくと便利な2つのツールも共有してもらいました。1つ目が Debouncing に関する外部ライブラリです。Debouncing とは、ボタンやスイッチを押した後に、バネや長押しなど要因で Arduino が電圧のオンとオフの認識を正しくできないことです。噛み砕くと人間の感覚では1回のオンとオフつもりが、Arduino 上では複数回オンとオフが繰り返されて認識されてしまうことです。そういう時に 下記の FTDebouncer のライブラリーを使うと良いと言われました。

2つ目は、pinMode() として、INPUT_PULLUP を使うことです。INPUT_PULLUP を使うと、回路に抵抗を配置しなくても Arduino 内の抵抗を使って回路を補完してくれます。スイッチを作るためだけに抵抗とスイッチを回路に配置する面倒を省いてくれます。ただ、通常の INPUT を使う時と比べて、デジタル値の LOW と HIGH が逆転するので注意が必要です。参考の記事を見つけたので下記に示します。

Day 59: Brainstorming

Photo by Per Lööv on Unsplash

この日は、今回の授業の課題が渡されてコンセプトを決める日でした。今回の課題は、「身の回りの何気ない製品に、新しい要素を加えることで人間の影響範囲を超えたインタラクションを作る」です。抽象度の高い課題だったので、これを噛み砕く上で効果的だと感じたブレインストーミングの方法を共有しようと思います。

Try different angle

今回は Day 28 でやった方法と同じ方法でブレインストーミングしました。その方法は、5分のブレインストーミングを6回やる合計30分の方法でした。しかも、各ブレインストーミングでお題が変わります。今回は、フィジカルコンピューティングで使うセンサーを5分ごとに変えてブレインストーミングしていきました。その5分内ではできるだけアイディアをスケッチに描き起こしていきました。

Day 28 でも感じましたが、「長くダラダラやらない」というのと「各ブレインストーミングで思考の角度を変える」というのがとても効果的だなと感じました。外的要因を使って強制的に思考の角度を変えられるので、色々なアイディアを出しやすいと感じました。今回でいうと外的要因はランダムで出されるセンサーです。

ブレインストーミングに興味ある人は下記の記事に詳細が載ってます。

Beyond-human scale

今回の課題の中に「人間の影響範囲を超えた」という文言が入っています。これは、僕にとってかなり面白く思考の幅を広げてくれたと思います。僕たちのチームは「時間を擬似的に止められたらどうだろうか?」と「時間が各個人で違う相対的なものだったらどうだろうか?」という問いを設定して、人間の限界突破をするようなコンセプトを考えました。

この文言がなかったら、Arduino とセンサーの出来ることの逆算で考えてしまうと思います。特に僕は技術から逆算でものづくりをしてしまう癖があります。この癖からできるコンセプトはどうしても小さくこじんまりとしたものになるなと感じていました。しかし、このコンフォートゾーンから程よく追い出してくれたのが、この文言だったと思います。

程よく抽象度が高くて、程よく技術に繋がっているような、丁度よいコンセプトができていると思います。この「人間の限界突破」の思考のストレッチはこれからも使って行きたいと思いました。

Day 60: Brush up concept

Photo by Volodymyr Hryshchenko on Unsplash

この日は前日に引き続きコンセプトの作成とコアインタラクションの決定をする日でした。結論から言うとこの日にコンセプトが決まらなかったので週末の宿題になってしまいました。今までソフトウェアやビデオでしたインタラクションを表現してこなかったので、今週のハードウェアのインタラクションの作成にかなり苦労しました。しかし、その中でも効果的だった思考法を共有しようと思います。(過去の授業の振り返りです)

Low-Fi prototype

Day 36 にやったプロトタイプの授業の Low-Fi のプロトタイプを作成することにしました。まずは、紙やダンボールを使って個人で自分の考えるコンセプトをプロトタイプで表現しました。それを使って「なぜこれを作るのか?」という議論を行い、コンセプトの明確化に励みました。実際に tangible なもので議論するとそれぞれの考えが可視化できるので、チーム内の合意形成がかなりラクにできました。下記が僕たちが作った Low-Fi のプロトタイプです。

興味ある人は下記の記事に詳細が載ってます。

IXD framework

更に、コアインタラクションを明確にするために、Day 7 の IXD framework を使いました。僕たちのチームでは、ハードウェアのインタラクションを考えていると機能がモリモリになったり、あまりにも抽象的な機能が出て来たりしました。それで、チームでもう少しシンプルで小さいスコープでインタラクションを考えるために、このフレームワークを使いました。一番有効だったのは、Metaphor を決めることによってインタラクションの機能を明確化かつ絞れたことだと思います。このことによって、一つのインタラクションと機能に集中できたと思います。

正直、最初このフレームワークを見た時はあまり理解できていませんでした。しかし、Metaphor, Model, Task, Control, Display は非常にインタラクションを最小かつシンプルにするのに良い分解方法だと思いました。下記に僕たちのチームが作ったフレームワークを載せておきます。

興味ある人は下記の記事に詳細が載ってます。

Day 61: Key interactions

この日は自分たちの作るプロダクトのキーインタラクションを決める日でした。この週を通して感じましたがハードウェアを作る工数はソフトウェアを作る工数の倍ぐらい掛かるなと感じました。ソフトウェアを作る時にも注意していましたが、ハードウェアを作る時は更に重要な機能に絞って作ることが求められるなと感じました。そのために僕たちのチームがやったことを共有しようと思います。

Bodystorming + gif

僕たちのチームのコンセプトは、先週の議論を通して「物体に感覚を与えることで、日々の平凡な家事を物体とのコミュニケーションに変える」に決まっていました。そして、それをボディーストーミングしてみることにしました。ボディーストーミングとは Day 38 にやった、ロールプレイと同じです。

ボディーストーミングをする前までは、作りたいインタラクションが盛りだくさんだったと思います。しかし、一連の流れを Low-Fi のプロトタイプを使って自分たちで体験することで、作り込む必要があるコンテキストやインタラクションを絞り込めたと思います。そして、この段階で自分たちのキーインタラクションを定めて、ボディーストーミングと Low-Fi プロトタイプを使って短い gif に落とし込みました。このことでチーム内の作るべき共通認識を確定できました。3つの gif を作ったのですが、その中で一番重要な gif を下記に載せておきます。

僕たちのチームは「物体に感覚を与える」ということで、ディズニーの「ファンタジア」のように「箒とコミュニケーション取れたら面白いよね」ということで、箒に物体を絞って実装を進めていきました。この動画では、箒の動きをジャイロセンサーを使って感知し、それを LED の点滅でフィードバックしています。

Day 62: Key features

Photo by Isaac Smith on Unsplash

この日は実際に僕たちのチームが作る機能を実装していく日でした。制作作業は「Arduino の実装」と「回路の作成」と「実際の形の作成」の3つの分担作業でした。僕は「Arduino の実装」と「回路の作成」を担当して、他の二人がレイザーカッターと3Dプリンターを使った「実際の形の作成」を担当し、残りの一人がドキュメンテーションとストーリーボードの作成を担当しました。4人がバラバラの作業をする前に、プロトタイプに必要な「機能」の決定を行いました。その際に役立った方法を共有しようと思います。

State machine

前日の段階で、キーインタラクションは決まっていましたが、作るべき機能は決まっていませんでした。僕たちのチームは「物体に感覚を与える」プロダクトなので、「どの感覚に対してどういうフィードバックをするのか?」という問いが宙ぶらりんのままになっていました。そこで、僕たちのチームは制作作業の前に State machine(状態遷移図)を作ることにしました。詳しい説明は下記のサイトに譲ります。

データ構造を理解するためにソフトウェアの要件定義としてかなりお馴染みなツールだと思います。しかし、ハードウェアを作る際にもインタラクションとフィードバックを可視化できるので、かなり有用な手段だったと思います。また、一連のインタラクションとフィードバックが可視化されているので、作らなければならない機能も可視化されます。そのことによって、この段階で工数見積が可能になりました。そして、僕がザクッと工数の見積もりを行って、「3日間でどこまで作って、どこを捨てようか」という議論ができました。僕たちのチームが作った State machine の一部を下記に載せておきます。

かなり簡素化して作っていますが、このくらいでチーム内の合意を取るのは十分だったと思います。この段階で、僕の工数見積をもとに下記のように作るものと機能の分解を行いました。pending と書いたものは今回のプロトタイプで実装を見送りました。

## Mailbox- Play audio message (1 day) -> pending- Regiter name(1 day) -> pending- Show text messsage(0.5 day)## Hackey Handle- Implement motion sensor (0.5 day)- Volume changes according to motion (1 day)## Plant Radio- Make sound with piezo(0.5 day) -> pending- Face change according to music (1 day)- Text display (0.5 day) -> pending- Emotion display (0.5 day)- Sound sensor to detect music (1 day) -> pending## Connecting Mailbox with sensors -> pending- Build API server (1 day)- Send message to Mailbox (0.25 day)- Receive message from sensors (0.25 day)

Day 63: Implementation

この日はすべての制作作業を終わらせて、翌日のビデオ作成に備える日でした。なので、この日はみんなモクモクと自分たちの作業を行っていました。なので、僕たちがこの段階で作ったものを共有しようと思います。

prototypes

最初に動きを感知するハンドルを作りました。これは、3Dプリンターを使って形を作り、Arduino を使って加速度を感知しています。その感知された加速度を bluetooth を使って、P5.js に送信し、P5.js で音楽の音量調節を行っています。

次に、音を感知するチューナーを作りました。レイザーカッターを使って、形が作られています。このチューナーは、本当は感知した音に応じて、表示される顔が変わる予定でした。しかし、音センサーの制度が低かったので、チューナーに可変抵抗値に応じて顔が変わるようにごまかしました。可変抵抗値の取得と表示する顔ロジックを Arduino で実装しています。

最後に、色々な物体から集まったメッセージを表示・再生するメールボックスを作りました。このメールボックスは、旗、ディスプレイ、モーター部分が一つのボタンで制御されるように Arduino で実装されています。本来は、各物体からのメッセージを扱うために API サーバーを作る必要があったのですが、一つのボタンで一連の動作をするようにごまかしてあります。

コードを Github にまとめてあるので興味ある人は見てみてください。

Day 64: Shooting

Photo by Anastase Maragos on Unsplash

この日は、翌日の発表に向けてコンセプトビデオを作成する日でした。チーム内にモーションデザイナーがいたので、彼女の言う通りに撮影と編集を行いました。本番さながらの機材を使っての撮影はとても楽しかったです。また、彼女の編集力のおかげでもありますが、ハリボテのプロトタイプを上手くごまかせたなと思います。この章では、ビデオの編集を通して学んだことを共有しようと思います。

最初の一歩はとにかく小さく

前述した通りキーインタラクションとそれに付随する機能しか実装されていません。なので、もし最終の動画を見て「欲しい!」と思ってくれた人がいても実際に動きません。ただ、プロトタイプで動画を取るということに対してはそれだけで十分だったと思います。

ビデオ撮るにあたって、音は後から編集で足されているし、主なインタラクションのトリガーは僕がボタンを使って行っています。その動画を下記に載せておきます。

なんだか結局ビデオの編集力次第だなと感じる部分もありますが、3日間で作るにはこれが限界だったと思います。最終日に実際のプロトタイプを使ってデモを行ったのですが、実際に試せる機能は少なく、言葉で説明することが多かったです。

このことから、ハードウェアの開発はとにかく主要機能に絞って小さく検証する必要性を学びました。そうしないと、結局ビデオの編集力に頼ってしまうことになってしまいます。ビデオでも良いと思う人もいると思いますが、やっぱり僕は実際に動くものを作りたいと思っています。なので、できるだけフェイクの部分を減らしたいと思っています。そのためには、とにかく小さく細かくものづくりする必要があるなと感じました。そうすればユーザーからのフィードバックも素早く手に入るし、フェイクの部分を少なくなるし一石二鳥なのだろうと思います。来週からのものづくりは、なるべくコンセプトの段階から小さくシンプルになるように意識して、デモで体感できるプロトタイプを作りたいと思います。

Day 65: Presentation

この日はプロジェクトの発表の日でした。僕たちは「Sense Maker」というプロダクトを作りました。その動画と発表資料を下記に載せておきます。

今週の授業はとにかく楽しかったです。実際にフィジカルなものづくりをできたのが嬉しすぎて、実装している時は2日間ご飯を食べるのを忘れて回路とコードを書いてました。それと同時に、ハードウェアのものづくりの難しさも体感できました。ハードウェアでは大きさや電圧や使用環境などの物理的な制約が多かったです。

また、今までとは違いコンセプトだけで終わらないリアルなものづくりをできたのが楽しかったです。プロジェクトの前半は抽象的なコンセプトでものづくりをしていたので、フィジカルな物体に落とし込むのに苦労しました。そのために、ボディーストーミングや Low-Fi プロトタイプ、State machine を使えたのは面白く、今までの経験と授業の集大成を感じました。また、作る範囲を小さくしてよりアジャイルに開発するのが、フェイク少なくする意味で良いのだろうと思いました。

15週目の記事もあるので良かったら読んでみてください。

--

--

Ats
Ats

Written by Ats

I like building something tangible like touch, gesture, and voice. Ruby on Rails / React Native / Yocto / Raspberry Pi / Interaction Design / CIID IDP alumni

No responses yet