僕は発展途上技術者

脳波で Scratch をコントロール - Mind2Scratch


MindWave Mobile という脳波センサーがついたワイヤレスヘッドセットを使って脳波データを取り出し、Scratch 1.4(教育用プログラミング環境)に送って、だれでも脳波データを使ったプログラムを作れるようにしてみました。

MindWave Mobile で計測できる脳波データはいくつかあるのですが、このうち比較的コントロールしやすい Attention と Mediation を使っています。Attention は集中したときに値が高くなります。一点をみつめて「上がれ、上がれ」などと念じると高くなります。Mediation はリラックスしたときに値が大きくなります。目をつぶってリラックスすれば上がりやすいです。

Attention があがると黄色いネコが上に上がり、Mediation があがれば青いネコが上がるようにしています。

両方の値とも 0 - 100 の間で MindWave Mobile で計測することができ、Bluetooth 接続した iPhone で動かしている自作アプリ Mind2Scratch(仮) に送ります。NeuroSky の SDK を組み込んだ Mind2Scratch で脳波データを取得します。

取得した脳波データを、Scratch のリモートセンサ接続(詳細はこちら → Scratch(スクラッチ)を外部のプログラムなどとつなぐ「遠隔センサー接続」を解説する)を利用して、Scratch に送ります。

Scratch で動かしているプログラムはこんな感じ↓ これは黄色いネコのプログラムです。

MindWave Mobile のような一般の人でも気軽に手に入れることができる脳波センサーの存在は、福祉用具や医療機器の設計やコンサルティングをおこなわれている 株式会社モノ・ウェルビーイング の榊原さんに教えていただきました。

榊原さんは、手足を自由に動かすことができない障害を持っているような方でも、脳波を使って意思表示することができるのではないかということを考えられており、それならそういうアプリをスクラッチを使って作ってみましょう、ということで実験してみました。

実際に自分の脳波を計測しながら練習を繰り返していると、比較的簡単に集中・リラックスを切り替えることができるようになってくるので、これでいろんなものを自由にコントロールできるかも、と思えてきてワクワクします。

今後は Scratch2Romo ともつなげてみたりして、念力(?!)で Romo を動かすとかもやってみたい。

MindWave Mobile と一緒に、榊原さんからお借りした本を読んで勉強中です。

(MindWave Mobile と Scratch をつなげる Mind2Scratch はまだ絶賛開発中です。体裁を整えたら App Store からダウンロードできるようにします)

 

Show & Tell(ショーアンドテル) at Scratch Day Tokyo 2015 振り返り

今年も Scratch Day Tokyo 2015 が大盛況と言ってんじゃないだろうかという盛り上がりで終わりました。 主催側だとステージ上でのプログラムがなかなか見られないのですが、今年はニコニコ生放送で全編放送されていたおかげで、 それのタイムシフト視聴で存分に楽しめることができました。いまさっき観終えたところです。

僕は昨年、一昨年に引き続き、こどもたちが自分で作ったスクラッチの作品を自分で紹介する Show & Tell を担当しました。さっそく振り返ってみたいと思います。

