初めまして。

現在、Mindstromのことを色々調べているのですが、MIBOみたいに
複数のRCXを積んであるのがありますよね。

そこで質問なんですが、それぞれのRCXに個別にリアルタイムな
コマンドを送ることは可能なんでしょうか？できるとすれば、
最高何個までのRCXを区別して送れるのでしょうか？

また、RCX同士で送受信は可能でしょうか？

まずは可能かどうかでいいのですが、
ご存知の方、どうぞ教えてください。お願いします。

kojima さん、
もしよかったら、legOS の LNP という項目を調べて見たら少しヒントになる事がかかれていると
思います。
もし何かわかったら、フォロー入れてくれると嬉しいです。


また、オリジナルのファームウエアーについては、mac さんが書いていただいたような制約
があります。 いつもフォローありがとう > mac さん。


さいごに、kojima さん、何か面白いことを考えていらっしゃるようですね、どんなロボット
作ろうとしていらっしゃるんですか〜？、今度教えてください。

JinSatoさん、こんにちは。

出張で留守にしていました。お返事が遅れたことをお詫びします。

当方、まだMindstormを購入したばっかりで何ができるのか模索中の状態です。
ですから、「legOS の LNP」と言われてもなんのことか分からないんです。
教えていただいたのに、まことに申し訳ありません。

現在の私の認識としましては、動くものを作るには、
Mindstormに付属のソフトウェアを利用する方法と、spirit.ocxをVBなどで利用して
動かす方法の２種類あるのだなという程度です。

これ以外にもあるようですが、まだ良く分かっていないだけに全体像が掴めて
いません（＾＾；）。

私が試してみたいと思っている複数RCX制御ってのは、付属のソフトウェアや
spirit.ocxを使ってできるものなんでしょうか？

> さいごに、kojima さん、何か面白いことを考えていらっしゃるようですね、どんなロボット
> 作ろうとしていらっしゃるんですか〜？、今度教えてください。

それがまだぼんやりとなんですが、たとえば、２台のロボットを向き合わせて、
あたかも会話しているように見せられないかとか、それがうまくいけば、
漫才ロボットでもできないかな、といったものです。アイデアだけで、作れるか
どうかは全然自信ないのですけど・・・。

ただいま、JinSatoさんの「鉄人テクニック」を読んで勉強中です。
良い本をありがとうございます（＾＾）。

> 現在の私の認識としましては、動くものを作るには、
> Mindstormに付属のソフトウェアを利用する方法と、spirit.ocxをVBなどで利用して
> 動かす方法の２種類あるのだなという程度です。

Messageを使ってちょっと複雑なことをやらせる場合、
NQCが使いやすいと思います。
とりあえず、チューターを見てください。
http://www.cc.toin.ac.jp/EI/NQCj.html

> 私が試してみたいと思っている複数RCX制御ってのは、付属のソフトウェアや
> spirit.ocxを使ってできるものなんでしょうか？

できます。
が、付属ソフトはちょっと複雑なプログラムになると、
かえって組みにくく、
spirt.ocxはPCと連携動作させるときに適しています。
また、RIS2.0では付属しなくなってしまいました。

> それがまだぼんやりとなんですが、たとえば、２台のロボットを向き合わせて、
> あたかも会話しているように見せられないかとか、それがうまくいけば、
> 漫才ロボットでもできないかな、といったものです。

