ききょうやです。

NQCのUSBタワー対応版の新しいバージョンと
RcxCCのUSBタワー対応版を一緒のアーカイブにしてテスト用に公開します。
上記の家アイコンからDLしてください。

テスト用なのでドキュメントもしっかりしておりません。
また、インストーラなどもありませんので、使用できる人だけ試用してみてください。
よって転載は禁止にします。

NQCの改良？点は以下の通りです。

・USBタワーからの戻りデータのチェックを多少甘くした

RｃｘCCのバージョン３．１からの改良？点は以下の通りです。

１．USB IrTower（RIS2.0付属）に対応

２．Scoutに対応

３．Spirit.ocxを不要にした（RIS1.xを持っていなくても使用できる）

４．自動設定による、COM/USBポート、ターゲットRCXタイプの判別

詳しくは付属のドキュメントをご覧ください。

試用レポートをお待ちしております。

Win2000Pro(VAIO SR9C/K)で試用してみました。もちろんUSBタワーです。

目的はmacさんのlibvll.nqcを使ってDDKにプログラムを送るためです。Win2000でも正常に機能していることをご報告いたします。
ファームウェアの転送は不可でしたが、今のところ不具合は見当たりません。
初めて使いましたがRcxCCは大変使いやすいです。Mac版のNQCと同様、コンパイルしなくてもダウンロードできるのがとっても便利ですね。
今後ともよろしくお願いします。

> Win2000Pro(VAIO SR9C/K)で試用してみました。もちろんUSBタワーです。
>
> 目的はmacさんのlibvll.nqcを使ってDDKにプログラムを送るためです。Win2000でも正常に機能していることをご報告いたします。
> ファームウェアの転送は不可でしたが、今のところ不具合は見当たりません。

libvll.nqcをご愛用いただきありがとうございます(^^)

Win2000でも、USB版NQC/RcxCC共に動くんですね。
firmの転送だけうまく行かないのが、残念と言うか、
ちょっと不思議ですが、微妙なタイミングがからんでいるのでしょうか。

JinSato です。 ちょうどマシンの入れ替えで出遅れてしまいました。 （＾＾）
早速ダウンロードしてみました。 （これから使ってみます）

ききょうやです。

Watchで紹介していただき大変うれしく思います。
みんなにいろいろいじってもらえると幸いです。

私が試験した結果をご報告します。

まず、CyberMasterは、起動時、
Cannot find RCX. Switch it on or move it closer and press OK.
になって認識されませんでした。
COM1にCM Towerを接続してあります。

USB対応パッチ付きnqcをDOS窓で使ったり、
ノーマルのRcxCCでは正しく動作しています。

また、Searchしている時、CM TowerとCM本体のLEDが、
点滅し通信自体は行っている様です。

次にScoutですが、
task main()
{
PlaySount(3);
}
を繰り返しdownloadしましたが、
正常に終了するのは、10回中3回程度でした。
No replyとProblem..が半々に出てます。

どうも、予備試験の結果の差は、
修正法の違いというより、器差の影響が強かった様です。

ちょっと残念な結果ですが、
何か追試すべき点があれば、遠慮なくお申し付け下さい。

壊れた応答パケットがどう見えているかは、
もうちょっと時間をとれる時に調べる予定です。

ききょうやです。

> まず、CyberMasterは、起動時、
> Cannot find RCX. Switch it on or move it closer and press OK.
> になって認識されませんでした。
> COM1にCM Towerを接続してあります。
実はCyberMasterは自動認識できるようになっていないのです。
自動認識せず、COM1とCMをチェックして起動してみてください。

それで使えるようでしたら、ROM/RAMのバージョンを
教えていただけると自動認識ができるようになると思います。

> 次にScoutですが、
> task main()
> {
> PlaySount(3);
> }
> を繰り返しdownloadしましたが、
> 正常に終了するのは、10回中3回程度でした。
> No replyとProblem..が半々に出てます。
そうですか、私の環境では失敗率が３割くらいです。
周りの光とかの影響もあるのかな？個体差かな？
RCXではほとんど失敗することはないんですけどねぇ・・