KEEP(今年できて、今後も続けていきたいこと)

  • このエントリー同様に、昨年も振り返りを残しています。
    きちんと振り返ることで、KEEPで挙げていた点は継続し、PROBLEMに挙げていた点に対しては確実に対策できていると思うので、 引き続き今年も、もしあれば来年以降も続けていきたいと思っています。
  • 昨年のPROBLEMに挙げていた、オンライン環境が不安定な場合にそなえて作品をあらかじめダウンロードしておくべきだった という反省を活かし、作品の差し替えは前日の 20:00 までという制限を設けた上で、それ以降にすべてダウンロードしておきました。 ダウンロードしたファイルおよびあらかじめ提供してもらった動画ファイルも含めて、発表順に、1番は 1_◯◯ ではなく 01_◯◯ のように 0 始まりの二桁で番号付けしておくことをきちんとおこなっていたので、この点では手間取ることはありませんでした。
  • Show & Tellに参加したこどもたちの交流の機会をまったく用意することができなかったという昨年の反省があったので、 Show & Tellが終わって、参加者にもう一度整列してもらったあと、ステージ横に一度集まって写真撮影をする機会を設けました。 こうすることで参加者同士の顔を覚えたり、Scratch ID を交換するきっかけになったらと思ったのですが、お膳立てはここまで、 あとはこどもたちにおまかせしました。 倉本さん中心にOtOMOメンバーで用意したスクラッチIDが書かれたシール、実はプログラミングバトルとShow&Tellに出たこども達は ブルーのシールで一般参加者のオレンジのシールとは別だったのです。これによって誰が登壇者なのかがわかるような仕掛けになっていて、 これも交流の一助になることができたんじゃないかと思います。
  • マルチプレイの模様など、当日のデモでは見せることが難しい部分はあらかじめ動画を用意してもらい送ってもらっていました。
    これは阿部先生にもらったアドバイスに従ったものだったのですが、Facebook グループにて Show&Tell 選考の模様を逐一報告していたために もらえたアドバイスなんじゃないかと思います。
  • 申し込みフォームはこれまでの フォーマットを利用したりとこれまでの資産を存分に利用しました。採用通知に関しても Gistに共有しているので、来年以降もこれを参考に利用できるようにしています。採用の過程や、特に文面に神経を使う不採用通知はあらかじめ Facebook グループでスタッフ間で共有し、チェックしてもらうことでトラブルになりそうなところを事前につぶせたんじゃないかと思います。

PROBLEM(来年以降、今後解決していきたいこと)

  • オフラインエディタで発表することという条件だったので安定した環境は作ることができたのですが、クラウド変数を使いたかったりなどオンラインでないと 披露できない機能を持った作品に関しては、ブラウザで発表してもらっても良かったなあと思っています。
  • ターボモードでないとストレスなく動かないという作品に関しては、あらかじめ聞いておき、オフラインエディタでもターボモードに切り替えて あげて発表してもらえたら良かった。配慮が足りませんでした。
  • スクラッチの日本語フォーラムをきっちりとフォローしておくべきでした。Show&Tellに関する質問を結構フォーラムで 受けていたのですが、阿部先生にこんな質問来てますよーと教えてもらってから答えるみたいな感じになってしまい、 レスポンスが悪かったように思います。
  • 相変わらず大人顔負けのMCぶりを披露してくれた宮島くんに安心しきってしまったのですが、今回から手伝ってもらう ことになったIくんのフォローが足りず、結果的にちょっとつらい思いをさせてしまいました。事前にきちんと運営側で打ち合わせを すべきで、役割をきちんと決めておくべきだったし、簡単なところから手伝ってもらうみたいに緩やかに慣れてもらう手段を 取るべきだったなと思っています。
  • こちらが用意した環境でない、自身が用意した特別な環境での発表も認めていたのですが、どうしても 発表に手間取り、結果的には割り当てられていた時間をオーバーしました。ちょっとどう解決すべきか まだ具体策が思いつかないのですが、次回までには何らかの策を用意しておきたいです。
  • [追記] ニコニコ生放送は、かなりクオリティが高く、後から視聴できる僕にとってはありがたい限りなのだが、一方で一部登壇している僕でも、コメントを見るのはかなり勇気がいる。こどもにとっては結構酷なコメントも散見されるので、特に登壇しているこどもが後から観る場合には、心ないコメントはゴミみたいなものだから全く気にしなくて良いということをきちんと説明する必要があるし、必要ならば、コメントをオフにして観てもらう、あるいはそのことを親御さんにあらかじめ説明しておくべきだったと思っている。

