まっすぐ走らない？

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

組み込んだコマンドインタプリタを利用してオドメトリの校正作業を楽しんでいます。写真のようなゾンビ状態ですが。

移動系のコマンドは、元祖Shakey先輩に倣って下記のようになっています。

ROLL 距離(cm)　浮動小数点。プラスで前進、マイナスで後退
TURN　角度(degree)　浮動小数点。プラスで反時計回り、マイナスで時計回り
ROLLTO　X座標　Y座標(cm)
TURNTO　X座標　Y座標(cm)

TOのついているコマンドは、マップ座標系の特定の位置へ直線移動したり、その座標位置に向かって旋回したりするモノです。

校正作業は、コマンドのパラメータと実際の運動量を比較して、STM32F4に実装したオドメトリの係数を調整する訳ですが、どうもうまくいきません。改めてロボットの運動を観察すると直進でぐぐっと左に曲がってしまうことに気がつきました。1mほどの直進中、次第に左に曲がってゆき停止時には５度以上も左を向いています。しかもオドメトリではまっすぐ進んだことになっています。なんと！　ベースだけでテストしていたときにはこんなことはなかったのに！　これではだめですね。

本機の直進補正はこの投稿で書いたように、左右の駆動輪のトリップメーターを比較して、先へ行ってる方のモーターのPWMパルスを0にする、つまり瞬間的にパワーを切るという方法で行っています。単純ですが効果的な方法です。

駆動輪のインタラプタを二相に変更したばかりなので、もういちど波形観測やドライブサーバのソフトの確認をしてみましたが、これといって問題は見当たりません。
次に内部シリアルバスに直接パソコンからアクセスして左右トリップカウンタの値を連続的に読み出してみましたが、走行中常に両者の差は±１カウント以内です。

次に馬を入れて駆動輪を浮かせ、ホイールに黒いビニールテープでマークをつけて、停止位置がずれるかどうかを確認しました。これもOK、左右とも同じ位置で停止します。

となると、タイヤと路面のスリップが疑わしくなりますが、路面はフローリングの床でグリップはよく、駆動輪のタイヤがこれほど滑るとも思えません。
ではホイールに対してタイヤが滑っているのでしょうか？　そこで、ホイールとタイヤにこの写真のようにビニールテープの切れ端で印を付け、走行実験をしてみました。

銀色の駆動輪下部の四角いマークがホイールのマーク、ちょっと見にくいですが、テープを長方形に切ったものを踏ませる形でタイヤに張り付け、これをタイヤ側のマークとしています。これを1m走行させた結果がこれです。

ご覧の通り、タイヤとホイールのマークがずれています。タイヤがおいていかれる形ですがら、当然左側の回転数が足りなくなり、車体は左を向いてしまいます。ここで滑っていたのですね。観察するとどこかでがくんとずれるのではなく、走行中次第にずれてゆくこともわかりました。そこで、タイヤとホイールの間に瞬間接着剤を流し込んで固定しました。

本機の駆動輪はアルミプーリーにOリングのタイヤをはめています。はめ込んだだけですが結構しっかりはまっていて、手でタイヤだけをまわそうとしても回るものではありません。まあこれで大丈夫だろうとタカをくくっていたのですが、重量が増えてくるとこれが回ってしまうのですね。大きなものはいろいろと大変です。

接着後は大きな問題もなく、なかなかの精度で動いています。

TrueSTUDIO Liteの旧バージョン

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

以前投稿したように、TrueSTUDIO Liteの最新バージョンはコードサイズの上限が32KBになりました。僕は以前ダウンロードした古い、コードサイズ制限なしのインストーラを持っているので、これをネットブックにインストールできるかどうか試してみました。

やはり、使い捨ての暗号を使って認証する際に、「もっと新しいバージョンがあるのでそちらを使え」というメッセージが出てアクティベートできません。現在使っている旧バージョンがクラッシュしたらおしまいです。早いとこ乗り換えを進めなくてはなりませんね。

STM32F4はFLASHもRAMもたっぷりあるので、H8やPICなんかのようにケチケチしないでコードがかけるのはありがたいことです。
もちろん、ホストとの通信もsprintfやsscanfを使っているので、大変に楽です。そのかわり、コードサイズもそれなりに大きくなりますね。

現在オドメトリでロボットの位置や進行方向の計算とコマンドインタプリタくらいの実装で、すでに38KBくらいになっています。math.h、stdio.h、stdlib.hをインクルードしています。これくらいになるとほとんどパソコンでソフトを作っているのと同じような感じでいけます。さすがSTM32F4、たいしたもんです。