> どうも、予備試験の結果の差は、
> 修正法の違いというより、器差の影響が強かった様です。
そうですね。これ以上の対策はいまのところ施すことは
不可能でしょう＜USB IrTowerかドライバの改善等が必要

> 壊れた応答パケットがどう見えているかは、
> もうちょっと時間をとれる時に調べる予定です。
お願いします。
COMとUSBでタワーの仕組みが違っているみたいで
USBでは、半２重みたいなことをやっているみたいですね
（送信中は受信しない）

とりあえずは、失敗を恐れず何回もリトライを繰り返すしか
ないのかもしれません。

ところで改版のRcxCCの使い心地はどうでしょうか？
ほとんどのコードに手を加えたので追加、改善点があれば
反映させることができるかも？しれません。

ではでは。

ごぶさたしてます、清水です。
ききょうやさんの改良版NQCを現在ダウンロード中...

> > 正常に終了するのは、10回中3回程度でした。
> > No replyとProblem..が半々に出てます。

> そうですか、私の環境では失敗率が３割くらいです。
> 周りの光とかの影響もあるのかな？個体差かな？
> RCXではほとんど失敗することはないんですけどねぇ・・

たまたま私も先週から Scout を骨までしゃぶろうと、
nqc や ATLClient を使って実験しているのですが、
＃ RCXはツクモロボコンマガジン館に出張中。
やはり成功率はとても低いです。

なんとかうまくいかないかと試行錯誤を繰り返してわかったことは、
・nqcもATLClientも成功率は同程度。
(ということはアプリケーションはたぶん悪くない。)
・コントロールパネルでUSBタワーのパワーを「短距離」にすると、
「長距離」のときと比べて格段に成功率が上がる。
・nqcやATLClientでリモートコマンドを送信すると、
ほとんど成功するが、とりこぼすこともたまにある。
あまり有用な情報でなくてすみません。

> > 壊れた応答パケットがどう見えているかは、
> > もうちょっと時間をとれる時に調べる予定です。
> お願いします。

nqc に -v オプションを付けると送受信パケットが表示されます。
＃ 通信エラーをなんとか直せないかとソースをhackしてたら
＃ 偶然見つけました。...もしかしてもうご存知でした？
受信パケットの中身は、リトライごとにかなりばらばらでした。
デバイスが苦手の私にはそれ以上はわからないのですが、
やはりハードの仕様/特性がずれているのですかね。

それでは。

清水さん、ビンゴです！

何でLEGO Towerの設定という重要パラメーターを忘れていたのか、
思わず赤面しています。

これで確かにかなりScoutのエラー発生は少なくなりました。
fVerboseがあるのは気付いたのですが、
ちょっと冗長過ぎるので、別に試験プログラムを作りました。

Pingを投げて、返事をダンプするだけのものです。
RCXのROM firm / Scoutでやってみました。
100個投げた返事を多い順に並べました。

わざとエラーを起き易い状態にするため、
Tower / DUTを20cm離し、角度を付けて光軸をずらしています。
発生回数　: 応答で示します。

RCXのL
76 : 55 ff 00 ef 10 ef 10
6 : 55 ff ef 10 ef 10
5 : 55 ff 00 ef 10 ef
4 : 55 ff 00 ef ef 10
2 : 55 ff 00 10 ef 10


RCXのM
68 : 55 ff 00 ef 10 ef 10
4 : ff 00 ef 10 ef 10
4 : 55 ff 00 ef ef 10
4 : 55 ff 00 ef 10 ef
4 : 55 ff 00 ef 10 10
2 : 55 ff ef ef 10
2 : 55 ff 00 10 ef 10

RCXのS
48 : 55 ff 00 ef 10 ef 10
11 : 55 ff ef 10 ef 10
9 : 55 ff 00 ef ef 10
8 : 55 ff 00 ef 10 ef
4 : ff 00 ef 10 ef 10
4 : 55 ff 00 10 ef 10
3 : 55 00 ef 10 ef 10
2 : 55 ff 00 ef ef
2 : 55 ff 00 ef 10 10