TRY(次回挑戦したいあらたな試み)

  • PROBLEMというにはあまりに贅沢な悩みなのでTRYに挙げるのですが、年々作品のレベルが上がるし、応募数も 増えてきて、このままだと次回どうなってしまうのだろうという感じです。これまで基本、ほぼ応募してくれた 作品は受け入れてきたのですが、来年以降どうしても選考に漏れてしまうという作品がでてきそうです。 しかしそれは正直やりたくない、応募するというだけでもかなりの勇気が必要で、 そのすべてに発表する機会をあげたいと願っています。また、今年はびっくりするくらいレベルが高い作品が めじろ押しで、そのこと自体は本当に凄いことなのですが、あまりに Show&Tellの作品が凄すぎて、 「ぼくの、わたしの作品ではダメだわ」とはなからあきらめてしまう子供がでてきてしまうのでは とも危惧しています。僕がMITで観たアメリカのShow&Tellでは、天才的な凄い作品もあればそうでない 作品も等しく受け入れられ評価されていたのを覚えていて、そこが素晴らしいと思い日本でもやりたいと 思ったわけで、その原点に立ち返り何か良い方策を用意したいと考えています。
  • [追記] 来年は壇上とは別で、ミニShow & Tellコーナーを設けて、初心者でも参加できる雰囲気を作り、そこでひたすら Show & Tell をやるという企画を検討したい。スクラッチデーに来られない人でもリモートで接続できる環境を用意する。さらにひろげて、show & tell の動画を自分で撮って投稿できるサイトを用意し、マイクラ紹介動画のような感覚でこどもたちが気軽に自分のスクラッチ作品紹介動画を投稿できるような場を用意する。
  • 昨年に引き続きやはりゲーム主体、男の子が応募しやすい形式にしてしまっているなあと思っています。 昨年と同じTRYです。「ゲーム部門、ストーリー部門、音楽部門、ツール部門のように部門をいくつか作る必要があるかもしれません。 女の子の応募をしやすくする工夫も必要そうです。」
  • PROBLEMにあげたことの解決策もTRYも、もしかしたら大人だけで考えているから良い解決策が思いつかないのかも しれません。スクラッチの日本語フォーラムを通して、現役スクラッチャーのこどもたちに助けを借りるのが いいのかもしれません。また、スクラッチデーの運営、その中の Show&Tell の運営にも、もう少し こどもたちが関われるような工夫をしていく必要があるのかもしれません。

MacOS で rbenv install 2.1.2 しようとすると The Ruby openssl extension was not compiled. Missing the OpenSSL lib? エラー

MacOS で rbenv install 2.1.2 しようとすると The Ruby openssl extension was not compiled. Missing the OpenSSL lib? エラーがでる場合の対処方法。
% CONFIGURE_OPTS="--with-openssl-dir=`brew --prefix openssl`" RUBY_CONFIGURE_OPTS="--with-openssl-dir=`brew --prefix openssl`" rbenv install 2.1.2
でインストールすることができました。

iPhone が Xcode から見えなくなったときの対処法

iPhone 6 にしてから、ことあるごとに iPhone が Xcode から見えなくなるという問題に悩まされていた。 Mac の方を再起動すれば直るというのを経験的に知ってはいたが、いちいち面倒。 Stack Overflow で探してみたらあっさり解決。
% sudo pkill usbmuxd
で usbmuxd(MobileDevice(iPhoneとか)とコンピュータをやりとりしているところ) のプロセスを kill すれば良い。(usbmuxd は自動的に再起動する) » Xcode doesn't see my iOS device but iTunes does

スクラッチからツイートするよ - Scratch(スクラッチ)を外部のプログラムなどとつなぐ「遠隔センサー接続」を解説する(その5)

Scratch Advent Calender 9日目は、3日目に書いた「Scratch(スクラッチ)を外部のプログラムなどとつなぐ「遠隔センサー接続」を解説する(その4)」の続きになります。 いままでのエントリーはこちら↓ » Scratch(スクラッチ)を外部のプログラムなどとつなぐ「遠隔センサー接続」を解説する(その1) » Scratch(スクラッチ)を外部のプログラムなどとつなぐ「遠隔センサー接続」を解説する(その2) » Scratch(スクラッチ)を外部のプログラムなどとつなぐ「遠隔センサー接続」を解説する(その3) » Scratch(スクラッチ)を外部のプログラムなどとつなぐ「遠隔センサー接続」を解説する(その4) その1からその4までに解説した方法を使い、Ruby とスクラッチを連携させて、スクラッチだけではできないことを実現してみたいと思います。

Twitterにつぶやく

スクラッチからTwitterにつぶやいてみましょう。 まずは Ruby だけでTwitterにつぶやくプログラムを書いてみます。 こんな感じです↓ 上記プログラムを実行するには、
gem install twitter
で twitter gem をインストールしておく必要があります。 また、Application Consumer Key (API Key) などの各設定値は、自分のものに書き換えてください。 各設定値は Twitter にアプリケーションを登録して取得する必要があります。 取得する方法は、 » Twitter(Gem) - 逆引きRuby などで調べて下さい。

