ロボットンのDCマウス製作記

マイクロマウス(クラシック)についての備忘録です。

東日本大会の振り返りとクラシックの機体の紹介

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

こんばんは　Mice所属のこみです。

前日の記事はエアプ回路レビュワーさんの「LTSpiceによるDCDCコンバータの発振判定(じっさいに作ってみた)」でした。

 

今回は12月21日に行われた東日本大会の振り返りと今年開発した機体について書いていこうと思います。

書きたいことをまとめきれず結構長くなってしまいました、すみません

 

 

東日本大会の振り返り

クラシックマウス競技　結果　2位

今回走行したマウス (機体名Meteoboy+)



この機体については機体紹介で詳しく述べますが、今年の東北大会ごろに設計を始め、学生大会に出場させた機体です。前回の学生大会では一週間前に機体が完成したこともあり調整が間に合わず、完走はできましたが、最短走行はすべて失敗しました。非常に悔しかったので、今回はそのリベンジをするべくクラシックに全力を注ぎました。

 

前回の大会からやったこと

前回の大会では斜め直進突入時にわずかでも姿勢がぶれていると、壁切れを見逃して壁に突っ込んでいくという挙動のせいで最短失敗しました。自分の機体では壁切れ補正の際、壁の切れ目or柱を見るまで進み続けるという処理になっている為、壁切れを読めなかった場合、ターンせずに壁に突っ込んでいきます。

 

また、ターンの調整は壁切れを読ませてから前距離→ターン→後距離

といった感じで行っており、完全に壁切れに依存しているにも関わらず、壁切れの判定方法はかなりテキトーで以前の機体でも柱を誤認識したり、見逃したりと問題がありました。頻度が低かったのでまあいっかと放置してましたが、新機体ではセンサー角度を変えたこともあり、その問題が牙をむいた感じでした。

 

そんな問題があったため、壁切れの判定方法を見直すことにしました。

 

もともとの壁切れ処理では

①走行中壁センサー値が一定以上の閾値を上回ったら壁(柱)ありとしてフラグを立てる

②フラグが立っている状態でセンサー値が閾値を下回った場合、壁切れ判定とし、現在の走行距離を補正する

といった感じで行っていました。斜めの場合も同様です。

 

壁センサー生値で壁切れの判定を行う方法なのですが、これが一般的なのかと勝手に思っていました。他のマウス競技者の方はどのように壁切れを判定しているのでしょうか？

 

前回の大会では柱を読み飛ばすことが多く(①の処理)、大会会場で閾値をいくら調整しても改善しませんでした。斜め直進中のセンサ値ログを取ってみると、マウスが道の中心を走って柱の横を通り過ぎた時は、閾値以上のピークが見られましたが、わざと角度や位置をずらして機体を置いた状態から直進を走らせてみるとピークが大きく下がっていることが分かりました。これに合わせて閾値を下げると今度は柱の誤認識が多くなりました。どうやら吸引ファン振動のノイズも入っているようでした。(本当はログを見せて説明したかったのですが、残っていませんでした...)

 

最初はセンサー値の変化量(一つ前のセンサ値ー現在のセンサ値)を割込み毎に監視し、その値が一定の閾値以上のときに壁切れ判定にしようとしましたが、ログを取るとノイズが乗りまくっており、閾値の調整が厳しそうな感じでした。(これもログが残っていなかった)

 

どうしようかと思って「マイクロマウス　壁切れ　方法」といった感じでググり、こちらのブログを見つけました。

regarasu.blogspot.com

 

 

こちらの方の記事を参考にして前後2点の変化量を使う方法をやめ、現在のセンサー値と過去3点のセンサー量から求めた平滑化微分値を壁切れの判定に用いることにしました。

 

壁の切れ目や柱を読んだときにいい感じにピークが立つように、ログをExcelに貼り付け係数をいじったりしました。

 

その結果　

変化量=現在のセンサー値-3つ前のセンサー値+1つ前のセンサー値-2つ前のセンサー値

で判定することにしました。

 

実際に直進を走らせて壁切れさせたときのログは以下のようになりました。

 

これは壁があるときパターンのログです。

迷路を3区画走らせ、2区画目のみ右の壁が開いている場合です。

壁の切れ目(0.05秒付近)でピークが立っていることが分かります。



 

こっちは柱のみのパターンです。

迷路を3区画走らせ、1区画目と2区画目で右の壁が開いている場合です。

このパターンでは上のパターンと比較して、何もない状態から柱ありになったときのピークも入っていますが、壁の切れ目のピークの位置は殆ど上と変わっていないことが分かります。



 

どちらのパターンでも常に壁がある場合と無い場合での値の変動が少なく、柱の読み飛ばしを防ぐために閾値を低めに設定した場合でも誤認識しづらそうな感じでした。

 

さらに姿勢をずらしたりといくつかのパターンでも走らせてログを取り、誤認識が少なそうな閾値を探しました。

 

この壁切れ方法に変えてから直進や斜め直進中に壁切れや柱を見逃してぶつかることは無くなりました。

 

壁切れの判定方法を変えると、壁切れ判定のタイミングが早くなり、全ターンの再調整を余儀なくされました。特に斜めの壁切れが早くなったので、斜めの出のターンの速度と再現性が上がったかも

 

大会一日前の試走会で走らせると、安定パラメータは一度もコケることなく安定していました。いつもは試走会でまともに最短が走らず、顔色を悪くしていましたが、今回はいけるのでは？と思っていました。


 

大会振り返り

続いて大会の振り返りをしていきます。

 

 

今回はこんな感じの迷路で、自分の機体は南を回っていくルートを選びました。今回の迷路は探索で必要な場所が見れていれば大体みんな南のルートを選んでいて、搭載している最短経路導出アルゴリズムによってあまり差がつかない感じでした。

 

1走目　完走　記録37.461s

ゴールまでは普通に足立法、帰りはダイクストラ法で求めた最短経路上の未知区間を探しに行く探索　探索速度0.5m/s

