車両型ロボット(Ｗ６)の製作日誌　その３

ボールが床に落とす影からボールを認識する様に、ライントレース用のサブルーチンを 調整しました。

−−−＞

左の画像が元の画像で、右が処理後の画像です。灰色の部分が「ボールの影」として認識 した部分です。（小さい黒丸は図形の重心です。) 影と大体同じ大きさの、丸くて黒い紙もフレームに入っていますが、これも 「ボールの影」判定が出ています。大きさと形が近ければ、この様に立体物も、床の模様にも 同じ判定が出ます。

でも、ここまで来ると、物の大きさと、ロボットとの位置関係が分かっているので、距離センサでスキャンして 立体かどうか確認できます。

試しに「線の上に乗る」部分のプログラムまで実行してみました。上の検出結果によって 計算どおりにロボットが動けば、ボールを少し押してから止まるはずですが、頭の方向 、画像からのボールの位置の取り出し、指定位置への走行など、それぞれの段階の誤差が 重なってか、少し押したり、手前で止まったりといろいろでした。

そのまま、以前作った正面にあるボールを腕で拾う動作を実行してみると、うまく拾えるときも ありました。ボールをロボットの正面に導くようなガイドをつけてしまえば終わりのような 気もしましたが、これだけのセンサーと、自由度の多いボディーがある意味がなくなってしまうので、 ここはやはり、ハードを生かすソフトを書きたいと思います。

スポンジボールに手が届く様な位置まで来た後で、ロボットの位置の微調整が必要かどうかや、 どの辺に手を伸ばせば良いかを決めるための情報取得に使うプログラムを書いています。

少し前に、３６０度スキャンのプログラムを書きましたが、同じ要領で、ロボット前の床面の、 ロボット前面からの距離にして５ｃｍから１０ｃｍ程度の辺りをスキャンします。 そして、取得したデータからボールがどの辺りにあるかを判断します。

３６０度サーチの時は、取得したデータはレーダーチャートになりますが、こちらは下に示す 図のようなグラフになるので、山の位置からボールの中心位置を判断し、ロボット位置値の 微調整のためのデータや、手を伸ばす目標位置を計算します。

ギアボックスが移動ユニットＴＹＰＥ２の裏面に付いていますが、普段持ち運びの時に、 ついギアを触ってしまったり、ホコリがつき易かったりと少々不便だったので、覆いを 付けました。

腰の関節には、上半身の重量を支えるために４個のローラーが付いています。このローラーは 高さの精度が出ていないので、いつも２個、もしくは３個で上半身を支えていました。 浮いているローラーがあるため、ロボットが自分で動いているぶんには支障ないのですが、 手で持つ時にグラグラと動き、気になっていました。

今回は、これをローラーを３個に減らすことによって改善しました。ロボットの重量の割りに ボディーの剛性が低いため、やはりグラグラしますが、前よりだいぶ良くなりました。

画像を利用して、ボールを捜し、近づいて拾い上げるプログラムがひとまず動きました。 今までに作ったプログラムの組み合わせで出来ています。2004.05.02のところから書いていた 「最終アプローチ」の部分は新しいプログラムです。今回のアルゴリズムは以下のとおりです。 画像処理や、ボールとの位置関係の計算などはＰＣでやっています。
１．頭を適当な方向に向ける。
２．明るさをCdsで測定し、カメラに露出データをロードする。
３．右目(カメラ)で撮影し、画像をＰＣへ転送する。

＜撮影した画像＞

４．画像を処理し、ボールを見つける。

＜処理後の画像＞

５．ボールとロボットの相対位置および、移動距離と方向を画像から計算する。
６．計画のとおりに移動する。
７．ロボットの足元を赤外線距離センサ（ＰＳＤセンサ）でスキャンする。
８．ボールの場所をレーダーチャートから特定する。

＜レーダーチャート＞

９．ボールが正面に来るように旋回する。
１０．腕を広げる。（予め作ってメモリに入れてあるアクションデータ使用）
１１．ボールを挟むまで腕を閉じてゆく（手先のタッチセンサで挟んだかどうか判断）
１２．持ち上げる。


ソフトウェアの機能要素を統合してゆく形の製作は、ひと段落した気がするので、今後しばらく は、機能要素の開発やハードの機能拡張、使ったことが無い部品のトライなどをしようかと 思いました。

ボールの認識のテストをしていて、時々「何でこの良い位置で見逃すかな〜」みたいな ことがありました。処理前画像と処理後画像を見てみると、移動ユニットと頭部ユニットの 両方のセンサのＬＥＤがちょうどボールの影の部分を照らしているため、うまく認識できなかった 様だと分かりました。

そこで、ＰＳＤセンサの電源系統にリレーを入れて、ＯＮ／ＯＦＦ出来る様にしました。 使ったリレーはOKITAのDIP-1M-05Dという、14PのDIPパッケージサイズのリレーで、Ｈ８の ポートから直接駆動できるものです。Ｗ１〜Ｗ４の余りの部品です。 購入してからずいぶん時間がたちますが、使えました。また、データシートのダウンロード も出来たので、まだ売っている様です。

Ｗ６ｖ３は何もしない状態で約7.2V・0.6A使っていますが、PSDを切り離すと7.2V・0.4Aに 下がるので、電池の持ちが良くなると期待してます。

あと、ついでに、ＰＳＤセンサの作動状態が分かるように、移動ユニット前面に、ＰＳＤセンサ と一緒にＯＮになる、点滅回路入りの緑色ＬＥＤを付けました。

画像の転送が、あまりに遅いので、差しさわりの無い範囲ということで、シリアル通信速度を 19200bpsから38400bpsにアップしました。これでも遅いので、LAN接続に 変えようかなーという気が沸いてきました。

• ボールを拾えるような、手が届く範囲が思ったよりも狭かった
  ロボットとボールが触る位置は、移動ユニットとアームが干渉するので拾えませんでした。 ムービーの位置から数センチの範囲が大体いいところでした。
  しかし、到達範囲も自由度も低いアームですが、移動ロボットにペアで付いていれば、 けっこういろいろと使えそうだと思いました。「作業移動ロボット」の 論文の緒言に、なんとなく納得しました。

• ボールの拾い易い面と、拾いにくい面
  ボールはどの方向から見ても、陰の付き方の差はありますが、同じ形に見えるので認識が 易しくなります。また、どの方向からつかんでも同じようにつかめるので、アプローチに 工夫が要りません。ただ、中心を通るように挟まないと、うまく持ち上がりません。 そして、ラフなつかみ方をすると、転がっていってしまいます。
  アプローチのプログラムにバグがあった時は、何回やっても、手の間には入るのですが、 持ち上げられませんでした。

