カテゴリー「電子工作」の198件の記事

2017年12月 8日 (金)

ロボットアームを2台のESP8266でリモコン操縦する

ブレッドボードのテストは順調だがスマホのHTMLタグが難しい(11/13/2017)
 モータードライバーで、ロボットアームをタクトスイッチで動かすことは出来た。これをESP8266のGPIOで制御してやれば、ワイヤレスリモコンが完成する。

 ソフトは、以前クローラーをスマホで動かしたときのESP8266のスケッチが残っている。これを流用すれば良いはずだ。ESP8266のWiFiをAP(アクセスポイント)モードにして、スマホとpeer to peerでつなぎ、スマホの画面から制御する方式である。

 このスケッチの中の制御ピンを増やしてやれば良い。ESP8266のハード周りをもう一度復習する。ESP8266は18本ピンが出ているが、このうちGPIOとして使えるピンは9本だけである。しかも、いくつかはモード切替などのため使えないピンがあり、結局、自由に動かせるピンは、6本しかない(制限付きのものが3本)。ぎりぎりだった。

Dsc01236 以前のスケッチに、動かすGPIOピンを少しづつ増やし、モーターを動かす代わりにLEDをブレッドボード上につけて動かしてみる。LEDは順調に点いたり、消えたりした。

 しかし、問題なのはスマホの方だ。画面上のボタンを増やしていくと、すぐ画面が一杯になり、スクロールしないと、ボタンが押せなくなる。画面のタップで操作性が悪くなっているところへ、画面の移動までして操縦することは、ほぼ不可能だ。

 小さなスマホの画面に、数多くのボタン類をどうレイアウトするかも問題である。はじめ、ボタンをトグルスイッチのようにして、モーターの細かい制御が出来るように考えたが、スマホのタッピング操作は連続させると全く違うactionにとられることがわかってこれは断念する。

Dsc01237 不便だが、それぞれのモーターのボタンはすべて動きの開始だけで、停止は共通のボタン一つにすることにした。それにしても、このボタンに使うHTMLのformタグのレイアウトはとても難しい。行と行の間隔が空きすぎて、ボタンの多い今度のリモコン画面は一面に納まらない。

 formタグを一行に複数置く方法は、幸いウェブにやりかたが載っていた。フォントをさらに小さくするなどして、一画面に納まるようにレイアウトする。もっと良い方法があると思うが、情けないことに新しい方法が思い当たらない。これまでの方法を力づくで片付けていくしかない。

スマホでテスト用のLEDは動いたが、運転するのは無理か(11/14/2017)
 画面が出来た。LEDをタップで光らして見る。点灯は僅か遅れるし、画面だけ見ているならともかく、アームの動きを見ながら、のっぺらな画面をタップする事は目茶目茶難しい。スマホのタップで細かい動きを制御するのはどうも無理な感じがする。

 何か良い方法はないだろうか。色々探してみる。すると、ESP8266同士をサーバー・クライアントでつないでいる記事が見つかった。そうか、スマホでなく、もう一台のESP8266をクライアントにし、これをUARTか、タクトスイッチで動かせば、スマホのタップを使わなくてすむ。

 しかし、これまでWiFiで2台のESP8266を連携させた経験がない。通信のイメージが良くつかめない。STAモードなのか、APモードなのか、TCPかUDPか色々方式がありそうだ。ちゃんと動くのかどうかの確信がない。それに対して今のスマホ方式はとにかく動いている。

 乗り掛かった舟ということもある。今、これをやめるとこれまでの苦労が無駄になる。迷った挙句、とりあえずモーターを動かすところまでやってみて、だめなら2台方式に乗り換えることにする。

オシロの計測では、0.5~0.6秒遅れ。やっぱり諦めるべきか(11/22/2017)
 その前に、スマホ方式の時間遅れをオシロで調べてみることにした。スマホは画面のタップ操作以外に、スマホが反応してから実際にESP8266のGPIOが動くまで、瞬時というわけではなく一息遅れてしまう。これがどれくらいの遅れか実測し、スマホ方式を諦める駄目押しにしたい。Dsc01238_2

 実測と言ってもスマホをタップしたタイミングは、残念ながら電気的に知ることは出来ない。これは別のタクトスイッチとスマホを同時に押して近似することにした。以前、スイッチの同時押しを実装するとき、人間の同時押しというのがどれくらいの誤差があるか測ったことがある。

 それによると、人間は、ずれを5ms以下にすることは殆どできないが、50ms程度の違いなら同時に押せる。今測りたい時間差は数百msの世界なので、この程度なら複数回測って平均をとればよい。

 久しぶりの新型オシロに電源を入れる。ブレッドボードにタクトスイッチを付け、それで手でタクトスイッチとタップを同時に操作し、それをトリガーにESP8266側でONされる時間を画面に出す。

 測定の結果、少々の誤差はあるが、平均では、0.5~0.6秒程度遅れていることが分かった。この前、クローラーをスマホで動かしたときと大体同じ感触だ。クローラーのような大雑把な運転ならともかく、ロボットアームでものをつかむというような、細かい操縦は出来ないだろう。 

スマホの操縦でロボットアームが壊れそう。モーターを分解修理(11/24/2017)
 とにかく、スマホによるロボットアームの動作試験は、やって見ることにした。まだ実装がすんでいないのでブレッドボードを経由して、ロボットアームとESP8266を接続する。Dsc01254

 スマホのWiFiサイトを、画面に出てくるESP8266のアクセスポイントに設定し、適当なブラウザーでアドレスを指定する。よーし、制御画面が出てきた。適当なモーターをONする。良いぞ。モーターが動き始める。記念すべきスマホによるロボットアームの最初の稼働だ。

 しかし、予想した通り、やはり、遅れ時間が大きいうえ、少し焦って画面を見ずにタップすると思った通りの操作にならない。そのうちアームは限界点に達して悲鳴をあげる(このキットのギアは空回り機構がついている)。

 さらに都合の悪いことに、タップを正確にボタン上で行わないと画面が移動して目的のボタンがなくなってしまう。そのうち、モーターのひとつのギヤがかんで空転し始め、慌ててロボットアームの電源を切り離した。やれやれ、落ち着いているときは良いが、すこし焦るとタップ操作は、昨今の高齢者のブレーキとアクセルの踏み間違いと同じになる。Dsc01252

 モーターの空転は、減速ギアボックスの中で、歯車がはずれたようだ。ギアボックスの分解を余儀なくされた。予想通り、画面のタップで、こういう細かい動作を制御することは無理だということが良く分かった。

 タップというのは画面を見ながらでないと正確にできないし、それではロボットアームの動きがわからなくなる。これでスマホで操縦することは完全に諦めがついた。

 やっぱり、もう一台ESP8266を入れて、タクトスイッチを動かすクライアント方式にしよう。ロボットアームの実装は途中でお休みし、ESP8266の2台方式にとりかかった。

2台めのESP8266ブレークアウト基板の制作(11/25/2017)
 ということで、ストックしてあった予備のESP8266のブレークアウト基板の組み立てにとりかかる。これはクライアント用である。久しぶりなのでESP8266の開発環境を復習する。

 結構沢山のピンを事前にセットアップする必要ある。これまでの基板は、便利と思って、I/Oピンソケットをすべて片側に一列に並べたが、ピンの位置の確認に余計な手間がかかり反って非能率だった。その反省を生かして、今度はESP8266のピン両側に分けてピンソケットを並べる。

 書き込みモードとフラッシュブートの切り替えは、スライドスイッチからタクトスイッチに変更する。切り替えは、電源立ち上がりかリセット直後のGPIO0のhigh/lowだけで判断しているようなので、タクトスイッチだけで良い。 Dsc01264

 さらにGPIO15は立ち上がりの時は、必ず、LOWでないと動かないが(これが結構はまる)、立ち上がった後は、制御可能なので、プルダウンはピンヘッダーで変更可能にする。

 大した作業量ではないので、この基板はすぐ出来た。あとは、ロボットアームに実装する作業手順である。ロボットアームの基板は小さく、リセットスイッチなどは載せられないから、どこかでスケッチを焼いてから、持ち込む必要がある。

Aitendoピッチ変換基板で実装するESP8266を用意する(11/27/2017)

 作業手順を検討した結果、ESP8266の稼働用の基板がもうひとついることが分かった。リセットや書き込み用のボタンは必要ないが、立ち上がりに必要ないくつかの設定がある。立ち上がりモードの設定(GPIO0)、GPIO2のプルアップと、GPIO15のプルダウンである。

 ロボットアームの基板の平面上は確保したが、ESP8266のピッチ変換基板のピンヘッダーの高さが意外に大きく、普通にシングルラインのICソケットにつけていたのでは、カバーが入らないか、下のフレームにぶつかってしまう。

 実は、前からこのことに気づき、色々調べていたのだが、ふとしたことで良さそうな案を思いついた。秋月が売っている汎用基板に厚さが0.8ミリの薄い基板があることを知って閃いた。これにICソケットをハンダ付けし、この基板をESP8266の裏側に入れてESP8266をはさむ。Dsc01258

 こうすると、ICソケットの高さ分が低くなり、カバーの中におさまる。ESP8266の立ち上がりに必要な部品は、この薄い基板に配線できる。なかなか良いアイデアだと自己満足する。

 そのうち、Aitendoのピッチ変換基板の裏には、初期設定用のプリント配線が用意されており、あらためて配線しなくても実装できることを発見した。

 このプリント配線だが、リセットやENABLEのプルアップ抵抗のランドは、2010くらいあるのに、GPIO0や、GPIO15などのランドは非常に狭い。1005よりもっと狭い。これはあとになってわかったのだが、このランドはハンダブリッジの間隔で、チップ抵抗を置くランドではなかった。直接VccやGNDに落としてもOKだということなのかもしれないが、何となく不安だ。

 で、これまでのストックから、1005クラスのチップ抵抗を探し、ランドを削って正式なプルアップ/プルダウン配線にすることにした。しかし、こんな小さな抵抗の手持ちはない。

そこで、物入れから、ジャンク基板(結構たまった)や、歴代の不良HDDなどを掘り出して、1005に近いプルダウンになる10KΩ程度のチップ抵抗を探した。

 思ったより簡単に見つかった。ハンダごてだけで採集する。例の低温ハンダを使うまでもない。少し周りを長い間あてていれば、チップ抵抗くらいだと自然に動き出すので、取りだすのは簡単だ。

 何とか必要な数のチップ抵抗を確保し、やっとのことでつけたのだが、案の定、一か所テンプラハンダをやってしまった。ランドが小さすぎて片側が接触不良になっていたのである。Dsc01251

 写真ではよくわからないが、左側がつながっていない。これで数時間を無駄にした。チップ部品は、片側が固定されてしまうと、残りの部分の接触不良は目検や、物理的な検証(部品を触る)では簡単には見つからないことを学ぶ。

 それにしても、残してあったHDDは不良品もふくめて5個以上ある。Appleマッキントッシュ時代の160MB(GBではありません)、SCSII(スカジー、これは死語か)DISKを見つけて感慨無量である。あのころは100MBを越す容量は大容量だったのだ。このあたりのチップ部品は、2010ではなくもっと大きいので、最近の基板には大きすぎて使えないのが残念である。

UDPでLEDを制御するスケッチを見つけた(12/1/2017)
 2台のESP8266の接続を紹介するサイトは、探してみたら結構沢山見つかった。参考になりそうなスケッチ(ソースコード)もあちこちにある。いくつか見て手続きの簡単なUDPで行うことにする。ここのソースコードを拝借することにした。4つのLEDの点滅を別のESP8266で実現している。こちらと全く同じだ。動画も公開されており、見たところレスポンスも速い。

 Arduinoには沢山のライブラリーがあるのでUDPを動かすのは、とても簡単なようだ。UDPを知らなくても、単にソケットをオープンしてそこへデータを流し込むだけである。クライアント側は、ソケットにデータが来るのをループで待って、それを読むだけである。

 こちらも2台のESP8266とLEDで実験してみた。最初は全く動かなかった。動かなかった理由は、お恥ずかしいながら全く基本的なところである。拝借したソースコードのSSIDとパスコードを自分のところに変えていなかっただけのことである。Dsc01256

 UDPが今一つ理解できていない証拠である。ソースコードの中の、WiFiのSSIDとパスコードが'*'になっているのを見て、UDPではそうするのかと、そのままにしてあったというオチである。良く考えれば、WiFiのこことUDPとは何の関係もないのだが、思い込みというのは恐ろしい。これに気付くまでまた数時間を浪費した。

 2台のESP8266のWiFiを正しく設定して、UDPを使ったリモコンLEDは全く問題なく動作した。動きも速い。案ずるより産むがやすしである。もっと早くこの方式にすれば良かった。

 ついでにオシロで遅れ時間を測定した。今度は両方とも電気的に問題なく採集できる。良いぞ。最小5ms、最大でも20ms以内にレスポンスが返ってきた。スマホ経由のTCP/IPのサーバー経由なら数百msオーダーだったやつだ。

やった、タクトスイッチのUDP接続でロボットアーム快調に動く(12/6/2017)
 ここまで来たら、もうあと一歩である。ブレッドボードを何枚か連ねてバラックでモータードライバーの制御線をESP8266のGPIOにつなぎ、もうひとつのブレッドボードにタクトスイッチを並べてクライアントを組み上げる。

 あれえ。クライアントのGPIO16だけが一旦、0(active)になると1(stop)に戻らない。試行錯誤の結果GPIO16はプルアップが必要とわかった。10KΩの抵抗を入れてしのぐ。Dsc01263

 早く結果が見たいので、一部のモーターだけの結線にして、UDP接続を確かめる。UARTを動かして接続をモニターしながら、テスト開始。

 やった。とても機敏にモーターが動いたり止まったりする。スマホとは比較にならないレスポンスだ。全く問題ない。ところがしばらく動かしている間に、突然モーターが止まらなくなった。あわててロボットアームの主電源を切り離す。暴走だ。こういう機械で最も避けねばならない現象である。不安がよぎる。

 冷静になって、慎重にソースコードを見直した。ははーん、原因がわかったぞ。サーバーは常にクライアントからのUDPメッセージを待ち続け、切れても再接続の初期手続きをやりなおしてループしている。

 GPIOの状態はどうだ。あらあら、通信が途絶えても、前の状態を続けたままだ。これではクライアントの接続が切れると同時に、前の状況のまま暴走する。

 良かった。これが原因に違いない。LEDなら付きっぱなしでも実害はないが、モーターの場合は致命的だ。サーバー側に、通信が途切れれば、必ずすべてのモーターの駆動を止めるステップを加えた。その結果、動きは安定し、今までのところこのトラブルは再現していない。Dsc01260

 ESP8266基板に正式にモータードライバーの制御線を接続し、所定の基板スペースにセットして一段落である。記念撮影する。テストをやりすぎたので電池がへたり、モーターの動きが鈍くなってしまったが、すべてのモーターがリモコンで動くというのは気持ちが良い。

やれやれこれでロボットアームのリモコン化は一段落である。

| | コメント (2) | トラックバック (0)

2017年11月 9日 (木)

ロボットアームをESP8266でリモコン化する

 また、ブログ書き込みの間隔が空いた。懸案のWiFIモジュールESP32を画像付きサーバーにするプロジェクトが一段落して、すっかり肩の力が抜けてしまい、そろそろ一か月を越える。

 とはいえ、このブログは備忘録を兼ねているので休むわけにはいかない。これまでの細々とした出来事を時系列でご報告し、そのあと、突然、その気になった表題のロボットアームの話をご紹介することにする。Dsc01232

 ロボットアームは、将来もっと本格的なものに乗り換えたいのだが(CNCフライス盤キットとどちらにするか迷っている)、とりあえずは、トイ(玩具)レベルのロボットアームキットで勉強することにする。動いたらこれをESP8266か何かでリモコン化しようと思う。詳しくは後半で。

CディスクがS.M.A.R.Tチェックで、BADになりディスクをSSDにした(10/1/2017)
 ESP32の画像サーバー開発に取り組んでいたころから、メインのPCがまたおかしくなった。BIOSの段階でハードディスクのエラー警告で止まる。エラーは、1TBのCディスクのハードチェックS.M.A.R.Tである。不良セクターの数が限界に近付いているようだ。

 今のところファンクションキーを押せば何事もなく立ち上がるが、この状況は爆弾を抱えているようなもので、このままにはしておけない。ウェブなどで探索するが、エラーの数が限界を越えたものをもどす方法はない。ハードを取り替えるしかないようだ。

 ハードディスクの購入や交換は造作のない話だが、中味をそっくり別の物理媒体に移すのは結構面倒である。ネットで簡単な方法を探しているうち、何も今さらHDDではなくSSD(Solid State Disk)に取り替えてしまえば良いことに気づいた。前からSSDにしたかったので一石二鳥である。

 どんなSSDが良いか調査を開始する。なんと240GBのサイズが一万円を切っている。現在のCディスクの使用量は100GBもないので、これだけあれば十分である。製品も新興メーカーも含め、多種多様のSSDが出回っている。Dsc01235 まあ、メインのCディスクにいくら安くても無名の会社のものを使うのは怖いので、SAMSUNG(ここが信頼できるかは別として)の240GBを選ぶ、それでも1万円少々で手に入る。面倒なので、通販で注文する。ほどなく郵便で届いた。便利な世の中になったものだ。

 早速、一緒に買った5インチベイのアダプターをつけてミニタワーのメインPCの筐体に装填する。ウェブサイトの記事にならい、無料のクローンユーティリティを使って、Cディスクの丸ごとコピーを始めた。このあたりのソフトは昔は有料で、しかも結構良い値段だったけれど今やこれも無料である。

 小一時間で終了した。早速、立ち上げる。おおー、これは超早い。Win10の立ち上げ14秒(BIOS入れて29秒)、シャットダウン10秒。これまでどれだけ早くても、それぞれ45秒、20秒かかっていた。それにしても世の中の進歩はすさまじい。半導体ディスク240GBが1万円しないのだ。

NTPでJST時間を作るには(10/3/2017)
 ESP32の画像サーバーの後始末で、ちまちました作業をやっている。今度入れたESP-IDFのSPIFFSは、生意気にもWifiでNTPにつなぎ、ファイルに時刻を記録している。時刻を見るとどうもGMTである。で、これをJSTに換えようと気楽に調べ始めたのだが、簡単に変更出来ない。ここはUNIXの世界なのである。奥が深い。

 少し調べたところでは、ロケールは日本になっているので、何もしないでTimeコマンドに反映されているはずだが、そうなっていない。それとも、NTPの数値はあくまでもGMTなのか。Timeコマンドの基本的な構造を理解していないので、手さぐりのトラブルシューティングになっている。

 たいしたことでもないことに時間をとられている感じがして、今一つ身が入らない。それでもソースコードを見ているうちにふと閃いた。Timeはある時刻からの積算秒を返す。それなら、GMTと日本時間の差9時間分の秒数を常に足してやればよいのではないのか。

 で、9X60X60=32400 を出てきた時間(秒)に足してみた。やった。ちゃんと時刻は日本時間になった。何というか、子供の時に「ずる」をしておやつを余分に貰った気分である。何となく後ろめたいが、まあ、次に行こう。

