迷路データ作成ツールが使えなくなってしまったため、新しいツールを爆速でつくって公開した話

この記事は

マイクロマウス(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拡張機能の開発

そもそもやりたいことが実現できそうかを確認

1. SVGを用いた迷路エディタの作成：　4x4ぐらいのサイズでコンセプトを確認
2. クリックイベントを利用した迷路データの編集機能：　クリックとテキストデータの編集の流れを確認。
3. .maze ファイルの読み込み・書き出し機能。：　txtファイルから.mazeに変更。

2. SVGの動的生成と編集

SVG上に迷路を描画し、クリックと迷路データの編集ロジックの構築

1. SVGの描画形式をマイクロマウス形式に変更。：　壁がある座標に四角を設置。見えないときは透明とするように工夫
2. クリック位置の取得と座標補正（縮尺対応）。：　クリックした対象の座標情報は取得する際、画面をズームしていると縮尺がずれるため、相対位置を考慮した取得方法に変更し取得。
3. クリックしたセルを対角線で4分割し、クリック位置を分類（north, east, south, west）。：　壁ではなく、セル内をクリックしたときにも編集が可能なようにUX上ケア

3. READMEの作成と多言語対応

ここで公開方法を別途調べ公開用のコマンドを実行したところ失敗。READMEが体裁に沿ってないとのことで、chatgptに作らせた。

1. VSCode拡張機能のREADMEを作成。：　ここまでのchatgptに指示した内容をベースにいい感じにしろと指示。
2. 英語と日本語を併記したREADMEの作成。：　日本人ユーザが多いことを期待し併記するため指示。（公開後、Facebookのマイクロマウスコミュニティにも投下）

4. コードに関する処理やロジックの改善

自分でも使う以上、最低限の使いやすさ、見やすさなどUI/UXをこだわる

1. テキストデータ処理における改行の挿入。：　１行にまとめると見にくい＋編集された実感がないので工夫。
2. VSCodeの拡張機能に設定画面を追加。：　パラメータで壁の東西南北がそれぞれ何ビット目かなど対応できるように、パラメータだけ取れるように修正（反映側は未対応）
   1. 設定画面の表示順序を制御。：　設定順をコントールできると手順書が書きやすいため指示。（うまく行かなかった）

---

こんな感じです。

作業時間はおそらく4時間も必要なかったです。初めてのvscodeの拡張期の開発だったので、慣れればもっと早かったはず。

作ったコード

githubでも公開してます。

github.com

最後に

明日の当番は・・・（ないですね。） 学生大会後の感想、課題などなど待ってます。

マイクロマウスのテストモードの紹介

この記事は「マイクロマウスアドベントカレンダー2023」 1日目の記事です。

---

はじめに

こんにちは、なおフィスです。

2020年度ぶりにマイクロマウスアドベントカレンダーの旗振りをさせていただきました。 今年はなんと開催前に全枠埋まるという好スタートです。この勢いで、Miceアドベントカレンダーの復活も期待しています。

昨年度、私はESP32-S3の機能を活かした、マイクロマウスのシステム構成について紹介をしていましたが、今回は中級者向けに、マイクロマウスにおけるテストについて紹介して行こうと思います。

導入：テストの重要性

ちょっと堅い話ですが、まず、ソフトウェアの開発プロセス、各開発工程について話をします。

開発プロセスには 「ウォーターフォール型」、「アジャイル型」、「プロトタイプ型」などありますが、いずれの手法においても、以下の作業工程が必要になります。

1. 要件定義： ユーザの要求から、求められる条件・要件を明らかにする。
2. 設計：要求を満たす手段を構想し、具体的な機能に分解する。
3. 開発：機能を実装する。
4. 機能テスト：作成した機能が設計通りか確認する。
5. 統合・統合テスト：個別の機能を１つのシステムに結合し、全体として要求された条件を満たすか確認する。
6. 品質確認：最終的なシステムがすべての要求を満たすことを、総合的に確認する。

特徴として、

• 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 2021 - Adventar
• マイクロマウス Advent Calendar 2022 - Adventar

「知識/実力不足だから」と書かない、エントリーしない

ここで伝えたいことは

• 執筆中に考えが整理されていくことが多くある
• 困っていることは発信することで誰かの助けになることがある。

あとは 「発表した奴が一番偉い」というのもあります。

書く内容がない

大会に出ている人、完璧にしてからエントリーして、いい成績が出せたことはありますか？

ないですよね？ということで、エントリーしてから考えてください。

こんな記事があるといいな

昨年度の全日本大会にて実行委員会の先生から「参加者が初級者と上級者に二極化している」という話がありました。

このことから、

• もっと成績を良くしたいのに、～に困っている。
• ～ができたら途端によくなった。 などノウハウが溜まるとうれしいです。

是非とも登録をお願いします。

枠がいっぱいになったら２枚目作ります。

マウスのシステム構成の紹介

この記事は、「マイクロマウス 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(構造体)を拡張することで、容易に可能。
• 実装が容易であるか
  • main_taskではSTLのコンテナ(vector)などを活用。実装コストを下げることに成功

最後に

明日は後輩の半田ディザスターの人こと、しろめ君です。
10月に、個人的に学生大会を見据えた講習をしたのですが、無事優勝を勝ち取ってくれたので、やった甲斐があったかなと勝手に満足していますｗ
そんな彼が、直前に何をしていたのでしょうか（焦るようなツイートをしていた記憶がある）

2021年度マウス活動振り返り

はじめに

IREXでの全日本大会お疲れ様でした。 試走会からの参加はできず、IREXの展示もある程度絞りながらではありましたが、普段とは違う大会を味わえたなと思います。 難しい情勢のなか、運営、関係者各位本当にありがとうございました。

大会結果

セミファイナル３位

過去の大会の実績から、セミファイナル不適切との判断。受賞なし。

実質、セミファイナル出禁と受け取りましたｗ

感想

斜めなし、壁切れなし、ターンのパラメータはシミュレーター通りでオフセット距離の調整は一切しないという個人ルールで走り切れました。 色々不安定なところが有りますが、環境や言語などこれまでのソフトの資産が一切使えなかったので、今後時間を書けて育てていきたいところです。

１１月にハード設計初めて１２月中旬ぐらいに完成してからの最短まで感想なので、まぁ良いでしょう。

次年度について

新しいマシーンの設計、発注が完了しており、既に一部部品を組み立ててます。 マイナーチェンジ機なので大きな変更はありませんが、シーズンを通じて少しずつ改良する感じにしていこうと思ってます。

32×32対応も既に終わってまして、解を出すロジック面は何もせず、計算コスト面で工夫をしただけですが、来シーズンはコレで挑めるかなと。

いずれはプロファイルの修正だけで、クラシック・ハーフの両方を同じソフトで挑みたいですね。

1ヶ月でマウスを作ってみた

この記事はマイクロマウス Advent Calendar 2021 - Adventar11日目の記事です。

昨日は入院をしていたアライさんどうぞご自愛ください。
最近マウサー界隈、体調崩す方が多いので、自分も体調を気をつけたい。（といいつつ、無頓着なんだよなー）

---

さて、今回は、新作を１ヶ月で作成したので、その話をします。

きっかけは、この告知。

ビックサイト開催を知ったのは、11/6のことである。

さて、ここ１年の自分の行動を確認しよう。

• 昨年はBustersする相手がいないため、Bustersを休業。
• 今年も秋まで具合から、オンラインだろうと判断。
• 使ってみたい、ICの発売遅延と知り更にだらける。（watchだけはしてた）

このモラトリアムからの急転換であった。

国際ロボット展なので、何であれ、行くのは決定事項。行ったら捕まるので、自分から出向くしかないなと判断。 走らせるものがないと話にならないので、ハードウェアから用意を開始。マイクロマウスづくりRTAを実施。 今回はハーフサイズ。
ハーフに致命的な設計ミスがあったら、クラシックでExiaAlter出します。

スケジュール確認

２月に調整に集中したい。となると、１月末までに基本システムの構築、１２月中にはハードウェアをFIXさせなくてはならない。
ということは、11月から年末までの１ヶ月〜２ヶ月でハードウェア周りFIXさせなくてはならない。
（最近、仕事でもプライベートでもスケジュールに追わてる！）

コンセプト

とは言え、コンセプトを決めなくては形も定まらない。以下のように（後付）設定した。

1. 脱Renesas
2. C++を使う
3. ESP32-S3を使う
4. K峰さん撃墜を目指して基礎を固める。

1については、RX71Mや72Nの在庫があるが、RXシリーズやる気なさそうだし、開発環境もやる気なさそうだし、見限りました。
2については、ここ数年rosで戯れていたということも有り、夏休みにシミュレータを再構築した。
3については、ピンアサインの制約が小さく、十分なRAM、処理速度、そして開発環境はOS縛りからの脱却。
4については、クラシックでは宇宙人枠でカウントされてますが、ハーフは試作機止まりなので、地球人からやり直し。K峰さんの機体の重さなどを参考に目標値を設定。

設計

CPU

ESP32-S3は2021年12月時点でサンプル品がdigikeyにて手が入る、という流通レベル。チップ単体での販売は現時点では行われてないため、WROOMボードからヒートガンをつかって剥がすことにした。

ESP32-S3は内蔵フラッシュがあるタイプと、ないタイプがあり、WROOMボードは内蔵フラッシュなしだったため、仕方なく外付けフラッシュを搭載して設計。 MINIボードの方は8MBのフラッシュがある模様。

ピンアサイン

ESP32はADCのピン以外は特に機能の制約がないため、spreadsheetである程度雑にアサイン。

ICはdigikeyと手持ちの在庫を見ながら調整。

一気に仕上げた（この画像では外付けフラッシュなし版）

足回りの設計

磁気式エンコーダは手持ちのAS5147Pを選択。旧作マウスの足回りからESP32のパルスカウンタで値が取得できるかを確認。 ピニオンギアは2017年ごろに買った在庫に合わせて設計。(kkpmoで発注したが３週間経過したが発送されない。)

開発環境の確認

ESP32-S3とS2はピンコンパチではないがWROOMボードならコンパチなので、 届いたWROOMをESP32-s2-devkitcボードに無理やり移植し火入れ。一発成功しuartでデフォルトで設定されているアプリが吐き出す文字列を確認。

そして、ESP-IDFを使い開発環境を構築を実施。 ESP32の開発の場合、通常platformioを使い、GUIサポートなどを受けながらが楽なのだが、S3は最新のためplatformioが最新のESP-IDFに対応していない。 そのため、ESP-IDFを単独利用を敢行。複数のバージョンを試したが、v5-devに落ち着いた。

発注＆組み立て

足回り

DIDEL mk-06-4.5で仮組み。 実はタイヤをつけるとシャフトとタイヤが干渉。千石で売っているアルミプチカッターにて切断。

この時アルミプチカッターで切断後の表面処理用にリューターを購入。

mk-06を使うのでは、目標としているK峰さんマシーンに回転数では同等となる。更にスペックを狙う場合、より回転数が出せるモーターを選ぶことになるが、その場合、モーターの全長が長いものしか無く、収まりきらないという問題が生じる。

「収まらないなら削ればいいじゃないか。」 ということで、リューターで器用に後の金属部スレスレまでプラスチック部を削り落とした。だが、まだ足りない。 ダイヤモンドカッターを使って金属部をどれだけ削って良いのか限界を確認。 意外と行けるが、全体を削ると当然プラスチック部が落ちる。（性能は落ちている可能性はある）

最後に互い違いになるようにして、配置することでモーターは完成。 （まさかモーターのシャフト以外を加工するとは・・・）

はんだ付け

ステンシルとヒートガンを使ってLGAパッケージたちをはんだ付け、無事１度もショートすること無く完成。

完成

ExiaAlterから継承したセンサー５つ構成

重さはというと、 仮のバッテリーを使って17.1gなので、実際はもう少し軽くなると思いますが、少し改善できそう。 当初目標にしていたK峰さんのロング１９号機はセンサー４つで１６ｇなのでいい勝負なのでは無いだろうか。

作り終わって

短期決戦ということも有り、在庫を駆使しつつ、楽をしながら、作ってみました。 各方面に怒られそうなことをやってますが、自己責任です。 参考にするかは今年の大会結果が出てから判断してください。（12/7時点でここまでに執筆）

2021.12.10時点 での話

既にESP32S3の使用なのか、起動時や書き込み時にHighになるピンが複数存在し、 モーターが全力で回転するという嫌な事象に遭遇しています。ESP32の一部のモデルには起動時の値がHighになるという言及が有りますが、S3にはないので困ってます。場合によっては回避した基板を作成してしまおうか検討中。（ちゃんと調べて直す時間よりも、さっさと回避した基板を発注したほうが安上がり？）
工場出荷直後の状態でテスターを当ててもHighだったので、チップ側が原因（仕様）っぽいですね。

つまり・・・・

１ヶ月でマウス完成しませんでした！！！！（2021.12.10 23:45に確定）

モーターが分回るのが嫌なら、初期状態の状態リストを作って、影響が出るモーターやブザーを避けて再度基板作しかないですね

---

オチがついたところで、明日の担当はkerikun11です。/dev/nullとのことで、ログも何もかも握りつぶされるので、何が来るかわからないですね。

追記

某５年制大学の圧政によって、Miceが息していないため、MiceBustersは名乗る意味は少ない。
どうしようか？と考えているのですが、最近、ふと思うのです、毎年表彰台を荒らす某組織Dに対抗する組織が必要なのではないかと。
考えた組織名は、
対D抵抗組織「D_structions」(ディーストラクションズ)

１強は流石につまらない。抗いたいという人たち、とりあえず、名乗りませんか？ 構成員募集中！ご賛同いただける方、サブ組織でも良いので、是非、名乗っていただきたいです。

正式名称はD_structionsです。

○nikiBustersにしなかっただけ自重したとご理解ください

AtCorderに挑んでみた

この記事は書きかけの記事です。一通り終えたら、清書し直す予定です。

プロコンをやってみたきっかけ

• 特に無い。
• 思いつき。
• 自分がどれだけ書けるのは興味がある。

目的

やってみた後に考えてみた。

• C++にもっと慣れたい。（プログラマー歴に対し、C++歴がとても浅い）
• 数をこなしたい。

目標

• 水色（上位１０％）！

現状の実力（主観）

• プログラミング歴：９年（大学１年から）
• 言語
  • Java・・・３年：品質を意識して商用レベルが書ける
  • JavaScript・・・３年：品質を意識して商用レベルが書ける
  • Matlab・・・　２年：書けはするが、あまり好きじゃない。
  • C++・・・１年半：最初はCの延長で適当に書いてたため適当。
  • C・・・９年：ロボコン用の汚いコードを量産。（コンパイラの成約でC99止まり）

元Web屋さんという背景から、ミドルウェアやAPI、OSSなどを扱う機会が多く、実は、各言語に向き合ってちゃんと勉強したことは少ない。製品化する過程でコーディングもするし、品質も意識したり、周りの人のコードのレビューも行っていたことから、コーディング自体に不安はあまり無い。

自分にとってプロコンの意味あるのか？

仕事でやるようなWebや組み込みシステムを作りコード（品質を考えたコード）とプロコンのコードは異なることは理解している。「プロコンが強い人材≠仕事で書くソフトの品質も高い人材」も理解している。（相関はあるとは思う）

広義のソフトウェアエンジニアとしての力量はコーディング能力だけでは測れない。アーキテクチャやデザインパターン、運用など、ソフトウェアにおけるサプライチェーンまで含むすべてが対象になると考えている。

ただ、仕事で書くコードに「工夫の幅」を広げるために、プロコンで使われるようなスキルが役に立つのでは？という期待はある。

（初期戦略）進め方

AtCoder（主にAtCoder Beginner Contest（以降：ABC））の問題はA~Fまであり、後半になるにつれ難易度が上がる。初レート戦に挑む前に、試しに５回分ほど過去問を解き、以下に分類。

(1) 解ける（毎回安定する）
(2) 解ける（たまにミスる）
(3) 解けない（回答を見たら理解できる）
(4) 解けない（問題文が理解できない。回答を見ても理解できない）

当初。Aはほぼ安定（１）。Bはたまにミスる（２）。Cは回答できることもあるがほぼ（３）。D以降は解けない（４）という状況でした。

当面の進め方は、「過去問を解き(2)(3)の正答率を上げつつ、(4)については徐々(3)に近づけるよう勉強する。」とした。

(4)に該当しているのは、そもそもの手法を知らない、考え方がわからないため、手を付けられないものである。 これはレート戦でも最初は相手にせず、QIitaの解説記事を見ながら徐々に学習していくことを優先した。

環境準備

過去問を１，２回やる中で、競技プログラミングはタイムアタックの性質上、ローカルの実行環境を整える必要性があると判断。普段遣いのPC（Ubuntu 20.04）で作業しやすいようにワークスペースを作成。以下のコマンドなどを用意。

• テンプレートからcppファイルを出題数分（６個）生成するコマンド
• ビルドコマンドの省略化するためのコマンド
• IDE（clion）でビルドするために、CMakeLists.txtを整備
• 解いたコードを退避し保管するコマンド

特にワークスペース作成コマンドは問題に取り掛かる初動がとても早くなったことから有用である。（たぶん、誰でもやってることなのかな？）
ワークスペースはgithubで公開済み。
github.com

仕事でもココらへんは自主的にやってる（好きでやってる）

---

To Be Written....