ScoutのL
35 : ed 00 ef 10 ef 10
28 : b5 00 ef 10 ef 10
16 : 00 ef 10 ef 10
10 : 55 ff 00 ef 10 ef 10
8 : d5 00 ef 10 ef 10
2 : ff 00 ef 10 ef 10


ScoutのM
50 : ed 00 ef 10 ef 10
19 : 00 ef 10 ef 10
10 : b5 00 ef 10 ef 10
7 : d5 00 ef 10 ef 10
5 : fb 00 ef 10 ef 10
2 : ff 00 ef 10 ef 10
2 : f6 00 ef 10 ef 10
2 : 55 ff 00 ef 10 ef 10
2 :

ScoutのS
55 : 55 ff 00 ef 10 ef 10
36 : d5 00 ef 10 ef 10
5 : 00 ef 10 ef 10
2 : ff 00 ef 10 ef 10

つまり、55 ff 00以外にff 00 / ed 00 / b5 00 / d5 00を、
ヘッダーとして見とめてしまえば、成功率が高まる事が予想されます。

直ちに実行しました。
Towerをshortにして光軸を合わせれば、
10中8,9成功します。

予想される原因なのですが、
送受切り替えのタイミングというよりUSB Towerの、
IR LEDと受信モジュールの干渉が大きい様に思います。

RCXとScoutの応答時間の差異は影響していると思いますが、
それだけでは、IRT側の送信強度で、受信状態に変化が起こることを、
説明しにくいと思います。

私が予想したモデルは以下の通りです。
受信モジュールはAGCといって入射した信号の強度によって、
出力を一定にするようゲインを自動調節する仕組みが入っています。

COM　IRTに比べUSB IRTは送信指向性を向上させるため、
3個のLEDを多方向に向けて付けました。
これにより発射した赤外線が、自分の受信モジュールに、
強く受信される様になりました。

赤外線信号は振幅変調(on/off)で送られるため、
AGCは符号速度よりかなり遅く応答する様にしなければなりません。
自分の信号で送信中はゲインを最低にしていた、
IRTの受信モジュールは、Scoutが送信を開始する時期になっても、
受信に適したゲインまで戻る事ができず、
受信シグナルの先頭部がエラーになる。

このモデルなら送信強度が強いほど、
AGCが強くかかる事で、現象を説明できるかと思います。
AGCのかかり具合を外部から観測できれば実証できるのですが、
受信モジュールは1 chip ICなので、観測不能です。

追試する方のためにrcxlib/RCX_Link.cの該当ファンクション、
FindRCXSync()を書きます。

int FindRCXSync(const UByte *data, int length)
{
const UByte *end = data + length - 2;
const UByte *ptr;

for(ptr=data; ptr<end; ptr++)
{
if ( ptr[0]==0x55 &&
ptr[1]==0xff &&
ptr[2]==0x00) {
// printf("ok 0\n");
return ptr-data+3;
}
if (
ptr[0]==0xff &&
ptr[1]==0x00) {
// printf("ok 1\n");
return ptr-data+2;
}
if (
ptr[0]==0xed &&
ptr[1]==0x00) {
// printf("ok 2\n");
return ptr-data+2;
}
if (
ptr[0]==0xd5 &&
ptr[1]==0x00) {
// printf("ok 3\n");
return ptr-data+2;
}

}

return 0;
}

> 予想される原因なのですが、
> 送受切り替えのタイミングというよりUSB Towerの、
> IR LEDと受信モジュールの干渉が大きい様に思います。

> 私が予想したモデルは以下の通りです。

いやあ、お見事な考察をありがとうございます。
大変興味深く読ませていただきました。

これが正しいとすると、RCXでは失敗しないのは
Scout よりゆっくり応答しているということでしょうか？
それもなんだか不思議ですね。

それでは。

Jinさんのレシーバをシールドするアイデアは、
強力な傍証になりますね。
やってみました。

ケースを開けレシーバーの下にアルミホイルを挟み、
わざとlong rangeにして通信させた場合と、
そのまま、位置を変えず、アルミホイルを引き抜いた時の比較です。

シールドあり
99 : 55 ff 00 ef 10 ef 10
1 : ff 00 ef 10 ef 10