ESP-IDFの環境で日本語が通らない(10/4/2017)
 さらに気になっているのが、ESP32の画像サーバーのindex.htmlで日本語が化けることである。ソースのエディターのTeraPadでは正常に日本語が表示されるのに、ESP-IDFの開発環境mingwで見てみると、完全に字化けしている。mingwそのものは日本語メッセージが出ているのにソースの中の日本語が化ける。

 当然、ホームページの日本語は化ける。はて面妖な。どうでもよい話だが何か気に喰わない。当面やることがないので、少し本腰を入れる。ソースファイルのTeraPadのエンコードはUTF8になっている。それなのに、ESP-IDFのコンソールで字化けしている。

 ESP-IDFのコンソールが完全に日本語化(UTF8)されていることは確認した。そうなるとエディターTerapadの問題だ。バイナリーエディターを使って作られたテキストファイルを検証した。その結果、驚くべきことがわかった。

 Terapadは一旦シフトJISで作ったテキストファイルを編集画面上のオプションでいくらUTF8にしても、途中からUTF8に換わらない。エンコードをUTF8と指定した空のテキストファイルを起こし、そこで日本語を入れればUTF8になるが、一旦シフトJIS(それ以外は検証していないが)で作ったテキストファイルに後からエンコードをUTF8に直しても、UTF8にならないのである。

 要するに、TeraPadの不具合だ。いやもしかするとどこかにオプションがあったり、こういう仕様なのかもしれないが、フリーソフトなので余り追及する気にはならない。いずれにしても、空のファイルから日本語を入れ無事ホームページは日本語になった。このファイルにあとからシフトJISの日本語データを他からコピペして持ってきてもUTF8になる。

ESP8266はやっぱり遅い(10/8/2017)
 雑用が多くて、このところ電子工作に向かう機会が少ない。PCのエクセルで3日近く数字と格闘していたので、気分なおしに工作がしたくなり、久しぶりにESP8266を動かしてみた。

 ESP8266に、このあいだESP32で使ったjpgファイルを持ち込んで、どの程度の速さかを確認してみようという実験だ。これまでの画像ファイルは12KB足らずの小さな画像なので、ESP32で使った同じ40KBのjpgファイルを表示させてみれば直接比較ができる。

 前のブログ記事を見ながら、SPIFFSのアップロードを始めた。おやあ、エラーが出て途中で止まる。これまでと変えたところと言えば、ArduinoIDEでフラッシュサイズを最大の4MBに広げた。(前は1MBにしてあった)。

 ESP8266のフラッシュメモリのサイズは公称4MBだが、ウェブには、2MBしかないとか色々議論があるようで、これの検証も兼ねて4MBにしてみたのだが、いずれにしても動かないなら仕方がない。これを1MBに戻して再度挑戦。おお、ファイルのアップロードが順調に始まった。

 問題なくアップロードが終了し、ファイル名を前のファイル名と同じに換えて動かしてみる。これなら再ビルドも不要だ。うむ、動いた。いやあ遅いな。ESP32では一瞬だったが、やはりのったりと画像が出る。

 価格的には、ESP8266とESP32は余り違いはないので、これからはESP32を使う方が良さそうだ。I/Oピンもはるかに多いし。

DS3231の恐るべき精度(10/9/2017)

 ESP8266のボードの近くにTODクロックのDS3231がころがっていた。これをいじってから、もう一年は経っている。久しぶりに動かしてみる。ESP8266で動かしたことのあるI2C接続である。スケッチを取り出しI2Cをつなぐ。順調に時計が動き始めた。

 出てきた時刻を見て目を疑う。何と、数秒も狂っていない。ブログを慌てて読み返す。それによると最後の校正時間が2016年の4月1日とある。1年と6か月。そのあいだの誤差が1秒足らず。

 何かGPSかNTPで較正したとしか考えられない正確な表示で、狐につままれた感じだ。これは恐るべき精度としか言いようがない。それとも、ちょうど一年の寒暖の差で補正されたのかもしれない。

ESP32で固定IPアドレスの設定に成功したがNTPが通らない(10/17/2017)
 ESP32の次のテーマが見つからない。画像を出すようなウェブサーバーのアプリケーションがないのだ。これまでのDoit(懸案)メモを見なおしていると、ESP32のIPアドレスの固定化が懸案で残っていた。

 当初、固定アドレス化はすぐ着手したのだが、ArduinoIDEと違ってESP-IDFには、固定アドレスを設定するAPIが見当たらない。ESP-IDFでは出来ないと言っているサイトもある。それでそのままになっていた。

 それが、久しぶりに、ESP32 static IP addressなどでウェブを探したらやり方を紹介する海外のサイトが見つかったのである。それも一年も前のフォーラムでの議論だ。あとをたどって、ここをみつけた。

 入れてみた。最初、構造体をグローバルにするとコンパイルエラーになったので、ダメ元でローカル(Wifiの初期化ルーチン)に入れてみたらすんなり通った。早速実験する。おおお、うまく行った。あれだけ探していたのになぜ今まで見つからなかったのだろう。不思議なほど簡単に見つかった。

 得意になっていたのも束の間、こんどは、NTPのアクセスがうまくいかなくなった。うーむ、次から次にトラブルが起きるなあ。元へ戻すと大丈夫。staticアドレスにしたことでNTPが見つかっていない。

 DHCPがやってくれていた、NTPのURLの名前解決が出来ていないようだ。で、生のIPアドレスをnslookupで調べてそれをコードに埋め込んでみた。よーし、これならstaticでもNTPが動いた。

 原因を究明する。そもそも、固定(static)アドレスを指定するAPIの構造体には、IPアドレスとゲートウエイアドレス、それにnetmaskのメンバーはあるが、ネームサーバーのメンバーがない。バグではなくて仕様なのかもしれない。

 解決法は見つけられない。ESP-IDFには、mDNSという名前解決をローカルでやるネームサーバーのスタックがあるので、これを使えということかもしれない。いずれにしても、ここもUNIXの世界で、そう簡単に答が出る話ではない。まあ、これはこのあたりで深入りは止める。

ArduinoIDEでもESP32のSPIFFSサポートが始まった(10/19/2017)
 そうこうするうちに、ESP32のArduinoIDEでも、フラッシュファイルシステムをサポートするようになったことが判明した。うーん、こちらの方が楽か。ESP-IDFはやっぱり、日本で使っている人が少なく情報がとりにくい。

ロボットアームに興味が移って、キットを衝動買い(10/22/2017)
 秋雨前線が居座ったり、台風が来たりして連日雨にたたられ、自宅で引きこもることが多くなった。電子工作もテーマが品切れでやることがない。それでも、見るともなくウェブをさ迷っていたら、ちょうど良い遊び相手が見つかった。

 それは、ロボットアームである。昔(と言っても7~8年前)、エレキットのロボットアームに興味が湧き、一時は購入まで検討したことがあるが、その後、熱が醒めてそのままになっている。確か、商品を画像認識で、色別に仕分けしていたサイトで使われていた。

 久しぶりに、「robot arm」をキーワードにウェブで調べてみると、そのころに比べると海外も含めて多数のキットが売り出されていることがわかった。すべてアマチュア向けであるが、多種多様のロボットアームのキットが売られている。

 玩具レベルのものから、海外製品では、3DプリンターやCNC加工にでも使える数十万円のものまでたくさんある。玩具レベルのものは普通のDCモーターだが、少し高級になるとサーボモーターが多い。ステッピングモーターを使ったものはアマチュア向けにはないようだ。これは位置決めの仕掛けが難しいからだろう。Dsc01226

 所長が選んだキットは、¥5,000余りの日本製の「グリッパーアームロボット40320C」である。有線リモコンの5軸のDCモーター駆動で、先端に名前の通りはさみ(グリッパー)がついている。ツートーンカラーで、デザインが洒落ているのが気に入った。

 DCモーターなので、自動制御のようなことは出来ないが、有線をESP8266のようなものでワイヤレスにすることはできそうだ。画面を見ているうち急に欲しくなり、思わずアマゾンで注文のボタンを押してしまった。

電池が原因で片側が動かず、あせる(10/25/2017)
 キットは、4~5日で届いた。早速、記念撮影し、中を開ける。丁寧な組み立て説明書がついているので制作に不安はない。リモコンのコントローラーまで組み立て式で、スイッチは大きな金属片でプリント基板と接触させる。バラストを兼ねた単一電池4本を2本づつ正転と逆転用にわけ通電する方式で電子的な部品は一切使っていない。Dsc01227

 プラモデルのような部品を組み合わせ、モーターユニットを作っていく。3時間程度の作業を2回かけて2日で完成した。勇躍テストに入る。ところが逆転ができない。ひとつひとつのモーターユニットはテストが済んでいるので、問題はコントローラー周りだが、おかしなところは何もない。

 大体、部品など何もついていない回路で疑うところは電池のホルダーのところだけだが、しっかりハンダ付けで固定されている。しかも片側だけ動かないというのが気に入らない。テスターまで持ち出してやっと原因がわかった。Dsc01228

 何と片側の電池1つが、へたっていた。無負荷で測ると、1.5Vを指すが、電流を流したとたん0V近くまで下がる。使ったあとの電池が紛れていたようだ。単一電池は、他の小さな電池に比べると、へたると格段に高い内部抵抗を持つことが分かった。

 やれやれ、この電池のおかげで2回、配線ボックスを分解させられた。電池を取り替えてめでたくロボットアームは上下左右、自由に動くようになった。暫く夢中になって遊ぶ。ただリモコンのスイッチが固く、小さい子供さんが動かすのには苦労するだろう。Dsc01234

 次の目論見は、これにモータードライバーを入れてタクトスイッチだけで動くようにすることだ。最終的には、ESP8266を使ってワイヤレス化する。

#22AWGの基板配線はとても難しい(10/28/2017)
 モータードライバーで動かす基板制作を始める。キットの元の基板のマウントを利用し、秋月のC基板を少し削るとピッタリ入った。ESP8266あたりを付ける広さも確保された。Dsc01230

 例のモータードライバーDRV8835を3つ、コネクターの周りにレイアウトし、5つのモーターの制御を行う。6つ制御できるがひとつは未使用のままにしておく。念のためアートワークも描いた。配線はモーターなので細いUEW(ウレタン)線ではなく、#22の耐熱撚線(UL3265)を使う。こういうときのために買い置いてある、少々のハンダ付けの熱でも全く溶けたりしない丈夫な被覆を持っている撚線だ。

 配線を始めてちょっと後悔した。#22は少し太すぎて、DIPピッチではピンとピンの間を通すことが出来ない。まあ、被覆があるので接触することに神経質になることはないが、もう少し番手の大きい#24あたりが良かったかもしれない。しかし乗り掛かった舟である。そのまま配線を進める。Dsc01231

 ちなみに、22番の撚線の断面積は、0.633平方mmで、厚さ35μmのプリント基板配線だと9ミリぐらいの幅に相当する。#24くらいの撚線で配線すれば問題ないかも知れない。これで5ミリ幅程度、1Aクラスのモーターまで大丈夫なはずだ。

 久しぶりの基板の配線に夢中になる。苦労すればするほど出来上がったときの喜びは大きい。ただ最近は集中できる時間が短くなって2時間が限度だ。制御線はUEW線で済ませ、一日2時間程度の作業で5日で仕上がった。

DRV8835モータードライバーの在庫切れ(11/4/2017)
 しかし、問題が残っている。DRV8835そのものの手持ちが2つしかない。ひとつ足りない。未実装のDRV8835はアダプターの配線だけで先に進んだ。4つのモーターの動作確認は済んだが、まだ全体には組み込めない。Dsc01233

 秋葉原に車で出かけて秋月電子に向かった。なんと!DRV8835が売り切れている。11月上旬入荷予定とある。そのあとネットで入荷を確認して店にいったがまだ届いておらず、結局3回も秋月に通って11月4日遂に3個めを手に入れた。 

 帰ってすぐブレークアウト基板をハンダ付けする。とりあえず制御線だけ引き出し、ミニブレッドボードにタクトスイッチを並べてテストする。

 タクトスイッチはモーター5つに6ケ。モーター一つにスイッチを2つ設けて、正転、逆転それぞれ受け持たせるのが一番自然だが、これだと、制御線が10本になってしまい、将来のリモコンには多すぎる。esp8266は9本しかGPIOピンが使えない。

 このために、DRV8835のモードは、始動/停止と、正転/逆転にわかれたモード1を選ぶ。正転/逆転のピンは全部共通にしてピンの節約をはかった。

 とにかく、タクトスイッチによるリモコンは完成した。思っている以上に紙数が増えたので今回はこのあたりで。

| | コメント (3) | トラックバック (0)

2017年9月28日 (木)

WiFiモジュールESP32で画像付きサーバーの開発に成功

 前回までのブログは、失敗続きで暗かった。この年(もう70才を数年越えた)で、無謀にもみんながやっていないI2Cのクロックストレッチをソフトで実現しようとして、ハードウエアの基礎知識不足を見事にさらけだし、あえなく撤退した。

 しかし、今度の記事は胸を張って明るく報告できる。今流行りのWiFiモジュールESP8266の兄貴分ESP-WROOM-32(以下ESP32)で、画像付きのウェブサーバーの開発に挑み、このほど動かすことが出来たのだ。 Dsc01199

 ESP8266ではフラッシュの部分をファイルシステムにするSPIFFSがArduinoIDEで用意されていたので、これを利用して画像データファイルをホームページに表示することが出来た。ただ、ESP8266では性能的に一杯一杯で、わずか12KB程度のjpegファイルの表示に、ひといき(0.5秒くらいか)時間がかかり実用的とは言えない。

 ESP32は、ESP8266に比べると、CPU数が1から2、クロックも1.5倍(160->240Mhz)と性能が一段と強化されている(他にもBlueToothなど機能も豊富になった)。こいつなら少しは実用的な画像を背景にしたホーム画面や、イラストで作ったボタンが使えるかもしれない。
ここが詳しい

 ところが、ESP32のArduinoIDEの環境では、今のところSPIFFSが動いていないようなのだ。(このブログ参照)しかし、ウエブ情報を集めていくと、製造元(espressif社)の提供する開発環境、ESP-IDFや、他のプロジェクト(Rua-RTOS)で、フラッシュファイルシステムを作ったという話が出てくる。

 うまく動いているらしいが、リンク先が海外で、いまひとつ確実なことがわからない。でもここまできたらESP-IDFを導入して画像が出るところまで動かし、ESP8266との差を確かめたくなった。

 以下は、ESP-IDFの環境整備から、画像表示に成功するまでのESP32開発記録である。実は終盤になって画像を表示させるのにSPIFFSより遥かに簡単な方法が見つかるという、どんでん返しがあったのだが、詳しくは本文で。

ESP-IDF開発環境の導入から始める(9/2/2017)
 ESP-IDFとはArduinoIDEとは別の開発環境である。製造元の正式環境だが、make主体のCUIの世界で、WindowsにLinuxの環境を作るなど、準備に手間がかかり、今まで敬遠してきた。しかし目標である画像の出るサーバー画面の実現のためには避けて通れなくなった。

 気分を新たにして、開発環境を準備する。ハードウエアはArduinoの時と同じ秋月で売られている純正ブレークアウト基板DevkitCを使う。こいつは横幅が広いので普通のブレッドボードに差すとジャンパーが出せなくなるが、ここはミニブレッドボード2枚を並べてしのぐ。

 ESP-IDFのインストールは紹介するサイトが今や山ほどある(以前は少なかったが)。戸惑うことはない。むしろ沢山ありすぎて何を選べば良いのか迷うほどだ。まあ、余りこだわることはない。こことかこのあたりを参考にインストールを始めた。

 最初のmingw(Win上のLinux環境)のインストールファイルが500MB近くもあり、サーバーの線が細くてダウンロードに1時間近くかかったのが問題だったくらいで、インストールそのものは、意外にも順調だった。ここでも「ねむいさん」のブログにお世話になる。彼(彼女?)は何と去年のうちに環境をインストールしテストまでされていた。

 mingw上に自分のホームディレクトリを作り、開発環境は出来上がったが、沢山のサイトを拾い読みしていたために、ホームディレクトリの位置がさまざまで、esp-idf(開発環境本体)のディレクトリパスが中々通らない。何とか、ごまかし、ごまかし(mingwなので、サブディレクトリ区切りがバックスラッシュ\と、/が混在してややこしい)、makeが通るようにする。

 やっと動き出して、中味のファイルや、サンプルコードを覗く。ここはC++でもなく、純然たるCの世界だった。STM32で少しかじったFreeRTOSがメインのOSのようで、何か久しぶりに旧友に会ったような気分でなつかしい。

 ただ、MakeFileのあたりの情報隠蔽がかなり深い。実際のMakefileの中身が全く表に出て来ないので何をやっているのかわからない。ソースがメインプログラムしかないのも不思議である。わからないことだらけだが、とりあえず先に進む。

LチカとHelloWorldは簡単に動いた(9/3/2017)
 以前の記事のとおり、ESP32はArduinoの環境で既に動かし、LEDをウェブから制御できるサーバーまで作った。それでもESP-IDFの環境に慣れるため、サンプルソースにLチカ(blink)と、hello worldのソースがあったので、これらを使って練習することにした。

 ホームディレクトリに、サンプルソースの一式(AVRで言うプロジェクトのようなものか)をコピーし、make menuconfigで、シリアルラインの定義をしたあと、makeに入る。延々とビルドが始まった。

 ふーむ、Lチカくらいで、何か、すべてのリソース(IPV6からBluetooth、SSLまで)をビルドしているようだけど、どう言うことなんだろう。まあ、何十分もかかるわけでもないので待つしかないが、何か無駄のような。

Esp32_spiffs  Lチカは、指示通り、make menuconfigでIOピンの位置を修正する。前に使ったLEDをGPIOに設置し、makeに入る。幸いNO Errorのようだ。続いて、make flashでファームに焼く。これもエラーは出ない。すると、めでたくLEDが1秒近い間隔で点滅し始めた。よーし、動いた。

 次は、Hello worldである。もうひとつ手順が増える。make flashのあと、make monitorでコンソールにUSBコンソールのCOM3仮想ターミナルを立ち上げる。やたらとメッセージが多いが、無事、コンソールにHello World!の文字が10行づつ繰り返された。これも問題ない。