なにか写真がないのは寂しいので、シェーキー頭部の後ろ側の写真を載せておきます。このケーブルは４芯の細いロボットケーブルです。しなやかで曲げ耐久があるのでこのような用途にはもってこいです。マルツパーツなどで5mの袋詰めにして販売しているので、アマチュアにも使いやすいものになっています。

シェーキーの近況あれこれ

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

近況報告です。

充電器の電源に電流計を追加し充電状態が分かるようにしました。こんなものです。

プラケースにACアダプタを入れ、1Aの電流計をつけました。通常充電では600mAくらい流れることが多いようです。充電終了時には50mAくらいになります。満充電で充電したままロボットの電源をONにすると400mAくらい流れます。
充電器をつないでおけば一日中動作したままにすることが出来るので、ソフトの開発作業はやりやすいです。

アンテナはこの写真のように胴体内部に搭載しました。真ん中あたりに見える黒い横棒がそれです。外装はプラスチックと木材なので、通信状態は問題ないようです。もっとも、このようにアンテナを寝かして実装すると指向性が出るのであまりよくはありません。

現在オドメトリのソフトをテストしています。制御系のソフトだと演算は整数化して行うことが多いのですが、三角関数が必要になるとそういう訳にもいかず、パソコンソフトのようにdoubleで演算する必要があります。パソコンやPICでこれまでに作りためたソースコードをガタガタと組み合わせていくのですが、整数化している部分もあり浮動小数点の部分もありで意外と大変です。

旋回精度の調整はこのように行いました。この写真のように、シャーシにレーザーポインタを取り付け、壁にスポットを当てます。ここでロボットを360度旋回させたとき、同じ場所にスポットがくるようにパラメータを調整しました。

旋回角度の測定は難しいので、このようにすれば簡単です。

PSDできちんと距離を測定するには

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

シェーキーにはロングレンジ測距用としてGP2Y0A710K、ミドルレンジ測距用としてGP2Y0A02YK、二つのシャープ製PSDを、カメラ上部のレンジファインダエンクロージャ内に、この写真のように搭載しています。

電源を独立してON/OFFできるようにしてあるので、切り替えて使用します。このPSDで周囲の環境を測定してマップを作成する予定です。となると、この測距センサの精度が問題になります。

まず、PSDには本質的に下記の誤差要因があります。

１・モノの角や本の背表紙が凸凹に並んでいる本棚など、平面でない物体との距離は正確に計測できない
２・平面でもポスターのように模様があると正確に計測できない場合がある
３・メッキ面や鏡など光を反射する物体は反射光がセンサに帰ってこないので測定できない
４・遠距離になるほど測定結果が正確でない

つまり、PSDで正確に測定できるのは、経験から、デバイスの測定最大距離の半分程度までで、単色の平面までの距離を測定する場合のようです。この条件だとかなり正確に距離を測ることが出来ます。

それ以外の誤差の要因としては、電気的なノイズが測定結果に混入することが考えられます。以前、PSDの消費電流を解析した結果から見ても、ちょっと心配です。早速センサ出力を測定して見ました。

100mV/Divです。波形が毛羽立っているのは、 DC-DCコンバータのスイッチングノイズです。デジタルオシロは極めて短い（数nsくらい）の信号も正直に拾い上げるのでこんな感じになります。このケバは相当高速のADでないと拾えないので、それほど気にする必要はありません。ただ、100us強のパルス幅、1000us強の周期で、100mVほどのパルス性のノイズが乗っているのはいただけません。これはADコンバータに捉えられ、誤ったデータをシステムに与える恐れがあります。障害物回避などの用途ならそれほど問題はありませんが、今回のようになるべく正確に距離を測定したい場合は何とかしたいところです。モチロン、ソフトウエアで対処する手もありますが、アナログな僕は、オーソドックスにノイズを「元から断つ」という方針で対策しました。

このノイズはここで投稿したパルス状の電流消費が影響しているのは明らかです。パルス幅、周期が同じです。これをなるべく少なくするには電源まわりのインピーダンスを下げればいい訳です。

そこで、各PSDの電源ラインに4700uFのコンデンサを入れました。こんな感じです。

なるべくPSDの近く（電気的に）入れました。その結果の出力がこんな感じです。

かなりパルス性のノイズがとれていると思います。

