リモートブレインを見直そう

ロボット作ろう：新リモートブレイン

シェーキーで考えていたリモートブレインの方式を図にまとめました。

これはネットタンサーの方式と同じです。
ロボット側では、一定距離の走行とか旋回とかの運動の制御のみを行い、ローカルコンピュータに走らせた専用ソフトで、障害物の回避などの行動型人工知能や、画像処理などの高度な情報処理、ユーザーとのインターフェイスを行います。
この構成では、ネット接続は主に遠隔操作に用いられています。

シェーキーではこれに対話型の人工知能を追加して、普通の言葉でロボットに命令できるようにしたいと考えていました。

今回はこの方式をこんな風に見直します。

見ればお分かりの通り、ロボットの情報処理の主要部分を、ローカルのコンピュータからリモートサーバへと移してあります。また、ロボットとの対話は、ネット端末でサーバにアクセスして行います。

ロボットへの命令だけでなく、適当なインターネット端末があれば、どこからでもこのロボットのソフトを開発することも可能になります。今までの僕にはなかった発想です。これがどういう効果をもたらすかはわかりませんが、ともかく今回はこれで行こうと思います。

ただし普通のクライアント・サーバモデルでは、サーバー側にあるロボットの頭脳がボディをリアルタイムに制御するのは困難です。Skypeなどの仕組みを使えないかとも思いましたが、ちょっと難しそうです。

そこで、リアルタイム性の必要な行動制御の部分を、リモートブレインからロボット側に移しました。さらにこれをプログラマブルにし、リモートサーバからプログラムを送り込むことで、特定の場所に移動したり、センサーを使って環境を測定したりする一連の動作を、ロボットだけで完結できるようにするつもりです。大げさに言えば宇宙探査機と同じです。

ローカルコンピュータはネットワークのブリッジとしてのみ機能するので、無線LANを搭載したボードコンピュータを使えば、ロボットに搭載することも出来ます。こうすると製品としてのロボットのまとまりが良くなります。ただ、消費電力の問題がありますが。

今回はここまで。続きは次回。

「シェーキー」プロジェクトを手直しする

ロボット作ろう：シェーキー製作記

久しぶりの更新です。

ここでやっているシェーキー製作は、「60年代の知能ロボット、シェーキーの動く模型を作る」というコンセプトではじめました。
当時の技術水準から「やむを得ず」リモートブレインを実装している知能ロボットを、21世紀のアマチュア工作で再現しようというものです。

スタートはかなり順調でしたが、現在は進行が滞っています。大きな理由は、いままでの投稿にあるように「作るものがでかい」という素朴なものです。

模型である以上、見た目は重要です。現在生地完成状態のロボットの艤装を進めるには、どうしても大きなロボットの塗装を先に済ませる必要があり、これが都会のマンション暮らしではなんとも困難です。

楽しみではじめたプロジェクトだからぼちぼちやればいいか・・　と思っていたのですが、どうもスッキリしません。

そんなわけで、思い切って現状のプロジェクトから卒業することにしました。3月ですからね。

新しいプロジェクトをはじめましょう。

このプロジェクトは「シェーキーの模型を作るという」コンセプトはそのまま生かしますが、もう少し未来につながるカタチにしたいと思っています。

つまり、リモートブレインの考え方をもう少しコンテンポラリーなものにする、ということです。

現在のシェーキーは無線LANで頭脳となるパソコンに接続する、というオーソドックスな方式をとっています。これは有効ですが、ロボットに搭載可能なコンピュータが高度化している現在、必ずしも効率的な方法ではないのかもしれません。未来を見据えた見直しが必要です。

それから、製作する機械は「身の程」にあったものにすることにします。シェーキーは現在でも大きくて重く、実験するのも大変です。オドメトリの実験をしたときには、ほとほと疲れました。もっと小型の軽い機械にしたいと思います。お座敷プロジェクトという認識が甘かったですね。

このへんを盛り込んだ、プロジェクトの内容はのちほど。

Tiny-BASICをデバッグする

「未曾有」という言葉がこれほど実感を伴って語られるとは・・ 使い古された慣用句の重さを感じる昨今です。

震災の影響で自宅待機になったので、気持ちの切り替えもかねて、HANA-BASICのデバッグをしました。

改良版のプロジェクトはこれ↓。このソースは20MHz版です。hexファイルも入ってます。

「HanaBASIC_V041.zip」をダウンロード

大きなバグとしては、forループ実行中にカウンター変数を書き換えて抜けようとすると、1回余分に回ってしまうというのがありました。

今回はこれまで。

みなさまどうぞご自愛のほどを。

PICのTiny-BASICで移動ロボットを試す

HANACの裏側にはこのようにメタルコネクタでI/Oを引き出してあります。

最初はMT管の9Pソケットを使うつもりでしたが、相方のプラグが絶滅状態なのであきらめました。アキバの国際ラジオにも無かったですからね。

ここからモータードライバとPSDセンサに接続し、障害物をよけながら移動するロボットを試します。シャーシは以前作ったこれを流用しています。20MHzにクロックアップしたHANACをどんと乗っけてます。

XBeeでターミナルと無線接続してるので、ロボットからのレポートを見ながら実験できます。ちょっとNASAのコントロールセンターみたいでカッコイイですね。（それほどでもないか…）

見てお分かりの通り、１個のPSD（赤外線測距センサ）で回りをスキャンしながら、進行方向を決めています。PSDの読み出し値はADの値そのままです。距離への変換はしていません。

このテストで、ゆっくり動くロボットなら行動制御は出来そうなのがわかりました。（えー！これでロボット作るの？）

秋月のXBeeをシリアルケーブル代わりに使うには