2走目　成功　記録4.906s

まずは安定パラメータ(ターン速1.7m/s 加速度17m/ss 直進速度4m/s)を走らせました。とりあえず最短が走って一安心

3走目　成功　記録4.375s

次にターン速を上げたパラメータ(直進から斜めに入るターンが1.9m/s、それ以外のターン速2.1m/s 加速度17m/ss 直進速度4m/s)を走らせました。

機体の限界に近いターン速で再現性低めだったので走ってびっくり

4走目　R

緊張と前日にサーキット用パラメータを入れたこともあり、どれが何のパラメータかわからなくなり、パラメータ選択をミスる。結局Maxパラメータ(直進加速度25m/ss　直進速度5m/s)で走らせ、柱にぶつかりファンが爆散。全日本にも出したいので壊れてないといいなあ。

5走目

大破したので記録なし

 

こうしてみると、4走目でMaxパラでなく、加速度20m/ssのを走らせてれば、タイムを0.2～0.3くらい短縮できてもう少しいい勝負ができた気がします。自分はいつも最後の詰めが甘いんですよね。次回はパラメータ選択などの戦略をしっかり考えて人間のミスを減らしたいです。あとは単純に直進加速の安定性が低いのも問題ですね。4走目でぶつかったのは加速度を上げすぎて、高速域でモーターのトルクが足りていない気がします。多段加速を実装しないと加速度25はきつそうです。また、動画を見返すと壁の無いほうに吸い寄せられている感じもするので、壁制御もおかしい気がします。これは全日本までの課題にします。

 

 

ハーフマウス競技　6位＆特別賞

今回走行したマウス(機体名　TITAN)

この機体は去年の全日本前一週間前に完成し、32x32迷路を完走できず5Rした機体です。シーズンの前半はこの機体に力を入れていましたが、後半はクラシックの方に時間を取られてあまり進化できていません。

前回の大会からやったこと

前回の学生大会ではクラシックに時間を取られてまともに調整しませんでした...

結局今回も大会一日前に少し走らせる程度しかやれていません。しかもそこでリポと電源を延長するケーブルが切れ、リポをコネクタに直挿しせざるを得なくなり重心バランスが悪化しました。さらに電流がたくさん流れるようになり、ぶつかるとリポの保護回路で電源が落ちるようになってしまいました。ハーフの方はFLASHへの迷路保存をやっていなかったのでやろうとしたのですが、謎のバグを解消できずに諦めました。

 

結局前回から大した進歩もなかったので、当日簡単な迷路が出ることを祈っていました。

 

大会の振り返り

ハーフの今回の迷路はこんな感じでした。

 

 

祈りが天に通じたのか片道の探索だけなら簡単で、出てくる最短もそこまで難しい要素はないように思いました。自分は最短を走らせることしか考えてなかったので、片道だけ探索させ、簡単な経路を走らせることにしました。一方で往復で出る最短はかなり難しそうで上級者には厳しいのかなとか思いました。

 

1走目　完走　記録32.944

足立法で片道のみの探索　探索速度0.3m/s

2走目　成功　記録6.103

まずは安定パラメータ(ターン速1.0m/s　直進加速なし)でトライ

普通に走ったように見えたが、ゴール内で壁にぶつかりフェイルセーフ発動

3走目　成功　記録32.974

速度を上げて最短を走らせようとするも何故か、ファンを回すと機体が動かなくなる。機体を持ち上げなければもう一度走らせてよいといわれたため、もう一度片道探索

4走目　R

やや攻めたパラメータ(ターン速1.3m/s　加速度15m/ss　直進速度3m/s)で走らせるも、下の方で壁にぶつかり暴走...

5走目

4走目のクラッシュで迷路データが消えたため、辞退

 

この機体は大会に出すたびに退化している気がします。8月の台湾大会がピークで以降の大会では探索の安定性や最短のスピードが下がっていきました。

 

磁器式エンコーダの組付けが悪く、探索が不安定なので作り直そうかと思ってます。ただ最近リポと電源コネクタをつなぐ延長ケーブルの接触が悪く、また線が細い為あまり電流を流せていないことが発覚したので最短はもう少し速度を上げられそうです。また、ハーフの方も壁切れに問題を抱えたまま走らせているので、クラシックの壁切れを試してみようかと思っています。

 

今回は6.1秒で6位だったのですが、自分より上の順位の方は全員2.6秒以内の記録を出されており、自分の機体の倍の速度で走っているのかなと感じました。自分ももう少し頑張りたいですね...

 

 

今年作ったクラシック機体の紹介

ここからは今年作った機体の紹介をしていきたいと思います。

 

機体名　Meteoboy+

機体情報

サイズ 長さ 105mm 幅 72mm 高さ30mm

重量　116g

ギア　ギア比3.5　スパーギアm0.3 70T ピニオンm0.3 20T

 

 

テクニカルデータ

https://www.ntf.or.jp/entry/2025/RobotEnt02.php?n&disp=2&id=354321

コンセプト
  1. 前作Meteoboy

    クラシック機体紹介 - ロボットンのDCマウス製作記

    の改良版　具体的には壁切れを早くかつ正確に読めるセンサ配置　6V版1717から3V版への変更　できるだけ振動を低減する吸引ファンマウント
  2. 1717モータを使って設計時間の短縮
  3. 1717に電流を流しまくる設計

まず1に関しては2年前に初めてDCマウスを作りました。ただいろいろと設計が雑で様々な問題に苦しめられました。例を挙げると、吸引ファンを回すと物理的・電気的なノイズが両方発生するなどがありました。これに関しては吸引ファンを強く回すと振動で機体が前進していく、また壁センサーにノイズが乗りまともに壁制御が利かなくなる問題がありました。これらの問題のせいでファンを回した状態での最短走行はまともに安定しませんでした。

