バランス取り

ファンのバランス取りの様子。ミニ４駆の部品（側壁用のタイヤ？のホイール）を２個づつ少しずらして取付その間にシャフトを通したファンを載せる。　軽く回転をさせて様子をみて、止まった時にしるしをつける。下に来る方を少し削ってまた同じことを繰り返す。
バランスを取ることにより　音が静かになる、ログを見てもタイヤの速度が安定する（きっと振動でグリップが不安定になっていたのだろう）などの効果がある。

------------------------------------------------------------------------------

JDE for ARM を　開発用のメインのPCにインストールした。　現在の環境は残したままで大丈夫そうなので実行。　
モニタの書き込みから　定番のHellow Woldの表示に成功。
ただ　リセットすると　Hellowが転送されてくるはず（？）なのに　送られてこない。　リターンキーを押すと　Hellowが来る。　こっちがあいさつするのが先かい！態度でかい？　なにか誤解しているのか？

日記１１月２９日

本日のmomoco

吸引を始めた時からずっと使っているファン。
momoco09では　外形をずいぶん小さくして　真ん中の穴も大きくしている。
ファンの径が大きいとモーターへの負担が大きく回転が上がらないと考えたで小さめに。中央の穴はモーターが入り込むので　空気の通り道を確保するために広げている。
元々は　カークリーナーのファンです。　これです。
http://store.shopping.yahoo.co.jp/ktnet/321006305.html
もも太郎と言う名前だったのは今気づいた。
もうすでに片手では済まない数を購入して分解している。本体はすでに廃棄されているので手元にはないので　加工前のファンも、内部の様子も写真無いです。
次回は　ファンのバランス取りの様子の予定。

------------------------------------------------------------------------------

STMの　開発環境として取り組んでいるのは　今まで同様JSDのJDE。
HOMEページにはまだ　製品としては公開されていないのですが　STM32を載せたCPUボードが存在する。大会ではそれを頂きました。
その開発用として　JDE for ARM　をダウンロードしたのがスタート。　紹介をする許可を頂いたので、、、。
http://jsdkk.net/download/jde/help/cpuboards/cpuboards.htm
JDEも最新版がダウンロードできます。
かなり優しいと思われる解説もあるので　本来なら簡単に使えるはずなのだろうが、、、
きっと（自分が）想定外のSPECなのだろうがなかなか大変だ。

色々見ていると　このようなページも見つけてびっくり、勉強させて貰います、、。
http://jsdkk.net/mycom/?page_id=2

日記１１月２８日

タイトルは手抜き。

今日は片づけ、買い物などで実作業は少し。　当然進捗もあまりなし。
なかなか参考資料の様にならない。

momocoが拍子に載りました。
http://www.ohmsha.co.jp/robocon/archive/2010/11/-2011.html


新マウスはなかなか進展しないと思うのでしばらくはmomoco09のアップを公開。
文字ばかりでは見栄えしないので。
まずは　普通のアングルで

苦戦中

STM32を使う為の環境構築に挑戦
現行のSHの環境を残さないと困るので　念のためにこの間まで使っていたノートPCを引っ張り出して来てそちらでテストをしてからと思ったのだが、、、、

やはり　簡単にはうまくいかない。

-----------------------------------------------------------------------------

全日本の大会の時に「勉強してください」と頂いたボードを使う為に昨日の夜からずっと。
時々　逃避したりしているけど　結構な時間を割いているのに　進展が今一。

JTAGで通信をする事が出来ない、CPUと話が出来なければ　文字通り　話が始まらない。

新型構想＿CPU

CPUは　最近マウスで使われることが多いSTM32系に挑戦したい。
環境が変わるのは荷が重いが大会中に聞いた事、ちょっと調べた所では苦労する価値はありそう。
しばらくは情報収集にいそしむ。

心機一転

今日からいつもの生活に復帰。
トラブルの原因も判明（壁を作った原因は予測でしかないけど）して結構すっきり。
新しい機体も作らず地味な活動の結果、勝負にこだわって無残な戦績。ちょっとへこんだけど、、。

今日からはマウスの２０１１年度スタート。
今年は好きなように楽しむことにした。作りたい物を作るために勉強して、作ること自体を楽しむ。
勝負に関わらないと言うつもりもないけど　新しい機体を作ろうと考えるとわくわくしてくるのでやっぱり　ものつくりの方が興味の対象だなぁと実感しているところ。

まずはコンセプトを考えよう。

大会終了