シールドなし
36 : d5 00 ef 10 ef 10
26 : 00 ef 10 ef 10
24 : 55 ff 00 ef 10 ef 10
7 : ff 00 ef 10 ef 10
7 : b5 00 ef 10 ef 10

これはビンゴでしょう、やはり。

清水さんの、時間差原因説への疑問はごもっともです。
Write後、1 char受信終了までの時間を計りました。
プログラムで行ったので、分解能が10msしかない事もあって、
RCX / Scoutは誤差範囲で一致してます。
共に50〜60msです。

分解能をあげると差が見られるのか？
他に原因があるのか、今のところ不明です。
とりあえず分解能を上げる方向で追試予定です。

Jin です
> Jinさんのレシーバをシールドするアイデアは、
> 強力な傍証になりますね。
> やってみました。

すばらしい！！。 その様子のイメージ見せてください〜。

> ケースを開けレシーバーの下にアルミホイルを挟み、
> わざとlong rangeにして通信させた場合と、
> そのまま、位置を変えず、アルミホイルを引き抜いた時の比較です。
>
> シールドあり
> 99 : 55 ff 00 ef 10 ef 10
> 1 : ff 00 ef 10 ef 10
>
> シールドなし
> 36 : d5 00 ef 10 ef 10
> 26 : 00 ef 10 ef 10
> 24 : 55 ff 00 ef 10 ef 10
> 7 : ff 00 ef 10 ef 10
> 7 : b5 00 ef 10 ef 10
>
> これはビンゴでしょう、やはり。

これは、ビンゴですね。 それにしても、ほとんどこぼさなくなるなんて。
ケースにうまく入れるようにできれば、見た目もきれいになるかもしれませんね。

（あ、でも半透明のプラスチック反射するから、だめかな）

それにしても、ここまで調べられると、ちょつとまとめて、LEGO MINDSTORMSの部隊
の人に、リポート書いて送ってあげたほうがいいかな〜なんてちらりと思ってしまいました。

ききょうや＠風邪でダウン気味です。

ｍａｃさん、なかなか興味のある実験結果でしたね

> つまり、55 ff 00以外にff 00 / ed 00 / b5 00 / d5 00を、
> ヘッダーとして見とめてしまえば、成功率が高まる事が予想されます。
ｆｆの部分が壊れることは結構多いみたいですね。
実験結果を眺めていてふと思ったのですが、送ったコマンドがわかっているなら
ｆｆのあとの部分である 00 ef 10 の部分をチェックする方が安全じゃないかと
思うのですがいかがでしょう？

RcxCCの方ではff 00 xxの３バイトの存在のみをチェックする方法にしてありますので
00 xx ~xx に変更するのは容易です。

ｎｑｃにこの改造が可能かどうかはソースを眺めてみることにします。

CyberMaster動かなかったのですね・・・・残念
もう一度見直してみます＜RcxCCのソース

ではでは

> > つまり、55 ff 00以外にff 00 / ed 00 / b5 00 / d5 00を、
> > ヘッダーとして見とめてしまえば、成功率が高まる事が予想されます。
> ｆｆの部分が壊れることは結構多いみたいですね。

そうですね。

55のstart bitを取り損ねて、
55の途中から読み始めた結果、
parityやstop bit 次に来るffのスタートビットまでも、
データーの一部として読み込み、
55とffがくっついてこれらのパターンが発生しているのでしょう。

Serial dataはlsbが先になるので、
下位ニブルに5が多いのはそのためだと思います。

> 実験結果を眺めていてふと思ったのですが、送ったコマンドがわかっているなら
> ｆｆのあとの部分である 00 ef 10 の部分をチェックする方が安全じゃないかと
> 思うのですがいかがでしょう？

これはいいアイデアですね。

1/2^24あった、エラー検出能力が、
私の案だと、1/2^14まで低下してますから、
あまり手間をかけずに修正できれば、
ききょうやさんの案のほうが優れています。

b3のtoggleは1/0両方の可能性があるので、
検出力は1/2^23ということですね。

もっとも、1/2^14の検出力でも、
このルーチンはプリアンブルを取り除き、
データーの頭出しをするのが目的ですので、
その後データー自身のチェックで跳ねられ、
それほど、大きな問題を生じないと思います。

