迷路解析ルーチン

　中部地区初級者大会で試走できることを期待して，とりあえず迷路を走れる状態にすることを目指している．今年はハーフには出場しないものの，32*32の迷路に対応した探索ルーチンと経路計算ルーチンを半年前くらいにつくったのだが．．．半年も経つと自分で書いたソースを読んでもよくわからない．参った．

　確か，大きな変更点は最短経路計算のときに，「ターンでは重みを大きくする」というターンに対してペナルティを与えるという考え方から，「直進は長いほど加速できるから時間距離が短くなる」という考え方に変更した．計算時間が長くなるかもしれないが．

　でも結局最後は迷路との相性になるし，賢いアルゴリズムを考えてもそれほど大きく変わるとは思えないし(既にある程度の水準に達しているし)，見ている人からはよくわからない部分というのが悲しいかな．

DCモータの制御(フィードフォワード)

　マウスにおいて最大のパフォーマンスを発揮するためには等加速度の加減速をすることが必要．わりときっちり制御しないと，過剰なトルクがかかってスリップなんてことになってしまう．

今，加速度aで加速(もしくは減速)したいとすると，必要なタイヤのトルクT_tireは
　　　T_tire = a /2 * d
　　　T_tire = m * a / 2 * r_tire
となる．mは機体質量，r_tireはタイヤ半径であり，2で割っているのはタイヤが左右で2つある場合を考えているから．モータが出力すべきトルクT_motorはギヤ比をr_gearとして，
　　　T_motor = T_tire / r_gear.
モータのカタログにのっているトルク定数k_mを用いれば，モータに流すべき電流Iは
　　　I = T_motor / k_m.
そのために必要なモータの両端の電圧Vは
　　　V = R * I + V_r
である．Rはモータの巻線抵抗，V_rはモータに発生する逆起電力で，カタログの発生電圧定数k_eを用いれば，
　　　V_r = k_e * n
となる．ただし，nはモータの回転数であり，一定時間のエンコーダのカウント値からわかる．
実際にモータを制御する際にはPWM波のduty比r_dutyを変化させる．電源電圧をVsとして，
　　　r_duty = V / Vs
である．これで今モータに与えるべきduty比を計算することができる．

　以上はフィードフォワード制御をする場合に役に立つ．というかこれなしではレスポンスが遅すぎて制御しにくいと思う．実際にはこれに加えて目標値とのずれを埋めるためにフィードバック制御もする．

いわゆるシミズのタイヤ

　マイクロマウスではいつからか有名になったシミズ金型のミニッツレーサー用のタイヤ．特にKiatさんが長く使っているというPS-300．ここ数年製造中止になって入手できなかったが，ここを見て販売が再開されているのを知る．さっそく売り切れる前に（売り切れるか?）発注．もちろん5000円を超えるようにたくさん．．．

　さてこれでようやくずっと気になっていた，タイヤのグリップの差を確認できる．

　また，今年はグリップ剤の使用が禁止されることもあり，グリップに関する条件の都合がいい．トップ層との差をつくるものが減った．

数学関数

　こじまうすでは今まで浮動小数点を使ってこなかった．今年もつかうつもりはない．

　それはまあどうでもいいとして，少数ながら数学関数を使いたくなることがある．絶対値をとるABS(x)や符号をとるSIGN(x)はマクロで実装している．それ以外ではデッドレコニングなどに三角関数を使うので，sine(x),cosine(x),tangent(x),cotangent(x)の関数を定義している．
sineについてはuradの単位で角度を受け取り，テーブルを参照してsin(x)の1000倍の値を返す．cosineは角度をπ/2ずらしてsineのテーブルを参照．tangentとcotangentはsineとcosineの割り算の結果を返す．

　整数演算だけだと精度の確保とオーバーフローの回避のために掛け算と割り算が計算式の中にたくさんはいってくる．使う単位はなるべくミリやマイクロといった指数が3の倍数となるようにしてバグが埋まるのを回避しているが，それでもたまに桁を1000倍間違ってとんでもない動きをする．

ジャイロ出力から角速度

　ジャイロセンサはドリフトがあり，ゼロ点がきっちり決まらないという点でやや使いにくい．角速度が知りたいだけなら問題にならなくても本当にほしい情報はその積分値である角度なので，ゼロ点のずれはわりと効いてくる．
　電圧出力のジャイロの場合，AD変換によって得られた値sから角速度ωを計算するには，
　　　ω = k * (s - s0)
となる．kは比例定数，s0はω=0(マウスが停止している状態)におけるAD変換値．10bit分解能のAD変換器を使うとs0は500程度の値を示すが，真の値が499.8だった場合0.2の誤差が生じ，積分すると相当な大きさになることがある．
　この場合には，
　　　ω = k/10 * (s*10 - 4998)
とするなどして十分な精度を確保する．

　これはジャイロセンサに限った話ではないが，エンコーダの場合は速度0でカウント0を示すし，積分しなければちょっとずれていても問題にならないからジャイロ特有といってしまってもよく，わりと見落としがちかもしれない．

