マイクロマウスの設計・製作時のチェック項目/故障・おかしな動作をしたときに確認すること

2020年6月7日

マイクロマウス関連記事のまとめはこちら。

マイクロマウスがしっかり走っていたと思いきや唐突におかしくなることは多々あると思います。モチベーションがとても下がりますし、辛い気持ちになりますが直さなければいけないこともあると思います。

今回は、根本的に故障や問題点を起こさないように気を付けるべき点と、壊れてしまったときの問題点の切り出しのための対応例を書いていきます。

(＊内容は、2019年度のマイクロマウス合宿で発表をしたものをまとめたものになります。)

 




注意点について

  1. 対処法が正しいとは限りません。
  2. 対処法を試した結果問題が起きたとしても責任を取ることはできません。自己判断でお願いします。
  3. ここで紹介した以外にも対処法はあると思います。参考程度にしていただければと思います。

 

設計・製作時のチェック項目

機械設計編

マイクロマウスの設計は基本的に二次元CADまたは3次元CADを使用して設計していることを前提として話を進めていきます。

設計時に気を付けている点は以下の通りです。

  • 部品の干渉をしっかりとチェック
  • ギアのバックラッシの間隔を少しあけ、駆動系のバックラッシはゼロではなく遊びをつくってスムーズに動作をするようにする。
  • 部品が手に入るかどうかをしっかりと確認する

ここに書いたもので、部品が手に入るかどうかをしっかりと確認するということは意外と大切です。マイクロマウスで使用しようと思っていたリポバッテリーが売切れたり、ギアが廃盤になってしまい手に入らなくなるといったことが起きて設計をやり直すということが起きるとモチベーションが下がるので、入手性を考えて選定するようにすることをお勧めします。上の2つに関しては、ちゃんとやらないと走らないのでやりましょう。

わからない方は、単語を頼りに調べてみてください。

私は2DCADで設計をした後に、ギアがちゃんとかんでいるか、干渉がないかといったことを3DCADで簡単にアセンブリをして確認しています。

2019年マイクロマウス紹介のページに、簡単にモデリングして干渉チェックに使用しているマシンの3DCADのデータがあるので興味をある方は見ていただければと思います。

 

回路設計編

回路設計時にしっかりとやらなければならないことは、使用する素子が電子部品を選定するときにはディスコンになっていない(手に入る)か、素子のデータシートをちゃんと読むことです。データシートをしっかりと読まないと次のような事案に悩まされる可能性があります。

  • SPI通信という同じ規格のジャイロセンサとエンコーダを一緒のバスで繋いだら通信方式のルールが違うせいでソフトウェアが複雑になり大変になった
  • マイコンのコンデンサをつけ忘れた結果マイコンの動作が不安定になった
  • マイコンに書き込みができない(ブートの設定が間違っている)
  • ピンアサインを間違えてつないだ
  • マイコン周りの電源回路を間違えて短絡させた

あくまで例ですが、このような問題点が起きる可能性があります。短絡させてしまったことや、ピンアサインなど目に見えてわかるものは問題がありませんが、マイコンの動作が不安定な場合は走行中に問題が唐突に起きてデバッグが大変になる可能性が多いにあるため気を付けましょう。

また、回路の配線を引くときに気を付ける点は以下の通りです。

  • 配線を直角に引く(NG)
  • ベタグラウンドの浮島を作ってしまわないこと
  • モーターICのパワーGNDとそれ以外のグラウンドは一点設置にする
  • 配線の太さは定常的に流れる電流を考えて決める(例:1A流れるところは1mmを目安にする)

 

はんだづけ、火入れ編

はんだづけをするときは、温度調節をできるはんだごてを使用することやフラックスを塗ってからはんだ付けをするといったように、環境をしっかりと整えてするとミスが減ると思います。

ここで、気を付けるべき点を紹介させていただきます。

ここに、はんだ付けが終了したばかりのマウスの基板と、基板につなぐことのできるバッテリーがあったとします。

はんだ付けができた基板

 

リポバッテリー

皆さんはどうしますか？

  1. 繋いでみる
  2. テスターでショートの確認をする
  3. 組み立てて、全ての配線をつないでから電源を入れる

 

1を選んだ場合・・・やらかした場合は一瞬で虚無の完成

2を選んだ場合(推奨)・・・虚無を生む可能性が少なく安全

3を選んだ場合・・・下手をするとモーターなどの配線をしたものを一緒に虚無に変える可能性があり

 

マイクロマウスは、表面実装の中でも小さい部品を使用していることではんだ付けの難易度が上がり目では確認できないものショートや、部品の付けるパッドを間違えている可能性等があり得るのでテスターで短絡チェックは必ず行いましょう。3だけは選ばないことを強くお勧めします。

 

組み立て編

私がやらかしたわけではありませんが、過去に私が見た事例では、組み立て時にモーターにピニオンを圧入する際に、ピニオンギアを万力圧入しようとして壊した、ねじの山が舐めてねじを外すのが大変、接着剤がモーターの軸の中に入ってだめにしたという事案を見たことがあります。