ただ、これでもまだ問題ありで、50Hzの電灯線ハムのような成分が乗っていることがわかりました。（写真を撮りそびれてしまいましたが）シェーキーではPSDの出力をシールドなしのロボットケーブルで50cm以上引っ張っています。あまり、外来ノイズに強い構成とも思えません。ただ、これは信号ラインのインピーダンスが高く、オシロのプローブを接続したことで乗るということも考えられるので、信号ラインにOPアンプによるボルテージフォロワを入れてみました。前の写真の下の方に見えているのがそれ用のOPアンプです。
しかし、この対策は全く効果なしでした。まあ、もうちょっと考えなくてはなりませんねえ。

この状態でSTM32F4 Discoveryで読み込むと、読み込むたびに数十mVもの差が出ることがあります。そこでとりあえず、20mS（50Hzのハムの周期）ほどの間に100回読み込んで平均を取るようにしてみました。これだと毎回の差はかなり小さくなります。つまり、ノイズの周波数成分がわかっているので、それをキャンセルするようにした訳ですね。電気的に対策したいものですが・・

うーむ、なんとなく釈然としない部分もあるのですが、とりあえず何とかなっています。近いうちにもう少し分析したレボートができればと思います。

アクエストークLSI・ATP3011F4-PUを試してみる

花岡ちゃんのウィークエンド：アクエストークの実験

前回投稿したアクエストークのLSI、ATP3011F4-PUを入手し、テストしてみました。
最もシンプルな回路でのテストです。

スピーカーの駆動はトランジスタ１石です。D級動作なので、いわゆる小信号用やスイッチング用ならだいたいのものが使えます。ベース抵抗も数百Ωから数KΩくらいまでなら何でもかまいません。
パソコンとの接続にはレベルコンバータが必要です。僕は、単三電池４本を簡易電源として搭載した実験用レベルコンバータを自作して使っています。新たに作る人はこれなどを利用するとUSBで使えて便利でしょう。試作したものがこれです。

回路は手前のブレットボードに組みました。左奥の基板が電池内蔵のレベルコンバータで、今回はこれから安定化した3.3Vを供給しています。右奥の丸いスピーカーはタッパーウェアに組み込んだものです。裸では良い音がでないので、この程度でもかまいませんからスピーカーボックスに入れるようにしましょう。

テストはTeraTermで行いました。このデバイスはボーレートを自動設定するようになっているので、ボーレートは何でもかまいません。今回は38400bpsに設定しました。その他の設定は、パリティなし、ストップビット１、フロー制御なし、ローカルエコーあり、です。
これが動作させた様子です。

接続し、電源を投入したら、"?"をタイプします。これでボーレートをチェックするようで、同期するとプロンプト">"を表示します。この操作はパワーオンリセットやスリープからの復帰後１度だけ必要です。
続いて"konnnichiwa"（こんにちわ）などと喋らせたい内容をローマ字で入力しリターンキーを打つと喋ります。発声が終了するとプロンプトを返し、次の言葉を待ち受けます。
前のデバイス同様、喋れないデータのときはうんともすんともいいません。喋らないときは"aiueo"などの簡単なデータで試してみてください。

音量はそれなり。ポケットラジオくらいです。肝心の音質はちょっとカサカサいう感じです。オーディオ評論のジャーゴンでいえば「シャリってる感じ」ですかね。ただ、音声合成としての品質は十分で聞き取りやすい音声だと思います。

3.3V、8Ωのスピーカーでの消費電流は、待機時0.6mA（同期させるまでは3mA）、発声時80mA程度です。スピーカーを16Ωとか32Ωにすれば、もう少し消費電流を減らせると思います。反対にトランジスタをICが1Aくらいのモノにかえれば、もう少し音量がとれるでしょう。もっとも、音量を求めるなら、アンプを別付けにする方が消費電流も抑えることが出来るので、合理的だと思います。
待機電流が少なくて、とてもいいですね。電池動作で面白いものが作れそうです。

最後に、気がついたことをいくつか。

■一度に送れるデータサイズは127バイト（MicroTalkの半分くらい）
枕草子なら「春はあけぼの、ようよう白くなりゆく山際、すこしあかりて、紫立ちたる雲の白くたなびきたる。夏は夜」くらいまでです。それ以上の台詞を喋らせたいときは、分割して送信する必要があります。

■ボーレートを固定したいときはPMOD0をLにすると9600bpsに固定される
組み込み機器にはこの方が確実でいいかもしれません。

■ローマ字で記述されたデータは確認しにくい
ホストのマイコンにデータを埋め込んだりする場合には、日本語文字コードで悩まなくてよいのですが、データの確認はちょっと厄介です。ホストがパソコンで大量のスピーチデータが必要な場合は、スピーチデータにひらがな表記の使えるMicroTalkの方がいいかもしれません。