• 6V/700mAhのNiMH電池でＷ６ｖ３を動かしてみる・・・
  一応動くことは動くのですが、ボールを持ったりして、消費電力が高い状態になると、 先にDC/DCコンバータの系統の電圧が下がり、RCサーボが電圧不足で震えだしました。 やはり7.2Vの電池くらいが必要なようです。

• 太陽電池でH8マザーボードを動かしてみる・・・
  秋月のH8/3048用マザーボードを、やはり秋月で売っている、1枚2Vの太陽電池を４枚 直列につないだ電源で動かしてみました。日向に電池を出しておけば動きましたが、 日陰ではダメでした。
  
  

今向いている方向に移動する

2003.09.28に書いた「磁気コンパスによる進路保持」のプログラムを発展させました。 しくみは、例えば「出力が”北”のときは進路を右に、”北東”のときは進路を左に というようにして蛇行すれば、結果的に北北東に向かって移動する」というものです。

去年のプログラムと違うのは、移動を始める前に、磁気コンパスが付いている頭を、 出力がちょうど方位データの変わり目になるように回しておく点です。 こうすると、その変わり目をまたぐように蛇行すれば、今向いている方向に進みます。

次は地磁気に対する絶対方位を入力して、そちらに移動するプログラムを作ろうかと 思っています。これが使えると、部屋の中でのナビゲーションがＷ４の時と比べて 格段に楽になると思います。

制御の精度は、方位を角度で言って、ざっと数度程度といった感じです。問題は、 今試している、自室以外の場所でも同程度の性能を発揮するのかですが、それは おいおい試してみようと思っています。

「磁気コンパスによる進路保持」を自分の部屋の外で試した時、 移動速度の遅さがどうにも気になりだしたので、速度アップを図ることにしました。 具体的には、ギア比を505.9:1から196.7:1に変更することによって速度を変えました。 なかなか良い感じです。ちなみに、今使っているギアボックスは、元々６段階に ギア比を変えられるものなので、歯車の入れ替えをするだけで簡単に変更できました。

カメラの軸あわせ

立体視を試すにあたり、左右のカメラの取り付け角度のズレを微調整出来るように、 カメラのマウント部分を頭の外装と別パーツにして、角度を調整しました。

今まで、左のカメラで撮影した画像が数度ほど傾いていましたが、これで調整が つきました。ずっと気になっていたのでスッキリしました。

Ｗ６よりも一回り小さい同タイプのロボット、動力性能アップのための実験、デジカメつきの ラジコンボート等に使うことを念頭において、Ｗ６の移動ユニットＴｙｐｅ２のマイコンボード と２Ｌ２のマイコンボードの仕様を混ぜたようなマイコンボードを作り始めました。 （RCサーボ、マブチモーター、ジャイロ、RC受信機etc.を接続します。）

先ずこのボードが出来上がったら、ラジコンのセグウェイみたいなものを作ってみようかと 思っています。（カットアンドトライだけでやってみようと思っているので、うまく行かない 可能性大です。）

私の場合、新しく同タイプのものを作る時は、前の作品をバラして （保管場所、材料費、製作時間の節約のため）材料として使ってしまうのが常ですが 、Ｗ６の後継機は、Ｗ６を使わないで、独立したもの として作ろうかと考えています。

ボードが出来たので、有り合わせで倒立振子みたいなものを作ってみました。ソフトとハード の部品は、今まで使ったことがあるものばかりなので、簡単に組みあがりました。 倒立させるための制御プログラムが新しい部分ということになります。

（この安っぽさがなんともいえず、いい感じです・・・）

ムービーのダウンロード（120kByte)

「倒立振子の制御ってこんなだったよなー」と、おぼろげな記憶をたよりに、いいかげんな 制御プログラムを書いて動かしてみました。なんか、それっぽく動きはしますが、すぐに たおれました。モーター、ギアボックス、電池、モータードライバＩＣなど、秒単位の短い時間で動かすぶんには 、加熱などの異常はないようなので、ハードとしては遊べるものが出来たみたいです。

マイコンと電池を内蔵し、搭載マイコンのみで制御しています。また、ＲＣ受信機も積んでい ますので、ＰＣから切り離して、プロポからスタートをかけたりも出来ますが、ムービーでは プログラムのロード用の通信ケーブルの抜き差しが面倒なので、ケーブルを引っ張りながら 動いています。

電池の構成は２Ｌ１／２Ｌ２と同じで、制御系等がハンディーカム用の7.2V Li-Ion電池で、動力系が 6VのNi-MH電池です。

センサーはＰＧ０３（ＲＣジャイロ）とＡＤＸＬ２０２を１個づつ積んでいます。 今日のところはＰＧ０３だけ使っています。

加速度センサー（ＡＤＸＬ２０２）を読む部分のプログラムを書き足して、静止状態に 近い時、重力の方向から、傾きを求められるようにしました。

任意の傾斜状態で自由落下している状態と、 センサーを地面に対して水平にし、静止している状態の出力が一緒であるのと同じ理由で、 動力を切った状態で、自然に倒れている時等は、加速度センサーから傾斜を求めることが出来ません。 といった理由で、 ジャイロからの角速度情報が一定以下の時だけ、加速度センサーを有効にしました。

先週よりも安定が良くなったので、ＲＣで動かせる錘を載せるなどすれば、操縦できそうだと 思いました。

先週は、動力系統の電圧を安定化しないで動かしていましたが、それだと、電池の残量 に依存して、制御のゲインが変わってくる等不都合がありました。そこで、大体動くことが確認 出来たので、より運動の安定化を高めるため、動力系統にDC/DCコンバータ（Ｗ６と一緒の型） を入れました。また、軽量化のため、電池を7.2V 700mA/hのNi-MH　１個にまとめました。

錘を動かす方法と、加速度センサーの中立位置をずらす方法を試しました。 錘の方は、錘を動かし始める時の反作用と、動き終わった後の重心変化を読みきれず、 操縦不能に近い感じでしたが、中立位置をずらす方は、まあ働きました。

はじめは、どこを見て操縦すればいいか分からず、すぐに倒れてしまいましたが、 何回か試してコツがつかめてくると、「バランスゲーム」といった感じで、なんとなく 操縦できるようになって来ました。テレビでなどで見た車輪型の倒立振子は、もっと ずっと安定良く動いていたので、もっと安定が 良くなるはずなんだろうと思いましたが、これはこれで面白いと思いました。

操縦といえば、ずっとラジコンで遊んでいた経験から言って、かなり「慣れ」というか「練習」 の要素が絡んで来ると思います。なので、どの辺りで「これは操縦不能だ！」と判断するか 微妙だと思いました。

また、どの程度不安定にしておくのが、操縦して面白いおもちゃになるのか、 さじ加減が難しいところだと思いました。

ムービーのダウンロード（343kByte)

相撲ロボットの競技に、車輪型倒立振子クラスを作ったら、面白そうだと思いました。

