CONTENTS -- 最終更新:2009-05-06 (水) 01:51:21
このロボットは2008年で29回目となるマイクロマウス大会に出すことを目的に製作した.
長さ | 115mm |
幅 | 70mm |
高さ | 23mm(配線除く) |
質量 | 108g |
CPU | H8SX-1653 |
SRAM | 128kByte(8bit) |
モータ | ミニモータ1331T006SR+IE2-400 |
ギヤ比 | 14:36 |
電池 | リチウムイオンポリマー(7.4V 200mAh) |
リチウムイオンポリマー電池
INTELLECTにて7.4V200mAh5Cのものを入手.3号機に使っていたのを流用しただけ.各種保護回路が入っているらしいから安心.
ジャイロセンサ
マウスの世界ではお馴染みのアナデバのジャイロADXRS300.ハンダ付けできないのでベステクの実装済みのものを利用.ゼロ点や感度の係数が変化しにくくかなり正確に角度を得られる.どうやら他のジャイロセンサではそうはいかないらしい.壁や柱に激突しても走り続けられることがあるのはこのジャイロのおかげである.
また,基板上のローパスフィルタを構成しているコンデンサは応答速度向上のために取っ払い,また感度をおとしてmax300deg/s --> max900deg/sとして使っている.
こじまうす4はこんなふうに走る!
2008/10/28(中部地区大会)
2008/11/21(全日本大会試走会当日早朝@機械研迷路)
2008/11/23(全日本大会決勝)
中部地区大会10/26 | マイクロマウス競技 | 7秒117 | 準優勝 | (上位の人の表彰辞退により繰り上げ) |
サーキット競技 | 12秒467 | 7位 | ||
全日本大会エキスパートクラス決勝11/23 | 7秒428 | 8位 | ニューテクノロジー賞 |
低コスト高性能マウスのキーである.ただし,超高性能マウスにはなれないかもしれない.
こんなかんじ.局所的には密度が高いところもあるが,全体的にはスカスカのところも多い.
以下の内容について書くつもりだったが,5号機をつくるときに書くことにする.
機械研標準のH8-3069に比べ次の点で優れている.
磁気式エンコーダ付きDCコアレスモータ
光進電気経由で注文.2個で4万円弱.痛い.
ホイールとタイヤ
ホイールはアルミ丸棒を機械研卓上旋盤で削り出した.そこにオリジナルマインドで買ったモジュール0.3の歯車とベアリングを接着剤で固定.
タイヤは京商ミニッツの20度スリックナロータイヤ.あまりグリップがないように思う.
注意:ここで使っているゲートドライバICのTPS2836はフルブリッジを想定してはつくられていない.そのため電源ON時や正転逆転の切り替えの際に全FETがoffになって身動きがとれなくなる.変なところに20Kのプルダウン抵抗があるのはこれを防ぐためである.
キーワード
壁の検知もさることながらマウスの姿勢を把握する上で極めて重要なフォトセンサについてじっくり考えてみる.最近では外乱光除去を確実にしつつ回路の部品点数をいかに減らすかがポイント?
前センサ
前方の壁を確実に見分けることと前壁によりマウスの傾きを検出するために,マウスの先端付近に2つつける.
斜めセンサ
素朴に考えるとなぜセンサを斜めに向けるのかと思うが,その意義は次のとおり.
横センサ
横向きのセンサに関しては以下のとおり.
横センサは本当は真横に向けたいが,壁に対して垂直に光を入射すると反射率が大きい一方でわずかでも垂直からずれると反射して返ってくる光は急激に少なくなると考えられる.距離測定がうまくいかないのであえて真横から20度程度傾けて配置する.(10度ではダメだった)
赤可視LED
まあ可視光である必要はないが,赤外である必要もなく,使い慣れていて光軸のはっきりわかる可視光のものを使う.3.3Vで抵抗をかまさずにFETで駆動する.保護回路を入れ忘れたのでソフトのバグによってLEDが死ぬのが難点.LED自体は100円だけど交換がたいへん.
090223追記-回路図にあるLEDは大電流のパルス駆動には対応していないので使い続けていると死にます.
フォトダイオード
いままではフォトトランジスタ(TPS601A)を,簡単に使えて入手性がよいという理由で採用していたが,フォトトラは信号の大きさによって反応時間が変わるという特性があり,この点で外乱光の除去が困難であるので今年はフォトダイオードを使う.今回使った素子は1個100円くらいなのでコスト面でも助かる.
1次パッシブハイパスフィルタ+オペアンプによる増幅
外乱光が強すぎて飽和してますなんてことにならないよう,まず外乱光をカットしてから必要な信号のみを増幅する.
注意:FETをonし続けるとLEDが焼ける.
数年前から全日本大会の決勝に限ってフラッシュ撮影をしてもよいことになった.
一瞬強烈に光るのは性質がわるいと思いつつもたいして対策をしてこなかった.
明確にフラッシュのせいで走れなかったマウスを見たことがない上にフラッシュがどれくらいの時間光っているのかよくわからなかったから.
ただ今年も決勝が走れないなんていうのはごめんなので,フラッシュ撮影してみた.
全センサが見事に機能していない瞬間がある.単純な判定基準では壁切れだと勘違いをするから注意.
こじまうすではマウスの加速度aと角加速度a_angを操作することによって走行の制御をする.
角加速度a_angを操作することによって進行方向に垂直な方向のずれyを0に制御したい.フィードバックされる情報から操作量a_angをいかに計算するかがここでのテーマである.まず,a_angを与えることによってyがどのように変化するかを確認する.
角加速度a_ang ↓ 積分 角速度v_ang ↓ 積分 角度x_ang ↓ マウス速さv × sin(x_ang) ≒ v×x_ang マウス速度のy方向成分v_y ↓ 積分 中心からのずれy
ここで注目すべきなのは,a_angを与えてからそれがyに反映されるまでに積分が三回あるということである.一般にばねの振動のような2次遅れ系ならば,有名なPID制御によってyを0にまるめこむことは容易である.しかし3次遅れとなると発散しやすくなりそう簡単にはいかない.しかも速さvによってもyは影響を受けるためにさらに複雑である.
ここでは簡単のためにv=一定であるとする.そうすると,フィードバックする必要があるのはy,x_ang,v_angの3つが考えられる.PID制御から連想して単純に考えてみると,
a_ang = - P * y - D * x_ang - D_2 * v_ang;
のようにa_angを決定してやればよいのではないか.a_angによって影響をうけるものをすべて使ってるんだからなんとかなるでしょ.
ちなみに上の式には積分制御がはいってないが,基本的に積分制御は不安定を生むので,必要がなければ使わなくてよい.マウスの姿勢制御には経験的には必要ない.
さて,上記Iではマウスの傾きx_angとy座標がわかっているとしたが,実際にはそうはいかない.横フォトセンサの出力はx_angとyの2つによって変化する(s=s(y,x_ang))ため,センサの値1つからx_angとyの両方を得ることができない.ということで,やむを得ず次のようなコントローラを考える.
a_ang = -Ps * Y(s) - D_2 * v_ang;
ここで,Y(s)はセンサ出力sに対応する傾き0のときのy座標である.つまり,Y(s(y,0))=yである.
傾きが0の条件でセンサ出力sとそれに対応するy座標の関係はあらかじめ近似式とかテーブルとかで準備しておく.
sはyとx_ang両方の関数s(y,x_ang)であり,センサ値をそのまま制御に使うと汎用性に欠けるので,Y(s)に変換してから制御に使おうと考えている.こんなものは必要なくセンサ値をそのまま使っても何ら問題ないかもしれない.
この制御が有効かどうかは,Y(s(y,x_ang))がどんな関数であるかによる.イメージをつかむために1次近似して,
Y(s(y,x_ang)) = y + k * x_ang
とする.k(の絶対値)が大きいほど傾きにたいして敏感にセンサ値が変化することになる.このkはセンサの壁に対する傾きとマウス上の配置で決まる.ハードウェアを作った時点で決定している値である.おそらくこのkが大きいほど制御がしやすく,kはセンサがマウス先端についているほど,また壁の法線に対する光軸の傾きが大きいほど大きくなる.また,レーザ光を使っても大きくなるらしい.
ちなみにこじまうす4ではk=0.15(y[m],x_ang[rad])程度であり,やや小さいので制御しにくい.設計ミスかな?
こじまうすでは1号機からずっと
直線→クロソイド曲線→円弧→クロソイド曲線→直線
を基本とし,スリップは起こらないとして旋回の制御をしていた.しかしながら,ジャイロセンサの出力を見ると相当スリップしているようだ.
コンパイルは,
Windows+Cygwin+GCC
binutils-2.18+gcc-4.2.3+newlib-1.16.0
C++を利用できるようにした.
ソースコードの編集はサクラエディタ.不満点も多少あるが,タブ型とSDIを同時に使い分けられる点がすごくいい.
マイコンとの通信はteraterm.
GCCがH8SXに対応していると信じて開発してきたが最適化をかけたときに使用されるmova命令に問題がある.@(d,r2l.b)は@(d:32,r2l.b)と認識してほしいのに@(d:16,r2l.b)になる.
コンパイラが@(d:32,r2l.b)と指定していないのが不具合なのか,アセンブラが勝手に16ビットと思い込んでるのが問題なのか.
そもそもアセンブラはH8SXに対応しているとは書いてないような気がする.
仕方ないのでH8S用のコードでコンパイル.
GCCのバージョンをあげて,
binutils-2.19+gcc-4.3.2+newlib-1.16.0
とすると,
#pragma interrupt void func() { ... }
と書いても適切にコンパイルされない.
gccのドキュメントを見ると,「gccでも#pragmaでコンパイラに指示を与えることはできるが,そもそも他のコンパイラ用のコードを利用できるようにしてあるだけだ」というようなことが書いてあった.gccでは本来__attribute__を使うらしい.
H8系の場合は割り込み関数であることをコンパイラに知らせるのに以下のようにすればいいらしい.
void func() __attribute__((interrupt_handler)); void func() { ... }
2008/06/01 サンハヤトのガラスエポキシ両面感光基板を利用してプリント基板を自作する.が,銅箔に無数の穴があり,断線多数.失敗.原因としては,
6/14 プリント基板製作に再挑戦.今回は成功か.
6/29 ほぼ全てのモジュールがそれらしく動作することを確認.ハードウェア完成か.
7/5 今年もパソコンの故障がやってきた.
7/6 パソコンを分解するも原因は不明.しかしいじってるうちになぜか動くようになっていた.
7/12 パソコンの故障再発.今回はかなり詳細に調べてみる.
7/13 どうやらメモリとのアクセスがうまくいっていないらしい.静かに放置しておくと動作し続けるが,少し傾けるとエラーがでる.接触不良か.マウスの作業は進まない.
8/3 センサ用LEDの大量死.やってしまった.
8/11 パソコンがまた調子悪い.今までよりさらに悪い.マウスの作業としてはセンサホルダ作成.
8/15 横センサと斜めセンサの値から傾きを求められるようになる.が,傾きが10度を超えると正確に測定できないどころか逆符号になることもある.設計ミス.
8/17 いまさらながらコンパイラかアセンブラに不具合発見.
9/7 最近は壊れかかったパソコンの分解に時間を費やしていたが、このままでは間に合わないのであきらめてマウスの作業を再開.で、バッテリの容量が足りない可能性に気付く.
9/14 ソフトが複雑になるに従ってバグは急激に増える.しかし,予想以上にバグが多い.センサ用のLEDの1つが妙に暗い.壊れたかもしれない.
9/15 バグとりを少し.
9/28 だいたい走れるかも.フォトセンサによる姿勢制御がいまいち.
10/4 今年は32ビットマイコンのH8SXの採用とクロックも25MHz --> 50MHzとアップしたので演算能力は飛躍的に上昇した.が,高速域での姿勢制御をするにはもっと高速に処理できる方が望ましい.
10/5 c言語で,ビット演算子&は等価演算子==よりも優先度が低い.よってちゃんと括弧をつけないと次の式は意図したとおりにコンパイルされない.知らんかった.
status & 0xff00 == 0xff00;
昨年はちゃんと括弧をつけていたようだ.
10/6 中部地区大会まで3週間をきり,そこそこ走れる目途はついた.が,試走の機会がほとんどないかもしれない.やはり本番と同じ材質の迷路を使えるのが年に数日(数時間?)しかないのは悲しい.
10/10 AD変換にはマイコンのADコンバータを使っている.レギュレータにより5Vを生成し,抵抗により分圧してref電圧は約3.3Vとなる.これが失敗で,refは意外にも電流を食うらしくサンプリング周期によってref電圧が変化する.refになっていない.
10/13 全日本大会の登録をした.142,143番だった.
10/18 時間が足りない.斜め走行が決まらない.今年はものすごくたくさんバグがあるように感じる.絶対数が多いのか,発見能力が向上したのか.
10/24 中部地区大会まであと2日.高速化のためにホイールを作り直す.が,最後の最後で加工ミスにより歯車の歯が欠けた.
10/26 中部地区大会.それなりにちゃんと調整して持っていったが,本番の迷路と違う環境で調整しても仕方がない.まあ,それなりには走ったし,迷路の壁の情報とか持って帰れたし,本番前のばたばたしているときに2つもバグを見つけられたしよしとする.全日本大会までには環境の変化に弱い制御を排除して,短時間で本番の迷路に最適化するための調整用のプログラムをつくっておかなければならない.
11/2 気づけば11月だ.今日は車軸を作った.後はホイールを作れば満足いく足回りになる.
11/3 フォトセンサの特性と使い方についてじっくり考えてみる.機械研迷路と本番の迷路の壁の特性がだいぶ違うことは先週の大会でわかった.で結局このマウスで斜めセンサと横センサから傾きを得ようとするのはイマイチであると結論した.
11/6 いまさらながらホイールの設計.あと直進時の姿勢制御について考えてみた.結果,マウスの傾きに敏感に反応するセンサは有利だという結論に達した.
11/8 ホイールを削る.これで足回り完成.
11/9 まあまあ走る.あとは確実に調整していけばいい.時間がやや足りない.
11/11 こじまうす4の欠点はステッパー時代の感覚を引きずっていることかもしれない.
11/12 あちこちのブログで,予選突破は10秒切らないと厳しいだろうとある.いつのまにかそんなにレベルが上がっているのか.しかし昨年の予選突破ラインは13秒339だった.公式ページの記述は間違っているが...
11/15 まずい.3号機より遅い上不安定.ハードウェア性能は格段に向上しているのでソフトの問題.時間が足りない.圧倒的に.
11/16 かなり走るようになってきた.が,中部地区大会ではそう思いながら本番の迷路ではふらふら走っていた.支部が活動している地区がうらやましい.
11/21 前日の徹夜を経て今日は試走会に参加.中部地区大会で失敗した後相当考えて環境の変化に強くしてきたが,その成果かほとんど調整なしである程度走れた.シンガポール勢のターン速度はちょっと無理.
11/22 予選.4号機はシードマウスなので今日は出走せず.
11/23 決勝.昨年センサ回路の設計ミスで失敗した探索走行は全く問題なく完了.最短走行もスリップして壁にぶつかるパラメータまで走れたのでOK.次はグリップの確保を考えなければならないようだ.
11/24 そういえば全日本大会でパソコンとマウスが両方ちゃんと動作したのは4年目にして初めてだ.結局ものを言うのは金なのか.
12/1 今年の大会では全く予想していなかったニューテクノロジー賞をいただいた.特に新しいことをしたわけではないと思うが,確実な技術の蓄積が評価されたらしい.ということで4号機をつくる過程で得た知見をいくつかまとめようと思う.
12/14 GCCのバージョンを最新版である4.3.2にあげた.なんとなく.動作しなくなった.めんどいな.
12/16 3日間かけてGCCのバージョンアップに伴う不具合を調査した.何が起こっているのかわけわからないときはだいたい割り込みまわりのバグであることが多い.#pragma interruptがダメらしい.詳細は上の記述参照.
2009/5/2 5号機開発のため(モータを使いまわすため),解体されました.