久しぶりのウィークエンドですが、ちょっと素朴なテーマを取り上げました。

「管理人」のほうでやっているTiny-BASICコンピュータは、シリアルでパソコンのターミナルソフトに接続して使うようになっています。これをXBeeで無線化しようというときに起こった問題と解決法をまとめます。

XBeeはすでに「猫のぞきカメラ」で実用的に使っていたので、その設定のままシリアルケーブル代わりに接続したのですが、うまく行きません。

試作したTiny-BASICは、ターミナルから送られた文字を、そのままエコーバックするようになっています。こうすると、通信系統の健常性がオペレータにわかり易いからです。

タイプすると最初の実験の「ループバックの調子が悪い」と同じ現象が発生し、使い物になりません。

仮ソフトを組んで調べてみると、END DEVICE（外部機器のXBee）からのデータ送信は、/CTSでのフロー制御をきちんとやれば、何千バイト送っても問題ないのですが、ブロードキャストに設定しているCOORDINATOR（PC側のXBee）からは80バイトくらい送信すると、それ以上データが送信されないという現象が確認できました。エコーバックが返ってこなくなるのです。無視して送り続けるとデータがロストします。フロー制御をしているはずなのにダメです。その後、２秒程おくと、また80バイトの送信が出来るようになります。

またXBeeの仕様書に戻って原因究明したのですが…　この仕様書はちょっとふんわりした感じで、知りたいことがダイレクトに見つからないんですねえ。英文なので斜め読みが難しいのも問題です。

とにかく、大づかみにしたのは下記です。
１・メッシュネットワークに採用されているZigBeeプロトコルの問題らしい
２・COORDINATORだかららしい
３・「80バイト」程は「RF payload」、つまりいっぺんに電波に乗せられるデータ量に近い
４・「２秒」程はデフォルトのSD、「Scan Duration」つまりネットワークから情報を集める時間に近い
まとめると、「ブロードキャストのCOORDINATORは、１回RFパケットを送信する度にSD時間分ネットワークに耳を澄ます」ということでは無いかと思われます。

試作したXBeeカメラでは、COORDINATORからはわずか1バイトのコマンドを送信するだけだったので、この設定で問題なかったようです。

そういうわけで、ブロードキャストをやめてユニキャストに設定したら、送受とも問題なく転送できるようになりました。この設定を図にしたものがこれです。

ディスネーションには、お互いのシリアル番号(MACアドレス)を入力します。XBeeと機器のシリアル速度は、2台のXBeeで異なっていても、フロー制御をしていれば問題ないようです。
フロー制御は次のようにします。
■マイコンの場合：１バイト送信する前に/CTSをチェック。Lなら送信、HならLになるまで待つ。
■PCの場合：FlowControlをHardWareに設定。

このようにすれば、シリアルケーブルを単純にXBeeで置き換えることが出来ます。ただし、通信速度は9600bpsくらいですが。

PICで走るTiny-BASIC（拾遺）

BASICという「死語」のこと
前回の投稿でBASICの悪口を書いてしまいましたが…　変人で堅物の花岡数子も、見方を変えれば恋する乙女だったように、視点を変えればいいところもあります。

それは、「プログラム初心者が思った通りに書ける」ということでしょう。
まっさらなファイルに実行順に命令を書き込んで行くだけ。条件によってやらなければイケナイことが出てきたら、GOTOで別の処理に飛ばす。と、いうきわめて素朴な作業でプログラムが完成します。

また、以前子供にプログラムを教える機会がありましたが、Cのように文法以外の約束事があるものは、初心者や子供にはちょっと抵抗があるようです。
スコープやインクルードファイルや独特の式の表記などなどを、頭ごなし（もちろんまっとうな理由はあるんですが、説明が大変なので！）に「こういうもんですよ」と言われても、「なんで？」というモヤモヤが残ってしまうみたいです。モヤモヤがあるがゆえ、うまく動かない時に、自分の書いたプログラムではなく、その辺を疑ってしまう傾向が見られました。

その点、BASICはキカイ寄りで「この命令を書くとコンピュータはこう動く」というわかり易い約束事だけです。そういうモヤモヤは少ないと思います。

小学生や中学生がプログラムに触れる最初のものとしては、良いのかも知れません。でも、大人の入門用には未来が無いのでお薦めしませんが。

クロックアップのこと
PIC16F886に20MHzの水晶を外付けし、修正したソフトを書けば、20MHzにクロックアップできます。これで2.5倍速になります。
クロックアップしたhexファイルはこれです。PicKit2で書き込めばOKです。（水晶をお忘れなく）

「HBV04_20M.hex」をダウンロード

16F88Xのデータシートによれば、20MHzで動作させる時は電源電圧を4.5V-以上(P246)にしなければなりませんが…　3Vでも十分に動作します。手持ちの５個をテストしましたが問題ありませんでした。また、データシートでは水晶発振回路に抵抗とコンデンサが入ってますが、水晶だけ付ければ一応動作します。特にコンデンサは、変な値のものを付けると周波数が狂ったりするので、アマチュア的には付けない方がいいかも知れません。

俺BASICマシンのこと
僕は古いプラモを集めていますが、そんなマニアの中には、SFプラモ風のオリジナル作品を作っている人も居ます。モグラスやバンガード、アトラスといった有名どころ（ご存知？）のSF戦車なんかを、「俺○○」という形でスクラッチするわけですね。
これに倣って、あの頃憧れていたAppleやMZ-80をモチーフにしたオリジナル作品を作るのも面白いのではないでしょうか。「俺BASICマシン」というわけです。
僕の作品のモチーフは60年代の汎用コンピュータ（に憧れて作った自作機）です。コンソールに雰囲気があるのではと思っています。