スクラッチからTwitterにつぶやく

スクラッチから命令を送ったらつぶやくようにするには、その2で解説した方法で、スクラッチから Tweet という命令を Ruby に送るようにし、Ruby 側でこの命令を受け取ったら、つぶやく部分を実行するようにします。 プログラムはこんな感じになります↓ 実際に実行してみましょう。 スクラッチから Tweet という命令を送ったら「こんにちは」とつぶやくことができました。

Scratch(スクラッチ)を外部のプログラムなどとつなぐ「遠隔センサー接続」を解説する(その4)

Scratch Advent Calender 3日目は、スクラッチのちょっと高度な使い方「遠隔センサー接続」についてです。 » Scratch Advent Calendar 2014 「遠隔センサー接続」はスクラッチと外部のプログラムや機器とをつなげることができる仕組みです。仕組み自体はシンプルなので、比較的簡単にスクラッチとほかのものを連携させることができ、たとえばスクラッチからツイートしたりとか、モーターを動かしたりといったこともできます。 遠隔センサー接続について、このブログでこれまでシリーズで書いてきたので、興味がありましたら その1 から読んでみてください。 » Scratch(スクラッチ)を外部のプログラムなどとつなぐ「遠隔センサー接続」を解説する(その1) » Scratch(スクラッチ)を外部のプログラムなどとつなぐ「遠隔センサー接続」を解説する(その2) » Scratch(スクラッチ)を外部のプログラムなどとつなぐ「遠隔センサー接続」を解説する(その3) 今回は Advent Calender の力を借りて、なかなか筆が進まなかった遠隔センサー接続シリーズの続きを書きたいと思います。

センサーの値を外部のプログラムから変更する

シリーズの最初で遠隔センサー接続でできることを4つ挙げたのですが、そのうちの最後の1つ、スクラッチにカスタムなセンサーをつくってその値を外部のプログラムから変える、ということをやってみます。 スクラッチのセンサーの値を変更する Ruby のプログラムは次のように書けます。 その3で紹介した、スクラッチに命令を送る Ruby プログラムを一行変更したものです。
broadcast "a"
というメッセージの代わりに
sensor-update "a" 1
というメッセージをスクラッチに送っています。 その3で、スクラッチの変数の情報を送るために、スクラッチから Ruby のプログラムに送られたメッセージと実は同じなのだが、Ruby のプログラムからスクラッチに送った場合には、センサーの値を変更することに使われます。 実際にこのプログラムを実行してみましょう。 a という名前のセンサーの値を 0 から 1 に変更することができました。 その1からその4までで、遠隔センサー接続でできる4つのことを実際に Ruby のプログラムを使ってやってみました。 次回はこれらを応用して、Scratch と Ruby のプログラムを連携させて何か作ってみましょう。

Scratch(スクラッチ)を外部のプログラムなどとつなぐ「遠隔センサー接続」を解説する(その3)

2ヶ月近くのブランクがあいての続編。 これまでのエントリーはこちら↓ » Scratch(スクラッチ)を外部のプログラムなどとつなぐ「遠隔センサー接続」を解説する(その1) » Scratch(スクラッチ)を外部のプログラムなどとつなぐ「遠隔センサー接続」を解説する(その2)

スクラッチの変数の情報を Ruby のプログラムに送ってみる

