MiceAdventCalendar 2019 12/17の記事です。

5年ぶりにマイクロマウスの新作を作り、競技に参加しました。 新しいチャレンジはできましたが、完走できなかったので辛かったという話。

あと、技術的な面で、昔からやっているターンの自動生成を簡単に紹介します。

5年ぶりにマウスを作ったら辛かった話

2014年にさくらねずみ1/2を作って以来、大会への参加も新作も作っていませんでしたが、1年前くらいから再開しました。 完走はできませんでしたが、大会には出場し、一応マウスの形にはなりました。

コンセプトは、迷路の中心を走る時代を終わらせたいです。

さくらねずみ玄1の画像

第一の辛かったポイント

色々辛いポイントはありましたが、一番は皆速くなりすぎという問題でした。

具体的には、吸引の普及によって加速度とターンの最大横Gが、私が全日本大会のクラシックで(万年)2位を取れていた時の2~2.5倍くらいになっていました。 5年で2倍はどう考えても発展速度がおかしいと思います。

足回りの設計段階でモータとギヤ比を今までの常識に基づいてどう組み合わせても性能が出ないので本当に意味がわかりませんでした。

第二の辛かったポイント

エンコーダ基板立てはんだ付けがうまく行かず(パッドの幅が狭すぎた)、エンコーダがまともに読めない状態が続いていたタイミングで、2019/2にApexLegendsというゲームが出たので、無事に現実逃避しました。事前情報無くこんな神ゲー出すのはやめてほしい。現時点で350時間以上プレイしています。そういう事です。

PUBGの1250時間とか、BF4の4000時間に比べれば全然ですが、社会人マウサーには致命的なダメージでした。 あと、マウスを犠牲にしたにも関わらずFPS力すら落ちているのも辛いです。目が追いつかないので、年かな・・・。

第三の辛かったポイント

ゲームの呪いを85%くらい解いて、6月くらいから基板を再設計しながら新作を完成させました。 アートワークに気合を入れたり、エンコーダ基板のパッドサイズ等の見直しによって、かなり満足の行く出来の基板ができました。

ホットプレートリフローを前提として設計しているため、車体後部の部品の密度が手はんだ不可能な位(多分できないことはない)高い部分もあり、お気に入りです。

正直、4-5年もまともにはんだ付けしていない人間がこんなもの作れるのか？という辛かったポイント候補でしたが、照明付きルーペを導入したら余裕でした。次は実体顕微鏡を導入してもっと高密度にしたい。

第二のポイントであったエンコーダも一発で動作し、プログラミングに入った訳ですが、ここで何故か言語にRustを選択した上、RTOSを書き始めました。 ちなみに、Rustを選択した理由は、完全にC++へのヘイトです。

RustではCortex-M系のベアメタルプログラムを書くための環境が素晴らしく整っています。 しかし、マイクロマウスに丁度良い(C/C++で言うFreeRTOSのような)RTOSが無く、仕方なく自前で作る事にしました。何故ここでこんなに勢いがあったのかは謎です。 Rustという(割と癖の強い)言語で、ほぼ最初に書いたプログラムがRTOSというのが非常にまずく、1カ月くらいで形はできましたが、動作が不安定な状態が続き、ひたすらに時間を吸い取られました。

そのまま時間が足りず、2019年度のマイクロマウスは1大会も完走できずに終了となりました。辛い。来年は上位陣を脅かせる速度＆ライン取りして走れるように仕上げるつもりです。

という事で、今年の敗因は自分の実力を見誤ってRTOSを書き始めた事・・・ではなく、ゲームにはまった事です。RTOSでは1~1.5カ月ロスしましたが、ゲームでは4カ月くらい飛ばしていますね。 社会人マウサーはゲームをする事すら許されないみたいです。辛い。

ちなみに、自作RTOSはLチカできただけでめっちゃ嬉しさを感じられたのでオススメです。
みんなもHardFaultと仲良くなろう(デバッグが辛い)。

辛くならないためには

大会に参加し続けるのが重要だと思います。
新技術のキャッチアップを続けないと、やってる事がニッチ&参加者のレベルがおかしいので一瞬で置いて行かれるというのを実感しました。

ということで、毎年大会に出ましょう！それって辛いのでは？

ターンの自動生成

今年は何も新しい事はできていないので、過去の資産を食いつぶします。

さくらねずみ5、1/2、(玄1)ではマウス内でターンの自動生成を行っています。
ターンシミュレータまではよく見かけますが、自動生成は見かけない気がするので紹介します。

さくらねずみ５現役時はずっと自動生成だったので、今でも入賞できるくらいの速度では走れるのではないかと思います。

時間がなかったので内容薄いです。すみません。

動機

ターンの調整好きな人、居ますか？

方法

問題の設定

まず、ターンの終了位置を解析的に解く事は非常に難しいらしく、これは諦めます。数学に強そうな人が皆無理と言っていたので、無理なんだと思います。 各種パラメータを繰り返し調整して自動的にターンを生成します。

ここで定義するターンの生成とは・・・太字にしたパラメータを決める事です。

  • ターン終了時に目標の直線に載るようにする
    • 角速度の与え方を調整する
    • 速度の与え方を調整する
    • ターン開始までの直線の長さを調整する
  • ターン終了後、キリの良い位置まで進む
    • ターン終了後の直線長さを調整する

速度まで可変なのか？と思った方が多いと思います。速度を可変にしてしまうと、何をもって走行パラメータとするのかが謎になると思います。

今回紹介する方法ではグリップ≒最大横G=最大横加速度で規定します。 また、角速度の”形”も固定してしまいます。 こうする事で、ターンの形を速度によって確定させる事ができます。

この条件下で、速度、前後の直線の長さを自動調整するというのが自動生成の方法です。

また、同Gの設定で速度を上げるとターン軌跡が膨らむという前提の下にある手法なので、
シミュレーションのモデルや角速度の形によって、この前提が崩れた場合、収束しなくなると思われます。

基本的には

生成の方法

最適化数学を駆使してカッコよくやりたい所ですが、泥臭い場合分けと簡単な二分探査です。

ターン生成のながれ

シミュレーションを行い、起こった事象を元に速度とターン開始位置を調整していくという流れです。

新しい用語を色々出してしまったので、135度ターンを例にして説明します。

下の画像で、それぞれ、こんな感じです。

  • 緑線
    • 目標線分
  • 橙点
    • 目標位置
  • 黄線
    • 開始位置(による線分)
  • 青線
    • ターン軌跡

ミソは「速度調整量を更新」の所で、二分探査にする事です。 具体的には、前回の速度調整と今回実行したい速度調整の符号が逆であれば、調整量を1/2にします。

「速度を上げるとターンが膨らむ」事を前提としているため、このように速度を探索する事ができます。

ターンが合わないときはシミュレーションを調整して、実際の動きと合うようにします。

発展

上の紹介内では、角速度の形と、シミュレーションの具体的な実装を規定していません。
「速度を上げるとターンが膨らむ」ようになってさえいれば、角速度の形とシミュレーションは好きに選ぶ事ができます。

吸引が台頭している今、昔と同じシミュレーションではまともに生成できないと思いますが、
吸引に対応したシミュレーションを開発すれば、多分現役で使えるはずです。

アドベントカレンダー的に時間がやばいので、ここで一旦投稿しますが、そのうち実際の動作を交えてまた記事を書きます。