【終了】(2021年度)技術科教育法

公開·16名のメンバー

戻る

山下泰知

2021年11月6日

課題５　kcar製品化へ

チームkcarの山下です。今回は、推しのアイテムを光らせたり、音を鳴らしたりするということで、kcarを光らせたり、音を鳴らしたりしました。

推しについて

まず、私たちは、未知の「推し」について考え始めました。

推しとは何か。

好きなものとは違う？

そもそも推しってなに？

推しって何かって考えてる時点で推しなんてないんじゃないか。

そう、私たちには推しなんてないのです。そこで、入学当初から「推し」について語っている澤谷さんに推しについて尋ねました。すると、、、推しの写真が送られてきました。ますますわけがわからなくなるわけです。

結局、推しについてわからないまま、なんとなく私たちがずっと触れているkcarを光らせたり、音を鳴らしたりすることに決めました。

作ったもの

私たちが作ったものは、先ほども述べた通り、光って音の出るkcarです。これは、立体的に作られたkcarを実際の車に近づけるために、ウインカー、ライト、ブレーキ灯を音と光を使って表現したものです。

プログラム

図１：送信機

図２：受信機１

図３：受信機２

今回は、三つのmicrobitを使うため、３つのプログラムを用意しました。そして、今回は配線が複雑になるのがわかっていたので、なるべく、microbitに触れないように無線を使用しました。(無線の使い方は、先輩の記事をいくつか参考にしました)

無線をするには、受信側と送信側もしくは、その両方の機能を備えたものが必要になるようです。ですから、私は、わかりやすく、受信側と送信側を分けて区別しました。ペアリングのようなものは、受信側と送信側ともに、最初にグループを設定し、同じ番号なら勝手に繋がってくれます。また、LEDを複数個使うには、ある特定の拡張基盤の端子を使わなければ誤動作を引き起こしてしまうので、実質5箇所程度しかLEDを使えない状況でした。ですから、その上限を増やすためにmicrobitを使ったという意図もあります。

受信側

受信側からは、いくつかの入力(Aボタンを押すことや、ロゴを触ったりすること)で、送信側に文字列を送信します。ここで、文字列を送信する理由は、送信側で条件文を使用した際に数字を使っているとエラーが出るためです。文字列なら出ません。また、入力がない場合には、送信側で一つも指示のしていないDという文字列を送信し続けています。そうすることで、送信側での条件文を上手く動作させることができます。

送信側

送信側は、受け取った文字列に合わせて、ライトを点滅させながら音を出したり、だんだん明るくしたり、光の点灯に合わせて音がなったりします。

先程の送信側で一つも指示のしていないDという文字列を送信し続けているのは、ここでの条件文での抜けにくいループを抜け出すためです。

まず、送受信の詳しい説明をすると、送信側で送られた文字列は一旦、receivedStringという受信するための専用の変数に代入されます。しかし、このreceivedStringは、条件文で直接使用できないので、他の変数(図２、図３でいうとhamburger)に代入します。そうすることで、やっと条件文で文字列を認識し、判別の手段に使用できます。

それをそのまま利用すれば、簡単に条件文をかけるのかといえば、そうではなく、例えば、文字列Aという条件の動作をしている場合、Aの動作が終了した時点で、すぐに他の信号が入らなければ変数hamburgerに文字列Aが代入されているので、すぐに文字列Aの動作が始まってしまいます。しかし、送信機でボタンを押していない時に送信側で使用しない文字列を送り続けることで、文字列Aの動作後にhamburgerに代入されている文字列を図１で言うところのDにすることができ、受信側では、文字列Dの動作は指示されていないので、条件文の一番下のLEDを光らせないというプログラムが実行されます。（わかりやすく、いらない動作を入れた。）いわゆる、変数hamburgerを初期化し続けるということをしています。ですから、先程の通り、送信機で任意のボタンを押せば、綺麗にプログラムが動作します。

工夫した点

・送信機からの文字列を、各受信機で同じにした場合、同時にプログラムを実行させることができる点（ランプやブレーキ灯）

・送信機からの文字列を、各受信機で異なるものした場合、別々にプログラムを実行させることができる点（ウインカー）

Kcar(アクリル)