目次

7-1 基本的な対処法

トラブルシューティングの基本

電子工作で制作物のトラブルが起きた時は、問題の切り分けが肝心です。
その問題の原因が何かによって、対処法はまるで違います。
  

原因別・よくあるトラブルの例

電気的原因によるもの

テスターを使うと発見できるものが多いです。

プログラムのミスによるもの

大概のプログラムの書きミスはコンパイラが指摘してくれますが、中にはコンパイラがキャッチすることができずに発生するミスもあります。
以下はその一例です。

  →例えばサーボを90度に動かしたいのに角度の数値に180と入れている
   while文から抜け出すための処理を設定し忘れていて無限ループに陥っている 等

  →入れたい値が入らない変数を宣言している
   例えば1億までの数字を扱おうとしているのにint型で変数を宣言してしまっている
   小数点のある数値を扱おうとしているのにlong型で変数を宣言してしまっている  等

その他の原因によるもの

  

トラブル対応の基本のおさらい

作った電子回路が動かない・或いは動作がおかしい場合、まずはすぐに電源を切りましょう。
動作不良の原因にすぐに思い当たる点がない場合は、電気的原因 → プログラムの順番でミスを探るのがベターです。
  
  

回路のデバッグについて

まつはちさんからのアドバイス

この項は私が回路デバッグをする際に実行していることです。
初心者向けではない部分もありますが、ご参考までに。
  

回路のデバッグでやるべきことリスト

  • 導通チェックをする
    • テスターでピーと鳴るか
    • 抵抗値を測るのもあり。導通してなければ不定になる
  • 電圧を測る
  • パーツの極性を確認する
  • パーツを外すと状況が変わるか見る。1個ずつ外す、逆に最初に1個から始めて1個ずつ追加していく
  • 発熱の場合はどこで発熱してるかを見る
  • 素子のスペックを洗い出し、電流や電圧が許容範囲内か再度確認する
    • ドロップアウト電圧にも注意してください
  • 電子顕微鏡で、挙動が怪しい部分のはんだ状態を観察する
    • ショートや、オーバーヒート、いもはんだを確認する
  • 電子顕微鏡で怪しいところを観察する
  • オシロスコープで波形を見る
    • 異常発熱時など、オシロに負荷かかりそうな場合はできる限りのことをやってからにする

  

テスターについてのメモ

  • ちょっとだけピッとなるのはコンデンサの影響。導通してるわけではないです
  • 電流は、流れてる線をぶった切って直列につないで測る

  

まつはちさんによるテスターの使用例動画

  
  

プログラムのデバッグについて

コンパイルでエラーチェック

プログラミングの構文的なミスはコンパイルをすることである程度チェックすることができます。
コンパイルはArduinoIDEでは検証ボタンを押すか、もしくはツールバーの スケッチ → 検証・コンパイル から実行することができます。
また、プログラムをArduinoに書き込むときにも実行されます。
  
コンパイルをかけてエラーメッセージが出た場合は、7-2 エラーメッセージ集のページを読みエラーの原因を探ってください。
7-2 エラーメッセージ集のページにはないエラーメッセージが出現した場合は、メッセージをコピペして検索し、対処法を探るのが最も基本的な対応です。
ちなみにメッセージ全文をコピペするのではなく、どういうエラーであるかを直接指摘している部分を探し出してコピペして検索するといい感じに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にプログラムを書いてもらうこともできます。
こちらもそのままでは使えないことも多いですが、プログラムを書き始める時の“たたき台”として使ったり、有名ライブラリの使い方を訊いてみるといった用途などで非常に便利です。