SPIFFSのgithubを見つける(9/6/2017)
 次は、HTTPサーバーだが、その前にこれまで見つけてあるSPIFFSプロジェクトを入れることにした。目星をつけたいくつかのサイトを調べているうち、英文だが、外国人(イタリア?)の英語なので、とても理解しやすいサイトを見つけてある。

 以前に見つけたところとは別のサイトだが、esp-idfの環境で、SPIFFSが出来たという報告である。沢山の感謝とお礼のレスポンス付きだ。これは間違いなく動いているようだ。喜び勇んでダウンロードする。

 順調に進むかと思われたが、そう簡単に問屋は許さなかった。今度も、ディレクトリパスが難しい。make menuconfigそのものが通らない。いくつかの関門を潜り抜け、menuconfigまで行ったが、今度は本番のmakeでビルドエラーが出る。残念!

 何かおかしい。インストールした場所が悪いのか。githubなので、clone先が所定のところにないと、正しく動かないようだ。余り深入りは避け、次の日、出勤した事務所のPCで最初からインストールしてみた。これが不思議、makeが通ったのである。

SPIFFS動作成功(9/8/2017)
 帰宅して、もう一度やり直す。やった。makeが通る。make flashで実際にファーム焼き込み。これもうまく行った。原因はやっぱりgitを展開するディレクトリの位置だったようだ。いやあ気難しい。

 まあ、あまりこれにこだわっていても仕方がない。先に進もう。それにしても単なるフラッシュだけの操作なのだけど、LチカとHelloWorldと同じように、延々とすべてのライブラリのコンパイルが続く。

Ws000032  testSPIFFS.cのソースコードをあらためて精読する。mainで各種の関数をテストし、それをコンソールに出力している。そんなに複雑ではない。これだけで動くようだ。何はともあれmake monitorでコンソールを動かしてみた。

 やった、それらしい出力が次から次に出力される。ディレクトリを増やしたり(mkdir)、ファイル一覧(ls)なども出来る。うむ、うまく動いているようだ。フラッシュファイルにアップロードする方法がまだわからないが、テスト環境には、フラッシュに入れたファイルイメージが残されており、何らかの方法でアップロードは出来るようだ。

 ここまで進むと先は見えてきた。ESP-IDFのサンプルソースにはHTTPサーバーのソースがあるので、このSPIFFSを、サーバーに合体させれば動く見通しがついた。どちらを母体にするか迷ったが、構造の複雑なサーバーのソースコードにSPIFFSの要素を組み込んでいく。その前に、HTTPサーバーを動かしておかないといけない。しかし、これが意外と難渋したのである。

やっとホームページが出せた。サンプルソースでは動かない(9/18/2017)
 サンプルがあるので、簡単にHTTPサーバーは動くかと思ったが、これがなかなかいうことを聞かない。いくつかあるHTTPサーバーのソースの一つをビルドしたが、ホームページ(index.html)を出すようなところが見当たらない(http_request_server)。

 やっていることは、どこからかのソケットを受けてそれをSTDOUT(コンソール)に表示するだけである。これはサーバーではないよね。クライアントがやることだ。少なくともesp-idfのサンプルソースesp-idf/examples/protocols/http_requestと、https_requestにあるソースには、リクエストしかなく、これでは動かない。

 困ったときはgoogle先生である。esp-idf http_server などのキーワードで検索を続けると、別のそれらしいソースコードが見つかった。ドイツの電子工作ショップのサイトで、ソースだけで説明記事に戻れないが、コードを読む限りでは、クライアントのリクエストに対してindex.htmlを返す部分がある。もうひとつタスクが必要のようだ(netconn_server)。

 半信半疑ながら、このソースに取り替えて、再度ビルドしてみる。よーし、OK! 簡単なindex.htmlが表示された。良かった。でも、なぜ本家のサンプルには、本来のHTTPサーバーの雛形がないのだろう。謎である。次はいよいよhtmlファイルのフラッシュファイル化に進む。

HTTPサーバーの解析に夢中になる(9/16/2017)
 フラッシュファイルを入れるため、サーバーのソースを読みふける。おおー、段々全体が見えてきた。嬉しい。いや勉強になる。これまで近づこうとしてなかなか機会のなかったソケットプログラムだ。lwipとか、nghttpとか、新しいプロトコルを知る。

 電子工作ではなくて、ウェブプログラミングで遊んでいる。この世界も複雑で奥が深い。HTTPサーバーの教科書が少ない。事務所の帰りにいつもの秋葉原書泉で参考書を探すが、自分が知りたい基礎の部分を解説したものはなかなか見つけられない。

 このesp-idfの開発環境にも大分慣れてきたが、それににしても、このフルビルドは何とかならないか。延々と必要もないモジュール群をコンパイルしていく。一旦コンポーネント(ライブラリ)が出来ると、あとは少し早くなるが、それまでは大変だ(まあ、モジュールを選択するのも大変なので、こういうやり方もあるか)。

 文字列の連結、文字列のサーチなどArduinoIDFにはあった機能をせっせと開発する。コーディングとしては楽しかったが、これらはすべてCの標準関数(string.h)にあることがわかって、お蔵入りした。完全な無駄足である。

SPIFFSでテキストファイルの送出は成功した(9/22/2017)
 画像表示は、読み込みのとき大きなバッファースペースが必要なので、まずは文字ベースでindex.htmlに埋め込む方法をテストする。これが結構難しい。どうも思ったようにhtmlに展開してくれない。

 それより問題なのは、nett_conn_serverというFreeRTOSのタスク上でSPIFFSを動かすとstack overflowでプログラムが落ちるのである。menuconfigなどでスタックサイズを広げるが改善されない。これもウェブで調べて解決方法が見つかった。タスクを起こす関数に、スタックサイズを指定するパラメーターがあったのだ。

  これを通常の3倍(6144バイト)まで広げてやっとstack overflowは止まった。しかし、それでもindex.htmlに思ったような文字列が出てこない。何回か試行錯誤するうち、重大な誤りをみつけた。

 文字列の長さを得るのに、sizeofを使っていたのだが、ポインターを使った文字列では、これがアドレスを収容するエリア(ここでは4バイト)になってしまうことに、だいぶ後になってから気づくというお粗末である。Esp32spiffs1

 しかも、関数の引数にすると呼ばれた先では、strlenでも文字数が正しく得られない。それやこれやで苦闘の結果、何とか出せたのだが、<object src=XXXXX />のタグでは、スクロールバーのようなものが出てしまう。目的は画像ファイルなので、道草を食いたくないのだが、テキストファイルの表示だけで四苦八苦である。

何と、もっと良い方法を見つけた。バイナリの埋め込み(9/24/2017)
 色々とウェブをさ迷ううち、SPIFFSではない、もっと楽な画像ファイルの表示方法があることを偶然つきとめた。いや情報は浴びるように摂っていれば良いことがあるという言葉どおりの快挙である。

 esp-idf esp32 webserverなどのキーワードで、調べているうち、スマホのきれいな画像のボタンでLEDをウェブから制御しているページを見つけた。

 ボタンがきれいなイラスト画像(pngファイル)である。へえー、サーバーでどこかのクラウドサーバーにリンクして画像を持ってきているのだろうかと、思っていたら、どうもそうではない。Ws000001 mainと同列にある、component.mkファイルにCOMPONET_EMBED_FILES:=でファイル名を定義すると、これをbinary dataとしてフラッシュに埋め込んでくれるというのだ。

 これはすごい。以前、AVRでやったことのある、フラッシュにバイナリーデータを埋め込むobjcopyと同じ手法である。埋め込んだ後、エントリーポイントを取得すれば、プログラムのなかでこのバイナリーデータを使うことが出来る。

 まだSPIFFSではjpegファイルまで進んでいないが、ファイルを読み込まなくても、外部参照だけでデータをとりこめる。しかもバッファーの長さを気にする必要もない(コンスタントデータなのでバッファーの長さは気にしないで良い)。

 これは試してみるしかない。早速、サイトの情報を頼りに、見よう見まねで、適当なjpegファイルをとりだし(SPIFFSスタックの中にあった画像)、component.mkファイルに設定し、ビルドしてみた。おーし、何のエラーも出ずビルドは終わった。

Esp32spiffs2  次はmake flashである。いつもより少し時間がかかるが無事終了した。jpegファイル40KB分だけ遅くなっているか。さあ、make monitorでサーバーを立ち上げる。

 おおー、やった。画像がホームページに出た。しかも早い!一瞬だ。嬉しくて何度もディスプレイの前でガッツポーズをする。ホームページそのものは、画像とテストメッセージ一行の何も意味もないページだが、このあとには無限の可能性が待っている。

SPIFFSでも画像ファイルの送出に成功。そう遅くにもならない(9/25/2017)
 勢いに乗って、SPIFFSでも画像が送れるかやってみる。このnetconn_serverというしかけが良く見えないので、バッファーサイズをどれくらいまで広げられるかわからない。これが、画像ファイルの読み込みを遅らせていた理由だが、もうそんなことは言っていられない。適当なサイズ(4KB)でneconn_write()を繰り返し発行することにする。

 恐らく、バイナリ埋め込みに比べれば遅くで使い物にならないかもしれないが、まずはやってみる。動かしてみた。おやあ、またstack overflowで止まる。祈る気持ちでスタックサイズを2048の3倍からさらに4倍の、8192まで上げて再度動かしてみる。

Esp32_spiffs3  よーし、動いた。そんなに遅くならない。esp-idfについているデバッグ用のメッセージにms単位のタイムスタンプがあるので、これで測ってみると、同じ画像で、埋め込みで平均62msが、SPIFFSだと108msだ。ブロックサイズを広げればもう少し早くなるかもしれない。

 とにかく、ESP32の画像付きサーバーの開発はこれで一段落した。胸を張ってブログに報告できる。

以下に、サーバーのソース一式をONE DRIVEで公開します。ディレクトリごとzipファイルにしたので、これをesp-idfのホームディレクトリに展開し、mainの直上のディレクトリでビルドすれば、バイナリデータを埋め込んでくれます。ソースには2種類のやりかたがコメントとして残っているので、適当に選んでください。WiFiの設定はmake menuconfigで行います。

ここをクリックしてONEDRIVEに行く

| | コメント (2) | トラックバック (0)

2017年9月 2日 (土)

ソフトI2Cはクロックストレッチまで手を出してあえなく沈没

 I2Cのスレーブライブラリの改訂が泥沼に入り込んだまま動けない。アナログの超音波距離計測センサーHC-SR04(以下SR04)を、電源3.3V、I2C化したブレークアウト基板を作ったところまでは良かったが、そのあと、計測を高速で動かそうとして、ソフトI2Cスレーブのプログラミングに大苦労し、気が付いたら一か月が経っていた。

 そもそも、このTiny85を使ったソフトI2Cのライブラリーは、もう2年も前に開発したもので、ソースコードまで公開している。今度の開発でいくつかの不具合が見つかったので、改訂版を出せばそれですむ話なのだが、せっかく再公開するのだから、もう少し機能を増やしておこうと欲を出したのが間違いの始まりだった。Dsc01170

 ソースコードをレビューしているうち、最初の版は、I2Cのマスター読み込みのストップコンディション検知が未実装だったことがわかった。ブログ記事では作ったことになっているが、ソースコードを読んでみると実装されていない。

 スレーブからマスターへの送信(マスター読み込み)の終了は、最後のデータバイトにマスターがNACK応答を返せば止まるので、ストップコンディションは不要と言えば不要である。しかし出来ていると書いてしまった手前、放置するわけにもいかなくなった。それにマスター書き込みの方は、リピートスタートまで(もちろんストップも)実装したのに、何となく落ち着きが悪い。

 そこで、これを追加しようと気楽にコードを加えたのだが、これがうまくいかない。出来上がったプログラムはどうやってもストップコンディションを受け付けないのである。マスターはストップコンディションを出しているはずなのにロジアナで見ると波形が出ていない。謎である。

 脱線につぐ脱線というのが、がた老AVR研究所の通例ではあるが、今回はどうもいけない。迷路に入りすぎだ。I2Cのスレーブ側のプログラムは、すべて割り込み駆動で、SR04を制御するバックグラウンドルーチンとは非同期で同時に動く。デバッグは一筋縄では行かない。

 こういう細かいことに興味のない読者の方々には申し訳ないが、実は所長は、こうした箱庭のような8ビットマイコンのマルチタスク的プログラミングが好きで、つい深入りしてしまう。ロジックアナライザーで全体の様子が手に取るように把握できるようになったので余計やめられなくなっている。

 以下は、この泥沼のようなプログラム開発の一か月の顛末である。しかも今回は撤退に次ぐ撤退の苦しい開発となった。まあ、こういうときもあると自分を慰めている。

懸案のI2C通信と計測の同時処理はあきらめる(8/6/2017)
 前回記事で、SR04のエコーと、I2C通信の共通変数(タイマーキャリーカウンター)を分離して、正しいデータが出たと喜んだのもつかの間、少し待ち時間を短くしていくとまたデータが不正確になってきた。どうも距離の計測値が低すぎるし、安定した値がでてこない。

 ソースコードをもう一度入念に調べる。すると、共用していないはずのタイマールーチンに続々とおかしな使い方が見えてきた。要するに被っていたのはキャリー変数だけではなかったのである。

 まず、肝心のタイマーのおおもとのレジスターTCNT0をI2Cが始まるたびに0に戻していた。最大でも0.26ms(8ビットのオーバーフロー)、音速にして5センチ余りの誤差は、今度の用途(人感センサー)を考えると、そう大きな問題ではないが正確でなくなることには間違いない。Ws000029 さらに、I2Cの通信が終わるたびに、タイマーのオーバーフロー割り込みを止めてしまっていることが判明した。タイマーそのものは動いていても、8ビットタイマーのキャリーが増えていかないのは致命的だ。これが、ときどき距離が不正確になる犯人であった。

 この一週間、デバッグに奔走していた。調べれば調べるほど、エコー時間計測とI2C通信の非同期処理は不可能であることがわかってきた。要するにタイマーが一つしかないところで、タイムアウトと計測を一緒にやろうというのが無理筋だったのである。

 とにかく、こんなにリソースを共用していたらマルチタスクもあったものではない。計測期間中にI2C通信を行うソフトの開発は中止することにした。今回の無駄足は疲労感が強い。もっと早く気が付くべき基本のところを忘れて、深入りしてしまったからだ。 

 当初の方式、センサーのエコーを少し長めに待ち(SR04の最大エコー30ms程度)、データを読み込む方式に戻した。これでも100ms以内で連続して計測が出来る。まあ、人感センサーならこの程度で十分だろう。

マスター読み込みのストップコンディション検知にチャレンジ(8/16/2017)
 エコー期間中にI2Cを動かして計測間隔を短縮しようという目論見は完全にはずれた。意気込んでプログラミングをしようと振り上げた拳(こぶし)の行き先がない。この高ぶった気分を鎮めるために、何か手を動かさないと納まりがつかなくなってしまった。

 そこで、未実装の「マスター読み込み」シーケンスのストップコンディションの検知機能を開発することにした。しかし、これも難儀したのである。しかけは、「マスター書き込み」と同じように最初のデータビットのクロック(SCL)立ち上がり区間で、データライン(SDA)を監視して、ストップコンディションを判定する。

 「マスター書き込み」では、スタートコンディション(これはリピートスタート)もストップコンディションも順調に検知し、動作も確認している。簡単に動くだろうと気楽にコーディングしたのだが、全く動かない。かえって、全体の動作が不安定になってしまった。Dsc01195

 いつものロジックアナライザーにプローブ点を増やして解析する。波形を見ると、マスターがストップコンディションを実行しているのにSDAが上がっていない。つまりストップコンディションが発生していない状態であることが分かった。謎である。

 メモに何枚もタイミングチャートを描いて調べていく。ひとつづつの動きを詳細に確認していくと、驚くべき事実が浮かび上がってきた。「マスター書き込み」なら容易に出来る処理は、「マスター読み込み」では不可能ではないかということである。

ソフトでストップコンディションは作れない(8/20/2017)
 誤解を招かないように補足すれば、ソフトウエアでは実現できないということである。ハードウエアならSCLがHIGHのときのSDAの動きを監視する機構を加えれば良いので問題はない。しかし、ソフトでは同時処理が出来ないので、「マスター読み込み」ではSCLクロックが来る前に、スレーブは次に送るべきビット値を用意してSDAに乗せておかなければならない。

 もし、その値がLOW(0)のときは、ストップコンディションを阻止してしまい、スレーブ側ではそれを検知できないということになる。そもそも、「マスター読み込み」はスレーブ側がSDAラインを上下させてデータをマスターに送る。スレーブがSDAを下げてしまうと、マスターはこれをHIGHにすることが出来ない。

 元から不可能な機能を作ろうと、もがいていたことになる。ack/nackビットを受け取って次のデータの第一ビットの間中SDAラインをスレーブは占有してしまうので、スタート/ストップコンディションをマスターが出せないのである。「マスター書き込み」では、SDAラインはマスターが制御するので問題ない。

 とにかく、「マスター読み込み」のとき、ソフトでスレーブ側のストップコンディション検知は実装できないことが明らかになった。この2週間余りの作業は全く無意味なものになった。お馬鹿としか言いようがない。エコー期間のI2C騒動と、このストップコンディション開発を撤退するにあたり、反省をこめて何が悪かったのかまとめてみる。

教訓:

  •  一度に複数の機能をデバッグしてはいけない。どれが原因か特定するのが難しい(欲張るな)。プログラムをなめてかかって、いくつかの機能をまとめてコーディングしていた。原因が見つけにくいうえに、単独でバグをつぶしていくより、結果として余計な時間がかかっている。
  • 基本的な機能から確認していかないと何をやっているのかわからなくなる(急がば回れ)原理を理解せずに、小手先のコーディングが多すぎた。タイミングチャートをいくら詳しく描いて、コードを工夫しても、I2Cの基本を忘れていたら何にもならない。
  • 思い込みは可能な限り見直す(これは定数だから変わらないと思い込むな)わかっているはずなのに、この思い込みというやつは魔物である。すべてを疑うという視点をなくさないようにと気を配っていても、つい先のことに気を取られて基本部分を忘れがちになる。

 やれやれ、現役時代、さんざん後輩に言い聞かせてきた原則ばかりである。このブログにも偉そうに何度も同じようなことを書いてきた。それがこのざまである。お恥ずかしい。まさしくプログラムは考えたようには動かない、書いたようにしか動かない、である。

 この記事はあとから書いているので、まだ冷静な話になっているが、デバッグの最中は暗中模索、ロジアナの前で悪戦苦闘であった。もうやめようかと何度も思った。Tiny85のファーム書き換えはSR04を外す必要があり、ビルドを繰り返しているうち、ブレッドボードの接触不良で動作が不安定になったりする。散々である。

 ただ、ロジアナの威力は今さらながらすごいと感動した。プローブの数を増やしていけば、色々な所の可視化が可能になる。今回も、マスター側からもプローブを出せることに気づいたのは大きかった。これによって、マスター側が正常に動いていることを確認でき、自分の愚かな思い込みに気づくことが出来たからだ。

