はじめに
以前自己啓発コミュニティの講習でAWS IoT Coreを触る前に、LTとかでサッと話したい内容を記事化したものです。
最近は「Raspberry Pi + センサーモジュール + AWS IoT Core」で何かやってみる、という記事や勉強会がたくさんあります。とても良いことなんですが、出来合いのモジュールやキットを使うだけでIoTを覚えてしまうと、最終的に自分で回路を組めなくなるという落とし穴があります。
クラウド側の前段、「センサーから値を取り出すところ」の解像度を上げておきましょう、というのが今回の趣旨です。
回路設計は大事
センサー → ラズパイ → IoT Coreという流れのいちばん上流で値の質を決めるのが回路設計です。
ここがズレると、どんなにLambdaやTimestreamを綺麗に組んでも、ダッシュボードに出る数字は嘘になります。
プログラムと回路の決定的な違い:「一発でショート」のドキドキ
コードはバグってもCtrl+Cで止まります。git revertもできます。
回路はそうはいきません。
- 抵抗値を間違える → 部品が焼ける
- +とGNDを逆挿し → センサーが死ぬ
- 電圧が高すぎる → ラズパイのGPIOごと逝く
「実行ボタン = 物理的に壊れる可能性のあるボタン」 という緊張感は、ソフトウェア畑の人ほど最初は戸惑うところです。逆にこの感覚を一度通っておかないと、実機トラブルの原因を「ソフトの問題」と誤解し続けることになります。
まずはここだけ:電圧・電流・抵抗・電力
「電圧、抵抗、電力」を語るには電流(I)も外せないので、合わせて4つだけ。式は2本だけ覚えてください。
V = I × R (電圧 = 電流 × 抵抗) … オームの法則
P = V × I (電力 = 電圧 × 電流)
| 記号 | 名前 | 単位 | イメージ |
|---|---|---|---|
| V | 電圧 | V (ボルト) | 水の「圧力」 |
| I | 電流 | A (アンペア) | 流れる水の「量」 |
| R | 抵抗 | Ω (オーム) | 配管の「細さ」 |
| P | 電力 | W (ワット) | 仕事量(発熱量) |
例:3.3VでLEDを20mA光らせたい場合、
- LEDで2.0V落ちるとして、抵抗が負担する電圧は 3.3 − 2.0 = 1.3V
- R = 1.3V ÷ 0.02A = 65Ω以上
これを知らずに直結すると、LEDは「ピカッ」と一瞬光って終わります。(経験者多数)
センサーの正体は「電気の流れ方が変わる抵抗」
ここがいちばん伝えたい所です。
多くのアナログセンサーは、突き詰めると外部の刺激によって抵抗値が変わるだけの部品です。
| センサー | 何で抵抗が変わるか |
|---|---|
| CdSセル(光センサー) | 光の量 |
| サーミスタ | 温度 |
| 感圧センサー(FSR) | 押す力 |
| 湿度センサー(一部) | 湿度 |
つまり「センサーの値を読む」とは、抵抗値の変化を電圧の変化として取り出し、ADC(アナログ-デジタル変換)で数値化しているだけの話です。
これが腹落ちすると、I2Cモジュールから降ってくるtemperature: 24.3という値の解像度がガラッと変わります。
出来合いモジュールとの違い:生の値は「揺れている」のが普通
ブレイクアウト基板や既製モジュールは、内部で電源を整え、ノイズを取り、I2Cやデジタル出力で「整った値」を渡してくれます。便利な反面、生のアナログ値を見たことがないと、値はそもそもどう揺れるものなのか分からないままになります。
生センサーをADC直結で読むと、だいたいこうなります。
温度センサーの読み値 (1秒間に10サンプル)
24.1, 24.3, 24.0, 24.2, 28.7, 24.1, 24.3, 24.0, 24.2, 24.1
↑ 急に外れ値
電源ノイズ、隣の機器の電磁波、配線の長さ、人体の静電気…とにかく揺れます。
ここで効いてくるのが、回路上の 「遊び」と「溜め」 です。
- 遊び = プルアップ/プルダウン抵抗、保護抵抗で「想定外の電圧・電流」を物理的に抑える余白
- 溜め = コンデンサで電源と信号を平滑化する(瞬間的な変動を吸収する)
このひと手間を知らずに値をIoT Coreに流すと、ダッシュボードのグラフがトゲトゲになります。
ソフト側の対策:平均値より中央値
回路で揺れを抑えても、サンプル粒度では外れ値が混じります。ここでどう集計するかが効いてきます。
samples = [24.1, 24.3, 24.0, 24.2, 28.7, 24.1, 24.3, 24.0, 24.2, 24.1]
avg = sum(samples) / len(samples) # 24.55
median = sorted(samples)[len(samples) // 2] # 24.2
平均値は1個の外れ値で簡単に持っていかれます。
中央値(median)は外れ値に強いので、IoTテレメトリで「人間や機械が判断に使う値」を作るときの第一候補です。
実装上はこの三段構えで一気に落ち着きます。
- 高めのレートでサンプリング(例:100Hz)
- 直近Nサンプルで中央値を取る
- その値だけをIoT Coreにpublishする
ペイロード料金も削れて、グラフも大人しくなって、後続のRulesやLambdaの判定もブレません。
まとめ(ここまで)
- 回路は「壊れる」前提の世界。コードと違って実行ボタンが怖い
- センサーの正体は「変化する抵抗」。電圧として取り出してデジタル化しているだけ
- 値は揺れるのが当たり前。回路で「遊び」と「溜め」、ソフトで「中央値」
- これを知らないままIoT Coreに繋ぐと、クラウド側の頑張りが全部ノイズに食われる
つづく
次回はこの前提を踏まえて、ラズパイで実際に生センサーをADC経由で読み、IoT CoreにMQTT publishするところまで書きます。