最低限やるべきことは、ねじを締めるときはねじの番手にあったものを使う、部品に無理な力を与えないことです。

ドライバの番手(先端の大きさが違います)

また、組み立てている最中に分解して付けた方が楽だけど、分解するのが面倒だから分解せずに何とかしようといった横着は絶対にやめましょう。横着をすると悪い結果を運んでくれます。

 

プログラム関連のエラーやミス

マイコンのコンパイルオプションについて

普段、PCでプログラムを書くときは最適化オプションについて考える必要はないと思います。しかし、マイコンを使用してプログラムを書くときにはコンパイルオプションが大切になる可能性が高くあります。

例えば、マイクロマウスの走行前にマシンのセンサの前に手をかざして動作を開始するプログラムを書くことを考えると以下のプログラムになると思います。

while(sensor_front.now < start_Threshold );

やっていることは簡単で、センサの値がある一定以上の数値になるまではまっているだけです。

ここで、最適化の問題が出てきます。コンパイル時の最適化オプションには次のものがあります。

-O1
  • グローバルな最適化を有効にする。
  • 組み込み関数の認識と組み込み関数のインライン展開を無効にする。
  • メモリアクセスを減らすためにレジスタに値を保存するなどの最適化を行う
-Og
  • GCC 4.8で導入されたオプションであり、デバッグ機能を維持しつつ速度を最適化するオプション
  • -O1と同程度の最適化が行われる
-O2
  • PCのgccにおけるデフォルトの最適化レベル
  • 関数のインライン展開を有効にする
  • for,whileの空ループを削除する(詳しくはgccに依存する)
-O3
  • -O2よりもさらに最適化を行う
  • 最適化オプションは使用しているgccに強く依存する
  • ループとデータプリフェッチの最適化を有効
  • 最大実行速度になるように最適化する

STM32F405RGT + makefileのコンパイルオプションに-O2を指定した場合は上記で上げた待ちループの動作タイミングで動作がおかしくなってしまうことが多くあります。

マイクロマウス競技のセンサの赤外線LEDのパルス発光で使われるfor文を使用した待ち時間の生成などの処理がおかしくなってしまいAD変換に入った瞬間におかしくなってしまいデバッグに時間を溶かしたことがあるので、おかしな動作をしたときは確認をして見ていただければと思います。

変数の最適化を無効にするためには”volatile”を使用することで可能です。

 

変数について考える

変数を宣言するときには、変数のスコープを意識していますか？スコープとは変数の使える有効範囲のことを指します。C言語における有効範囲は{}の間でのみ有効だと思えばいいと思います。

c言語における変数には、グローバル変数、ローカル変数、静的ローカル変数と呼ばれるものがあります。それぞれの変数の性質についてまとめてみました。

変数名 有効範囲
ローカル変数 {}の間
グローバル変数 プログラム全体
静的ローカル変数 変数の値を保存したいが、関数内の変数をグローバル変数にしたくないときに使用する

 

変数の確認用プログラムは次のものを使用しました。

#include <stdio.h>

void changeGlobalVer(void);
void checkStaticLocalVarAct(void);

int global_var; // グローバル変数

int main(void)
{
  int local_data1; // ローカル変数
  printf("ローカル変数の宣言時の値をチェック local_data1 = %dn", local_data1);
  local_data1 = 255;
  printf("ローカル変数の値を設定した後の値のチェック local_data1 = %dn", local_data1);
  {
    int local_data2; // ローカル変数
    printf("ローカル変数の宣言時の値をチェック local_data2 = %dn", local_data2);
    local_data2 = 240;
    printf("ローカル変数の値を設定した後の値のチェック local_data2 = %dn", local_data2);
  }
  printf("グローバル変数の初期値をチェック global_var = %dn", global_var);
  global_var = 15;
  printf("グローバル変数の設定した後の値をチェック global_var = %dn", global_var);
  changeGlobalVer();
  printf("グローバル変数の値を関数内で1足した後の値をチェック global_var = %dn", global_var);
  checkStaticLocalVarAct();
  checkStaticLocalVarAct();
  checkStaticLocalVarAct();
  return 0;
}
void changeGlobalVer(void) 
{ 
  global_var++; 
}

void checkStaticLocalVarAct(void)
{
  static int data = 1; // 静的ローカル変数 
  printf("関数を実行したとき data = %dn",data); 
  data++; 
  printf("関数内で足しを実行した後 data = %dn",data);
}

基本的にグローバル変数の値は0で初期化され、ローカル変数の数値は不定になっていると思います。ローカル変数の初期値が0は不定になるので初期化をして宣言をしてあげるまたは、初期値をしっかりと代入するようにしましょう。

ローカル変数の初期化を忘れた結果、アルゴリズムの中で使用する際に意図しない値を使用してバグを作ってしまうということがありえます。

 

故障？プログラム(アルゴリズム)？問題点の切り分けをどうするか

