昨年も，クラッシュすると衝撃的な動画が撮れます，などと言ってアップロードしたが，今年はそんなもんじゃない．
今年のうちに今年のマウスの問題を確認すべく，全日本大会のときのNVS動画を見ていると，4回の最短走行のうち，直進の距離が合わないためターンがおかしいのが2回，斜め素行中のクラッシュが2回あった．斜め走行の制御は問題ないレベルまで調整したはずなのでなにかおかしいと思って少し確認をしていたときに撮れたのが次の動画である．
なかなか基礎点の高そうな技ではなかろうか．着地の前に撮影停止してしまったのが惜しい．
ではなくて，1G程度の加速でなぜ突然壁に向かって向きが変わっているのか．どうもジャイロセンサがおかしいらしい．中部地区大会で発症した接触不良が再発している．そもそも全日本大会までに再発しなかった方が不思議である．
結局のところ，今年は試走が圧倒的に足りていないということであろう．予選で1位と僅差の2位というのが良すぎる結果であったというところか．
さて，無理を言ってマウス競技日本人トップの方々にパラメータを公開いただいた．というよりも無理矢理引き出した．
クラシックの方はかなり感覚が薄れているが，これは相当に速い．聞き出したからには作らねばならないが，次の一年も時間がないだろうからどうしようか．7号機のときのように大部分共通のマウスとすれば良いだろうか．
ハーフは7回目の大会が終わり，フレッシュマンクラスもできて皆が力を入れるのはハーフサイズ競技へ確実にシフトしている．クラシックはそろそろなくなるかもしれないところであるが，クラシック最高順位は6位だと思うので，競技がなくなる前にこれ以上を狙いたい．
今大会は全日本大会連覇が4で止まったことが一番大きいが，連覇はいつか止まるしこのハイレベルの中4まで積み上げたことの方が不思議である．
実はそれよりもある意味ショックなのは，愛嬌のある目玉と猪突猛進的な走りのあのマウスに完全にBusterされたことかもしれない．決勝の朝，バスの中で宣言されたとおりコソッと書いてある．クラシックはピーコなのでともかく，ハーフは本当に負けた．
来年リベンジせねば．
では，早速，「クラシックの準優勝パラメータを教えてください！」
ハーフマウスが最短走行できなかった原因が不明であった．経路生成は正しいし，仮想走行（タイヤ空転）させると問題なく走る．これまでの経験をもとに考えてもそれらしい原因がはっきりしなかったが，簡単に再現走行をするとおそろしいまでの再現性で引っかかる．
とはいえ，同じパターンで引っかかるのではない．動画のように直進で一区画距離を間違えて壁切れを読む．加速時にスリップして実走行距離が短くなり，壁切れを読んだときに一区画ずれるためである．決勝直後の負けず嫌いの集いで撮影していただいた高速度撮影動画から判断してもこれが原因でほぼ確定である．
これは非常に良くあるミスであり，もちろん対策しているがどこかで間違ったのだろうか．ソースコード中にバグは見つからない．
確率的に読み間違うのではなく再現性は非常に高いので，しっかり調整していれば問題なかったのだろうとは思われる．（一度は調整したはずなのだが．．．）10区画程度の直進でも十分読み間違えるので決勝の迷路特有というわけでもない．しかし，タイヤの回転数は十分追従しているし制御が不安定になるわけでもないにもかかわらず5区画程度加速を続けると半区画くらいずれるということが今まで作ったマウスより大きく，感覚の狂うところである．まだまだマウスは奥が深いようだ．
そして，みんなのブックマーク，優勝機のパラメータが公開された．昨年までのものと見比べても毎年どんどん速くなっていることがわかる．直進は圧倒的に速くなったものの，旋回速度は4年前とあまり変わっていないようだ．こじまうす11は2輪タイプであるので，これくらいの旋回は問題なくこなせる．実際それくらいのターンでも動画のようにきれいに曲がるしピタッと直進動作へ移る．そしてまっすぐ跳ね返る．
決勝が終わり，クラシック，ハーフともに探索は完璧ながら最短走行が全く走らなかった．
| 競技 | ロボット名 | 記録（秒） | |
|---|---|---|---|
| マイクロマウス（ハーフサイズ） | こじまうす11 | 73.296 | 特別賞 | マイクロマウスクラシック | ぴいこじまうす | 69.608 |
クラシックは秘密のターンをよくわかるように公開してしまう結果となった．最近はほとんど調整していなかったし，フォトセンサなんて夏前に調整したきり一切定数を変更していないが走ってしまうから驚きである．斜め走行の制御が甘いようである．
ハーフは昨晩のデバッグは有効に機能し，試走台では相当高い設定でもかなり安定していたが，本番はやはりそうはいかない．結局はっきりとは原因がわからないが，一区画手前で曲がろうとしつつ壁切れを読むのを待っている状態だったようである．速度を下げても上げても挙動が変わらず，ちょっと何が起きたか想像がつかないが，今年は未だかつてなく調整時間が短かったこともありマウスの状態を把握できていないだけだと思われる．
結果が出なかったが，珍しく後悔する点を思いつかない．予定通り試走会から探索の調整をして決勝までに相当安定したし，最短走行も試走台のレベル（16x16）では十分安定していた．極端に軽いマウスを作ってその特性を知ることもできたし，結果には残らなかったが確実にさらなる高速マウスに向けて経験を積むことができた．
裏は大変だったと思うが，参加者として見れば大会はうまく進行していたし，技術交流等も相当面白かった．趣味とはいえ（趣味だからこそか）競技として本気で取り組んでいる人たちの技術，発想，精神はやはり洗練されていると改めて感じる大会であった．
今年は（今年も？）調整時間が足りず，デバッグも不十分であるのでホテルで作業した．
さて，明日（今日）の試走で最悪の状態になっていたらどうしようか．
予選である．クラシックはシード権を持っているのでハーフの新作１１号機のみ．左センサの出力が弱く，壁読みを失敗することが怖かったがなぜか本番は回避モードすら発動せず探索完了．
昨年と同等くらいのパラメータでタイムを残して２位通過．シードマウスがいることも考えると今年は本当につらい戦いである．同時に連覇の重圧から解放されるときまであと少し．
とにかくバグだけは発動しないようにしたいが，今年は経路生成のバグが頻発している．今から修正できるか？
まず，新しい迷路解析アルゴリズムはあきらめた．これで実績がある一方で既知のバグを含む従来のアルゴリズムに戻ることになるが，新たなバグは入らないので無難である．
とにかく最短走行が昨年より速くならなければ新作を調整する意味はないので探索走行を後回しにして斜め走行など調整．昨年と同等以上は可能．これまでの大会から，同等の速さではダメなのはわかっているがそんなにすぐには安定性を保ったまま速くはならない．安定性を捨てると32x32は走りきれないのを知っているので慎重に調整を進める．
ここまでが未明の調整内容．昼過ぎには試走会に現れて探索走行の調整をする予定が，結局夕方になり，
変数値の振動は一度でもまともに探索の試走をしてログを見ていれば気付いていたものを放置していたので今さら気付いたというシンプルなバグであった． 具体的には，スリップ角→横力→マウスの描く軌道の角速度→スリップ角を内部で計算しているが，これが数値的に振動していた．陽的に解くのが良くないのは明白なので，ホテルにて陰的に解くようにすると解決したようだ． しかし，これまでに調整した最短走行用のスラロームのバランスを崩していないか心配である．
海外からも変態マウスが現れているし明日から楽しみである．
調整時間が短いが，２輪マウスの素直な挙動に助けられ，昨年と同等くらいまで走れる可能性が見えてきた．問題は明らかに性能の劣る長い直線への対応である．これは前日に取り組む予定．
ここで，探索と最短のアルゴリズムを今年開発した新しい（そして完成度の低い）ものへ入れ替える作業を始めてしまった．ピーコに搭載しているのでなんとかなるだろうと思い始めたが，挙動があやしいし32x32だと計算が間に合っていない．．．
走るかわからないので出し惜しみしていた今年の新作．久々にまともに調整していくつかバグをとり，なんとか走れそうな気がしてきたので公開する．
一応秤の正しさを確認しておいた．おおよそ合っていると考えてよさそうである．
２輪タイプはやはり制御しやすい．スラロームはほとんど調整しなくても低速からそこそこの高速まで合う．
問題は，明らかに走り込みが足りないこと，角度がイマイチあわないこと，人の方に先に異常が出そうなことである．
これは中部地区大会前の状態であるが，設置点が前後に移動するのでカタカタする．これは根本的には解決できないが問題になるのかさえ現時点では掴めていない．
学生大会の迷路が公開されたので前回に引き続き迷路について．
この迷路は相当面白い．議論になるのもわかる．いろいろアイデアはあるものだ．学生は考え方の似たマウスが多く存在するのでちょっと想定をはずしたパターンを準備すると一網打尽にできるということか．
両壁がない区画がほとんどとのこと．確かにそのとおりだ．しかし両壁がないと補正できないということはなく，それほど難易度は変わらないような気がする．
壁切れが読みにくいとのこと．確かにそうかもしれない．読み方が雑だと読めない．しかし，探索走行に壁切れは必要かというと必要ない．壁切れなしで走れるくらいきっちり旋回を詰めて調整すべきと思われる．と言いながら私のマウスは壁切れなしでは探索できない気がする．柱でも壁切れ読めるけど．
くしの歯パターンはなし，４方向に壁のない区画もない．ほぼ常に横壁は存在するしほとんどのターン直前に前壁が読める．考えようによってはそれほどの難易度でもない．
でもうちのPi:Coが走れるかどうかは自信ないのでこれくらい簡単だとは言えない．
学生大会の迷路で話が盛り上がっているようである．どんな迷路なのか気になるところである．所詮マウスの迷路なんて決まった位置にしか壁がないのであるからどんなパターンでもあまり文句は言えない．もちろん嫌なパターンがあるのは重々存じておりますが．
少なくとも，過去の迷路パターンや誰かが組んだ迷路に合わせて調整するのみで，苦手そうな迷路を想像しないのは止めましょう．これは一種の合わせ込みの調整と言えますが，ある程度制御が構築できた後にやることです．
また，過去問だけ勉強して単位をとるのも止めましょう．これも一種の合わせ込みで，こればっかりやっていると想定外を想像できないダメな技術者になります．過去問は基礎を勉強した後に見るべきです．関係ない話になってしまった．
いずれにしても，マイクロマウスというのは完走すら難しい，記録で勝負するはずが記録を残すのすら難しいという変な競技なのです．そういう意味で必ずしも初心者に配慮した迷路を準備する必要はないと個人的には考えます．
ところで，予選まで後何日かというところではあるがそのうち10日間は出張している．この状況はまずい．再び撃墜されるのか．
新作11号機の自作エンコーダ用の歯は18個あり，これは10号機と同じ設計である．フォトリフレクタも同じである．したがって問題なく使えるはずである．いや，そのはずであった．
中部地区大会の試走からあやしいことは把握していたが，実際にはこんな波形が出ているようだ．振幅や中心値が等しくないことは問題ないが，明らかに立ち上がり，立ち下がりを検出できなさそうな波形が見える．これでもある程度は走れるわけであるからエンコーダの役割はその程度のものなのだろうか．
もちろんこれでは全日本大会では戦えないので，真面目に設計し直して再度加工．フォトリフレクタのデータシート等見ながら検討し，歯の数は8とした．
こうするとかなりまともな波形が出る．
ようやく正確に距離を測れるようになった．
と，ここで表示用LEDが接触不良のようだ．残り使えるのは2日間＋αしかないがどうなるか．
中部地区大会でなんとか最短走行も一度だけ成功した新作11号機であるが，これまでの経過と全日本大会までの見通しを立ててみた．
ここまでは，
そしてここからは，
最後の地区大会ということでしたがなんとか新作も間に合いました．
| 競技 | ロボット名 | 記録（秒） | |
|---|---|---|---|
| マイクロマウス（ハーフサイズ） | こじまうす10 | 4.454 | 3位 |
| マイクロマウス（ハーフサイズ） | こじまうす11 | 6.259 | |
| マイクロマウスクラシック | ぴいこじまうす | 11.880 |
その他の結果はこちら．最近はどの地区大会も結果の公開が非常に速い．
ハーフは想定以上の設定でも走ったもののそれでも勝てないわけで，全日本までになんとかせねばという状況．新作はなんだかスパッと走っているふうなのでこのまま調整すれば良さそう．
クラシックは斜めの連続でジャイロのないピーコさんには難しかったですが１回走れたのでOK．それ以上のパラメータだと完全に角度がずれていたのでもうダメです．そして謎の※2．なんだこりゃ．
中部地区大会に参加．
SGP Finalをもってしても負けてしまった．しかも相当タイム差がある．
直後の負けず嫌いの集いで，同じ経路を選択させるとともにSGP Final+ を適用すると同程度のタイムになることは掴んだが，とある吸引マウスに再撃墜され終了．
今年のレベルは昨年とはまた全く違うようである．
統合システムの場合，最も性能の悪い要素に引っぱられて全体の性能も低下する．
新作が昨年のマウスを超えられないのであればこのまま進める意味はない．
であるから，なんとかわずかな妥協で設計ミスをカバーしたい．
リファレンスマニュアルを見ながら考えた結果，なんとかなりそうである．モータ駆動にはTIM1からPWM出力が2本出れば良い．TIM1はコンペアマッチ信号を4本出力できる．よって残り2本をDMAトリガに使える．この2本はDMAの空きStreamをたたける．問題は，周波数を共通にしなければならないことと，AD変換器のトリガに他のタイマを使う必要があることである．モータドライブに周波数を合わせるしかないが，256kHz駆動にすると，それに合わせて過剰にDMAトリガがかかるがまあ良いとする．もともと64kHzでDMA起動の予定だったが4倍なのでそこまで負荷が増えることはなかろう．AD変換器のトリガはTIM2を使って，TIM1と同期動作させる．途中で停止，再開しても完全に同期して動作させることができる．TIM2の周期をTIM1の4倍に設定すると64kHzであるので当初の予定通りの周期でAD変換できる．
これで頭の中とテスト動作のレベルでは解決したが実際はどうなるか？また別の落とし穴にはまるだけだろうか．
しかし，依然としてErrataと思われる問題は残っている．シリアル通信のDMA転送が上記DMA転送に干渉してくる．STM32のDMACはダメですね．
やってしまった．
11号機製作中，センサLEDがどうしても光らないので原因を調べてみると，DMAコントローラがエラーを出している．
LED発光タイミングはDMACで制御．ポートをたたけるDMAはチャネル2のみ．チャネル2のDMAを起動できるタイマはTIM1のみ．TIM1はモータドライバに使っている．モータドライバのつながっているピンにはTIM1以外のタイマを割り当てられない．
自由度の高いSTM32とはいえ，かなりきついぞ，これは．．．詰んだか．
試走会から参加し，Pi:Coの調整を少しは進められたはず．ちゃんと走行したし．
ネット民に監視されていたのでなかなか手を抜けない大会であったが，Pi:CoたちはBusterしたし，ハーフも地区大会スペシャル1stパラメータでなんとかタイムを残せたので十分でしょう．
| 競技 | ロボット名 | 記録（秒） | マイクロマウス（ハーフサイズ） | こじまうす10 | 4.944 | 優勝 |
|---|---|---|---|
| マイクロマウスクラシックエキスパートクラス | ぴいこじまうす | 12.900 | 第3位 |
うちのvaioさんはSSD認識できない病を発症したことがあるが，そのときは取り外し，取り付けでなぜか完治したかに見えた．
が，再発した．恐怖の "Operating System Not Found" である．関西地区大会から帰って起動したときに再発し，再び分解することに．．．マウスが調子よいとPCが調子悪くなることはよくあることである．
接触不良も疑われるので一応コンタクトスプレーも使って対処すると，複数回の起動に全て成功する．
しかし，なんとなくS社のSSDが怪しいというか相性が悪いというか気になること，せっかくなのでWindowsと共存させたいことから，倍の容量の同規格SSDを購入．高い！Vaio proの11inchに使うには片面実装であることが必要であるが，なかなか情報がない．その中同じvaio proで動作報告のあるC社のSSDにした．ちなみにオリジナルのものは裏面にも少し部品がのっており，これを避けるようにvaioのメイン基板はくりぬかれている．
で，取り外したSSDも壊れたわけではないと思われるので外付けケースに入れて使う．M.2は選択肢がない上にケースが高い！
問題はここからである．気の迷いでWindowsを復活させようとしたのが間違いであった．リカバリメディアを作成した後すぐに退去いただいたWindows8を再度インストール，8.1に更新，をしようとしたら，やたらと時間がかかる．「こんにちは」などと表示が出るが，もう「こんばんは」の時間である．丸一日かかってOSが使えるようになっただけとは．．．
このままでは来週の東北地区大会で使うPCがない．UEFIに対応したとのことなので，本命のLinux Mint 17.2をインストールするも，はまる．インストール自体は10分もかからず超高速であるが，どうブートされるのか意味不明であり，Linuxを起動できない．Google先生に聞きながら謎の呪文を唱えまくってやっとデュアルブートできるようになった．
さて，開発環境構築しますか．
なぜ遠方まで参加しに行っているかよくわからないが，参加してきた．
ハーフは試走会で柱に正面からぶつかるルートを作ってしまうことがあるという致命的なバグを発見． 一応修正されたはずである．
大会本番では最終出走であること，それまでのマウスがかなり良いタイムを出していたことから 昨年の全日本大会優勝パラメータを第二走で設定するという 攻めた戦略で走行．やはり昨年のパラメータでは勝てないようなので， 地区大会スペシャルパラメータ（別名：Sapphire撃墜パラメータ）で残り三回を走行． 相手の自滅もあって今回はなんとか勝てた．
Pi:Coは．．．なんかシード権が降ってきました．決勝の５分ルール対策を しないといけないのかと思うと頭が痛い．
| 競技 | ロボット名 | 記録（秒） | |
|---|---|---|---|
| マイクロマウス（ハーフサイズ） | こじまうす10 | 4.841 | 優勝，シード権 |
| マイクロマウスクラシック | ぴいこじまうす | 11.428 | 2位，シード権 |
クラシックマウス，Pi:Coの話．設定し損なっていたことに気付いた．
台湾大会では試走会のときにキャリブレーション無しでとりあえず走らせてみた．ゴールのない小区画内ではあるが，走る．
とはいえ，台湾の壁は日本と違うという話があるので基準点の再設定を行った．つもりだった．操作はした．しかし，Pi:Coにはパラメータ設定用のROMなどなく，保存されているはずはない．手動でソースコードを書き換える必要がある．
ところが，書き換えた記憶がなく，git diff しても書き換えられた形跡がない．
すなわち，うちのPi:Coは預け荷物として空輸されるとともにいつどこで設定したかわからないフォトセンサの基準点をそのまま使って環境の異なる台湾の迷路を走行したことになる．
少なくともこのPi:Coはpoor robustnessではないようだ．
敗因を真剣に考えるのは久しぶりである．
台湾大会ハーフマウスの優勝はK氏の新作4輪マウスであるが，ちょうど私の9号機のような構成である．しかし相変わらず理解できないほど優れた安定性と速度を有している．
動画から分析するに，ターンで負けている．斜め走行で負けている．そしてK氏の経路は最適ではなく，かなり損をしている．要するに私の現状のマウスでは全くお話にならないということのようだ．
特に斜め走行についてはもしかして3.5m/sで走っているのでは？と思える速さである．今年も吹っ飛ぶのを覚悟で調整する必要がありそうだ．
部品が営業所にあるのだがどうやら休暇らしく受け取れない．．．
敗北した．
大会本番．試走はできないので出走まで待つのみであった．
出走は写真の２台．
Pi:Coは最短経路でないとしても二次走行まで成功したので上出来でしょう．よく考えてみるとピーコ杯のときに探索ができるように調整はしたが，二次走行の調整はまだできていない．
ハーフサイズはバグ２個が発動．とはいえ，ほぼ昨年の全日本最高タイムのパラメータで走れた．しかし，それでも三位である．
| 競技 | ロボット名 | 記録（秒） | |
|---|---|---|---|
| ハーフサイズマウス | Kojimouse10 | 6.668 | 第三位 |
| クラシックマウス | P-Kojimouse | 〜28.950 | <--Score |
Pi:Coはとりあえず走りそうである．意外にも．
問題は予想通り４輪ハーフマウスである．昨年同様路面の違いがもろに影響する．パラメータを下げないと安定しない．何度も吹っ飛びながら調整を繰り返すもイマイチである．やはり４輪マウスの扱いは非常に難しい．再現性が全くないというわけでもないのでなんとかなりそうなものだが時間切れ．
しかしこれだけぶつかっていて壊れないのはなかなか優秀である．
そして今年追加されたイベントであるマウス小会議で発表した．今日は濃い一日であった．
今年も呼んでいただけたので台湾大会へ参加しに台北へ来ました．
今年はmeetingで発表することになっているので，今朝（現地はまだ18日）から急ぎでスライドを準備しはじめ，新幹線，NEX，空港，機内と作業してなんとか日本の経済水域を出るまでにはほぼかたちになりました．ピーコ杯プレ大会のときの使い回しですが．
で，到着後はいつもどおり？買い出し．別途報告が上がると思いますが，昨年の「大丈夫」と同系統のあやしげなものも混ざっています．誰が飲むのでしょうか？
明日は試走会とmeeting．国外の迷路でPi:Coが走れる気がしないのですが．．．
毎回の面倒な作業，登録を完了した．今年はデータ引き継ぎ機能搭載のすばらしい登録ページになったので今後は楽できるはずである．
しかし，残り30分ほどで締め切られる状況の中急ぎで入力するのは大変であった．ところどころいい加減な値を入れた気がするがやむを得ない．メールが転送の過程で文字化けするがこれはこちらの環境の問題だろうか．
新作は間に合わないので10号機とピーコで参戦予定である．
その前に，未だかつてなく厳しい戦いが予想される台湾大会の（旅行の）準備をしなければ．
今年も新作ハーフマウスを製作する．
制御の難しい4輪をやめ，ベーシックな2輪マウスとしてさらに1g軽くして7gを切るマウスを目指す．ターン速度は上がるでしょう．直進速度をどこまで確保できるかが鍵か．
回路はほとんど変更しないつもりだったが，気がつけばいろいろ変わっている．また今年も苦労するのだろうか．
関西地区大会には基板くらいは完成させていたいところ．
徹夜明けの試走動画
すでに詳細な結果が公開されていますが，大会迷路とベストタイム時に選んだと思われる走行計画はこのとおり．
RAM容量の関係で500個しか確保していなかった経路計算用のある配列のうち，470個ほど使っていたらしいことがわかった．危ない．過去の迷路では350個ほどで足りるものもあるが，今回はわりとスカスカな迷路だからだと考えられる．
ゲスト参戦ということで順位表彰対象外で参加．そんな扱いされてもまだ走れませんけど？という状態で前日の試走会へ．Googleマップのナビ機能で会場へ向かうも，絶対そっちじゃねえだろという経路を選択させられる．無事到着したので良しとする．
実走行によるタイヤ半径，トレッドの計測からはじめ，スラロームなど調整するも，安定しない．再現性がない．ステッパなのに．
スラロームについてはバグを発見．修正すると安定した．しかし，超信地旋回が安定しないまま懇親会へ．
懇親会の後は秘密の部屋で調整の続き．どうやら駆動回路の問題なのか低速回転が異常に振動する．もともと低速では安定して回らないとはいえ，昔ステッパマウスを作っていたときには経験したことのない振動である．ちなみに1号機に同じプログラムをロードすると再現しなかった．2号機の問題か？これをシャチョーにも確認いただいたところでレンタルピーコユーザのS氏とひたすら調整を続ける．振動する領域をスキップして回すことである程度の再現性を得られ，いくつかのバグをつぶすことで少しずつ走れるようになってきた．
大会当日，昨日は何時までやってたんですか？と聞かれるも，そもそも切れ目がなかったので答えようがない．あえて答えるなら6600円のベッド付きシャワー室を利用したときが切れ目だとして7時頃か．大会会場へ移動してフル迷路でテスト走行させると，なんと普通に走るではないか．斜め走行までできる．新型スラローム軌道も機能している．なるほど，これが精神と時の部屋の効果か．
タス(TAS) （一財）置賜地域地場産業振興センター， 2015年7月26日
| 競技 | ロボット名 | 記録（秒） | |
|---|---|---|---|
| マイクロマウスクラシック | ぴいこじまうす | 9.077 | 支部長賞 |
というわけで，ある程度のレベルを実現でき，普通のピーコユーザが出せない記録を残せた．まだ速くなると思うが，とりあえず初心者の言い訳封じを達成できた．ピーコにはかなり苦労させられたが，フレッシュマンのコースよりは難しいにもかかわらず大会の完走率は非常に高く，キットの威力を感じた大会でもあった．
ピーコにマイクロマウスとして必要な最低限の機能を搭載した．RAM，ROMともにカツカツ．特にRAMはスタックがオーバーフローするのであまり攻めないようにする．何か忘れている機能があるともう無理ではないか．また，迷路との相性が悪いと最短経路の計算ができないことがわかっている．
後は前日調整（というよりデバッグ）でなんとかピーコ杯に挑む．
チラッと金沢大会の様子を見ていると，ピーコで遊んでいる場合ではない気がしてきた．
大会参加にあたってどうもやる気の出ない参加登録を完了した．「・・・が入力されていません」とか言われたら閉じてやろうかと思うが後悔するだけなので我慢する．今年は競技参加歴の欄が全て優勝で埋まる．
今年はこれが他の大会に引き継がれるのだろうか．そろそろ引き継ぎシステムが動かないとマウスより先に参加登録に飽きてしまいそうだ．
肝心のうちのピーコさんは．．．これから8kByteとの戦いがはじまる．
参加し，予定通りリタイヤして終了．会場でフォトセンサのキャリブレーションをせずとも走っていたのでプレゼンした通り外乱光には打ち勝つことができたと思います．
Pi:Coは無償で提供してもらっていますが，某社は今回の技術レポートですでに十分元をとっていて一人勝ち状態ですね．
皆でさんざんダメだしをしたのでPi:Coもバージョンアップされることでしょう．でもそうすると，せっかく１ヶ月以上かけて構築したフォトセンサプログラムが不要に．．．
SH-7125はメモリが8kByteしかなく，32x32用のプログラムはそのままのらないので16x16に変えて移植したつもりでしたが，これにバグがある模様．せっかくの機会なので探索アルゴリズムを見直して整理しようと思います．
大会の時間や場所の情報が来ない．．．と思っていたらこんなところに情報が．なるほど，とりあえず13:00ですね．
ムリムリ詐欺の常習犯という扱いをされているが，今回は本当に無理．モチベーションも低いですし．
一方，発表についてはしっかり準備してしまった．フォトセンサについてソフトでめんどくさい補正をしていることを話す予定．
ちょっとモータ出力について検討しているときに以前のソースファイルを確認すると．．．2で除すというなぞの演算式を見つけた．理論式にはない演算である．どうやらこれは間違いのようで，モータトルクに関するフィードフォワード項では理論値の2倍のdutyを与えていたようだ．
いつから？と思い過去のソースファイルを確認すると，4年前こじまうす7のときからであった．
とはいえ，実害はない．フィードフォワード項に含まれるモータの抵抗値はパラメータとして実走行に合わせて調整しており，打ち消されるからである．以前から，テスターで計った抵抗値より低い値を与えるのは気持ち悪いとは思っていた．バグだったか．
Pi:CoはフォトセンサのLED位置を接着剤でfixしているところ．今週末にでもフォトトラもfixし，センサテーブルを作成予定．プレ大会では完走はもちろん無理．ちゃんと走らせようと思うとそんなに簡単に扱えるハードウェアではない．
以前作成したフォトセンサテーブルは変な挙動を示しているが，その後，フォトトランジスタの立ち上がりに依存するタイミングは避けた方がよいことやハイパスフィルタを有するにもかかわらず外乱光の強度によって出力が変化することについて検討した．
問題は二点である．一つは外乱光強度に依存して立ち上がり時間が変化すると同時にハイパスフィルタにより減衰が進むことである．これに対してはピークホールドが有効に働くと思われるので，連続的にA/D変換を実行しソフトウェアで出力のピークをとれば良いと考えられる．立ち上がりが遅いときにも対応できるように連続的に20回A/D変換を繰り返し，その最大値を採用するようにした．20回のサンプリングに要する時間は60usであり，Pi:Coの場合はこれくらいが必要十分な時間となるようである．これによって安定度は格段に向上した．
もう一点は，直感で光軸合わせをした場合には反射光強度が強すぎて壁が近いときに飽和することである．これに対しては，光軸をわざとずらした．指向性の高いLED,フォトトラなのでなかなか簡単ではないが，適当な角度差にするとほどよい受光強度になる．
かなり時間がかかったが，ようやく使えそうな状態になってきた．結果今までの対数近似でほぼ大丈夫そうな特性になった．図中の緑のラインは2次関数＋対数関数で近似した結果である．
dw = a0 + a1 s + a2 s2 + a3 ln(s)
普段の作業はデスクトップPC，外へ行くときはvaio pro 11を使っているが，vaioさんの調子がすこぶる悪い．
昨年に台湾から帰る空港ではじめて発症した内蔵SSD認識できない病である．このディスクは元のWindowsさんには立ち退いていただいてLinuxに完全に入れ替えており，これが原因の可能性を完全には否定できないが，今回はBIOSが認識していないのでおそらく関係なく，わりとお手上げ状態である．これまでは認識しないことがあるという程度であったので地区大会や全日本大会でも問題にはならなかったが，今日はごくまれに認識することがあるもののOS起動完了までに読み取りエラーが出るというバックアップもとれない状態になってしまった．
というわけで，ついカッとなって裏蓋をはずした．軽量PCなのではずすのは厄介かと思ったが，ねじ9本はずせばパカッととれる．メンテナンスはかなりしやすいようだ．すばらしい．
右下にある長細い板がSSDであり，こいつがダメになっているのなら同規格のものを購入して換装ということになるが，とりあえず一度はずして特に何もせずつけなおした．
何か（Sタイマー？）がリセットされたのか接触不良だったのかわからないが，今のところ確実に起動するようになった．しばらく様子を見よう．
最近Pi:Coのフォトセンサをうまく使えなくて試行錯誤している．
今日はフォトセンサ回路について考える．Pi:Coのフォトセンサ回路について書くのはあまりおもしろくないので，BasicMouseのフォトセンサ回路がいかにすぐれているかを考える．実は昔説明文章を書いたことがあるらしい．その説明が正しいかどうかは知らない．
今改めて考えると，すぐれているのは「強力パルス発光」と「ピークホールド機能」である．
前回はフォトセンサの特性に触れたが，これを考慮するとハイパスフィルタ付きのフォトセンサを外乱光のある場で使うと次の図のような出力が得られるだろう．すなわち，周囲の明るさと壁との距離（反射光の強さ）で立ち上がりの速さが決まり，壁との距離で出力の極大値が決まる．ハイパスフィルタの影響で初期値は0であり，立ち上がり遅れの後は時間とともに出力が低下する．
この場合，外乱光の影響を避けるには，外乱光の強さに比べ十分強い反射光を得ること，出力のピーク値をA/D変換すればよいことがわかる．BasicMouseの回路は，パルス状にはLEDに5Vをそのままかけ大電流を流せるものの，定常的には電流が制限される比較的安全な構成になっている．そのため，ソフトウェアにバグによる回路破壊のリスクを避けつつ非常に強い発光をさせられる．また，ピークホールド回路のおかげで十分遅い時間にサンプリングすれば立ち上がり時間が多少異なっても影響を受けない．
知識のないときにはまねするしかないのでまねていたが，今思えば偉大であった．
I put my photo sensor characteristics on the previous blog post. The curve shows that sensor output around 600 does not change with distance to wall. I have believed that this characteristics is caused by the geometry of emitter and detector because the parallel distance of them is relatively long.
When I wrote the answer in the comments, I came up with another possibility. Schematic of photo sensor response is shown below. In general, response of photo transistor is slow and it changes with light intensity. More intensity the received light is, faster the rising speed becomes.
When the sampling timing of A/D is set to B in the figure, A/D value is not affected by the response time. On the other hand, sampling is performed at timing A, A/D value is determined by the response speed. There is an advantage to sample at timing A, because saturation of current or output of opamp is avoidable owing to its low photo current. However, the response speed also saturates for very high intensity of light. This effect may cause the low sensitive curve in my photo sensor.
If this is true, the easiest solution is to change the value of register, but, anyway, I cannot change it by the rule for Pi:Co in this year.
マイクロマウスのフォトセンサの出力は距離に対して比例しない．なんとなく走らせるのであれば単調でさえあればリニアかどうかは気にしなくても良いかもしれないが，それではすぐに限界が見える．左右の特性の差も気になる．
そこで，何かしらの方法でセンサの出力を距離に変換するわけであるが，壁との距離d，センサ出力sとすると，対数近似（d=log(s)) やべき乗関数近似 (d=s^n)がわりとよくフィットするので広く使われているようである．こじまうすでは昔は対数だったが，何年か前にべき乗に切り替えた．特に意味はなく，そちらの方がよく一致していたからである．
と・こ・ろ・が，である．ピーコのセンサは全然違う特性を持っているではないか．既出とはいえ，本当に全然違うからまいった．
とはいえ，結局テーブルを作るのでそもそも何かの関数で近似できる必要はない．そこで，無理矢理5次関数近似で間を補完してテーブルを作った．次数の高い多項式近似では外挿が全く役に立たないことが多いので，計測範囲外は補完しない．赤丸が計測値，緑線が5次近似の結果であり，LDは左横センサ，LFは左前センサである．
なんとも気持ちの悪い特性である．
さて，ピーコのSH-7125にはFPUがないので，整数型で組むことを決めたわけであるが，早くもあきらめてしまった．
過去のプログラムを見返すと，2009年のこじまうす5までは整数型で全て組んでいたようである．2009年の大会後，12月にFPUのないSTM32F1でfloat型で組めるか試し，なんとかなることを確認した．それからずっとfloat型で制御を組んでいる．
それから5年以上経過しており，プログラムの骨格は変わっていないが様々な補正機能を導入してきた．これを整数型に書き換えるのは並大抵の作業ではない．よって，SH-7125の処理性能に期待してfloat型のまま移植を進めることにした．制御周期が1msは不可だとして，5msくらいまで長くなってしまったらどうしようかと危惧するところではあるが．
前回のはそのコメントも含め不満が出始めたが，長くやっているとハードウェアの不備を修正する技術は嫌でも身につくわけで，ベストを尽くすために修正を試みた．
まず，機体後端が接地したときに前方が浮いてセンサ光が上向きになる問題を解決するために，後端のテフロンシートをかさ上げした．
つぎに，実はマニュアルにもぼそっと意味のとれない日本語で書いてあるが，フォトセンサ用赤色LEDを基板と並行ではなく，下方に向けた．
さらに，壁切れを区画中央くらいで検出できるように横センサの水平方向の傾きを調整し，マニュアル通り前方センサは少し外側に開いた．シルクの位置なんて無視だ．
結果，まともに壁に光があたるようになった．
ピーコを使うにあたってハードウェア変更なしという拘束条件があるのはわかっていたが，まあ初心者が使ってあれだけ走れるのだからなんとかなるだろうと思っていた．
甘かった．
フォトセンサについてこちらの検討の結果を見ていたので大変なのだろうとは思っていたが，予想を超えていた．
まず，LEDから出る光は壁の上ぎりぎりにあたる．一部は壁にあたらないため，加速中と減速中，言い換えるとマウス先端と後端のどちらが接地するかによって返ってくる光の強度が変わる．後ろ重心で普段は後端が接地しており，この状態では半分くらい壁からはみ出てるので製作ミスしたのかもしれない．
次に，既報の通り壁が近くにあると距離の変化に対するセンサ値の変化がほとんどなくなる．LED発光時間を延ばせば値は大きくなるので飽和ではなく幾何学的な効果であると思われる．おそらくLEDとフォトトラの間に分厚い基板があるためだろう．ある程度壁が近くに来るとセンサ値から壁の距離を測ることができないことになる．一方，これはセンサ値が過剰に大きくなり制御が強くかかりすぎるのを防ぐ効果があると考えられるので初心者に対してはうまく働くのかもしれない．特に距離に対する線形化をせずにセンサ値をそのまま使ってフィードバック制御する場合には，なるほどうまい方法だと言える．しかし，上級者にとってはただの欠陥である．
また，どうやらなかなか優秀なフォトトラを使用しているようで意外と反応が速く，LED発光時間は10us程度で十分なようだ．しかし，ハイパスフィルタの時定数は100usと長すぎる．これでは1msに１回しかサンプリングできない．悪くはないが，コンデンサ容量を変えるだけでサンプリングレートを上げられるのに．残念．
やむを得ず不満が多く含まれる進捗報告になり販売元には痛いかもしれないが，初心者と上級者の観点の違いが見えるだろうから初心者がステップアップする上で何を考えればよいかのヒントになるのではないか．
さて，ここに不吉な宣伝がありますが，うちのピーコはようやく各ハードウェアを動かす関数群ができあがったところです．プレ大会は完走ヤッター！のレベルではないのか？がんがん走らせている人もいるのでそうはいかないか．
最近はSTM32ばかり使っていたのでルネサスマイコンは慣れていません．とはいえ，H8を使っていたので概要はわかっているし，ドキュメントは日本語なのでサラーっと読めば使い方はわかる．問題は，FPUを持っていないのでfloat型を使うと遅いこと．こじまうす10の16MHzに比べればなんと3倍の48MHzというのは強力だがそれでも処理を加えていくと厳しくなると思われる．
仕方ないので整数型で全て書くわけであるが，オーバーフローなど気を配ることが増えるのでここからの制御プログラム構築は大変だろう．物理量ベースで制御を組むのがあたりまえになってきたマイクロマウスにおいて浮動小数点を扱えないのは時代遅れ感がある．
これを見て，ふと思い出したのでメモ．
LinuxでUSB-シリアル変換ケーブルを使うのは場合によっては非常に簡単である．FTDIのチップを使っていればUbuntuなどでははじめからドライバを持っているのでドライバのインストールという面倒な手順をスキップして挿すだけで使える．
かというと，実はそうでもなく，リンク先でも書かれているように一般ユーザには読み書き権限がない．Ubuntuの場合昔は普通に読み書きできたのだが，数年前のバージョンからできなくなったようだ．はじめにこの問題にぶつかったときは焦った．
結局chmodして権限付与すればよいわけだが，それよりも/dev/ttyUSB0などはdialoutグループでありグループに対しては読み書き権限があるので，自分をdialoutグループに入れるのがよいと思われる．例えば，kojimaというユーザをdialoutグループに追加するためには下記を実行する．
$ sudo usermod -a -G dialout kojima
-aのオプションを忘れると痛い目を見るので注意．実際に追加されたか確認するために，下記コマンドで自分の所属グループを調べる．
$ id
ちなみに，変換ケーブルをUSBポートに挿した後
$ dmesg
で，どう認識されてどこに接続されたのか確認できます．
休日は真剣に休まないと体がもたないので，少しずつ進めている．特にマウスはやりはじめると抑えが効かなくなることがあるので危険．
今週はピーコのステッピングモータ用のタイマ設定とパルスレートを変更する関数を作成．たいして進んでいない．．．電流調整用のトリマの初期値がとんでもない位置にあったので電源装置から電流を供給できなくて焦った．10A/相くらいの設定になっていたようだ．
モータがこじまうす2のものと同じなので懐かしい音をたてて回る．無負荷で9000pps（400pulse/rev）くらいが限界のようだ．当時は30Vまで昇圧していたので，それよりは性能が低いと思われる．
さて，ぴいこじまうす計画が持ち上がってからずっと困っていた問題が解決されそうだ．問題とは，コンパイラとFLASHライターである．
普通はこんなところで困ることはないが，Linuxユーザは普通ではないという認識が一般的であり，SH/Tinyの場合も例外なく困るわけである．
仮想マシン上のWindowsで．．．なども考えたが gvimでテキスト編集→make→コマンド一発で書き込み の流れで開発ができないとフラストレーションが溜まるのは明白なのでLinuxにおける開発環境構築に踏み切った．
オプション指定ではかなりはまったがネット上の情報をもとにGCCコンパイラのコンパイルを行い，ハードウェアマニュアルを見ながらFLASH書き込みツールの作成を行った．これだけでは不十分で，スタートアップルーチンやらリンカスクリプトやら準備し，ようやくStep1のLEDチカチカ，通称エルチカを達成した．
main関数だけはコピペでいいかと思ったが，チカチカしない．いや目にも止まらぬ速さでチカチカしているのか？ループ変数にvolatile指定が必要であった．環境が変わるといろいろはまりどころがあり，自爆行為のようにも思われるが仕方ない．このためだけにWindowsを使うよりましである．
アップするのを忘れていたが，特に問題なくマニュアル通りに組み立ては完了した．3時間では終わらなかった気がする．半田付けの難易度は，ベタグランドで放熱が激しい部分は厄介であるが，普段のものに比べればかなり低い．
取扱説明書p12 図2-3-4，写真とスイッチの色が違って焦った．p27 図2-5-11，金属部分が小さいことと足が長いことを同時に満たさないので焦った．バッテリをどうおさめればよいのかわかんない．
半田リールは作業前124gだったのが作業後は116gだった．つまり約8g消費したことになる．ほぼ全てピーコにのったはずであるが，8gというとこじまうす10の重さに相当する．だから何ということはないが．
名前は2013年台湾大会で決定済みである．そのときからこの企画が始まったと思われる．正確には決まっていたのは発音だけであり，文字表記は少し悩んだ．