２０１０年の大会スケジュールが終了。
せっかくシードを貰ったのに最短走行できず。相変わらず全日本では消化不良感。
自分はともかく　久しぶりに日本勢がクラシックを制したり新たな風が感じられる良い大会でした。
大勢の方の尽力に感謝感謝です。　本当にありがとうございました。

-----------------------------------------------------------------------

帰宅、明日は休みでないが、今日は休みを取ってあるのでゆっくり。

今年は結果と言うか勝負にこだわりすぎた。それで結果が無いとがっかり。ハードを継続した分、小改造とチューニングなのでベクトルが過程でなくて結果の方に比重が行ってしまった。
マウス本体としてはすでに時代遅れなのを再確認したので　この後はしっかりと代替わりを考えよう。　やること覚えることが多いと過程が楽しめるので　そちらの方が精神衛生上もベターだろう。STM32を搭載したボードを頂いたし、勉強しないとなぁ。

-------------------------------------------------------------------------

原因判明
最短走行が出来なかった理由が判明した。
いくつかの複合みたいだ。
・無い壁を作っていた。ゴール区画の中に１枚壁がなぜかある。ただし、最短経路は残っている。
・袋小路をふさぐ処理をする。本来はゴールの中は空なので袋小路ではない。しかし、壁が１枚あるので袋小路が出来る。そこから順に塞いでいくとゴールに入れなくなる、、、。
１か所の誤検知がゴール区画内だったために起きた事らしい。
うーーーーん、参った。

大会当日

大会当日の朝。
昨日までの観戦で周りの進化を感じる。マイナーチェンジが通じるのも今年まで、電気系のフルモデルチェンジをしないことには先はないなぁ。
思いっきりプレッシャーをかけられ続けたけど、結果はもうすぐ判明する。
そろそろ出かけよう。

今週の本職は終了

明日は予定通りお休み。　
マウスモードに切り替え。
昼前に出れば良い時間にホテルに到着できる。　まず立体駐車場を確保してから会場入りの予定。
長めの斜めの調整だけはやっておきたい。
参加するみなさん　会場でお会いしましょう。

最短経路続き

最短経路の比較
２００８年決勝の迷路の例
通常使う予定の「最適経路」上位のマウスが選んだ経路

タイム的に一番最速になる「最速経路」momocoが選んだ経路、ちょっと難しかったみたい

昨日作った「直線優先経路」


最速と最適は一致する事が多い。違う場合でもタイムはそんなに違わない。なのでコマンドを増やさないため　競技用に準備をするのは　「最適」と「直線優先」の２つに。
改めて決勝の迷路は経路の選択幅があって面白い、、なんて余裕言っていて大丈夫か？

直線優先

今更ながら　直線優先の経路を選べるようにしてみた。
トライの回数が十分に取れる時でもないと使用しないだろうが　もしもの時にあっても良いかと思って。　もともと重みを変えて等高線MAPを作り経路を数種類（ダブりもあり）作り　斜めを含んだルートに翻訳してから　ターンの種類や直線の長さなどを考慮して「最適」経路を選んでいる。最後の評価の時の配点を変えると別の個性を持った経路が選べる。　なのでノーマル直線に配点を小さく（点の少ない方を選ぶので）すると　直線優先が選べる。
重みを変えた等高線MAPがベースなので最短の歩数では無いルートも候補に上がる。
「最適」を選ぶと　過去の迷路でほぼ優勝マウスの選んだ経路を選択できる。
今回用意した「直線優先」を選ぶと結構遠回りでも直線をつないだ経路を選ぶ。保険としては使えるかな。
去年は探索の後、経路の算出に異常に時間がかかりトライが出来なかった（予選）。しらみつぶしに経路を作って評価していたので案別経路が多いと時間がかかった。普通はそんなに候補がないはずだが去年の予選は相性が悪かった、、、。　今年は　重み付けの種類しか案別がないので　たしか１０種類だけ評価。これなら見た目には待ち時間なしで終了する。
実は今年の進歩はこれが一番だったりするかも。　

去年の迷路

例によって各所を拝見させてもらっていると　サイエンス・チャンネルで去年の大会が見れるととの情報。　さっそく見てみると　去年の決勝はあんな迷路だったか、、、。　斜めの長いのが連続で。
あの斜めは自宅サイズでは試せない。　全日本になると斜めを嫌がる様ではだめなんだと改めて実感。金曜日に試すしかあるまい。　それでまともに走れれば良し、ダメなら、やばいかもしれない。
不安の種は尽きない。

まだまだ見つかる

