はじめまして。
こちらのページやいしかわさんのHPに触発されまして(^^;、
パソコンからIr-Tower(USB)経由でRCXを制御するようなプログラムを
作り始めました。
いしかわさんのHPのサンプルソースのおかげでモーターのON/OFFは
簡単に出来たのですが、これを応用してボタンひとつで前進/後退
させようとするとうまく動きません。
モーターの回転方向、モーターのON/OFFを連続して発行すると
最初のコマンドしか受け付けてくれないようです。
何かコツがあるのでしょうか?

ぱむ吉さん、こんにちは。いしかわです。
某掲示板で(^^;ご活躍を拝見しております。

私のページを見て頂き、本当にありがとうございますです。
PC から自由に RCX が制御出来ると、単体で動かすのとは
また違った面白さがありますよね！

mac さん、Jin さん、含みを残しつつ適切なフォローを
して頂きありがとうございました。_<(_ _)>_

いいかげんな Web ページで分かり難い所が多くて反省しています。
mac さんも書かれておりますが、とりあえず以下のページを見て頂ければ
いいかな〜と思っておりますです。

toggle 関係
http://www.asahi-net.or.jp/~qx5k-iskw/lego/rcxplay.html
0xD2 関係
http://www.asahi-net.or.jp/~qx5k-iskw/lego/rcxrmt.html

上記ページを作っていた時の新鮮な感動は今いずこに....自戒(^^;

> ぱむ吉さん、こんにちは。いしかわです。
> 某掲示板で(^^;ご活躍を拝見しております。

こんにちは。最近はすっかりROM状態なのですが、ちゃんと書き込みは
メールで転送する設定にしていますので、会社で読んでます。(^^;
またそのうちでしゃばっていきます。

> 私のページを見て頂き、本当にありがとうございますです。

いえいえ、こちらこそドップリお世話になってます。
お話が非常にわかりやすいし、サンプルもあるし、申し分ないです。
ぜひ引き続きいろんな情報を提供してくださいませ。
これからも楽しみにしています。

とりあえず教えていただいたページを読んで、0xD2のナゾ(笑)について
探ってみます。

">

> PC から自由に RCX が制御出来ると、単体で動かすのとは
> また違った面白さがありますよね！

ですよね。
一般用マニュアルに載っていないと言うのが、またそそるところで、
その味を損なわないようにするのがJinさんのフォローの趣旨と思い、
お付き合いしてしまいました(^^)

> いいかげんな Web ページで分かり難い所が多くて反省しています。

げ、そういう趣旨じゃなかったんですか（ぼかっ）

もう、問題の答えは出たと思いますので、その他の部分を補足します。

通信の正確さと速度は相反問題なのでそのトレードオフかつき物です。
エラーフリーのバーチャルサーキットTCPがあるのに、
速度が優先されれば、UDPが使われるのもその例ですね。
10Mbps以上のEthernetでもそんな具合ですから、
2400bpsのRCXでは、より深刻な問題です。

単純に「肯定応答」、「否定応答」を返したのでは、
応答シグナルのロストや、
「肯定」が「否定」にエラーするパターンに対応できず、
かといって、パケットにシーケンス番号を振って、
CRCでチェックして...と言うのでは、
大半が1〜2 byteの通信内容なのに、
オーバーヘッドやCPUの処理が大げさすぎます。

その割に赤外線で結ばれた通信路は、
エラー確率がかなり高いのですね。
そのあたりのトレードオフをつけた結果が、
RCX Protocolになったものと思います。
よく出来てますよね。

RCXから応答がない場合は、RCXが受信できなかったか、
受信して応答したものの、応答が届かなかったかのどちらか不明なので、
再送するときは、toggle bitを変化させず、
もしRCXがすでに受信していれば、
「再送」と判定して廃棄できるようにしたわけですね。

RCXの受信処理のほうが、送信するPCより楽に出来るところも、
妥当な解法だと思います(が...送信プログラム書くときは...)

JinSatoです

> その割に赤外線で結ばれた通信路は、
> エラー確率がかなり高いのですね。
> そのあたりのトレードオフをつけた結果が、
> RCX Protocolになったものと思います。
> よく出来てますよね。

RCX の Byte Codeの Protocoｌ は Byte単位で Bit 反転したものを送ると言うのがいい
アイディアだと思います。

なぜならば、 Byte 単位で Bit を反転しているので、光的に言えば平均された明るさになる
わけで、もしも、外部から強い赤外線などが入ってきて、光が明るい方に傾いたりし場合でも
エラーチエックが出来るところだと思うんです。

> RCXの受信処理のほうが、送信するPCより楽に出来るところも、
> 妥当な解法だと思います(が...送信プログラム書くときは...)

受信するほうは割と単純ですね。
http://207.236.16.161/JinSato/MindStorms/Dkousaku/PIC-EMU/index3.html
で公開した、PIC-EMUの受信側のコードなんかだと

int GetByte( byte *pData )
{
byte c;

c = xGetCh();
if ( xGetCh() != ~c ) return 1;
*pData = c;
return 0;
}

だけで、単純な Byte単位での確認できますからね〜。
それに、全体としては、チエックサムがあるし。 （PIC-EMUでは無視してるけど）


RCXと何かコミュニケートするプログラムは、

初めに、 0x10 で ping して、RCXがわのトグルビットを初期化して。
あとは、PC側で、メッセージを送るルーチンの中で、3ビット目の On/Off を
繰り返してやればOKですね。

ただ、もしも、RCXから何かを受信する場合だと、もう少しコツが必要ですね。

">

> RCX の Byte Codeの Protocoｌ は Byte単位で Bit 反転したものを送ると言うのがいい
> アイディアだと思います。

出来ることなら、RZ, PE, PPMなど、
1 bit中に必ず1/0両方が入る信号系が理想なんですが、
当時、PIC/AVRなど、ローコストのデバイスがまだ一般的でなく、
H8のSCIをそのまま利用する上でも、
UARTの信号をそのまま利用するのが、
前提になっていたんでしょうね。

おかげで、IRMの波形ひずみに弱いと言う宿命が出来てしまったのですが...

Jin です。

>
> 出来ることなら、RZ, PE, PPMなど、

RZ,PE,PPM って ....

PPM = pulse position modulation （パルス位相変調） か
pulse position modulation （パルス位置変調）ですよね。

PE ＝ phase encoding 位相変調方式，位相コード化方式，ＰＥ方式
RZ ＝ return-to-zero method ゼロ復帰記録方式

これらの手法って、モデムで使われている方法でしたっけ（って、もっと調べろって＞自分）


> 1 bit中に必ず1/0両方が入る信号系が理想なんですが、
> 当時、PIC/AVRなど、ローコストのデバイスがまだ一般的でなく、
> H8のSCIをそのまま利用する上でも、
> UARTの信号をそのまま利用するのが、
> 前提になっていたんでしょうね。

これ、マイコンを作るときに、その様な変調回路をオンチップに出来たら面白い
マイコンが作れそうですね。 まあ、でも、アナログ回路になると思うので、オンチップじゃ
むりかな〜。 いや、今ならDSPを使うのかな〜。

> おかげで、IRMの波形ひずみに弱いと言う宿命が出来てしまったのですが...
それは、感じますね〜。赤外線モジュールの出力BIT の On/Offの比率が均等
な幅でないと、こけますからね。

">

PPM = pulse position modulation
です。
赤外線リモコンの一般的なエンコードで使われます。
あぶくさんのURLを参照させていただきましょう。
http://www02.so-net.ne.jp/~abuku/rcx2tv/index.html
これだと波形ひずみの影響を受けにくくなります。

> PE ＝ phase encoding 位相変調方式，位相コード化方式，ＰＥ方式
> RZ ＝ return-to-zero method ゼロ復帰記録方式

磁気テープでよく使われたエンコードです。
http://www.rad.com/networks/1994/digi_enc/main.htm

磁気テープは、磁束の変化がないと記録できない(直流は無理）でかつ、
速度が変化すると符号速度が直に変わるので、
クロック成分を一緒に記録する方式が選択されました。

いずれも、ロジックICでもエンコード／デコードできますが、
UART直接に比べれば、付加回路がいることには変わりありませんね。

こんにちは。
> こちらのページやいしかわさんのHPに触発されまして(^^;、
すみません。私にもそのホームページのアドレスを教えてください。

> すみません。私にもそのホームページのアドレスを教えてください。

Link 集の中にちゃんとありますよ〜。

はじめまして、ぱむ吉さん

> 最初のコマンドしか受け付けてくれないようです。
これは、普通なんです。

解決方法は ２つあります。

> 何かコツがあるのでしょうか?

Kekoa さんのサイトと、RCX2SDK のドキュメントをよ〜〜く
読むとわかるとおもいます。

また、石川さんが公開しているコードを読んでもわかると
思います。

右側の マインドストーム情報局内の検索で Kekoa と
検索か、マインドストームWatchの 1998年10月31日 を
見るといいかな〜。

一度 それらのサイトを見て調べてみてください。

# なんだか、ケチって答えを書いてないように思われるのも
# いやなんですが〜、でも、ほら、ぱむ吉さんも、自分で
# 調べられて、答えを見つけたときに得られる充実感を
# 奪うのは悪いかな〜と思って、そうしました。
# ２時間くらい調べてもわかんないときは、もう一度
# 聞いてみてください。
# もしくは、分かったら、またそれは、それで、簡単に
# まとめて、報告してくれるとうれしいな〜＞ぱむ吉さん。

こんにちは!!

> Kekoa さんのサイトと、RCX2SDK のドキュメントをよ〜〜く
> 読むとわかるとおもいます。

Kekoaさんのサイトはざっと見てみたのですが、見落としているんで
しょうね。RCX2SDKの方はダウンロードさえしていなかったので、
これから見てみます。

> # なんだか、ケチって答えを書いてないように思われるのも
> # いやなんですが〜、でも、ほら、ぱむ吉さんも、自分で
> # 調べられて、答えを見つけたときに得られる充実感を
> # 奪うのは悪いかな〜と思って、そうしました。
> # ２時間くらい調べてもわかんないときは、もう一度
> # 聞いてみてください。

いえいえ。めっそうもありません。
これだけのヒントとやさしいお言葉を頂き、十分です。
もう少し試行錯誤をしてみます。(SDKも見なきゃ)
それでもダメだったらもう少しヒントをお願いします。(^^;

初めてモーターが回ったときの感動は忘れません。
(ってほとんどいしかわさんのコードでしたが...)

">

> RCX2SDKの方はダウンロードさえしていなかったので、
> これから見てみます。

頑張ってください。
私は、RCX2SDKのLASMのドキュメントが、
この問題の解決に一番役立つんじゃないかなあと思います。

えーと、toggleを引くとか
# ヒントだしすぎちゃ、かえってなんですよね (^^;

こんにちは!!

> 頑張ってください。
> 私は、RCX2SDKのLASMのドキュメントが、
> この問題の解決に一番役立つんじゃないかなあと思います。

ありがとうございます。ざっとナナメ読みしてみましたが...。
いえ! どこかにきっと!!(笑)

> えーと、toggleを引くとか
> # ヒントだしすぎちゃ、かえってなんですよね (^^;

いやー。あはは。(TvT)
toggle...ビット?? あれれ???
家に帰ってもう一度読み直してみます、ハイ。

">

> toggle...ビット?? あれれ???
> 家に帰ってもう一度読み直してみます、ハイ。

はは、大丈夫そうですね。
Jinさんがおっしゃっている、２つめの方法と言うのは、
0xD2のことですよね？

おはようございます。

> はは、大丈夫そうですね。
> Jinさんがおっしゃっている、２つめの方法と言うのは、
> 0xD2のことですよね？

??? これ、いしかわさんのPocketStationのソースの中で
使っているのを見たんですが、意味不明なので悩んでました。
最初に送ってますよね? どういう意味があるのでしょう?
(これじゃ、ほとんどギブアップだな。 ^^;)

">

> ??? これ、いしかわさんのPocketStationのソースの中で
> 使っているのを見たんですが、意味不明なので悩んでました。

おお！PocketCommandのSourceまでよんだのですか〜。

> 最初に送ってますよね? どういう意味があるのでしょう?
> (これじゃ、ほとんどギブアップだな。 ^^;)

LASM Byte codes.pdfで、0xD2を双眼鏡マーク(^^)すると、
RemoteCommandに当たると思います。
純正リモコンが使っているcodeで、これにはtoggle bitがなく、
逆に、連続して同じコードを送り続けないと、
止まってしまうのです。

ただし、0xD2でも、モーター関連以外は、連続して受け取らないようになっていて、
たとえば、0x80 remote soundを2回ならしたければ、
0x80のあと、0x00を送り、0x80を送るなど、
remote soundのbitに変化を与えないと無効です。

RemoteCommandは、Reply Codeがなく、取り扱いが容易で、
信号が途絶えると止まってくれるので、暴走する危険はないのですが、
モーターのパワー調整がなく、また、実際に信号が届いているのか、
送信側では掌握できません。

Kekoaさんのリストにはないのですが、RCX2SDK公開の前に、
http://207.236.16.161/JinSato/MindStorms/BBS/lms_old_04.html
で、あきたむさんの解析があり、
いしかわさん
http://www.asahi-net.or.jp/~qx5k-iskw/lego/rcxrmt.html
や、あぶくさん
http://www02.so-net.ne.jp/~abuku/irrc/index.html
が、実装したと言う経緯があります。

いしかわさんのRuputer de RCX
http://www.asahi-net.or.jp/~qx5k-iskw/lego/rcxctrl.html
は、それよりずっと前の話なので、
一般の0xD2系の命令ではなくモーター制御コマンドを使っているため、
toggle bitの制御と、受信機能が必要でした。

ききょうやです。
今、ネットコントロールロボのプログラムを作っていて
気になったことがあったので報告します。

> LASM Byte codes.pdfで、0xD2を双眼鏡マーク(^^)すると、
> RemoteCommandに当たると思います。
> 純正リモコンが使っているcodeで、これにはtoggle bitがなく、
> 逆に、連続して同じコードを送り続けないと、
> 止まってしまうのです。
これと同じように0xf7のメッセージ送信コードもトグルビットを
つけてはいけないみたいです。
まぁ連続して何回受信しても一向に構わないのでよいのですが、
ビットを立てると反応してくれないみたいで、実はUSB対応版RcxCCは
モロにバグっています（２回に１回しか反応しない）。
直した版をそのうちアップします。

ところでこれって周知の事実？？？それとも新事実？
ｍａｃさんあたりには常識レベルだったかな？

ちなみに６／１０（日）に広島駅前の河合塾でネットロボのデモを
やります（１１：００から１６：００まで）。
ついでに６／１７（日）昼１２：５０過ぎからききょうやがRCCの
テレビに出ます。
広島近辺の方、暇だったら見てやってください。
ではでは。

">

> これと同じように0xf7のメッセージ送信コードもトグルビットを
> つけてはいけないみたいです。

ちょっとうる覚えなんですが、
Message Ballを作っているとき、
0xD2系のコードのがいいかなといったら、
たしか、いしかわさんが、
toggle bitもReplyも0xF7でも同じだから...
と教えてくださった様な気がします。

というわけで、私レベルでは無理ですが、
いしかわさんレベルだと、常識かもしれません(^o^)

toggle bitはエラー再送の制御を主目的にしているので、
Replyしないコードとか、
常に答えてくれなければ困るPingは、
toggleは、意味をなさないので例外的扱いに、
なっているということなのでしょう。

ScoutとRCXでD2のtoggleに対する反応が違うのは、
仕様というよりバグですかね？
# 仕様とバグは同義語 (^o^)

> LASM Byte codes.pdfで、0xD2を双眼鏡マーク(^^)すると、
> RemoteCommandに当たると思います。
> 純正リモコンが使っているcodeで、これにはtoggle bitがなく、
> 逆に、連続して同じコードを送り続けないと、
> 止まってしまうのです。

ふむふむ。0xD2にひっかかったです。kekoaさんのHPで0xD2を引いてみて
なんじゃこりゃ???になってました。
PocketStationが使える環境にあったので、実際にプログラムを使って
操作してみたんですが、ようやくソースコードと動作が頭の中で
リンクしてきました。「送り続ける」というのがミソですね。
ボタンを離したときに、STOPコマンドを送っているわけではないのに
止まる理由はそれだったんですねー。> PocketStation

たくさんの貴重な情報をありがとうございました。
もう一度整理してコードを書いてみます。

まだ自分の中であやふやなところが多々ありますので、とりあえず
動かしてみて、理屈はそれから勉強します。(^^;
(モーターの制御が目標地点ではないつもりなので)

ありがとうございました。またいろいろ教えてください。

どうも、 mac さん、おはようございます〜 ＆ ALL

> Jinさんがおっしゃっている、２つめの方法と言うのは、
> 0xD2のことですよね？

はい、そうです〜。

あと、よく、考えたら、方法は３つありました。
もうひとつは、 0x10 で トグルを初期化と言うのもありました。

たぶん、今ごろ、ぱむ吉さん、ひざを叩いている頃ですね。

おはようございます。

> もうひとつは、 0x10 で トグルを初期化と言うのもありました。

これは「もしや...」と思い、夕べ実験するはずがそのまま眠って
しまいました。(^^;

> たぶん、今ごろ、ぱむ吉さん、ひざを叩いている頃ですね。

今夜こそは絶対に試してみます。

ありがとうございました。 > ALL

では結果は後ほど...。

おはようございます。

> > もうひとつは、 0x10 で トグルを初期化と言うのもありました。

おかげさまであっさりとうまくいきました。感激です。(T▽T)
いしかわさんのソースを真似して(^^; 最初に"トグルを合わせる"という
ことで0x10の送信関数を作っていたので、それをコールするだけ
でした。
今度は0xD2のパターンを試してみます。

それから、もうひとつのツリーの方の話にヒントが隠されているような
気がするのですが、一度0x10を送信して、トグルを反転させる理由は
何でしょうか? それが書かれているHPや、SDKのここに書かれているなどの
ヒントがありましたらよろしくお願いいたします。
(教えてばっかりですみません)

">

> おかげさまであっさりとうまくいきました。感激です。(T▽T)

おめでとうございます。

> それから、もうひとつのツリーの方の話にヒントが隠されているような
> 気がするのですが、一度0x10を送信して、トグルを反転させる理由は
> 何でしょうか?

勝手に話が先に進んでしまいすみません。

No.547が多分お探しの答えだと思います。

0x10で初期化

while(1) {
コマンドを送る。
while(replyコードが正しくない) {
コマンド再送
}
toggle反転
}
と言うのが、コマンドをロスせずに通信する概略手順なんです。
再送を繰り返しても、RCXが間違って同じコマンドを2回実行しないよう、
用意されたのが、toggle bitと考えると分かりやすいと思います。

おはようございます。

> と言うのが、コマンドをロスせずに通信する概略手順なんです。
> 再送を繰り返しても、RCXが間違って同じコマンドを2回実行しないよう、
> 用意されたのが、toggle bitと考えると分かりやすいと思います。

お礼が遅くなりました。
ようやく理解できてきました。ありがとうございました。

オークションで落札したVisionCommandが届いたので、早速カメラのSDK
とここで教わったモーターの制御を組み合わせて、カメラをコントロール
するプログラムにチャレンジしています。
肝心のブロックの方が全然組みあがってないのですが。(^^;
私の環境はWin2kなので、カメラのSDKがなかったらVisionCommandが
宝の持ち腐れになるところでした。

">

> ようやく理解できてきました。ありがとうございました。

おめでどうございます。
説明した甲斐があります。

> 私の環境はWin2kなので、カメラのSDKがなかったらVisionCommandが
> 宝の持ち腐れになるところでした。

私は、最近System Selectorというソフトをつかって、
Win2000/Win ME/Win 98を切り替えて使ってます。
WinVLLの動作確認済みにWin2kが追加されたのはそのためです。
http://www.line.to/mac/MindStorms/winvll

＃Q&A BBSでだれかが,
紹介してくださったので試しに買ったんだけど、
誰が教えてくださったのか、
無礼な事に忘れてしまった(_o_)

このソフト、とっても便利で御奨めです。
他にも100種類ぐらいOSを同居できるらしいのですが,
Linuxは専用機があるし,それほど大量なOSの操作は,
私の頭の容積を超えるんで今はその二つを切り替えてます。