初めましての方は初めまして.
そうでない方はお疲れさまでした.
頑張って今日を何とか生きているぱわぷろです.
この記事は
Micro Mouse Advent Calendar 2019 - Adventar
10日目の記事です.
昨日は先輩であるしまじゃき氏の担当でしたが…癖強いですねぇ.
切符鉄はあの人を通じて初めて知りましたが、トラベラー向のいい趣味だと思います.
最後のはお褒めの言葉と受け取っていますよ、お師匠さん.
今回はマイクロマウス2019を通して得た教訓の話です.
内容については後輩から「初心者にも分かるものを!!」とオーダーされたので軽めです.
上手くいった話はよく聞きますが、ダメだった話も後輩のためになるかなぁ…と思いながら今年の個人的教訓を列挙する記事です.
知ってる人にとっては当たり前じゃんwwwってなるだろうし
半年前のぱわぷろでも、それぐらい知ってるわ!ってなりますが
知識として知っていたにも関わらず、この半年で身をもって痛感したこと(の一部)です.
目次です.
教訓1.レギュレータの出力計算は概算をしておく
これは東日本大会前に発生した、突然マイコンがリセットする問題からの教訓.
症状としては
「モータを回そうとするとマイコンが落ちてしまう」
という旨.
当初はマイコンのmain文がbreakしてしまっているか、配列の領域外参照、メモリオーバーフローなどのソフトウェアを疑っていました.
しかし原因は特定できず、発動条件が「モータ起動」であることから、電源の瞬間的な電圧降下を疑ってオシロスコープで電圧を測定しました.
モータ回すとマイコンがリセットする問題が発生
— ぱわぷろ@ラボ (@ss_sholaw) 2019年9月3日
5Vレギュレータの出力を見ると驚愕の波形
3.3Vの入力を5Vにしてるのでその影響受けてリセットしてた
コンデンサ???
配線???
何が原因だ…?
#道標を辿る pic.twitter.com/wsHq1Hw35A
結果的に、壁センサLED用の電源とマイコン含めたIC部分でレギュレータを分割 + 出力電流500mAのレギュレータに交換、で解決しました.
定常電流にモータ起動時のノイズ(?)が足され、レギュレータ電流出力を超えてしまったと仮説を立てています.
(電源電圧は電圧降下が観察できなかったため)
ちなみに当時のレギュレータは出力電流150mAにも関わらず、全てのICを動かしていました.
壁センサLEDは1つのパルス発光で50mA消費 + ジャイロ + モタドラ + マイコン等などと考えれば明らかに足りなさそうですね…
教訓2. マイコン変更は計画的に
タイトル通りです.
今回のクラシックマウス「道標 現」(みちしるべ うつつ)は、ぱわぷろマウス初のSTM32でした.
LPC1114, RX220, RX631と来て突然のSTM32でしたが、所属サークルの標準はSTM32に統一したのでその流れに乗っただけです.
良くなかったのは、始め方.
ハードウェアトラブルまで原因が特定できたものの、
— ぱわぷろ@ラボ (@ss_sholaw) 2019年5月10日
1年前に回路図、設計図を全て失った事
足回りのギアも入手困難となり予備パーツが無い事
等々の事情により
現行機体を破棄し、新作製作に勤しみます
遺影です pic.twitter.com/3rrshi98gH
去年から製作していた、先代マウス「道標」が急死したことから設計がスタートしました.
5月のこの時点から設計を始めてたにも関わらず、マイコンを変えたことが後に大きく響きました.
前作までのペリフェラルを全て書き換える羽目になり、HALライブラリに変更しました.特にジャイロで使うSPI通信、壁センサに使うAD変換の部分で苦しみました.
ジャイロで苦しんでいた問題は開発環境のファームウェアをアップデートしたら全く同じコードで動いたのでよくわかりませんでした….
AD変換はDMAにチャレンジしたらハマってしまい、通常のAD変換の設定を変えながらセンサ数だけ取得するスタイルにして乗り切りました.
マイコンを変えると、動作部分の様々なところを変更しなくてはならないので、慣れていないマイコンならば、焦って1,2ヶ月でやるべきところではなかったなぁ…と反省しております.
でも今年の苦労があったから新作はここが楽になってくれる…はず.
教訓3. ターンシミュレータを面倒臭がらずに作れ
これは旋回における角速度と角加速度を、重心速度と半径からちゃんと計算しましょうね、って話です.
「シミュレータを絶対作れ!!」ってよりも
「シミュレータを作る過程で、ターンの理論をちゃんと身につけましょう」って意味合いが大きいですね.
実は、自分のターンパラメータはv-tグラフとw-tグラフの幾何学から生成していました.
数値として与えるパラメータは
・ターンにかける時間
・台形(w-tグラフ)の上底と下底の比
・オフセット距離
です.これで他のパラメータを自動計算していたのですが、問題がありました.
パラメータ調整がしづらいことです
角速度と角加速度でシミュレータが作れれば、いい感じのパラメータをぶちこめばいいのですが、台形の比とか言われても分かんねぇ…ってなるだけなのでお勧めしないです.
この方法でも行けるところまで行ってみれば良い感じになるかもしれませんが…
幾分、自分でも何を考えてこんな制御側を書いていたのか覚えていないのです….
シミュレータがあればこんな面倒くさいことする必要ないです.
シミュレータは何でもいいと思います.
Python、MATLAB、Qt等々ありますが自分はExcelでテキトーに作りました.
テキトーでしたが使えます.頼りになります.
もっと洒落たもので作りたいですね…Qtが触りやすいかなぁ….
教訓4. とにかくログを見れるようにしてログを見ろ
これは色んな方がおっしゃるのですが、その通りです.
そして、ログの結果が明らかに変だったら何かがおかしいです.
ボクの場合はモータの挙動が何かおかしいなぁ…?と思っていたら
とりあえず動いてるのでよし!っと放置していたら
左右のモータのピンアサインを逆にしてコードを書いていました.
直線がどんなに係数合わせても震えるし,異音がしていたので
「何かがおかしい…」とは思っていたのですが,初歩的なミスでした….
あとは壁情報の表示です.
LED等の物理的なインターフェースで表示するのもアリですが,探索終了後に壁情報を吐き出させられると原因の切り分けができて非常に便利です.
実際の走行データから迷路情報を表示する事を確認
— ぱわぷろ@ラボ (@ss_sholaw) 2019年11月14日
見ていない壁もしっかり消えてる
ピニオン直したらベイブレード問題も解決した
最短を走れるように台形走行関数を作成中#道標を辿る pic.twitter.com/wJ6tXFYi9g
大会前日に前壁制御を入れた探索で暴走していた原因,位置座標のズレが直ぐに分かったのは,壁情報のログと現実がかみ合っていなかったからです.
走行中の内部状態をログで確認できれば,すぐに直したり,機能をオフにしたり対応ができるものですね.
総評と来年
実は今年の学生大会終了後の段階で、マイクロマウスから距離を置こうと思っていました.
理由としては今シーズンで大学1年の頃に掲げた「学生の間にやるべき事」を全て達成してしまったからです.
それは
・WMMCの再建(教育システムの変更)
・自身のDCマウスの完走
・自分以外の誰かがDCマウス完走
でした.(3つめはあまり公言してませんでしたが…)
当時の予定では5年間かけて実現しようと狙っていましたが、3年間で終わってしまったので燃え尽きた状態に近かったんですね.
でも全日本に行ってみると、この3年間で得た感情が思い出されました.
人類の上位と勝負したい、ハーフ決勝に出てみたい、1からステッパーを作ってみたい、自分の脳内にあるオリジナル機体を作ってみたい等々.
今は,マウス以外にもロボマスでトップを目指すとか他の目標も色々あります.
3年間自分を突き動かしていたものが無くなったので、フワフワと浮いている状態に近いのです.
いい機会だし,何をしたいのか改めて考える必要が出てきたな、と感じています.
ステッパーを自作してみるのか、ハーフをやるのか、クラシックを続けるのか、距離を置くのか、考えながら卒論を乗り切ろうと思います.
お付き合い、ありがとうございました.
明日はまんぼー君による「ロボット製作のスケジューリング」です.
ボクは長い期間をスケジュール守って開発できたことないので、参考にしたいですね….