そのため今作では吸引ファンの固定を3点から4点にし、回路設計では先に部品の配置を決め、信号線をできるだけクロスしないようにするなど配線をきれいにすることを心掛けました。

次に2に関してなのですが、最初8520モーターなど軽くてトルクのあるモーターを使って速い機体を作ろうと思ったのですが、そういったモーターには当然エンコーダーがついていないため、ギアをかませて磁気式エンコーダーなどを付ける必要があります。磁器エンコーダーは設計がテキトーだと速度にノイズが入って走行が不安定になるため、しっかりとした設計が必要になります。その点1717モーターには高精度なエンコーダーが最初から付いており、エンコーダー周りの設計がいりません。設計と機体の開発が長引いて大会に間に合わなくなりそうだったため1717モーターを使うことにしました。

最後に3に関しては機体の開発をスムーズに行うためにモーター、モータードライバ、リポなど走行性能に大きな影響を与える部品を前作から流用しようと思っていました。しかし、それではつまらないと思ったので、変えてみることにしました。モーターを6V版1717から3V版1717にし、モタドラは常時5A流せるMP6551を採用しました。それに伴いリポバッテリーも3セルから2セル250mah 45/90Cのものに変更しました。3V版モーターは6V版に比べて端子間抵抗が低くトルク定数が低いので、電流容量の高いリポと定格電流の大きいモタドラを使ってそのぶん電流をたくさん流せば高い加速度を出せて速くなるのでは？と思っていました。

 

回路図




さいごに

ハーフの機体の方も紹介しようと思ったのですが、力が尽きたのでまた今度にします。

明日の記事はトコロさんの「自作ハーフ1セル用充電器の紹介」です。

 

学生大会振り返りとstm32の内蔵flashに迷路保存してみた話

この記事は

マイクロマウス(2) Advent Calendar 2024 - Adventarの22日目の記事となっています。

 

はじめましてこみです。

今回は12/1に行われたマイクロマウス学生大会について振り返っていこうと思います。

学生大会の振り返り

クラシック　結果　最短失敗

今回走行したマウス(機体名Meteoboy)

 

クラシックは最近全く触っておらず、にも関わらず前回の中部地区大会で2位になってしまったので、ちょっとまずいなと思ったので今回は力を入れました。


具体的には、これまでは制御においてターン中や直進中は相対的な角度でしか扱ってなかったのですが、絶対的な角度で扱うように変更しました。今のクラシック機は吸引するとセンサにノイズがのって、斜めの壁制御が効かなくなる問題があるので、斜め直進中に理想角度に追従させるようにして、角度だけでも直すことで、斜めの安定性が多少上がりました。


また、絶対角度をつかって、前回のターンの理想角度と現在の角度の差を求め、次のターンの角度を調整するという制御も入れてみましたが、これは壁にぶつかったりして大幅に姿勢がブレても稀に立て直すということがあったので、導入した意味はあったと思います。


さて大会の結果ですが、探索のみで最短失敗という結果になりました。長い斜めに入る前の連続ターンで姿勢がぶれ、角度制御で姿勢を直す前に、柱に接触してフェイルセーフがかかってしまったようです。フェイルセーフ緩めるか、切るかしてればワンチャン走ってたので、出走が終わってからすごく後悔しました。また、この機体はいっぱい吸引すると振動で制御が暴走するという問題もあるので、あまり吸引力を上げられません。その結果高速ターンで滑って再現性が悪くなるといった問題もあります。このように問題を抱えすぎていてこの機体で調整するのが辛くなってきたので新機体作りたいです。ただ、そんな余裕はなさそうなので今シーズンはこの機体で出場すると思いますが...

 

ハーフ　結果　5位