2004.06.27の更新では写真が無かったので追加します。



ＤＣ／ＤＣコンバータの取り説に指定があるので、今回初めて 「ＯＳコン（有機半導体アルミ電解コンデンサ）」を使いました。いやーずいぶん単価の高い コンデンサです。

ちなみに、今Ｗ６に積んである電源ユニットは、組み立てた時にＯＳコンの入手先が分からな かったので、ＯＳコンの数倍の容量の「高周波低インピーダンス型アルミ電解コンデンサ」 を付けています。（このＯＳコンはＲＳコンポーネンツで買いました。）

スキャンの結果得られたレーダーチャートから、まっすぐな「壁」を認識するプログラムを 書きました。隣接する３点を線で結んで、間の点の角度を求め、この角度の大小や、その３点 に隣接する３点との関係などを評価して、壁を探します。 認識した結果は、部屋の中での自己位置推定などに使用します。



緑の線は赤外線センサのチャート、青の線は超音波センサのチャートです。 青い丸のマークは、壁と思われる場所。赤いマークは測定結果が怪しい場所です。 この測定では、超音波センサの方から、４箇所の「壁｣データが取れました。

赤外線センサのレンジ内ならば、超音波センサのチャートと突合せて、超音波センサ の方で「壁」と認識した部分の性質がより明確になります。例えば、超音波センサは、赤外線センサ とくらべて分解能が低いので、家具の隙間の入り口等では戻ってきます。一方赤外線センサ の方はそのまま奥まで届きます。こんな感じの差が「赤マーク」の所に出ています。

「壁｣が認識結果の境界の先まで続いている時は、超音波が一定以下の角度で壁に入射した時 にエコーが返らない性質から、レンジオーバーになります。それが画面の下に、青い線が 飛び出している部分です。

といった要領で情報を取り出して行きます。Ｗ２〜Ｗ４で遊んでいた数年間は、 この辺を主にやっていました。そんなわけで、幾何計算の関数は、書いてから１０年くらい たつものを使いました。（我ながら、飽きないものだと思います）壁と思われる「点」を、まとめて「線」に する部分は、画像処理の方で、２値化された後のデータから、エリアをまとめる時に 使ったアルゴリズムを使いました。

先週からの継続です。「壁がありそう」と判定された測定結果から、連続した「壁｣ として、点列をグループ化する部分のプログラムを書きました。



太いピンクが「壁」として取り出された｣データで、始点・終点やIDなどが、関数から 返ってきます。

画面と、実際のロボットの状態を見比べて見ると、壁の方向が実際と１０度程度 違っています。 腰と首のRCサーボの制御の誤差がそのまま出ている様です。画像から距離を割り出す時も そうですが、RCサーボの位置制御の正確さが、測定結果にダイレクトに反映されます。 今のところ、RCサーボの制御入力と、実際の角度の調整が甘い状態なので、そろそろ 面倒だけれども、校正をやろうかと考えています。

あと、一歩進めて、腰と首の RCサーボはSX-101からERG-WRX等、手元にストックがあるデジタルサーボに交換して 精度を高めようかなどとも思っています。

「壁に沿って走る」時の参考に、３６０度スキャンの結果を使おうとするような時は、 今のままでも、まあ何とかなるのですが、画像認識で何か拾おうとする時など、 目標の距離と方向の測定が甘いと、腕が 空振りするので、そちらの方からもデジタルサーボ化を考えています。

「壁｣として認識された場所に交差している距離測定結果を、除き、ロボットの大きさ を考慮に入れて、それぞれの方向に移動可能な距離を求めました。 図の中で、中心から放射状に伸びている青い線が、走行可能と判断された各方向の距離です。



距離センサーを回転させながら測定すると、まっすぐな壁は、壁に対して浅い角度で入射した 超音波が、ロボットの方に返ってこないことから、ごく一部しか取り出せません。 そこで、壁は認識できた始点・終点の先にずっと続いているものとして処理しています。

この例では、図の中で右上に突き出している部分は実際は壁なので、正しく走行不可能エリア として除外されています。

Ｗ６を自律動作させているときに、Ｗ６の動作状況をモニタするため、無線モジュールを 載せました。通信はＷ６からＰＣへの単方向で、４８００ｂｐｓでシリアル通信します。

主な用途は、Ｗ６がどう判断して動いているかを、ターミナルソフトにテキストで表示して、 プログラムのデバグに役立てようとするものです。

載せた無線モジュールは、ＩＰＩの通販で、１年？くらい前に買ったFM-RTF-Q1-433とFM-RRF-Q1-433という 433.92MHzでFM方式のモジュールで、イギリスのメーカーによるものの様です。Ｗ６側ではメインＣＰＵのSCI2に接続しています。 ROBO-ONEでかづひさんにWeird-7を見せてもらった後「似たような無線モジュールないかなー」と探して買ったものです。

取説によると、最高40Kbit/Sで室内７５ｍ、屋外３００ｍ通信可能とあります。Ｗ６には 十分な性能に感じます。

2004.08.01の所で書いた無線モジュールの外見に関する説明です。写真をクリックすると大きな写真が見られます。

	送信モジュール メインCPUのIOボードの一番手前の基板が送信モジュールのFM-RTF-Q1-433です。 （背中にRTFQ1等と書いてあるのが見えます）IOボードから 伸びている黒いビニール線はアンテナです。
	受信モジュール 一番奥に立っている基板が受信モジュールのFM-RRF-Q1-433です。その他には３端子レギュレータ の78L05、レベル変換ICのADM232、そして汎用ロジックICの74HC04等が付いています。水色の 物は7.2V 700mAhのNiMH電池です。右側に見えるD-SUBコネクタをPCのシリアルポートにつないで 使います。

モーターへの通電時間で移動に関する制御を行っていましたが、やはり、精度が良くありません。 視覚をはじめ、ナビゲーションに使えるセンサーがいろいろ付いているので、精度が良くなくても、 なんとかなると言えばなるのですが、移動の精度が高い方がその他のプログラムが簡単になるので、 移動ユニットＴＹＰＥ１と同じような、光学式のエンコーダを付けました。

移動ユニット裏面

エンコーダの読み取りはTCLK-BとTCLK-Cから入力してITU0とITU1で行おうと試したのですが、 信号の立ち上がり／下がりが遅いところに、モーターのノイズがのってくるため、スレッショルド 近辺でたくさんカウントされてしまう様で「手で車輪を動かしている時は正常にカウントされるのに、 モーターで走るとダメ」という結果でした。（入力のLOWレベル電圧が、約0.8Vと、高いのも、原因 かもしれません。）