超音波センサーユニットの配線図とライブラリソースコードの再公開(8/19/2017)
 とにかく開発は一段落した。ライブラリーも安定して、これまでのように時々、0値が連続したり、異常値が出たりすることはなくなった。思い当たる不具合は、これまでのところ全部つぶした。

 最後までわからなかった偶に起きるデータ異常値は、ロジアナの波形を精密に調べなおして、SCL割り込みがタイマー割り込み(オーバーフロー)によって遅れ、その結果、SCLクロックが外れているのを発見した。I2cslaveoverhead

 タイミングによっては、これがスタート/ストップコンディションとみなされ、そのあとのデータが欠落する。Tiny85のCPUクロックは8MHzで、内蔵CRクロックなのでこれ以上は上げられない。SCL割り込みのオーバーヘッドは8μs内外で、クロックが40Khz(半サイクル12.5μs)のI2Cでは、ギリギリである。

 I2Cはこれ以上遅くしたくないので、タイムアウト用のタイマーの割り込みを起こさないようにするしかない。プリスケールを8から64に上げ、メッセージが16文字以内なら割り込みが起きないようにした。テストの結果、20文字以上送っても、数値の乱れはなくなった(必ず起きるわけではない)。

 お約束のソースコードと配線図を掲載する。I2Cライブラリーそのものは上記のようにすべて改善に失敗したが、マスター側とSR04制御部には若干の機能を追加してある。
 以下に例によってZIPで固めたソースライブラリ、readme.txt、配線図ファイル(.bs3)を置きます。 
   「I2CslaveSet_2.zip」をダウンロード

 コマンドの解説など詳しくはreadme.txtに説明した。以前の公開したライブラリーはうまく動かないところもあるので、この版のライブラリを使われることをお勧めする(当該ブログ記事にも注記)。

I2CスレーブライブラリーとSR04測定ルーチンの改善点(8/21/2017)
 テスト用の親機のTiny861とのペアで追加した機能と、修正した不具合の部分を以下にまとめておく。

I2cslave_85_2

追加した機能:
(1)    連続距離測定
SR04の距離測定が0.2秒間隔で開始され、UARTコンソールに測定値が1行づつ表示される。人感センサーなどで機器を動かしながら最適位置を見つけるのに便利。リターンキーを押すことで測定は中止される。

(2)    スレーブ側からの独自データ送出
サンプルとして、スレーブ側のソフトのバージョン番号をフラッシュに定義し、それを表示させる。I2C化するディバイスのレジスター値などを表示するのに使える。

(3)    バッファーデータの16進データ表示
スレーブの持つ送受信バッファー(36バイト)を全部表示する。本来はデバッグ用。

修正した不具合
(1)    マスター読み込みでのスレーブ側の不正データ送信のバグ修正
タイマー割り込みのオーバーヘッドで、送ったデータが欠落したり、文字化けが起きていたのを修正。

(2)    スレーブ側の連続データ送出でのバグ修正
マスターから送ったデータの戻しでバッファーサイズ分を全部表示できなかったのを修正。

 いやいや、長い間かかったけれど、何とか納まった。ウェブで見る限り、AVRマイコンでソフトI2Cスレーブの開発例は殆どない。あっても、すべてUSIというAVR独自のハードインターフェースを使ったもので、この開発のようにGPIOだけで作った例はひとつもない(自分で探した限り)。

 ちょっと鼻が高いのだが、これは完全な自己満足の世界である。ということで、さらに挑戦しようと、欲を出して恥の上塗りをすることになった。それが、次に紹介するクロックストレッチの実装である。まあ、笑わずに聞いてください。

クロックストレッチ実装の野望、もろくも砕ける(8/23/2017)
 I2Cは、原則、すべての通信の主導権をマスターが握っており、マスターの出すクロック(SCL)に従って複数のスレーブが動作する。これに対し、クロックストレッチとは、I2C通信でスレーブが、マスターを待たせる唯一の手段である。

 スレーブの処理速度が遅く、マスターの要求に応えられないときなどに使う。SCLラインをいずれかのスレーブがLOW(0)に落とすことによって、マスターはSCLの発行を止め、スレーブが解放(HIGH)にすることで再開する。
実装は簡単に見える。マスター側で、クロックライン(SCL)を監視していて、誰か(スレーブの誰か)がSCLをLOW(0)に落とせば(いわゆるワイアードNOR)、それがHIGHになるまで通信を止める(クロックパルスを延期する)。

 スレーブ側はもっと簡単である。必要な時にSCLをLOWにしてしまえば、すべての交信はストップする。また、HIGHに戻せば、マスター側が待っているから再開する(はず)。鼻歌交じりで、双方をコーディングし、勇んでテストに入った。これが地獄の始まりとは露知らず。

 テストの前は、クロックストレッチが実際に行われているかの実測のため、タイマーを再整備したりして余裕だったのだが、実際には全く動かなかった。スレーブでクロックストレッチをかけた途端、すべての反応は止まる。ハングアップである。

 ロジアナで様子を見る。通信シーケンスは、スレーブがクロックストレッチをかけたとみられるところから、見事にSCLがLOWになったまま、最後まで動かない。あれ、おかしい。マスターが待つのはともかく、スレーブがどうして引きすられる?

 スレーブには1秒タイムアウトが設けてあって、I2Cの通信が1秒以内に終わらないと通信を終了させて初期状態にもどるようになっているはずだ。

 あっあっあー、だめだ。スレーブ側の割り込みプログラムのなかで、SCLがHIGHになるのを待っている。これではバックグラウンドのコマンドでいくらSCLを元に戻そうにも、永遠にバックグラウンド側に戻ってこない。いわゆるデッドロックである。

 悪あがきで、多重割り込みでスレーブ側に短いタイムアウトを設け、別のところで待つようなしかけも考えた。avr-libcには多重割り込みを認めるマクロはあるが(リニアPCMプレーヤーで使用)、今度の場合は、バックグラウンドに戻っても、スレーブの割り込みプログラムに帰れないので意味がない。

 クロックストレッチをスレーブ側が要求するとき、あらかじめ割り込みルーチンの進入を止めておくという姑息な方法もあるが、マスター側の通信要求がいつ発生するか分からないときに、スレーブを止めるのは著しく可用性を失う。

 要するに、ハードでのみ実現できる機能で、そもそもソフトでやろうというのが無謀だったのだ。クロックストレッチという誰も実現していない機能を実現してやろうという野望は、もろくも消えた。

 やれやれ、三度にわたる敗退である。暫くは立ち上がれそうにない。ただ、この電子工作は、定年後の重要なライフワークのひとつになっており、もう今さら止めるわけにはいかない。

 今、考えている次のテーマは、ESP32で、課題になっていたSPIFFS(フラッシュメモリを使ったディスクシステム)だ。フォーラムなどを見ていると、ESP-IDFという、Arduinoとは違うプラットホームで動き始めたようだ。これを試すのも悪くないかと思っている。

| | コメント (2) | トラックバック (0)

2017年7月26日 (水)

オシロのテストどころかソフト開発で大はまり

 新しいオシロで色々テストするつもりが、久しぶりにソフトのデバッグにはまってそれどころではなかった。超音波距離センサーSR04のI2C化の最中に、avr-libcのバグらしいもの(と最初は確信)に遭遇して意気込んでいたのだが、何のことはない、わかってみたら全てこちらのミスと判明した。いやあ情けない。まあ、それまでのいきさつを最後まで聞いてください。

新しいオシロは機能がありすぎて持て余し気味(6/30/2017)

 ほぼ10年ぶりにオシロ(帯域200MhzのSiglent SDS1202X-E)を新調して、埃をかぶっていた自作のファンクションジェネレーター(以降FG)を棚から持ち出し、FFTとか、シーケンスモードとかの新機能を試そうと、張り切ってオシロに向かった。

Dsc01176 ただし、まだ操作に慣れていないので簡単な測定でも四苦八苦である。トリガーのかけ方がいまいち理解できない。スロープとエッジの違いも良くわからない。FGで矩形波を出し、FFT(高速フーリエ解析)の波形を見るが、思っているような形にはならない。だいたいアナログ機器の調整ならともかく、単にFFTでスペクトル波形を出しても、「で、それがどうした」と言われたら黙るしかない。

  というので仕事の帰り、秋葉原の書泉ブックセンターに寄ってオシロの参考書を探した。入門書はいくつかあるが、中上級のものはほとんどない。技術の進歩が激しいので単行本になりにくいのだろう。雑誌の特集を集めたムック本が2種見つかったが、ひとつはすでに初代のオシロの時に買ったものだった。しかたがないので残りの一冊も買う。Dsc01175

 参考書の中のオシロはメーカーが違うので、パネル面や用語が手持ちのものとかなり異なる。まあ基本のところは大体似たような機能なので迷わないが、ちょっと細かくなってくるとわからなくなる。本来はこの会社(Siglent)のマニュアルを探すべきなのだろうが、日本語のものはないし、とっつきにくい。

 ウェブには何故かこういう紹介サイトもある。しかし、情けないことに半分も理解できない。うーむ、難しいな。知らなければならないことが山ほどある。ここは基本的なやり方を参考書の最初から読みこんで少しづつ理解していくしか方法はないようだ。

 前記事にあるように測定の時間的な範囲が広がったのはとても収穫だが、アナログ波形を見なければ進まない工作は現在していない。そう、宝の持ち腐れと言っても良い。使い道が見いだせないというのはつらいものだ。

センサーのブレークアウト基板を作る。久しぶりハンダ付けが楽しい(7/4/2017)
 いうことで、これまでの工作の続きをすることにした。ブレッドボードに組んでいた超音波距離センサーHC-SR04のブレークアウト基板の制作である。入力を電源3.3VとI2Cだけの結線にしぼり、RaspiやESP8266などの最近のCPUと簡単に接続できるようにする。

 手持ちのケース(タカチのSW70 75X50X35)に全体が入ることを考慮して、秋月のC基板を少し小さくする(72X40)。ここにSR04とTiny85、それに例のストロベリーリナックスのDC-DCコンバーター、秋月で入手したI2C用のレベルシフター(FXMA2102 ¥200)をレイアウトする。Dsc01164

 過去のブログ記事を見てみたら、本格的なアートワークをやる汎用基板でのハンダ付けは数年ぶりのことだ。久しぶりのアートワークそのものが楽しい。ここでの醍醐味は、複雑だった引き回しが部品の位置を少し変えるだけで簡単になることだ。

 パズルを解くのと同じである。何度もアートワークをメモに描きなおし頭を捻る。配線を交叉させないというルールは守れないかなと諦めたころ、ピンヘッダーの方向を逆にするときれいに解決したりする。鬼の子をとったような気分である。実際の工作前にもこれだけ楽しめる。

 アートワークも完成したので、部品を揃えてハンダ付けの工程に入る。ハンダ付けは一気にやらない。楽しみながら少しづつやる。実体顕微鏡を買っておいてよかった。最近TVのCMでメガネにかける拡大鏡を見かけるが、これは精々1.6倍程度で、倍率20倍のこの顕微鏡にはかなわない。ただ、顕微鏡は慣れないと対象物に絞り込むのが一苦労だ。Dsc01171

 配線作業は進む。サインペンでアートワークにハンダ付けした部分を塗りながら、出来上がっていく基板を矯めつ眇めつ(ためつすがめつ)眺めて感慨にふける。考えてみたら、この方式を始めて、そろそろ10年。このパズルのような、UEW線を交差させないアートワークと、この細かいはんだ付けの絶妙な組み合わせが、心をひきつけてやまない。

 自分がこの小宇宙の創造神である。満足感、達成感は、悪いけれどArduinoやRaspiなどでの工作とは比較にならない、至福の時間である。この基板にI2Cスレーブライブラリーを使ったSR04のインターフェースソフトを合わせて記事にしたら喜んでもらえるかもしれない。期待が膨らむ。

使えないHC-SR04があった。ブレークアウト基板はミスなし(7/6/2017)
 サインペンで線を塗るところがなくなった。完成である。ニチアツのコネクターを奢って、圧接ペンチでソケットに入れるピンを用意する(久しぶりなので1ピン失敗した)。SR04は背の高さを低くするため、センサーのピンソケットを平型に換えてある(オリジナルはL型)。テストに入る。Dsc01172

 最初、動かなくてあせったが、沢山あるセンサーユニットSR04のうち、選りによってトラブルのある方を使っていたことがわかり、あわてて正常な方にピンを付け直す。さあこれでどうだ、電源ON。良かった。ブレッドボード上の親機(Tiny861)のUARTコンソールに、距離が表示された。

 やった、やった。基板のハンダ付けは完全試合だった。腕はまだ落ちていないぞ。SR04距離センサーは、このあいだ秋月で同種のセンサー(US-015)を買ってある。ついでにこれも平型ピンに取り替えてテストする。これも問題なく動いた。 

 これで当研究所には、なんと合わせて5つもの距離センサーが揃ったことになった。アマゾンでは2つも買ってあった。このうち正常に動くのは3つ。具合が悪いのは、アマゾンの一つと秋月で最初に買ったもの合わせて2つである。Dsc01166

 ハードは一応、これで一段落である。用途は現在、階段の照明切り替えに使っている赤外線人感センサーの代替を考えているが、人間の近接を距離によってどうやって検知するかロジックが決まっていない。これからテストをして決めていくことになる。

親機のコマンド新設。距離が安定しない。DC-DCコンバーターが怪しいか(7/8/2017)
 SR04ブレークアウト基板のソフトの整備に入る。これまでにI2Cスレーブそのもののソフトは、Tiny85に組み込み、かなり作りこんだライブラリーが完成してコードも公開済みである。

 マスター書き込みでデータを送った後、ストップコンディションを送らずに、続けてスタートコンディションが来ても、これに対応する機能(リピートスタート)や、書き込み/読み込み双方のストップコンディションの対応、タイムアウトなど、I2Cスレーブとしてはほぼ満足できる機能がライブラリーとして実現している。

 ここはもう余り手を加える必要はない。残るは、このブレークアウト基板が部品として使えるように、親機のTiny861に必要なUARTコマンドを追加して、汎用的なソフト環境を整備することである。Dsc01169

 まずは、連続して測定した距離を表示するコマンドを新設する。これは先のロジックを作るのにも必要な機能で、人が近づいたときどう距離が変化していくか連続的に調べるためである。作るのは簡単で、SR04の測定を開始するコマンドと、SR04のエコーを調べるコマンドを連続的に実行すれば良い。停止は、コンソールからのリターンキーである。

 簡単に出来たので、三脚にブレークアウト基板を固定して測定を開始する。順調にデータが出始めた。ところが、出力データが安定しないのである。階段の下から上部に向けて超音波を発射し、最上部に人が立てば、距離が変化して照明などの回路をONする理屈なのだが、無人なのに距離が安定しない。

 壁に囲まれた閉空間なので反射が多いからか、また、空気中の微粒子からの反射か、突然距離が短くなる。安定した距離が続かない。困った。このままでは、実用的な目的を果たせない。

DC-DCコンバーターを調べているうちにレベルシフターを壊したか(7/12/2017)
 三脚に固定しているのに、距離センサーが不安定な原因は、どうもDC-DCコンバーターのせいではないかという疑いがでてきた。埃が原因というのも考えにくい。DC-DCコンバーターはSR04にごく近い所に固定されている。疑うところはこれくらいしかない。

 というので、5Vの昇圧コンバーターの動作を停止し、別のスイッチング電源からコードを引き込んでテストした。最初、これで安定したので、DC-DCコンバーターの影響に間違いないと思っていたのだが、少し長い間測っていると、やっぱり別電源でも測定値の揺らぎは発生した。がっかりである。

 障害物がまわりにあるときは、測定値が不安定になってしまうようである。気流の動きで反射した音波が遅れて到着し距離が不当に伸びるのかもしれない(ロジックは良くわからない)。そうこうするうちに、突然センサーが動かなくなった。I2Cの通信自体がNO Responseである。

 何度も確認したが、接触不良ではない。トラブルシューティングの原則通り、マルチメーターで各部の電圧をひとつひとつ調べていく。電圧も問題なかった。DC-DCコンバーターも5Vを作っている。

 次はI2Cだ。まだ使い慣れていないがオシロでI2Cの波形をチェックする。まず親機。大丈夫だ。次はスレーブI2CのTiny85、おやあ、クロックがおかしい。パルスは受けているようだが、0になっていない(負論理なのでactiveにならない)。

 I2Cのスレーブはクロックは受信するだけである。異電圧間をつなぐレベルシフター(FXMA2102)が正しく伝えていないのではないか。

新しいオシロがお手柄。すぐにレベルシフター不調を表示(7/13/2017)
 オシロの波形によれば、I2C信号がレベルシフターを介するところでクロックのパルスが痕跡だけになる。Tiny85のUARTは動くし、親機も正常にI2C信号を出している。配線でおかしなところもない。これはレベルシフターICが壊れたとみるのが順当なところだろう。

 この実験中、DC-DCコンバーターをはずして、5Vを別の電源アダプターなどで供給した。何度かやっているうちに逆差したのかもしれない。Tiny85などのDIP製品は逆差しに案外耐えるが、こういうSMD(表面実装)部品は一瞬でも壊れる可能性がある。

 幸い、レベルシフター(FXMA2102)は予備が買ってあった(こういうときのため)。後ろ向きの仕事で気が進まないけれど、交換してみるしかない。低温ハンダで基板とピンヘッダーをはずし(ピンヘッダーはハンダ付けしてしまった)、チップだけ載せ換えた。

 電源を入れ直す。SR04基板は問題なく動き始めた。I2Cの信号もちゃんと見える。やっぱりレベルシフターが死んでいたのだ。いや、レベルシフターを失ったのは残念だけれど、新しいオシロが手柄を立ててくれた。自らを慰める。

 距離が時々違う値を示す現象は、照射する方向を選ぶと殆どなくなることがわかった。反射面の形によって値が不安定になるようである。人感センサーとしては、垂直方向(音波の方向)で使うのは無理な気がする。水平方向(音波を横切る)なら100%検知できるのだが。