前回まででスクラッチの「◯◯を送る」ブロックを使って、スクラッチから Ruby のプログラムに対してメッセージを送ってみた。 次に、スクラッチの変数の情報を Ruby のプログラムに送ってみよう。 前回同様、スクラッチの遠隔センサー接続を有効にし、スクラッチからのメッセージをのぞき見る Ruby のプログラムをスタートさせる。 スクラッチで「a」という変数を「すべてのスプライト用」に作る。 すると、変数を作った瞬間
0000001473656e736f722d75706461746520226122203020
というメッセージが Ruby のプログラムに送られる。 これを前回同様、ASCII文字コードをたよりに解読すると、
00 00 00 14 | 73 65 6e 73 6f 72 2d 75 70 64 61 74 65 20 22 61 22 20 30 20
長さ20バイト     s  e  n  s  o  r  -  u  p  d  a  t  e  SP "  a  "  SP 0  SP
(SP はスペース)
となる。 sensor-update(センサーの値を更新、という意味)という命令に続いて、スペースを一つおいて変数名 a を " (ダブルクオート)で囲み、変数の値 0 に続いてスペースという順に並んでいる。 スクラッチで新しく変数を作ると、最初は自動的に 0 が入ったよ、という情報が Ruby のプログラムに送られたのだ。 試しに変数を変えてみよう。 まず a の値を 1 に変えたあと、次に 2 に変えてみた。 最初に変えたときに送られたメッセージは、
00 00 00 14 | 73 65 6e 73 6f 72 2d 75 70 64 61 74 65 20 22 61 22 20 31 20
長さ20バイト     s  e  n  s  o  r  -  u  p  d  a  t  e  SP "  a  "  SP 1  SP
(SP はスペース)
次に変えたときに送られたメッセージは、
00 00 00 14 | 73 65 6e 73 6f 72 2d 75 70 64 61 74 65 20 22 61 22 20 32 20
長さ20バイト     s  e  n  s  o  r  -  u  p  d  a  t  e  SP "  a  "  SP 2  SP
(SP はスペース)
変数の値の部分が最初は 1 に、次に 2 に変わっているのがわかる。 『「すべてのスプライト用」の変数に値を入れると、その変数の名前と新しくセットされた変数の値の情報を、スクラッチ以外のプログラムに送ることができる』ことがわかった。

Ruby のプログラムからスクラッチに命令を送ってみる

今まではスクラッチから Ruby のプログラムに命令や情報を送る例を見てきた。 今度は逆に、Ruby のプログラムからスクラッチに命令を送っている様子を見てみよう。 スクラッチに命令を送る Ruby のプログラムは次のように書ける。 コメント行を抜かした最初の2行は、前回までのスクラッチからの命令を受けるプログラムと一緒だ。 外部のプログラムからスクラッチに送るメッセージの形式は、いままでのスクラッチから外部のプログラムに送られるメッセージの形式と同じで、最初の4バイトは命令文の長さを表しており、その後に命令文自体が続く。
broadcast "a"
という命令の長さを
length = command.length
で求め、
bytes = [length].pack("N")
でバイト列に変換している。 そして最後に
socket.write(bytes + command)
でこの Ruby プログラムがつながった先、つまりスクラッチに命令を送っている。 スクラッチに送った命令の内容は、
broadcast "a"
Scratch Wiki に書かれている情報から組み立てたものなのだが、これはスクラッチの「a を送る」ブロックと同じ命令だ。 つまり、スクラッチの「a を送る」と同じことを、スクラッチではない Ruby のプログラムから実行できるということだ。 「a」を受け取ったら「こんにちは」とネコが言うスクリプトを作ってみて、Ruby のプログラムからネコに「こんにちは」と言わせてみよう。 『スクラッチとつながったプログラムからスクラッチに対して、「○○を送る」と同じ仕組みの命令を送ることができる。スクラッチではこの命令を「○○を受け取ったとき」ブロックで受け取ることができる』ということがわかった。

Scratch(スクラッチ)を外部のプログラムなどとつなぐ「遠隔センサー接続」を解説する(その2)

のんびり書こうかなとも思っていたが、こちらの記事 →Pyonkeeで遊ぼう! でも紹介されたりと期待もされているようなので続けざまに2回目を書きます。 前回の記事はこちら↓ » Scratch(スクラッチ)を外部のプログラムなどとつなぐ「遠隔センサー接続」を解説する(その1)

ポート番号 42001 を開放

前回の記事で、スクラッチの「遠隔センサー接続」を有効にする方法を書いた。 「遠隔センサー接続」を有効にするとスクラッチは TCP のポート番号 42001 を開放する。 スクラッチのユーザーを意識して、コンピューターのことにまだ詳しくない人にも、できればスクラッチ中上級者になったこどもたちにもわかるようにと思ってこの記事を書いているが、とはいえ全部を説明しだすとキリがないので、TCP について、あるいはポート番号についてもっと詳しく知りたかったら Wikipedia などで調べて欲しい。 ポート番号というのは、語源が port(船の荷物の出入口)であることから連想できるように、プログラム同士をつなげて通信するときの出入口の番号だと思ってもらいたい。ポート番号というのは実はたくさんあるのだけれど、42001 番の出入口だけが開いて、そこからだけ通信できるようになると想像してほしい。