Ｗ２、Ｗ３そしてＷ４では、ローパスフィルタ とシュミットトリガ入力のゲートICを通してからバイナリカウンタへ入れていましたが、同じ部品の ストックが無かったので、PAポートから、約２ｍ秒間隔で読み取ることによって、ローパス フィルタの代わりにしました。これで動いたので、支障が出るまでこのまま使おうと思います。 ＣＰＵの無駄使いですが、どのみち、今のところは遊んでいる時間 が多いので良しとしました。

１年くらい前に、東急ハンズ渋谷店で「バキュームプレッサー　桃象」を衝動買いしてしまいました。 どうせ１つしか作らないものに「型」を準備するのに気分がのらず、そのままになっていましたが、 １回使ってみよう・・・と準備を始めました。

複雑な形を作っても、なかなかうまく成型出来ないだろうと思い、簡単な形ということで 車輪のカバーを作ってみることにしました。型製作の時間節約のため、左用、右用で共用できる型を 作っています。型の材質は「ラドール」という、フィギュア製作で使い慣れている、石粉粘土 を使っています。

これができたら、腕のアルミがむき出しになっている部分のカバーを作ろうかと思っています。 そして、要領が分かってきたら、「顔」なんか作ってみたらどうかとも考えているところです。

型が出来たので、成型してみました。出来は・・・まーこんな物でしょう。 ちょっと、ロボット全体の形のナゲヤリさが薄れて良くなったと思いました。

	作業全景 こんな感じで作業しました。桃象の右の透明の物は、タイヤとの隙間確認のために 、試しに透明塩ビ板で成型した試作品です。バキュームフォームのやり方は、普通のやり方です。 ネットで比較的簡単に、ステップ・バイ・ステップでやり方を解説しているＨＰを 見つけられたので、ここではやり方の解説は省略します。
	仕上がり タイヤに１９５０年代？のクラシックカー風のカバーをつけました。手前に写っているものが 「型」です。「ラドール」は乾燥すると石膏のような感じになります。型は、粘土を こねて形にする−＞カーッターナイフで削って形を整える−＞棒ヤスリで削って形を整える−＞ 紙ヤスリで削って形を整えるといった工程で製作します。

「2004.09.05」のところで取り付けた、車輪のエンコーダを使って走るためのソフトを、 Ｎｏ．１サブＣＰＵ用に書きました。目的は、直進、走行距離や方向転換時の制御精度アップです。

エンコーダの１カウントの移動距離が約７．６ｍｍ、車輪の間隔が約１５３ｍｍなので、 信地旋回をした場合の、制御精度は最高で３度以内程度ということになります。 あんまり良くないです。

カウント値を同期させることによる直進性能のアップは、６畳くらいの部屋で動かしている 分には「十分に直進に見える」感じでした。ただ、左右のエンコーダの位置関係、 起動電流の違い、キャスターの向き、ギアボックスのバックラッシュの状態の違い など幾つか原因は考えられますが、 走行開始の瞬間に進路がそれることが時々ありました。

走行プログラムが改善されたところで、「2004.05.16」頃に作った、「床の上のボールを拾う」 動作の走行に関する部分を新しいプログラムと差し換えて動かしてみました。同時に、腕を 動かすスピードなども少し上げてみました。

ボールへのアプローチの精度は以前とそれほど変わらず期待はずれでした。でもまあ、走行速度 そのものを「2004.06.06」のところで倍にした点と、腕等ＲＣサーボの動作スピード変更で、以前 約３０秒かかっていたものが２０秒程度まで短くなりました。ボールに手が届くところまで移動した 後、拾うために、狙いをつける動作に時間を取られているので、次の改善ポイントはココです。

いつも使っているデジカメは１５秒までしか動画を撮影できないので、１４秒以内で動作完了 するように、もう少し工夫したいと思います。

部屋の中における自己位置推定用のランドマークとして、蛍光灯を使おうと、プログラムを 作り始めました。いつもＷ６を動かしている部屋は、照明として、天井に蛍光灯が１本と、 机のゼットライトがあるだけなので、天井を見上げて、蛍光灯がどういうふうに見えるかと、 磁気コンパスの情報を合わせれば、部屋の中のどこにいるかが計算できると思い、作り始めました。

先ず試しに、蛍光灯を撮影した後、画像をネガポジ反転すれば、天井に描かれた線として、 ライントレース用のプログラムで認識できないか試してみました。

--> -->

あっけなくラインとして認識できました。あとは、画像に写っているものと、ロボットとの 位置関係を計算する関数の中で、ロボットとラインが書かれている平面 との位置関係を、変更するだけです。まだあまりいろいろな条件で試していませんが、 蛍光灯の真下に移動するプログラムを動かしてみたところ、それらしい位置に行くので、 位置関係の割り出し計算は、だいたい良いみたいです。

お手軽でいいですね。

いちおう、思いつくところのハードを付けるだけつけ、それぞれのハードへのＩ／Ｏ の関数なども落ち着いてきたので、各ＣＰＵへの通信プロトコルの整理を始めました。

具体的には、例えばＲＣサーボを動かすコマンドは、作ったときは、メインＣＰＵ もしくはＰＣからキャラクタの"A"を始めに送り、No.2の受け取り準備が整った頃 を見計らって（約40m sec待って）関節番号と角度データを送る様にしていましたが、 No.2サブＣＰＵから明確に「受け取り準備完了」のサイン（実際にはコマンドキャラクタの エコーバック）を受けて、データ送信にかかるような方式に変更しました。

最近作った、上位のＣＰＵから見て出力系のコマンドは、大体エコーバックがありますが 、古いコマンドには無かったりしたので、この辺りを整理しています。 その他、画像の取得のように、一定のバイト数のデータが送られてくれば、コマンドに 対する動作が終了したとみなせる入力系のコマンドにも、エコーバックがあったりしたので これも「コマンドキャラクターのエコーバック無し」に統一する方向で直しています。

「通信プロトコルの整理」も終わり、その他広範囲にわたるソフトの手入れも済んだので、 「スポンジボールを拾う」ムービーを再撮影しました。まだまだのろい動きですが、前に 比べればだいぶ早くなりました。

以前、動物の番組（アッテンボローの何とかいうやつ？）を見ていて、めまぐるしく木から木へ 飛び移るザルを指し、「このサルは大変目が良いので早く動ける」といったようなことを 言っていましたが、目が良くないせいで動作が大変のろいＷ６を作りながら、まったくもって 良い目（視覚の処理能力まで含めて）が、すばやい動きへの一つのキーだと思いました。

温度センサーを搭載しました。搭載場所は、頭部で外気温度を計測します。 センサーの機種は石塚電子製の AT502-1という使用温度範囲が−５０度から１０５度のサーミスタです。 実際に計測する範囲は、Ｗ６がシステム全体として耐えられると思う０度から６０度 の範囲と決めて、センサーのデータシートの温度と抵抗値の表から、回帰計算で２次の 多項式を出して、プログラムに組み込みました。