重ね探索の変更を確認するためにセミクォーター迷路を広げた。
変更は　今までは重ねの時も最初は足立でゴールを目指した。それをゴールが出ていれば全面探査にすぐ入る様に変更。全面は一番歩数が少なく見に行ける未探索区画に向かう仕様。なのでゴールに向かうと全面探査終了までには時間がかかる可能性がある。　とりあえずゴールに向かう方は別のゴールまでの経路が早く出ると言う事。失敗の可能性が高い時には少しでもゴールに向かう経路を増やしたいのでそれも悪くないのだが、、、。
選択できるようにしても競技中は冷静に考えられない可能性が大なのでまぁ決め打ちで。１回の探索で決められれば必要のないことなんだけど。

探索の確認は　問題なく機能したのでOKだったのだが、、　
もう弄るのはやめと思っていたけどせっかく迷路をひろげたし　と思って最短走行を試すと　失敗。大して難しくも無いのに。速度を下げてもゴールはするものの壁に接触したり。
やばいので真面目にログを取って見てみると　斜め直線で　横センサーでのエッジが読めていない。ターンに入る前に内側のエッジ検出MUSTがあだになりそのまま直線走行を続けてします。待ちの距離に制限を設けてあるので永遠に直線ではないけど遅れてターンに入るので失敗したり、接触をしたり。
原因は斜め直線で横センサーのエッジを見ようとした時に　やはり柱の手前、後ろ、両側に壁がある時で反応の仕方が大きく違う。　エッジを見る時は後ろに壁のあるなしが影響大。
斜めセンサーだと角度が点いている分後ろ側の壁はほとんど影響がない。（斜めセンサーの場合は手前の壁が影響大だけど）　その結果　後ろに壁がありそれを検出している間にエッジの判定範囲を超えてしまった（らしい）。　今までなぜ気付かなかったのかは不明だけど　出やすいパターンとかあるのかもしれない。
対応は　斜めの直線では横センサーでの距離の補正はしない。斜めセンサーのみ。もともと斜めは走行路が狭くズレによる誤差が出にくいのでOKだろう。　また斜めだと最後の区画で検出せずにターンに入る事があるので　MUSTの検出も斜めの直線ではOFFにする。　
これで今回問題になった経路はちゃんと走れるようになった。やはり簡単で短いからエラーが無ければ危なげなくゴール。
調子に乗ってMAXを試すと別のルートを選んだ、、
確かに速度パラメータも考慮して経路を選ぶようにしているけど　今までは速度によって実際に選ぶ経路が違う例はなかった気がする。　後でシミュレータで所要時間を比べてみるかな。

何にしてもさらに　問題が見つかったのは収穫。
メモ代わりにMOVIEを貼り付けて　今後の調整のパターンの１ケースとして記録。

速度は中部大会と同じ
こちらが修正前のトラブルケース　斜めの直線からターンに入るのが遅れているのがよくわかる。

まだ見つかる

大会前の最後の週末
大きな作業テーマは無し。
タイヤも結構ぼろぼろになっているがここでの変更はパラメータへの影響が不明なのでこのままとする。　バッテリーは新しいもので問題がないと思われるので　この週末に新しいのをパックする予定。
スカートも少し擦り切れてきているがこちらも変更のリスクの方が大きいのでそのまま。思ったより耐久性があったので夏に作ったまま。

作業は昼過ぎから　ぼちぼちと　斜めの調整から。　中部前に柱の手前に壁がある場合と裏側に壁がある場合の　場合分け姿勢制御をあわてて実装した。　その再調整。　壁が裏＝柱のみ　なのでこちらは再調整の必要はなさそう。　手前に壁がある場合は　急いで決めた定数はベストではなさそう。
ところが　変な補正が入る時がある。　ログをチェックすると、、、
斜めの直線では柱が左右交互にやってくる。　なのに柱のない側にエッジのフラグが立っている。フラグが立つとその時に柱によるセンサー出力のピークを計算する。　もちろん本当は柱がないのでピークと言っても全然低い。　結果柱から離れすぎと判断してそちらによってしまう。　最大制御量にリミットがあるので　とんでもなく飛んでは行かないけれど変なズレによりその後の軌道が乱れる。
エッジが立つのは　柱の判定の閾値が低すぎるので　斜め用に閾値を新設定して　少し高めにした。

さらに、エッジフラッグの２度だしが発生。２度目のエッジではピークが一度リセットされているので本来のピークよりずっと低い値（柱を過ぎているのでバックグラウンドレベル）になる。なのでこの場合も変な補正になる。　こちらはフラッグをクリアするタイミングが変だったために起きた事が判明。　無駄に色々な変数をログしていると不意に起きた事象でも解明できる時がある。