Ruby のプログラムをスクラッチにつなげる

これ以降の説明では Ruby が登場する。Ruby がわかっているのが望ましいが、遠隔センサー接続の仕組み自体は実はそれほど難しいわけではないし、説明にはアニメーションgifを使って実際に動いている様子を見せるようにするので、Ruby がわかっていなくても何となく雰囲気だけでもわかってもらえるかもしれない。 Scratch につなげる Ruby のプログラムは以下の通り、コメントを抜かせばたった2行だ。 localhost とは、プログラムを動かしているマシンのそのもののアドレスだ。スクラッチとこの ruby のプログラムは同じマシン上で動いているので、つなげる接続先は、同じマシン上の TCP 番号 42001 となる。 これを実行してみても、特に何も起こらない。プログラムをスクラッチにつなげただけで何もせず終了しているからだ。

スクラッチからのメッセージを覗き見る

スクラッチにつなげたあと、送られてきたメッセージを読み込んで表示するプログラムを追加した。 loop do と end で囲む部分はスクラッチでいえば「ずっと」のブロックだ。囲まれた部分はプログラムを中断するまでずっとループし続ける。 socket.recv(100) で、ポート番号 42001 から流れてくるメッセージを十分な長さ(100バイト)受け取っている。 そして puts message.unpack("H*")[0] でメッセージをバイトで表示している。unpack("H*")[0] は16進文字列に変換する命令だ。 これを実行して、試しに「◯◯を送る」ブロックで a というメッセージを送ってみる。 「a を送る」をクリックするたび、何やら謎めいた文字列が表示されているのがわかるだろうか。メッセージの内容は良いとして、どうやらスクラッチから Ruby のプログラムに何らかのメッセージが送られているらしいということはわかってもらえたと思う。

メッセージの内容を読み解く

「a を送る」をクリックしたときにスクラッチから送られてきたメッセージは
0000000d62726f61646361737420226122
だ。これは送られてきたメッセージを16進文字列で表示したものだ。 読みやすくするため数字2つずつで区切ってみる。
00 00 00 0d 62 72 6f 61 64 63 61 73 74 20 22 61 22
Scratch Wiki の Remote Sensors Protocol の説明を読めばわかるのだが、スクラッチとの間でやり取りされるメッセージは、最初の4バイトとその残りとに分けられ、最初の4バイトは残りのメッセージが何バイトなのかの長さを示している。 上記の例では
00 00 00 0d
が残りのメッセージのサイズを示している部分だ。これを10進数で表すと 13、つまりその後に続くメッセージの長さは 13 バイトであることを示していて、0d に続く 62 以降のバイト(2つの文字または数字のかたまり)を数えてみれば 13 個であることがわかる。 残りのメッセージの部分
62 72 6f 61 64 63 61 73 74 20 22 61 22
は、ASCII 文字列(本当は UTF-8 なのだが英数字しか登場していないので ASCII 文字列と考えて良い)の16進数表示だ。 ASCII文字コードを頼りに、置き換えてみよう。 62 → b、72 → r、.... 20 → スペース、22 → " と置き換えていくと、
62 72 6f 61 64 63 61 73 74 20 22 61 22
b  r  o  a  d  c  a  s  t     "  a  "
のように暗号が解ける。 スクラッチから送られてきていたメッセージは broadcast "a"(a をブロードキャスト、放送する)だったことがわかる。 「制御」カテゴリの「◯◯を送る」ブロックは実は英語では「broadcast ◯◯」ブロックなのだ。スクラッチの言語を英語に切り替えてみればそれが確認できる。 これで、「◯◯を送る」を実行すると、スクラッチから broadcast "◯◯(送るメッセージの内容)" というメッセージが送られてくる、ということがわかったかと思う。

Scratch(スクラッチ)を外部のプログラムなどとつなぐ「遠隔センサー接続」を解説する(その1)

