鎌田と申します。
Squeakのリストに対して、Scratchの話題で恐縮です。阿部さんに直接お話できる場所がここぐらいかと思い、参加させていただきました。 Scratch + Arduinoで、横川さん+阿部さんのScratchBoard+WeDo互換拡張を触っていて、blog http://tkamada.blogspot.com/ に、拙いことを書いています。 モーター制御で、サーボモーターを追加しようと思い、ArduinoのServo標準オブジェクトを使えばArduino側はなんとかなる見込みが立ったのですが、Scratch側をどうしようということで、Smalltalkのブラウザを開いてコードを追いかけています。 そこで、コードを見ていると、#(84 254 xx xx)というバイト列をScratchは送信しているように思うのですが、Arduino側では最後の1バイトだけを見ているように見えます。 また、モータ番号として1〜6が設定されるようなのですが、このあたりをうまく受け取ってサーボモーター番号決め打ちみたいなhackができるのかどうか、といったあたりも含めてお伺いしたくメールさせていただいている次第です。 ただ、モータ番号を指定するブロック(Morph)はありませんので、現在の実装がどうなっているのか、変更するならどのあたりか、といったことを若干ご示唆いただければと思っております。 Smalltalkは学部のとき少しDolphin Machineでいじった程度ですが、そのうちなんとかなるだろうと思っています。 ぶしつけな質問で申し訳ありませんが、どうかよろしくお願いいたします。 |
阿部です。
鎌田さん、お久しぶりです。 2011年7月21日17:32 Toshiyuki Kamada <[hidden email]>: > Squeakのリストに対して、Scratchの話題で恐縮です。阿部さんに直接お話できる場所がここぐらいかと思い、参加させていただきました。 ご指名いただくのはさておき、ScratchもSqueakなので構わないと思います。 > モーター制御で、サーボモーターを追加しようと思い、ArduinoのServo標準オブジェクトを使えばArduino側はなんとかなる見込みが立ったのですが、Scratch側をどうしようということで、Smalltalkのブラウザを開いてコードを追いかけています。 > > そこで、コードを見ていると、#(84 254 xx > xx)というバイト列をScratchは送信しているように思うのですが、Arduino側では最後の1バイトだけを見ているように見えます。 > > また、モータ番号として1〜6が設定されるようなのですが、このあたりをうまく受け取ってサーボモーター番号決め打ちみたいなhackができるのかどうか、といったあたりも含めてお伺いしたくメールさせていただいている次第です。 たぶんこれはGoGo Boardのコードですね。 http://www.gogoboard.org/ Scratchが標準でサポートするデバイスには、SensorBoard(aka PicoBoard)、WeDo、そしてGoGo Boardがあります。 この内、SensorBoardとGoGo Boardは排他で、ScratchBoard監視盤(SensorBoardMorph)のShift+右ボタンメニューで切り替えます(SensorBoardMorph>>rightButtonMenu)。 モーター関連のメソッドはGoGo BoardとWeDoのものが混ざっており、センダーなどを確認してどちらに属するものか調べる必要があります。 > ただ、モータ番号を指定するブロック(Morph)はありませんので、現在の実装がどうなっているのか、変更するならどのあたりか、といったことを若干ご示唆いただければと思っております。 SensorBoardWithMotorで私が変更したのはSensorBoardの方です。このプロトコルは、ボードへのデータ送信要求として1サイクルごとにPCから1バイト(16r01)を送っていたので、これをモーター1個分の回転方向用に2ビット、モーターのパワー用に6ビット使って送信するように変えました(SensorBoardMorph>>processIncomingData)。 UIのブロックとそのためのメソッドはWeDo用のものを流用しています(ScriptableScratchMorph>>motorOn:など)。 その他の変更箇所は、SensorBoardWithMotor.1.csをご覧ください。 この設計は、ArduinoにSensorBoardとWeDoの両方の機能を持たせ、ハード、ソフト共に最低限の変更(モータードライバーとWeDo用コネクターの追加など)で低コストに両方の機能を活かしつつ、プロジェクトファイルの互換性を維持することを意図しています(公式サイトで共有可能)。それらを超える能力は狙っていません。 GoGo BoardにしてもWeDoにしても、DCモーターの制御しかできませんので、ブロックもそれ用のものしか用意されていません。もし、サーボモーターを使われるのであれば、自分でスケッチを書き、プロトコルを決め、ブロックも用意する必要があります。 それを実際に行なっているのがS4Aです。 http://seaside.citilab.eu/scratch?_s=yQf-lmh7eaq_Ev0_&_k=_Ac121eeMFBO3xsR Smalltalkの拡張でサーボモーターをお使いになるのであれば、これを参考にすることをお勧めします。 あるいは、リモートセンサープロトコルを使って、サーボモーターを制御するサーバーとScratchがソケットで通信するように書くのも手です。その場合、サーバーの記述言語はSmalltalkで無くても構いません。また、Scratch側の変更が不要となります。 http://wiki.scratch.mit.edu/wiki/Remote_Sensors_Protocol これを行っているのがCatenaryです。 https://sites.google.com/site/chalkmarrowfiles/ //abee -- 阿部 和広 EMAIL [hidden email] |
鎌田です。
阿部さん、早速ありがとうございます。 > たぶんこれはGoGo Boardのコードですね。 > http://www.gogoboard.org/ むむむ、GoGo BoardとSensorBoardが切り分けられているのは気づいていたので注意していたのですが、結局そちらでしたか(SensorBoardにモータはつながらないから、僕が仕様を知らないWeDoの隠れ仕様なのかなと漠然と考えていました)。WeDoがA, B 2個のモータをもつ、というのは後述のご示唆で確認できました。 > Scratchが標準でサポートするデバイスには、SensorBoard(aka PicoBoard)、WeDo、そしてGoGo Boardがあります。 > この内、SensorBoardとGoGo > Boardは排他で、ScratchBoard監視盤(SensorBoardMorph)のShift+右ボタンメニューで切り替えます(SensorBoardMorph>>rightButtonMenu)。 > モーター関連のメソッドはGoGo BoardとWeDoのものが混ざっており、センダーなどを確認してどちらに属するものか調べる必要があります。 ありがとうございます。コードの該当部分を確認しました。 >> ただ、モータ番号を指定するブロック(Morph)はありませんので、現在の実装がどうなっているのか、変更するならどのあたりか、といったことを若干ご示唆いただければと思っております。 > > SensorBoardWithMotorで私が変更したのはSensorBoardの方です。このプロトコルは、ボードへのデータ送信要求として1サイクルごとにPCから1バイト(16r01)を送っていたので、これをモーター1個分の回転方向用に2ビット、モーターのパワー用に6ビット使って送信するように変えました(SensorBoardMorph>>processIncomingData)。 なるほど、ハンドシェイク用の1バイトを流用した形でしたか。納得です。 > UIのブロックとそのためのメソッドはWeDo用のものを流用しています(ScriptableScratchMorph>>motorOn:など)。 > その他の変更箇所は、SensorBoardWithMotor.1.csをご覧ください。 > この設計は、ArduinoにSensorBoardとWeDoの両方の機能を持たせ、ハード、ソフト共に最低限の変更(モータードライバーとWeDo用コネクターの追加など)で低コストに両方の機能を活かしつつ、プロジェクトファイルの互換性を維持することを意図しています(公式サイトで共有可能)。それらを超える能力は狙っていません。 ありがとうございます。ScriptableScratchMorphにセレクタがあるのですね。 一点だけ、知識が足りなくて、.csというのがどこを指しているのかわかりませんでした。 一応、ChangeFileを通して変更箇所は把握できたつもりです。(おかげさまで、Smalltalkの使い方を徐々に思い出してきました) > GoGo BoardにしてもWeDoにしても、DCモーターの制御しかできませんので、ブロックもそれ用のものしか用意されていません。もし、サーボモーターを使われるのであれば、自分でスケッチを書き、プロトコルを決め、ブロックも用意する必要があります。 > > それを実際に行なっているのがS4Aです。 > http://seaside.citilab.eu/scratch?_s=yQf-lmh7eaq_Ev0_&_k=_Ac121eeMFBO3xsR > Smalltalkの拡張でサーボモーターをお使いになるのであれば、これを参考にすることをお勧めします。 なんと、これは派手にやっていますね。たいへん参考になります。 実は僕もScratchのプロジェクト互換は考慮していなくて、MYUロボ的に自律動作できるVMをArduinoに載せて、そのバイトコードをScratchのブロックからコンパイルして送り込むような改変をする、ある意味Scratchコミュニティに対して全く失礼な構想を持っています。ただし、Scratchとの協調動作もできるようにしたいと思っているので、Scratchを単なるプログラミングインタフェースに貶めてしまうようなつもりは全くありません。 むしろ、ModKitの、ScratchのUI模倣、ブロックはすべてWiredの命令、というのが筋悪に感じています。 > あるいは、リモートセンサープロトコルを使って、サーボモーターを制御するサーバーとScratchがソケットで通信するように書くのも手です。その場合、サーバーの記述言語はSmalltalkで無くても構いません。また、Scratch側の変更が不要となります。 > http://wiki.scratch.mit.edu/wiki/Remote_Sensors_Protocol > これを行っているのがCatenaryです。 > https://sites.google.com/site/chalkmarrowfiles/ はい、これは承知しています。遠隔センサープロトコルを知れば、まずやってみることかなと思います。 ただ、制御がScratch側にしかないので、ひもつき(無線でも電波が届く範囲)なのは少し物足りなく思いました。 というのも、サーボモーターで質問したのはひとつの例で、他にはGPSロガーをプログラミングして近所を巡ってきた結果を視覚化するとか、そんな応用まで考えています。Scratch(では、もはやないのかもしれませんが、派生物)とは、いつでも切り離せて、再び接続して協調動作させることもできる(同じプロジェクトのなかで、どちらもできる)といいなと思っています。PCとマイコンが主従関係にあるのではなくて、相互補完の関係になるのが理想です。 |
阿部です。
2011年7月23日5:52 Toshiyuki Kamada <[hidden email]>: > WeDoがA, B 2個のモータをもつ、というのは後述のご示唆で確認できました。 WeDoのハブには2個のソケットがあるのでハード的には最大2個のモーターを動かせるのですが、ScratchのUI上では1個しか使えないようになっています。たぶんこれもsimplicity原則との絡みでしょう。 私はこれを使えるようにしたバージョンを作って以下に置いています。 http://squeakland.jp/abee/tmp/controlingTwoMotorsWithMesh.zip 説明はこのあたり。 http://scratch.mit.edu/forums/viewtopic.php?pid=719696#p719696 >> UIのブロックとそのためのメソッドはWeDo用のものを流用しています(ScriptableScratchMorph>>motorOn:など)。 >> その他の変更箇所は、SensorBoardWithMotor.1.csをご覧ください。 > > 一点だけ、知識が足りなくて、.csというのがどこを指しているのかわかりませんでした。 「ScriptableScratchMorph>>motorOn:など」以外の変更ということですね。 MLを読んでいる他の人へのリファレンスの意味もありました。 > 実は僕もScratchのプロジェクト互換は考慮していなくて、MYUロボ的に自律動作できるVMをArduinoに載せて、そのバイトコードをScratchのブロックからコンパイルして送り込むような改変をする、ある意味Scratchコミュニティに対して全く失礼な構想を持っています。 目的によって手段は変わるべきなので、失礼ということは全くないのではないでしょうか。 私も上記のイメージのようにプロジェクト互換のないものをたくさん作っています。 これについて、Scratchチームの見解は以下にあるとおりです。 http://info.scratch.mit.edu/Source_Code > むしろ、ModKitの、ScratchのUI模倣、ブロックはすべてWiredの命令、というのが筋悪に感じています。 私も少しそれは思います。前回のMTMでは会場のネットが全滅してデモもできなくなってしまいました。 私ももう少しライトな物が作れないか考えています。 > というのも、サーボモーターで質問したのはひとつの例で、他にはGPSロガーをプログラミングして近所を巡ってきた結果を視覚化するとか、そんな応用まで考えています。Scratch(では、もはやないのかもしれませんが、派生物)とは、いつでも切り離せて、再び接続して協調動作させることもできる(同じプロジェクトのなかで、どちらもできる)といいなと思っています。PCとマイコンが主従関係にあるのではなくて、相互補完の関係になるのが理想です。 それはすばらしいです。 雰囲気は、先日亡くなられた武蔵大学の加藤美治先生のSplishに近いですね。 http://www.splish.org/about/?lang=ja 先生はこの名前はSqueakやScratchを意識したものだとおっしゃっていました。 どなたかこのプロジェクトを引き継がれる方がいらっしゃればよいのですが。 //abee -- 阿部 和広 EMAIL [hidden email] |
In reply to this post by Toshiyuki Kamada
横川です。
コードをコンパイルしてArduinoへ送り込むあたりをSqueakでやっている人も居 て、このようなプロジェクトが公開されています。 (ぼくは使ったことがないので、どれくらい「使える」物なのかはわかりません が参考になれば) Arduino http://www.squeaksource.com/Arduino.html ちなみに、これはPhysical EtoysというArduinoをはじめとしてLego Mindstorms Nxt, Nintendo Wiimoteなどの身近なハードウェアをSqueakで利用する大きなプ ロジェクトの一部です。 Physical Etoys http://tecnodacta.com.ar/gira/projects/physical-etoys/ Toshiyuki Kamada wrote 11/07/23 5:52: > 鎌田です。 > > 阿部さん、早速ありがとうございます。 > >> たぶんこれはGoGo Boardのコードですね。 >> http://www.gogoboard.org/ > > むむむ、GoGo BoardとSensorBoardが切り分けられているのは気づいていたので注意していたのですが、結局そちらでしたか(SensorBoardにモータはつながらないから、僕が仕様を知らないWeDoの隠れ仕様なのかなと漠然と考えていました)。WeDoがA, > B 2個のモータをもつ、というのは後述のご示唆で確認できました。 > >> Scratchが標準でサポートするデバイスには、SensorBoard(aka PicoBoard)、WeDo、そしてGoGo Boardがあります。 >> この内、SensorBoardとGoGo >> Boardは排他で、ScratchBoard監視盤(SensorBoardMorph)のShift+右ボタンメニューで切り替えます(SensorBoardMorph>>rightButtonMenu)。 >> モーター関連のメソッドはGoGo BoardとWeDoのものが混ざっており、センダーなどを確認してどちらに属するものか調べる必要があります。 > > ありがとうございます。コードの該当部分を確認しました。 > >>> ただ、モータ番号を指定するブロック(Morph)はありませんので、現在の実装がどうなっているのか、変更するならどのあたりか、といったことを若干ご示唆いただければと思っております。 >> >> SensorBoardWithMotorで私が変更したのはSensorBoardの方です。このプロトコルは、ボードへのデータ送信要求として1サイクルごとにPCから1バイト(16r01)を送っていたので、これをモーター1個分の回転方向用に2ビット、モーターのパワー用に6ビット使って送信するように変えました(SensorBoardMorph>>processIncomingData)。 > > なるほど、ハンドシェイク用の1バイトを流用した形でしたか。納得です。 > >> UIのブロックとそのためのメソッドはWeDo用のものを流用しています(ScriptableScratchMorph>>motorOn:など)。 >> その他の変更箇所は、SensorBoardWithMotor.1.csをご覧ください。 >> この設計は、ArduinoにSensorBoardとWeDoの両方の機能を持たせ、ハード、ソフト共に最低限の変更(モータードライバーとWeDo用コネクターの追加など)で低コストに両方の機能を活かしつつ、プロジェクトファイルの互換性を維持することを意図しています(公式サイトで共有可能)。それらを超える能力は狙っていません。 > > ありがとうございます。ScriptableScratchMorphにセレクタがあるのですね。 > > 一点だけ、知識が足りなくて、.csというのがどこを指しているのかわかりませんでした。 > 一応、ChangeFileを通して変更箇所は把握できたつもりです。(おかげさまで、Smalltalkの使い方を徐々に思い出してきました) > >> GoGo BoardにしてもWeDoにしても、DCモーターの制御しかできませんので、ブロックもそれ用のものしか用意されていません。もし、サーボモーターを使われるのであれば、自分でスケッチを書き、プロトコルを決め、ブロックも用意する必要があります。 >> >> それを実際に行なっているのがS4Aです。 >> http://seaside.citilab.eu/scratch?_s=yQf-lmh7eaq_Ev0_&_k=_Ac121eeMFBO3xsR >> Smalltalkの拡張でサーボモーターをお使いになるのであれば、これを参考にすることをお勧めします。 > > なんと、これは派手にやっていますね。たいへん参考になります。 > > 実は僕もScratchのプロジェクト互換は考慮していなくて、MYUロボ的に自律動作できるVMをArduinoに載せて、そのバイトコードをScratchのブロックからコンパイルして送り込むような改変をする、ある意味Scratchコミュニティに対して全く失礼な構想を持っています。ただし、Scratchとの協調動作もできるようにしたいと思っているので、Scratchを単なるプログラミングインタフェースに貶めてしまうようなつもりは全くありません。 > > むしろ、ModKitの、ScratchのUI模倣、ブロックはすべてWiredの命令、というのが筋悪に感じています。 > >> あるいは、リモートセンサープロトコルを使って、サーボモーターを制御するサーバーとScratchがソケットで通信するように書くのも手です。その場合、サーバーの記述言語はSmalltalkで無くても構いません。また、Scratch側の変更が不要となります。 >> http://wiki.scratch.mit.edu/wiki/Remote_Sensors_Protocol >> これを行っているのがCatenaryです。 >> https://sites.google.com/site/chalkmarrowfiles/ > > はい、これは承知しています。遠隔センサープロトコルを知れば、まずやってみることかなと思います。 > ただ、制御がScratch側にしかないので、ひもつき(無線でも電波が届く範囲)なのは少し物足りなく思いました。 > > というのも、サーボモーターで質問したのはひとつの例で、他にはGPSロガーをプログラミングして近所を巡ってきた結果を視覚化するとか、そんな応用まで考えています。Scratch(では、もはやないのかもしれませんが、派生物)とは、いつでも切り離せて、再び接続して協調動作させることもできる(同じプロジェクトのなかで、どちらもできる)といいなと思っています。PCとマイコンが主従関係にあるのではなくて、相互補完の関係になるのが理想です。 -- Koji Yokokawa <[hidden email]> http://www.yengawa.com/ |
In reply to this post by Kazuhiro ABE-2
鎌田です。
> 雰囲気は、先日亡くなられた武蔵大学の加藤美治先生のSplishに近いですね。 > http://www.splish.org/about/?lang=ja > 先生はこの名前はSqueakやScratchを意識したものだとおっしゃっていました。 > どなたかこのプロジェクトを引き継がれる方がいらっしゃればよいのですが。 ちゃんとArduino側にモニタを持ち、リモートデバッグまで考えられているところにセンスを感じました。 ただ、やはりWiresの関数がベースになっている点や、Scratchの特徴である構造エディタ(をブロックで表現)とは異なるところが、僕の基本的な考えとは違うところです。 しかし、印象深い取り組みのご紹介、ありがとうございます。 |
Free forum by Nabble | Edit this page |