サーミスタというものを初めて使いましたが、精度のことをあまり気にしなければ、 接続は簡単だったので、モーターとかバッテリーとかの温度も計測しようかと思いました。 インターネット経由など、ロボットを身近に置かないで動かそうとした時には、こういった 情報も、ロボットの状態を知る手がかりとして役立ちそうだと思いました。

ボールを拾うとき、アプローチ完了後に足元をスキャンしますが、ＰＳＤの場合は頭を 止めて測定しなくても、それほど測定結果に影響しないので、止めずにスキャンする様に 変えました。また、この機会に、スキャンの関数がバラバラあったのを、統合しました。

2004.10.03のところで試している「蛍光灯をランドマークとして利用する」自己位置推定 のプログラム（といっても、ただの画像を使った三角測量のプログラムですが） を、使えるようにしました。具体的には、視野に蛍光灯の一部しか入らない場合 に、首を動かして、より多く視野に入るようにして再撮影したり、視野に入りきっていない 端の位置を計算で求めたり、磁気コンパスの情報と合わせて、撮影した蛍光灯のイメージの 南北はどちらかを判断したりといった部分を書き足しました。

このプログラムによって、いつもＷ６を動かしている部屋 （蛍光灯の下にＷ６が移動できる床面積が３畳くらいある） では、±５０ｍｍ位の精度で、蛍光灯の真ん中を床に投影した位置を座標原点、 南側の端をＸ軸の正の向きとして、部屋に対する絶対位置が求められるようになり、 走り回った後でも、部屋の中の決まった位置に帰ってこられるようになりました。

次は、部屋の中でスポンジボールを捜すプログラム、ボールを拾うプログラムと組み合わせて 、床に散乱しているボールを拾い集めて、部屋の特定の位置（座標を予めロボットに与えておく） に置いた箱に集められるようにしようかと、機能の統合テストを始めましたが、とんでもない 自己位置データが出てくるときがあり、まだバグつぶしに時間がかかりそうです。

蛍光灯のルーチンがだいたいまともになってきたので、「ボールの拾い集め」に向けて 簡単なケースからプログラムを作り始めました。今回は、部屋座標（０，０）近辺に ボールを１つ、そして、ゴールとして部屋座標（９００，１００）にプラモの箱を 置いておきました。そして、ロボットは蛍光灯が見える適当な場所からスタートします。 プロセスは、初めに自分の位置を所得したあと、部屋座標（０，０）の辺りを見て ボールを拾い、プラモの箱にボールを入れるというのをやりました。

一定の誤差はあるとしても、ロボットの絶対座標が取れるようになったので、地図情報 を持たせるべく、データ構造の検討を始めました。ひとまずはＷ４で使っていた地図 データベースのデータ構造をスタート地点として始めようと思っています。

色々な要因（例えば移動中に予期しない障害物に出会ったとか、ボールを搬送中に落としたとか 、蛍光灯が視野に入っていないとか・・・） で、処理が中断した時のエラートラップルーチンなどを整備しながら プログラムを書き進めています。 プログラムのテストの課題は2004.11.14のままですが、だいぶよく動くようになって来ました。

部屋の絶対座標、ロボットから見た座標、移動の時の方向の与え方、首と腰の０方向、 ラジアンと度の変数があることなどなど、 座標系に関する計算で”はまる”ケースが多くなってきたので、プログラム全体を通して なるべく間違えにくくなるように変数や引数を整理しようと思い始めました。

ボール拾いの成功率アップのため以下の対策をとりました。

• スキャンのリトライ
  画像からの位置計測の精度が良くないために、しばし、接近してみたあとで、ボールまで まだ距離がある場合があります。そこで、完全に手が届く位置をスキャンして見つからなかった 場合は、３ｃｍと６ｃｍほど先をスキャンしなおすようにしました。

• センサーの幾何データ折込
  あたまのＰＳＤから出る赤外線のスポットの位置を計測して、スキャン結果からボールの 位置を求めるプログラムに反映しました。これで、ＰＳＤセンサーのＬＥＤが、頭の 中心線からオフセットしている分を反映できたので、手の狙いがより正確になり、空振り の回数が減りました。

• 手のゴム
  より確実にホールドするため、手にゴムを張りました。右手の甲側が厚さ５ｍｍの スポンジゴムで、左手の掌側が厚さ１ｍｍの板ゴムです。２足ロボの足の裏や魚ロボ のヒレに使うために １０種類くらい買ってストックしてあった材料を使いました。（ゴムの種類はネオプレンゴムとか 、クロロプレンゴムとか、天然ゴムとかいろいろあるのですが、どれがどれだか書いて おかなかったので、分からな い状態のため種類が書けません。すみません。）

• バンパー
  ボールに近づきすぎて拾えなくなるのを防ぐため、針金で昔のラジコンカーのバンパー の様なものを作って付けました。

地図データベースの実装がまだなので、簡単に、「部屋の真ん中の辺りから周囲を見回し、 見つけ次第、集積ポイントまで持っていく」というプログラムで動かしてみました。

ところで、いつものスポンジボールの場合、昼間は外からの光で下に濃い影が出来ないので、 今使っている画像認識ルーチンでは見つけられません。そこで今回は、黒いスポンジのブロックを 拾い集める対象として動かしました。

じっと動かない時間が長いですが、動かない時は、ＰＣに画像を送っています。 今は、仕組みを作ることに注力しているので気にしないことにしていますが、改善したいです。
上を向いている時は、天井の蛍光灯を見て、自分の位置を計算しています。床にビニールテープで Ｘ，Ｙ軸が書いてあるのが写っていますが、ここが、蛍光灯の中央の真下で、「部屋」の 座標原点（０，０）にしている場所です。部屋を見回すための位置（３００，３００）や 集積ポイント（９００、５０）はここからの距離としてプログラム中に記述されています。

こういうマークを床に描くなら、こっちを見ても良いのですが、まあ、今回は「蛍光灯を ランドマークに使う」ということをテーマにしていますので、見ていません。プログラムの デバグの時に、ロボットの場所をメジャーで測るために使っているだけです。

先週のムービーを見ながら、ストップウォッチで「撮影時間」「画像の転送時間」「走行時間」 「近距離スキャンの時間」など別々に計り、どうしたら時間短縮につながるか考えてみました。

やはり、ムービーの時間の内、画像をPCに転送する時間が半分近くを占めています。これを 改善するにはどうしたら良いか考えると、単純に、転送しなくて済むように、すべてW6内臓の メインＣＰＵでローカルに行う方法と、ＬＡＮ接続やＵＳＢ接続に変えて通信スピードを上げる方法 が思いつきました。（撮影回数が減るようにアルゴリズムを工夫というのもありますが、気持ちと しては、もっと撮影回数を増やしたいので・・・）