スクラッチ(1.4)で Romo を動かしたり、Sphero を動かしてみたりしている。 » iPhone がロボットになる Romo を Scratch でコントロールしてみました » Sphero を Scratch(スクラッチ)から動かせるようにしたのでこどもでもプログラミングできるよ 「凄い!これってどうやっているんですか?」とその仕組みを大人からもこどもからも良く聞かれる。「スクラッチの「遠隔センサー接続」を使っていて、詳しくはScratch Wikiに載っています」と答えてはいたのだが、ページは英語で書かれているし解説もかなりシンプル過ぎていて、これでわかってください、というのも酷だったので、これから何回かにわけて「遠隔センサー接続」の仕組みについて日本語でできるだけ丁寧に解説してみたいと思う。

なぜ「遠隔センサー接続」を使うとスクラッチ以外のものが動かせるのか?

そもそもなぜ「遠隔センサー接続」を使うとスクラッチ以外のものが動かせるのか、説明しよう。 たとえばスクラッチから Romo を動かすには、スクラッチから Romo に何らかの命令を送る必要があるのだが、そのためにはスクラッチと Romo が何らかの形でつながっていなくてはならない。 しかし、スクラッチでの操作は、いつもはスクラッチの中で閉じている。何のことを言っているかわからないかもしれないが、たとえば、「制御」カテゴリのなかの「○○を送る」というブロックで考えてみよう。 「○○を送る」ブロックで送った命令は、同じ「制御」カテゴリの「○○を受け取ったとき」ブロックで受け取る。これがスクラッチの中で閉じている、ということだ。スクラッチで送った命令は同じスクラッチの中でしか、普通は受け取れない。 けれどもスクラッチの「遠隔センサー接続」を有効にすれば、「○○を送る」ブロックで送った命令がスクラッチの中だけではなく、スクラッチ以外の別のプログラムでも受け取れるようになるのだ。 たとえば「前進」という命令をスクラッチから受け取ったら Romo を前進させるプログラムをスクラッチとは別に用意しておく。「遠隔センサー接続」を有効にしたスクラッチの「『前進』を送る」ブロックを使えば、「前進」という命令が Romo を動かすプログラムに届き、そのプログラムが Romo を前進させる。 スクラッチから Romo を動かすのに必要な Scratch2Romo や、Sphero を動かす Scratch2Sphero などはすべて、スクラッチからの命令を受け取ってそれぞれ Romo や Sphero など対応するものを動かす橋渡しをするプログラムなのだ。

「遠隔センサー接続」でできること

「遠隔センサー接続」を有効にしたきに、スクラッチとつながったプログラムに対してできることは以下の2つだ。 1. いままで説明したように「○○を送る」で送った命令をスクラッチ以外のプログラムにも送ることができる 2. 「すべてのスプライト用」の変数に値を入れると、その変数の名前と新しくセットされた変数の値の情報を、スクラッチ以外のプログラムに送ることができる スクラッチとつながったプログラムから逆に、スクラッチに対して以下の2つのことができるようにもなる。 1. スクラッチとつながったプログラムからスクラッチに対して、「○○を送る」と同じ仕組みの命令を送ることができる。スクラッチではこの命令を「○○を受け取ったとき」ブロックで受け取ることができる 2. 自分で好きに名前を付けたセンサーをつくり、その値をスクラッチとつながったプログラムから変えることができる。スクラッチでは、「調べる」カテゴリの「○○センサーの値」ブロックで値を受け取ることができる このように「遠隔センサー接続」を有効にすれば、スクラッチ → スクラッチ以外のプログラム という一方向だけでなく、スクラッチ以外のプログラム → スクラッチ という方向に対しても情報を送ることができ、双方向のやり取りができるようになる。

「遠隔センサー接続」を有効にするには

スクラッチの「調べる」カテゴリの一番最後の2つのブロック「○○センサーの値」か「ボタンが押された」のブロックの上で右クリックして現れる「遠隔センサー接続を有効にする」を選ぶ。

次回予告

さて次回は、スクラッチからスクラッチとつながった他のプログラムに対して命令を送っている様子、反対にスクラッチとつながった他のプログラムからスクラッチに対して命令を送っている様子を実際に見てみたいと思う。

デジラボおきなわ第3弾「クリエーターズキャンプ」にメンターとして参加してきました