一進一退のデバッグ。同時処理でこける。avr-libcがおかしい?(7/16/2017)
  SR04を動かす分のソフト開発は大体終わった。SR04では使わない連続データの入出力機能などは開発済みだ。考えられる機能はほぼ実現したが、ただひとつ気になっているところがある。

 連続測定のとき、SR04のエコーが返ってくるまで余裕を見て50msの待ち時間を設けていることだ。用途から言って、そう短い測定間隔が必要なわけではない。実用上は全く問題ないのだが、距離が短くても、待ち時間は変わらない。そのあいだ何もしないというのも芸のない話だ。 Dsc01173_2

 この間隔を短くするのは、超音波のエコーが返ってくるまでに、親機の方から、エコーが返ってきたがどうかを調べるコマンドを送れば良い。親機はそのフラグを見て、バッファーに収容されたデータを読む。簡単なロジックだ。

 トリガーをSR04にかけるまえに、フラグを0にし、帰ってきたらこれを1にする。親機は適宜マスター読み込み宣言でこのフラグを読み取って1になるのを待つ。造作のない話なのだが、これがつまづきの始まりだった。どうにもうまく動かないのである。

 何故かフラグが1になったあとの計測データがでたらめになる。計測が割り込みを受けている間にデータが不正になるのである。慌ててAVRの参考文献を調べるが、AVRと、avr-libcは基本的にはリエントラント(複数のタスクを受け入れる)で、同じプログラムに複数のスレッドが通ることを許している。Ws000027

 これまでにこうしたプログラムはいくつか作り、何の問題なく動いている。リニアPCMプレーヤーなどは、DACの音声発生、SDカードの読み込み、LCDの進捗表示と3段のマルチタスクで動いている。

 勿論、リエントラントといっても共通のグローバル変数や、printfなどの標準関数はリエントラントには動かない。しかし、I2CとSR04の計測ルーチンは全く無関係だ(とこのときは確信していた)。だから問題なく動くはずなのだが、現実にはデータが汚されている。ハングするならともかくまともに戻って動くのが気に入らない。

 満を持してロジアナを出動させる(オシロでは無理)。I2Cとエコー、実際にデータをセットするプロセスにプローブを入れ、状況を見る。確かに、エコー期間の時にI2Cが動くとデータが不正になる。共通リソースもないのにどうしてこんなことが起きるのだろう。

情けない。とんでもない思い込みだった。立派に共通変数が被っていた(7/23/2017)
 このブログは原因がわかってから書いている。原因が解明される前のメモを今読み返しているが、いつものデバッグのときと同じで、なぜこれに気が付かなかったのだろうと感心するほど、思い込みというのは恐ろしい。 Ws000028

 I2Cの割り込みと、計測ルーチンとは全く独立していると完全に思い込んでいるから、最初は、もしかしたらavr-libcの不具合とか、もっと別なことが原因ではないかと思っていた。そのあいだに以下のような副次的なバグまで発見された。

(1)    親機から子機(スレーブ)のデータを読み込むのに、いちいちコマンドを送っていたが、そんなことをせずにマスター読み込み宣言で自由にデータが読めることがわかった。SR04のトリガーをかけてからの動作をひとつ省略した。出来る限り競合を避けるため。
 ->全く効果なし 

(2)    データをマスターに送る時、スレーブのバッファーに各ビットにひとつだけ1 の立ったマスクビットをANDしてバッファーを壊していた。データを送り終えると、元のバッファーデータはALLゼロになる。つまり、一旦送ったデータの再送が出来ていなかった。 
->これも特段の変化なし。データの再利用はしていなかった。

 完全な迷路にはまっていた。I2Cとエコーロジックは無関係だと思っているから、割り込みのときにレジスターなどが破壊されて値が不正になるのではとも考え、測定部分が関数になっていたので直接にコーディングしなおしたりした。もちろん変わりはなかった。ほぼこれで一週間悩んでいた。

 それが見るともなくソースコードを見ているとき、ふと気になるところが見つかった。スレーブのソフトI2Cは先方からの想定したビット列が来ない時は、ハングアップを避けるため1秒程度のタイムアウトを設けて、通信自体をリセットするようになっている。

 このタイムアウトのメッセージに、"No_Echo or Timeout..."というところがある。ちょっと待て、このNo Echoというのはどういうことだ。あっあっあー、何ということだ。このタイマーのキャリーを記録する変数をSR04のエコー期間を測定するときにも使っているではないか。

 たとえプログラムがリエントラントでも、変数を共通にしていては駄目になるのは当たり前だ。I2Cは通信開始時に必ずこの変数を0に戻す。これで、これまでに測っていたエコーのキャリー変数は0に戻り値はでたらめになる。あーあ、何というお馬鹿なプログラム。

 この修正は極めて簡単である。キャリー変数を、I2Cのタイムアウト用と、エコー測定用のものを分けて定義するだけだ。これで、どれだけエコー期間にI2Cが被っても正常な値を表示するようになったのは当然のことである。

 やれやれ、長い間かかった。思い込みというのは恐ろしい。「すべてのものを疑え」というデバッグの格言をかみしめる。 配線図や、コードの公開は、今ちょっとショックが大きすぎて作業する気力が生まれない。公開は次回以降としたい。

| | コメント (4) | トラックバック (0)

2017年6月29日 (木)

超音波方式の人感センサーI2C化と新しいオシロ

 PCの横で超音波距離センサーHC-SR04がブレッドボード上に残されたままになっている。他の電子部品に比べると特徴的な形をしているので何かと目立つ。ブログを調べてみたら、このセンサーにはまっていたのはもう2年も前のことで(2015/7/28)、そのあいだ放置したままということになる。Dsc01163

 ブログによると、このあとこの距離計測センサーをI2Cでつなごうとして、AVRの8ピンプロセッサーTiny85を使ってソフトのI2Cスレーブライブラリーを苦労して開発した。ソースコードをブログに上げたのは良かったのだが、そのあとは力が抜けてそのままになっている。

 このセンサーはアナログで動作電圧は5V、距離をパルス時間幅で返してくる。Edisonやesp8266などの3.3Vベースの32ビットプロセッサーとは電圧が違うし、それよりもプロセッサーにOSが入っていたりWiFiなどの割り込みが起きると、こうしたアナログのパルス幅の正確な時間は測れない。 

 そういうことでI2C化を始めたのだが、工作は全然別の方向に迷走したままになっている。そういえば、秋月で異電圧間のI2CをつなぐICも買ってあったのに部品箱の不良在庫になっている。Raspi3の電源問題も一段落したので、このあたりを次のテーマにすることにした。

 HC-SR04のブレークアウト基板(Vccは3V)をつくる。I2CスレーブのTiny85と3.3->5Vコンバーターをつけ、外部へは3.3V入力とGND、それにI2CのSDA、SCLの4本のケーブルをつけて、32ビット機器に簡単に接続できるようにする。

 親機はEdisonはもはや重いので、esp8266あたりを想定する。アプリケーションは、人が近づいたら反応する人感センサーにしようと思う。現在の階段のセンサーは焦電型で結構、反応が微妙で調整が難しい。距離測定の超音波なら、扉を開けるだけで反応するはずだ。

これまでの工作の再現だけで2日を要した(6/19/2017)
 裸になっていたSR04とTiny85を取り出して、ミニブレッドボードに移し替え、ブレークアウト基板のテストベンチをつくる。これまでのブログ記事を参考に(もうこれなしでは生きていけない)、もういちど配線をし直す。Tiny861の親機の方はまだブレッドボード上に生き残っていた。Dsc01157

 UARTを2つつないで意気揚々とテストに入った。しかし動かない。親機は動いたようだが、子機のTiny85は UARTにWelcomeメッセージは出るが、反応が全くない。親機からコマンドを送っても「そんな機械はない」と門前払いだ。

 接続を確かめる。プルアップ抵抗が隣のピンに入っているのを見つけた。最近は目が悪くなって良く間違える。さあ、どうだ。駄目だ。依然として動かない。しようがない。オシロを取り出す。なにー、ちゃんとI2Cの波形が見えるではないか。それでも動かないとはどういうことだ。

 暫く大騒ぎしていたが、落ち着いて配線を見直し、間違いを見つけた。要するにジャンパーコードの接続ミスだった。SDAとSCLが逆さまになっている。Tiny85と親機のTiny861の間のピンが揃っているかだけに気をとられ、ピンそのものが逆だったというお粗末である。情けない。Ws000022

 つまらない配線ミスで時間をとられたが、完動した。次はこのSR04のブレークアウト基板のソフト仕様である。どの程度の独立性を持たせるかで、基板ハードの仕様に影響が出る。何から何まで、例えば、音速の補正をコマンドで修正できるようにしておけば、ファーム書き換えのISPピンソケットはいらないかもしれない。しかしそれも面倒だ。

 実装するDC-DCコンバーターを何にするかも迷うところだ。部品箱を久しぶりに整理すると、5コ以上のDC-DCコンバーター基板が出てきた。1V以下でLEDをつけるやつ(これは今回は使えない)やら、表面実装にこだわったFP6291のもの(2つもある)、昔のHT7750など、自作品だけで沢山ある。

急にオシロが欲しくなって衝動的に発注(6/21/2017)
  そのうち、オシロで半分つぶれかかったI2Cの波形(これで良くデータが通ると感心)を見ていて、突然、これまで我慢していたオシロに対する物欲が沸き起こった。 波形がお粗末なのはオシロのせいではないが、この物欲というやつは、「ときめき」と同じでどうも理由が明確ではない。Dsc01155

 数年前こちらに良くコメントを寄せてくれる、ばんとさんにオシロを勧めたとき、自分も新しいオシロが欲しくなったことがある。このときは、使う機会が少なかったので、やっとのことで我慢した。

 当研究所がオシロを買ったのは、もう9年も前の話である。帯域60MhzのOWON製(PDS6062T)で、当時は10万円近くした(¥79,800)。買ったときは、清水の舞台から飛び降りる気分だとブログにはある。

 オシロの効果は抜群で、PCMプレーヤーのバッファーアンダーランを一発で発見したり大活躍をしたこともあるが、単純なトリガーしか選べないことや、蓄積データ量が少ないので大したことは調べられず次第に使われることが少なくなった。

 まあアナログ工作は殆どやらないので、それほど大きな不満はない。ちょっと複雑になればロジアナを引っ張り出せば良い。 オシロは今度の工作のように、動きを確認するだけに使われていた。必要性を強く感じることはなかったのである。

 このあと、低価格帯のオシロは、さらに安くなって中華のオシロは帯域100Mhzが3万円台になった(ばんとさんに勧めたころ)。中華製も評判は悪くなさそうだったが、強いニーズがなかったことがあって、オシロ熱はそれほど高くならず、その後は余り調査していない。

 あらためて調べてみると驚いた。さらに低価格化が進んでいる。少し前までは高級オシロにしかなかったフォスファー機能(アナログオシロのように繰り返し波形を色分けしてくれる)のついたものが、10万以下で手に入る。

 調べている間に、狙いをつけたのが、SiglentというシンセンのメーカーのSDS1202X-Eというオシロである。帯域が200MHz、メモリが14 Megaポイント。フォスファー付きで、この-EというサフィックスはUART、I2C、SPIなどのレコードの解析もできるシリアルデコーダーが付いている最新バージョンである。Ws000023

 ひところなら確実に100万以上はした商品ランクである。価格が悩ましい。日本で買えば(アマゾンとか楽天)10万近くするのだが、Alibabaなどの中華サイトでは、$380、何と4万円そこそこで売っている。にわかには信じられない安さだ。

 今これがないと進めないようなプロジェクトはないが、欲しいという欲望に勝てなくなった。しかも5万円以下で、これまで想像もしていなかった高性能のオシロが手に入るのだ。ここ数年は、余り電子工作に金をかけていない。少しくらいは良いだろう。

 中華サイトの買い物はリスクが大きいが、日本のサイトの半額以下というのは強烈な魅力だ。何しろ所長は「破格の安値」というのに弱いのである。ウェブサイトの珍妙な日本語の広告画面を何度も見ては迷っていたが、抵抗できず、ついポチってしまった。相手は、AliExpressである。

DCDCコンバーターの電源でSR04が動かない(6/24/2017)
 注文はしたけれど、到着まで10日はかかりそうなので、SR04のブレークアウト基板制作を続けた。次の課題はDC-DCコンバーターのテストである。

 久しぶりに秋葉原で買い物をした。自作のDC-DCコンバーターは、殆どが9 V以上の昇圧コンバーターで、5Vに上げるコンバーターにするため、秋月電子で面実装の半固定抵抗を入手するためである。

 面実装の基板の修正はとても難しい。例の低温ハンダで部品をはずすのは簡単だが、この自作のDC-DCコンバーター基板(FP6291)は、最初のバージョンではんだ付けに大苦労した版だ(ブログ参照)。半固定の抵抗器を取り替えるだけに数時間かかった。

 何とかして取り換えた。電源を入れる。おやあ、無負荷では5Vになるが、LEDだけつけても3V近くまで下がる。オシロで見るとパルスだらけの出力で明らかにおかしい。実体顕微鏡で配線を子細にチェックする。Dsc01162

 すると、分圧抵抗のグランド側のハンダブリッジでつないだところが見事に切れているのを発見した。やれやれ、以前もこの現象に悩まされたことを思い出す。他のところで熱を加えているときにブリッジが解消されてしまうのである。

 これを直して無事、負荷をかけてもちゃんと5Vが出るようになった。300mA以上流してもOK。勇躍、SR04の電源に組み込む。SR04は無事動いた。

不愉快にも市販のDCDCコンバーターは完動(6/25/2017)
 ところが、何故か、センサーの計測距離が不正確になってしまった。どれだけ遠くを指しても、出てくる距離が30cm以上にならないのである。電圧は5Vのままで、オシロで見る限り波形も正常だ。理由はわからない。DC-DCコンバーターのパルス周波数と、超音波センサーのパルス(40khz)とが近いからだろうか。

 スペックによるとFP6291のPWMパルス周波数は、1Mhzと高いのでその影響はないはずだが、おかしなことには間違いない。修正の手間を考えると、もうひとつの自作のDCDCコンバーター(同一のFP6291)をさらに試す気力はもう残っていない。

 昔作ったHT7750もだめだった。距離はもう少しFP6291のより伸びるが、1m以上にはいかない。だいたいこいつはオシロで見ても、脈流でこういう電源には向いていない。本来の工作と違う脇道でこういうトラブルは、気分が滅入る。折角I2Cのレベルシフターまで入れて不良在庫を少し消化したというのに。

 しかし、少々のことではへこたれない当研究所の所長である。手持ちの市販(ストロベリーリナックス)のDC-DCコンバーター基板(LM2735)の予備があるのを思い出し、これを部品箱から探し出して実験してみた。

 何と悔しいことに、このコンバーターでは全く問題なく超音波センサーが動くのである。えー、なぜだろう。何故、自作のコンバーターでは動かないのだろう。不愉快なことだがこれが現実だ。Lm2735

 そもそもDCDCコンバーターをつくるのが目的ではなかった。へそ曲がりでは負けない所長だが、さすがに今度は、これ以上、これにかかわるのはやめることにした。全くの時間の無駄だ。

 だいたいこのストロベリーのコンバーター基板も予備品でこれまで部品箱の肥やしになっていたパーツである。ここで役に立っただけでも良しとせねばなるまい。ブレークアウト基板を早く作って人感センサーを作ろう。

新しいオシロ来たー(6/27/2017)
 オシロを注文したあと、注文先からは「入金は確認しました」や、「商品を配送しました」という意外にこまめなメールが届いていたが、思ったより早く、注文していたオシロが届いた(Siglent SDS1202X-E)。Dsc01158

 カード入金して2日で出荷の知らせがあり、到着は5日後である。たいしたものだ。初めての中華サイトでの買い物でどきどきしていたのだが、とりあえず一安心である。メールが届いていたので大丈夫とは思っていたが、やはり数万円台の買い物では緊張する。

 噂では、大陸からの荷物はべこべこになっている(荷扱いが極端に悪い)はずなのだが、結構、荷姿は崩れていない。ただし、段ボールを開けると、正式の梱包の段ボール箱が現れた。やはり二重になっていた。しっかりした間仕切りの発泡スチロールで機械は中央に浮いている。Dsc01159

 取り出す。現状の8インチに比べれば今度のオシロは7インチでやはり心持ち小さい。心がはやるので前と同じように居間で梱包を解き、プローブの校正をする。画面はかなり高解像度だ。

 我慢が出来ず、早速地下の工作ルームに持ち込んで現在のI2Cなどの波形を観測する。沢山機能はあるが、まだ使いこなせないので、これまで計測したものだけの再現である。

 おおー、測定範囲が広い。これまでのオシロは少しでも長い間観測しようと思っても、すぐに切れてしまい、全体をつかめない(こういうときはすぐロジアナに切り替え)のだが、今度は違う。何しろ記録量がこれまでの2倍以上あるのだ。(6M->14Mpt/s)。Dsc01161

 距離センサーのテスト機で、I2cをスタートさせ実際のアナログの応答トリガーがかえってくるところまでが一目で見られる。これはありがたい。画面が小さくなったことを感じさせない性能向上である。以前より価格は半分で性能はざっと3倍(帯域60Mhz ->200Mhz)。時代の進歩を実感する。

 フォスファー機能とか、シリアルのデコーダーとか盛りだくさんの機能があるのだが、とりあえずは満足である。追い追い調べていくことにしよう。久しぶりに自作のシグナルジェネレーターなどを埃をはらって登場させ色々テストする予定だ。Dsc01160

| | コメント (7) | トラックバック (0)

2017年6月12日 (月)

RaspberryPi3の電源問題はOSの不具合だった

 しつこいことでは誰にも負けない当研究所の所長が、やっとのことでRaspberryPi3(以降Raspi3)が立ち上がらない問題を解決することができた。

 研究所の工作テーマはESP32に移っていたが、定点カメラを目指したRaspi3の初期ブートが失敗するトラブルは解決されていない。パワーオンリセットが効かないのである。USB機器をはずして立ち上げると大体うまく行くが、USBをつないだまま(もちろんセルフパワーHUBで電源供給済み)だと、ほぼ立ち上がらない。Dsc01131_1 質(たち)の悪いことに、一旦、ブートに成功すると暫くは問題なく動く。しかし半日おいておくと、立ち上がらなくなる。一番先に疑われたのは電源である。いくつかのアダプターを買ってきたり、ケーブルを吟味したり、HUBを換えたりしたが、はっきりとした改善は見られない。

 オシロを使って立ち上がりの電圧の波形を何とかとることができた。立ち上がらない時と、正常に動いた時の双方の波形がとれた。しかしどちらも似たような波形だ。確かに0.5msくらいのところで大電流が流れたらしいディップがあるが、正常に立ち上がる時も同じようなものだ。電源が原因ではないような気がする。Dsc01133_1

