Pico2：進行方向の速度制御による，角速度系への干渉について

作ったはいいものの，いまいち実験，検証内容と手段がなかなか決まらないPicoシリーズの2回目．

今回は，前から何となく気にしている，進行方向の速度制御による，角速度系への干渉について．

　私の場合，速度制御系はこちらなどで紹介されているとおり，進行方向と角度方向に入力を分け，進行方向は2つのモーターへ同符号の入力，角度方向は逆符号の入力で制御している．

　これまでなんとなく思っているのが，(当たり前かもしれないが)2つの入力はそこまで独立しておらず，進行方向の制御は角度方向に干渉しているのではないか？ということ．

　例によってPicoで試走調査．今回はフィードバック入力で進行方向の速度を制御している状態を想定し，左右輪の速度差は一定だが(角速度は一定になるはずだが)，左右輪の速度の平均値である進行方向の速度を振動させた入力となるようオープンループで走行させログを見てみる．

　前回と同じく，直線→右180度ターン→直線のコマンドを実行させる．ターン中の進行方向の速度は，今回は　0.5 + 0.05×sin(wt) [m/s]と，目標値に対して±10%の振れがある場合を想定する．

　結果が以下のログ．上が，速度が振動している場合，下は比較のための速度が振動していない場合のログである．左上と右下がそれぞれ左右輪の目標速度，それに比例するステップパルス周波数であり，右上と左下がそれぞれジャイロの角速度と角度を，目標値と共に記したものである．

・進行方向速度：0.5 + 0.05×sin(wt) [m/s]　(振動的)のログ

・進行方向速度：0.5 [m/s]　(一定)のログ

ものの見事に進行方向の速度の振動が，回転系に伝わっていることがわかる．

程度にもよるんでしょうが，進行方向の速度制御は角速度制御の外乱になると．

あと何個か思いつく限り実験をし，それぞれの影響を定量的に評価できたら，そろそろ自分のハーフマウスの制御も見直しをかけなければ．

Pico

　珍しく長文になってしまった．

　昨年の全日本大会でいただいたPicoを組み立てた．
実は「クラシックマウス」も「ステッパマウス」も作製は初めてである．
はんだ付けや組み立てはマニュアルが詳しいので，特に迷うことなく組み立て完了．

　今回作製した目的として，「スラローム旋回時に車輪が目的速度を完璧に再現できたうえで，マシンの軌道と慣性センサの出力はどのようになるか？」を調べてみたいと考えている．
　というのも，昨年のマウスはグリップ(吸引力)，モーター出力をこれでもか，と上げたので，いよいよ制御が律速要因になっているように思い，マシンの挙動やセンサの出力を一度マトモなマシンでちゃんと見極めてみたいという思いがあった次第．

　今のマウスは「4輪」やら「吸引」やら「非線形出力の磁気式エンコーダ」やら「安物DCモーター」という，理屈がわからないものばかりあるため，信用ならないセンサ出力でそれっぽい動きをするしかないのである．

　上記の目的のため，私のPicoはマイコンボードを自作のものに変更しており，仕様として，ジャイロMPU6500を搭載しマイコンも自分のソフトが移植しやすいようRX→STMに変更している．
(ルネサスのマイコンはH8,SH,RX全ていじったことがないのです…)

　そんなこんなで試走までできるようになった．直線→右180度ターン→直線のコマンドの動画とログが以下．ちなみに全センサの出力はフィードバックしておらず，オープンループで制御している．

動画

ログ

　ログについて，左上と右下がそれぞれ左右輪の目標速度，それに比例するステップパルス周波数であり，右上と左下がそれぞれジャイロの角速度と角度を，目標値と共に記したものである．

　角速度の波形より，角「加速度」がプラスから０，マイナスから０になるときは，オーバーシュートが見られる．車輪の速度は全くそうなっていないのに，である．
　自分のマウスだと制御がかかっているため，オーバーシュートが起こっても原因がわからなかったが，制御と関係なく起こることがわかったわけで．

何となくこういう発見をしていきたく，引き続きこのPicoで遊ぶことにする．

