はじめて投稿させていただきます、TomTomと申します。

RCX CODEのセンサーウォッチャーの使い方がよく分かりません。
私は割込み処理のようなものかと思っていたのですが、
使っているうちに違うような気がしてきました。

割込み処理なら、短い処理にしないといけないとか、
Waitなんか入れたらマズイんじゃないかとか考えますが、
本の参考プログラム等を見たら平気でWaitを使っています。

ひょっとしてメインプログラムとは別のタスクになっていて、
一定時間毎にセンサー状態を見に行くというイメージなんでしょうか？

また、センサーウォッチャーの処理をあまり長くすると、
途中で処理が途切れてしまっているような気がするのですが、
処理時間制限のようなものがあるのでしょうか？

メインプログラムとセンサーウォッチャーの処理配分を
どういう風に考えたらいいのか悩んでいます。
どなたかアドバイスをお願いします。

> ひょっとしてメインプログラムとは別のタスクになっていて、
> 一定時間毎にセンサー状態を見に行くというイメージなんでしょうか？

そうです。
RCXのファームウエアは、マルチタスクになっていて、
センサーウォッチャーは、
メインとは別のスレッドで実行されるため、
時間制限はありません。

センサーの状態は、周期的にポーリングされ、
センサーウォッチャーの条件にしたがった変化があると、
その下に連なるタスクが実行されます。

残念なことにRCX codeでは、
タスクを明示的に生成／消滅させることが出来ないので、
複雑な条件を組み合わせて、センサーウォッチャーを、
切りかえようとするとかなり無理があります。

たとえば、最初は時間だけで制御して動作し、
後半は、パスファインダーの様にセンサーで動作し、
最後はわざとコースを外れてゴールするなどです。

しかし、ファームウエア自身には、
タスクのstart, stop機能があり、
Robolabや、NQCではこれを活用することが出来ます。

処理配分にお悩みのようですと、
マルチタスクに関し知識をおもちで、
既に結構複雑な動作をさせようとなさっているのではないかと、
思うのですが、いかがでしょうか。

その場合はRCX codeより、NQCの導入をお勧めします。
NQCに関しては、
http://www.mi-ra-i.com/JinSato/MindStorms/nqc/index.html
をご覧ください。

Jinさん、macさん、早速の返信ありがとうございます。

やはりタスクですかぁ。
では、タスクの切り替わるタイミングはやはり時間でしょうか？
優先順位はありませんよね。（指定はできませんよね）

メカ制御というとリアルタイムOSを期待してしまいがちですが、
RCXは割込み無しでタイムシェアリング（時間配分）方式の
マルチタスク処理という感じかと思うのですが。

JinさんWrote:
> もしくは、NQCなどを使い始めてみると良いかもしれません、
> こちらの方がすっきりする場合も多くあります。

macさんWrote:
> 残念なことにRCX codeでは、
> タスクを明示的に生成／消滅させることが出来ないので、
> 複雑な条件を組み合わせて、センサーウォッチャーを、
> 切りかえようとするとかなり無理があります。
> 処理配分にお悩みのようですと、
> マルチタスクに関し知識をおもちで、
> 既に結構複雑な動作をさせようとなさっているのではないかと、
> 思うのですが、いかがでしょうか。
> その場合はRCX codeより、NQCの導入をお勧めします。

そうですね、NQCだったらもっと楽に複雑な処理ができますし、
ロボットの動きも予想しやすい気がします。

複数のセンサーウォッチャーをつなげ、
タスク間で同期とりのようなことをやらせようとしてみたのですが、
制限がありすぎてとてもプログラミングがややこしくなり、
思うように動いてくれなかったりします。（これはバグか？）

また、何回確認しても（数人で）プログラムは合ってる気がするのに
うまく動かなかったり、ほとんど同じ処理を３回つなげてるのに
３回目だけうまく行かなかったり、RCX CODEは難しいです！

RCXのOSとRCX CODEについてもっと理解するには
いろいろなプログラムを作ってみて実験するか、
NQCを使って行く方がやはり近道でしょうか。

> では、タスクの切り替わるタイミングはやはり時間でしょうか？
> 優先順位はありませんよね。（指定はできませんよね）

現バージョンにはありませんが、RIS2.0SDK
http://www.legomindstorms.com/sdk2/index.html
では、タスクの優先順位設定が可能です。
ソースがないので、正確なところはわかりませんが、
タイマー割り込みでタスクスイッチする、
ラウンドロピン方式になっているのでしょう。