2台で会話といえば、
http://www.isogawastudio.co.jp/legostudio/modelgallery_model/b004.html
でしょう。
メカは使ってませんが(^^;

JinSato です。
> 「legOS の LNP」と言われてもなんのことか分からないんです。
> 教えていただいたのに、まことに申し訳ありません。

マインドストーム情報局の右側のメニューの下に
情報局内の検索機能がありますので、 legOS をキーワード
にして検索してみると、手がかりが見つかると思います。

また、Net上でも、 http://www.google.com 見たいな
便利な検索サイトがありますので、検索すると色々な
文章が見つかると思います。

あとは、情報を見つけたら、がんばって読んで見ることだと
思いますので〜、がんばってみてくださ。


> それがまだぼんやりとなんですが、たとえば、２台のロボットを向き合わせて、
> あたかも会話しているように見せられないかとか、それがうまくいけば、
> 漫才ロボットでもできないかな、といったものです。アイデアだけで、作れるか
> どうかは全然自信ないのですけど・・・。

上記のことは、ちょっとしたアイディアの積み重ねで
全部可能ですし、すでに同じようなことをされている方もいらっしゃい
ます。

> ただいま、JinSatoさんの「鉄人テクニック」を読んで勉強中です。
> 良い本をありがとうございます（＾＾）。

まいどあり〜〜。 (^^)

> そこで質問なんですが、それぞれのRCXに個別にリアルタイムな
> コマンドを送ることは可能なんでしょうか？できるとすれば、
> 最高何個までのRCXを区別して送れるのでしょうか？

残念ながら、RCXに区別はありません。
標準のリモコン等でコマンドを送ると、
すべてのRCXに到達し、同じ動きをしてしまいます。

それでは、所期の目的が果たせないので、
RCXのプログラムで工夫して別々の動作をするようにします。
具体的には、Messageという1-255のコードを送受する仕組みがあるので、
Program1はMessage 1で、モーターを回し、Message 2でこれを止め、
Program2はMessage 3で、モーターを回し、Message 4でこれを止める...
などのようにして、別々のプログラムを組むわけです。

そして、RCX-Aだけ電源を入れて、Program1を送り、
次にRCX-Bだけ電源を入れて、Program2を送ります。
こうしたあと、双方に電源を入れれば、
Message1は双方に届くもののプログラムが違うので、
RCX-Aだけが反応し、RCX-Bは動きません。
これをさらに高度に発展させたのが、
いしかわきょーすけさんのMessage Routerです。
http://www.asahi-net.or.jp/~qx5k-iskw/lego/mesroute.html

何個区別して？ということだとMessage一つでは255ですが、
連続する2つのメッセージに意味を持たす等の工夫で、
さらに増やすこともできますから、
何個までという事は出来ません。

> また、RCX同士で送受信は可能でしょうか？

RCXはMessageを送受できるので、
これを使い可能です。

macさん、すばやいレスをありがとうございます。

> 具体的には、Messageという1-255のコードを送受する仕組みがあるので、
> Program1はMessage 1で、モーターを回し、Message 2でこれを止め、
> Program2はMessage 3で、モーターを回し、Message 4でこれを止める...
> などのようにして、別々のプログラムを組むわけです。

なるほど、理屈は良く分かりました。

> いしかわきょーすけさんのMessage Routerです。
> http://www.asahi-net.or.jp/~qx5k-iskw/lego/mesroute.html

楽しそうなページですね。まだ理解できないことが多いです。
勉強せねば。

> RCXはMessageを送受できるので、
> これを使い可能です。

とにかくできることが分かって嬉しいです。
どうもありがとうございました。

jinさん、macさん。前回は質問に答えていただいてありがとうござい
ました。大変参考になりました。
　今回も基本的な質問で恐縮な
のですが、nqcでscoutを制御したいと考えているのですが、dosプロ
ンプトに
nqc -SUSB1 -TScout -d test.nqc
と入力すると、r>Not enough free memory in Scout to download program
とい
うメッセージがでてしまいました。
　いろいろ自分でも考えてみ
たのですが、解決策が浮かばないので是非意見をお願いします。

ききょうやです。

> nqcでscoutを制御したいと考えているのですが、dosプロンプトに
> nqc -SUSB1 -TScout -d test.nqc
> と入力すると、
> Not enough free memory in Scout to download program
> ・・・
ですが、ＵＳＢタワーを使ってらっしゃいますね？
今、ＵＳＢタワー対応のＲｃｘＣＣを作ってるんですが
ＵＳＢタワーを使うとコミュニケーションエラーがよく出ます
特に相手がScoutだとよく発生しています。
この辺がこの問題を引き起こしているのかもしれません。
RIS1.xをお持ちなら、そちらのタワーで試されてはいかがでしょう？
私も今からちょっと実験してみます＜先にやっとけって？（爆）

ではでは

ききょうや＠自己レスです。

> 私も今からちょっと実験してみます＜先にやっとけって？（爆）
実験してみました。
やっぱりエラーになりますが、
No reply from Scout
というエラーですね。
このエラーが出る原因としては
RCXやScoutからの返送データの形式がRS-232CとUSBで違うみたいで
RS-232C：送ったデータ＋返送データ
USB：返送データのみ
この違いだけならよいのですが、Scoutの場合、返送データの
最初の数ビットがこぼれてしまって
0x55,0xff,0x00・・・の部分が化けることが多いみたいです。
これがコミュニケーションエラーの元だと思います。

ところで本件のエラーは私の場合では出ませんでしたから
他にも原因があるのかもしれません（つまり原因不明？）。

役にたたなくてごめんなさい。
もう少し調べてみます＜USBタワー関連もあるので

> やっぱりエラーになりますが、
> No reply from Scout
> というエラーですね。

私も追試してみました。

rcxlib/RCX_Link.cppに細工して、
0x55,0xff,0x00の確認から、
0x55を取ってしまって実験したのですが、
No reply from Scout
Problem talking to IR device
が出ますが、ちゃんと通信して、downloadできる場合もあります。

でも、0x55が乱れる様だと、0xffで同期回復する確率は、
あまり高くない様で、うまく行く方が少ないですね。

受信パケットに対する応答が、Scoutの方がRCXよりだいぶ早く、
USB Towerの送受切り替えが間に合わないのですね。

RCXなら、firmをversion upできますが、
このトラブルを根本的に直すためには、
Scoutのfirmか、LEGO USB TOWERのfirmのどちらかを修正する必要があり、
これらは、ROMなので後から修正と言うわけには行きませんね。

根本的じゃなくても、実用になる対策が見つかるとよいのですが。

Jin です

mac さん、さすがディープな実験してますね。

> 受信パケットに対する応答が、Scoutの方がRCXよりだいぶ早く、
> USB Towerの送受切り替えが間に合わないのですね。

あれれ〜、そうなると。 USB IR Tower のファーム 変えないといけないですよね。

> RCXなら、firmをversion upできますが、
> このトラブルを根本的に直すためには、
> Scoutのfirmか、LEGO USB TOWERのfirmのどちらかを修正する必要があり、
> これらは、ROMなので後から修正と言うわけには行きませんね。

ROMに焼かれているとお手上げですね。

> 根本的じゃなくても、実用になる対策が見つかるとよいのですが。

NQCの場合だと、RCXやSCOUTと交信する前にPing して IR Towerをたたき起こして
から、本命のコマンドを送るようにしていたと思いますが。

USB IR Tower の場合は、Pingのコマンド （たしか、0x10 ）を飛ばさなくても、
IR Towerはおきている（と思った）ので、いきなり本命のコマンドを送ると、
Ping がなくなる分、エラーを発生する回数が減るようなきがします。

根本的な解決策じゃないですが。

> IR Towerはおきている（と思った）ので、いきなり本命のコマンドを送ると、
> Ping がなくなる分、エラーを発生する回数が減るようなきがします。

ええ、確かにUSB　TOWERは起きたままですが、
エラーが起きるのは、「応答が必要なとき、その応答が早すぎて取れない」
現象の様なので、たたき起こしPingのように、
応答を期待していない時は、あまり効かないと思います。

たぶん0x55,0xff,0x00ヘッダーで、bit同期自体は、回復すると思うんです。
ff00とながい同一極性が続くパターンがありますから。
だから、0x55を取り損ねた場合にそれに続くcharはパターンが発生し、
そのうち、後続するデーターには、損傷がないと予想されるものを、
「正しいヘッダー」と解釈してしまう様にすればうまく行くような気がします。

ききょうやです。

> たぶん0x55,0xff,0x00ヘッダーで、bit同期自体は、回復すると思うんです。
> ff00とながい同一極性が続くパターンがありますから。
> だから、0x55を取り損ねた場合にそれに続くcharはパターンが発生し、
> そのうち、後続するデーターには、損傷がないと予想されるものを、
> 「正しいヘッダー」と解釈してしまう様にすればうまく行くような気がします。
自作プログラムでScoutとの通信をチェックしたところ
0z55が破壊、または無くなるが、そのあとは正常というパターンが多く見られるので
昨日すでにNQCにパッチを当てて、正常動作する確率が上がることを確認しました

アップしましょうか？

> 自作プログラムでScoutとの通信をチェックしたところ
> 0z55が破壊、または無くなるが、そのあとは正常というパターンが多く見られるので
> 昨日すでにNQCにパッチを当てて、正常動作する確率が上がることを確認しました

ご苦労様です。

私のは、手を抜いて0x55のチェックをしないだけにしたので、
「0x55がなくなる」場合に対応できず、
あまり正常動作確率が上がらなかったのですね。

時間を見つけて、追試してみます。
CyberMasterも、やってみたほうがいいですか？

続きは、「やってみよう」に移動します。

ききょうやです。

NQCのUSBバージョンの新版とRcｘCCの新版の情報を
「やってみよう」の掲示板にアップしたので
試してみてください。

JinSato です。
　そうか、USB-IR Tower のことも考えないといけなかったですね。
　

> > 私も今からちょっと実験してみます＜先にやっとけって？（爆）
> 実験してみました。
> やっぱりエラーになりますが、
> No reply from Scout
> というエラーですね。

　ということは、SCOUT　と　USB IR TOWER の場合は現状ではちょっと問題ありという感じかな。　

> このエラーが出る原因としては
> RCXやScoutからの返送データの形式がRS-232CとUSBで違うみたいで
> RS-232C：送ったデータ＋返送データ
> USB：返送データのみ
> この違いだけならよいのですが、Scoutの場合、返送データの
> 最初の数ビットがこぼれてしまって
> 0x55,0xff,0x00・・・の部分が化けることが多いみたいです。
> これがコミュニケーションエラーの元だと思います。

　　RIS2.0の英語版に向けてLEGOの方もブラシアップしているみたいなので
USBのドライバーなどバージョンアップされる可能性があるみたいです。

> ところで本件のエラーは私の場合では出ませんでしたから
> 他にも原因があるのかもしれません（つまり原因不明？）。

　SCOUTの　"Not enough free memory in Scout to download program" については
そうですね。　

> nqcでscoutを制御したいと考えているのですが、dosプロ
> ンプトに
> nqc -SUSB1 -TScout -d test.nqc
> と入力すると、<b
> r>Not enough free memory in Scout to download program
> とい
> うメッセージがでてしまいました。

Programが長すぎる場合に、発生するエラーですが、
短いプログラムでもこのようになっているのでしょうか？
task main()
{
PlaySound(1);
}
のような極端に短いプログラムで試験してみてはどうでしょうか？

実は私もそう考えて、非常に簡単な命令も送ってみたのですが、やはり

Not enough free memory in Scout to download program
というメッセ
ージがでてしまいます。
macさんの
task main()
{

PlaySound(1);
}
でダウンロードしても結果は同じでした。r>ひょっとしてScoutの内蔵メモリーが故障しているんでしょうか？
Sco
ut自体はなんの問題もなく動いているのですが・・・

役に立たない可能性がとてもたかいのですが〜、ちょっと実験で

Scout　から一度電池を抜いて、そして、On　ボタンを押してから
再度電池を入れて、短いプログラムを転送してみるとどうですか？