マイクロマウスのテストモードの紹介
この記事は「マイクロマウスアドベントカレンダー2023」 1日目の記事です。
はじめに
こんにちは、なおフィスです。
2020年度ぶりにマイクロマウスアドベントカレンダーの旗振りをさせていただきました。 今年はなんと開催前に全枠埋まるという好スタートです。この勢いで、Miceアドベントカレンダーの復活も期待しています。
昨年度、私はESP32-S3の機能を活かした、マイクロマウスのシステム構成について紹介をしていましたが、今回は中級者向けに、マイクロマウスにおけるテストについて紹介して行こうと思います。
導入：テストの重要性
ちょっと堅い話ですが、まず、ソフトウェアの開発プロセス、各開発工程について話をします。
開発プロセスには 「ウォーターフォール型」、「アジャイル型」、「プロトタイプ型」などありますが、いずれの手法においても、以下の作業工程が必要になります。
- 要件定義： ユーザの要求から、求められる条件・要件を明らかにする。
- 設計：要求を満たす手段を構想し、具体的な機能に分解する。
- 開発：機能を実装する。
- 機能テスト：作成した機能が設計通りか確認する。
- 統合・統合テスト：個別の機能を１つのシステムに結合し、全体として要求された条件を満たすか確認する。
- 品質確認：最終的なシステムがすべての要求を満たすことを、総合的に確認する。
特徴として、
- 1の成果物の正しさを6で確認
- 2の成果物の妥当性を5で確認
- 3の成果物の動作を4で確認
という成果物の確認構造になります（V字フローで画像検索すると、差異はあれどイメージが付きやすいと思います）
ソフトウェア開発において、4~6は品質を確認・改める機会を得るための重要な工程であり、企業活動においては、この品質担保の仕方が製品の良し悪しに響くと言っても過言ではありません。
このことは、ソフトウェアのウェイトが高いロボットであるマイクロマウスにおいても言えることです。 そして、「性能をちゃんと引き出せる」というのは、中級者以上には必須とも言えますが、本番でそれを再現するには、テストモードを作成し確認・調整していくことも重要です。
テストモードの紹介
この記事では、私のマイクロマウスでのテストモードについて紹介していきます。
私の場合、以下の画像のように、競技モードとテストモードで大別し、テストモードを計11個を作ってあります。
ソフト開発経験者からすると、単体テストをすっ飛ばして、いきなり複合機能で確認しているじゃないか！！というツッコミはあるかもですが、ROS 2による迷路シミュレータ、MATLAB/Simulinkを使ったPlannerなど個別にテスト、確認する環境があります。
内訳について
駆動系とその他で分けて紹介します。
駆動系
制御に関わる大半を６種で確認しています。使用頻度も高く、順次動作を確認しながらオフセット量などを確認していきます。
調整する順序も重要ですが、できる限り単体の機能を確認してから、複合する機能を確認しています。 判断には、迷路に補助線を引くことで視覚的に判断していますが、大会会場では補助線がないため、定規を使って最後の微調整をしています。
以下、それぞれのモードに対し、モーションの補足です。
- 最短時ターン：（「」はモーションパターン）
- 「直進→壁切れ→ターン→直進→停止」：最短走行時のターン時の１モーションの流れを再現し確認
- (派生)「直進→壁切れ→ターン(斜め45/135）→直進(斜めの制御)→停止」：斜め走行時の壁制御を確認
- 「直進→壁切れ→ターン(斜めに)→壁切れ(斜め)→ターン→停止」：斜め走行状態からのモーションの確認
- 「直進→壁切れ→ターン→直進→停止」：最短走行時のターン時の１モーションの流れを再現し確認
- 直進：
- 「その環境での最長距離を低速で直進」： タイヤ系の調整
- 「その環境での最長距離を最高速で直進」： 速度の追従具合から各FF項、FB項を調整し、遅れなく追従できるように確認。（限界性能を確認）
- 超信地：
- 180度確認(左右)： FF/FB項の確認
- 360 x 10確認(左右)： FF/FB項の確認、ジャイロのゲイン確認
- 360 x 10回確認(左右)： （あまり使わないのでパス）
- 壁切れ：
- 「直進→壁切れ→直進→停止」： 壁切れの閾値をログから、壁切れ後のオフセット量を目で見て調整
- 前壁補正：
- 「停止→前壁制御(壁を手で動かして追従を確認)」： 壁との向き、距離を調整
- 探索時ターン：
いずれも、探索、最短時に使う関数・パラメータをそのまま利用するように作っています（重要）
その他
こちらの５種は主に、機体完成後やメンテ後に使用します。
- 吸引： 秤を使って何g吸えるかを確認。吸引力の調整は電源装置を使うことで、使用する電流量も確認しています。
- その場停止： （「宴会芸」とも言われる、目標速度０、距離０、目標角速度０、角度０に追従する制御）
- 並進方向のみFB制御： 機体を前後方向に移動させ、初期位置に戻ろうとする確認
- 回転方向のみFB制御： 紙の上に置き、紙を動かし向きが変わらないことを確認
- 並進＋回転のFB制御： 制御の発振が無いこと確認
- I/O確認： デバイスの単体テストです。（初めて使うものほどよく確認しましょう。）
- センサー確認： 一覧出力し、値の変化やノイズはなさそうかを確認
- センサーキャリブレーション： 壁センサーの値をcsvデータをシリアル通信で出力（距離に変換するためのデータセットとして利用）
調整は何をどこまで詰めているか？
一部を参考として紹介。（一部、私が学生の頃、Miceで採用していた調整基準です）
- タイヤ径：16区画直進で目視で1mm以上のズレがないこと
- ジャイロゲイン：20回転で目視で基準線とのズレがないこと
- オフセット値調整：目視でズレがないこと
- FF/FB項調整：感覚。（どの速度・角速度でも追従してるっぽいな〜。破綻してないな〜という感じ）
各テストモードが終わってから、探索や最短走行を試験走行。失敗した場合はログから原因となる動きを特定しテストモードを再走します。
調整するパラメータ数について
上記に紹介したテストから、パラメータを網羅的に調整しようとすると、パラメータが多いため大変です。 性能向上に伴い、ターンのパラメータを増やすと、調整項目が増えていき、「モード切り替え→パラメータの調整」する際、都度「ビルド＆書き込み」を繰り返すと膨大な時間がかかります。 他にも、直進時の「速度・加速度・距離」、超信地の「角速度、角加速度、角度、向き」など、状況によって細かく変えたくなることがあります。
私の場合、迷路情報の保存と同じ要領で、不揮発性メモリ領域にキャリブレーションデータを読み書きする機能を作ることで、ビルド〜書き込み時間をなくし、調整時間の短縮しています。
具体的にはyamlファイルに記載したパラメータをシリアル通信でマイコンに送信し、マイコン側はパラメータを保存しています。（私が使用しているマイコン（ESP32）ではUSBメモリのようなファイルシステムを持っており、パラメータのリストをテキストデータごとに保存し、起動時に読み込むようにしています）
これによりソースコード上に散在する値を変更するのではなく、調整用ファイル内の変更だけで調整を進めることができるので、ファイルの管理も用意になります。
まとめと補足
ざっくりではありますが、テストモードの紹介をしました。 駆動系とその他と雑に分けましたが、確認したいとき、確認するための方法を揃えておくというのが重要です。
１つ１つの動きを確認・調整していくことで長時間走る土台が固まるので、まだ決まったテストモードを持っていない方は参考にしてみてください。
補足をしますと、今回紹介したテストモードには、言語化できてないことや、下支えするツールありきな部分もかなりあります。 例えば、私の場合、ESP32-S3のPSRAM 2MBを使った豊富なログ情報と調整システムに駆使することで、大量のパラメータ調整を詰めていくという戦法を取っています。（逆にいうと、このスタイルを組みたいので、ESP32を選んでいます） このようなツールは何年も継続して活動する上で必須になるので、是非時間をかけて作ってみてください。
私自身、不揮発性メモリを使った調整の時短化は2017年ごろから行っており、調整速度の早さが私の戦績に大きく寄与しているので、中級者の方々には「マウスに役立つツールを作ってみる」ところから始めるのもどうでしょうか
明日の話。
PIDream.netさんの「クラッシュ時の止め方」です。フェールセーフは大事ですね。 『３・２・１ ゴー シュート！！！』
