====== 7-1 基本的な対処法 ======
===== トラブルシューティングの基本 =====
電子工作で制作物のトラブルが起きた時は、問題の切り分けが肝心です。
その問題の原因が何かによって、対処法はまるで違います。
==== 原因別・よくあるトラブルの例 ====
=== 電気的原因によるもの ===
テスターを使うと発見できるものが多いです。
* 電圧不足 → 部品の動作電圧に満たない電圧が印加されている
* 電力不足 → 部品の消費電力に対し供給電力が足りない
* 過電圧 → 動作電圧を超える電圧を部品に与えている
* 過電流 → 定格を超えた電流が部品に流れている
* 配線ミス → 配線が間違っている、抜けている
* 接触不良 → ワイヤやコネクタの接触不良や断線、コネクタの圧着不良、はんだ付けの失敗など
* 配線が長すぎる → メートル単位のような配線はNG。特にI2CやSPIは20cm程度の長さでも通信不良を起こすことがあり、かなり短くしないといけない
* 逆接 → 極性のある部品(LEDやCRDなど)を逆に接続している
* ノイズ → 電気的ノイズが部品の動作に悪影響を及ぼす
* UARTの接続 → RX-RX/TX-TXになっていないか。基本的に互い違いに接続する。RXはTXに、TXはRXに接続
/*UARTの接続が逆、ここはTX/RXと書いたほうがやさしい*/
=== プログラムのミスによるもの ===
大概のプログラムの書きミスはコンパイラが指摘してくれますが、中にはコンパイラがキャッチすることができずに発生するミスもあります。
以下はその一例です。
* プログラムの動作的には至極正しいが、自分の意図通りのプログラムを書けていない
→例えばサーボを90度に動かしたいのに角度の数値に180と入れている
while文から抜け出すための処理を設定し忘れていて無限ループに陥っている 等
* ピン番号の指定間違え → ピン番号を変数化している場合に番号を間違えたり、部品の初期化時に別の変数を入れている
* 変数の型の宣言間違え
→入れたい値が入らない変数を宣言している
例えば1億までの数字を扱おうとしているのにint型で変数を宣言してしまっている
小数点のある数値を扱おうとしているのにlong型で変数を宣言してしまっている 等
* 変数の指定間違え → ある変数を入れるべき部分に型が同じ別の変数を入れてしまっている
* デジタルピンのINPUT/OUTPUT/INPUT_PULLUPの指定が間違っている
* UARTを使う場合、繋いだもの同士のボーレートが一致していない
* I2Cを使う場合、I2Cアドレスが間違っている。もしくは同じアドレスの部品が複数ある。
* そもそもマイコンへのプログラムの書き込みに失敗している
/*変数宣言時の型違いとかもトラブルとしてよくあります。intなのにlongにしたとか*/
=== その他の原因によるもの ===
* マイコンや部品の初期不良
* マイコンや部品が過電流や逆接、静電気などで既に壊れている
* 極端な環境(高温や低温)で動作させようとしている
* モータ系の部品で、トルク以上の力や重さが動作部にかかっていて動きが相殺されている
* 通信系の部品で、電波の状況がよくない、電波を遮るものがある
==== トラブル対応の基本のおさらい ====
**作った電子回路が動かない・或いは動作がおかしい場合、まずはすぐに電源を切りましょう。**
動作不良の原因にすぐに思い当たる点がない場合は、電気的原因 → プログラムの順番でミスを探るのがベターです。
===== 回路のデバッグについて =====
この項は私が回路デバッグをする際に実行していることです。
初心者向けではない部分もありますが、ご参考までに。
==== 回路のデバッグでやるべきことリスト ====
* 導通チェックをする
* テスターでピーと鳴るか
* 抵抗値を測るのもあり。導通してなければ不定になる
* 電圧を測る
* パーツの極性を確認する
* パーツを外すと状況が変わるか見る。1個ずつ外す、逆に最初に1個から始めて1個ずつ追加していく
* 発熱の場合はどこで発熱してるかを見る
* 素子のスペックを洗い出し、電流や電圧が許容範囲内か再度確認する
* ドロップアウト電圧にも注意してください
* 電子顕微鏡で、挙動が怪しい部分のはんだ状態を観察する
* ショートや、オーバーヒート、いもはんだを確認する
* 電子顕微鏡で怪しいところを観察する
* オシロスコープで波形を見る
* 異常発熱時など、オシロに負荷かかりそうな場合はできる限りのことをやってからにする
==== テスターについてのメモ ====
* ちょっとだけピッとなるのはコンデンサの影響。導通してるわけではないです
* 電流は、流れてる線をぶった切って直列につないで測る
==== まつはちさんによるテスターの使用例動画 ====
{{youtube>1VCpHvv3z_A?large}}
/*ここに回路デバッグの仕方を入れた方がデバッグの順番として適切だと思うので、ここに私の回路のやつ入れた方がいいと思います ちょっとレイアウト悩みますが…回路→プログラムの順なので*/
===== プログラムのデバッグについて =====
==== コンパイルでエラーチェック ====
プログラミングの構文的なミスはコンパイルをすることである程度チェックすることができます。
コンパイルはArduinoIDEでは検証ボタンを押すか、もしくはツールバーの スケッチ → 検証・コンパイル から実行することができます。
また、プログラムをArduinoに書き込むときにも実行されます。
コンパイルをかけてエラーメッセージが出た場合は、[[gimmickkouza:electronic_basic:7:2_arduino_errormessage|]]のページを読みエラーの原因を探ってください。
[[gimmickkouza:electronic_basic:7:2_arduino_errormessage|]]のページにはないエラーメッセージが出現した場合は、メッセージをコピペして検索し、対処法を探るのが最も基本的な対応です。
ちなみにメッセージ全文をコピペするのではなく、どういうエラーであるかを直接指摘している部分を探し出してコピペして検索するといい感じにHitしやすいです。
==== プログラムのチェックに使える小技集 ====
コンパイラは非常に便利で心強い存在ですが、そのチェックは必ずしも万能ではありません。
特に__「プログラムの動作的には至極正しいが、自分の意図通りのプログラムを書けていない」場合、コンパイラがそれを見抜くことは基本的にはできません。__
「コンパイルは通ったしボード書き込みも無事完了した、電気的な問題や配線もチェックし問題なかったけど意図した動作にならない」
そんな時のセルフチェックに使える手法をいくつかご紹介します。
=== とにかくシリアルモニタに表示する ===
基本中の基本はSerial.printlnを使ってシリアルモニタに処理状況を表示することです。
* 特定のループ文や条件分岐がちゃんと実行されているのか？
→そのループや条件分岐の中にSerial.printlnを入れる。メッセージが表示されれば実行されている
* どこかで無限ループが発生していないか？
→setup部、loop部の冒頭にSerial.printlnを入れる。
無限ループがなければsetup部のメッセージは1回、loop部のメッセージは繰り返し表示される
* 計算式の計算結果、変数に入っている値、センサで拾った数値等の値がおかしくないか？
→値をSerial.printlnで表示する
=== コメントアウトを活用する ===
プログラムの特定の行をコメントアウト「//」、「/* */」で無効化し、動作確認をします。
* 不具合の原因っぽそうな怪しい行がある
→プログラムに差し障りがなければその行を無効化し、Arduinoに書き込んで動作がどう変わるかチェックする
* プログラムを上から順番にチェックする
→スケッチが膨大でダメ箇所の目星もつかない場合、特定の行以下すべてを「/* */」でまとめて無効化し、Arduinoに書き込む
(無効化はプログラムの動作に不具合が出ない箇所で区切ってください)
動作に問題がなければ無効化した行の一部を少しだけ有効にし、書き込み→チェックを繰り返してダメ箇所を特定する
* 部品ごとに動作チェックをする
→Arduinoに複数の部品を繋いでいてどれが不具合を起こしているのか見当がつかない場合、部品ごとに動作チェックをする
関係のない部品の動作箇所をコメントアウトし、ある部品の動作がOKならコメントアウト箇所を変え別の部品のチェックをする
部品の動作すべてに問題がなかった場合、各部品間の連携やそれ以外のプログラムに問題があるかもしれない
=== AIにプログラムを見てもらう ===
ChatGPTなどのAIツールに自分が書いたプログラムを投げてダメな箇所を教えてもらいます。
最近講師がよく利用している方法です。講師が思う、使用に際してのコツをいくつか列挙します。
* プログラムだけでなく、「そのプログラムを説明する情報」を与える
→プログラム本文のアップと併せて、
「これは何のためのプログラムか」
「このプログラムでどういう処理をしたいのか」
「このプログラムが望ましい動作をしたときの処理プロセス」
「このプログラムを実行している今、どういうエラーや問題が起きているのか」 といった情報をAIに与えます。
うまくいけば、AIはこちらの要求の観点に立った改善案を挙げてくれます
* どういう風に回答してほしいかを指示する
→回答の仕方を指示せずに専門的な質問を投げると、容赦なく専門用語を多用し難しい言い回しをしてくる可能性があります。
例えば「初心者向けに難しい言葉を避け、わかりやすく説明してください」等の指示を盛り込むと、AIは回答の仕方を工夫してくれます
* マニアックな情報は期待しない
→AIは有名な情報・サンプルが多い情報には強いですが、マニアックな情報やユーザー数が少なくネットに情報がないもの
…例えばレアな部品の仕様やライブラリの使い方といった質問には答えられない可能性が高いです
* **課金する**
→講師はChatGPTしか使っていないので他のAIはわかりませんが、
ChatGPTの場合__課金して利用できるツールと非課金ツールとでは精度に天地の差__があります。
**真にAIの力を借りたければ課金しましょう**
2024年6月現在のAIはまだ完璧な存在とは言い難いです。
**不正確な情報や最新ではないソースをもとにした情報、こちらの指示にそぐわない回答をすることも多く、人の目の校正やチェックを前提に使うべき**であると強く思います。
ちなみにAIにプログラムを書いてもらうこともできます。
こちらもそのままでは使えないことも多いですが、**プログラムを書き始める時の"たたき台"として使ったり、有名ライブラリの使い方を訊いてみる**といった用途などで非常に便利です。