先週末ですが、沖縄で開催されたデジラボおきなわ第3弾「クリエーターズキャンプ」にメンターとして参加してきました。 デジラボおきなわ クリエーターズキャンプは、第1弾、第2弾でソフトウェア、ハードウェア開発を学んだ小・中・高校生達が2日間の合宿で一からプロダクトを作る、あるいはそれまでの準備期間で作り上げたプロダクトの仕上げをおこない、最終日に発表するというハッカソン形式のイベント。 CoderDojo Okinawaの主催者であり、Ruby on Rails チュートリアルを翻訳した Yasslab こと安川さんと僕は、主に小学生を対象とした「スクラッチでピタゴラ装置を作ろう!」(Making Rube Goldberg Machine with Scratch) というプロジェクトのメンターとして参加しました。 2日間といっても最初の日はイベントの説明や各プロジェクトの紹介などがメインだったので、開発期間は実質1日。最初に定番のねこ逃げでスクラッチのおさらいをした後、それぞれの担当部分のプロジェクトを作り上げていきます。 ピタゴラ装置は全員のプロジェクトがうまく連携しあわないと成功しないので、自然と直接つながる隣同士とは協力しあわないと完成しないところがミソ。とかくプログラミングというと、集中してのめりこんでしまうので、ワークショップ中まったく参加者同士の交流がないといったことになりがちなのですが、このテーマだとコミュニケーションが必須というところが良いところだと思います。 こうして完成した作品を動画におさめ、発表のときに使用しました。 ゴールしたときのこども達の歓声に何度観ても笑みがこぼれます。 成功の裏側には数多くの失敗が。。。成功版もいいですが、こちらの NG 版も僕は好きです。エンジニアリングとは失敗の連続だということも学んでもらえたんじゃないかなあ。

「スクラッチでピタゴラ装置を作ろう!」NG集 from Yohei Yasukawa on Vimeo.

2年前 Scratch@MIT でおこなわれ、僕も参加した教師向けのワークショップを参考に、OtOMO でおこなったスクラッチでピタゴラスイッチマシーンを作ろうを、今回は Raspberry Pi の上で動くスクラッチと電子部品数点で実現してみました。 安価にとても手軽に実現でき、ワークショップのネタとしておすすめで、安川さんがインストラクター向けのドキュメントを用意しているので興味ある方はぜひ参考にしていただきたい。 » ラズベリーパイ版「スクラッチでピタゴラ装置を作ろう!」(インストラクター向け) さてさて最終発表会では、各プロジェクトが発表し、最後には各スポンサーから賞が手渡されたのだが、残念ながら「ピタゴラ装置」チームは賞を逃してしまいました。 まあ確かに、イベント概要に
自分自身のアイデアを活かして、実際に社会や家庭の課題を解決する製品、「プロダクト」の開発にチャレンジ
とあり、
おうちの人、地域の人、世界の誰かの課題や悩み、困っていることを解決したり、誰かをハッピーにするものが望ましい
とあるので、「ピタゴラ装置」には分が悪かったかな? でも、発表会の聴衆を楽しませ、そして何より参加している子供たちがハッピーなのは負けていないと思いました。 しかし、大賞を勝ち取った沖縄県西原市西原東中学校チームの「Scratch GPIO + Raspberry Pi でドラムの自動演奏」は文句なく圧巻でした。 Scratch GPIO を使ってドラムをスティックを動かすことを想像するのはそれほど難しくありません。そのアイデアを思いつくことは簡単かもしれない。しかし、それをここまで完成度高く実現した例は初めて見ました。アイデアよりも実践が大切、MIT も説くDemo or Die の精神を目の当たりにした思いで、演奏中感慨で思わずちょっと泣きそうになってしまいました。 最初から最初まで、ドラムを演奏しているのは人間ではなく Raspberry Pi の上で動くスクラッチのプログラムです。 教えにいったのに、実際には沖縄の子どもたちにいろいろと教えてもらった感じです。 おまけ↓ 沖縄の海はやっぱり綺麗でした。

プロフィール

株式会社まちクエスト代表、つくる社LLC代表。

Raspberry Piではじめる どきどきプログラミングを書きました。

Amazonから図書館検索 Libron、iPhoneアプリ ひらがなゲーム かなぶん を作っています。

Twitter @jishiha

最近のエントリー

アーカイブ