> メカ制御というとリアルタイムOSを期待してしまいがちですが、
> RCXは割込み無しでタイムシェアリング（時間配分）方式の
> マルチタスク処理という感じかと思うのですが。

すべての事象の発生がinterrupt drivenになっている場合には、
RTOSでなくても、多重割り込みさえ可能なら、
シングルタスク+Interrupt Service Routineでいけます。

ポーリングしなくてはいけない事象が、
非同期に複数あり、ある事象の処理をしているさなかにも、
別の事象をポーリングによって処理しなければいけないときが、
RTOSの必要性をもっとも感じると思います。

> RCXのOSとRCX CODEについてもっと理解するには
> いろいろなプログラムを作ってみて実験するか、
> NQCを使って行く方がやはり近道でしょうか。

RIS付属の開発環境は、マルチタスクを意識せずに、
誰でもマルチタスク処理のプログラムが出来るのが、
すごいところで、それ以外の難しい部分は、
極力意識的に排除されていると思います。
たとえば、「変数」さえもありません。
Robolabでは、4変数に制限されてます。

それが故意であることは、
RCXの「純正」ファームウエアーにはその機能があり、
NQCで引き出せることから明らかです。

それでも、これは一種の中間コードインタープリターですので、
処理速度には限界があり、それを上回る性能を求めるなら、
jinさんもおっしゃっているlegOSを導入することになります。

さらに、legOSの機能では飽き足らない場合、
OSを自作してしまうのも「あり」で、
実際、いしかわきょーすけさんがiTRONの実装に挑戦しています。
http://www.asahi-net.or.jp/~qx5k-iskw/lego/

> すべての事象の発生がinterrupt drivenになっている場合には、
> RTOSでなくても、多重割り込みさえ可能なら、
> シングルタスク+Interrupt Service Routineでいけます。

もう少し確認させていただきたいのですが、
NQCではInterrupt Service Routineの記述はできないですよね。
（もちろんRCX CODEでも）

たとえば、センサーの変化によりなにか処理させたい場合、
本来ならInterruptを使いたいところですが、
その代わりに、RCX CODEではセンサーウォッチャーを、
NQCではスキャンタスクを作成するとか、
タスク内のループでチェックするというのでいいですよね。

> さらに、legOSの機能では飽き足らない場合、
> OSを自作してしまうのも「あり」で、
> 実際、いしかわきょーすけさんがiTRONの実装に挑戦しています。

今のところ自作までは考えていません。というよりできません。
私が知りたいのはRCX OSの限界？制限？なんです。
こんなことしちゃいけないよとか、
こうしなくちゃいけないよとか、
ここまでしかできないよとか．．．。
そんなこと考える私はわがままでしょうか？

茶々みたいでもうしわけないですが、ちょっと思うところを一言

> 今のところ自作までは考えていません。というよりできません。
> 私が知りたいのはRCX OSの限界？制限？なんです。
> こんなことしちゃいけないよとか、
> こうしなくちゃいけないよとか、
> ここまでしかできないよとか．．．。
> そんなこと考える私はわがままでしょうか？

というより、それを調べるのもたのしいのではないかと思いますし、
そういうことを調べることが”科学”するっていうことだと思うのですが。
MindStormsはおもちゃでなのにそれが出来る、それが子どもから
大人まで楽しめるゆえんでしょう。
”これはできない、こうしなくちゃいけない、ここまでしかできない”って
いうことを全部教えてもらえたら、TomTomさんはその後、どうするのかな〜と
ちょっと思ったりしてます。事実を教えてもらうより、それを自分で調べる過程の
ほうがずっと大事なんじゃないかと思うわけですが、いかがでしょう。
ＲＣＸは所詮ちっぽけなコンピュータですからできないことなんかたくさん
あるに決まってるわけですから。説教臭くてゴメンナサイね。

まるさん、こんにちは。
貴重なご意見ありがとうございます。

> いうことを全部教えてもらえたら、TomTomさんはその後、どうするのかな〜と
> ちょっと思ったりしてます。事実を教えてもらうより、それを自分で調べる過程の
> ほうがずっと大事なんじゃないかと思うわけですが、いかがでしょう。
> ＲＣＸは所詮ちっぽけなコンピュータですからできないことなんかたくさん
> あるに決まってるわけですから。説教臭くてゴメンナサイね。