単純ミスじゃないバグも残っている。　本当の所　あとどの位眠っているのか。　ソフトは怖いなぁ。

-------------------------------------------------------------------------------
斜めの調整を終了
壁が手前にある時の閾値が低かったのを少し上げ。真ん中を通っている時に補正量があまり発生しない様にしただけ。　中部の動画ではちょこちょこ機体を振っているのでこれで少し収まるはず。

各所を見に回っていて思い出させられた（良かった）。
決勝は５分だった。　決勝の経験が少ないので５分のイメージが今一。７分あれば　トラブルさえなければ全面探索＋４回トライは　難しくない。　が５分だとかなり短い。　唯一まっとうな競技が出来たおととしも４本の最短は出来ていない。　とは言っても　今更探索早くも無いので　トラブルがあった時にどうするかを準備しよう。
�@基本の探索：（変則）足立でゴール→全面探査、タイマー２１０秒
�A重ね探索：タイマー１２０秒
�B重ね探索：タイマー６０秒
と言ったところか。　重ねはゴールまでのMAPが無いと足立から、あれば全面　を自動選択にして。

最短走行は　無駄に段階が一杯用意してあるので　どこら辺を使うか　
�@東北大会�A中部大会�BMAXの順で　失敗をしたらそこから少し下げるとすると、やはり最低で３本は最短をしたい。　やっぱり探索が１発で成功するか、、がポイントだなぁ。

またバグ発覚