バグとり

　5号機のソフトもなんとなくかたちができてきた．というよりも4号機から整理しつつ移植する作業が進んでいる．そうするとひたすらバグをとる時期が来る．ほんの数週間前に自分で書いた計算式の意味がわからない．ソフトは書いたらすぐに動作確認するのが理想的だが，特殊な場合しか実行されないコードのバグは発見が遅れる．

ジャイロ

　こじまうすでは，3号機からジャイロセンサを搭載している．実際に有効に使えたのは4号機からで，4号機では探索，最短走行ともにスラローム旋回と直進走行両方の安定度が増した．

　ただし，優秀なジャイロを使わないとあまり効果は得られないらしい．要求されるのは，

• レンジが広い(1000deg/sくらい)
• 応答が速い
• 比例係数の経時変化が小さい

などだろうか．こうしたことを考えると使える素子は決まってきて結局みんなADXRS300もしくは同等品を使うことになる．優秀だから．高価だけども．

　しかし，思ったほど簡単には使えず効果を発揮するには時間がかかった．

壁切れは必須か

　高速でスラローム旋回するためには旋回半径を大きくするのが有効な手段の1つであろう．しかし，旋回半径が大きいと制御が難しくなるうえに，旋回開始のタイミングをはやくすると壁切れを読む前に旋回しはじめなければならないという問題に気づいた．前回書いたように壁切れなしでは安定して走れないと思う．さてどうしようか．壁切れなしでどれくらいずれるのだろうか．

壁切れ補正

　マイクロマウスの制御において極めて重要だと思っている位置情報の補正方法に壁切れがある．特に高速でターンをするようになると壁切れ補正なしではまるで走れない．シンガポールのマウスなんかはその動きを見ていると壁切れを読み取りにいっているのがよくわかる．

　読み取りに必要なのは，

• 都合のよいセンサの向き
• 確実な読み取り方法

である．
　センサの向きについてはkatoさんが書かれているような方針であらゆるターンに対応できるようにすればよい．
　読み取り方法は確実に毎回読めるようにしようと思うとかなり難しいが，サンプリング周期を短くして，外乱，特にフラッシュ撮影があることを考慮してその方法を考える必要がある．

　厄介なのは，マウスが横にずれていたり，進行方向に対して傾いていたりすると読み取りタイミングが変わってくることだろう．

太陽光の強度

　最近の迷いに決着をつけるために以下の回路を組んで実際にいろいろ計測してみた．

TPS601Aだけを使って太陽光のもとで出力を見ると，

• 太陽が雲に隠れているとき1～1.5Vくらい
• 太陽光が壁に当たっていると少なくとも3.8V

ということがわかった．1kの抵抗では太陽光のもとでは飽和してしまう．

　また，SFH4550に100mAくらい流して計測すると，壁との距離が100mmで0.5Vくらい，近づけると3Vくらいとkatoさんのコメントとほぼ一致する．さらに外乱光が1V分くらいのってようと減算によってほぼ完全に除去でき，TPS601Aは線形性に大変優れていることがわかった．

　ちなみにこじまうす4は直射日光が壁に当たっている条件でも問題なく計測できた．さて，実際の会場が太陽が照ってるときほど明るいわけでもなく，結局どうしようか．

フォトセンサ再考が必要か

　先日の記事の(たぶん)続きの考察をこちらでされている．太陽光相手に計算してもLEDの発光量が十分あることがわかった．直感的には信じられないけど計算は合ってるように思う．

　こじまうすでこれを検討すらしなかったのはおそらく，

• 最大サンプリング周期200usを実現したい
• 迷路のかなり偏ったところを走っていても距離測定をしたい
• 斜め走行時など壁が近い状態でも飽和しない

などと考えていたからだろう．

　最近LEDとセンサが重すぎるように感じてきたので方針転換を視野にいれておく必要があるかも．

フォトセンサ回路の部品点数

前回のBasicMouseのセンサ回路につづいてフォトセンサ回路について考察．
フォトセンサ回路を作るときに考慮することは

• 外乱光をカットして周囲の明るさに関係なく壁との距離を計測できること
• S/N比を高くとること
• 十分な分解能の確保

などを考えるかと思う．
その結果BasicMouseのようなセンサ回路に行き着くわけだが，もっと部品点数を減らせればと思う．

• シンガポール勢が使っている増幅器つきの受光素子を使えばオペアンプまわりの回路を省ける．
• さらにソフトウェア側で定常光成分をカットすればハイパスフィルタも省ける．
• 発光からAD変換までの時間を毎回一定にすればピークホールドも省ける．

かもしれないが，全日本大会決勝の強烈な照明環境を考えると，どうも「十分な分解能の確保」をできる気がしない．
なぜシンガポール勢はちゃんと走れているのだろうか?
もっと明るくなればいいのに．

こうゆう回路を見ると気になってしかたがない.
実際にフル迷路を走れているようなのでもしかしてこれで十分なのか?
ただ，3号機ではセンサで失敗したのであまり攻める気がしない．

