Scratch と OSC の連携


Scratch は、初心者向けのプログラミング言語学習環境です。
OSC (OpenSound Control) は、MIDI の代替となる電子楽器用の通信プロトコルです。

注意
Scratch の最新版は バージョン 2.0 ですが。
この記事は バージョン 1.4 について述べています。
Scratch のサイト からダウンロードできます。

Scratch と外部プログラムの連携
Scratch 1.4 には 遠隔センサー (Remote Sensors) という機能があります。

Scratch と OSC の連携
Scratch の遠隔センサーと、OSC を橋渡しする Scratch OSC Bridge (以降 Bridge と称する) というアプリがあります。
Windows、MAC、Linux で動作します。

遠隔センサーのメッセージには、broadcast と sensor-update の2種類がありますが。
Bridge では、sensor-update を OSC メッセージとしてサポートしています。
broadcast は、Scratch と Bridge との間のコマンドして使用しています。

注意
Bridge は Java SE 6 を必要とします。
MAC の場合は ダウンロード – Java for OS X 2015-001 から

動作確認1 : Scratch から OSC Server へ
Scratch にて画像をクリックすると、
OSC Server にて画像に対応する文字が表示する。
OSC Server は pyOSC を使って Python で記述しました。

設定
(1) Scratch にて to_osc.sb を起動する。
20160827_scratch_to_osc

(2) Bridge を起動する。
「Connected with Scratch」が表示される。
送信先ホスト (HOST IP-ADDRESS) はデフォルトの「127.0.0.1」のままに。
送信先ポート (OUTGOING PORT) はデフォルトの「9000」のままに。
20160827_bridge_to_osc

(3) ターミナルにて、osc_server.py を起動する。

操作
(1) Scratch の画像をクリックする。
変数 /animal に値を代入し、sensor-update メッセージを送信する。
(2) Bridge にて、OSC メッセージに変換し、送信する。
(3) OSC Server にて、OSCメッセージを受信する。
ターミナルに、値に対応する文字を表示する。
画像と数字とメッセージの対応。
ねこ : 1:cat
いぬ : 2:dog
うま : 3:horse

プログラムの工夫
Scratch では、変数の値が変わった時に、sensor-update メッセージが送信されます。
「ねこ」の画像を続けてクリックしても、最初の1回しか送信されないという不具合が生じます。
これを回避するために、変数の値を設定してから、1秒後に画像以外の数字(0)を送っています。

動作確認2 : OSC Client から Scratch へ
OSC Client にて数字を入力すると、Scratch にて猫が移動する。
OSC Client は、pyOSC を使って Python で記述しました。

設定
(1) Scratch にて from_osc.sb を起動する。
20160827_scratch_from_osc

(2) Bridge を起動する。
「Connected with Scratch」が表示される。
「NOW LISTENING TO OSC PORT」に「8000」に表示される
「RECIEVED OSC ADDRESS」と「SEND THESE OSC ADDRESS TO SCRATCH」に「/MOVE」が表示される。
20160827_bridge_to_osc

(3) ターミナルにて、osc_client.py を起動する。

操作
(1) ターミナルにて、コマンド(数字)を入力する。
OSCメッセージ「/move 数字」を送信する。
(2) Bridge にて、sensor-update メッセージに変換し、送信する。
(3) Scratch にて、変数「/move」の値が変更される。
値に応じて、画像が移動する。

コマンドは、数字1文字です。
0 : 中心に移動する
1: 左に移動する
2 : 右に移動する
3 : 上に移動する
4 : 下に移動する

プログラムの工夫
Scratch では、sensor-update メッセージを受け取った時というイベントが無いようです。
sensor-update メッセージを受け取ると、対応する変数に値が設定されます。
変数が同じ値を保持するために、右に移動するというコマンドを送ると、いつまでも右に移動し続けるという不具合が生じます。
これを回避するために、OSC Client では、コマンドの数字を送ってから、1秒後にコマンド以外の数字(−1)を送っています。
Scratch では、変数の更新を1秒間隔にすることで、コマンドが一度実行された後は何もしないという動作を実現しています。
う〜ん。もっといいう手があるかもしれない。

プログラム
作成したプログラムは Github で公開しました。

参考
Scratch OSC Bridge
Scratch OSC Bridge 用の環境のセットアップとテストの手順


Python OSC (python-osc)


OSC (OpenSound Control) は、MIDI の代替となる電子楽器用の通信プロトコルです。

python-osc
前回は pyOSC を試した ので、今回は python-osc を試します。

インストールする

$ pip3 install python-osc

ソースとサンプルは github にあります。

動作確認
サンプルを試します。

(1) サーバー(受信)側を起動する

$ python3 simple_server.py

Serving on ('127.0.0.1', 5005)

(3) 別のターミナルで、クライアント(送信)側を起動する