> b3のtoggleは1/0両方の可能性があるので、
> 検出力は1/2^23ということですね。

済みません。
言ってしまった後で、けちをつけるようで大変恐縮なのですが、
私が論理的に勘違いしている様なので、訂正します。

このデーター切り出しの精度については、
先の考察の通り、ききょうやさんの案が優れているのですが、
Packet全体のエラー検出能力は、
この案では同じデーター本体を2回チェックすることになるので向上しません。

崩れてはいるものの、データー部とは独立な、プリアンブルをチェックしている、
私の案の方が多くの情報を取り入れているため検出力が上がるのではないかと思います。

mac さん、Deepな世界ですね〜。

> 私が予想したモデルは以下の通りです。
> 受信モジュールはAGCといって入射した信号の強度によって、
> 出力を一定にするようゲインを自動調節する仕組みが入っています。
>
> COM　IRTに比べUSB IRTは送信指向性を向上させるため、
> 3個のLEDを多方向に向けて付けました。
> これにより発射した赤外線が、自分の受信モジュールに、
> 強く受信される様になりました。

もしも、USB IRTower を裸にして、赤外線受信モジュールをアルミ箔や何かで、
指向性高めてやると干渉が減る可能性があるのかな？

> > COM1にCM Towerを接続してあります。
> 実はCyberMasterは自動認識できるようになっていないのです。
> 自動認識せず、COM1とCMをチェックして起動してみてください。

済みません。

手動でCOM1とCyberMasterにチェックを入れた結果が、
こうなっています。
Version Infoはメモしなかったので、
今夜にでももう一度やってみます。

mickyです。
ききょうやさん、
NQCのUSBタワー対応版、早速使わせていただきました。
USBタワーからSCOUTへのダウンロードはうまくいきました。
RCXccもRIS1.Xなしで使えるようになって本当に助かりました。
Q&Aでのアドバイスも大変参考になりました。
ありがとうございました。

ききょうやです

> NQCのUSBタワー対応版、早速使わせていただきました。
> USBタワーからSCOUTへのダウンロードはうまくいきました。
> RCXccもRIS1.Xなしで使えるようになって本当に助かりました。
> Q&Aでのアドバイスも大変参考になりました。
> ありがとうございました。
お役にたててうれしく思います。
改善点、追加機能のリクエスト等ありましたら
どしどしお願いします。

ではでは

ききょうや＠ちょっと訂正です。

> 上記の家アイコンからDLしてください。＜元祖掲示板と勘違い
上記URLからDLしてください。

清水です。
結果的にはあんまりおもしろくなかったのですが、
話の種になればと思いまして。
＃ ちょっと長いです。

先週、お気コンマシンをツクモロボコンマガジン館さんに
持っていったついでに、Vision Command を買ってきました。
で、固定カメラでひとしきり遊んでいたのですが、
やはりモーターで動かしたくなって来るんですよね。
しかしRCXはロボコンマガジン館さんに出張中...なので、
お気コンでもらった Scout に目をつけ、
これを使って遊べないかやってみました。

別スレッドで話題に上がっているように、USB IRタワーと Scout は
どうも上手にお話ができないようです。Vision Command からでも
「通信相手がいません」とか「うまく話せない」といったエラーが出て、
運がよくないと会話が成立しませんでした。

やってみよう その1: Vison Command の矢印ボタンで Scout を動かす

Vision Command の画像の下にある矢印ボタンで Scout を動かせないか
やってみました。「どうせリモコンのコマンドを飛ばしているだけ
だろうから、問題ないに違いない」と予想していたのですが、
これは半分だけ正解でした。
「リモコンコマンドを飛ばしている」は正解で、
一応 Scout はコマンドを受けてモーターを動かすのですが、
次のような問題があることがわかりました。

