文書の過去の版を表示しています。

7-1 基本的な対処法

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

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

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

電気的原因によるもの

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

  • 電圧不足 → 部品の動作電圧に満たない電圧が印加されている
  • 電力不足 → 部品の消費電力に対し供給電力が足りない
  • 過電圧 → 動作電圧を超える電圧を部品に与えている
  • 過電流 → 定格を超えた電流が部品に流れている
  • 配線ミス → 配線が間違っている、抜けている
  • 接触不良 → ワイヤやコネクタの接触不良や断線、コネクタの圧着不良、はんだ付けの失敗など
  • 配線が長すぎる → メートル単位に及ぶ配線はNG。特にI2Cは20cm程度の長さでも通信不良を起こすことがある
  • 逆接 → 極性のある部品(LEDやCRDなど)を逆に接続している
  • ノイズ → 電気的ノイズが部品の動作に悪影響を及ぼす
  • UARTの接続が逆

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

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

  • プログラムの動作的には至極正しいが、自分の意図通りのプログラムを書けていない

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

  • ピン番号の指定間違え → ピン番号を変数化している場合に番号を間違えたり、部品の初期化時に別の変数を入れている
  • 変数の指定間違え → ある変数を入れるべき部分に型が同じ別の変数を入れてしまっている
  • デジタルピンのINPUT/OUTPUT/INPUT_PULLUPの指定が間違っている
  • UARTを使う場合、繋いだもの同士のボーレートが一致していない
  • I2Cを使う場合、I2Cアドレスが間違っている。もしくは同じアドレスの部品が複数ある。
  • そもそもマイコンへのプログラムの書き込みに失敗している

その他の原因によるもの

  • マイコンや部品の初期不良
  • マイコンや部品が過電流や逆接、静電気などで既に壊れている
  • 極端な環境(高温や低温)で動作させようとしている
  • モータ系の部品で、トルク以上の力や重さが動作部にかかっていて動きが相殺されている
  • 通信系の部品で、電波の状況がよくない、電波を遮るものがある

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

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

プログラムのチェックに使える小技集

プログラミングの構文的なミスはコンパイルをすることである程度チェックすることができます。
構文的なミスは、例えば「変数を宣言しないで使おうとした」、「あるライブラリの関数を使おうとしたが、ライブラリがインクルードされていない」、「あるライブラリを使おうとしたが、そもそもインストールされていない」、「; を付け忘れている」、「｛　｝の括りがおかしい」といったものです。
(詳細は次項のエラーメッセージ集をご確認ください)
　　
但し、コンパイラのチェックは万能ではありません。
特に「プログラムの動作的には至極正しいが、自分の意図通りのプログラムを書けていない」場合、コンパイラがそれを見抜くことは基本的にはできません。
　　
「コンパイルは通ったしボード書き込みも無事完了した、電気的な問題や配線もチェックし問題なかったけど意図した動作にならない」
そんな時のセルフチェックに使える手法をいくつかご紹介します。

とにかくシリアルモニタに表示する

基本中の基本は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にプログラムを書いてもらうこともできます。
こちらもそのままでは使えないことも多いですが、プログラムを書き始める時の“たたき台”として使ったり、有名ライブラリの使い方を訊いてみるといった用途で非常に便利です。