私の書き方がまるさんの誤解を招いてしまったようです。
決して全部教えてしただきたいわけではないんです。
OS(?)の基本仕様だけなんです。
マルチタスク制御ができてタスクのスイッチングは一定時間毎に行われ、
センサの状態はタスク内でチェックするんだなぁ〜、
とここまでの話の内容で理解しているのですが．．．。

もちろん自分でいろいろ実験するのは大好きです。
ただ、今は公私とも大変忙しく（言い訳ですが）、
「これだけはまず知っておきたい」っていうことを研究する時間がとれず、
ここに質問を投稿させていただいた次第です。

私はでRTOSと制御ソフトを実機に組み込むという仕事を
数年やってきましたが、まだまだ知識も応用力もありません。
ここにはその道のプロの方も大勢いらっしゃるようだったので
相談してみたらと思ったんです。

もちろん、思いっきり遊ぶ時間がとれるようになったら
いっぱいいっぱい RCX OSで実験してみて、
そのうちにlegOSは絶対組み込んでみたいと思っています。
自作は自信ないですが。

ちなみに私にとって「科学する」ってことは
一番好きなことのひとつです、まるさん。

皆さん、Q&Aの内容から脱線してもうしわけありませんでした。

すいません。脱線の張本人です。

> 私の書き方がまるさんの誤解を招いてしまったようです。
> 決して全部教えてしただきたいわけではないんです。
> OS(?)の基本仕様だけなんです。
> マルチタスク制御ができてタスクのスイッチングは一定時間毎に行われ、
> センサの状態はタスク内でチェックするんだなぁ〜、
> とここまでの話の内容で理解しているのですが．．．。

誤解というかこのへんがたのしいのにな〜と思ったのと
Jinさんも時々書いておられるように質問だけするのじゃなくて
自分はいまこういうことやろうとしてるんだよ〜みたいなのも
あるといいコミュニケーションになるかなとおもってかいてしまいました。
お気を悪くされてなければ幸いです。