問題のひとつめ:
Vision Command の矢印ボタンがモーターをどのように動かすのかは、Command Center に入るときに選ぶロボットの種類によって決まります。
こともあろうに、これらのロボットはRCXのモーターポートA+Cまたは
B+Cを使っているのです。ですから、この矢印リモコンのボタンを押すと、
モーターAとCを動かす組み合わせか、BとCを動かす組み合わせの
コマンドしか送信されません。Scout のモーターポートはAとBで、
CはVLL送信用LEDに相当しますから、片方のモーターだけが動いて
LEDがぴかぴかする、というちょっと寂しい動きしか
してくれませんでした。

問題のふたつめ:
矢印ボタンを押すと、Vision Command の動作がしばらく(数秒)停止し、
操作を受け付けなくなります。ボタンを押しつづけると、
コマンドを送信しては動作停止、の繰り返しとなり、
「ガッ...ガッ...」とモーターが断続的に回転します。
これはうれしくありません。
どうやら、Vision Command の矢印リモコンは、リモコンの分際(?)で
RCXからの応答を待つ仕組みになっているようです。
Scout は上手に応答を返せない(またはIRタワーが上手に受信できない)
ので、結果的に受信タイムアウト時間の間 Vision Command が
待ち続けてしまうことになるようです。
コントロールパネルでUSB IRタワーの受信タイムアウト時間を
短くすると、それなりにスムーズに動くようになりました。

やってみよう その2: RCXコマンドを使ったプログラムを実行する

画像に反応してRCXコマンドを送信するプログラムを作って、
Scout を動かせるか？というお話です。
これができれば Scout でも結構遊べそうですよね。
RCXコマンドを使用したプログラムを作ってRUNすると、まず
Vision Command はRCXがいるかどうかを確認しに行きます。
ここで、IRタワーの前に Scout を置いておくと、
なんと Vision Command は「RCXがいたよ」と言いました。
まんまとだまされてくれた、と喜んだのもつかの間、
「でもファームウェアが古いから、新しいのをダウンロードするね」
などと言い出してしまいました。
こんなことをされると Scout は「はぁ？」と答えるしかなく、
ここで Vision Command と Scout との会話は終了とあいなりました。
ちゃんちゃん。

...というわけで、Vision Command と Scout で遊ぶ野望は
見事に玉砕されてしまいました。
やっぱり nqc かあ。

Jinです。
そうか、Vision Command と Scout の組み合わせというのは、今まで考えもしませんでした。

> ...というわけで、Vision Command と Scout で遊ぶ野望は
> 見事に玉砕されてしまいました。

そりゃ残念。

まあ、EGOにしてみれば、パソコンがなくても楽しめる SCOUTという事で売られていると思うん
で、Vision Commandまでは考えてなかったんでしょうね。 でも、せっかくの商品資産を
有効に活用できなかったのは残念ですね。
日本語版の Vison Command は USB IR-Towerも正式にサポートしたものになると
思いますが、SCOUTはどうなんでしょうね〜？

2001年には SCOUTの新しいバージョンなどがでる予定もなさそうなんで、このま
ま消えていく運命にあるのかな〜。 （さびしいような）
それとも、意外などんでん返しがあったりして。 （わくわく）

> まあ、EGOにしてみれば、パソコンがなくても楽しめる SCOUTという事で売られていると思うん
> で、Vision Commandまでは考えてなかったんでしょうね。

RCXにも最新のfirm0321.lgoを要求するので、
firm0309.lgoのsubset相当のScoutでは、
無理だったのでしょうね。

でも、flash ROMの価格も十分安くなった事だし、
できれば、ScoutやMicroScoutも、
firmを変更できるようにしてほしかったですね。

そうすれば、多分VisionCommandにも対応できたし、
今回のUSB IRT / Scoutの件だって、抜本的対策ができたでしょう。

清水です。

> 日本語版の Vison Command は USB IR-Towerも正式にサポートしたものになると
> 思いますが、SCOUTはどうなんでしょうね〜？

私がVision Commandを走らせて「おやっ」と思ったことがあります。
というのは、IRタワーの接続の仕方を説明するムービーで、
「もしあなたの持ってるRISが2.0だったら、こんなふうに
USBポートに差します」などと言うのです。
また、IRタワーの状態表示画面でも「ハイパワーハブ」とか
出てくるので、既にUSB正式対応のマイナーバージョンアップが
為されているのかなと思いました。

それでは。