ローカルに行う方法を考えたところ、以前、動くもののトラッキングをメインＣＰＵでやった 時の事を思い出し、今ＰＣで動かしているプログラムをメインＣＰＵに移植することは、 ＲＡＭの容量や、Ｃ言語の移植性を考えると可能ではあるけれども、結局６秒以内（転送の 所要時間）に画像認識が完了せず、今のメインＣＰＵでは結局スピードダウンになる可能性が あると思いました。そんなわけで、死蔵状態のアルファプロジェクト製 ＳＨ３ボードの復活に思いが向かいました。

また、通信方式を変えるとしても、メインＣＰＵ基板の変更になるので、どっちにしても 時間短縮にはメインＣＰＵのハードをさわるしか無さそうだと思いました。

どうも、カメラを使っての自己位置や、ボール等までの距離を割り出す時の誤差の、少なくない 割合が、腰と首の角度制御の誤差から来ている様な気がします。そこで、それを確かめるべく 腰と首のＲＣサーボをＳＸ−１０１ＺからＥＲＧ−ＷＲ（腰と首のピッチ軸）とＥＲＧ−ＶＲ （首のヨー軸）に交換しました。機種選定の理由は、手元にある機種で、軸受けがしっかりしていて 、比較的消費電力が少ない機種ということで選びました。本当は３つともＥＲＧ−ＷＲに するのがいい気がしますが、空きがあったのがこの組み合わせだったので、こうしました。

今日のところは、取り付け作業中で、結果の確認はまだです。ただ、ちょっと動かしたところでは、 手でストッパーまで動かすと１８０度以上動くので、ＳＸ−１０１Ｚみたいに１８０度使えるの かと思っていたら、両機種とも１８０度まで動きませんでした。誤算でした。でも、３６０度 スキャンはあまり使わないので、視覚からの測距性能を重視して、このまま行くことにしました。

２Ｌ２でＥＲＧ−ＷＲを使っていた時は気が付きませんでしたが、 ちょっと見たところ、可動範囲はだいたい１２０度 くらいで、範囲を超えたパルスを入れたときは脱力でした。

首と腰の中立位置や、「角度」の入力から「パルス長」データに変換する係数を直しました。 各関節の校正をしながら よく調べてみると、ERG-VRはSX-101Zの様に180度強の作動範囲がありました。

次にボールを拾い集めるプログラムで動かしてみました。蛍光灯を見上げた時、その角度が 足りず、部屋の床の上で、蛍光灯を視野に納められる範囲がすごく減ってしまいました。 測距の正確さと 蛍光灯を使った自己位置測定機能のどっちを取るか秤にかけて、自己位置測定機能を 取ることにしました。そこで、首のピッチ軸の動作角を確保するため、ここもERG-VRに 換えました。

プログラミングに飽きてきたので、腕のカバーを作り始めました。写真中央、下寄りに 写っている、白っぽい、いかにも粘土でこねた様なものが、腕のカバーのオス型になる 予定のモノです。例によって、バキュームフォームで成型します。

腕のカバーの製作風景

２つのカメラの視差を利用して、視野に入っているものの距離を求めるプログラムを 書き始めました。カメラは２つ付いていますが、今までは右しか使っていませんでした。 はじめて、両方使うアプリケーションを作ります。

第１のステップとして、右カメラで捕らえたある物が、左カメラの画像のどこに映っているかを 探すために、特徴点抽出をやっています。特徴点は、とりあえず、水平方向のみに画像を スキャンして取り出した、エッジ抽出画像を使ってみることにしました。

　−＞

型が出来たので成型しました。

	成型後（表側） 桃象にセットできるプラ板が２００ｍｍ×２００ｍｍなので、型が大きくて つらかったです。１つ失敗しました。使ったのは１ｍｍ厚のプラ板です。
	成型後（裏側） 粘土の乾燥が速くなるように、型の裏側は、窪んでいます。
	切り抜き完了 左右で微妙に出来が違いますが、まあこんなものでしょう。 板一枚のままで強度が出るように、各所に適当な曲げを入れています。 小学生の時 よく遊んだラジコンカーの「紫電改」のクリアボディーを思い出しました。「伊太利屋」 ロゴが懐かしい・・・
	仮止め（その１） ＰＳ２の上で記念写真。箱デザインと３Ｄ曲面が似合わない・・・。 これは、部品製作の練習ということで良しとしておきます。
	仮止め（その２） 外装の取り付けによって、関節の可動範囲が狭くならないように、肘のあたりの 形状を工夫しました。 移動中に引っかかるときは、だいたい腕が引っかかるので（一番はり出している為） このカバーの裏にマイクロスイッチをつけて、タッチセンサーとする予定です。

次は首の周りに、何かカバーを付けたいです。

先週決めた方針でやってみたところ、使えそうな感じの結果が得られました。 下は、左右の画像のマッチングや、距離の計算の具合を確認するためにVBで作った ソフトのスクリーンショットです。

クリックすると拡大します。

上段の画像が、それぞれ左右のカメラからの画像です。 赤い点は、距離を計測することが出来た場所を示しています。下段の図は、同心円の中心を ロボットの位置として、計測できた対象の位置をプロットしたもので、レーダー画像 のようなものです。

基本的に今していることは、「この画像には何が写っていて、こう見るべき」という自分の 主観のコーディングを進めているのだと思います。ロボットと人間のハードの仕組みや性能の 違いや、コーディング時の勘違いから偶然発見する事実を盛り込むことから出る違いは生じ てきますが、出来上がるものの方向は、「人間の目の錯覚」のような錯覚を同じように起こす、 人が見る見方に近い見方をするロボットなのだろうと思いました。 たぶん、身近においておくロボットは、コレが都合よい発展の方向なのでしょう。

「目の錯覚」といえば、この「錯覚」を生ずる仕組みが、人と同じようにモノを見るキーに なっているという実感が強まってきたので、今後、より積極的に、認識プログラムの評価関数に 取り入れてゆこうと思いました。

プログラミングにおいては、学生の頃に製作に燃えたオセロゲームプログラムの評価関数 を作った経験や、難しくてイマイチよく分からなかった「ゲーム理論」や古典的な「人工知能」 の本で読んだ事柄などが役に立っているような気がしました。

ロボットとＰＣの間の通信速度アップへの、一つの取り組みとして、秋月の H8/3069 LAN ボードキットを買って組んでみました。こういうハードに近いレベルで LANに関するプログラムを組んだ経験が無いので、どの程度意図に沿うのか分かりませんが、 試してみることにしました。

キットが組みあがったので、キットに付いてきたシングルタスクのH8/OSをROMにインストールし、 H8/OSのシステムコールとキット付属のｇｃｃの環境が 動いていることを確認するため、タクトスイッチを押したらLEDが点灯するプログラムを 作ってみました。LAN関係のハードは、付属のｈｔｔｐのプログラムで確認しました。