Considering emitter's light process

   Here, I will write about the consideration to the previous experiment.

   The result was that Vector's diagonal receiver catches more light than experimental circuit's horizontal one. This means stronger reflected light comes from the front, though nothing reflects light. I wonder what the emitted light process is like.

   I completely forgot "diffuse reflection". Since maze wall is not mirror, light does not go like the picture below (sorry I'm not good at painting).

   In fact, light goes like this, I think. Here, diffuse reflection occurs and reflected light goes in all direction.

  Because of that light process, stronger reflected light comes from front than side. This explaines the experiment result. And parallel arrangement of IR emitter and receiver is the best, since receiver faces to the direction in that light comes.

非平行センサ試作テスト

前回　横壁センサのフォトトランジスタ(PT)はLEDに平行でなくてもいいのではないか、真横でもいいのでは、なんて書きましたが、今回試作してテストしてみました。
結論から言うと、平行なときより明らかに信号強度が下がり、問題外でした。
一応、何をしたのか紹介します。

下の写真左のようなLEDとPT、抵抗だけの簡単な回路をユニバーサル基板上に試作。テキトーです。
私のマウス「Vector」(写真左)と比較して、LEDはだいたい同じ配置で、PTだけはほぼ真横にしています。横壁のPTだけ調べたいので、前壁用のPTは付けていません。

これをブレッドボードに接続してテスト。Vectorと回路構成は同じです。ブレッドボードの接点抵抗が大きいですし、配線が長いですが。

実際にAD変換してみました。まず、周囲に何もない場合。直接PTに入って来る光量を調べています。
12bitAD変換値はおおよそ　試作：100、Vector：50　でした。

次に横壁から3cmくらい離れたところで実験。
AD変換値は試作：200、Vector：500　でした。

どうも直接光は増えて反射光は減るようで、あまり利点がなさそうだということで、これ以上のテストは中止。

やはり多くの人がやっていることには、それなりの理由があるということで。残念。

壁センサの発光素子と受光素子の光軸は平行であるべきか?

気になります。
前回に続き壁センサの話。
だいたいどのマウスの壁センサもLEDとフォトトラが平行に実装されてますよね。
例えば私のハーフマウス「Vector」だとこんな感じ。

自分としてはこれといった考えもなくみんな平行にしているからという理由で自分も平行にしてましたが、真横とか真正面にLEDを向けない限り壁から光が反射してくる方向はLEDに平行ではありません。

LEDを傾ける角度は横壁センサだと45°とか、ある程度経験的に決定された値を使うとして受光素子はその限りではないなと思うわけです。

横壁センサのLEDは45°に向けるけど対応するフォトトラは真横にしたりするとどうなるんですかね?

①横壁から光が反射してくる方向に向けることで信号強度が増える
②前壁から反射してくる方向に向けないことで干渉を防ぐ

あたりの効果があると思ってます。

そのうちテストしてみましょうかね。Vectorに使ってるLEDが在庫切れですが、、、

マウス的時定数

もう1個ロボット相撲から。

前回のOn_Off制御の話は興味のある方がおられれば話のタネになるかな、くらいだったのですが、今回は自分もマジメに気になった話。


同じように、「モータに電圧がかかってからロボットが動作するまでにどれくらい時間がかかるか知っているか？」と質問を受けたわけですが、そんなことは考えたこともなかったので、調べてみることにしました。

その前に前提として共有したいのはモータの機械的時定数です。モータが回ればマウスが動くだろうという考え方ですね。私はこの程度の大きさだろうと思ってこれまでマウスの調整をしてきました。
例えばMaxonの場合、RE6だと機械的時定数は7~8msくらいで、もっと大きいモータ、RE65だと3msくらいみたいです。

http://www.maxonjapan.co.jp/product_re.htm

私のマウスに使っているモータMk-06-4．5がどうなのかはわかりませんが、大きくても十数msくらいと予想しています。

それでは実際の実験。左右のモータに一定のDutyで電圧をかけ、左輪エンコーダで読み取った速度をログでとりました。左輪である理由は別にありません。

まずは静的測定。停止状態から両モータDuty比10%で1秒間直進させました。

この時の左輪エンコーダで読み取った速度と時間の関係。波打っているのは置いといて、それっぽく1次遅れの応答になってますね。

次に動的測定。停止状態から両モータDuty比10%で1秒間直進させたまま、左だけDuty比30%にあげてそのままぐるぐる1秒間回しました。ジェットコースターみたいな楽しい動きしてますね。

同じように速度と時間の関係。やはり同じような時間をかけて、1次遅れの応答っぽく速度が変わっています。

この二つのグラフから分かるのは1次遅れ系とみなして時定数を定義する場合、100~200ms程度になるということです。モータの時定数の程度という私の予想は大幅に外れ、1ケタ上の値になってしまいました。

ギアやマウスの慣性が影響してるとは思うのですが、10倍にもなるとは思わなかったので、個人的に驚いてます。
こういう結果が得られると、100msに満たない時間で終わる45°スラロームとか、自分のマウスが問題なくこなしているのがなぜだかわかりませんね。

ロボット相撲

関西支部総会で知り合ったロボット相撲に参加されている方から、
「なんでマウスは台形加速なんかしてるの？速さ競うならOn_Off的に出力変えて力の限りかっとばせば?」という指摘をいただいた。

私はロボット相撲をよく知らないので、とりあえず競技を見てみる。
http://www.youtube.com/watch?v=spC_eH8d8zY

なるほど確かに急激に(多分出力の限り)加速して相手とぶつかりあっている。
この速度でマウスが走れば間違いなく無敵。

ただ、どう考えても走行精度は出せず、柱クラッシャーになるだけな感じはある。
一方で、モノにできれば板マウス、吸引、変則4輪のように新たな競技レベルを生み出す技術にもなりうる。

直線走行高速化の意外なネック

Maxonのモータ（RE6など小型のモータを想定しています）ではモータ軸のベアリングは23000rpmが最大許容回転数らしいです。
他のモータがどうなのか知りませんが(データがなかなか見つかりませんが)、だいたい同じくらいではないでしょうか。

最大許容回転数が何を意味するのか分かりませんが、少なくともこれ以上の回転数では劣化が速いのでしょう。

一年計画で走行し調整するマイクロマウスでこのような回転数を与え続けるのは得策ではなさそうですね。

ちなみ23000rpmというとギア比4：1、タイヤ直径12.5mmとすると3.7m/sにあたります。おそらくこの前後の速度をを目標としている方もおられるでしょう。

ハーフサイズ競技の一部で4輪化＆直線の高速化が話題になってますが、あまり減速比は上げられない計算になりますかね。モータを30000rpmとかで回転させようとかいう考え方がよろしくないと、、、