スラロームのオフセット距離を補正する話
この記事はマイクロマウスアドベントカレンダー2025の７日目の記事です。
はじめに
昨日はY.Iの 我搬到了中国でした。
界隈で海外赴任までの流れがわかる貴重なサンプルと言えるのではないでしょうか？
あと、今年の春節は2/17からと遅めなので注意ですが、今年の全日本大会は2/21~22ですね。
今回紹介する補正とは？
それでは本題です。
スラロームではターン前後にオフセット距離を設けることが一般的です。 背景は複数あると思いますが、厳密な軌道追従や自己位置推定を導入することが個人開発が多いマイクロマウスでは実装が難しいことから、調整のための猶予項としてしばしば使われます。
（画像のオレンジの線がオフセット距離です）
このオフセット距離はシミュレーションを用いて計算したり、調整することで決定しますが、確認走行時には区画中心を走るなど、理想的な条件で確認する場合が多いため、本番とは条件が異なります。
本番との差
主に以下の２つ。
- 区画中心から横方向にずれる（本ページにおいては、進行方向をｘ、横方向をyとします）
- 回転方向にずれる（本ページにおいては、半時計回りを正とし、θで表現しますが、考慮すると難しいのでパスします。（私もまだ使ってない））
補正対象・手法
補正対象は前オフセット（スラロームの前に行う補正）と後オフセット、それぞれありますが、今回は主に前オフセットを中心に紹介します。 補正手段としては「オフセット距離を変更する」だけです。
前提条件
主に以下の２つが必要です。
- 横方向につけている光センサーについて、壁との距離を物理的距離に変換できること
- 最後に壁を見えていたときの、壁との距離を覚えてること
参考データと基本原理
画像は左の壁の切れ目が発生したときの参考図と壁センサーの値のログ（上が左、下が右側）です。
ほぼ区画の中心を走っていることから、right45_d(右45度センサーの距離[mm])の値は44mmを示していますが、同時刻の左側のセンサは65mmと壁の切れ目を通りすぎ、見えなくなってきていることがログからもわかります。
このとき、右壁が見え続けている場合なら、右壁までとの距離を使えば、「後オフセット」の補正距離は簡単に求まります。
float slalom_after_offset_dist = ~~~~~ // プロファイルからデフォルトオフセット距離を取得 float dy = 45 - right45_d [mm] // 壁との距離偏差を取得（マイクロマウス競技の場合45, クラシックの場合90) // 左右の壁の有無など、条件分岐などは省略 slalom_after_offset_dist += dy // 右に近づいている場合、dy>0 のため、後オフセット距離は増加。
しかし、横を見るだけでは、前オフセット距離の補正はできません。所謂「壁切れ」を使うことで前後方向を合わせることができているというのも、正確ではありません。
区画中心を走っていない状況下での壁切れ検出時の状態
画像はわざと左寄りに走らせたときのログです（制御を切った状態で区画中心に戻さないように設定を変更）。
特徴としては、ほぼ同じ時刻にも関わらず左壁との距離(left45_d)が遠のいてない（数値上大きくなってない）ということです。これは、横にずれて走行した際、壁切れは進行方向に対しても影響があると言えます。
このことから、壁切れ判定を用いたタイミングの補正だけでは不十分といえ、画像の場合、９０度回転するスラロームの場合、進行方向に画像上側（ｘ軸上）にずれることが予想できます。
前オフセットの補正距離の算出方法
左右(y)方向のズレとセンサーの取り付け角度(θ)から前後方向(x)のズレ量を推定します。
画像のように、壁と平行に走行している場合、壁の切れ目タイミングは、光センサーの光軸の角度と、y偏差量に対して、幾何形状的に比例関係があることが予想できます。 また、「壁切れのタイミングは壁との距離に関わらず、オレンジの先の軸上で実行可能である」ことを前提としていますが、センサーの誤差があることを含めると厳密には違います。
。
とはいえ、前後方向（ｘ軸上）の補正距離は以下のように幾何計算可能です。
float slalom_before_offset_dist = ~~~~~ // プロファイルからデフォルトオフセット距離を取得 float slalom_after_offset_dist = ~~~~~ // プロファイルからデフォルトオフセット距離を取得 float dy = 45 - right45_d [mm] // 壁との距離偏差を取得 float dx = dy * std::tan(theta) // θはセンサーの取り付け角度（CAD上の設計値を用いてる） slalom_before_offset_dist += dx; // dy<0のとき、壁切れ判定が遅れているので、dx<0で補正する // afterは省略
あとは走って見て、合うかどうかを確かめて見てください。 厳密に合わなくても、「補正しないよりマシ」というのが重要です。
注意事項
- サンプルコードでは、右センサーを使って判定していますが、場合分けし参照する値をうまく変えてください。左右で差が大きい場合、偏差量が小さい方を採用しましょう。
- 補正距離は、何かしら上限値を設けたほうが良いです。（私は5mmまでにしています）
2. 最後に壁を見えていたときの、壁との距離を覚えてることについての紹介はしませんでしたが、壁が見えてないときに使ってください。
最後に
この補正はここ数日で編み出してそこそこ効果がありそうなものだったので紹介しました。 センサーの値を正確に取れているかが非常に重要になってきますし、仮定を置いた箇所について、上限値などでうまくごまかしている部分もありますので、繰り返しになりますが、厳密な補正というより「マシにする」レベルと思ってください。
明日はタケぽんぬさんの「社会人１年目の振り返り」です。卒業後ADCに投稿してくれるのは偉い！！
開発環境やツールの紹介
この記事は「マイクロマウス Advent Calendar 2024」 14日目の記事です。
昨日はmhrさんがスラローム設計、２枚目の方もKojimouseさんが補足を....あれ...？（12/13 20:20時点ではまだですね・・・）
中部支部大会で前振りしていたとはいえ、突然メールをぶん投げたのに、登録していただけただけでも感謝です。
私のスラロームは大学を卒業する2014年度大会の頃にMiceで流行ったものをずっと使っています。 今日の記事でもその補助ツールが名前だけですが登場します。
導入
「ESP32使いとのことですが開発環境などはどうされていますか？」 という質問に応える形で、私のマイクロマウスの開発に使用している環境・ツールを紹介していこうと思います。
開発環境・ツール一覧
| No. | ツール名 | 用途 |
|---|---|---|
| 1 | ESP-IDF(custom) | ビルド環境 |
| 2 | Matlab/Simulink | Planningのシミュレーション環境 |
| 3 | maze_solver | ROS 2ベースの迷路探索アルゴリズムのシミュレーション環境 |
| 4 | maze creator | 迷路データの作成ツール |
| 5 | slalom simulator | スラロームパラメータの計算ツール |
| 6 | param tuner | パラメータの調整ツール |
| 7 | plot-juggler | ログの可視化ツール |
| 8 | vscode | エディタ |
| 9 | mm_maze_viewer | 迷路ファイルの可視化&編集ツール |
| 10 | sensor calibration | 光センサーのキャリブレーションツール |
| 11 | trajectory plot | 走行軌道の可視化 |
※メカ・エレキ系は除く
多いって？これが歴戦の賜物ってやつです。
しかも、自分で作ったやつはすべてgithubに公開してあります。
1. ESP-IDF
ESP32向けの開発環境です。
コンパイラもC++17に対応しており、組み込み界隈にしてはモダンな実装に対応可能できます。
RenesasやSTMicroのマイコンなどとは違い、アプリケーションはROMではFlash領域に書き込むようになっています。
デフォルトでpartition.csvにflash領域の使い方を設定することで、ファイルシステムとしても利用可能でテキストの読み書きなどもできます。
各種ペリフェラルの使い方は公式のドキュメントやESP-IDF内にサンプルコードがあるので、それをベースに作成してきますし、chatgptに聞くとサンプルコードが結構出てきます。
前述のファイルシステムには、迷路情報をファイルとして登録したり、パラメータすべてテキストとして保存し、起動時に読み込むようシステムを構築しています。
ESP-IDFでは標準でJSON parserが組み込まれているので、保存するテキストはほぼ全てがjson形式としており、
後述するparam tunerでは、このjsonテキストを送りつけることで、ゴール座標の変更はもちろん、各種ターンの調整にビルドを必要としません。
そのため、大会会場ではビルドをしていません。
1.1 ESP-IDFの改造について
本家のESP-IDFをそのまま使ってません。そのため表ではESP-IDF(custom)と表記していました。
改造の背景は、本家のSPIとADC機能はFreeRTOS上で複数のタスクから同時にリクエストされることを前提に、排他制御ができるように設計されていたり、都度、初期化などの無駄な処理を行っているため処理時間が遅いということがありました。これにより、処理が間に合わずシステムが不安定になってしまう場面があることに気が付きました。
それらを取り払った結果がこちら。
| before | after | 削減率 | 1ループ中の実行回数 | トータル削減時間 | |
|---|---|---|---|---|---|
| AD変換 | 16usec | 12usec | 25% | 2x4 + 1回 | 36usec |
| SPI変換 | 15usec | 9usec | 40% | 3回 | 18usec |
トータルで1ループあたり、54usecを削減しています。
これらの調査・検証は、各ループ処理中の実行時間を計測し、ログに書き込み、後述のplotjugglerで可視化したり、デバッグ用のprintfを仕込んで行いました。
以前は以下の画像の様な処理時間のバタつきが見られましたが、今では大分落ち着きました。
ESP-IDFには、時刻を取得できるAPIがあり、処理時間の評価や、センサーの時刻保証などに役立てています。
1.2 FreeRTOSのqueueの利用の廃止
FreeRTOSを利用していて気づいたのが、足立法などで決まったモーション（行動指示）をqueueを使って制御側に依頼を出すという処理をFreeRTOSのqueueを使って行っていたところ、受取時にかなりの処理負荷がかかるのか、処理遅延が見られました。（アドレスのみを送るなど、データサイズを削減してもダメ） 対策として、高速だが細かい情報は送れないnotifyを使うようにしたことで明らかな改善が見られました。
1.3 よく使うコマンドのスクリプト化
ビルド、flashなどは引数・パラメータは固定化されていますので、全部shellスクリプトにまとめてます。（話すと細かいので今回は省略）
1.4 ワークスペース全般の話
お恥ずかしい話ですが、2021年11月にドタバタと作ったので記憶にないです。 ESP-IDF自体もアップデートが進んでいるため、やり方・体裁が古いかもしれません。参考にされる際は注意。
2. Matlab/Simulink
各モーションに対して1stepごとの指示値を算出する、いわゆるPlanner機能のシミュレーションをしてます。前職で「モデルベース開発」というものをやっていたのですが、題材は違えど、その練習も兼ねて作りました。
Matlabのライセンスは毎年マイクロマウス向けにフルライセンス（全部買ったら、数百万円とかするレベル）な上、商用利用オンリーのものもあったりと、大盤振る舞いです。
Simulinkのモデルをコマンド一つでビルドし、マウス側で使えるようにコピーすることで、手間を省いていたりします。
3. maze_solver
迷路探索アルゴリズムのシミュレーション用に作りました。
コロナ禍で大会がない時期、復帰時にはRenesasからESP32に移行することは決めており、C++の練習がてらシミュレーター兼、アルゴリズム開発のために作りました。
過去の課題迷路を使ってシミュレーションし、賢い探索アルゴリズムを検討・実装に役立ちました。
こちらも仕事でROSを使うようになり、勉強がてら作り、元はROS 1で作っていたのですが、転職先がROS 2がメインだったので、ROS 2に移行しました。
最近は探索アルゴリズムに関する課題はあまりないため、お役目終了気味です。
4. maze creator
2016~2019まで使用していたRenesasマイコンで作ってた時代の調整システムに付随して作っておいた、迷路情報作成ツールです。 Webアプリで作っていたのですが、保存機能がなかったりと不器用なためお蔵入り。
（作る過程でサーバ、ネットワーク、GUIなどなど色々と勉強になったので感謝してる）
5. slalom simulator
スラロームに使用しているパラメータを計算してくれるツールです。
速度、角度、基準旋回半径、終端位置を指示することで、よしなに計算してくれます。 計算結果はyamlファイル形式で出力されるので、パラメータファイルに転記して使ってます。
軟化子というものを使って曲線加速を実現しています。
一括変更機能もあるのですが、高速化していくにつれて、手動で変更を加えたい部分が増えてきたため、意図しない上書きを回避するため、一括変更はやめました。
6. param tuner
前述の通り、ESP32はファイルシステムを持てるので、テキストデータをUARTで送受信する機能だけを行ってます。 ESP32側では、指定したファイルに文字列を保存する。起動時に読み込む。 だけを行ってします。
この機能の他に、ログファイルの保存機能が２種類あります。
- 走行ログの時系列データのcsvにして保存する。
- 迷路情報をテキストファイルとして保存する。
7. plot-juggler
OSSとして公開されている、可視化ツールです。起動時にcsvファイルとレイアウトファイルを指定し起動します。（起動したままcsvファイルを入れ替えるという使い方は向いていない）
6で紹介したログのcsvファイル保存と連携しており、保存時にファイル名を日付時間で保存しているのと同時に、latest.csvという固定のファイル名をコピーし作成しています。
これで、起動時の引数を固定することができますし、ファイル名は日付にしているので、ファイル名でソートして、「新しい方からN個目」を指定して描画するという起動用スクリプトを書けば、過去のデータも簡単に見れます。
8. vscode
エディタです。キーマップはEclipseという昔は広く使われてたが今はあまり聞かないIDEのキーマップを採用してます。（初めてのプログラマーのバイトで覚えた）
github copilot(課金)も使ってコーディング量を減らしてます。
9. mm_maze_viewer
迷路データ作成ツールが使えなくなってしまったため、新しいツールを爆速でつくって公開した話 - なおフィスのブログ こちらで紹介したやつ。新入りです。
10. sensor calibration
csv形式でdumpした光センサーをデータから、AD値と距離の関係式を推定するツールです。 壁との距離から指定した式に曲線フィッティングします・
11. trajectory plot
plot-jugglerと似たようなものですが、csvに記録したx-y座標情報を可視化します。 動きが早くなっていると、位置と状態が目で追えないため、最近作りました。
まとめ
ざっと11個紹介しましたが、GUIに関わるもの多いです。 「正確性の向上と手間を省く」を実現するには可視化できるスキルは持っておいて損はないですし、どれも開発資産として有用です。
上位陣でこの手のツールを使ってない・作ってないという人はいないと思います。
最初はエクセルベースでグラフを描画するなど、導入は色々あると思いますので、スキル向上にもつながるので是非トライしてみてください。
他にも、便利な開発時の課金要素で思いつくのは
- chatgpt(無料枠あり)
- 生成したコードを理解する読解力と、意図したものを出させる説明力が必要
- こういった生成AIを使いこなすことも、将来の仕事に求められる資質かも？
- github-copilot(学生なら無料だったはず)
- とりあえず、使っておいていいのでは？
- そもそもgitは、使ってないやつなんていねぇよな!!?というぐらい、ソフトウェア系の仕事につくならやっておけという代物です。
- 高級キーボード
- お気に入りの一品を持つと満足度が上がります。
などありますが、お試しで使ってみてください。
最後に
明日はコヒロさんから「昇圧について」です。
昇圧はロマンではありますが、色々リスクがあるかな〜と思って中々手を出せてないので、今後の参考にします。
迷路データ作成ツールが使えなくなってしまったため、新しいツールを爆速でつくって公開した話
この記事は
マイクロマウス(2) Advent Calendar 2024の1日目です。
１枚目が全枠埋まってしまった点と、書いてくれる人の層が変わらないな〜と思ってゆるく作ったものですが、全然枠が空いているので、今からでも是非登録の方、よろしくおねがいします。
いきなり脱線
「強くならないと、読んでもらえるような良い記事が書けない」と思っている方へ。
「自分の力で調べて成長できる強い人だけが良い記事を書ける」という考え方は、少し甘いかもしれません。実際には、良い記事を書くためには他者との関わりやフィードバックが欠かせません。この点で、順序や前後関係が逆になることもあります。
私の意見をお伝えします。
記事を書いて発信すると、コメントや感想をもらえる機会が増えます。そのやり取りの中で、「この人とは技術の話ができそうだ」と認識され、他の技術的な話題でも声をかけてもらえるようになることがあります。このようにして、自分があまり興味を持っていなかった分野についても知識を深めることができ、結果的に知識の幅が広がります。この幅広い知識は、予想外の場面で役に立つことがあります。
例えば、大学のレポートで間違いを指摘されてリテイクを求められる経験だけでは、この重要性にはなかなか気づけないでしょう。しかし、技術者にとって最も大切なのは、技術を吸収できる環境に身を置くことです。その環境を作るために、「発信力」を身につけることは非常に重要なスキルだと私は考えます。
書き散らしは以上、それでは本題。
大学時代の卒業制作のツールが使えなくなっていた
シーズン後半に入り、勝負パラメータを決めようと思い、トップ帯とのタイム差をシミュレーションするため、迷路情報を作ろうとしたところ、文字化けやら何やらぶっ壊れている。（現在は復旧してくれたようですが文字化けなどが直ってない）ツールのリンク
このツールは、2015年卒業時、Miceでは「卒論」というのがありまして、ブログ記事の投稿や卒業製作が総会か部会で可決されたため作りました。（確か部則だった気がするので、消されてない限り現在も有効だったりします）
迷路情報を公開し、迷路探索アルゴリズムの作成、研究に役立ててもらいたい、という思いから当時の拙いWeb技術で作ったものになっています。
なぜ使えなくなっていたのか
jQueryを取得する際セキュリティエラーが弾かれてたようです。 現在は管理者に対応してもらいましたが、流石に10年前の技術ですから、限界がありますね。
今回作ったもの
Visual Studio Codeの拡張機能で*.mazeというテキストデータ形式から、迷路画像を出力しその画像内でクリックをすると迷路情報のテキストデータを更新してくれる というものです。（ファイルの編集のみで保存までは行いませんので、自分で保存してください。）
利用例
１． 拡張機能でmm_maze_viewerを検索し、インストール。
２．chubu2024.mazeというファイルを用意（32x32版で用意）
14,6,6,6,4,6,6,6,6,6,6,6,6,6,6,5,12,4,4,4,4,4,4,4,4,4,4,4,4,4,4,5, 12,6,6,6,2,6,6,6,6,6,6,6,6,6,7,9,8,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1, 9,12,6,6,6,6,6,6,6,6,6,6,4,6,5,9,8,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1, 9,9,12,4,6,6,6,6,6,6,4,7,11,13,9,9,8,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1, 9,9,9,8,6,7,12,6,6,5,9,13,12,2,3,9,8,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1, 9,9,9,10,6,6,3,12,6,3,10,2,3,12,5,9,8,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1, 9,9,9,12,5,13,14,2,6,5,12,6,4,3,9,9,8,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1, 9,9,9,9,10,1,13,12,4,1,9,12,2,5,9,9,8,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1, 9,9,9,9,14,2,1,10,3,11,8,3,12,3,9,9,8,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1, 9,9,9,8,5,12,0,4,7,12,2,5,10,5,9,9,8,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1, 9,9,9,9,9,9,9,10,5,10,4,3,12,3,9,9,8,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1, 9,9,10,3,10,3,10,6,0,5,10,5,10,5,9,9,8,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1, 9,9,12,6,6,6,6,5,9,10,5,10,5,9,9,9,8,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1, 9,9,10,6,6,6,5,9,10,6,2,5,10,1,9,9,8,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1, 9,10,6,6,6,6,3,10,6,6,5,10,6,3,9,9,8,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1, 10,6,6,6,6,6,6,6,6,6,2,6,6,6,2,3,8,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1, 12,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1, 8,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1, 8,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1, 8,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1, 8,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1, 8,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1, 8,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1, 8,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1, 8,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1, 8,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1, 8,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1, 8,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1, 8,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1, 8,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1, 8,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1, 10,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,3
３．迷路ファイルを開いた状態で、ctrl+shift+pでMaze Previewを実行。
テキストファイルの右側に以下の画像のようなプレビュー画面が出ればOKです。
あとは、画面をクリックすることでテキストデータが修正されていきます。
迷路をゼロから作りたい人は、拡張機能の紹介ページにテンプレートを用意しているので、そちらをご利用ください。（16x16版のリンク）
どうやって作ったのか？
ほぼ全てchatgptです。
vscodeの拡張機能自体初めて作るし、公開も初めてだったのですが、意外とスムーズに済ませられました。
以下、コード作成時にChatgptに指示した内容の要約です。（この要約もchatgptに書かせた後、少し修正）
指示内容の概要
1. VSCode拡張機能の開発
そもそもやりたいことが実現できそうかを確認
- SVGを用いた迷路エディタの作成： 4x4ぐらいのサイズでコンセプトを確認
- クリックイベントを利用した迷路データの編集機能： クリックとテキストデータの編集の流れを確認。
.mazeファイルの読み込み・書き出し機能。： txtファイルから.mazeに変更。
2. SVGの動的生成と編集
SVG上に迷路を描画し、クリックと迷路データの編集ロジックの構築
- SVGの描画形式をマイクロマウス形式に変更。： 壁がある座標に四角を設置。見えないときは透明とするように工夫
- クリック位置の取得と座標補正（縮尺対応）。： クリックした対象の座標情報は取得する際、画面をズームしていると縮尺がずれるため、相対位置を考慮した取得方法に変更し取得。
- クリックしたセルを対角線で4分割し、クリック位置を分類（north, east, south, west）。： 壁ではなく、セル内をクリックしたときにも編集が可能なようにUX上ケア
3. READMEの作成と多言語対応
ここで公開方法を別途調べ公開用のコマンドを実行したところ失敗。READMEが体裁に沿ってないとのことで、chatgptに作らせた。
- VSCode拡張機能のREADMEを作成。： ここまでのchatgptに指示した内容をベースにいい感じにしろと指示。
- 英語と日本語を併記したREADMEの作成。： 日本人ユーザが多いことを期待し併記するため指示。（公開後、Facebookのマイクロマウスコミュニティにも投下）
4. コードに関する処理やロジックの改善
自分でも使う以上、最低限の使いやすさ、見やすさなどUI/UXをこだわる
- テキストデータ処理における改行の挿入。： １行にまとめると見にくい＋編集された実感がないので工夫。
- VSCodeの拡張機能に設定画面を追加。： パラメータで壁の東西南北がそれぞれ何ビット目かなど対応できるように、パラメータだけ取れるように修正（反映側は未対応）
- 設定画面の表示順序を制御。： 設定順をコントールできると手順書が書きやすいため指示。（うまく行かなかった）
こんな感じです。
作業時間はおそらく4時間も必要なかったです。初めてのvscodeの拡張期の開発だったので、慣れればもっと早かったはず。
作ったコード
githubでも公開してます。
最後に
明日の当番は・・・（ないですね。） 学生大会後の感想、課題などなど待ってます。
マイクロマウスのテストモードの紹介
この記事は「マイクロマウスアドベントカレンダー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さんの「クラッシュ時の止め方」です。フェールセーフは大事ですね。 『３・２・１ ゴー シュート！！！』
マイクロマウスアドベントカレンダー2023について
この記事は「マイクロマウスアドベントカレンダー2023」 マイナス10日目の記事です。
はじめに
今年は数年ぶりに全地区大会が一度の延期もなく、予定通り実施されましたね。 大会運営に関わってる方々には、以前と変わりない運営をしていただきまして、ありがとうございました。
軽く地区大会の振り返りをば。
私は例年、金沢、東日本、北信越、中部に絞ってスケジュールを組んでいましたが、今年は大学卒業以来初となる東北地区にも行きました。
実は、４度目の東北地区大会出場にして、初のタスパークホテルに宿泊でした。 というのも、大学の頃は基本ゼロ泊4日という強行軍で、「大会会場がホテルなのにホテルに泊まるという概念がなかったサークル」でした。 「あの部屋」の復活待ってます！
他にも、中部地区では「特別賞(勇者)」をいただきました。
勇者というと「葬送のフリーレン」が連想しますが、 私に関して言うと、決して、時事ネタだから、目新しいから印象的、という訳ではなく、 今シーズンの大会のデータシートには「そろそろ勇者パーティーがいてもいいのでは？」ということをずっと書き続けていましたので、「乗ってくれた！（ということにしてる）」という思いです。
是非とも魔王軍を滅ぼしたい人は残り２か月半頑張りましょう！！（もちろん来シーズンも）
転生者、チート持ちをお待ちしております。
地区大会の振り返りは主題ではないので、そろそろ主題に。
このAdventCalendarについて
過去には学生さん同士の煽りあいにより成立していましたが、今年はそういう訳にはいかなさそうなので、エントリーに際し、何点かお伝えしたいなと。
何を書けばいいか？
何でもありです。というのは困ってしまいますよね。
先にNGをあげます。
「ちゃんとしたものを書かなくては」という思い込み
「なんでもいい」の緩さを伝えるため、せっかくなので例をあげます。
ね？何でもありでしょう？
以下に、過去のアドベントカレンダーのリンクを張っておきます。参考にしてください。
「知識/実力不足だから」と書かない、エントリーしない
ここで伝えたいことは
- 執筆中に考えが整理されていくことが多くある
- 困っていることは発信することで誰かの助けになることがある。
あとは 「発表した奴が一番偉い」というのもあります。
書く内容がない
大会に出ている人、完璧にしてからエントリーして、いい成績が出せたことはありますか？
ないですよね？ということで、エントリーしてから考えてください。
こんな記事があるといいな
昨年度の全日本大会にて実行委員会の先生から「参加者が初級者と上級者に二極化している」という話がありました。
このことから、
- もっと成績を良くしたいのに、～に困っている。
- ～ができたら途端によくなった。 などノウハウが溜まるとうれしいです。
是非とも登録をお願いします。
枠がいっぱいになったら２枚目作ります。
マウスのシステム構成の紹介
この記事は、「マイクロマウス Advent Calendar 2022 - Adventar」３日目の記事です。
こんにちは、なおフィスです。昨日は、ウメちゃんによる設計のノウハウ紹介でした。
タイヤに関し、運用含めノウハウが詰まった記事でしたね。単に、運動性能だけを語るのではなく、トレードオフを意識しつつ、運用も見据える。強者の目線ですね。
さて、今回は、昨年度から参戦をしているハーフサイズ競技における、システム構成について、大雑把ですが、語りたいと思います。
導入：利用しているマイコンの紹介
ESP32-S3という7x7mmサイズに、2コアが載ったマイコンを採用しています。 同シリーズを利用している人は非常に少ないですが、以下の魅力的な特徴があります。
- 開発環境の依存性が少ない。公式の開発環境ESP-IDFが提供されている。
- チップの単価が安い（300~400円程度）。昨年度の半導体不足の環境下で新作を量産。
- A/D変換を除くと、SPIなどの専用ポートなどの制約がないため、ピンアサインは対応するIC・部品に一番近いところを選べばよい。
- フラッシュ領域（最大8MB程度）はファイルシステムとして利用可能（ファイルの読み書きができ、迷路やパラメータを保存可能）
- メモリマネージャが利用可能（簡単に言うとヒープ領域に対し、動的なメモリ確保を「何度も」できる。STLのコンテナ（vectorなど）も使える）
- FeeRTOS対応
このように、様々な特徴を備えていますが、それを使いこなすには、良いソフトウェアシステムであることが求められると考えています。
それは「各機能の役割が明確」であり、「機能進化のための拡張性や互換性が保てる」ものであり、かつ、「実装しやすい」ものが理想と考えます。
今回、私が考案したシステム構成を紹介します。
システム紹介
以下、システム概要図
図は、Core0とCore1にタスクの配備状況、各タスクが担う役割と、データの流れの簡易的に表したものです。
以下、各タスクが有する機能の紹介です。
main_task
マウスの基本機能を実行するメインルーチンともいえるタスクです。
主には、足立法の実行や、必要なモーションを決め、動作が終わるまで待つといった、意思決定と要求を順序に沿って行います。
また、「調整値読込」では前述のファイルシステムの機能を用い、シリアル通信で送り付け保存したテキストファイル（jsonテキスト）を読むことで、タイヤ径などの値をソースコードではなく、フラッシュ内のファイル上の値を用いるようにしています。 これにより「再ビルドすることなく」調整したい値を反映・確認を可能にしており、調整作業の時短に繋げています。
読み込むパラメータはPIDのゲインなど様々な値があり、起動時に他のタスクが使うパラメータを更新するようにしているため、大会会場では原則再ビルドの必要はありません。
sensing_task
各センサーから値を取得します。このタスクはマウスがおかれている状況は把握してないため、扱うデータは基本生値（A/D変換の結果そのまま）としています。
- 壁センサー（IR_LED + IRセンサー）の値をA/D変換で取得。
- ジャイロセンサーの値をSPIで取得。
- バッテリー電圧をA/D変換で取得。
planning_task
main_taskからの動作要求に対し、置かれている状況を踏まえ、sensing_taskの結果を物理量に置き換えた値から、目標の状態を算出。 目標値偏差からFB制御（PID）や、FF制御（内部モデル制御（Internal Model Control））による制御量を算出し、モータに与える出力（Duty）として反映します。
logging_task
認識結果や制御、システムの状態をメモリに貯めこむタスクです。 走りながらファイルシステムにデータを保存することは性能上できませんが、300kByte超のRAMとSTLのコンテナによるお手軽な動的データ確保機能を活かし、複数のデータを記憶、csv形式で出力することで可視化ツールと連携し解析作業をしやすくしています。
まとめ
簡単ではありますが、システムの構成を紹介しました。 役割が不明確で、複雑でスパゲッティなシステムを作ると、何年もわたって進化させることが難しくなってしまうため、これから作る人・作り直したい人には是非、以下の観点を意識してみてください。
- タスクレベルで役割が明確であるか
- 図より相互関係は明確といえる
- 拡張性・互換性があるか
- タスク間を行き来するI/F(構造体)を拡張することで、容易に可能。
- 実装が容易であるか
最後に
明日は後輩の半田ディザスターの人こと、しろめ君です。
10月に、個人的に学生大会を見据えた講習をしたのですが、無事優勝を勝ち取ってくれたので、やった甲斐があったかなと勝手に満足していますｗ
そんな彼が、直前に何をしていたのでしょうか（焦るようなツイートをしていた記憶がある）
2021年度マウス活動振り返り
はじめに
IREXでの全日本大会お疲れ様でした。 試走会からの参加はできず、IREXの展示もある程度絞りながらではありましたが、普段とは違う大会を味わえたなと思います。 難しい情勢のなか、運営、関係者各位本当にありがとうございました。
大会結果
セミファイナル３位
過去の大会の実績から、セミファイナル不適切との判断。受賞なし。
実質、セミファイナル出禁と受け取りましたｗ
感想
斜めなし、壁切れなし、ターンのパラメータはシミュレーター通りでオフセット距離の調整は一切しないという個人ルールで走り切れました。 色々不安定なところが有りますが、環境や言語などこれまでのソフトの資産が一切使えなかったので、今後時間を書けて育てていきたいところです。
１１月にハード設計初めて１２月中旬ぐらいに完成してからの最短まで感想なので、まぁ良いでしょう。
次年度について
新しいマシーンの設計、発注が完了しており、既に一部部品を組み立ててます。 マイナーチェンジ機なので大きな変更はありませんが、シーズンを通じて少しずつ改良する感じにしていこうと思ってます。
32×32対応も既に終わってまして、解を出すロジック面は何もせず、計算コスト面で工夫をしただけですが、来シーズンはコレで挑めるかなと。
いずれはプロファイルの修正だけで、クラシック・ハーフの両方を同じソフトで挑みたいですね。