斜めの姿勢制御の中で「センサーの値が閾値より大きい場合」
if(センサー値＞閾値）が何故か　if(センサー値＋閾値）になっていた。
これだと　いつも正になり　補正が入る→センターを通っていてもふらふら。
右側だけなので半分は正常に働く。
これが全てではないけど　一つの要因だったのだろう。

怖いのはこう言ったミスが他にも入り込んでいること。
「他には無い」と言うほどの自信は全く無い。
以前には　if(A==B)のところが　if(A=B)なんて言うのもあったし。

帰りのルート

帰りのルートを算出できた。　と言っても単純に最短の経路の逆をたどらせるだけ。確実で簡単な方法だ。スマートじゃないけど。　シミュレーションでは問題ない。　動作の確認はまた週末。


去年のlogをチェックして少しがっかり。
今年　まぁ使えそうなパラメータは去年のTOPパラメータよりも低いのに気付いた。さらになぜだかターン入口のDUTYも飽和していないか、していても少しだけのようだ。　ターン前半の速度追従性がはるかによい。　今年は速度を上げて調整をトライしたけど実用的な所まで下がってきたら去年とあまり変わらなかったと言うおち。　安定度は上だと信じたいけど、、。

------

若干　体調不調

東北、中部で起きていたターン進入位置のズレの原因はつかめていない。
可能性としては　エッジの見落としが一番わかりやすいのだが、、、。
ターン前が壁なのでエッジを見落とす可能性は低い
進入位置の指示間違い　これも突然一か所だけ、、は変。
ターン走行距離での補正が入っていなかったのが判ったのでターンが大きく乱れるとターン終了の位置がずれた時の補正がない。ターンが伸びた（方向が定まるのが遅れた場合）は次のターンの進入が遅れる。その場合はエッジで補正が入るのだが、、、。
最後のターン内側のエッジは必ず存在をするので検出MUSTとしている。そのため見落とすとずっと待って進んでしまう。横センサーのエッジが出るまでは進む。横センサーはセンサーが近いし角度もついていないので斜めより確実。とは言え高速のターンでは横センサーのエッジではすでに遅い。

などなどを考えて検出MUSTを外すことにした。一番早くターンを始める４５度ターンでも斜めのエッジから２０ｍｍほどの余裕があるので　その２０ｍｍの間にエッジが見えれば補正される。それ以上ずれた時は待ちきれずにターンを始めてしまうわけだが　そもそも２０ｍｍもずれている時点でかなり無理な事になっているはず。　そこを捨ててでもエッジ見逃しによるターン開始の遅れを嫌ったわけ。　エッジ見逃し、２０ｍｍ以上のズレ＋４５度ターン　と言うレアなはずのケースの事なのでいずれにしても大勢に影響は出ないはずなのだが。

---------------------------------------------------------------------------
ログを見ていて気付いた左斜センサーの出力がおかしくなる時があるみたい。　そう見えてからだと全体的に怪しい。　時々ノイズがのるという時と横センサーの値に対して低すぎる時と。
例によってハードのトラブルか。左斜センサーの回路を再度半田ごてでなめてみる。結果、きれいになった気がする。エッジも正確に検出できているようで走りもベターになっている（みたい）。
と言う事で前言撤回、必須エッジ検出は残す。　

競技そのものには影響が少ないのだが最短走行からの帰りが出来なくなっている。　探索からはOK。どうも帰りの経路を求められていないみたい。　今年は最適経路の算出を完全新作したけどその際に帰りの経路算出に影響が出ていたのに気付かなかった。　競技ではゴールのマウスを取りに行くより自分で戻ってくる方が時間の節約になると思うので　再度ちゃんと整備しないと、、。もちろん戻ってくるマウスの方が知的で賢げに見える（本当に賢い）ので。　吸引マウスは帰りの為だけにターンをチューニングするので（ファン無のターンを一揃え持たないといけないので）つい億劫になってしまう。

----------------------------------------------------------------------------
帰りのルートの作成部はデスクワークで出来るのでファン無ターンの調整。900mm/sec程度のターンならファンがなくても安定。ここで少し早くても実用上メリットは少ないのでゆったりとした速度。
音も静かだし、迫力もない分気楽に調整できる。ハードが痛む心配も少ないし。


ミニモーターの軸も削りますか、、、。すごい
穴はもしかすると、、

探索向上

午前中は通院などで　先ほど迷路を広げて探索テスト。袋小路っばかり（１７回）を問題なくパス。袋小路を出る時の向きも補正されていて改善。横位置の修正がうまくなくて繰り返すとずれていく。もっとひどくなるとおしり当ての修正が入るのでまぁまぁってことか。バッテリーの充電を忘れていたので１回テストして一安心したところで充電中。

----------------------------------------------------------------------
午後に買い物に付き合ったりで　作業はごくわずか。　探索のずれも調整。　例のトラブルも再現をしない。　探索の見た目の安定感はアップ。　探索の心配は少し去ったかな。

----------------------------------------------------------------------
最短走行の弱点の洗い出しが出来ないかとトライ。　壁の後のターンでエッジを見逃すことがあるのかどうか。直角で壁有なので本来なら比較的楽な迷路なはず。　ところが　中部の速度でゴールが出来ない。　もちろんそれ以上も。　東北の速度はOK。　もう少しの上乗せも大丈夫みたい。だが中部の速度は数回トライしてもゴールはしても接触が多くとても走れたという感じではない。やはり中部は運が良かったのか？
東北の速度

中部の速度

まだどこでも使えていない準備した最高パラメータ


エッジの見逃しとかではなく　時々ターンが抜けることがあるのかもしれない。

-----------------------------------------------------------------------
９０度ターンと１３５度などのターンでは約200mm/secの差をつけてあるのだがそれが少しバランス悪いのかもしれない。　弱気だけど４５／９０度のターン速度を少し下げる事にした。

週末

帰宅→週末突入
今週は探索の確認の予定。ループ中の処理の追加で本当に不測の停止がなくなるのか？バグが残っていたとしても他に怪しい所は見つからないので手の打ちようがないのだが。
最短走行は中部の直前に修正をした斜めの姿勢制御をもう少し改良したい。もうちょっとセンター付近でちょこちょこ修正をしないでスーッと走り抜けてほしい。
中部最短の動画をアップしてしまいました。　被写体はうちのだけど撮影者は自分で無いのですが撮影者さんに連絡が取れていません。　不都合があればご連絡ください。

こちらは通常モード


こっちは同じ走行のハイスピード動画


斜めでちょこちょこしているのが判る。センターに居るときは無理に修正をする必要はなので　ロスにはなるし不安定の原因にもなりそうなので　もう少し改良をしたい。
前半の左９０度ターンで大きく膨らんでいるのも気になる。もしかするとエッジを見逃しているのかもしれない。　９０度ターンだから後が続いたけど斜め系のターンだと完全に失敗をしているはず。
うまくゴールしたけど完全ではなかったみたいだ。
ログは無いのでターンの改良は難しい、、、。

慣性モーメント測定法

「実験とシミュレーションで学ぶ　モーター制御」日刊工業新聞社
に２本釣り法と言う計測法が紹介されています（１５０頁）。
自分ではやったことがないですが。　大体の重量物で当たりをつけて後は計算結果と実際の結果、（DUTYから換算して）を照らし合わせて合わせ込みで決めてます。　あまりアカデミックな方法ではないけど。　慣性モーメント以外にも色々な外力が考えられるので　それらも合うように定数を設定している、、。