reo

reo　は、元々は、Fさんと共同開発をしようと始めたプロジェクトだった。
それが、ぼくの勝手によって、中止となったのである。

Fさんに頼もうと思っていた相場・調査・分析は、弱視に鞭打ってでも、
自力でやろうとしている。既に調査項目と分析方法は、固まっている。
プログラミングが始まれば、デカ文字エディタと、頭さえあれば、
問題なく、進むだろう。完成したら、MTエディタにコピーして、
コンパイルするだけだ。MTエディタは見易いとは言えないが、
操作位置などを事前に頭に入れておけば、問題ない。
1年ほどに渡って取り組んだ、経験もある。
ロボット開発には、経験値がものを言う。

こう言うぼくも、ゼロから、コーディングした経験はない。
しかし、改造したコーディング量は、何個分のロボットにも、相当するだろう。
よくも、MQLをしっかり学びもせず、大量のコーディングをしたものだと、自分でも驚く。
しかし、思いも寄らぬ挙動をしたことは、一度も無かった。
気づかなかっただけだろうか。最後の1か月ほどは、パソコンを
ほぼ、放置していたのだ。よく、やったもんだ。

reoは放置しておいても、問題が起きれば、悲鳴を上げる機能を付けておくつもりだ。
問題のレベルによってBEEP音の間隔を変えればよいだろう。
その理由も、MTのコンソールに表示すればいい。
順調なら、順調のレベルも、運用者に教えるといいよね。
このようなロボットの機能を、モールス（Morse）あるいは、
モールス機能と呼ぶことにして、技研のロボットには、必ず、
標準装備するようにしたい。

また、機能しなくなったロボットを、調整・メンテナンスする機能を、
サイボーグと呼んだが、これをロボット内部に持つのは、MQLの機能から、
不可能なので、別枠で作る必要がある。
師かも。調整・メンテ・プログラムのイメージと、サイボーグと言う言葉の
イメージが合わない。そこで、単体機能としての、
調整・メンテ機能のプログラムをリモコン（Remocon）
あるいは、リモコン機能と呼び、その価値をロボット本体とは、
別のの価値として、認識し確立したいと考える。
これで、reoロボットは、モールス機能と、リモコン機能を持っていると、
利用者に、伝えることができる。

モールス機能は、MQLのみ下実現するので、比較的易しいプログラムだ。
リモコン機能は、設計も、プログラミングも面倒で、しかも、
MQLでは、作れない機能だ。外部の言語で作らなくてはならないだろう。
技研では、リモコン開発の技術も、蓄積したい考えだ。

技研の方針は、過去、迷走したが、時間が経つ中で、
固まってきたと思うのは、自己満足なのだろうか。
よく考えれば、通信ロボットは、ナンセンスだった。
モールスとリモコンについても、意見があれば教えてほしい。
耳を傾ける用意はある。