フォトリフレクタQTR-1Aの使い方

花岡ちゃんのウィークエンド

久しぶりのウィークエンドで測距輪を作ってみました。ROSのカテゴリでやっている「1/8計画（！）」の一環です。

測距輪とは、その名の通り、転がった距離を測定する装置です。今回試作したのは内径55φのOリングを使い、写真のようにまとめました。3Dプリンタのおかげで、こういうものが作りやすくなりました。

これをロボットなどに引っ張らせることで、移動距離を計ります。見ればわかるように、車輪の白い帯をフォトリフレクタで数える構造です。二相式で一回転72パルス、分解能は3mmほどです。
仕組みは、以前シェーキーで作ったものと同じですが、分解能がだいぶ落ちています。

今回は回転を検出するフォトリフレクタに、出来合いの基板、QTR-1Aを使いました。実はこれが分解能が落ちた原因です。これから使う方のために、顛末を投稿します。

QTR-1Aは２個で480円、とても小型で外付け部品も必要なく、アマチュアにとって魅力的な商品です。本家ページによると「アナログ出力」ということで、シェーキーでやっているように、反射の強さを読み取ることで、かなり細かいエンコーダーパターンにも対応できそうに思われます。下の写真は測距輪での実装例です。

QTR-1Aの回路はこうなっています。

フォトトランジスタ側は、エミッタ接地の増幅回路ですから、バイアスのかけられないフォトトランジスタの場合、出力特性は下図のようになります。

ある明るさを境にして、出力電圧が急激に変化しています。それ以外の明るさではあまり変化はありません。つまり、アナログ出力といいながら、実用的にはデジタル的な二値しか使えないことになります。どうやらこれは、中間的な電圧を出力する可能性があることから、マイコンのロジックレベルの入力ではなく、アナログ入力に接続すべきである、という意味のようです。

エミッタ接地のアンプでは、バイアスをかけることで、変化する部分に動作点を持っていき、わずかな入力電圧の変化を、大きな電圧の変化にすることで増幅作用を実現しています。しかし、フォトリフレクタの場合は、反射光の明るさが、この変化点をまたぐように黒／白の幅を調整する必要があります。その結果、エンコーダーのパターンをこのくらいに粗くする必要があり、分解能が落ちてしまったのです。

エンコーダーの黒／白のパターンは、センサーの視野にいきなり出現する訳ではなく、徐々に入ってくるので、反射光の強さはアナログ的に変化しています。
シェーキーのリフレクタは、このページの写真にあるように、パターンからの反射光の強さをアナログ電圧として出力します。これをADで読み、波形処理を行った上で、回転方向や回転数の計測をしている訳です。

これは、フォトトランジスタを下図のようにエミッタフォロワとして使っているからです。

エミッタ側に負荷抵抗を入れたエミッタフォロワの大きな特徴は、グラフのように入力（明るさ）と出力電圧が比例することにあります。エミッタ接地とは違い、広い入力範囲で、変化を読み取ることが出来ます。しかし、明るさの小さな変化を増幅する作用はありません。一般にエミッタフォロワのゲインは１以下です。
従ってこれを読むには、感度のいいADが必要です。シェーキーの場合は、黒と白との電位差は700mVくらい、これを10bit分解能4.9mVのADで読み取っています。パターンをより細かくすると、電位差も小さくなります。

QTR-1Aを使う際は、「アナログ」とあるけれども、それはマイコンのアナログ入力に接続する必要があるということで、信号としてはデジタルとして扱わなければならない、ということに注意する必要があるでしょう。ライントレース用のセンサや、リミットスイッチ代わりなら問題ないですが、アナログであることを利用した応用を考えている場合は要注意です。

もちろん、エミッタ接地回路でも、フォトトランジスタのコレクタ抵抗を調整することで、変化点を都合のよいところに持ってくることが可能です。しかし、QTR-1Aの小さな基板では、抵抗の調整や取り替えは難しいと思います。
また、フォトリフレクタに光学スリットを追加して視野を狭め、細かいパターンに対応させることも出来るはずでが、細かい工作が必要で、アマチュア向きではないでしょう。

1/8計画（その２）

ROSさんお手やわらかに：ROS奮闘編

久しぶりのロボット製作だ。ジャイロコンパスにはLEGO用のXG1300Lか、おそらく同じ部品を使ったR1350Nを使う。少々心配なのは供給状況だ。現在、両方とも国内で入手するのは難しいようだ。XG1300Lを扱っていたテクノロジアではカタログから外れているし、R1350Nはおなじみスイッチサイエンスで品切れだ。せっかく試作するのだから、後進の人の参考となる内容にしたい。そのためには部品がデスコンになっているようでは具合が悪い。メーカーHPにはまだラインナップされているのでデスコンという訳ではないだろうから、とりあえず手持ちの部品を使って試作することにする。

まず、オドメトリ実証機を試作することにする。ジャイロと測距輪で、自己位置推定が実用的に出来るかどうかを評価するためだ。測距輪の作り方や、ロボットへの取り付け位置も検討する必要があるだろう。測距輪を引っ張る形でうまく行くという保証はない。