マイクロマウスのデバッグ中や大会で唐突に変な動作をしてクラッシュをした後に、自分が想定していない動作を始めてしまったときに何が悪いのかを探す方法を紹介していきたいと思います。

 

ハードウェアの確認

初めに確認することはハードウェア全体のチェックをしてみましょう。考えられることは、ねじが緩んでいないか、ピニオンギアが滑っていないか、部品が外れかけたりしていないか、配線の断線がないかといった物理的なところに問題がないか確認しましょう。

ピニオンギアが滑るという点については巷で「妖怪ピニオン滑り」と呼ばれているほどなので、要チェックだと思います。モーターにピニオンギアを糸だけで圧入している方は定期的にメンテナンスをしましょう！

 

最新のプログラムを疑う

デバッグ中でプログラムの制御系や、迷路関連のプログラムを変更した後に急におかしくなった場合はだいたい追加したプログラムに問題があることが多いです。

この時に問題点の切り分けをしやすい方法が、過去に正常動作をしていた時のプログラムをマイコンに入れて動作確認を行うことです。もし、正常動作をした場合は追加したプログラムのエラーが問題であることがわかり、問題が継続して出ている場合はハードウェアの何かに依存した問題であることが伺えるためです。

したがって、正常動作をしている状態のプログラムを何処かに保存しておくことをお勧めします。簡単にやる方法は、ディレクトリをコピーして名前を被らないように変更することです。少しだけ勉強をする必要がありますが、Gitを使用するということも手です。私は、GitHubを使用してプログラムの管理を行っています。

プログラムが長くなるにつれてプログラムの問題個所を探すのが大変になるのでちゃんとバックアップは取りましょう。バックアップがあればdiffコマンドなどで差分を探すこともできるようになります。

git diffコマンドで差分を確認したときの表示例

 

センサの値が飛んでいないかどうかを疑う

私が出会った現象では、止まっている状態ではエンコーダの値が取れるが、振動させるとエンコーダの値が取れたり取れなかったりするようになるということに遭遇したことがあります。

その時に確認した方法は、4区画程度の直進を速度を徐々に上げながら行い、それぞれのログを取得してセンサ値に問題がないか確認する方法です。徐々に速度を上げる理由として、速度が上がれば上がるほどセンサ値が飛んだ時に問題が出やすくなるということと、ある一定速度以上でおかしくなるといったことに再現性が得られることがあるためです。

問題の再現性が得られたら、古い正常動作をしているプログラムで同じ動作をさせて問題がでないかどうかを確認をします。もし、同じ現象に遭遇した場合は、センサがおかしいのか、制御系がおかしいのか、ハードウェア(電子回路)がおかしいのかの切り分けを行いやすくなるためです。

センサーの値チェックの例

はんだづけやはんだクラックを疑う

センサの値が取得できていない、モーターの出力がおかしい、配線の導通はしているのにおかしいといったことがすべてわかったらはんだ付けのクラックの可能性が高いと考えられるためはんだの温め直しや、テスターで導通チェック、UEWで配線を繋げてしまうといったことをしましょう。

テスターで導通チェックしたときは大丈夫なのに動かすとおかしくなる場合はパターンがクラックをしそうになっている状態である可能性が高いのでUEWで繋いだときにどんな動作をするか確認するといいと思います。

はんだづけを温めなおしたら直った、UEWで配線を引き直したら直った等の場合は再発する可能性が高いので日々のメンテナンス作業で確認をするようにしましょう。定期的におきてしまう場合は、時間に余裕があるときならば、同じ基板をもう一枚つくったほうがいい可能性があります。大会会場で毎回問題と遭遇するとただ辛いだけなので・・・(実体験)。

同じ基板をもう一度製作した後は、同じ問題が起きないかどうかをチェックし、配線がクラックする場合は配線を太くすることや、回路や選定した素子に問題があると判断できる場合は、次のマシンで再発しないように、メモを取っておくといいと思います。

 

まとめ

いかがだったでしょうか。この内容を読んで当たり前だと思った方は、自分なりの問題点の切り分け方が経験則などから確立をしている方なのかなと思います。

また、マイクロマウスで問題が起きやすい理由として考えられることは、基板を走らせているために振動がクラッシュなどで基板にダメージが募りおかしくなるということが頻繁に起きやすいのかなということです。

普通は基板を走らせないので。吸引をして壁や柱にあたると嫌な音が響くのでクラッシュするたびに頭を抱えたくなっています。

最近は、問題点の切り分けは比較的できるようになってきましたが、マシンの不具合はたくさん起こしてしまっているので次の課題はマシンの不具合を少しでも減らすように努力をすることかなと勝手に思っています。

長い記事になりましたが、最後まで付き合っていただきありがとうございます。少しでも参考になれば幸いです。

 

知見のある方で、問題点の切り分け方法にこんなやり方がある、この方法はおかしい、といったことがあればTwitterやディスカッションで指摘していただきたいです。

 

参考文献

gccのヘルプ・マニュアル