TomTomさん、これからもよろしくおねがいしますね。
そのうちTomTomさんに質問するかも知れませんし(^o^;

> 自分はいまこういうことやろうとしてるんだよ〜みたいなのも
> あるといいコミュニケーションになるかなとおもってかいてしまいました。
> お気を悪くされてなければ幸いです。

そうですね、自分のことを最初に紹介するべきでした。

私が最初にMINDSTORMSを知ったのは今年の３月の始めだったと思います。
子供のころブロックというものをやったことがなかったので、
今の仕事をやっていなかったら多分興味はもたなかったと思います。
MINDSTORMS関係のHPを見ているうちにこれはただものではないと思い、
ぜひやってみたいと感じました。

私が今までに作ってみたのは、お気軽コンテスト#1のトレースロボットと
モータの回転検知機能付きロボット（これは未完成）です。
私にとって難しいのはやはりブロックの組み立てです。
投稿作品やコンテスト参加作品を見せていただいていると、
「なんでこんなもん思いつくんだ！」と関心させられっぱなしです。

今はMINDSTORMSは借り物なので、近々、自分で買う予定です！
作るペースは、多分、すごくゆっくりになると思いますが、
いろんなものに挑戦していきたいと思っています。

> TomTomさん、これからもよろしくおねがいしますね。
> そのうちTomTomさんに質問するかも知れませんし(^o^;

お答えできればいいのですが．．．。
これからもよろしくお願いします。

> NQCではInterrupt Service Routineの記述はできないですよね。

できません。

> たとえば、センサーの変化によりなにか処理させたい場合、
> 本来ならInterruptを使いたいところですが、
> その代わりに、RCX CODEではセンサーウォッチャーを、
> NQCではスキャンタスクを作成するとか、
> タスク内のループでチェックするというのでいいですよね。

「本来なら」が、「RTOSを使う場合、本来なら」でしょうか、
「自分がOSを作る場合、本来なら」でしょうか、あるいは、
「自分がハードを作るとしたら、本来なら」でしょうか？
「一般に外部事象を捉えようとするばあい、本来なら」かな？
細かくて済みません、どうもこの辺が、微妙な差異というか、
話がずれている原因のように思えているのです。

まず、割り込みを使えるのは、OSの有無にかかわらず、
金物が割り込みを発生できる機能をもっている場合に限られます。
産業用の高性能温度センサーでも、割り込みは発生しません。
どうしても割り込みで処理する必要があるなら、
外部にサブシステムをつけ、割り込み信号線を駆動するほかありません。

次に何らかのOSがあるなら、アプリケーションソフトは、
割り込みを記述しません。
割り込みを処理するのは、デバイスドライバの仕事で、
これはOSの一部です。

GUIアプリケーションのように、
ボタンが押されたときにイベントハンドラを起動するものや、
並行タスクが発生したメッセージを処理するため、
シグナルハンドラはありますが、
これは、割り込みとは区別した方がよいと思います。

割り込み処理を記述しなければならないのは、
ハードウエアに割り込み発生機能があり、
OSもしくはOSの一部を記述しているか、
OSが存在しないため、自分でシステムを、
全部プログラムしなければならない場合ですね。

もしかすると、このうちの「イベントハンドラ」を、
割り込みとおっしゃっているのかもしれません。
これも、RCX2.0SDKには追加されたようですね。

> 私が知りたいのはRCX OSの限界？制限？なんです。

ファームウエアの限界は、NQCの限界とほぼ同一といえます。
RCX2.0SDKの追加機能も、精力的に追加作業が続いており、
RIS2.0正式リリース時には、やはりNQCが限界を極めそうです。
もっとも今度は、p-Brick Script Languageという純正の言語があり、
やはりファームウエアの限界を引き出せるようです。

これにも、イベントタスクを起動する機能があり、
たとえば、
monitor lightLow {forever {sound 1 wait 10}} abort on event
ライトセンサーが（あらかじめ設定された）低レベルを検知したら、
別のイベント発生までサウンド1を十秒おきにならせ。

のように記述できます。

結局ソフトの限界は、自然界の法則による限界とは異なり、
作ってしまえばなんでもありなんで、
あまりこだわらずに、手当たり次第試してみた方が楽しいですよ (^o^)

> 細かくて済みません、どうもこの辺が、微妙な差異というか、
> 話がずれている原因のように思えているのです。

「本来なら」ということばは余分でした。
そのあとの「使いたい」というとこだけが言いたかったことです。

> もしかすると、このうちの「イベントハンドラ」を、
> 割り込みとおっしゃっているのかもしれません。
> これも、RCX2.0SDKには追加されたようですね。

ハードの割込み処理（デバイスドライバ）と
イベントハンドラの両方のことを言ってました。

でもよく考えるとデバイスドライバの処理範囲は、
割込みが発生してノイズでないことを確認し、
その値を読みとって指定範囲内であればイベントを発生させる、
ところくらいまでですよね。

> あまりこだわらずに、手当たり次第試してみた方が楽しいですよ (^o^)

私のわがままに何度も付き合っていただきありがとうございました。
macさんのお話どれも納得できて、もやもやしたものが一気に取れました。
これから「手当たり次第」やってみます！

> でもよく考えるとデバイスドライバの処理範囲は、
> 割込みが発生してノイズでないことを確認し、
> その値を読みとって指定範囲内であればイベントを発生させる、
> ところくらいまでですよね。

いえ、light sensorのdev. driverは、
電力供給と読み取りを一本の線で時分割しているため、
logOSのソースを見ていただくと分かりますが、結構複雑です。
角度センサーは、もっと複雑でしかも不完全です (^^;

> 私のわがままに何度も付き合っていただきありがとうございました。

私の解説は、人のためという高尚な志ではなく、
単なる趣味の一部ですんで、
教育的配慮とか、正確さについて無保証です。
また、質問の仕方、内容にかかわらず、知っていても答えなかったり、
途中で放棄することがありますが、他意はありませんので、
あらかじめご了承ください　(^o^)

Jinです。

>また、何回確認しても（数人で）プログラムは合ってる気がするのに
>うまく動かなかったり、ほとんど同じ処理を３回つなげてるのに
> ３回目だけうまく行かなかったり、RCX CODEは難しいです！

　それは、やはり、センサーの押されるタイミングや、メカニズムの誤差
など色々な要因があります。

　パソコンの中だけで完結しているプログラミングなどとは、その辺がちが
いますよね。　逆にいうと、プログラミングを本業としている自分でも、
パソコンの中で完結していているのになれていた人間が、複数のセンサーの
押されるタイミングがほんのちょっと違ったり（人の目的には同時でも）
メカニズムの構造的に生まれる誤差や、センサーの誤差などを体験して
リアルワールドとつながっている、プログラミングの難しさを感じた思いがあります。

　ところで、TomTom　さん、どんなロボットつくっているんですが〜。
ちょっと教えてください〜。　もしくは、どしどし、投稿してください〜。
みたいな〜、　＞　TomTomさん


> NQCを使って行く方がやはり近道でしょうか。
　そうだとおもいます。
　
　また、ちょっとチャレンジして、RCX2SDKを使うのも面白いと思いますよ。

RCX2SDKについては、左側のソフト関連のところに情報まとめてます。

もしくは、ハードにせめて、legOS なんてのも楽しいかもしれませんよ〜。

> 　それは、やはり、センサーの押されるタイミングや、メカニズムの誤差
> など色々な要因があります。

そうですね。
その誤差とブラックボックス部分の不明さがもどかしいです。

> 　ところで、TomTom　さん、どんなロボットつくっているんですが〜。
> ちょっと教えてください〜。　もしくは、どしどし、投稿してください〜。

ロボットの写真やプログラムの投稿は
Jinさんへのメールで行えばよいのでしょうか？
そのプログラムでだめだった原因を指摘していただければありがたいです。

> もしくは、ハードにせめて、legOS なんてのも楽しいかもしれませんよ〜。

ゆくゆくはlegOSを使いたいと思っています。
でも、RCX CODEを消化不良で終わらせたくないんです。

> > 　ところで、TomTom　さん、どんなロボットつくっているんですが〜。
> > ちょっと教えてください〜。　もしくは、どしどし、投稿してください〜。
>
> ロボットの写真やプログラムの投稿は
> Jinさんへのメールで行えばよいのでしょうか？

http://207.236.16.161/JinSato/MindStorms/Toukou/20000509/index.html
にあるような書式でHTMLとイメージをメールで送ってください〜。
投稿いただいて、早時で翌日、時間がかかるときで1週間くらいで
掲載させていただきます。
　また、いままで、投稿いただいたのは
http://207.236.16.161/JinSato/MindStorms/Toukou/　　
で見ることができます。

　いずれは、ここも、CGIで自動化したいな〜、なんて思っていますが、それまでは
まだ、手動です　（＾＾）

他の投稿作品を見てかなり怖気づいていますぅ〜。
もう少しましなもの作れて、デジカメを手に入れたら、
投稿させていただきますね。

●TomTom　さんへ　JinSatoです。

> ひょっとしてメインプログラムとは別のタスクになっていて、
> 一定時間毎にセンサー状態を見に行くというイメージなんでしょうか？

　ビンゴーです。　そういう風に内部で動いていると思って間違い有りません。
　NQC　でプログラムを作る場合は、別タスクで、別のタスクで無限ループを
　作っているような感じで作ることがよくあります。

> また、センサーウォッチャーの処理をあまり長くすると、
> 途中で処理が途切れてしまっているような気がするのですが、
> 処理時間制限のようなものがあるのでしょうか？

　これは、プログラムとか具体的な例がないと分からないのですが、
Mainの方でも無限ループなどを作る必要があるときがありますし、
メインの方はただの初期化として利用して、後は、センサーウオッチの
中の、どれか１つが後でのっとるように作る必要がある場合も有ると思います。

　
> メインプログラムとセンサーウォッチャーの処理配分を
> どういう風に考えたらいいのか悩んでいます。

　ロボットによるんじゃないでしょうか。
　また、センサーウオッチの利用法にもよります。

　メインの部分は、初期化だけ、
あとは、センサーウオッチの中で、条件分岐したどこかが、あとから
メインのループになるように考えてみてはどうでしょうか？。

　もしくは、NQCなどを使い始めてみると良いかもしれません、こちらの
方がすっきりする場合も多くあります。

私のパソコン"NEC:Pc-9821,Nr13"でもファームウェアー転送ができませんでした。トランスミッターLEDは一瞬光るのですがダメみたいです。ちなみに友人の"東芝:Libretto50"では正常に転送できました。９８で転送させる方法ご存知の方情報教えて下さい。

ＪｉｎＳａｔｏです。

「PC9821Cx13」や 「PC9821Nb7」 などの話をＦＡＱには載せていますが
それらのマシンでは、動いたという話を聞いたことがまだありません。

ＦＡＱの方でも情報を集めていますが、やはり、 ＰＣ-９８２１.NＲ１３
もだめなんですね残念です。