もう一台RaspberryPi3を買う(5/24/2017)
 次に疑うべきは、Raspiのハードそのものである。以前、Edisonで本体がおかしくなって熱暴走したこともある。もしかしたらハードがやられているのかもしれない。今、Raspi3は一台しかないので確認はできない。これはもう一台買うしかないか。

 予備ということにして(使うあてがないのがつらい)Raspi3をアマゾンで発注する。ケースとヒートシンク付きで¥5980と安かったのでつい手が出た。数日で届く。便利な時代になったものだ。

 まずは、この新しいRaspiの動作確認である。システムディスクの16GBのSDカードを用意し、NOOBS一式をダウンロードする。OSのバージョンは2.1.0から2.4.0に上がっていた。 

 ふーむ、zipファイルが200MB以上増えている。どんどん進化しているようだ。インストールは順調に進みトラブルなくOSは展開された。電源を入れる。全く問題ない。順調に立ち上がる。少なくとも電源ではない。電源不足を示す画面の稲妻マークも全く表示されない。快調だ。

Dsc01137 やっぱり最初のRaspi3が原因だったのか。いや、まだ、カメラをつないでいない。しかもOSが違う。今のOS(2.4.0)はまだ裸の状態で、これからSAMBAや、動体検知motion、日本語入力、固定IPアドレス化などを加えていかないとトラブルの起きた状況にならない。

 加えた変更のうち、初期化のトラブルに関係しそうな要素は、何といってもカメラモジュールの接続だ。ハードの初期化でループしてしまえばブートは先に行かない。まずトラブルの起きた元のRaspi3にこの2.4.0の新しいシステムディスクを差し替えて動かしてみる。

結局、OSを最新版にして落着(5/28/2017)
 やっぱり何の問題もなく立ち上がった。いやいや、まだカメラモジュールをenableにしていない。raspi-configでカメラモジュールをenableにして立ち上げ直す。よーし、素直にブートが始まった。Raspi本体が悪くないことは確実だ。

 最後の確認である。カメラの動作確認だ。motionはまだ入れていないので、raspistillなどの専用コマンドをあせる手でコンソールに入力する。おめでとうございます。ランプがついて写真がとれた。間違いなくOSの問題である。

 これでトラブルの原因がはっきりした。2.1.0でのカメラモジュールの接続はブートの時にハングすることがあるのだ。このあと、元の2.1.0のOSに戻し、再現を確認した後、raspi-configでカメラをdisableにすると、カメラをつけていてもトラブルが解消することを確かめた。

 このハングが何の原因で起きるのかはわからない。少なくともインストール直後は起きていなかったから、カメラモジュールだけの問題ではなさそうである。このあと入れたアプリと何らかの競合が起きた可能性が高い。

 何が原因にせよ、少なくとも2.4.0で電源トラブルは解消した。というので、2.4.0にこれまでのアプリをインストールし直せば問題は解決する。せっせとNOOBS2.4.0の新しいバージョンにこれまでのアプリをインストールし始めた。

 SAMBAサーバーや、Motion動体検知パッケージ、日本語入力など、入れるたびに初期化の状況を確かめる。2.4.0では最終的にmotionを動かしても全く問題は起きなかった。

 やれやれ、長い道のりだったが、ここ暫く当研究所を悩ませたブートの不調は、OSの更新で解決することになった。もっと早く、カメラをdisableにしてテストしておけば、もう一台Raspi3を買わずにすんだのだが、まあ、これは結果論だろう。

今度はSAMBAドライブが不調(5/29/2017)
 そうこうするうちにまたトラブル発生である。SAMBAのディスクにしていた昔のLet'sNoteの2.5インチIDEドライブがおかしなことになった。立ち上がり時に、$LogFile is not clean. mount in Windows....のエラーが出て、書き込みが出来なくなった。Windowsでマウントし直しエラーをリセットせよとのことである。

 ファイルの中身は普通に見ることができる。SAMBAを通すとWindowsからも正常に見えるが、書き込みはこちらからもできない。それではというので、Win10の方にUSB経由で直接持ち込んで、エクスプローラーで見たら、何とドライブは認識したが「この場所にファイルはありません」という完全拒否である。

 Windowsに昔からあるディスク管理ユーティリティで調べる。コントロールパネルの奥にあるこのユーティリティ(このネストの深さは何だ。このソフトはサードパーティ製で、MSとしては何としてもいじらせたくないらしい)でドライブを見ると、ちゃんと正常にディスクは見える。  
 しかし、ディスクの形式がRAW(生とでも訳すか)となっているのが気になる。このRAWをキーワードにウェブを検索すると、おお、良かった。沢山解決法があるようだ。要するに、何らかのタイミングでドライブのブートレコードのディスクの種類を規定するコードが誤って変更されるとこういう状態になるらしい。

Windowsのフリーソフトで解決(6/1/2017)
解決法の中から、まず、TestDiskを選ぶ。このユーティリティは、LinuxやWindowsでも動くフリーソフトで一番評判が良さそうなソフトだ。早速ダウンロードした。ガイドするサイトも沢山ある。簡単に治りそうに見えたが、これが結構難しい。

 やれることが沢山ありすぎて迷うのだ。日本語化されていないのはともかく、何がおかしくなっているのかわからないので下手にいじることができない。このあたりは、一瞬の動作で、すべてのファイルを失う危険がある。良く納得してからでないと作業は出来ない。

 要するに、「今、自分が何をやっているかを理解していないときは手を出してはいけない」というやつである。この「RAW」という文言が何を意味するのか具体的にわからないからである。迷った挙句、他にも方法がありそうなのでこのユーティリティの作業を諦めた。ウェブで検索を続ける。

 その結果、昔、所長も使ったことのある商用ソフトAcronisの無償試用ソフト(Acronis Disk Director)が良さそうなので、これで修復することにした。サイトに行き、慎重に無償版をダウンロードする。こういうソフトのページには、宣伝用の全く違うソフトのダウンロードボタンが隠れていることが多いので気を付けないといけない。Ws000008

 何とか目的のソフトをダウンロードして、早速試してみた。このサイトが親切だ。
画面がわかりやすい。ガイドに従って、未初期化をRAWと読み替え作業を進める。順調に処理が進んで、そう時間もかからず完了した。RAWはNTFSに変わる。

 念のため、Windowsを再起動する。よーし、正常なドライブに戻った。書き込めるか。中に入っているテキストファイルを呼び出し文字を書き込んで保存する。良いぞ、問題なく変更された。このディスクの中に入っているファイルで失って困るものはないが、正常に戻ったことが嬉しい。

 SAMBAにつなぎなおし、read/write可能なことを確かめる。昔、知人にPCで何をするでもないのに環境整備だけに異常に熱心な人がいた。自分も今度の入れ込みぶりはこの系統かなと苦笑いする。今のところSAMBAで使っているのはmotionの記録ファイルだけである。

ACアダプターの負荷特性を調べると驚くべきことが(6/2/2017)
 Raspiの電源問題の後日談である。Raspi3の立ち上がりの不安定さを解消するため、めたらやたらDC5Vの安定化電源ACアダプターを買い込んだことは前回までにご紹介してある。それが、落ち着いて数えたら、容量が2A以上のものだけで6個もあった(購入4ケ、故障した無線ルーターなどからの流用品2ケ)。 

 容量とは言うが、本当にこれだけの電流を取り出せるのか確かめたことはない。前にも書いたように、必ずしも容量の大きいアダプターが安定してRaspiを動かせていたわけではない。彼らの実力がどの程度なのか、ちょっと本格的に調べてみたくなってきた。

 良く言う電源のレギュレーションとは過渡特性のことを指すが、それ以前の静的な負荷特性は余り問題にしない。しかし過渡特性は、この静的な負荷特性が基本になるもので、これが低いようでは問題にならないはずなのだが、余り話題にならないのはなぜだろう。調べてみよう。

Dsc01135 こういうときのために、セメント抵抗を何種類かそろえてある。スライダックのような本格的なものはないが、物理の実験よろしく直列並列を駆使すれば、5Vなら0.1Aきざみで数Aくらいまで測れるくらいの種類は持っている(50、20、10、2Ω)。

 ブレッドボードにこのあいだ買ったUSBコネクター電流計や、ACアダプタージャックを取り付け、少しづつ測り始めた。データが揃ってくると驚くべき事実が明らかになってきた。おおげさな話かもしれないが、こうしたACアダプターは全然定電圧電源ではないのである。

結構、ケーブルの損失があるのだ(6/5/2017)
 どのACアダプターでも、1A少々の電流でもかなりの電圧降下がある。負荷によって出力電圧が変わらないのが定電圧だと思うのだが、サイトのいう定電圧回路の一般的なロードレギュレーションの上限±0.2%どころではない。平気で数%も落ちてしまう。

 4A容量のアダプターといえども1A流して(正確には0.9A)、0.3Vも下がり4.7Vになってしまうのはどうみてもおかしい。これで定電圧アダプターと称するのはいかがなものか。

 確かに、5Vフルスケールでグラフを描いてみれば、0.3Vの低下というのははごくわずかだが、0.5Vフルスケールにしてみると直線的に電圧が低下していく。

 汎用的なアダプターと違い、無線ルーター、USBハブなどの付属のアダプターは無負荷のときはあきらかに5V以上で、使われる範囲で5Vを維持するようになっている。これなんか一種の詐欺だ。

Dsc01138  グラフを描きながら、悪態をついていたが、少し冷静になって考えてみると、わけがわかってきた。流れる電流が1A近くなるとケーブルの長さが効いてきて負荷端では電圧降下が避けられないのだ。 

サイトで調べてみると、銅線の直流抵抗は意外に大きい。#24(アダプターで使われる一般的な太さ)の撚り銅線(錫メッキ)で1mあたり、0.09Ω(1kmで89Ω)。ということは、1A流せば、たった1mのケーブルで、0.1V近く下がってしまうのだ(往復換算)。

 大抵のアダプターのDC側のケーブルは2m近い。一生懸命、アダプターを取り替え、セメント抵抗をつけたりはずしたりしてグラフを作ったが、あまり意味がないことがわかった。手持ちの沢山のACアダプターの記録を詳しく公開するつもりだったが、誤解を招きそうなのでやめておく。

 この測定結果は、これまでのRaspiでのテストの状況と良く符合する。アダプターではなく、DC側のケーブルの長さや太さが大きく影響している。一番成績の良かったのは、例の秋月での長さ10cmの電源ケーブルが一番トラブルが少なかった。

 負荷端での電圧降下を少なくするのは、太いケーブルにするか短くするかが一番で、ケーブルの長さにかかわらず一定にするには、負荷端から電圧測定線(リモートセンシング)を引き出すような大掛かりな装置が必要だということも分かった。今回は良い勉強をさせてもらった。

| | コメント (4) | トラックバック (0)

2017年5月19日 (金)

RaspberryPi 3の電源事情好転せず。ESP32に手を出す

 RaspberryPi 3(以下Raspi3)による監視カメラはほぼ完成したが、恐れていた通り実際の観測には重い腰が上がらなくなった。現役時代の習い性だろう(若い時はそうではなかったので、一種の職業後遺症)。こういうプロジェクトを計画なしに始めることに強い抵抗があるのだ。

 どんな仕事でも一旦始めると、それを中止する大義名分が見つからない限り止められなくなる習慣が出来ている。途中でやめることに強い罪悪感を覚える。作業を始める前に具体的な目的と目標を決めておくのが決まりになっている。

 これまでに何度か気楽に始めてそれが止められず、といって順調に事は進まず、その葛藤で、へとへとになってしまったことがある。とまあ、出来ない屁理屈をこねているが、実はそれよりもっと深刻なことがある。Raspi3そのものの動作がまだ安定しない。

 USBセルフパワーHUBと電源のACアダプターを共通にすると大量にHUBの方から電力を供給してしまう問題は、特定のHUBの逆流と結論付けたのだが、念のため単独でテストしたところマスター側には電圧がかかってこないし(LEDが点かない)、このHUBを分解して中身を確認しても、しっかりVBUS側にはSBD(ショットキーバリヤーダイオード)が入っていたりする。

 別のHUBに交換し、ケーブルを吟味した結果、定常的な電源容量不足は一時的に稲妻の警告がでるものの、相当な負荷をかけても(カメラと自前ブラウザーなど)、ほとんど落ちることはなくなった。しかし、今度は、本体そのものが電源を入れてもブートしなくなるというトラブルが発生し始めた。Dsc01110

 必ず起きるということではなく、何度か電源を入れ直したり、HDDにつながるセルフパワーHUBの電源を別にしたり、あとからUSBを接続したりすると正常にシステムが立ち上がるので、それほど神経質になることはないのだが、安心して運用テストに入れるレベルにない。

UARTの字化けはあっさり解決。ボーレートがおかしかっただけ(4/17/2017)
 
Tiny13を使ったRaspi電源制御装置も、最初、電圧低下でRaspi3では不安定だったのだが、ケーブルやHUBを交換しているうちに安定して作動するようになっている。この制御装置は、電流量のモニターが出来るので、このまま使いたい、しかし肝心のUARTシリアル出力が盛大な字化けをしているのが気になる。Dsc01111

 で、これを先に直すことにした。久しぶりにオシロを動かして、ボーレートを調べる。明らかに9600bpsのボーレートより遅い(1ビット10.4μsのはずが12μs近く)。ネット情報によれば、Teratermはボーレートが設定画面で自由に変更できるというのでオシロのタイミングに合わせてボーレートを下げてみたが(9600 -> 9000近辺)、不思議なことに全く改善されなかった。

 どうも他の原因が考えられる。自作のソフトUARTのソースコードをじっくり見直した。すると送信期間はボーレートを守るため割り込み禁止(cli();)にしているところを、ストップビットを出した直後、解除(sei())してしまっているのを発見した。 

 ふーむこれか。もしここで割り込みが入ってしまうと、規定よりストップビットが長くなって字化けする。ただ、シリアル出力は、500msに一回の電流測定のときだけで、かかる時間は、9600bpsで30 字だしてもせいぜい3ms(1文字10ビットで1ms)だ。他と被ることはないはずだ。

 しかし、さらにコードを調べていくと、待ち時間をループでなく8ビットタイマーで作っていることがわかった。それもその割り込みは1ms単位だ。もしかしたら、ペンディングになっていたタイマー割り込みがここで入ってUARTと被るのかもしれない。

 ロジアナでも持ち出して測れば一発で原因がわかると思うが、何しろTiny13は8ピンでプローブに使えるピンが一本も残っていない。面倒なので、ボーレートの調整と、この修正(割り込み解除をひとつずらしただけ)を一緒に直してテストしてみた。Ws000019

 ピンポーン!見事に字化けはひとつもなくなった。やっぱり被っていたのか。念のため、割り込み解除のステートメントを元に戻してみた。何と、何と。それでも字化けは解消している。被ってはいなかったのだ。

 単なるボーレートの修正だけで直ってしまった。通信ソフトのTeratermのボーレート変更では治らなかったのに何故だ?心残りではあるが、余りこればっかりやっているわけにもいかない。先に進もう。

10インチのHDMIモニターを入れてRaspi環境が改善(4/18/2017)

 現在のRaspi3のOSはJessieで、HDMIコンソールからブートするようになっている。今まではPCのHDMIモニターを共用にしてディスプレイのSWで切り替えていたのだが、電源のトラブルシューティングで頻繁に再起動をする状況ではどうも具合が悪い。 

 例の7インチIGZOパネルをこのときとばかりに使いたいのだが、1920x1080の解像度では、動画を見るのならともかく、コンソールは猛烈に字が小さくなりデバッグなどはとても出来ない。フォントを拡大するコマンドは入れたが、実用性に欠ける。迷った挙句、適当なHDMIディスプレイを別個に買うことにした。Dsc01115

 ウェブで調べてみる。沢山ある。10インチ近辺のモニターは、車載用のTVモニターの需要があるらしい。爆安店で探せば数千円で買えるかもしれないが、買いに行く時間が惜しい。通販でも1万円近くだせばスピーカーまでついた本格的なHDMIモニターが買える。アマゾンで注文する。良い時代になったものだ。

 ほどなく品物が届いた。タッチパネル式のスイッチ、リモコンまでついて立派なものである(1024X600)。動かしてみる。おおお、少し小さいがコンソールを見るには十分だ。これで格段にRaspiの開発環境は整備された。いちいちPCのディスプレイをスイッチで切り替えなくて済む。Dsc01116

 専用のディスプレイが出来たので、Raspi3そのものの整備が楽しくなった。Raspi3はBluetoothもあるし、NOOBSのデスクトップには、既にいくつものブラウザーが動くようになっている。電源問題が先に進まないので、つい色々なことに目移りしてしまう。

 前にも書いたが、Raspi3の性能は大したもので、ウェブサーフィンも殆どストレスを感じない。居間で使っているASUSの古いネットブック(CPUはAtom)より早いかもしれない。感心なことにデスクトップにはBluetoothのドライバーまでインストール済みだ。

秋葉原で久しぶりの買い物。秋月の最大ACアダプターなど(4/21/2017)
 暫くご無沙汰だった秋葉原に仕事の帰り立ち寄り、秋月電子でいくつか部品を買ってきた。これからの電子工作プロジェクトの候補である。現状が迷走しているので、何らかの起爆剤になることを期待している。

・LTC1799
オシレーターチップ。電波時計の電波(JJY 40/60khz)をこれで発生させ、ESP8266などで、ネットのNTP(Network Time Protocol)で得た時刻を標準電波形式にスイッチングする。要するに電波時計リピーター(別経路のリピーターだが)を作ろうというものである。

ウェブサーフィンをしているときに、これを使い、ESP8266のArduinoIDEで作っている記事を見つけた。電波の届かないところでも電波時計が使える。面白そうなのでとりあえずICだけを調達する。Dsc01129

・ソリッドステートリレー (シャープ 8A 250V)
AC機器をリモートで入り切りするために在庫がなくなったので補充した。これまでのESP8266が遊んでいるので、これにウェブサーバーを立てて、ブラウザーからの指示でAC機器を制御する。典型的なIOTの第一歩である。WiFiモジュールは、新しいESP32も買ってあるが、この程度の制御にはもったいないので別の用途を考えることにする。

・4Aの定電圧5V ACアダプター
 Raspi電源制御の切り札、秋月電子内の最大容量の5Vアダプターである。自前で強力な5V安定電源を作る前に、本当に電源容量だけの問題かこれで確かめようというもの。

・ブレッドボード用DIP基板のついたUSBコネクター    
 Raspi電源問題解明で何らかの回路をUSBバスに付加してテストするため。ブレッドボードでハンドリングできるDIPピンのついたUSB Aタイプコネクター。ブレッドボードそのものは接触不良のかたまりみたいなものだが、何とか藁をも掴む思いである。          