BasicMouseのセンサ回路概説

今サークルでは後輩がマウスを製作している．そのついでに基本的なことをメモしておく．こういうベーシックなこともたまにはよく考えておかなければ．
森永さんのBasicMouseのセンサ回路を示す．

まず発光側はコンデンサC2に蓄えた電力で瞬間的に強く発光させる．発光量をかせぎつつLEDが焼けるのを防止できるという点で優れている．
壁からの反射光はTPS601で電流に変換する．フォトトランジスタには光強度に比例した電流が流れる．その電流を抵抗R2に流すと点Bの電位は光の強さに比例した電位になる．
次に，部屋の照明などの定常光成分をカットしてLEDの反射光だけを取り出すためにC3とR4で構成されるハイパスフィルタを通す．時定数は，
CR = 0.01uF × 10kΩ = 0.1ms
この時点(点E)の電圧は大変小さいのでオペアンプで増幅する．この回路の場合増幅率は11倍でC4のコンデンサがあるためここでもハイパスフィルタが構成される．
結局ハイパスフィルタを2回通すためにかなりシャープに定常成分がカットされる．
最後にD1とC5で構成される簡易型のピークホールド回路で信号の最大値を取得する．
これをAD変換器で変換すればよい．
なお，ホールドされた電荷はLEDをOFFにしたときにD2を通して解放される．

また，センサの向きや壁との距離に応じて抵抗値を変更する必要があるが，その場合R2もしくはR5を変更するのがよいかと思う．R2を大きくすると出力は大きくなるが，フォトトラの反応は遅くなる．R5を大きくするとやはり出力は大きくなるがやりすぎるとオペアンプが発振するかも．
ちなみに普通のオペアンプは電源電圧いっぱいまで出力できない．この回路の場合はオペアンプの出力が最大3.5VくらいでD1を通過するときに0.5Vくらい降下して結局3Vくらいまでしか得られない．

・・・長くて自分でも読む気しないな．

0.01g分解能のスケール

R/C Web Shop Kbにてリポを購入した．リポが安いためそれだけでは送料がもったいないと思い，半分思いつきでスケールも買った．0.01gの分解能をもちながら3000円をきっているのには驚いた．正確に量れるのか?

それよりも驚いたのは，24時くらいにネットで注文したら在庫確保のメールが3時間後に来たこと．速い．深夜に(も)仕事されているのだろうか．

STM32のFLASH ROM

こじまうす5で使うマイコンはSTM32F103RE(64ピン)である．
今まで使っていたH8系のものに比べてROMが512kB，RAMが64kBと多くROMの書き換え回数も10k回と十分あるので，外付けのSRAMとEEPROMをのせなくていいのがうれしい．
RAMにログを書き込んでおいてPCに転送して見るのが基本スタイルなので，これよりピン数が少ないものを選ぶとRAMサイズが足りない．

各種パラメータや迷路データはROMに書き込んでおきたい．そこで内蔵ROMの一部を記録用に使う．一見問題なく書き込めたように思えたが，消去中および書き込み中にはDMACが動作せず，ADのサンプリングで予期しないことが起こってしまった．サンプリング毎にDMACでデータ転送しているのだが，転送されずに次のサンプリングが始まってしまうようである．

データシートによればword(4bytes)書き込みに最大70us，消去に最大40msかかるらしい．時間がかかるのは仕方ないがその間ペリフェラルとRAMでDMA転送ができないとは．

ところで，STM32は今後流行りそうな気がするが，これにいち早く着目し導入を検討されたのはおそらく綿谷さんであろう．そのブログの情報は大変参考になります．katoさんはそれにつづいてSTM32を採用し，相当な速度での走行を実現するに至っている．今年の大会までにはもっと増えるのだろうか．

マイクロマウス2008(サイエンスチャンネル)

サイエンスチャンネルにて昨年の大会の番組が配信された．
確かに優勝マウスのMIN5はものすごく速いが，他にもっとターン速度が速く"見える"マウスがいたように思う．思い込みかもしれないが．
旋回半径を大きくとると速度が大きくてもそれほど速く見えないことがあるがその影響だろうか．

そういえば昨年の迷路は走行の難易度はそれほど高くないものの，最短経路計算は極めて難しく，明らかに最短でない経路をとってしまったマウスが多かった．こじまうす4もその1つかもしれない．特に予選の迷路では最適な経路を選んだマウスはほぼ皆無だったのではないだろうか．

ARM用GCCのコンパイル

5号機ではマイコンにSTM32を採用する．コンパイラにはgccを使う．以前にgccのクロスコンパイルをしてなんとなく動作していたが，ライブラリが浮動小数点演算ユニットを使うコードしか持ってなく，ライブラリのリンクができないことに気づいたので再コンパイルした．

コンパイルは検索で引っかかったこことここの内容にしたがって行った．

総合開発環境を使えばこんな苦労は必要ないのだろう．
windows上では多くの開発環境があるらしいが，制限が無く無料なものとしてRaisonance社のRIDEがいいかと思う．