クリックすると拡大します。

PC側は、一番ハードルが低そうな、VB6のWinsockについてマニュアル (MSDNライブラリ)を読みながら、プログラミングの練習をしています。ＵＤＰで、ＶＢの プログラムからＬＡＮ経由で受け取った文字列を、シリアルポートから吐き出して、ハイパー ターミナルに表示するのをやってみたら動いたので、誤解無くマニュアルを読めたみたいです。 とりあえず使えそうなことが確認できて良かったです。


クリックすると拡大します。

ふと、ＰＣの回路図を見ながら、ビット操作をするアセンブラのプログラムを書くようなことを していた頃と比べると、ずいぶん変わったと感じました。

このキットについて、いろいろとネットで情報収集をしてみると、発売当初は回路に 不具合のあるキットだったらしいということが分かりました。が、今売っているキットは 改修済の様です。（追加のコンデンサ等、部品や説明書が入っていました。）

H8/OSのシステムコールや、VB6のWinsockに慣れる為の練習として、チェックボックスに チェックするとLEDが点灯する機能と、読み取りボタンを押すと、状態が文字列で返ってくる 機能をプログラムに加えました。

キット付属のH8/OS　Var.2.5で、ボードに載っているDRAMを使えないか調べていたのですが、 DRAMエリアにプログラムを転送するとまともに動かないので、リセット直後はリフレッシュが されていない？様だと思いました。練習としてCMOSカメラのTrevaを接続して、1秒間に何 フレームくらいPCに取り 込めるか試してみようと思っていますが、プログラムは内蔵RAMエリアで実行し、アプリケーション でDRAMを使える様にした後、画像データだけDRAMに入れるようにしようかと考えました。

ちなみに、プログラムはこんな感じです。いまのＷ６のシステムを踏襲し、 文字列のコマンドで、マイコン側に何をするか指示しています。通信開始の権限は ＰＣ側が持っています。

Ｃの方は、プログラミングの環境整備として、使い慣れたヘッダファイル(3067f.h)を gccのインクルードファイルのディレクトリにセット し、いつものようにＶＣ＋＋６の環境でコンパイルのチェックが出来るように、H8/OSのシステム コールのダミー関数を作りました。（使う関数だけ）

Private Sub Check1_Click() If Check1.Value = 1 Then 'ＬＥＤ点灯 Winsock1.SendData "a1" Else 'ＬＥＤ消灯 Winsock1.SendData "a0" End If End Sub Private Sub Command1_Click() End End Sub Private Sub Command2_Click() 'タクトスイッチ状態レポート Winsock1.SendData "b0" End Sub Private Sub Form_Load() With Winsock1 .RemoteHost = "192.168.0.145" .RemotePort = 6000 .Bind 1002 End With End Sub Private Sub Text1_Change() Winsock1.SendData Text1.Text End Sub Private Sub Winsock1_DataArrival(ByVal bytesTotal As Long) Dim strData As String Winsock1.GetData strData Text2.Text = strData End Sub

ＶＢ６のソース

#include < h8/3067f.h > #include < h8/syscall.h > /*ＬＡＮ初期化*/ int init() { char *mac; PBDDR = 0xef; write_mode(SIO); ether_init(0x200000); if(get_ether_status() == 0) { write_string("NIC is not found!\n"); return -1; } mac = get_mac_address(); write_string("MAC:"); write_mode(BINARY);sys_write(mac, 6); write_mode(ASCII);write_string("\n"); return(0); } /*割り込み処理*/ int udp(unsigned short port, struct sockaddr_in *addr) { char buffer[64]; int i, n; if(port != 6000) return -1; n = udp_read(buffer, 63); udp_write(" ", 3); sys_write(buffer, n); if(n == 2) { if(buffer[0] == 'a' && buffer[1] == '1') P4DR.BIT.B0 = 1; if(buffer[0] == 'a' && buffer[1] == '0') P4DR.BIT.B0 = 0; if(buffer[0] == 'b' && buffer[1] == '0') { if(P5DR.BIT.B1 != 0) udp_write("The switch is not pressed down.", 31); else udp_write("The switch is pressed down.", 27); } } return(0); } /*メイン*/ int main() { int i, j; char work[64]; struct sockaddr_in addr; write_mode(SIO); write_string("\n"); P5DDR = 0x00; P5PCR.BYTE = 0x0f; P4DDR = 0xff; if(init() == -1) return -1; ip_setup(IPADDR(192,168,0,145), IPADDR(255,255,255,0)); udp_regport(udp); while(1); }

Ｃのソース

Ｗ６に地図を持たせるために、以下の作業を行いました。
• 普段、Ｗ６を動かしている部屋の家具類や壁の位置、そして走行可能エリア等をＣＡＤに入力
• ＣＡＤに入れた図面を見ながら、データとしてロボットに持たせるための構造体の設計
• 構造体に定義した項目の数字を、ＣＡＤで採寸してエクセルに入力
• エクセルから出したＣＳＶファイルを読んで、構造体にセットするファイルＩ／Ｏ関数を作成

  この地図データベースは、スポンジキューブを拾い集めるときに、「スポンジキューブ」として 画像認識された対象が、アプローチ可能な場所にあるかのチェックや、アプローチのルートの 計画等に使用します。

  ちなみに、今あるキューブ拾いのプログラムは、いつも部屋の中心に行って、そこから見える キューブまでまっすぐに行くという、出発地点を限定することによって、 途中で家具類に引っかかる可能性を考慮しなくても 成功する可能性が高いというアルゴリズムを使っています。

  地図の図面のダウンロード
  

  //地図データベースの構造体 struct MAP_DB { int id; //オブジェクトＩＤ double end_point[2][2]; //エリアの始点と終点 double area_width; //エリアの幅 int num_neighbour; int neighbour_id[16]; //隣接オブジェクトのＩＤ int num_node; double node_point[16][2]; //隣接オブジェクトとの接続座標 int num_wall; double wall_end_point[4][2][2];//壁の始点と終点 };

  Ｃの構造体 部屋が長方形で、家具類も長方形のものが多いので、エリアのエレメントも 長方形としました。 構造体の配列にして、データベースとして使います。

メインＣＰＵのプログラムは、長い間、ロボットを起動するたびにＰＣからＲＡＭにロードして 動かしていましたが、最近いじっていないので、ロードの手間を省くためＲＯＭ化しました。

ＲＯＭ化すると、メモリへのアクセスが早くなることから、プログラムがだいぶ速く動くよう になるので、同じ露出テーブルでは露出不足気味になりました。そこで、露出テーブルの数字を 調整しました。