$ python3 simple_client.py

Sending b'/filter\x00,f\x00\x00;2N\xfd'
... 

(3) 受信側のターミナルで、下記のような表示が出れば、OKです。

/filter 0.002720772521570325
/filter 0.31352025270462036
...

Python OSC (pyOSC)


OSC (OpenSound Control) は、MIDI (Musical Instrument Digital Interface) の代替となる電子楽器用の通信プロトコルです。
ちなみに、メッセージを送信する側を OSC クライアント、受信する側を OSC サーバーと言います。

Python などの多くの言語でサポートされています。
また、Pure Data などの音楽アプリや、Android や iPhone などの電子機器でもサポートされています。
電子楽器に限らず、汎用的な通信プロトコルとしても利用されています。

Python の OSC 対応には、Python 2 用の pyOSC と、Python 3 用の python-osc があります。

pyOSC
まずは、pyOSC を試します。
PyPI からソースをダウンロードする。
インストールする

$ python setup.py install

ドキュメントは pyOSC wiki にあります
サンプルは pyOSC examples にあります

動作確認
サンプルを試します。

(1)受信側を起動する

$ python basic_receive.py
 
Registered Callback-functions are :
default
/info
/arduino/analog
/error
/print
Starting OSCServer. Use ctrl-C to quit.

(2) 別のターミナルで、送信側を起動する

$ python basic_send.py 

(3) 受信側のターミナルで、下記のような表示が出れば、OKです。

OSCServer: OSCMessage '/print' from localhost:64300: [1234]
---
received new osc msg from localhost:60478
with addr : /arduino/analog
typetags i
data [4321]
---
OSCServer: OSCMessage '/print' from localhost:59731: [44, 4.5233001708984375, 'the white cliffs of dover']
...

OSC 2011 .Government


2011年11月20日 OSC 2011 Tokyo/Fall に参加した。
主に .Government 政府・自治体におけるオープンソースの利活用 を聴講した。

第5回自治体IT調査の進捗 災害後の被災地訪問を通して見えたもの
IPA/岡田 良太郎
このセッションは聞いていない

前総務省 担当室長が語る!自治体クラウドとオープンソースの活用
現IIJ・前総務省/高地圭輔

比較的小規模の自治体が全体の6割を占めるが、住民や職員の割合は2割にすぎず、専門のIT部門や担当者がいないのが実情である。
ベンダーと自治体の間には、情報の非対称がある。
そのため、自治体はベンダーのいうがままになり、1つの部門でシステムを入れると、他の部門も同じベンダーのシステムを入れることが多い。
結果として、ベンダーロックインが起こっている。
自治体業務は基本的に同じなので、同じシステムで済むはずという議論がある。
韓国では政府主導でシステムの統合化が行われている。
日本は状況が異なるが、自治体・ベンダー双方が、利用者本位のシステムを構築するべきであろう。
そのためには、ベンダーには、適正な価格で他のシステムの移行の協力するという、誠実な対応が望まれる。
オープン化やクラウドは自治体にも及んでいる。
クラウドの実証実験を5つの自治体で行い、一定の成果を得られた。
徳島県自治体パッケージ (Joruri, Deco, Ai)のようなものも出来ている。
松江図書館 のように OSS のひとつである Ruby をシステム要件にするところもある。
クラウドには、共同利用による経済性や、統一されたシステムのよる業務の標準化などの利点がある。
また、災害時にも有効である。
建物損壊や電力不足などに伴う問題が解消される。
今までは、OSSはコスト削減の観点から導入されることが多い。
今後は、柔軟なシステムによる業務の効率化や住民サービスの充実に向かいたい。

Q) 長崎県などで成功した秘訣は
A) スキルがある職員がいたなど、それが出来る体制があった
Q) どういうところから導入したらいいか
A) 基幹システムよりも、図書館などの住民サービスが向いている

感想: IT業界からみると、当たり前のことが多い。 それが自治体に浸透していないのが現実。 そこをどう打破するかが、真の課題でしょうね。

県庁で大活躍(予定)!OpenCOBOL☆Perlで汎用機ダウンサイジングに挑んだワケ
ランカードコム/峰松浩樹

汎用計算機時代の COBOL のソフト資産は多く、そのまま使いたいという要望がある。
例えば、長崎県庁では、15000本のCOBOLプログラム、6500本のバッチがある。
長崎県庁では、ながさきITモデル として、 基幹的なシステムのダウンサイジングを行うとともに、地元IT企業の育成を行っている。
レガシーな COBOL コードを C言語に変換し、安価なx86マシンで動かす試みを行っている。
3つの変換ツールを開発した。
・COBOL: COBOL プログラムを OpenCOBOL により、C プログラム に変換する
・JCL: JCL (Job Control Language) を Perl スクリプトに変換する
・帳票レイアウト: 帳票レイアウトを Perl で記述した仮想プリンタによりPDF形式で出力する
今後の課題よして。
・COBOL と PHPMySQL との連携を行う。
・COBOL を Perl Scala JAVA などの言語に変換する。