実証機はPIC24Fを搭載し、xbeeでパソコンに推定位置を送信する。これをターミナルで読むか、あるいは簡単なソフトでマップ上に表示することで、オドメトリの検証をする。

オドメトリがうまくいくようなら、実証機をROSで動かしてみる。ドライバパッケージを作って、この投稿のように、リモコンしながらrvizに現在位置を表示できれば「上がり」だ。

ここまでは実証機での実験だ。実証機にはレーザースキャナーやカメラを搭載できない。次は本格的なROS対応小型機に着手することになる。なかなか大変な作業だ。やる気が続くだろうか‥

1/8計画（その１）

ROSさんお手やわらかに：ROS奮闘編

roombaでは大きすぎて、ウチではナビゲーションの実験が出来ない。狭い室内で実験するには、もっと小さな移動ロボットが必要だ。自作ロボットをROSに対応させる実験も含めて、小型化の研究をすることにした。ウルトラQの有名なエピソードに倣って、1/8計画とでも呼ぼうか。1/8サイズになる訳ではないが、狭いスペースを有効活用するというコンセプトは同じだ。

まずは、小型のオドメトリ対応のロボットだ。今回はちょっと大胆なアイデアを試してみる。オドメトリを使ったロボットは、一般に駆動輪と床とがスリップしないという前提に立っている。滑りやすいカーペットの上でroombaのオドメトリが狂うのはそのためだ。

今回作るロボットでは、差動ドライブの駆動輪がスリップしても、オドメトリに影響が出にくい構造を考える。
つまり、左右の駆動輪のエンコーダから自己位置の推定をしないということだ。代わりに、ジャイロコンパスと測距輪を自己位置推定の情報源としたい。

3Dプリンタも導入したので、プラクティカルに、とにかく作ってみる。イメージはこれ。部品を並べてみた。

写真の左が進行方向。キャタピラ車に測距輪を引っ張らせる構造だ。カーグラフィック誌の「谷田部のテスト走行」を思い出させる。
キャタピラの走破力と大口径の測距輪で、下の写真のように、roombaやシェーキーの移動を阻害している我が家のカーペットを、スムーズにクリアすることを期待したい。

Hydroにアップグレード

ROSさんお手やわらかに：ROS奮闘編

重い腰をあげて、GroovyからHydroにアップグレードした。
FuerteからGroovyへの時はかなり苦労したが、これはマニュアルにしたがってHydroをインストールするだけでOKのようだ。ワークスペースもそのままで良い。
念のためワークスペースでcatkin_makeをしておく。おかしなエラーがでなければ大丈夫のはずだ。

マニュアルの最初にUbuntuのリポジトリを何やらという記述があって？？？ということになった。
これは端末を開いて、下記のコマンドを実行

$ software-properties-gtk

開いたウィンドウで下記のようにチェックが入っていることを確認すればよいようだ。

僕の場合は、すでに上記のようになっていた。

ことばでロボットを動かすこと

ABCは知ってても：

プラクティカルな他のカテゴリと違い、考えを積み重ねるこのカテゴリは、なかなかブログにまとめる体にはなりません。
最初は、ある程度まとまったらブログに落とそうと思っていましたが、そうは簡単にまとまるものではないですね。論文でいえば、いまだに参考文献の読み込みをしながら、ぼんやりとしたイメージをノートに書き散らしているような段階です。

とはいえ、備忘録として書いているブログですから、この辺で「ロボットを言葉で動かす」ことについて、考えたことをまとめておきます。

最もシンプルなモノは、80年代のロボットおもちゃ「キクゾー」のように、単語と動作を結びつけるものでしょう。

これは、モーターひとつで、前後左右に動いたり、小さなものを持ち上げたりするという、傑作おもちゃです。これまた興味深いシンプルな音声認識で、「前進」などの単語を認識出来ます。
命令をアクションに割り当てる方式です。リモコンのボタンに単語が割り当ててあると考えられます。そのため、「前進」で登録したのを忘れてしまい、「前へすすめ」なんて言うと、当然、動きません。

これでは融通が効きません。もう少し良さそうなのはSTT(Speech To Text)で音声を文書化し、形態素分析とロジックで命令の意味を解析する方式です。ネットタンサーではこの方式で、音声認識センサーを実現していました。

しかし、これで問題が解決する訳ではありません。話し言葉では「ああ」とか「えっと」などの意味の無い言葉が入りがちですし、「えっと前進。前へ４メートル‥‥いや３メートル」のように、きちんとした文法にならないことが多いようです。これを理解するソフトは結構大変なのではないでしょうか。

大学入試に挑戦する人工知能というのが話題になっていますが、文脈の理解という点では、理解されることを目的とした入試問題文と、何気なく発せられた話し言葉では、後者の方がずっと難しいのではないかと思います。

例えば先ほどの例では、ロボットが「３メートルですね？」と確認を求めるのが良さそうです。
これが、話し言葉を理解するには、一方通行の「音声認識」ではなく、人間との対話で情報を確定する、「対話による認識」が必要になると考える所以です。