今回走行したマウス(機体名Canonboy）

クラシックに力を入れたのでハーフは今回は攻めたことをせず、完走してポイントを取りにいくことを重視しました。

 

ハーフ機はデンソーカップのときから探索や最短時に再現性なく暴走するという問題に悩まされていました。当初は配列への領域外参照などソフトウェアのバグを疑っていたのですが、制御関係なく左右のモーターをduty100%で回したり、走行中にタイヤを手で押さえたりすると、マイコンが落ちることからハードウェアの問題だとわかりました。機体の回路をサークルの人に見てもらって、電源のコンデンサ容量が低いのではないかという、アドバイスをもらい、電源のコンデンサを違法増築しましたが、あまり改善しなかったです...

 

結局モーターのdutyを50%に制限する事である程度暴走を抑えるようにはなりました。
ただ、電圧を制限してもタイヤがロックしたりして電流がいっぱい流れるとマイコンが落ちてしまうので、そうなる前にフェイルセーフをかけるようにしています。


そしてハーフの大会結果は5位でした。今回は探索で出た経路が簡単だったこともあり、初めて5走全て走り切ることができました。今回の複数ポイントで全日本は32x32になりそうなので、この機体では安定した探索と、非吸引斜めで完走を目標に頑張りたいと思います。

 

大会の振り返りはここまでにして、ここからはサークルの人にstm32の内蔵flashへの迷路保存についてブログを書くように頼まれたので，ここからはflashに迷路保存をする方法について書いていこうと思います。

 

マイコンはSTM32G491REU6を使用し、開発環境はSTM32CubeIDEを使用しています。

 

まずstm32g4シリーズのリファレンスマニュアルを参照して、flashのどこのアドレスを使用するかを決めました。どうやらflashメモリは番号の若い順に使われていくみたいなので、下の図のバンク1のページ126、127(0x0803F000～0x0803FFFF)の4KBの領域を使うことにしました。

https://www.st.com/resource/ja/reference_manual/rm0440-stm32g4-series-advanced-armbased-32bit-mcus-stmicroelectronics.pdf

 

 

次にSTM32G491CEUX_FLASH.ldのMEMORYコマンドの定義に使用するメモリの領域を追加しました。

 

 

  1. /* Memories definition */
  2. MEMORY
  3. {
  4.   RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 112K
  5.   FLASH (rx) : ORIGIN = 0x8000000, LENGTH = 508K
  6.   MYDATA (rx) : ORIGIN = 0x803F000, LENGTH = 4k
  7. }

 

ビルドした後にcubeideのWindow->Show ViewからBuildAnalyzerを開くとメモリの配置が変更されたことが分かります。

 

 

以下はHALライブラリでのflashに情報を書き込むコードです。マイコンのデータシートを読むと、FLASHへの書き込みは制限されており、書き込みを行う際にはロックを解除する操作が必要なようです。HALライブラリのHAL_FLASH_Unlock()、HAL_FLASH_Lock()を呼べばロック解除とロックの操作をやってくれるみたいです。

flashの仕様とHALの関数の仕様はこちらのブログの方が詳しく書かれているため、ここでは省略します。

zeptoelecdesign.com

 

迷路情報は構造体にまとめてflashに保存するようにしました。今回は8byte単位でflashに書き込むことにしたため、構造体の変数のサイズも8byteのuint64_tにしました。

 

 

 

 

  1. #include "stm32g4xx_hal.h"
  2. #define START_ADR 0x0803F800
  3. #define MAZE_SIZE 16
  4.  
  5. typedef struct FLASHMAZEDATA//迷路情報を格納する構造体
  6. {
  7.     uint64_t Maze_Row[MAZE_SIZE-1];//1横壁
  8.     uint64_t Maze_Column[MAZE_SIZE-1];//2縦壁
  9.     uint64_t Maze_M_Row[MAZE_SIZE-1];//3最短の横壁
  10.     uint64_t Maze_M_Column[MAZE_SIZE-1];//4最短の縦壁
  11.     uint64_t Maze_KnowMap[MAZE_SIZE];//5既知の区画かどうか(0:未知、1:既知)
  12. }FLASH_MAZE_DATA;
  13.  
  14.  
  15. uint32_t EraseFlashMaze();//Bank1、127page目をすべて1にする
  16. void WriteFlashMaze(FLASH_MAZE_DATA* data);//8byte単位でデータをflashに書き込む
  17. void ReadFlashMaze(FLASH_MAZE_DATA* retdata);//迷路情報を読み出す
  18. void InitFlashMaze();//FLASHの迷路情報を初期状態にする

 

 

 

 

 

  1. #include "PL_flash.h"
  2.  
  3. uint32_t EraseFlashMaze()//Bank1、127page目をすべて1にする
  4. {
  5.     HAL_FLASH_Unlock();
  6.     FLASH_EraseInitTypeDef erase;
  7.     erase.TypeErase=FLASH_TYPEERASE_PAGES;
  8.     erase.Banks=FLASH_BANK_1;
  9.     erase.Page=127;
  10.     erase.NbPages=1;
  11.  
  12.     uint32_t error=0;
  13.     HAL_FLASHEx_Erase(&erase, &error);
  14.  
  15.     HAL_FLASH_Lock();
  16.     return error;
  17. }
  18.  
  19. void WriteFlashMaze(FLASH_MAZE_DATA* data)//8byte単位でデータをflashに書き込む
  20. {
  21.     EraseFlashMaze();
  22.     HAL_FLASH_Unlock();
  23.  
  24.     uint32_t adr=(uint32_t)START_ADR;
  25.     uint64_t size=sizeof(FLASH_MAZE_DATA)/sizeof(uint64_t);//8byte単位のdata数を求める
  26.     uint64_t* ptr=(uint64_t*)data;//8byteづつ書き込みを行うため、uint64_t*にキャストする
  27.  
  28.     for(uint64_t i=0;i<size;i++){
  29.         HAL_FLASH_Program(FLASH_TYPEPROGRAM_DOUBLEWORD, adr, *ptr);//8byte分flashに書き込み
  30.         ptr++;//ポインタの指すアドレスを8byte進める
  31.         adr+=sizeof(uint64_t);//addressを8byte分進める
  32.     }
  33.     HAL_FLASH_Lock();
  34. }
  35.  
  36. void ReadFlashMaze(FLASH_MAZE_DATA* retdata)//迷路情報を読み出す
  37. {
  38.     *retdata=*(FLASH_MAZE_DATA*)START_ADR;//0x0803F800からFLASH_MAZE_DATA構造体のサイズ分を読み取る
  39. }
  40.  
  41. void InitFlashMaze()//FLASHの迷路情報を初期状態にする
  42. {
  43.     EraseFlashMaze();
  44.     HAL_FLASH_Unlock();
  45.  
  46.     uint32_t adr=(uint32_t)START_ADR;
  47.     uint64_t size=sizeof(FLASH_MAZE_DATA)/sizeof(uint64_t);
  48.  
  49.     for(uint64_t i=0;i<size;i++){
  50.         if(i==15)//(0,0)の東壁を立てる
  51.         {
  52.             HAL_FLASH_Program(FLASH_TYPEPROGRAM_DOUBLEWORD, adr, 1);//8byte分flashに書き込み
  53.         }
  54.         else
  55.         {
  56.             HAL_FLASH_Program(FLASH_TYPEPROGRAM_DOUBLEWORD, adr, 0);//8byte分flashに書き込み
  57.         }
  58.         adr+=sizeof(uint64_t);//addressを8byte分進める
  59.     }
  60.     HAL_FLASH_Lock();
  61. }

flash実装したら何度も探索を走らせる必要がなくなったので、最短走行のデバックにはとても効果的でした。実装して良かったと思います。

今年の振り返りと迷路シミュレータ紹介

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

 

昨日はhmsnさんの学生大会の報告と今季の取り組みの紹介でした。モーターの音を測定して，逆起電力定数を測定する手法の紹介でした。自分は1717モーターなど，すでに逆起電力定数がデータシートに乗っているようなモーターしか使ったことがないですが，今後データシートがないモータを使う場合に試してみようと思います。

 

自己紹介

アドベントカレンダーでブログを書くのは初めてなので自己紹介をしたいと思います。

 

名前　こみ(@krmtnkm)

所属　東京理科大 Mice

学年　B4

参加競技　クラシックマウス

クラシックマウス競技は去年始めて今年で2年目となります。

学生大会の感想

マイクロマウス全日本学生大会に参加させていただきました。運営の工芸大からくり工房の皆さんありがとうございました。

自分の結果はクラシック部門で5位(37台参加)でした。タイムは5.040でした。当初の目標であった吸引走行での最短の成功は達成することはできましたが，長い斜めを走れず大きくロスしたり，せっかく作った1.7m/sパラメータがうまく動いてくれなかったりと悔しい結果となりました。安定性，速度ともにまだまだ学生上位陣には遠そうです。

Miceのほかの方々は，吸引や斜めに手を出していました。後輩も出場してましたが，完走にはなりませんでした。直前は自分のことで手一杯になってしまい，まともに見れず申し訳ありませんでした。また，Miceのトコロ君はいつも通り安定した走りでまだまだ勝てそうにありません。

今年作成した迷路シミュレータについて

去年は探索，最短共に足立法のみだったので，今年はアルゴリズムに本格着手するため迷路シミュレータを作成しました。シミュレータの製作にはDXライブラリを使用しました。

 

 

探索走行と最短走行が可能となっています。表示されている壁はボタンになっており，クリックすると壁を立て，もう一度クリックすると壁を消すことができます。

迷路に表示されている数字は歩数マップの数字です。

1ステップごとにマウスを動かすような機能はありませんが，代わりに一時停止でマウスの座標と向いている方角を調べることができます。この機能は探索アルゴリズムのデバックの役に立ちました。

マウスや壁の画像はedgeでテキトーに作成しました。

 

最短走行の様子です。最短走行ではダイクストラ法を使用しています。

最短時に表示されている数字はノードのコストです。

最短走行では斜め走行ができるようになっています。動きはちょっとかくかくしてますが，ベジェ曲線を使ってターンのアニメーションを作ってみました。

 

迷路シミュレータを作ってよかった点は新しいアルゴリズムの実装が楽になったことです。部室の迷路は16×7なので，探索はもちろん，最短走行も一本道になってしまいアルゴリズムのデバッグが困難でした。迷路シミュレータを作ってからは，シミュレータ上でいくつか迷路を試してバグがないかを確認してからコードをコピペで実機でも動きました。

 

シミュレータの今後の機能追加としては，パラメータによってターンの重みを変えて，違う経路になる経路導出をやりたいと思っています。もっと賢いマウスになりたいです。

 

最後に今年のマウス活動を簡単に振り返ろうと思います。

今年の振り返り

  (１～2月)

dcマウスの機械設計を始める。

足回りの雑さは後々後悔することとなる。

 

(２～3月)

回路の設計を行う。回路設計も雑で様々な問題を引き起こした。

 

(4月～6月)

機体が完成し，制御のコードを書き始める。また，このあたりから制御のプログラムと並行して，迷路探査シミュレータを作り始めた。

6月には非常に不安定ながら探索を実装することができた。探索のほかにダイクストラ法での経路導出を実装したが，実際に役に立ったのは半年後であった。

また，6月の下旬にはマイクロマウス合宿に参加した。プチ大会で走らせたが，壁制御がブルブルしたり，ターンの角度が毎回違うなどが原因で完走はできなかった。

 

(7月)

大廻のターンを実装して関西地区大会に参加した。大会三日前に機体を壊したりして，大変だったが，奇跡的に完走することができた。

最短は直進で距離がずれてコケてしまった。大会後は不安定だったスラロームの改善を試みた。かどすべーるを張ったりして角度追従がきれいになったように見えたが気のせいでターンの再現性は低いままだった。

 

(8月～9月上旬)

金沢草の根大会に向けて無謀にも斜め走行を実装しようとした。

スラロームすらできないのに斜めターンなどできるわけなく，実装はしたものの走るのは3×3の迷路ぐらいだった。

ターンの不安定さを補正で何とかしようと壁切れを頑張ったが，そもそも角度に再現性がなく，数回に一回±10°くらいずれるのでどうしようもなかった。

このころはサークルの部員が爆発的な進捗を生んでいたが，自分はスラロームで詰まっていた。

9月の上旬には金沢草の根大会に参加した。精神と時の部屋では不安定なスラロームを改善するべく，ひたすら角度のゲインをいじっていたが，結局一番最初のゲインに戻ってきて絶望した。

前壁補正と後距離の補正で何とか完走はできたが，最短走行はすべて失敗した。しかし重ねて探索させて記録を残すことはできた。

↑無謀な斜めターン(たぶんin135？)

 

(9月中旬～10月)

金沢から帰った後にマウスのタイヤを2つ外して走らせてみる。少し角速度の追従がよくなったのでソフトではなく足回りを疑う。

モータマウントの車高を変えて再発注，軸ねじの長さを短くし，ナイロンナット，ホイール，ギアすべて再発注した。

モータマウントを再発注したら精度の問題でナットをはめる穴が小さくなっており圧入しないといけなくなっており，少し焦った。

しかし，足回りを作り直したら，よりスルスルとタイヤが回るようになり，やっとターンの再現性問題が解決した。

原因はあまりよくわかっていないが，軸ねじが長すぎた，ナイロンナットのナイロンが劣化していて固定が不安定だったこと，軸ねじの頭とナットで止める部分の距離が短すぎたことなどが挙げられる。

角速度も多少の振動はあるものの追従するようになり，ターンの再現性が大幅に上がった。ターンがよくなり，やっと斜め走行がある程度走るようになった。10月の初旬には東北地区大会に参加し，斜めで完走することができた。(ターン速 all 0.8 m/s)

 

(10月～11月)

中部地区大会に向けて吸引の実装を頑張る。ファンを回したら偏心でマウスがものすごく振動してターンどころではなかった。

ファンをゆっくり回すようにしたら振動は収まったが，20~30gくらいしか吸えなかった。

また，ファンを回してたらなぜかファンのfetが焼けるようになった。fetを付けたり外したりしてたら吸引回路のパターンがはがれてファンを回せなくなった。

そのため中部地区大会と東日本地区大会は非吸引で参加した。ただ，このままでは進歩がないので，ターン速を0.8から1.0にした。

 

(12月)

マウスのスピーカを剥ぎ取り，そこにファンのコネクタをつなぎ，さらにファンをアクリルで発注しなおし，ファンの穴径を圧入前提にしたらようやく振動なく150gくらい吸えるようになった。学生大会に向け吸引ターンを調整しようとするが，吸引すると壁制御が利かなくなる問題が発覚した。

ログを見るとセンサーに吸引のノイズが乗りまくっていた。回路に問題があることが分かったが，再発注している時間はないので平均を取ってごまかした。普通の壁制御は平均でもなんとかなったが，斜めの壁制御はどうしようもなかった。

学生大会では長い斜めがあったため連続斜めの重みを増やして，斜めルートを回避した。最短は成功したものの，長い斜めを走れていればもっとタイムを短縮できたと思う。

ノイズが乗る原因はまだよくわかっていないが，ベタGNDができていないのが怪しいので，ベタを張りなおして再発注する予定

 

この一年を振り返えると，ひたすらハードで苦戦しているので，来年は今年の反省を踏まえてしっかりした設計を心掛けたいです。

 

明日はうえぽんさんのマウス0作目のソフト設計のようななにかです。今年はある程度全体のソフト設計を行ってから開発を始めましたが，まだまだ改善点があるので，参考にさせていただきます。

 

関西地区大会2023の反省

お久しぶりです。mice副部長のr.kです。

7月16日に行われた関西地区大会に参加させていただきました。非常にスムーズで楽しい大会でした。運営に関わった方々に感謝致します。

 

今回は関西地区大会での結果と反省点について述べようと思います。

 

まず、私の大会の成績は

DCマウスでの初めての地区大会で完走することができました。しかし、戻り探索と、最短走行はすべて失敗しました。1走目はゴールにはたどり着きましたが、ゴールから出るところでの連続スラロームで角度がずれて、串に突っ込んで止まってしまいました。2走目以降では最短走行を試みたのですが、まず最初の長い直線の距離がずれていたのか、直線後のターンでクラッシュしてしまいました。

 

このような結果になった反省点を並べてみると

①　部室では5×7の迷路しか走らせず、15マスの長い直線の調整をしなかったこと

②　大会3日前、前日、前々日は修理に追われ、ほとんどコードをいじらなかったこと

③　最短のパラメータを大回り有りと無しの２つしか用意しなかったこと

④　大会で2走目以降、探索ではなく、走らない最短を走らせ続けたこと

⑤　最短で壁切れを入れなかったこと

 

まず①に関しては、大会前はターンの調整ばかりしており、直線の調整はしませんでした。部室の迷路で直線2.5m/sでそこそこ走っていたので大丈夫だろうと思っていました。しかし部室の迷路では直線は長くても6マスくらいだったので、おそらく2m/sも出ていなかったと思います。この反省を踏まえて次の大会までには長い距離走らせて、どれだけずれがあるかを確認したいと思います。

 

②

大会3日前あたりからマウスの探索中やターンの調整中に急に、マウスが高速回転する現象に悩まされていました。なぜかその場でこの問題について考えずに走らせ続けていたら、さらに前センサーも読めなくなってしまいました。当初自分は前センサーが読めない原因と探索中などに回転する原因がマイコンの接触不良であるんじゃないかと思い、マイコン周りの半田付けをやり直したりしました。しかし、何も変わらず、なぜかwhoamiも0になっていました。あまりに分からなかったのでサークルの先輩に助けてもらいました。

 

前センサーが読めなくなっていた原因は半田がクラックしたのか、発光回路の抵抗が導通していたためでした。自分は最初前センサーが読めないのは、発光部でなく受光部が原因だと思っていました。センサのledが光っているかどうかを確認すればよかったのですが、高速で点滅させていたので、スマホの内カメラで見てみても、他のセンサーのledと違いがよく分からず光っていると勝手に思っていました。先輩からアドバイスされ、ledの割り込みでの点滅をやめ、常時点灯させるようにしたら１つだけledが光っていないことがはっきりと分かりました。

 

また、高速回転する原因としてはジャイロの接触不良だったようです。ジャイロのwhoamiをモニターしたら基本は正常値の0x98になっていましたが時々連続して0やffになっていることがありました。ジャイロを指で触ると正常になることがあったので、大会前々日にジャイロの足を温め直すと高速回転しなくなりました。しかしまた高速回転するのが怖かったのでwhoamiの値を監視して、異常だったらフェイルセーフをかけるようにしました。これは実装してよかったです。次の日にマウスを動かそうとしたらフェイルセーフがかかっていたからです。もう一度足を温めたら直りましたが、いつ再発するか分からなかったので大会会場には半田ごてを持って行きました。大会当日では時々マウスにリポをさしてフェイルセーフがかかっていないかを確認していました。

 

これらの反省としてはまず、少しでもマウスが異常な動きをしたら動かすのをやめ、原因を探るべきでした。これをしなかったせいで、どのタイミングで前センサーが壊れたのかが分からず、無駄に時間を消費してしまいました。

 

③

最短のパラメータを大回り無しと有りの２つしか用意しませんでした。理由としてはこれまで、最短走行のパラメーター選択がなく、前日に機能を実装してバグになるのが嫌だったからです。そもそもそんなに時間がかかる機能でもないのにこれまで、面倒くさがってパラメータを直接書き換えていました。まず、速度を上げたりするよりもパラメータ選択機能を作ることなどを優先させるべきでした。低速パラメータを作っておけば、もう少しよい結果になったんじゃないかと思っています。

 

④

大会では2走目以降も最短走行を走らせ続けましたが、すべて失敗してしまいました。そもそもパラメータは２つしか作っていなかったので、両方失敗した時点でこれ以上走らせても、成功する確率は低かったと思います。走る可能性の低い最短を走らせるくらいなら、既知区間加速もありますし、もう一度探索を走らせた方がいい結果になったと思います。しかし、大会中はまったく頭が回りませんでした。この反省を踏まえて、これから2走目は重ね探索をさせて、確実に記録を残そうと思います。

 

⑤

最短走行での補正は前壁補正のみで、壁切れを入れていませんでした。今回クラッシュした動画を見返してみると、直線の距離が足りず、ターンで引っかかっていた事が分かりました。ターンの前には壁がなかったため、前壁の制御ができず、距離の補正ができませんでした。これは壁切れを入れてさえいれば少なくとも、そこでコケることはなかったと思います。

 

次に今回の大会で良かったことを述べたいと思います。

 

①環境が変わっても安定していたこと

②壁制御はまあまあいい感じだった

③目標にしていた完走をすることができた。

 

①

去年のステッパーでは大会などで環境が変わるたびに壁センサーのリファレンス値を測り直していました。しかし今回のdcでは一切壁センサーの値をいじらずに、部室にいるときと同じように走ってくれました。

 

②

壁制御は前に比べるとかなり改善しました。マウス合宿のプチ大会で走らせたときは、壁の切れ目で吸い込まれたり、壁制御と角速度PID制御が干渉したりして、ブルブルと不安定な動きをしていました。部室で閾値をいじったり、壁制御をつける条件を厳しくしたり、AD値そのままで制御するのをやめたりといろいろやりました。その甲斐もあって他の方のdcマウスのような壁制御になったと思います。

 

③

今回の大会では機体が壊れて前日まで修理していたこともあり、棄権も考えていたので、完走したことはとてもうれしいです。しかし、人間欲がでるもので、マウスを前日あたりに修理していたときは

　　　　　　　　　　　完走しなくていいからせめて動いてほしい

　　　　　　　　　　　　　　　　　　　　↓

　　　　　　　　　　　　　　　　　完走してほしい

　　　　　　　　　　　　　　　　　　　　↓

　　　　　　　　　　　　　　　　　最短走ってほしい

　　　　　　　　　　　　　　　　　　　　↓

　　　　　　　　　　　　　　maxパラメータで走ってほしい

 

と大会会場でわりと走ってるのをみて、どんどん欲が出てきました。そのため、完走してうれしい気持ちもありますが、最短失敗して悔しい思いも大いにあります。

 

大会の反省としてはこんな感じでしょうか、とりあえず次の大会に向けて開発頑張っていきたいです。夏休みには斜め実装したいです。

 

 

クラシック機体紹介

人生で初めて製作したクラシックDCマウスの機体紹介記事です。

 

写真

 

 

機体情報

機体名　Meteorboy

size　width: 70mm　Length: 95mm

weight　117g

cpu　STM32F446

sensor　受光部 st-1kl3a　LED SFH4550

gyro　ICM-20689

encoder　IEH2-4095

motor　1717-6SR

motordriver　TB67H450FNG

 

オーソドックスな4輪DCマウスです。DCマウスを自分で設計するのは初めてだったので，他の人の使っている部品を大いに参考にしました。なので，ハード設計において，オリジナリティーなんてものはありません（笑）

 

設計コンセプトとか

①かっこいいので変則4輪にしたい

②ある程度実績のある部品を利用する

③去年のステッパの経験から前壁センサーは1個にした。

④c++でオブジェクト指向を意識したソフト設計をする

⑤リポ逆挿しをしない構造←重要

なお逆挿ししなくても回路を壊した模様

 

①について

先輩や大会にいた他のマウサーの方の機体を見て，かっこいいと思ったので，

 

②について

初心者がデータシートを読みこなすのは困難なので，他の方のブログを参考にできるように，有名な部品を選ぶことを心掛けました。

以下に回路図を示します

いちおう受光回路にハイパスフィルタを入れてみたのですが，今のところあまり効果を実感できていません。アートワークの方はここには載せませんが，水晶の下を信号線が通っていたり，ベタGNDができていなかったり，配線が無理やりだったりと色々と怪しいです。今回は無理にすべて手動配線したので，次作るときはもっと部品の配置を練って，自動配線を使ってみようと思います。

 

③について

去年のステッパは何故か，左前壁センサーの感度が低く，ほぼ右前壁センサーのみを使って前壁認識を行っていました。そのため別に前にセンサーが2つなくてもいいんじゃないかと思って，なんとなく前壁センサー1つにしました。ただ，センサー5個の配置の場合，斜めの壁制御がセンサー4つとかなり異なるものになるらしいです。

 

④について

僕は前々からオブジェクト指向を用いてプログラミングしたいと思っていたので，ステッパからDCに移行する際にCからC++に切り替えました。ただ，周りの人は誰もCubeIDEでC++を使っていなかったので，C++への移行は結構詰まるところがありました。CubeIDEでのC++のプロジェクト作成するブログは少なかったので，今後備忘録として書いておこうかとも思っています。

さて，去年の僕のステッパのコードは1ファイルに1500行以上書かれていたりとひどいものでした。コードの綺麗さとかは特に考えずにテキトーに書いてたので，似た処理の関数が複数あったり，externを濫用して勝手にフラグが書き換わっていたり，なぜか迷路探索部の処理の中に，ペリフェラルの関数が入っていたりしました。このようになった原因の一つとして，機能をどんどん追加していくたびに，違法増築を繰り返し，プログラムが雑になっていったという事があります。そこで今年はある程度ソフトの全体設計を行ってからコードを書いていくことにしました。去年ステッパをまあまあちゃんとやったので，マイクロマウスにおいてどのような機能が必要かなどを見渡すことができました。今回はクラス図を書いて，その通りに実装していったのですが，図の作成はplantUMLを使用しました。

とりあえず，制御部だけですが，以下の写真のようなクラス図を書いてみました。設計時は要素間のつながりはできるだけ少なく(特に制御部，センサー，迷路探索部の名前空間の間のつながりは最小限にした)，クラスに循環参照ができないように心がけました。実装の際にはsetter，getterを面倒くさがらずに書いて，関係ない所から参照できないようにする，インスタンスのメンバ変数の参照関係は極力クラス図の関係になるようするなどを気を付けました。

 



⑤について

去年の学生大会で大会前日にリポを逆挿しして悲しかったので，もう二度と逆挿ししまいと，電源のmosfetを2段にしました。そのため万が一逆挿ししても大丈夫だと思うのですが，怖いので試したことはありません。

 

↑スイッチを6角レンチで押そうとして手が滑り，回路を導通させ破壊した

 

おわりに

回路を破壊した後は，二日ほどかけてもう一度作り直し，現在は良好に動いています。これから迷路探索部のコードを書いていく予定です。

 

 

 

 

 

 

 

STM32のLチカで苦労した話

 

今回はDCマウスの基板が届いたので、電源とマイコン周りを半田付けしてLチカとUSART通信を試みたことを書こうと思います。

 

まずはプリント基板にレギュレータなどの電源系とマイコン周りを半田付けしました。マイコンの半田付けは足が異常に小さく、(自分には)普通につけるのが無理だったので、マイコンの足に半田を大量に盛り、足とパッドをくっつけてから余分な半田を吸い取り線で取り除いていく作戦でいきました。

 

 

次に秋月で買った64ピンのnucleoボードを下の写真のように部室のニッパーでカットしました。

 

このときボードを割るときに力を入れすぎて、指を切ってしまいました。これからnucleoを割る予定がある方は気をつけましょう。また、分離したボードのST-LINK部分のCN2ピンのジャンパ2つを取り除きました。これにより、CN4の外部デバックコネクタを使えるようになると、公式のデータシートに記述されています。

 

 

CN4のピンは以下の通りです。

自分は1ピン以外の5つのピンをターゲット基板と写真のように接続しました。基板の3.3Vと1ピンのVDDを接続できれば、マイコンをPCの3.3Vで起動できるようになるのでしょうか？よく分かりません？usart通信を行う際にはマイコン基板のTxとST-LINKのRxピンを接続することでマイコンからPC側に送信することができるみたいです。

 

データシートの記述通りにターゲット基板とST-LINKを以下の写真のように接続し、マイコンへの書き込みを試みたところ問題が発生しました。

 

 

とりあえずマイコンへの書き込みはできるのですが、Lチカができない問題が発生しました。CubeIDEのペリフェラル設定ミスかと思い、設定をいじりましたがLEDはうんともすんとも言ってくれませんでした。

 

絶望に打ちひしがれ、その日は帰ったのですが、次の日に部室に行ったら先輩がいたので、相談に乗ってもらったら水晶を逆につけていたことが発覚しました。これを直して一件落着かと思いきや、それでもLEDは光りませんでした。

 

LEDがだめならuartはどうかと思い、uartの設定を行いTeraTermに「hello」の文字列を表示させることを試みると、見事に文字化けして正しく通信ができませんでした。その後もいろいろ試してみましたが、どれもだめでした。

 

結局たまたまレギュレータを指で触っていたときのみLEDが点灯した事から問題の原因が判明しました。3.3Vを作り出すレギュレータとGNDの半田付けが甘く、接触不良になっており、正しくマイコンが動いていなかったようでした。

 

今回は運良く問題の原因が判明しましたが、今後もこういった問題が起こると思うと非常にうんざりします。今回の件で、ロボット製作の恐ろしさが垣間見えた気がしました。

 

 

 

ブログを始めてみました

初めまして

mice前部長のr.kです

ブログを始めてみました。

 

ブログを始めた理由

3月4日に現在制作中のDCマウスの基板を発注しました。これから部品の実装、動作チェックを進めていく予定なのですが、恐らく詰まることが多くなると予想されます。

 

特にマイコンへの書き込み、Lチカの成功が大きな課題だと感じています。

 

このとき問題をどう解決したのかを記録にして残すことで、またマウスを作るときに自分で見返したり、他にマウスを作っている人の役に立つと思ったのが大きな理由です。

 

ブログ自体は前々からなんとなくやってみたいなー、とは思っていたのですが、いつかやろうとなかなか踏ん切りがつきませんでした。あと、初心者過ぎて何を書けばいいのか分からなかったというのもあります笑。

 

他の理由としては自分の考えたことを他の人に伝える練習の意味もあります。

自分は人に考えたことを伝えるのが苦手なので...

 

また、miceでは白鑞先輩が初心者にもわかりやすいステッパーマウスやdcのマニュアルを書いてくださっていました。そのおかげで全くの初心者だった自分がひとまず大会で完走できるくらいにはなりました。

 

miceが潰れなかったのはサークルのメンバーが先輩に熱心に指導してもらったことが非常に大きいと思っています。ありがとうございます。

 

ただ、先輩は卒業されるので、今度は自分たちで技術継承をしていかないとmiceは再び存続が危うくなってしまいます。

 

技術継承を行う上で今の自分にできることはブログを書くことだと思いました。dcマウスの作成をメインに書く予定ですが、ステッパーでやってきたことについても書いていこうと考えています。

 

去年までは一応部長だったのですが、まったく何もしてこなかったので、さすがにそろそろサークルに貢献できることをしないといけないなと思っています。こんな部長だったので、去年の3月に新歓を行っていたときは、入ってくる1年生には申し訳ない気持ちでいっぱいでした。

 

今年からはブログの更新をはじめ、dcマウスの作成、後輩の指導などを頑張ろうと思います。