4AアダプターでもRaspi電源事情は改善せず。好い加減あきてきた(4/22/2017)
 当研究所には、5V定電圧ACアダプターなら山ほど揃っている。秋月で買った3Aと2.5Aのものを始め、例のUSBセルフパワーHUBの2.6Aや、2.1Aなど、数えてみたら5つもあった。

 今さら、さらに買い足す必要もないのだが、何となく意地になって4AのACアダプターを思い切って買ってみた(といっても¥900)。帰宅して、とるものもとりあえずまずこのアダプターの実験をする。しかし、残念ながらRaspiの電力環境は好転しなかった。これまでのACアダプターと殆ど変わりはない。

 相変わらず稲妻マークは出るし、時々最初のブートが効かない問題は依然としてなくならない。USBプラグを抜き差しすると変化があるので、アダプターの容量の問題ではなくこのあたりの接触不良の疑いも出てきた。

 ウェブで「電源 ロードレギュレーション向上」などのキーワードで、関連情報を探すが、出てくるのはプロ向けのおおがかりな回路設計の話ばかりで、アマチュアが手軽に試せるようなことは何も見つからない。

 本当は、自前で高性能の3端子レギュレーターなどでACから5Vにする定電圧装置を作るべきなのだろうが、このあたりは、素人なのでとっかかりがなく、もどかしい。

 解決の方向が見えない。ブートを失敗するのは、電源投入時の瞬間的な電圧降下であろうとあたりはつけているが、確認するにも現象が固定化されない(どのACアダプターでも起きる。長時間OFF後はほぼ必ず発生。一旦成功すると、そおあとは失敗しない)。具体的な手段が見つからない。段々飽きてきた。

Raspi3のオーディオ環境整備にはまっている(4/30/2017) 
 そういうこともあるが、このところはRaspi3の環境整備にはまっている。専用のディスプレイでデスクトップ環境が格段に使いやすくなったこともある。

 Raspiのオーディオは無印のころから、これまで全く手を出していない。Raspiのオーディオも結構人気のようである。まずはオーディオ関係を整備することにする。

 Raspi3にはアナログ(単なるステレオジャック)と、HDMI出力、それに情報によれば、入出力ピンにI2Sが出ているということだ。この10インチディスプレイはスピーカーがついているのでHDMIからの音が出るはずだ。Dsc01128

 とりあえずRaspi3のデスクトップのメニューバーにオーディオ選択のダイアログがあったので、これをHDMIにしてみる。ブラウザーで適当な音源を選び音を出す。簡単に音が出た。小さなスピーカーなので音質はお世辞にも良いとは言えない。「音も出ます」程度の音である。

 次は、アナログである。内蔵DACは11ビットというのでこれも音質は期待できない。ヘッドフォンを取り出しジャックにつなぐ。おやあ、シーッと量子化ノイズが耳ざわりだ。11ビットならもうちょっと良いはずだが。

 音を出してみる。小さいスピーカーに比べれば、音はましだが、やはりノイズが気になる。ウェブで評判を調べる。うーむ、このアナログの評価は散々だ。