スポンジボールを集積する場所の目印などとして使うための標識を用意し、搭載カメラでの 写り具合（見え方）の確認をしました。

	テスト風景 ロボットの向こうに写っている物が今回製作したランドマークです。工作用紙に黒の ビニールテープが張ってあります。
	ロボットの見ている風景 未処理の画像です。
	インデックス付け終了後 暗い部分を２値化で取り出し、インデックス付けが終わったあとの画像です。「十字マーク｣が キレイに取り出せています。
	ステレオ撮影 「十字マーク」の距離を取り出せるかやってみました。赤点の場所しか距離を 求めていませんが、コレもきれいに出ています。十字の先端の距離を求めれば、 ロボットと、マークが描かれている面の角度が分かるので、正面から撮影しなくても 大丈夫そうです。

ステレオカメラ、地図ＤＢ、部屋の中での絶対座標を知る手段、ランドマークの 形や大きさを登録してあるＤＢ等があれば、この様な見る方向によって見え方が 変わるようなランドマークでも使えそうだと思いました。

別の条件についても思いをめぐらせてみました。現行のノーマルＡＩＢＯの様に、地図ＤＢ無し？ でカラーカメラ1つの場合は、ＡＩＢＯの充電ステーションの様に、どっちから見ても 見え方が同じになるランドマークが理にかなっていると納得しました。

先週製作したランドマークを認識させるため、図形の判定をする関数に十字図形を認識する コードを書き足しました。幾つかのif文を通過させ、条件を満たすたびに変数を加減して行き、 一定以上の数字になったら「十字｣と判定するタイプのコードにしました。

これだと汎用性が無いので、一般的な文字認識などの「パターンマッチング」の関数を 実装した方が良さそうな気がしてきました。問題は、カメラで撮影した画像から図形を 取り出した場合は、ゆがんでいたり、大きさが不確定だったりするので、どうやって 登録してあるパターンと比較できるところまで持ち込むかが難しいと思いました。

でも、一般的な問題だと思うので、この問題を扱っている論文を探して参考に出来るのでは ないかと思いました。

走り出すときに、左右の車輪の駆動系のフリクションロス等の違いからか、タイヤが回りだす タイミングがズレるために進路がそれるケースが多いように見えます。 そこで、起動電流を多くして、起動タイミングのズレを少なくする意図でＰＷＭ周波数を １ｋＨｚから１００Ｈｚに下げてみました。なんだかこっちの方が、Ｗ６の駆動系には 良いようです。

例えば腕を展開する時は、動かし始める前にモーションのデーターを予め計算し、そのデータを 再生しながら動かしていました。そのため、モーションデータの計算中（約０．７秒くらい） ＰＷＭパルスが途切れるようになっていました。

腕をたたんでいる時は、ＰＷＭパルスが止まっても、もともと電源を切ってもＲＣサーボ自体の 機械的な抵抗の範囲でそのままの姿勢を保つようなポーズを各関節のホームポジションとして いるため問題無いのですが、腕を伸ばしている時に、腕がガクッと下がってしまいます。
ボール拾いのプログラムを動かしていて、ボールを集積場所で放すときにガクッと来るのが 気になってきたので、予めモーションデータを作るのを止めて、リアルタイムで各関節の 目標位置までを補間するだけにしました。

コレによって、目に付くほどの長時間にわたってＰＷＭパルスが途切れることが無くなりました。

また、計算の負荷を軽くするため、各関節の加速・減速のプロファイルに三角関数の形を 使うことを止めて、ただの三角形（注：台形ではありません)に変えました。

「2004.09.05」のところで、エンコーダを付けた時、部品のストックが無いからと、 ソフトでＩ／Ｏポートのビットを読んでカウントするようにしていました。しかし先週、 部屋の本棚の整理をしている時に何気なく「アナログ回路センスアップ１０１」 （ＣＱ出版社）の始めの方を見て、その後秋葉原へ行った時に７４ＨＣ１４を 買ってあったのを思い出し、付けることにしました。

ＣＲのローパスフィルタとシュミットトリガのインバータが付いたので、晴れてＨ８の ＩＴＵでパルスをカウントできるようになりました。

最近、走行時の音が大きくなってきた気がしたので、ギアボックスを分解して、グリスを 塗りなおしました。グリスを塗る前に、車輪を手で動かして音を聞いてみると、左の方だけ ギアに砂粒のような異物が付着している時に似た音がしたので、よく見てみると、モーターの 軸に付いているピニオンギアに亀裂が入っていました。ココの樹脂製ギアは、今までの経験では、 １〜２年の期間で割れているので、左右とも新品と交換しておきました。

ギアの交換とグリスアップを終えて、走行中の音がだいぶ静かになりました。 ちなみにグリスは、田宮模型から出ている「シリコングリス」を使っています。

	メンテ風景 メンテナンスのため、車輪、移動ユニット下部のカバー等を外して、ギアボックスを取り出したと ころです。
	ギアの亀裂 写真の中、矢印の先の辺りで、ギアに筋が入っている場所が破損個所です。

2005.02.13の作業の続きで、見つけたキューブを地図データベースに記録するプログラム を書き始めました。

実際に試してみると、６０ｃｍ程前にあるキューブの位置が、２０ｃｍ以上ずれて記録 されました。

原因を追究してゆくと、蛍光灯を見上げて、自機位置を取得する時の、首 サーボの位置決め誤差が大きく効いている様だと分かりました。 （要は、地図に記した自機位置からずれてました。）

先日、首のＲＣサーボを交換した時、例えば「ピッチ方向に６５度 上を向く」と指定した時に、６７度位になっているのをほおってありましたが、これでは ダメなようなので、指定角度をＲＣサーボのＰＷＭパルスの長さに変換する方法を、１本 の直線で行わず、ＰＣ側で、回帰計算を行い、複数の点から補間多項式で求める方式に変える ことにしました。

その後、結果の確認方法として、分度器をあてて計るようなやり方よりも、より精度が出る 簡単な方法は無いものかと少し考えました。ロータリーエンコーダをＲＣサーボの軸に 付けて計測する方法が紹介されていたのを思い出しました。
しかし、ある程度のロータリーエンコーダーは高価である事と、Ｗ６の首にロータリーエンコーダ を足すのは面倒なことから、ここは一つ、 学校で習う物理実験のベーシックな方法を 思い出し、レーザーポインタと壁に付けた印を使う方法を試してみることにしました。 そんなわけで、Ｗ６の頭の上にレーザーポインタを取り付けるべく、以前「粗品」として もらったキーホルダー型のレーザーポインタを分解し、発光モジュールに 電源とスイッチを外に付けました。

レーザーポインタ ケースからレーザーのモジュールを取り出して、動作確認しているところです。 似たようなものが、今でも秋月電子から「赤色レーザー発光モジュール」として 入手可能なようです。