Q) 汎用機の業者は協力的だったか。
A) かなり抵抗があったようだが、職員が頑張ってくれた。
Q) 汎用機からのデータの取り出しはどうやったのか。
A) 汎用機の操作が出来る職員がいたので、お願いした。
取り出しあとは、変換や照合を行うツールにて、作業を進めた。

感想: 今回の発表者の中では、唯一知名度のない地元IT企業の発表。さらりと流していたが、色々苦労があったのだと思う。

OSSでここまで出来る!横浜市消防局でのMoodleを使ったe-ラーニング導入事例 完全紹介
横浜市消防局/藤田豊

e-learning 導入の目的は、大量退職により技術伝承が途絶えることへの不安、災害の多様化により放射線のような見えないものとどうやって戦うのかなど。
OSS の e-learning システムのある Moodle を導入して成果を上げた。
3つのポイント
(1) 単なる LMS (Learning Management System) は廃れる
すでに業務システムや社内グループウエアがある中で、 e-learning の位置づけをどうするのか。
まず使ってもらう環境作りが大切です。
他のシステムの良いところ(情報)をRSSで持ってきて、トップページを情報ポータルにする。
仕事に必要なツールにする。
体力管理は、消防職員全員に義務つけられている。
大手ベンダー製の管理システムはあったが、使いにくかった。
Moodle の小テスト機能を使って、結果をレーダーチャートで出したところ、好評であった。
(2) やらされ感は最大の敵
Moodle が大学でも導入され、宿題の代名詞になっている。
用例: Moodle (宿題) やった?
学習コースは誰でも申請できる。申請者が教師を選任し、教師が生徒を選任する。
自分たちで作ったコースだから愛着がわく。
業務上の委員会もコースにする。 資料もそこに上げる。
(3) 縦割りを超えるために
縦割りの組織形態を踏襲しない。
複数の部署から人が集まる仕掛けを作る。
救助実戦訓練 (e-learning ではない) は、各消防署から実戦要員だけが集まる。
しかし、実戦要員だけで、後方部隊がいないのは、実際と違う。
Moodle のアンケートの機能で、意見やアイディアを募集した。
よいアイディアを人をピックアップして、訓練に参加して貰う。

Q) Moodle でそのままでいけた部分とカスタマイズが必要な部分は。
A) ほとんどそのままです。プログラマではないので、ソースはいじらなかった。
Q) Moodle はどこで覚えたのか
A) Moodle フォーラムやコミニュティで。
Q) Moodle の普及活動を行っているか
A) 月間消防 に連載中です。

感想: 現場からの声。どういうツールを使うのかではなく、どういう風に使うのかが、ポイント。 私が横浜市に住んでいることもあり、興味深かった。

震災後の復興に向けたICTの活用事例と「SAHANA」の取り組みご紹介
日本IBM/樋口正也

日本IBMでは、震災直後から、災害特別お客様支援プログラム を提供し、数週間に50件くらいの申請があった。
その取り組みの一環として、SAHANA に全面的に協力した。
SAHANA は、2004年のスマトラ島沖地震を契機に、スリランカで生まれたプロジェクトで、災害救援活動の管理を支援するためのシステムです。
2010年のハイチ地震では、携帯電話用のSNSで送られてきた情報を収集し、米国にいるハイチ人が情報を精査し、国連などの情報提供を行った。
現在、タイの洪水対策を支援してる。
震災直後から自治体に支援の打診をしていたが、4月に入っているから山形県と岩手県の避難所で運用された。
当初は、自衛隊員が毎日避難所を回って、御用聞きをしていた。
アンドロイド端末を避難所に配布して、必要なときに必要な情報を送ってもらった。
各避難所(要望)-> SAHANA -> 災害対策本部 -> 物流センタ -> 各避難所(物資)
災害時には大量の情報が集まるが、重複しているもの、真偽が分からないもの、古いものなどノイズが多い。
同種の活動をしていた sinsai.info では数100人のボランティアが人手で精査していた。
IBMの テキスト抽出技術 を使って、 Twitter から有効な情報を抽出する試みをしている。

Q) 数ヶ月で立ち上げることが出来た決め手は
A) SAHANA というシステムがあったことあるが、何よりも人としても熱い気持ちがあったこと。
Q) 今回の震災のための開発者数は
A) 多いときで、数100人、常時30人ほど。 当初は、バグも多く、日本語対応の不十分だった。

感想: 人としても熱い気持ちがあった にちょっと感激。 私も sinsai.info に微力ながら参加している。 スキルがあってもなくても、出来ることはあるのだ。

参考
日経BP OSC2011.Governmentレポート