RaspiAudioの音質不良はrpi-updateで少し改善。Bluetoothも(4/28/2017)
 ウェブをさまよい歩くうち、Raspiのアナログ音の出力は、ここのサイトによるとファームウエアがバグっていてサンプリングビットが1ビット少なく10ビットになっているという情報を得た。(オリジナルはここ

 ここには、バグの修正版のダウンロードサイトも紹介されている。2012年の古いパッチのようだが、正規のupdateにはなっていない。現在の最新バージョンには反映されていないようだ。ふーむ、恐らく何か別の不具合があってのことかもしれない。

 まあ、ものは試しである。一式をダウンロードして、インストールしたあと、ファームウエアの書き直し、rpi-updateをかける。エラーもなく順調にrpi-updateは終わった。

 音を出してみる。うーん、少しは良くなったか。確かに少しノイズが少なくなったが、音は驚くほど良くなったとは言えない。まあ11ビットDACは、二昔前のPCのサウンドカード程度なのでこれ以上の向上は無理のようだ。

 Raspiオーディオで検索をかけると沢山ヒットする。いわゆるハイレゾオーディオの中継基地として安上がりなのが人気なのだろう(この手のオーディオ機器は信じられないほど高価)が、当研究所は今のところハイレゾ再生には行かないことにしている。

 というので、次はBlueToothでの音の再生にチャレンジした。キーボードは動いたが手持ちのBluetoothヘッドフォン(サンワのMM-BTSH30)は、認識はするものの、音がすぐ切れる。ブラウザーや、デスクトップのScratchという教育ソフトの猫の音もでないので、BlueToothの問題だと放置していたのだが、あるとき、コンソールから、

aplay /usr/share/sounds/alsa/Front_Center.wav

というコマンドを入れたら、何と、Bluetoothでの音の再生に成功した。だとすると、ウェブに沢山情報のあるとおり、bluetoothのオーディオパッケージBluezと、これまでのLinuxのオーディオALSAとの衝突がどこかで起きている可能性が高い。

 Raspi内のどれかのオーディオパッケージをインストールし直せば、うまく行くのかも知れないが、問題は深そうで簡単に行く話ではない。ウェブでは調べた限りでは、こういう話題がヒットしない。解決策が見つかる可能性は低い。これも少々あきてきた。

ESP32-WROOM-32のテストに着手する(5/4/2017)
 というので、このあいだ買ったままになっていたESP-WROOM-32(以降ESP32)を試してみることにした。このESP32はWiFiモジュールESP-WROOM-2(以降ESP8266)のグレードアップ版である。Dsc01127

 中華製のWiFiモジュールには信じられないほど安価なのが多いが、日本の電波機器の技術適合証明、いわゆる技適をとっていないのが殆どである。しかし、ESP32はいち早く技適をとり、秋月からはPCへのUSB-UARTまで装備したブレークアウトボード(¥1480)も売り出された。単体の値段もESP8266と殆ど変わらない(¥550 と¥700)。

 これまでのESP8266の弱点、CPUが遅い、I/Oピンが少ない、SRAMの量が今一つという不満を一気に解消しており、これはお買い得と、少し前、予定もないのに単体と、ブレークアウトボードをひとつづつ買ってしまってある。

 以前ESP8266で画像付きのサーバーを作ったことがあるが、画像を出すだけ一息の時間が必要で、簡単なGPIOの操作ならまだしも、ちょっと手の込んだ遠隔制御には使えそうになかった。それがこのESP32ではだいぶ使えそうである。

 その割には日本ではまだブレークしていないようだ。技適はついているし、秋月などでもオリジナル(Espressif)社のブレークアウト基板を廉価で出しているに不思議だ。調べてみて何となく理由がわかった。

 どうもESP8266ほど周辺のソフト開発環境が進んでいないようだ。ESP32の開発元、Espressif社が、Arduinoではない独自の開発環境 ESP-IDEというのを作ったようだが、そのあたりの情報が不足している。一本道ではなく、いくつもの開発環境があるというのは、初心者にとってはかえって弊害になる。

 検索をかければ、ウェブには山ほど紹介記事が出てくるのだが、どれも今までのものと何か違和感がある。一例をあげれば、ここなどは、懇切丁寧な記事の大部分は、トリッキーな空中配線や、ブレッドボード上の配線法なので、読み流しているうち、急に複雑なウェブサーバーの紹介になってびっくりする。 

 ここのサイトは、詳細なESP32の情報が掲載されている。でも、ここの情報だけで、初心者がESP32を動かすことは難しいだろう。膨大な情報があるが、多すぎて、恐らくどこかで折れたら(書かれている通りに動かないなど)最後、手も足も出なくなるだろう。

 この違和感は、これらサイトの筆者の責任ではない。明らかに電子工作のやりかたがArduinoなどをきっかけに大きく変わってきたからではないだろうか。要するにハードやソフトウエアの複雑さが比較にならないほど大きくなって、全貌を簡単に把握できなくなっているのだ。

 結論から言えば、素人が手を出しにくい。WiFiによるスマホとの連携ひとつをとっても、その実現は膨大な技術の蓄積で可能になっている。本当の初心者なら電子工作はもっと少ない要素でできている8ビットのPICやAVRで経験を積む方が結局早道なのではないか。

 悪態をついてばかりいても先には進めない。とりあえずは開発環境から整備を始めることにする。何しろ沢山サイトはあるが、ちょっと目を通しただけではなかなかわからない。当研究所には、ESP8266を開発したArduinoIDEがある。当然この環境と一緒にしたいのだが、このあたりの解説が少ないのである。

ESP32のWiFiサーバーまであっさり動く(5/10/2017)
 このサイトを参考に、既存のArduinoIDEに、ESP32関係のパッケージをインストールする。ここを見つけるまでは、殆どのサイトが新規にArduinoIDEをインストールするところから始まっているので苦労した。要するに既にArduinoIDEがあるのなら、所定のディレクトリーにダウンロードしたパッケージを解凍して入れるだけで良い。IDEを再始動すれば、すんなりESP32関係がロードされる。

 ハードの方はいたって簡単だ。ブレークアウトボードなら、追加する配線は殆どない。LEDと制限抵抗を適当なGPIOピンにつなぐだけである。電源はとりあえずUSBから貰う。ここも電源問題が大変なようだが、まあ、実験レベルなのでこのまま行く。

 ArduinoのLチカのコードをコピペし、ビルドする。何事もなく、終了した。次は、ファームへの書き込みである。おお、無事に書き込みが始まったようだ。心なしかESP8266より速いような気がするが、これは、ファーム焼きこみのシリアルの速度が921600bpsとべらぼうに早いためで、本体が早いわけではないようだ。

 ファームの書き込み終了のメッセージと同時に、LEDが点滅し始めた。あっけなくLチカ成功である。ブレークアウトボードのおかげで、前の手製のESP8266開発キットに比べると、動作モードをタクトスイッチで切り替える必要がない(勝手にボードでGPIOピンを切り替えてくれる)。

 勢いに乗って、WiFiサーバーまで動かしてみることにする。ESP32のライブラリーにある、SinpleWebServerのソースを読み込み、このサイトを参考に、Lチカで使ったLEDをブラウザーからスイッチするコードに組み替える。

 これもビルド、ファーム書き込みともNO ERRORで終わった。立ち上げる(といっても何もしないで良い)。恐る恐る、PCに戻り、ESP32のIPアドレスを調べ(まだ固定化していない)、該当のIPアドレスでアクセスする。Ws000020

 やった。小さなメッセージだが、サーバーからの画面が出た。必要な所はクリック可能な色に変わっている。ONのところをクリックする。おめでとうございます。LEDが点いた。とりあえずESP32はウェブサーバーまであっけなく動くことが確認された。

 これから、ESP8266とどの程度高性能なのか調べていくことになるが、紙数も増えてきたので、このあたりで記事を区切ることにする。

| | コメント (4) | トラックバック (0)

2017年4月16日 (日)

motionの動体検知はRaspi3の電源が安定しない

フィールドテストの開始(3/25/2017)
 適当なパラメーター(前記事参照)を設定して、いよいよmotionによる自宅前の道路の動体検知の監視を始めた。道に面したサンルームのブラインドにカメラのレンズが通るだけのの隙間をわずかに開けて、そこに三脚に固定したカメラを設置する。外から見ると、ブラインドに隙間が空いて何か不自然だけれど、実験なのでとりあえずはこのままに。

Dsc01104 RaspiはWiFiにしたので引き回すケーブルは電源ケーブルだけで良い。設置は楽になった。HDDは三脚の下に置いた菓子折りの空き箱にHUBと一緒に載せる。電源スイッチを入れてその場を離れる。地下の工作室に戻ってPCからSSHを開き、motionを起動する。

 よーし、これでmotionは、ストリーム画像を送りながら、動きがあった時だけ、動画(aviファイル)と静止画(jpegファイル)をSAMBAサーバーの所定のフォルダーに画像を残していくはずである。念のため、PCのブラウザーでストリーミングを確認する。うむ画像が出た。102017032517352505 小一時間、カメラをサンルームに置き、データを収集した。ファイル数200ばかり。容量にして80MBくらいが溜まった。これくらいなら一日放置しても大した量にはならないか。

 データの中身をチェックする。自動車は監視対象ではないが、動体検知するのは車のときが殆どである。カメラの位置は進行に対して90°なので自転車の追尾は結構難しい。この場所からでは流れ映像しか撮れない。

 歩行者は問題なさそうだ。動体検知画素数1000程度で十分捕捉している。それでもタバコを人家の庭にポイ捨てする不届き者の人相を完全に把握するのは難しそうだ。 Ws000017

 ファイルは動体検知をしたセッション単位にひとつづつ数が増えていく。現在は、イベント番号(検知セッションの中での連番)というのがファイル名の先頭に来るので、ソートがうまくいかない。ファイル名を工夫しないといけない。

監視カメラの仕様がなかなか決まらない(3/28/2017)
 フィールドテストは始まったが、本格的な運用に入るまでに解決しなければならないことがブラインドの不自然な隙間だけでなく、まだ沢山ある。

 現在、撮影は室内から窓ガラス越しにやっているが、本当は外に置きたいところだ。しかし、外に置くとなると、カメラの防水、防風、防塵などの対策がただちに大ごとになる。レンズを近づけてガラスの影響を少なくする場所があれば良いのだが、今のところ都合の良さそうな所は見つからない。

 また、三脚にカメラを固定し、付属物を横に置いているが、これももう少し工夫したい。掃除はしにくいし、機動的な移動はできない。それに、まだ猫に気づかれていないが、HDDは僅かだが音を出す。長時間放置した場合の音に敏感な猫の対策も考えておかないといけない。

 さらにカメラの運転仕様が悩ましい。吸い殻を捨てる不届き者の特定を当面の目標にしているから、長時間の監視が求められる。人通りの少ない早朝か深夜が考えられるので、もしかしたら赤外線カメラにする必要があるかもしれない。自動的な時間制御もあった方が良い。

 出来上がった映像のチェックがこれまた大変である。motionを使っているので、歩行者、自転車が通過するときだけの映像になっているはずだが、映像をチェックするPC側のビュワーの機能だけでなく、現在のファイル名を今よりもうすこし合理的なものにしたい。

 先述したように、現在のmotionの録画したファイル名の先頭は、ひとつの動き検知のなかの複数の動きの番号(イベントNo)で、ソートするときとても不便である(ここの1や2は余り意味をなさない)。これはmotion.confのファイル名設定で換えられそうだが。Dsc01110_

 世の中の監視カメラの整理はどうやっているのだろうか。やっぱりしらみつぶしに映像を見ていくしか能がないのか。悩ましい所である。

電源制御装置を入れるだけで電圧降下の警報マークが出る(3/29/2017)
 フィールドテストをしながら、Raspiを安定して動かす電源の検討をしている。Raspbianのデスクトップには、電力不足になると画面右上に警報の稲妻型のロゴが出る(4.65V以下)ことを知り、これで、たくさんあるこれまでのACアダプターの性能比較が楽になった。

 ブート時はCPUにロードがかかり手持ちのすべてのアダプターで一部に稲妻が出る。結構敏感である。しかも必ずしも容量の大きい(流せる最大電流)アダプターの方が安定しているとは言えない。秋月の5V 3Aより、セルフパワーHUBについていた容量表示が2.6Aの方が何故か稲妻の出方が少なかったりする。ただ、少々稲妻が出てもすぐRaspiがダウンするわけではない。

 電源ケーブルとして使っているUSBケーブルでも大きな違いがある。太いケーブルの方が相対的には良いが、これとて余り長いと細い短いケーブルに負ける。秋月電子のRaspi専門の商品棚にあった長さわずか10センチくらいのUSBケーブル(タイプA->マイクロB)がやはり最強だ。

 先だって作った自慢のRaspiの自動電源制御装置(スイッチ押下で電源が入り、シャットダウンで小電流になると電源OFF)は、レギュレーションを間違いなく悪化させる。これを経由させると稲妻が出る頻度が高くなり、システムが不安定になってしまうことがある。

 この電源制御装置は0.22Ωのシャント抵抗で電流を計測している。500mA流れても、0.1Vの低下にしかならないので影響は少ないはずだが、どうしてなのだろう。

 以前買った、USBソケット内にLCD電流計を入れたやつはもっと良くない。入れただけで電圧が下がり、正常に立ち上がらない。表示は4.7V以上だが、恐らく瞬間的な大電流のとき表示以上の電圧降下があるのだと思われる。Dsc01113

 オシロでこの瞬間的な電圧降下を測定したいと思うが、トリガーをどうかけて良いのかわからない。入力をACにして、高感度にし、トリガーをnormalやsingleにしてみるが、全く引っかからない。

 こうした瞬間的な降下を回避したいのだが、どうもうまく行かない。下手なインダクターは無用の直流の電圧降下があるし、コンデンサーも大容量のものが既に付いている。これ以上の追加は突入電流が心配だ。

 どうも、Raspiの電源コネクターになっているマイクロUSBのソケットを疑いたくなってきた。2A以上の電流が流れるというのに、あの接点の小ささは気になる。あまり結果は期待できないが、これも例のやり方に替えて試してみることにする。

電源をGPIOピン経由にしても改善せず(4/1/2017)

 それは、以前の無印Raspiで愛用していた、GPIOピン配列に一緒に設定されているVccピンに直接5Vを供給する方法である。無印RaspiはUSBからのパワー供給は、ポリスイッチが間に挟まっており、こいつが悪さをして電源が安定しなかった。

 このポリスイッチを無効にすることで安定化したのだが、最も簡便なのはそのあとにピンに出ているVccピンに電源を供給してしまうことである。ポリスイッチが有効に動くのは、raspi基板内でショートなどで電流が流れることで、それは通常考えられない。これがなくても余り問題にならないという判断である。

 今度のRaspi3は、電源供給用に特化したUSBマイクロソケットがついており、その先の配線はRaspi2までと変わることはない。しかし、マイクロUSBのような小さな接点で、2Aを越す電流を安定的に送れるとは思えない。不安定さの要因のひとつになっているのではないか。

 そこで、前の無印Raspi同様、GPIOピンのVccに電源を供給し、いくつかの同じテスト(ブラウザー2本立ち上げ、motion動作、自分でストリーム受信など)をやってみた。残念ながら、マイクロUSBからの給電に比べ大きく改善されることはなかった。

電源制御装置で奇妙なトラブルにはまる (4/3/2017)
 問題なさそうなケーブルやACアダプターを選んで、何とか自作の電源制御装置を入れても安定して電源が供給されるようになった。

 ただ、SAMBAサーバーに使っている2.5インチHDDの電源供給(USBから給電)は、ただでさえ逼迫しているRaspi3の電源事情を考えて、当初から、セルフパワーのHUBを追加している。しかし、これでは、監視カメラを動かすのに2台のACアダプターが必要になり、取り回しが悪い。

 そこでせめて、ひとつだけのACアダプターでRaspi本体と、HDDをドライブするセルフパワーのHUBの電源にしようとした。ただ、セルフパワーHUBのACアダプターの受け口は、当研究所標準の2.1ミリジャック(秋月電子の標準と同じ)と違うので少々の加工が必要である。

 ところがこのテストをしているうち、妙な挙動に悩まされることになった。電源制御装置にACアダプター端子を追加し(単に入力をパラにしただけ)テストした時のことである。ブートしてRaspiのデスクトップ画面が順調に立ち上がった途端、電源制御のリレーが動いて切れてしまった。

 はじめは過電流が流れてRaspiがリセットしたのかと思ったのだが、勿論そんな状況ではなく、正確にリレーが働いて電源を切っており、症状は再現する。つまり、これはRaspiの消費電流量がシャットダウン時とみなされるまで低下していることを意味する。これはおかしい。Raspiは電源が切れるまで、ブートメッセージを始め、正常な動きをしている。Dsc01109

なんとUSBセルフパワーHUBが犯人(4/5/2017)
 こういう状況を放置しておけないのが所長の習性である。何が原因なのだろう。突き止めるまでは先に進めなくなった。幸いこのTiny13の電源制御装置は、裏蓋を開けるだけでデバッグ用のUARTにアクセスできる。字化けが何故か多いが(未解明)、そのときの消費電流と測定カウント、インターバルなどを表示する。

 このUARTをつないでスタート時からの電流量をモニターして驚くべきことが分かった。何と、このHUBのときは、Raspiには通常の1/3の電流しか流れていない。Raspiは普通、立ち上がりの時はかなり電流が流れるが、デスクトップが出てしまえばRaspiは200mA前後に落ち着く。これが通常の1/3だとシャットダウン時に想定している最高電流80mAを下回る。で、制御装置はシャットダウンと判定したのだ。 Dsc01111

 しかし、電流量が減ったのが全く理解できない。ブートは通常通り行われており、問題はない。するとHUBの電源を共通のACアダプターからとっていることが、これまで違ったところなので、これが原因であることは明らかである。しかし、理屈が合わない。USBコネクターから電源が供給される?そんな馬鹿な。

 試しにHUBを取り替えて別のHUBにしてみた。ははは、この問題は全く解消した。本当だ。セルフパワーのUSB-HUBの中には、スレーブからでもマスターのUSBパワーの電源を戻してやることがあるのだ。

体制は整ったが、突然、工作意欲がなくなる(4/14/2017)
 妙な現象は、手持ちのセルフパワーHUBの特性であることがわかった。症状の出ない別のHUBに切り替え、Raspiの監視カメラの電源整備はとりあえず一段落である。

 三脚の上にカメラ付きのRaspi3を置き、そこから電源用と、HDD接続用のUSBケーブルを2本出す。三脚の下にHDDとセルフパワーHUBを配置し、そこからACアダプターへの電源ケーブルを引くというレイアウトである。Dsc01108

 これをサンルームに持ち込み、テスト開始と意気込んだところに、珍しく風邪を引いた。これがかなり酷く、熱は微熱なのだが咳が止まらないうえ、声がしゃがれて出なくなった。こんなに喉をやられたことは記憶にない。無精して医者に行くタイミングを逃し、家人からあきれられた。

 そんなことで、突然工作意欲が湧かなくなった。電源制御装置のモニターのUARTの字化けを直そうと、久しぶりにAtmelStudioを立ち上げたりしているのだが、次の一歩が出ない。実はこのあいだネットで評判になっているESP8266の発展版、ESP32も買ってきてあるのだが、これも手が付かない。

 これまでにやった工作らしい工作は、傘の骨の修理(東急ハンズで修理用パーツをゲット)。DVDレコーダーリモコンの修理(これはカラ割には成功したが赤外線LED点灯せず。アマゾンで買い直し)。このあいだてこずったRaspiのBlueToothのテスト(キーボードは簡単につながったが、タイムアウトがあって使いにくい)、と脈絡のないことばかりである。

 まあ、これは意欲が戻るのを待つしかない。ブログもこのままではまずいので、とりあえず、中身はないが、これまでの報告ということで。

| | コメント (2) | トラックバック (0)

2017年3月25日 (土)

RaspberryPiのmotion動体検知の実用化に向けて

 このところRaspberryPi(以下Raspi)にはまっている。これを電子工作というのにはちょっと抵抗があるが、システム開発と言うのも何か大げさだ。まあ、Raspiは簡単にI/Oピンをいじれるマシンなので電子工作と言っても間違いではないだろう。

 巷(ちまた)には、Raspiに関する情報は溢れかえっている。しかし実用的な工作まで解説しているサイトは意外に少ない。あっても、詳しいのは導入までの工程で、そのあとの作業について解説しているところが少ないのだ。

 監視カメラに使うといっても、電源や、設置場所、耐天候対策、映像データの蓄積・管理など、検討すべき項目は数多い。この分野も既に専門家による大きな市場ができているので、素人が立ち入る場所がなくなっている。アマチュアがちょっと手軽にやってみるときの情報が少ないのは仕方がないのかもしれない。

 それに、アマチュアは作って動くところまでが楽しみで、動いてしまうと急激に興味が薄れるものだ(かく言う所長もその傾向を否定できない)。しかも、応用の方向は個人によって千差万別なので、参考にならないことが多い。このあたりは自分なりに開拓していくしかないのだろう。Dsc01068

 それはともかく、やっとmotionで想定した通りの動体検知システムが動き始めた。この監視カメラの運用までは、まだやることが沢山あるが、とりあえず一段落したのでブログに報告する。例によって時系列でまとめてあるので、話題が飛び飛びになることはご勘弁願いたい。

サブネット越しの名前解決(3/8/2017)
 直前の記事は、Raspi3をWiFiでつなぎ、SAMBAサーバーを動かすところまでだった。WiFiそのものは何事もなく動き、映像ストリーミングも快調に流れるのだが、SAMBAがなぜか通らない。撮りためるmotionの映像データは、何もしないとすべてRaspi3のSDカードに収容されるので、SDカードの耐久性が心配で、別のメディアを用意しておきたい。

 SAMBAにしておけば、リモートから監視映像を確認することもできるので一石二鳥だ。というので、SAMBAにこだわっているのだが、有線なら通るSAMBAが無線のWiFiではつながらないのである。

 WiFiルーターはブリッジで使っている(はずな)ので、同一のサブネットだと思うのだが、どうもSAMBAサーバーでは別のネットになるらしく、WindowsがRaspiを見つけられない。

 調べてみると、ウェブでは既知の問題点らしく、色々なところで解決法が紹介されている。要約すると以下のようになる。

(1)直接、PCでSAMBAサーバーのIPアドレスを指定してリモートドライブを定義する。WiFi越しでも通る(はずだ)。

(2)PC側のhostsファイルにサーバー名とIPアドレスを登録する。Windowsにもhostsファイルがあるとは知らなかった。しかし、これがとんでもないところにある。C:\Windows\system32\drivers\etcという深いパスの下にある。

(3)PC側のlmhostsファイルにサーバー名を登録する。これが正道なのだろう。lmhostとは、NetBIOSというWindowsのネットワークサービスの名前解決法である。このファイルも、hostsファイルと同じディレクトリにある。

 それぞれ試してみた。(1)は問題なく動いた。但し、固定アドレスをいちいち打ち込むのは運用上うまくない。他をあたってみた。(2)は、最初このファイルを変更することが出来なかった。さらに調べて、管理者権限が必要とわかり、エディター(Terapad)を管理者権限で実行させて変更に成功した。これも問題なくPCはサーバーを見つけてくれた。

 (3)も(2)と同じやりかたで、ホスト名とIPアドレスのセットを登録すると、WiFiでもSAMBAが動くようになった。一番、もっともらしい(3)にする。

Raspi3不調。OS入れ直し(3/9/2017)
 Raspi3の新機能のうち、まだ試していない機能がある。Bluetoothである。ただ、現在は、Bluetoothは、シリアルコンソールのUARTとぶつかるということで、停止している。実際に、ウェブにあるBluetooth関連のコマンドはエラーで戻って先に進まない。

 しかし、情報によれば、シリアルコンソールは、RaspiのBIOSにあたるconfig.txtに、クロックを固定する core_freq=250という設定だけで正常に戻るというのである。しかもBluetoothも動くという。

 今、Bluetoothを使う必要はないのだが、この方法が果たして有効なのかを確認するためBluetoothを動かしてみた。確かに、Bluetoothのセットアップコマンドは有効になり、Bluetoothが動き始めたような感じになった。

 ところが、Bluetoothのディバイスを持ち出して動作を試そうとしている間に、何故かRaspiそのものが正常にブートしなくなったのである。延々とエラーメッセージを吐き出すだけでブートが終わらない。ログインプロンプトまで行かないので何もできない。

 これまで加えたUART関連の変更(config.txtはPCから操作できる)を少しづつ元に戻してみるが、現象は変わらない。一番最初まで戻ったが、同じ状態である。恐らく何らかのBluetoothの設定ファイルが作られてしまい元に戻らないのだろう。設定ファイルをいじろうにもシステムが立ち上がらないので手の施しようがない。暫し途方に暮れる。

 余計なことをして、全く先に進めなくなってしまった。こういうときの一番の解決法は、OSを作り直すことだ。あれこれ悩んでいるくらいなら最初からシステムSDカードを作り直す方が手っ取り早い。Noobs

 手元に16GBのSDカードが見つかった(安売りショップで余りの安さに衝動買い)ので、今度はここに本格的なRaspbianをインストールしなおすことにする。ウェブを改めて調べる。どうも以前と様子が違ってOSのインストール方法が変わったようだ。

NOOBSって何だ?(3/10/2017)
 RasPiも例によって横道からつまみ食いをして動かしてきたので、最近の動向が良く見えていない。このNOOBSというやつが良くわからない。ウェブをさらにさまよい、これが複数のOSを選択インストールできる最新の方法であることがわかった。

 以前やっていたOSのカーネルをイメージファイルで、そっくりコピーする方式はどこへ行ったのだろう。ちょっと探したところでは見つけることが出来なかった。で、このNOOBS方式(ノービス、初心者向けということか)を試してみることにする。

 どうもこいつは、HDMIケーブルを使った画像デスクトップを要求するようだ。Raspiのデスクトップは、この前のSharpの7インチIGZOパネルを用意していたが、これが新しいOSで動くためには、またあのconfig.txtに修正を加える必要がある。面倒なので、PCのディスプレイと共用にする。

 太いPC用のHDMIケーブルを接続し、SDカードに展開したファイル群に起動をかける。よーし、画面にそれらしい起動画面があらわれた。ここではおなじみのRaspbianを選ぶ。他の選択肢にも興味をそそられたが他のは情報が圧倒的に少ないので選択の余地はない。

 Windowsと同じようなビルド画面が延々と続き、数十分でセットアップは終了した。そうか段々こいつもWindowsに似てきたな。キーボードとマウスをUSBハブにつけ準備を整える。順調にデスクトップが立ち上がる。ウェブブラウザーは既に日本語化されていた。20170324234018_1920x1080_scrot

 それにしてもあらためてRaspi3の速さを実感する。1920x1080の画面がスムーズに動く。ネットサーフィンも全くストレスなしに楽しめる。Linuxで動かす分にはもう十分な実用性があるように思えた。

新しいOSはデスクトップからでしか動かない?(3/13/2017)  
 デスクトップからの立ち上げには成功した。ところがシリアルから立ち上がるコンソールが動かないのである。SSHは動くが、シリアルは無反応である。シリアルはハードに直結しているので、ネットがおかしくなったり、デスクトップがおかしくなった時の緊急時のために動かしておきたい。

 ウェブを探していたら、何と、Raspi3からはシリアルはオプションで通常はdisableだという。(ここがとても参考になった。)

 あわてて、デスクトップの仮想ターミナルで、raspi-configを入力し、シリアルをenableにしようとした。なんと、そこにはシリアルを有効にする項目がないのである。ありゃー、これはどういうことなのだ?

 気を落ち着けて、ウェブの説明を最初から読み直す。なになに、デスクトップの「設定」メニューにはシリアルのenable/disableボタンがあるではないか。画面から「設定」を選び、最初のconfig.txtの部分を開く。ほんとだ。ちゃんとある。

 これをenableにして、rebootをかける。おおー、コンソールにブートメッセージが戻ってきた。やれやれ、これで一安心である。それにしても、以前のイメージファイルからのOSは何だったのか。

Raspi3は少しづつ元に戻る。マウントの制作(3/15/2017)
 OSを入れ直して、さらにWiFi化や、SAMBAサーバー、motionのインストールなど原状復帰の作業を進める。そのかたわら、定点監視カメラの本格的な実装に向けた工作も始めた。

 まず、ヨドバシでカメラ用の安い三脚(¥4000)を手に入れ、マウント台をアクリル板から自作する。マウントへのRaspiの固定は当初は輪ゴムで良いだろう。本格的にはいずれ別の方法を考える。Dsc01067

 久しぶりのアクリル工作である。楽しい。アクリル板からRaspiを載せる10X8(cm)の台座と、固定用の1/4インチボルト(これは万国共通のようである)を埋め込む2枚のホルダーを切り出す。以前、USBカメラを固定するのに使った方式と全く同じやり方である。

 これを2液混合のエポキシ系接着剤で接合した。乾燥のため一日放置し、これで丈夫になっただろうと実際に三脚に付けてみた。これが何と、少し力をかけただけでポロッと簡単にはがれてしまった。

 えー、エポキシ系ってアクリルにはつかないのか。前のUSBカメラのときは問題なかったのに。あわててGoogle先生にお伺いを立てる。接着面があまり滑らかだと接着力が落ちるらしい。そういえば前のUSBカメラの表面は梨地だった。

 そこでアクリル板の接合面を紙やすり(#200以下)で表面が曇るまでこすり、念のため別の新しい2液混合の接着剤にしてやり直してみた。今度も一日乾燥させる。試してみた。うむ、今度は大丈夫なようだ。 Dsc01071

 ついでに、近くのDIY店で、滑り止めのゴムシート(厚さ1ミリ、商品名エラストマーシート)を買ってきて、台座に合わせて貼り付ける。これは強力だった。輪ゴム程度の固定でしっかりカメラは固定された。よし、これで定点カメラの固定は万全になった(屋内専用)。

カメラモジュールのパイロットLEDの明度を下げる(3/17/2017)
 定点カメラにするためには直しておきたいところがある。カメラモジュール正面のLEDだ。動き出すと赤く光るのでわかりやすいが、カメラの正面に煌々と赤い光が点くのはまるで威嚇しているようにみえてまずい。

 このLEDをソフト的に消すことはできる。設定ファイルのconfig.txtで、disable_camera_led=1とすれば消えるが、カメラが動いているかどうかの確認が出来なくなるのも困る。

 そこで、LEDの位置を変えようとカメラモジュール基板を色々調べる。カメラチップのピンがビアを通して正面に出ている。これを利用して裏に移すことを考えたが、裏面にはスペースが余りない。しかもこれはかなりな手間だ。 Raspiled

 で、結論はLEDの制限抵抗を増やして暗くすることにした。基板についている抵抗は220オームである。どれくらいの抵抗が良いのか、適当な赤LEDをブレッドボードに差して(同色なら似たような特性と仮定)試してみる。

 10Kオームくらいでも結構明るく輝く。100Kではさすがに暗すぎる。久しぶりに例の低温ハンダを持ち出す。LEDのところに広がらないよう細心の注意を払ってハンダをつける。よーし、簡単に抵抗ははずれた。低温ハンダをハンダ吸い取り線で入念に除去する。

 部品箱の中から昆虫採集のように残してあったチップ抵抗のコレクションから10KΩを探し出し、交換する。パターンは1005だったが、手持ちの1608でも実装可能だった。交換作業は30分もかからなかった。

 試してみる。うん、10Kでも明るすぎるくらいだが、これくらいなら目立たないで良い。いや、くだらない作業だったが、何かとても充実した気持ちになった。

本格的なmotionの設定。画像はとれたが管理が大変(3/22/2017)
 準備が進んできたので、いよいよ、motionの監視用のソフト仕様の検討に入る。motion.confの膨大な設定パラメーターを、我慢して最初から読みはじめる。

 バージョンに新旧があるようで少し混乱するが、読み込んでみるとそう難しい構造ではなかった。大きく分けると静止画(動きを確認したところでのスナップショット)と、その前後の動画の2種類をアクションごとに保存していくようだ。Motion1 Motion2

 沢山のパラメーターがある(動きを検知する前の画像の処理とか、動かなくなってからの動画の記録をどこで止めるとか)。

 管理的には、スナップショットの静止画と、動画は別々のフォルダーに残しておきたいが、これはどうも無理なようだ。

 記録を始める動きの範囲の大小は、実際に動かして見て決めるしかないだろう。ファイルの置き場所は、SAMBAのHDDに指定する。とりあえず、以下のようなパラメーターで監視を始めることにする(変更したところのみ)。

width 640     (320)      Raspi3ならこれくらい画像を大きくしても十分見られる
height 480    (240)
framerate 12  (2)          あまり大きくすると時間遅れが大きくなるようだ
netcam_keepalive on (off)       HTTP/1.1を使ってストリーミングの性能向上
threshold 3000 (1500)             これはとりあえず。これでも結構敏感に反応する
pre_capture  1    (0)                      検知する前の画像も記録する。
event_gap    5    (60)                     検知したあと、不感となる時間(秒数)
max_movie_time 10  (0)                 動画記録の最大時間(秒数) 0は制限なし
output_captures best (on)        検知した一連の画像のうち最大変化量の静止画を残す
output_debug_pictures on (off)   静止画を検知するときの2値化した画像で残す ffmpeg_output_movies  on (off)    検知した時の動画を記録する
locate_motion_mode    on (off)     検知した画像の部分を4角で囲む
target_dir /SAMBAファイルのパス (/var/lib/motion)記録データの保存場所
stream_motion   on  (off)            ストリーム配信をする
stream_maxrate  20  (1)          ストリーム映像のフレームレート
stream_localhost off     (on)        ストリーム配信を自分以外にもする
webcontrol_localhost off   (on)  各種パラメーターの設定を自分以外でも変更可能

 以上の設定で、工作ルームでのテストでは、手を振ったり、動いたりすれば確実に画像が記録されるのを確認した。これが実際の道路を移して所定の画像がとれるのかはわからない。

Dsc01070  このあとは三脚をサンルームの道路に面した場所に置き、観測を開始することにする。さて、どんな映像がとれるか、久しぶりにわくわくする気分である。このあたりで今回の記事は一区切り。次回をお楽しみに。

| | コメント (0) | トラックバック (0)

より以前の記事一覧

その他のカテゴリー

ARM | AVR | EAGLE | Edison | ESP32 | esp8266 | FPGA | FreeRTOS | Node | Processing | Raspberry | STM8S | Xbee | 電子工作