カテゴリー「esp8266」の15件の記事

2018年8月 3日 (金)

また脱線。今度は電波時計リピーターでさらに迷走

 記事の間隔が今回も一か月を越えた。このあいだ電子工作をやっていなかったわけではない。毎日、PCルームにこもって、ごそごそやっているのだが、何しろやることが発散し、次々に興味が他に移るので記事にまとめるところまでいかない。

 赤外線リモコンウェブサーバーのプロジェクトはソースコードの公開で一段落し、そのあと、表面実装基板にするためkiCADの基板設計に取り組んでいた。しかしこれが、ひょんなことで別のテーマに興味が移った。電波時計のリピーターである。

 さらに、そのリピーターも部品の動作テストをやっただけで、関心は電波時計の制作の方に移り、それも、さらに別の枝葉の分野に手を伸ばして収拾がつかなくなってしまった。このあたりで戦線をまとめ直さないと、いつまでたっても記事が書けなくなる。

久しぶりのkiCADは進みが遅い(6/25/2018)
  ミニブレッドボードに作ったリチウム電池駆動の携帯型赤外線リモコンウェブサーバーは、とりあえず目的の機能を満足し(2階のエアコン、温風ヒーターの制御)、実用化の目途が立った。ただハードはまだ実験用のブレッドボード上だし、ソフト面でも残された課題が多い。

Dsc01462  まずは、覚えたリモコン命令を記録していくEEPROMエリアの拡張である。まともにやるなら、例のSPIFFSのファイルシステムにすれば良いのだけれど、そこまで大がかりにする気にはなれない。そう、ニーズがはっきりしていないので運用シナリオが描けないである。

 具体的な仕様が決まらない。今のところ考えているのが寝室の冷暖房の精密温度制御だが、どうしてもやりたいわけでもない(時限タイマーを使えばそれなりに間に合う)。もうひとつが洗面所の温風ヒーターだが、これは防水仕様(湯舟から動かしたい)をまとめる方が先で、ソフト面でこれ以上つけたすところはない。

 あらゆる機器開発でうまくいかない原因の最大級は、この「仕様が明確でない」ということである。実際の使い方が決まらなければ、結局、どれくらいの大きさのEEPROMが必要なのかも定まらない。困ったものだ。

 というので、赤外線サーバーのソフト開発はこのあたりにし、ハードの実装基板を作ることにした。もともとの制作動機は、この基板を表面実装で自前のCNCマシンで作ることだったのだ。何のことはない、本道に戻ったことになる。

 久しぶりにkiCADを立ち上げて表面実装基板の設計に入る。回路図エディターで、ミニブレッドボードに作ったESP8266のウェブサーバーの回路図を改めて書き下ろす。情けないことにkiCADの使い方をあらかたみな忘れている。 

 ESP8266のフットプリントデータをネットで探す。これが意外と見つからない。みんなブレークアウト基板で済ませているようだ。あちこち探し回ってやっと見つかった。しかし、これが回路図エディターに取り出すことができない。 Irserver

 原因はフットプリントデータと、ESP8266の回路図データは別物であることに暫く気が付かずに迷走していただけだった。やれやれ、年は取りたくないものである。見つけたフットプリントは、新しいバージョンのkiCADが必要だというので、kiCADのインストールをしなおす。殆ど泥縄状態である。

 ところが新バージョン(4.0.7)のkiCADは、変な所でループが始まって先に進まない。部品の諸元を変更するたびに、フリーズする。全く止まるわけではなく暫くすると復帰するが、ちょっとした定数の変更のたびに長時間待たされるのはたまらない。

 バージョンを元にもどそうかと考え始めたころ、解決法が見つかった。アノテーションと言ってパーツの番号付けをするルーチンがおかしくなっているようだ。強制的なアノテーションを部品の諸元を替えるたびに行うと、短時間で処理が終わることが分かった。なんやかんやで、回路図をつくるところでなかなか先に進まない。

電波時計リピーターは市販化されていて結構良い値段がする(7/8/2018)
 そんなころ、ESP8266の予備品を見つけるため部品箱を整理していたら、LCT1799というチップが目に入った。これは、去年の4月に面白がって買ったオシレーターチップで、これでNTP(Network Time Protocol)から得た正確な時刻を元に自前のJJYの標準電波(40kHz)を出して、電波時計を動かそうというものである。

 ウェブを検索してみて驚いた。NTPを使った電波時計リピーターは、最近は事務所などで沢山の掛け時計の時刻合わせに使われるらしく、市販品が多数出ており、しかも結構な価格で売り出されている。安いものでも2万円はする。

 電波時計のJJY信号は、もう6年も前、Aitendoで実際に受信モジュールを買ってきてテストしたことがある。値段を聞いて俄然、制作意欲が盛り上がった。赤外線サーバーそっちのけで、受信モジュールの実験の準備を始める。リピーターの実験には、こういう受信モジュールが必須だからだ。

 電波時計リピーターの方は、参考にさせて貰ったサイトではRaspberryPiでPythonを使ったソースコードが公開されている。電波時計は処理単位が一秒ごと、つまり1 bpsなので、NTPさえ動けば何もRaspiまで担ぎ出すことはない。ESP8266で十分動くはずだ。 

 NTPではなく、既存のJJYからのリピーターなら、当研究所の名前になっている8ビットのAVRでも十分可能だ。電子工作では著名なChaNさんは、10年以上も前にTiny2313クラスで電波時計を作られている。

 少し迷ったが、現在一番環境が揃っていて開発に慣れているESP8266で作ることにした。まずは正しい電波をデコードできる時計を完成させ、次に電波発生装置に行くことにする。アンテナが課題だ。

6年ぶりの電波時計モジュールは動いた(7/11/2018)
 部品箱から取り出したAitendoの受信モジュールは、ミニブレッドボードに刺さったままで、モニターのときPCなどからのノイズを避けるフォトカップラーもついていた。早速、通電して動作を確認する。電源を入れてすぐは動かないが、暫く(十数秒)すると、福島からの電波を受信し、LEDが点滅し始めた。

Dsc01475  うむ、動いているようだ。新しいオシロをつないでパルスを見る。前のオシロはじかに接続すると、ノイズが出て受信不能になったのだが、どうだろう。まずは直接つないでみる。おお、今度のオシロは直結でも全く問題なくJJYのパルスが表示された。

 ちゃんとした高周波ノイズ漏れ対策が出来ているのだろう。たいしたものだ。ただ、地下室の奥にあるPCのそばではやはりノイズが多い。オシロと受信モジュールをひとまとめにして、PCのそばから、地下室のオープンスペース(保安上の吹き抜け)へ持ち込むとJJY時報パルスは完全になる。

 蛍光灯の近くは全然だめだが、PC電源の影響は殆どないようだ。受信機はオシロがなくても、電波を受けるとLEDが点くようになっているので、部屋のあちこちに移動して受信状況を調べる。以前はPCの横でも正常に受信できたのだが、長波は季節的なものがあるのかもしれない。Dsc01468

 とはいえ、オシロで見ているとパルスが全くでたらめになることは少なく、パルスの立ち上がりと立下りでチャタリングが起きている程度である。頑張れば、ここでもデコードすることが出来るかもしれない。このあたりの受信強度でも時刻を得られることを今回の開発目標とする。

 ESP8266でのJJYデコードのソースコードはウェブにいくつかころがっていた。Arduino IDEを使ったそのうちの一つが簡単そうなので、これを利用させてもらうことにする。参考にさせて貰ったソースのブログは以下の通り。    
https://ameblo.jp/amano-jacky-nochio/entry-11824498383.html

 ソースが見つかったので安心して、その前に、まだやっていない40kHzの発振機能を確かめておくことにした。

電波送信は昔の真空管のC級増幅を真似る(7/14/2018)
 ブレッドボードにLTC1799モジュールを差し込み、ウェブで紹介された通りの回路を組み立てる。このサイトの記事は外見だけでアンテナの諸元の詳しい説明がない。これは電波法のからみで具体的な情報を避けておられると勝手に判断し、自分なりのアンテナを用意して長波の電波発振のテストを始めることにした。

 動作そのものは、モジュールなので電源を入れると簡単に動いた。オシロで波形を確かめる。矩形波の綺麗なパルスが出ているのを確認した。既に組み上げたJJY受信モジュールを近づけてみる。アンテナは適当なリード線(電話ケーブル4~5m)である。Dsc01473

 JJYのデコードは出来ていないが、受信だけならLEDの点滅でわかる。ブレッドボードの近くに受信モジュールを近づけると、LEDが点いたままになり、受信していることは明らかだ。少し離すと切れる。1m程度が限界だ。リード線はつないでも離しても変わらない。ほっておくとJJYからの電波を受信し始める。

 サイトの記事の外見はフェライトコアにUEW線を巻き付けたいわゆるバーアンテナである。長波なんて波長は何キロメートルもあるので、どんなアンテナで送信するのが良いか全くわからない。

 それでも、ふと思い出して部品箱を漁る。みつけたみつけた。以前Aitendoで買ったシングルバンド用の受信モジュールのアンテナ部分が見つかった。買ったころ断線していて苦労したやつである。

Dsc01466  これは受信用だが、送信アンテナの代わりになるはずだ。単にオシレーターの出力につなぐのではなく、サイトの記事通り、FET(2SJ377)をつけ、20Ω程度の抵抗負荷をつけてみた。

 少し電波は強くなったようだが、事務所内の電波掛け時計を一斉に同期させるほどの強さではない。よく考えてみたら、電源電圧が変わっていないのだから、FETで増幅してみても同じ負荷なら出力は増えない理屈だ。

 念のため、オシロで波形を見てみる。おやあ、鋭い下向けのパルス(数十V以上)が出ている。ふーむ。これはDC-DCコンバーターのスイッチング回路そのままだ。これをならせば正弦波になるのか。

 ここで閃いた。昔というより大昔、アマチュア無線の真似事でやった共振回路である。適当なコンデンサーをインダクタンス(バーアンテナ)に並列にして同調回路にする。真空管時代のC級増幅のタンク回路である。

 おお、正弦波まではいかないがそれらしい矩形波がでた。喜び勇んでJJY受信機の感度を確かめる。うん少しは良くなったようだ。LTC1799そのものよりは少し距離が伸びた。しかし、3mから4m少々までが受信限度である。

 バーアンテナの威力がわかったものの、すこし離れるとJJY電波の方が強くなる。福島からの電波に負けるのだから、LTC1799から発射されている電波強度は、いわゆる電波法に云う免許なしに出して良い微弱電波であることは間違いない。

 大きな部屋の多くの電波掛け時計を制御することは出来ないので実用品にはならないが、アマチュアで近くの電波時計を動かすには十分だろう。免許の必要もない(大体、許可されるはずもないが)

ESP8266によるNTPの受信は簡単に動いた(7/16/2018)
 JJY受信の目途はたったし(ソースを入手しただけだが)、電波の送信もOKになった。残りは、NTPの受信である。以前、RaspberryPiでNTPを受信したことがあるが、ESP8266では初めてである。またネットのお世話になる。

 調べると、簡単に、サンプルソースが見つかった。早速新規プロジェクトを立ち上げ、コピペ一発でソースをぶちこむ。幸いビルドはNO ERRORである。動かしてみるとシリアルコンソール上に、正確な年月日時分秒が出た。

Jjydecoder  同期をどうするかという問題は残るが、これで必要なリソースはすべて揃ったことになる。ただし正確さについては、NTPを使っている以上、余り厳密な追及は出来ない。

JJY受信機の表示に3.3V用のキャラクターLCDを使おうとして失敗(7/18/2018)
 JJYの受信デコードのプログラムのソフト開発に戻る。ネットから頂いたJJYデコードプログラムは、ESP8266ではなく、普通のAVRを使ったArduinoがベースで、表示装置はキャラクターLCDである。

 こちらのLCDの手持ちは、大分前に買ってあった定番中の定番、秋月の反転色の2行16文字のキャラクターLCD(SC1602BBWB-XA-LB-G)である。普通、こういうLCDは3.3Vでは動かない。ウェブを見ていても、ESP8266のLCDは最近はやりのI2Cインターフェースの3.3V版が殆どで、こうしたパラレルLCDの使用例は極めて少ない。 

 そのうち、5VのLCDを、LCDクロックのパルスを利用した負電圧発生回路を付加して使っているページを見つけて制作心が刺激され、これを入れてみることにした。久しぶりのハンダ付けを楽しむ。ところが、これが全く動かない。バックライトすらつかない。

 キャラクターLCDを使うのは、考えてみると久しぶりで、下手をするとガイガーカウンター以来で7年は経っている。色々調べるうち、お粗末な間違いというか勘違いをいくつも発見した。まず、このパラレルLCDはもともとが3.3V用で、負電圧回路は全く必要がなかった。お馬鹿な話である。

 さらに、バックライトの電源は別から供給しなければならないということにだいぶあとで気が付いた。いやいや、情けないの一言である。

Dsc01467  バックライトに電源を入れて、LCDはそれらしい表示が出てきたが、表示ドットはいわゆる豆腐状態で全く反応が見られない。オシロで制御信号を見ると、細かいパルスが出ているが、LCDのパルスにしては、細すぎる(数μs)。どうも、このソースはArduino用で、ESP8266では動かないようだ。

 ライブラリーのLiquidCrystal.hのソースを見た限りでは、クロック依存のところはなさそうなのだが、ここにあまりかかずらっているのも意味がなさそうな感じがしてきた。時計を作ることが最終目的ではない。潔くLCDをあきらめてシリアルコンソールにすることにする。

LCDを諦めて、シリアルコンソールに出力を換える(7/20/2018)
 猛暑である。週2回行っているヨガとプールのアスレチックジムもお休みである。LCDは開発の必須条件ではない。本筋でないところであちこち道草を食ってきたので、何が何だかわからなくなってきた。とりあえずはソースコードのLCD表示部分をシリアルコンソールに切り替える作業に没頭する。

 これは手数がかかっただけで、何も問題はなかった。シリアルコンソールに、それらしいメッセージが次々に表示された。しかし、エラーが多い。いつまでたっても正しいJJY時刻を手に入れることは出来なさそうである。

 このソースは、チャタリングなどの抑止機能は全くついていない。パルスを単純に受け入れて、パルス幅、0.2sec(マーカーパルス)、0.5sec(論理1)、0.8sec(論理0)をスペックどおり(±5ms)調べて、範囲を超えるところはすべてエラーにしている。

 これでは、オシロでみたような立ち上がりや立下りでチャタリングを起こせば、全くデコードできなくなる。そこで、スイッチ制御でおなじみのチャタリング防止ロジックを入れる。立ち上がりと立下りの双方に数十msの待ち時間を入れ、安定したパルスになるようにする。

 しかし、PC横の受信モジュールではどうやっても安定した時刻を得ることができない。前と違って、まれに(10回に一回くらいか)、時刻が出る時もあるが、これでは実用性にかける。

Dsc01471  こうなると意地である。受信機を地上近くのオープンスペースの階段に置いて、PCのところまで電話ケーブル(10m)で送電線のように引き回してテストを続ける。フォトカプラーを経由しているせいか、少々引き回しても結果が乱れることは全くなかった。

 地上近くでは、殆どエラーは起きない。この状態でやっとJJY電波のデコードに成功した。大体、JJY時計の開発が目的ではなく、リピーターが目的なのに全く無駄なことをやっていると思うが、やりだしてことを途中で止めることが出来ない性格である。自分でもあきれてしまう。

一分の遅れをどうするかでまた脱線(7/28/2018)
 実は、これも、NTPを使ったリピーターには関係のない話なのだが、ここでまた3日近く浪費した。それは、JJY標準電波の表示時間が、最初に正時パルスが来て、そのあとおよそ1分かけてその時刻(時分年月日)を伝えるパルスが送られてくるというロジックの問題である。

 つまり、パルスを受け取って、その時刻が何時何分の正時だったかがわかるのは、およそ1分後になるということだ。リピーターなら、NTPと同期させて正時パルスを伝え、その時刻データを送って行けばよい。しかし、時計の場合は、1分先の時刻を用意しないと、正確な時刻にならなくなる。

 これも、お馬鹿な話だが、リピーターでも、この1分先の時刻を用意しなければならないと思い、一生懸命ロジックを考えてテストしていた。たかが一分と侮ってはいけない。単に分を足すだけでは問題は解決しない。下手をすれば年をまたがるときは、すべての表示を変える必要がある。

 色々考えたが、UNIX経過時間を使うのが一番合理的だと判断した。UNIXは1970年1月1日午前0時から始めた秒数をタイマーとして持っている。これに関しては沢山の標準関数が用意されているのでこれを応用する。

 やりかたはこうだ。JJYから得られた時分年月日を一旦、この経過秒に変換し、これに60を足して、また時分年月日に戻せば良い理屈である。

 早速、先ほどのNTPプログラムにこのロジックを組み込んでテストする。ところがこれが一筋縄では行かなかったのである。

 悪戦苦闘、3日間。やっと解決した。しかし、この経過時間があちこちで違うので参った。つまり、JST(日本標準時)の扱い方が、サイトやNTPのオプションで違うのか、どうしても数が合わない。最終的な解決は、この前もやったと思うが、現場合わせである。つまり、NTPをJSTオプションで使ったタイマー値は、地道に計算した1970/1/1の経過秒より一日増やせば一致することがわかった。

 いかにも釈然としない解決だが、とりあえずは、一分遅らせることに成功である。やれやれ。このあたりでブログの原稿をまとめよう。

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

2018年6月23日 (土)

ESP8266の赤外線リモコンウェブサーバー実装にはまる

 2年越しの課題、古いエアコンの赤外線リモコンの制御に成功して意気が上がったのも束の間、またブログの更新間隔が1ヵ月を越えてしまった。久しぶりのソフト開発に思いのほか手間がかかった。ソースの公開のためのスクラッチビルドが遅々として進まず、開発が難航していたのだ。

 最近、ソースコードを公開していないので、そろそろソフトを公開しようとしていた。人様のソースの流用なので、許諾を得るために何度か先方に問い合わせをしてきた。しかし、今になっても返事がない。仕方がないので、ソースコードをこちらで書き直すことにした。

 本来は、クリーンルームなどにこもって、既存のコードとは完全に切り離した形で開発しないといけないのだが、まあ、アマチュアなのでそこは大目に見ていただき、ソースコードをモジュール単位に分解して作り直す。しかし、どうしても似たようなコードになってしまうのは仕方がない。

 それでも、独自のロジックを組み込んだりして、何とか目鼻がついてきたので、このへんでそろそろ公開することにする。

ウェブサーバーからリモコン操作ができるようにする(5/12/2018)
 参考にさせてもらったサイトはここである。ESP8266でコード式の赤外線リモコンの送受信までの機能がある。記事の続編には、ウェブサーバー版もあるようなので、これも少し参考にさせてもらった。

 ただ、ここでは、赤外線リモコンのコードは手入力でソースコードのHTMLデータにセットしている。せっかく赤外線コードが得られているのに、これを手書きで入れ直すのはあまり嬉しくない。 そこで、これをもっと使いやすく、受信したコードをコンパイルなしにウェブを通して送信する機能を追加することにした。

 この世界は所長の慣れないウェブプログラミングである。それでもAVRなどと違ってESP8266はかなりのフラッシュを持っているので、相当なことが出来そうだ。ここで勉強して経験を積み、このあたりの開発力をもう少し高めておきたいという下心もある。

Dsc01464 このため、最近何冊か参考書を買って勉強しているが、今一つ成果は上がっていない。意気込んでプログラミングにとりかかったもののなかなか先に進まない。ウェブを漁ったり、過去の参考書を引っ張り出したり、悪戦苦闘の連続で、まともに動き始めるのに、結局ほぼ2週間かかった。

 Arduinoのライブラリーを活用しようとしているので、回り道が多い。調べているうちESP8266のウェブサーバー関係のプログラム例は沢山、ウェブ上に見かけるが、まとめると大きく2つの流れがあることがわかった。

ESP8266のウェブサーバーライブラリには2種類あり微妙に違う(5/14/2018)
 まず、ひとつは、この参照サイトにも使われているESP8266webserver.hというライブラリ(クラス)を使ったコードで、もうひとつはArduino本来のWiFiシールド時代からとみられるWiFiserver.hである。 

 最初のライブラリは、クライアントからリクエストが上がると、server.on()というイベントドリブン的な関数が呼ばれて、ここでそれぞれイベントに応じた処理が行える。メインのloop()の中は、HandleClient()しかなく、ここでこまごまとした処理を一手に引き受けているようだ。

 もう一方は、clientというクラスを定義して、クライアントからのレスポンスをloop()の中で常時待ち、リクエストそのものを実際に受け取りながら処理を制御する。こちらの方はやや原始的だが多彩な操作が出来そうである。

 ウェブサーバーのGET/POSTといったデータのやり取りは今一つ理解できていないので、後者の系統が分かりやすくて良いのだが、クライアントからのデータの取り出しが難しい。見様見真似でコードを書いていくのだが、今一(いまいち)しっくり来ない。

 前者はそのへんを組み込み関数一発で解決できる。しかしウェブサーバーの処理以外の並行処理をしようとすると(たとえばタクトスイッチ制御など)、どうもうまく動いてくれない。loop()のなかの、handleclient()がブラックボックスになっていて難しい。あれこれ悩む。

50年ぶりの葵祭は小ぎれいになっていた(5/15/2018)
 開発の話が続いたので、たまには、電子工作以外の話題をご紹介。所長の例の京都の小学校の同窓会の話である。これまでは京都近郊の少し離れた会場(石山寺、宇治など)に惹かれて、東京から足を運んでいたが、こんどは別のおさそいである。幹事もなかなかやるものだ。

Dsc01451 前は場所につられたが、今度は京都三大祭りのひとつである葵(あおい)祭の当日がクラス会という趣向である。われわれのクラスの卒業時の総数は51名、そのうち物故者4名、所在が分かっている人32名で、今回は15名の参加であった。半分に近い結構な出席率だ。しかも関東からの出席者が半数近くもいる。やはり祭りの威力はたいしたものである。

Dsc01459  子供の頃見物した葵祭は、平安時代の装束をつけた行列が鴨川の土手を練り歩く頃は、祭りが終盤に近いので、学生アルバイトが汗みずくで疲れ果てて歩いており、近くで見ると見映えの決して良いものではなかった。しかし50年ぶりに見た祭りの行列は、なかなか小ぎれいになっていた。

Dsc01455

 みな溌剌としており、藤の花で飾られた牛車(ぎっしゃ)がとても優雅だ。馬に乗った人の列も昔より沢山いる。しかも馬はみなサラブレッドで昔はこんな立派な馬ではなかった。話に聞くと、関東方面の牧場から乗馬用の馬を大量に借りて来るそうで、人ごみに慣れておらず、時々、暴れるそうだ。

 そういえば、所長の学友には祭りの主催者、上賀茂神社の関係者がおり、直垂(ひたたれ)姿で乗馬していて、御所内で落馬しかけている報道写真を数年前新聞で見たことがある。

やっと目鼻がついたか。ウェブプログラミングが通る(5/25/2018)
 開発の話に戻ろう。2年越しでエアコンの作動に成功したといっても、これはモニターにしているシリアルコンソールからの発信で、ブラウザー画面からではない。ハードはこの前に使ったミニブレッドボードの携帯型の学習リモコンで、ここにウェブサーバーのソフトを流し込んでいく。

Dsc01465  ウェブサーバー用のソースコードは既にサイトに紹介されているのだが、スクラッチから開発したいため、別のライブラリーWiFiserver.hで動くようにコードを書き換えて行く。前にも述べたように、このライブラリーは、loop()の中でGET/POSTという、クライアントとサーバーのやりとりが目に見える形で操作できるのでプログラミングがしやすい。

 しかし、すぐに暗礁に乗り上げた。帰ってくるデータが制御文字を避けるためのエンコードが残ったままで(スペースが%20など)、これをデコードしなければならない。%20をスペースに戻すくらいなら簡単だが、サーバーには日本語が使いたいので漢字となるとお手上げである。

 ウェブ上で解決法を探したが手ごろな仕掛けは見つからない。色々迷ったが、結局、オリジナルのESP8266webserver.hに戻し、なるべく元のソースコードを見ないようにして開発していくことにした。

 こちらのライブラリでは、GET/POSTで入ってくるコードは、argsという組み込み関数にパラメーターを与えれば、コマンドのStringデータを次々に一発で得ることが出来る。しかもデータはエンコードされておらず(というより、関数内でデコード済み)、大幅に開発量を減らせる。

 お手本があるので進捗が早い。オリジナルのWiFiがAPモードで使いにくかったので、STAモードに換え、一般のブラウザーでも画面が出るようにする。これで使いにくいスマホをクライアントにしないで、一般のPCから操作が出来るようになった。

 HTML文書は、以前、ESP32で画像付きサーバーを作ったときのソースを流用して、とりあえず画面を立ち上げる。styleシートの扱いが難しく、素人まるだしの無粋な画面だが、動かしてみると、これが意外にも簡単に動いた。Ws000004 とりあえず、電子音量リモコンの上下ボタンと、エアコンのスタート/ストップだけの操作だが、PCの画面から、ボタンをクリックすると、音量リモコンが動き、エアコンが、厳かに音を立てて始動するのを確認した。いやいや、まだオリジナルのソースのかなりの部分が残っているが、とりあえずは完成である。感慨にふける。

コンパイルなしに新しい赤外線コマンドを画面から追加する(5/27/2018)
 次の課題は、ウェブサーバー上でのコマンドの追加である。受信部はまだこのサーバープログラムには実装していないので、まずはFORMタグによるクライアント画面上からのコマンド名と、その赤外線データの文字入力でコマンドを新設する機能を開発する。

 ブラウザーの画面で、データのやりとりをするのは簡単ではない。シリアルコンソールなどの送受信は、双方が同等の機能を持ち、独立して動くので、やりとりを設計するのに苦労しないが、HTMLを介したサーバーとクライアントのやりとりは、サーバーからクライアントにトリガーをかけることは基本的には出来ないので、一筋縄ではいかない。

 いわゆるプッシュ通信という、あたかも、サーバーからデータが来るように見える機能があるが、これは、あらかじめクライアント側のアプリに仕掛けがしてあるからで、基本的にサーバーは、あくまでもクライアントからのリクエストを待つしかない。

 つまり継続して通信を続けるには、必ず、クライアント側にお膳立てが必要で、HTML文書やCGIなどでサーバーが事前に準備しておく必要があるのだ。これが面倒である。

 悪戦苦闘の結果、画面上の形や位置は、とてもスマートと言えない状態だが、コマンド名とそのコード化された赤外線コマンド($から始まる16進コード、オリジナルがまだ残っている)を画面上に表示し、FORMタグで取りこむことに成功した。下の行に、クリッカブルになったコマンドが表示され、これをクリックすると、めでたくリモコンとして動作した。やれやれ、これでまた一歩前進である。

 こうなると、受信部の実装が急がれる。赤外線受信のハードの部分は携帯型学習リモコンに実装済みで、オリジナルのソースコードでは動作を確認している。これを独自ソースに書き換えなければならない。

 受信部分で最も大変なのが、得られたRAWデータ(パルス幅μs)をコード化する部分である。オリジナルは、AEHA(家電協)方式と、NEC方式しかサポートしておらず、あとからSONY方式を追加したのだが、今度は、いちから作り直しである。

 特に苦労したところは、NEC方式とSONY方式の区別だ。基本のパルス長が562μsと600μsと非常に近接しており、この差だけで区別することは難しい(テストのときは何とか特定データで誤魔化した)。これを全く違う方法で区別するように頭を捻った。

 その方法は、ソースを見て頂ければわかるが、NECとSONYの基本長がほぼ同じで、論理ビットがちょうど反転しているのを利用している(NECはONパルスの長さが一定で、OFFの長さで0.1を判断し、SONYはその逆)。得られたON/OFFのビット長の平均を比較すれば、ほぼ間違いなく両者を区別できるしくみだ。

EEPROMが曲者だった。いくつかの落とし穴にはまる(6/5/2018)

 受信部のスクラッチ開発は手間がかかるので、その作業のかたわら、EEPROMでデータを保存する機能をつけてみた。ESP8266でのEEPROMの実装は始めてであるが、見たところ簡単そうなので気楽にコードを加えて行ったところ、最初は大はまりにはまった。

 プログラムがひんぴんと落ちるのである。データを書き込むと、一瞬でメモリ破壊でシステムがリセットする。ためしにネットにある例題をコーディングすると問題ない。つまりハードではない。頭を抱えた。

 オチは簡単だった。要するに、データをStringで定義すると、EEPROMの中のデータ長が不定になるため(恐らく0バイト指定)、メモリ破壊になるのだ。Stringで定義してはいけない。探した限りでは、これまでの情報にこの落とし穴の指摘はなかった。

 文字配列にして長さを指定しても、実はまだメモリ破壊が止まらなかった。これは今度はこちらのミスだった。要するに、文字列の最後の'\0'キャラクターを長さに入れていなかったためで、少し多めにデータ長を指定してOKとなる。やれやれ。

Ws000006  このあと、待ち時間を入れないとおかしくなる(5ms以上必要)と聞いて、慌てて待ち時間を追加する。これでやっとのことで、画面で定義した新しいコマンドが電源を入り切りしても現れるようになる。このあたりも作りこめば、いろいろ工夫できるが、とりあえず、最後の受信部の書き直しに移る。

ウェブサーバーに受信部を追加する。大幅書き直しでこいつも難航(6/12/2018)
  Arduinoのプログラムステップ数も500を越えて、そろそろ開発の限界に近付いてきた(ひとつのモジュールの開発規模が500ステップを越えると制御不能になりやすい)。そういうことでもないが、気楽に、今までの受信部をとりあえず、全部取りこみ、タクトスイッチで受信を開始するロジックを加えたのだが、全体が全く動かなくなった。

 わかってみれば、単なる変数の初期化忘れが原因だったのだが、最初はなぜ動かなくなったのか全く見当がつかない。疑似コード作成をさぼって、適当にコードを追加した咎めである。こうなると、もう修復は難しい。

 一旦、入れたコードを#if 0と#endifで全部元へ戻し、少しづつコードを足して、その度に動くことを確認しながら入れるコードを増やして行った。結局、バグは先に述べた通り、単なるレコード数変数の初期化忘れという初歩的ミスだった。

 何とか動くようになり、このソフトは、以下の手順で学習した赤外線データを送ることが出来る。まず、タクトスイッチの押下で(準備OKのLEDが点灯)、赤外線リモコンの照射を待ち、正しく信号が入ると、LEDが点滅して無事受信されたことを知らせる。

 ここで、画面上の、「画面更新」というボタンを押すと、得られた赤外線コードが表示されるので、クリックすると、学習した赤外線コマンドが送信される。電源を切ってもデータを残すためには、この赤外線コードを、ブラウザーのコピー/ペーストで、コマンド新設の欄に入れて登録すれば電源を切っても残る。

Ws000007  学習したコマンドを直接EEPROMに保存する機能はまだ未開発だが、これ以上、公開を遅らせたくないので、見切り発車で公開の準備に入った。ソースコードの独自開発をせっせと進める。

ソースコードの公開(6/22/2018)

 そのうち、4年に一度のサッカーのワールドカップが始まった。PCに向かうより、TVの前で深夜過ごすことが多くなり、開発の速度はいやでも落ちる。しかも、全く勝てる見込みのなかったコロンビアに日本が見事な勝ち越しゴールで勝ったものだから、もう大変である。

 ということで遅れに遅れていたが、やっとのことでソースコードを公開できるまでになった。まだ未完成な所も多く、オリジナルのコードをすべて取り替えるところまで行っていない。プロの世界では、まずクロだが、まあ、お金をとるわけでもないので、とりあえず公開して様子をみることにする。
以下に、赤外線リモコンサーバーのスケッチを公開いたします。フォルダーがzipファイルになっていますので解凍のあと、適当なArduinoの開発環境に入れてビルドしてください。WiFiのIDとパスコードを加えるだけで、上記の画面が、192.168.0.33/で見えるはずです。

「sketch_IRserver.zip」をダウンロード

意:6/26以前にダウンロードした方は、もういちどダウンロードしなおし、前のものは廃棄してください。一部にバグがありました。

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

2018年5月14日 (月)

CNCマシンは少しお休み。赤外線学習リモコンに熱中

 CNCマシンで DC-DCコンバーター基板を切削して動作するところまで作りこみ、CNCマシンへの情熱は少しおさまった。

 電子工作を始めてから早いものでもう10年が経つ。正確には2007年10月、ブログの公開が2008年8月だが、前にも書いたようにCNC制御は究極の夢で、とても自分では実現できるとは思っていなかった。それだけに感動の思いはひとしおである。

 勢いに乗って、次々に基板切削にとりかかりたいところだが、なぜか手が止まった。当研究所のモットーは「実用」である。「何かに役に立つものをつくる」ということから言えば、今作りたい表面実装基板はない。

 実用にこだわると意外にテーマがないものだ。CNCマシンの他の応用、彫刻などの木工も、題材を探してはいるが、これはという決め手がない。レーザーカッターまで買ってあるのだが、テーマは見つからない。そう、何となく、みんな「ときめかない」のだ。

一度挫折した赤外線学習リモコン基板はどうだろう(4/15/2018)
 そこで、これまでのブログの記事を読み返しながらテーマを探していると、以前AVRで作って、うまく動かず途中で諦めた赤外線学習リモコンの記事が目に止まった。
(もともとの電子音量リモコン制作記事はこちら

 2年ほど前に、AVRのTiny861を使って、得られた受信信号をそのまま(RAWデータ方式)送り返す方式で、手始めに自作の赤外線による電子音量リモコンを動かそうとしたのだが、一番簡単なSONY方式にもかかわらず、全く動かなくて途中で投げ出した。エアコンのようなデータ量の多いリモコンを学習することはとてもじゃないけれど出来そうもなかった。

Pc043427  このあたりは最近どうなっているのだろう。ネットで「学習リモコン」をキーに検索する。すると最近のIOT時代を反映してか、予想以上にたくさんヒットした。2年前より明らかに多い。電子工作というよりこれは実用品のようで、商品の宣伝がやたら目につく。自作の制作記事も前より増えている。

 自作のターゲットマシンはWiFiモジュールのESP8266が多い。廉価だし、WiFi付きなので遠隔地からも簡単に制御が出来る。しかもプログラム開発にArduinoが使える。この前は意地を張って、ESP8266でなくわざとTinyを使って失敗したが、今度は素直にESP8266を使ってみようか。

 ソースコードも、あまりやせ我慢をしないで先人のものを使わせてもらおう。うまく動けば、この学習リモコンユニット基板をCNCマシンで作ればよい。これまでのリベンジと、CNCマシンの第二作、一石二鳥である。

 ESP8266はこの前使ったAVRに比べると格段に高性能である。クロックは80Mhzと、下手なARMより早いし、フラッシュやSRAMもメガバイトクラスなので気楽にプログラミングが出来る。AVRのときのようにメモリに気を遣う必要は殆どない。

 ただ、赤外線学習リモコンと言っても、色々な方式がある。一旦意味のあるデータにデコードしてから、それを再生するコード方式が一番確実だが、赤外線リモコンには多種類のコードフォーマットがあり、これをすべて網羅することは難しい。といって、記録したデータそのものを忠実に再現する方法(RAWデータ方式)は、以前、失敗していてトラウマがある(ロジアナで同じような波形だったのに全く動かなかった)。

 いずれにしても、ESP8266を変換基板なしに直付けして作る表面実装のリモコン基板なんかはちょっと格好が良いのではないか。どの方式にするかはあとからでも決められる。とにかく学習リモコンを作ることを次のテーマにすることにした。

受信部分はあっさり動いたが、送信部分は追加開発が必要(4/23/2018)
 RAWデータ方式でもコード方式でも、受信部分は同じなので、まずはESP8266を使った受信部分の開発を始める。ハードの準備はミニブレッドボードで簡単に組みあがる。
ソースコードは、ここ(東京お気楽カメラ)を使わせてもらうことにする。記事はここ

 ここは詳細な分析があり、送信部分は、RAWデータではなく一旦すべてのデータをデコードするコード方式だが、このコードを使ってサーバーからの送信もできるらしい。とても高機能だ。

 赤外線受信モジュールを用意し、ソースコードをネットからコピペし、新規スケッチに放り込んでコンパイルする。幸いコンパイルエラーもなく順調にビルドが出来た(当たり前か)。モニターのPCコンソールをつないで早速動作テストに入る。

Ws000003  おお、素晴らしい。赤外線パルスのマイクロセカンドのオーダーの数値がコンソールに並んだ。いや、さすがはESP8266だ。4バイト(long)や2バイトのバイナリデータを多数(5ケ)かかえた構造体の配列を400以上とってもびくともしない。AVRとは大違いである。

 次は送信部分である。このサイトは赤外線LEDへ流す電流を詳細に検討されていてとても参考になる。こちらもサイトにならって2本の赤外線LEDを直列に並べる。大電流の必要な赤外線LEDのドライブは、トランジスターでなく、前に使ったFET(2SJ377)を使う。

 すぐにでも送信のテストをしたいところだが、このサイトの送信は、AEHA(家電協)とNEC方式の2つのコード方式で、皮肉にもこちらの手元にある赤外線ボリュームコントロールのSONY方式はなく、新たな開発が必要である。

 いずれはSONY方式のコード化はしなければならないが(ネットを経由するとき)、結果を早く知りたいのでRAWデータ方式の送信部を追加開発することにした。あわよくば、全部をRAWデータ方式にしても良い。これでうまく行けば無敵になるからだ。

RAWデータ方式で電子音量リモコンが動いた!(4/25/2018)
 送信部分が完成した。テストに入る。受信部分で対象のリモコンからデータを受け取ったあと、何らかのトリガーで、マイクロセカンドオーダーで蓄積された時間間隔に従って忠実に赤外線をON/OFFし発信する(RAWデータ方式)。

Dsc01431  このユニットは電池駆動にする予定である。リモコンの対象が家の各部に散らばっていて、テストのためにはPCから離れなければならないからだが、トリガーのタクトスイッチなどの実装が手間なので、とりあえずはPCのシリアルコンソールからのキーボード入力で制御する。

 テストの対象は、まずは目の前にある以下の3つである。このあいだの自作の電子音量リモコン、それにPCルームにある10年以上前の古い三菱エアコンと、RaspberryPi用の10インチモニターのリモコンである。他の部屋のエアコン、TVやDVD、洗面所の温風ヒーターなどは現地に赴かなければならない。

 手始めは、因縁の電子音量リモコンである。送信する。全く動かない。ふーむ、やれやれ。今度も駄目か。赤外線LEDに並列に可視光線のLEDをつけているので、発信していることは間違いがない。オシロにもそれらしい信号(サブキャリヤー)が観測できる(ただし、端子の所で)。

 受信の時のデータはコンソールで確認できているので、あとは、赤外線LEDあたりを疑うしかない。参考サイト以外の赤外線リモコン関連の記事を見ていると、赤外線LEDを4つも並列に並べているところや、複数あるとかえって個体差でエラーが多いという指摘のあるサイトがあったりして、混乱する。

 2つあったLEDを1つに減らしたり、制限抵抗を10Ωに下げたり、LEDの照準を合わせたり試行錯誤するうち、おお、気が付くといつのまにか電子音量リモコンが反応し、ボリューム値が変わっていた。

少しづつ成功率が上がっていく。PWM方式も有効(4/28/2018)
 いや、嬉しい。今まで全く反応がなかったSONYフォーマットの赤外線音量リモコンが動く。百発百中というわけにはいかないが、今まで全く無反応だっただけに嬉しい。

 でも、ときどきESP8266そのものが暴走するし、成功率は余り高くない。オシロの波形をさらに良く調べたところ、意外にも、パルスの立下りがなまったサブキャリヤーの波形があらわれた。なにー、FETはトランジスタより高速だというのに、この波形はおかしいではないか。

Dsc01435  このFETは、前に動かなかったとき使っていたのと同じP-MOSのFET(2SJ377)だ。サブキャリヤーがちゃんとした矩形パルスになっていない。そうか、以前動かなかったのは、この原因もあるのだろうか。

 赤外線LEDのドライバーをFETからトランジスター(2SC1815)に切り替えた。オシロの波形はまだ少しなまってはいるが、FETよりは格段にましな矩形波パルスになった。成功率は残念ながら100%とは言えないが、それでも反応する率は確実に高くなってきた。 FETのスイッチング特性については、ここ(SUDOTEK)が詳しくて参考になる。

 それにしても、久しぶりのコーディングは、落とし穴に落ちてばかりで、結構な手間がかかった。たとえばwhileループの継続条件を決める変数を、最初のカッコのなかで、++や--で、うっかり変えてしまうと、そのあとの処理は、変わった後の変数が使われる。

 コーディングしているものにとっては、forループと同じように、i++や、i--は、繰り返し処理が済んでから、やってくれるものと期待しているけれど、そう甘くはない。プログラムは書いたようにしか動かないのである。このデバッグに数時間かかった。やれやれ。

 リモコンの成功率を高めるために、サブキャリアーをdelayループでなくanalogWrite()を使ってPWMでサブキャリアーを出すこともやってみた。これはうまく行った。オシロにもきれいな矩形波が並び、周波数も想定通りだ。暫くこれを使おう。

Dsc01434  成功率は徐々に上がってきた。好調なときは、ヒット率は90%まで達するときがある。しかし、100ビット以上あるエアコンはまだピクリとも動かない。うーむ、これはコード方式でないと無理か。

 それはともかく、ネットを探し回っているうち、以下のすごいサイトを発見した。ArduinoでなくAVRのTiny85で学習リモコンを作った方のURL。いやこれはすごい。詳細な解析結果と、データ圧縮まで考えた力作である。

ミニブレッドボードに携帯版の学習リモコンを作る(5/1/2018)
 SONY方式の電子音量リモコンに続き、NEC方式のRaspiのモニターのリモコンも問題なく動いた。エアコンはまだ動かないが、我が家には、まだ数種類のエアコンや、TV、DVDなどがあり、どこまでRAWデータ方式が有効か確かめておきたい。このため携帯版の学習リモコンの開発に移った。

 このあいだ買ったESP8266用の幅の広いミニブレッドボードに、もう一台のESP8266を載せ、送信LEDと受信モジュールを接続する。さらに、タクトスイッチと状態表示のLEDを追加した。シリアルコンソールがなくても制御出来るようにするためである。電源はリチウム電池で、このあいだのLDO(NJM2845)で3.3Vにする。

Dsc01430  赤外線の送信トリガーはタクトスイッチで、発信の確認は赤外線LEDに並列に接続した普通のLEDである。受信の方は、データを読み終わると別の状態表示用のLEDを点滅させ、その後、点灯したままにしてデータが蓄えられていることを示す。

 これで自宅のあちこちにでかけ実際のリモコンの動作を確認していった。その結果、TVのリモコンや、洗面所の温風ヒーター、さらに2Fの寝室のこの間、買い替えたばかりの三菱エアコンは、このRAWデータ方式でも見事に動くことが確認された。

 結局、我が家でこのRAWデータ方式の学習リモコンで動かないのは、10年以上前のエアコンだけとなった。このエアコンは1Fの居間のエアコンと全く同じであり、皮肉なことに最もこの機械を使う可能性の高い機器が残ったことになる。何となく気持ちが収まらない。成功した気分になれない。

 それに、小規模なリモコンでもコマンドシーケンスを持っているのがあるので苦労する。最近導入した台湾製のロボット掃除機などは、コマンドの種類は少ないのに、ボタンの2度押しなどでコードを変えているようで、単純に2回同じボタン信号を送っても正しく作動しない。 

ESP8266のWatch Dog Timerの作動から逃げる(5/2/2018)
 実験機が持っていた持病、時々暴走してしまう症状の原因がやっとわかった。プログラムを動かしている間に、いつのまにか、CPUが例外条件を感知してリセットしてしまう。いわゆる暴走だ。

 最初は測定中に配列に大きな値がはいってメモリでも壊しているのだろうと思っていたが、メッセージを良く見ると、そうではない。ループ中にWatch Dog timerが動いたというメッセージである。わけがわからない。

 こういうときはGoogle先生に聞くに限る。いつものエラーメッセージをキーワードにする検索で、すぐ原因がわかった。ESP8266のArduinoは、ユーザープログラムの裏でWiFiなどのシステムが動いている。従って、ユーザーが一定以上CPUを独占すると、エラーとしてシステムをとめてしまうらしい。

 つまり、While(1)などでCPUをループさせ、ディジタルピンの変化を監視するプログラムは、途中で、delay(0)とか、yield()などの関数をはさまないと、このトラップにかかる。

 理屈がわかれば対処は上の通り簡単だ。参考にさせてもらったサイトのソースに、delayループが各所に挟まれていた理由が始めてわかった。何故こんなところでms単位の待ちをいれるのだろうと最初は訝っていた。これを省いていったため暴走が始まったらしい。

赤外線センサーが時々ノイズを出す(5/3/2018)
 さらに、携帯版の学習リモコンで、折角、覚えさせたデータが失われる不具合(点いていたLEDが消える)が、頻発し始めた。赤外線センサーの誤動作で受信ユニットが動き、貯めてあったデータが失われるようだ。

 こういうときのためのオシロである。 赤外線センサーの出力にSingleトリガーをかけて、早速、調査を開始する。接続して1分も経たないうちに原因が判明した。赤外線センサーから、20μs程度の短いパルスが発生している。手持ちの2つあるセンサーの内の一つがノイズっぽく、もうひとつは比較的安定している。

 電源ノイズで、こういう現象が起きるようだ。Vccにコンデンサーと抵抗のデカップリングをすればなくせるらしいが、そもそもは、こういう短いパルスだけで、これまでのデータを消してしまう方も悪い。一旦、まともに得たデータ(カウント20以上)は、受信エリアとは別に残しておくソフト的な方法で解決した。シングルパルスのノイズは無視しておればよい。

 あれやこれやで、携帯型の学習リモコンも安定してきたが、どうもプロジェクトの終着点が見えない。この学習リモコンで何を制御するのかという明確な目的がないので際限がないのだ。何と言っても、我が家の主力エアコン2機が、この方式で動かないというのが致命的である。やっぱり、コード方式をやってみるか。

やっと主力エアコンが動いた。やっぱりコード方式でないとだめだった(5/8/2018)
 長い間の懸案、学習リモコンで難攻不落だった三菱の古いエアコンを動かすことに遂に成功した。コード化して送り直す必要があった。いやあ、長かった。上記サイトのソースコードのおかげである。感謝、感謝。

 秋月で入手した赤外線センサー(OSRB38C9AA) は、このサイトにあるように、どうもON期間が短く、OFF期間が長くなる傾向があって(およそ30μs)、それでも新しいエアコンや、ビット数の少ないTVなどの制御はRAWデータ方式でうまく動くのだが、我が家にある、10年以上前の古い三菱エアコンだけはこの方式ではガンとして動かなかった。 

 最初、センサーの立ち上がりと立下りの遅れの時間の差と考えていたが、オシロで調べたところ、明確な差は出なかった。パルス列の中で、差のあるところと全くない所が混在している。RAWデータ方式の明確な問題点は突き止められない。

 結局、これまで参考にさせていただいたソースコードを元に戻し、コード方式の実験に移る。さらにSONY方式を加えて、プログラムの確認が容易に出来るようにした。エアコンを激しくon/offすると機械に良くないということを聞いたからである。

 SONY方式は、ビット数が少ないのだが、データビットの論理が反転しており、ビット'0'と'1'の区別はON部分の長さである。従って、リーダーの直後のOFF区間からデータに入る。

 つまり、コード化にあたっては受信のところからデータ収集のやり方を変える必要がある。しかも、基準時間がNEC方式との差が10%以下(560と600μs)なのでどちらかを決めるのが難しい。エアコンのデコードとは本来関係がないのだが、ついSONY方式の実現の方に夢中になる。

 送信の方は少し楽だ。ソースコードの中で、送信するビットの部分を2つ作り、最初から独立させてしまう。独立させるのは、送出時間の誤差を少しでも減らすためでもある。ESP82366である。フラッシュは潤沢にある。

 できた。コード方式をSONY方式の電子音量リモコンで確かめる。よーし、動いた。しかし成功率は、RAWデータ方式よりちょっと良いくらいで、目を見張る程のことはない。さて、いよいよ、問題のエアコンのテストである。

 まず、リモコンをエアコンに読み取られないよう(エアコンが動くとステイタスが変わる)、陰で実験機に覚え込ませ、シリアルコンソールでデータが入ったことを確認して、祈る気持ちで、送信ボタンをON。

 ピーっと、言う音と共に、エアコンにスイッチが入った。やった、やった。2年越しの懸案が解決した。勝利の快感に酔いしれる。これだから電子工作はやめられない。このあと、ウェブサーバーへの移転にも成功したのだが、紙数が増えてきたのでこのへんで一段落としよう。

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

2018年4月14日 (土)

CNCマシン(3)遅れていたが、遂にプリント基板初切削に成功

 このところ順調に20日程度の間隔でアップしてきた記事が今回は遅れている。道草を卒業してCNCマシンの工作にやっと戻れたのに、ちょっとしたことでまた止まってしまったからだ。それでもその後やっとプリント基板の初切削に成功した。基板も動いて長年の念願がかなった。

前回のBluetoothによるUSBシリアルのワイヤレス化について(3/12/2018)
 本題に移る前に、先の道草の報告をしておこう。USBシリアルデータをBluetoothで送り、CNCマシンをワイヤレスで動かす話である。

 いくつかの障害を越えて、前回までにRaspberryPi Zero W(以降raspi0W)のUSBシリアルポートは、Bluetoothを通して、別のPCの仮想シリアルになった。接続の開始に少しコツがいるが、送受信とも安定して動いた。ただ、少し画面の展開が遅いのが気になる。Grbl_ble

 残るは、実機のテストである。raspi0Wの基板をCNCマシンの横に持ち込んで、USBケーブルをRaspiのホストUSBソケットに接続する。少し離れたPCではBluetoothの仮想シリアルポートをCNC制御ソフトCandle(Grblcontroller)のシリアルポートに指定する。このPCでCandleが動けばワイヤレス化は成功である。

念のため、PCのTeratermでCOMポート(com10となった)を立ち上げる。すると例の、
Grbl 0.9j['$' for help]
>

という、ArduinoのGRBLのWelcomeメッセージが出た。$などのコマンドのレスポンスも正常だ。良いぞ。次はいよいよCandleの始動である。立ち上げたあと、設定で、bluetoothのCOMポートを指定する。

 うーむ、つながったような、つながっていないような。画面では、ジョグダイヤルの画面部分が黒くなり接続しているようだが、反応はない。そのうちエラーメッセージが出て、画面の制御部分がグレーになる。たまにスピンドルが回り出すが、止めることは出来ない。

 こういう制御系でこの安定性ではとても危なっかしくて使えないのだが、根がしつこい性分である。あきらめきれずロジアナを持ち出して、シリアルデータをCNC2418のコントロールボードから採って調べてみた(ストロベリーリナックスがおまけにつけてくれた極小プローブが役に立った) Dsc01408

 その結果、シリアルデータは正しくPCからここまで送られているが、Candleがレスポンスを返していない。懸念したとおり送受信の反応が遅すぎ、タイムアウトとなっている公算が強いことが分かった。

 データの中継をしているRaspiでのPythonプログラムの問題である。プログラム上は単純に来たデータを送っているだけで余分なことは何一つしていない。従って、これをさらに高速化するには全く別のことを考えないといけない。残念ながらこれ以上は無理だ。ここは潔く諦めるべき時だろう。 Grblstart

 ということで、このUSBワイヤレスプロジェクトは、これで一区切りとする。PythonとBluetooth、それにRaspiでのリダイレクトの勉強が出来ただけでも収穫だと考えよう。

PCB(プリント基板)制作の進行に戻る(3/15/2018)
 MDF板の彫刻以来、止まっていたCNCマシンの工作を再開する。Easelで作ったMDF板の切削はとても順調に出来たが、こちらが主力でやろうとしている基板切削は、基板データの制作途中で止まったままだった。

 基板の回路は、これまで幾多の挑戦をしてきたDC-DCコンバーター基板である。KiCADで設計データは大体できていたが、サイズが問題だった。今まで汎用の表面実装基板で作ったものより小さくすることが難しくて、そのままになっている。 Ws000001

  久しぶりにKiCADを立ち上げ、コンバーター基板の小型化を再開する。DC-DCコンバーターは、これまで3個以上の基板制作をやってる。少なくともこれより大きくしたくない。入出力間のピン間隔が20.32ミリ(mil規格で8ピン)、全体のサイズで25X15ミリ以下が目標である。

 一時的に嫌気がさして先に進まなかったのだが、時間を空けたのが良かったのだろう、何故か順調に手が動く。ほどなく目標のサイズにすることが出来た。このソフトに慣れてきたのかもしれない。配線チェック(DRC)も問題ない。最後のステップ、べたアースにして状態を見る。

 あれえ、出力側のピンの周囲のべたアースがおかしい。ここはかなり部品を寄せたところだが、べたアースのパターンは前のピン位置のところを基準に描かれ、このままではショートしてしまっている。

 うーむ、前の部品データが残っていて悪さをしているようだ。そう言えばピンを移動した時、パーツエディターではピンのフットプリントと形状枠がずれておかしなことになっていた。この部品(2ピンヘッダー)を一旦削除し、新しいデータを持ってきたが、事態は改善されない。

 KiCADの不具合に間違いないが、今これにかかわっている時間はない。プリント基板エディターのデータをすべて消去し、回路図エディターからネットリストや部品抽出を再度やりなおし、そっくり基板エディターのデータを作り直した。

 何回目かの手順なので作業が早い。すぐ基板が完成した。べたアースはどうだ。大丈夫だ。余計なものはついていない。前のデータのミスも見つけられたし(片側のピンヘッダーがmil規格でなかった)、KiCADの習得にもなった。言うことはない。そう、所長は究極のプラス思考人間である。

Gcodeを出す工程に移る。聞きしに勝る複雑な工程に四苦八苦(3/19/2018)
 次はいよいよ難関のCAMデータ変換である。いやいや、これがこんなに大変とは思っていなかった。KiCADのガーバーデータ(基板情報を網羅したもの)からCNCマシンの制御コマンドGcodeに移すのは、膨大な手順が必要である。 Ws000002

 ひとつひとつが複雑な手順で出来ているので、沢山の設定が必要なのはわかる。しかし、途中の工程が多すぎる。でも、悪戦苦闘したおかげで今までちんぷんかんぷんだった事情がだいぶ理解できるようになった。ガーバーデータなどというCAM技術用語をそれなりに駆使できるほどになったのは大したものだと自画自賛する。

 面倒な理由は他にもある。KiCADからGcodeを出すには定番のルートというものがなく、多くのやり方があって何を選べば良いのかわからないことだ。素人にとっては複数の手段があることはかえって難しくする要素である。

 しかし、泣き言を言ってもいられない。せっせとウェブサイトを逍遥し、一番楽そうな方法を探求する。検討の結果、FlatCAMが一番主流なようなので、これで先に進むことにする。こういうのは善悪を抜きにしてやっている人の多い道を選ぶというのが一番という「ずるい」考え方でもある。

 FlatCAMの解説は色々あるが、ここあたりが一番詳しくておすすめである。こちらも詳しいが、ちょっとわかりにくい。

べたアースのGcodeが難しい(3/22/2018)

 べたアースの切削がやはり最大の難関だった。境界部分の切削パスは、カッターの切削幅だけを注意していれば良いのだが、べたアースを指定すると、どこにも接続されない島が残る。この残った部分を削除する、いわゆる、べた抜き銅箔部の削除(noncopper削除)手順が思ったように働かない。

 ゾーンを指定すると、その部分の島の部分を削除するパスを作ってくれるはずなのだが、ゾーンの範囲がうまく決まらず、ソフトがハング状態(ゾーンを調べまわっているのか)になったり、とんでもなく広い部分がごっそり指定されたりする。

 結局、KiCADから FlatCAM、さらに CandleのGcodeまで行き来してやっと切削できそうなGcodeデータが揃った。 べた抜き銅箔は、ゾーンではなく切削パスを追加する手順がFlatCAMにあるので、これをせっせと島になった部分に書き込んで、切削データを揃える。

 いやいや、一癖も二癖もあるフリーソフトである。何とか出来上がった。実際のデータをCandleに持ち込んで、エンドミルをつけない運転(カメラリハーサルか)を開始した。ふーむ、予想通り動いているようだ。 Ws000000

 それにしてもこの熱中ぶりは自分でも驚くばかりである。難しいから面白いのか、夢中でデータをいじる。うっかりすると、エンドミルを基板深さまで打ち込んで、いきなり走り出すGcodeを吐いたりするので、油断はならない(あっという間に刃を折っておしまいになる)。

基板(PCB)の初切削は思ったより順調。しかし穴あけができない(3/25/2018)
  リハーサルがうまく行ったので、本番の切削に進む。最後の工程である。基板切削なのでZ軸の補正をするheightmap機能が活躍する。切削の範囲は小さいのでheightmapのデータ収集は簡単に済んだ。 Dsc01411

 いよいよ、Vカッターを付けてPCB(プリント基板)の切削である。最初はカッターの位置をきっちり基板にあてなかったこともあり、遠慮めの切削となって銅箔を削るところまでカッターが行かなかった。

 切削の深さを少し増やし、Z軸の原点をさらに近づけた2回目は、うまく行ったのだが、掲載写真の通りY軸のステッピングモーターが最後の最後で空回りし、外周の切削が基板を横切ってしまって失敗した。3回の試行でほぼ考えているような基板が削れた。スピンドルは全速ではなく60%で音は殆ど気にならない。 Dsc01413

 切り離しまで行って重大な誤りに気付く。ドリルビットに換えようと手持ちのプロクソンのミニリューターのビットをとりだしたら、何とここのシャンクサイズは3.0ミリだった。CNCマシンは3.175ミリである。3ミリのコレットチャックの持ち合わせはない。

 やれやれ、このドリルビットは使えないのか。これは大誤算である。ドリルビットはこれを流用することにしていたので何の用意もしていない。あわててアマゾンで適当なドリルビットのセットを発注する。アマゾンだからすぐ着くと思っていたが送られてきた書類の到着予定日を見て目を疑った。

 何と、10日以上もかかるという。アマゾンだけど販売している会社は中国だった。うーむ、注文の時に良く調べるべきだったが、もう遅い。まあ、余り慌てても仕方がないので、到着までやり残していた工作で時間をつぶすことにする。

中国からドリルビットが届くまで、他の工作で気を紛らわす(3/27/2018)

 やり残している工作はいくらでもある。まず、このあいだESP8266でワイヤレス化したロボットアームの暴走抑止である。制御系の電池がへたるとアームが暴走するのを止めたい。このあいだ全てのモーターが動き出して、大騒ぎになった。

 この原因はわかっている。これまで参考にさせていただいたプログラムがもともと負論理だったが、これをそのままにしたので、3V以下でも動くモータードライバーに0のデータが送られて、すべてのモーターが全開になるというオチである。

 これを逆にするソフトの改修である。サーバー側の改修だけで済むはずだ。でも気持ちが悪いので、クライアント側のリモコンからもすべて負論理から正論理に換えることにする。作業は面倒なだけで単純な作業だ。

 ところが動かしてみたら全く不審な動きをする。動かそうとする部分が動かなくて他のアームが動く。えー、そんな器用なことを誰がする。あらためて慎重に工程を確認した。サーバー側のESP8266のコンパイルがテスト用にだけ済んで、本番のロボットアーム基板に換装するのを忘れていたことがわかる。 Dsc01415

 やれやれ年は取るものではない。コンパイルのときは、必ず最初のメッセージなどにコンパイルの記録を残しておくという鉄則を怠った咎めが早速結果に表れた。自戒、自戒である。

 次は、ブレッドボードに組んであったクライアント(リモコン側)をまともなケースに組み込む工作である。久しぶりにサーキュラーソーを持ち出して、基板の端を切り、ケースの上蓋にタクトスイッチの穴を開ける。これはこれで面白い。 Dsc01416_2

 電源スイッチは、最初手持ちのスライドスイッチですますつもりだったが、ウェブで小さなロッカースイッチを見つけて、急に気が変わり、Aitendoで沢山のロッカースイッチが売られているのを発見し、急遽、足を延ばして買いに行ったりした。

 こういうものは実際に手に取って調べるのが一番確実だからだ。Aitendoはウィークデイだったが、前にも増して客が多い。品数も増えたようである。付近には、全く別の電子部品の小売店ができたりして町が何となく以前と雰囲気が変わってきた印象だ。 Dsc01418

 やることがなくなって、レーザーカッターの準備まで始める。お馬鹿なことに買ってあったレーザーは0.5Wの一番小さいレーザーユニットだった。慌てて5.5Wの別のユニットを注文した。$100以上する。道理で最初に払った金額が小さかったわけだ。

届いたドリルビットは初回でポッキリ。スピンドルが回っていなかった(4/8/2018)
 ビットが届いた。基板に両面テープを貼り(基板カットまでしてしまったので)、マシンにセットして、以前の合わせ位置を頼りに位置決めをする。ジョグを動かして合わせるが、目視ではなかなか合わない。

 リハーサルを何度も繰り返し、何とか許容範囲に納まったので、意気込んで切削開始ボタンを押す。あれ、スピンドルが回らない。えー、という間もなくドリルビットは目的地まで動いて、静かに下がって行き、リセットスイッチを押す暇もなく、たわんだところでソフトはエラーで緊急停止した。 Dsc01414

 ステッピングモーターが高負荷で止まったらしい。リセットなど押す余裕など全くなかった。真っ赤なエラーマークを解除し、祈る気持ちでZ軸を上げたが、残念ながらドリルビットは数ミリのところで折れていた。

 スピンドルが回らなかった原因は、Gcodeではない。リハーサルのときに用心してモーターの回転を止めるため接続コードをはずしてあり、それを開始前に確認するのを怠った、誠に単純なチェックミスである。 Dsc01419

 まだ、ひとつも穴を開けないうちにドリルビットを失う。情けなさに何故か思わず笑いがこみあげてくる。やれやれ、あれだけ用心していたのにこのざまだ。たかだか一本¥100のビットだが、このあいだ1 万円以上入った財布を落とした時よりはるかにショックが大きかった。

 それでも気を取り直し、ビットを取り替えて(0.6 -> 0.5mm)工作をすぐ再開する(俺も懲りない男である)。今度は全速でスピンドルモーターを回しながら再開。無事、穴あけに成功した。それはそうだ、穴開けといっても今度の基板はわずか6か所である。 Dsc01421

 ただ慎重になりすぎ、穴あけの深さが足らなくて全部貫通していない。基板は作業盤からはずしてしまったので、リューターで、0.5mmの貫通と、ピン穴用の1mm穴あけをやる。これで、すべての工程は終了した。当研究所の初の基板切削は、ほろ苦い出発となったが、とりあえず一段落である。

一気に実装。よーし、一番性能が良いぞ(4/9/2018)

 基板切削終了のところでブログの記事にしようと思っていたのだが、部品のハンダ付けを試しに始めたところ、止まらなくなった。プリント基板は迷うことがないので次から次に進む。既に部品はビニール袋にすべて用意してあったのでなおさら止まらない。12個の部品実装はあっというまに終わった。 Dsc01422

 ここまできたら動くのを確認したい。これも我慢できない。ブレッドボードに基板を差し(これが使えるようにmilピッチにこだわった)、早速、これまでの基板とダミーロードのセメント抵抗も持ち出して実験を開始する。

 あれ、電圧が一定しない。一旦上がった出力電圧は、そのまま下がってしまって電源電圧と同じになる。早速、実体顕微鏡で仔細にハンダ付けをチェックする。すぐ不良個所が見つかった。電圧調整用の半固定抵抗のピンのひとつがどうもくさい。試しにピンセットで強く押すとピンが外れた。ここをしっかり固定しなおす。 Dsc01423

 よーし、所定の電圧が出た。さあ、これからが本番だ。ダミー抵抗で負荷をかけてテスト開始。これまでの自作基板では、250mAくらいまでは良いのだが、400mAを越えると出力が9Vを維持できなくなる。(7V程度に落ちる)

 さあ、こんどのやつはどうだ。うむ、250mAではこれまでのものと同様全く問題ない。400mAはどうか。やった。良いぞ。9Vに近い8.8Vで頑張っている。

 市販の大容量をうたったDC-DCコンバーターでも400mAを越えると、この程度の電圧降下はあるし、自作にしては上出来である。胸を張ってブログに報告できる。 Dsc01424

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

2018年1月15日 (月)

遂にCNCマシンキットを発注。細かい工作をしながら待つ

みなさま遅まきながらあけましておめでとうございます。
 おかげさまでこのブログは発足以来10年にもなりました。最近は記事の更新間隔が広がり、アクセス数も漸減しておりますが、自分として電子工作は定年後のライフワークとして欠かせない活動のひとつとなっています。

 このブログも少しは人の役に立っていることを感じる時がたまにはあり、自分の好きなことで人に喜ばれることは無上の喜びでもありますので、止める気は今のところ全くありません。この自己満足を満たしつつ、細く長く続ける所存でありますので今後ともよろしくご支援のほどを願っております(コメントがとても励みになります)。

 さて、今年は表題にありますように、とうとう念願のCNC(コンピューター制御)工作機の開発に挑むことにしました。当研究所の究極の目標のひとつでもあります。年末からこれまでの活動経過を以下にご報告します。

年末に意を決してCNC工作マシンに取り組むことを決定(12/27/2017)
 遂に中華CNCフライス盤キットを発注した。これまで欲しい欲しいと思っていたコンピューター制御の工作機械である。

Dsc01311_2  フライス盤とは高速で回転する刃物(ビット)で素材を切削し部品を作る機械のことで、プロの世界では、古くからコンピューター制御で自動的に作ることが当たり前になっている。最近はアマチュアの世界でも普及が広がってきた。

 しかし、ちょっと前までアマチュアが手の出せるCNCフライスは、どんなに安くてもキットで10数万円した。自作するのはもっと大変だった。市販のミニフライス盤を改造するにしても、相当な工作の熟練度と経験を持たないと近寄れない世界であった。

 それが中国製のCNCフライス盤キットならフレームからモーター、制御基板など全部合わせて、なんと数万円で手に入るのだ。ネットには続々と制作記が掲載され、評判も悪くない。

 情報が豊富になったので、中華キットでも不安がなくなってきた。これはもう作るしかないだろう。この制御コンピューターがArduinoというのも時代を感じさせる。やってみたいのは、プリント基板制作である。いわゆる乾式プリント基板である。

 発注先は、この前のオシロと同じAliexpressに決めた。沢山のショップが同じようなものを売り出している。良く見ると少しづつ微妙に違っていて同じではない。これを比較するサイトもあったりして選ぶのに参考になる。先月あたりから、色々物色して、多数の人が選んだCNC2418で、買うところは、一番安心できそうな、ここに決めた。

 発注の時、ついでに5.5Wのレーザーユニットもつける。フライス盤がCNCレーザーカッターに早変わりだ。3ミリくらいまでのアクリル板の切り抜きが出来るという。これまで実用品にこだわってきた電子工作だが、こんどのプロジェクトは究極の実用化である。 Ws000003

 ロボットアームなど、いくらこだわっても所詮は玩具である。一方、CNCマシンはこれをもとに、プリント基板や、ケースを自作できる。実用という意味では、「しかけ」を再生産する「しかけ」ほど実用的なものはない。

 価格は何とレーザーユニットも含めて$148、送料$50、あわせて$200たらず。関税がかかるにしても、日本円で2万5000円以下である。本当にこんなに安くて良いのか、画面の前で一抹の不安がよぎる。

 しかし、ここまで来て引き返すわけにもいかない。自分ひとりで興奮しながら、深夜、購入のボタンを押した。手元に届くには暫く日がかかりそうだが、楽しみに待つことにしよう。

参考にさせてもらったサイト。
CNC制御の自作レーザーマシンや、ルーター(フライスまで行かないか)マシンの全体俯瞰には、次のサイトがおすすめ。
自作CNCマシン・レーザーカッターについて

中華CNCマシンの制作や調整は以下の2つのサイトが細かくて懇切丁寧。必見である。
みら太な日々

マーティーの工房日誌

中華CNCマシンの比較は以下が詳しい。結局ここと同じものを選択。
念願のCNCフライスをついに注文……ただし、激安の中華CNCだがな

(無断引用ご容赦)

秋月電子で安いLDOを見つけた。秋月のLDOが勢ぞろい(12/29/2017)
 キットが来るまでには日数がかかる。調べたいことは調べつくした。何か手を動かしていないと落ち着かない性格になっている。ということで、これまでやりのこした細々とした工作で、気を紛らすことにした。

 ロボットアームのリモコンは、まだブレッドボードの上の仮ごしらえである。いずれケースに入れるつもりだが、せめて電源だけでもバッテリーにしようと、部品箱にころがっているリチウム電池を取り出した。

 リチウム電池は、満杯のときが4.1Vで、公称が3.7Vだ(危険水位は3.6Vでこのあと急激に下がる)。3.3Vディバイスのためには、いわゆるLDO(low drop out)3端子レギュレーターの出番である。

 当研究所には、既に沢山の3.3V用のLDOレギュレーターが揃っている。レギュレーターによっては、発振したり、なかなか定電圧にならなかったり微妙にやっかいな部品である。しかも、過去にはレギュレーターを2つも焼損させて「復讐」を受けたりしている。

 最近のディバイスの電源電圧は3.3Vが多い。RaspberryPiやESPシリーズなど、これらは消費電流が多くて、電源の容量不足で問題が続出し、ネットが一時この話題で大いに賑わったことがある。

 このとき、ねむいさん達が推奨していた3.3V用の強力なレギュレーター、ADP3338が、秋月でも売り出されているのを発見した。しかし高い。ひとつ¥300もする(DigiKeyではもっと高かった)。

 どうしようかなと、さらに秋月サイトを眺めていると、LDOのジャンルで、日本無線のNJM2845というチップが目に止まった。こいつは最大出力が0.8Aと少し低いものの(ADP3338は1A)、最小ドロップ電圧が0.18Vという優れものである(ADP3338は0.19V)。価格はなんと1/6の¥50。これは買うべきだろう。

Dsc01310  それに、LT1963というLDOも売り出されていた。これは小さいけれど1.5Aも出せる強力なLDOで、ねむいさんがかなり前に推奨していたことがある。しかし、これも少し高くひとつ¥200もする。でも何となく気になったので、暮れの秋葉原に出て、これら話題のLDOをまとめて買ってきた。

 買ってきてとりあえずNJM2845のブレッドボード用のミニ基板を作る。こういう工作は楽しい。簡単にできた。早速、ロボットアームのリモコンボードに使ってみる。うむ、これまで、LD3985や、AMS1117では、電池電圧が3.9Vを下回るとリセットを繰り返して動かなくなったリモコンが、快調に動く。

Dsc01308  まあ、AMS1117は最小ドロップ電圧が1.0V、LD3985は、最大出力電流が0.15Aといずれもスペック外になるのだが、同じLDOと銘打っても、こんなに差があることに驚いた。ADP3338ならもっと安定するのだろうが、これは先のお楽しみということで先に進む。

ESP8266の省電力化はうまくいかない(12/31/2017)
 ロボットアームのESP8266は送受信とも電池駆動である。ネット機器は一般に大飯喰らいで、Xbeeなどは数十mA、WiFiのXbeeなどは百mAを越す。ESP8266でもWiFi接続時は同じくらい消費する。そのため、当然、電池駆動などの時のため節電モードが用意されている。

 ESPシリーズ(ESP8266やESP32)はこれまで動かすことに専念してきたので、省電力化の機能は横目で見るだけだった。手が空いたので、少しは省電力化しようと調べてみた。このサイトの情報が良くまとまっている。

 それによると、3つのモードのうち、使えそうなのはlight sleepである。ただ、今度のロボットアームは、送受信とも常にネットで相手の状況を調べている。こういう常時ネットと交信するシステムでは余り効果がないように思われるが、こればかりはやってみないとわからない。

 省電力の設定そのものは、リセットを伴うdeep sleep以外はソースコードに手を入れる必要は殆どない。単に設定のAPI関数、 wifi_set_sleep_type(LIGHT_SLEEP_T) を入れるだけである(モデムスリープはMODEM_SLEEP_T)。

 deep sleepはプログラムがリセットされるから、プログラムの構造を変える必要があり、立ち上がりのトリガーをコーディングしなければならない。今度のプログラムではこれを使うことが出来ない。

 送受信とも、このlight sleepでテストしてみた。結果は全く影響がなかった。sleepを入れる前、受信側(サーバー)は交信前で、93~98mA、送信側(リモコン側)は、108mA程度で、交信が始まると、受信側が120mAに跳ね上がり、送信側も、134mAに上がる。

 sleepを入れると、受信側は、交信中で136mAとかえって悪化してしまう(送信側は変化なし)。休止するための何らかのオーバーヘッドがあるのだろう。プログラムの構造を考えずに、こういうステートメントを入れても効果がないことが良くわかった。

 測定は、電源に0.5Ωの抵抗を挿入し、両側の電圧をオシロで100mV/divで測った。今度のオシロは測定機能も充実していて、平均電流や、RMS(二乗平均)値も出してくれる(上記数値はすべてRMS値)。

 さらに、測定量が多いので、時間軸を拡大してもちゃんとデータを持っている。前のオシロでは、持っているデータが少ないので、少し詳細を見ようと、時間を広げると、すぐ波形が凸凹になって絵にならなかった。

 落ち着いた大晦日。電流の計測で、日がな、ゆったり時を過ごす。東京では雪が降ったそうである。こちらは雨だったと家人が言う。都心の方が雪というのも面白い。

めげない性格。何とかクライアント側を半分にする(1/4/2017)
 何事もなく新年を迎えた。近くの神社に初詣に行き、箱根駅伝を見てしまうとやることがない。CNCキットは正月中なので来る気配はない。で、年末挫折したESP8266の省電力化をあきらめないでしつこく続けることにした。

Dsc01305  要するに、断続的な観測以外の用途では、deep sleepは使えないし、無理に入れてもリセットなどで結果としてトータルとしては電力増の可能性がある。light sleepもネットが動いているときは殆ど無力だ。

 従って、UDPパケットがくるのをひたすら待つサーバー側は、省電力にすることは難しい。調べる間隔を延ばせば、反応が遅くなるだけだ。残るはクライアント側のリモコンスイッチのところである。

 少なくても、スイッチを押すまでは送信を休止していれば、少しは減るのではないか。再び、オシロに火を入れて測定開始である。まず、何もしない時の電流量は、先に紹介した通り100mAを越えている。一定の間隔(17ms)で常時パケットを送る仕様なのでこんなものだろう。

 そこで、スイッチを押したときのみUDP送信をするようにソフトの修正を行った。これがはまったのである。うまく動かない。電池が不足してコアダンプを始めたり、memcpyの標準関数がおかしくなったり、さんざんな目にあう。

 久しぶりの疑似コーディングで考え直す。スイッチを押した後の処理が難しい。うまく止まってくれない。フラグやスイッチはなるべく使いたくない。苦労の結果、前の状況を残しておくロジックで省電力化に成功した。電流量は60mAと半分近くになった。

 オシロで調べたところでは、最初、フルにネット接続をしているようだが、暫くすると休止モードに移行し(ベースの電流ががくっと下がる)、消費電流が低くなる。しかし、WiFiネットの継続のための内部のヘルスチェックの交信が入るようで、たとえアプリで送信を止めていてもこれ以上、下げるのは無理なようだ。

遂にCNCマシンキットきたー(1/9/2018)
 そうこうするうちに、思ったより早く暮れに発注した中華CNCマシンキットが到着した。AliExpressは注文確定から入金報告、出荷の有無などを逐一メールで報告してくれる。運送会社はEMSでこれも荷物の状況をかなり詳しくサイトで確認できる。

 ついでに発注したレーザー光線防眩ゴーグルは、本体より早く日本に到着していたようだが、受け取ったのは同時だった。外出中に家人が受け取ったのだが、関税は全く請求されなかった。送り状には、¥744と明記があるのだが、配達員は何も請求しなかったという。忘れたのかもしれない。Dsc01306

 荷物を記念撮影する。写真で見ていたのだが、思ったより小さい。しかしかなり重い。梱包も中国からにしては、歪みも殆どなくきれいな荷姿だ。さて、これから苦難の道が始まる。しかし、これは楽しみでもある。

 しばらく当研究所のブログはこの話題が続き、電子工作どころではなくなるが、まあ、AVRと銘打って今は殆どAVRをいじっていない。気儘にやることを勘弁して頂きたい。さきほどの先人たちの克明な制作記があるので何の不安もなく作業を開始できる。みら太さんの制作記事が一番詳しくてわかりやすい。

 梱包を解く。ありゃ、レーザー光線防眩ゴーグルが添付されていた。機材そのものは彼のキットとは微妙に違うところがあるが、大筋では同じ。X軸の動きが、彼のは渋かったようだが、こちらは、全く問題なくスムーズだ。反対にY軸がいまいち動きが悪い。レベル出しが必要なのかも知れない。

何とか動いたが、これからが大変(1/14/2018)
 残念なことに、我が家には水平を出せる定盤のような設備はない。床のフローリングも水平なようで、細かく歪んでおり、スマホの水平レベルアプリで調べても、これを頼りに水平を出すのは意味がなさそうである。

Dsc01307  実は当研究所では、ずいぶん昔、みら太さんが使っているダイヤルゲージを購入している。何のために買ったのか今になると思い出せないのだが、これを使えば相当精密な水平レベルを実現できそうだ。しかし、問題はフレームのレベル出しだ。色々考えた末、べニアの安い製図版を買って、ここで水平にすることにした。ネットで発注したが、到着まで10日近くかかるとメールが入った。

 待っていられないので暫定的な水平出しで我慢して、組み立てを急ぐ。4日ほどかけて無事完成した。組み立て過程は、これまでの複数のサイトの説明で十分なのでここでは省略する。最初は、このマシンの主要枠材、v-slotの取り扱いに難渋したが(後入れナットがうまく入らない)、これも慣れてくるとだいぶ楽になった。

 フレームが組みあがった。ステッピングモーターと、送りねじの接続で一苦労する。送りねじの長さが、X軸とY軸で微妙に違い、最初、逆につけてつながらない、つながらないと焦っていたり、基板の取り付けでフレームがずれているのに気が付かなくて(ここのずれは他と関係しない)、もうちょっとで取り付け穴を広げそうになったり、ドタバタはあったが特に大きな問題はなく組みあがる。

 電子回路の配線は、単にモーターのケーブルを基板につなぐだけである。あっけなく、終わった。さあ、今度はソフトの準備だ。実は、ソフトのインストールが一番てまどった。付属のDVDからPCに持ち込もうとするとエラーが出る。しかも英文用のGRBLはDVDで立ち上げようとするとアプリケーションエラーで止まる。

Dsc01312  あちこちいじったが、中文用のGRBLがDVDから動くことがわかった。紹介ネットサイトでおなじみのgrblControlの画面が出た。とりあえずこれでモーターの試運転まで行くことにする。USBをつないでUARTを接続、画面が変わった。

 動いたー。jogという手動のボタンで上下左右に動かす。いやあ感激、感激である。GRBLインストールのトラブルは、原因究明より大もとのサイトから正式のソフトをダウンロードしてめでたくHDDから起動できることを確認した。なんと全てオープンソースなのだ。これが中華製品躍進の理由かもしれない。

 とりあえず動いたというだけだが、ブログはこのへんで一段落しよう。残るは、防音ボックスと集塵装置の整備である。Fusion360のための64ビットOSの準備も待っている。ひょっとすると、このあたりの整備の方が本体より高くつくかもしれない。

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

2017年12月27日 (水)

ロボットアームのESP8266ワイヤレスリモコン化(続き)

ボタンの操作性を向上(12/8/2017)
 ロボットアームのリモコン(ESP8266のUDPクライアント)操縦用のボタン(スイッチ)は、5つのモーターの作動を指示するスイッチと、その正逆転の共通スイッチのひとつ、合わせて6つである。動かしてみるとやっぱり、アームの上下や左右の回転の操作は、それぞれが独立したタクトスイッチで動かす方がはるかに操作しやすい。

 しかし、ESP8266の使えるIOピンは6本が最大で、増やすわけにはいかない。というのでこのあいだ、I2Cで16チャネルまで増やせるI/OエキスパンダーIC(MCP23017)というのを秋月で買ってきてあるのだが、まあ、ここまでこだわることもあるまい。

 つらつら考えているうちにアイデアが浮かんだ。タクトスイッチは5X2の10個を並べ、対のボタンには、正転逆転のモードが同時に通電されるようなハード的なやり方を加えれば実現できるのではないか。例えばダイオードみたいなもので。

Tactsw_with_diode

 その昔、少年時代の頃、階段の明かりを単極双投のスイッチ2つでどちらから点けても、その先で消せるという回路を知って、ひどく感動した記憶がある。今度はそれほどでもないが、思いついたときは近来になく興奮した。

 でも、本当に動くのだろうか。これは試してみるしかない。小信号用の順電圧降下の少ないショットキーバリアダイオードの買い置きがある。早速、これを持ち出して同時に押す側のタクトスイッチから、正逆転のモードのピンと、本来の制御ピンに対して順方向に2つのダイオードをつなぎ、LEDをつけてみた。

 見事に、2つのLEDが考えたように点灯した。いやあ嬉しい。ウェブで調べると、キーマトリックスではダイオードが盛大に使われていることを知った。まあ車輪の再発明みたいなものだけれど、自力で思いついたところが偉いと自分で自分を褒める。

組み立てたけど動きが遅くなった。電池切れでもない(12/9/2017)
 遊んでいるうちに、アームの動きが急に鈍くなってきた。単一電池なのでまだまだ大丈夫なはずだが、グリッパーでものをつかんで運ぶのに結構長時間夢中になって動かしている。気がつかないうちに、電池がへたったのかもしれない。 Dsc01269

 オリジナルの電源は、単一電池4本を直列に接続し、その真ん中を共通グランドにして、これだけで正逆転の運転を巧妙に実現しているのだが、リモコンにするときは、この配列をモーター電源と制御電源(ESP8266とモータードライバー)に独立させて供給するように変更した。

 制御電源は、多くても数十mAしか流れない(但し、連続して流れる)。一方、モーターの方は数百mAではるかに消費が激しい。そこで、これを制御側と交換してみた。これで元気が戻るはずである。しかし、同じように勢いがない。ふーむ、これはおかしい。電池切れとは考えにくい。電圧を測るとモーター側もまだ一本1.5V近くある。

 マルチメーターで各部の電圧を測る。確かにモータードライバーのモーター出力は正規の1/3に近い1Vしか出ていない。念のため制御側のGPIO電圧も測る。おかしい。ここも1.8Vくらいしかない。ESP8266のGPIOピンのプルアップ不足かと思い、4.7KΩの少し強めのプルアップ抵抗をつけるが全く効果はない。

 モータードライバーDRV8835が早くも駄目になったのだろうか。ウェブで調べる。モータードライバーの損傷の原因は、過電圧、過電流、逆接続、モーターなどの逆起電力とある。電池なので過電圧はあり得ない。過電流に対してはモーター回路には用心して0.9A(遮断1.8A)のポリスイッチを入れてある。 逆向きに通電した覚えもない。

 ただ、モーターの逆起電力を抑えるダイオードは入れていない。考えられる原因は、やはり、逆起電力なのだろうか。しかし、リレーなどと違って正逆転するHブリッジのモーターの逆起電力を逃すダイオードの付け方がわからない。

 DRV8835がモータードライバーと銘打つからには、こうした備えは当然あると思うし、データシートには何の注意書きもない。しかし、現実には、モータードライバーがへたったとしか考えられない症状だ。仕事の帰り、秋葉原の秋月によって腹立ちまぎれにDRV8835を5つも買ってきた。

 交換する前に、念のため各部の電圧を測ってみた。すると奇妙な結果が出たのである。モーターの起動/停止ピンの電圧は低いが、左/右を決めるピンは、ばっちりVccと同じ電圧が出ている。

 おかしい。これは何か発振している。マルチメーターなので平均電圧しかわからないが、その可能性はある。 こうなると、オシロの出番だ。必要なピンにハンダ付けで臨時のプローブを出し、それをブレッドボードに差して動かないようにして慎重にIOピンの電圧波形を測定することにした。

オシロがお手柄。あけてみたら原因はハードではなくソフト(12/14/2017)
 実はオシロ測定に入る前に基本的なミスで大はまりした。こんどのESP8266受信サーバーは、モーターと制御系の電池を別にしているため、共通のグランドつまりローサイドで電源を切っている。これが原因で小一時間、頭を抱え込んでいた。

 念を入れてマルチメーターで電圧を測っていたときである。電源スイッチを入れてもいないのに電圧がでている。おかしい、どうしてだ。始めはスイッチがこわれているのではないかと疑った。しかしスライドスイッチがそうそう壊れるわけはない。

 ローサイドで電源を切っているときは、グランド側のプローブは、電池側でなく、スイッチの手前(回路側)にプローブをあてないといけないというのに気が付くまで暫く時間がかかった。図に書いたら一発でわかるミスだが、ブレッドボード上では中々わからない。実に情けない話である。

Dsc01265  この騒ぎが一段落して、やっと、オシロでGPIOピンの波形を出すところまで行った。そして、出てきた波形を見てさらにびっくりする。全く予想もしていない波形だった。最初、発振を疑っていたのでアナログっぽいランダムな波形を予想していた。

 それが、何とピンの電圧が、きれいなパルス状に出ているではないか。発振ではない人工的なパルス波形である。あっと思い当たった。これはソフトで作った波形だ。間違いない。

 動き始めた当初、暴走を止めるために受信メッセージが切れたときサーバー側で、とりあえず全ての制御を止めるロジックを入れた。こいつが原因に違いない。データが来るより、処理の方が速いため、次の受信データが来る前に制御は全部止まり、次のデータで再びONされる。

 マルチメーターでは平均電圧しかでないのでこの状況はわからない。ちょうどPWMのような動きをして回転が下がっているだけだ。モータードライバーはおかしくない。正しく動いている。全部自分が悪いのだ。モータードライバーさん疑ってごめんなさい。

 いやあ、世の中というのは恐ろしい。最初考えていた原因とは全く違っていて、犯人は暴走防止に気楽に入れたコードだった。ハードを疑った因果応報で、所長の本業のソフトの世界に弾が戻ってくるとは良く出来た話である。

無事、ロボットアームは元気を取り戻したが(12/16/2017)
 待ち時間を調整して、送る間隔と、受け取る間隔を同じにし、受信側も、受信データが来ない時は一定時間待ち、さらにデータの有無を聞いて、ないとき始めて制御を止めるロジックに変える。

Dsc01266  これで無事に普通のパルスが出た。ただ、どれだけ短くスイッチを押しても、100msちかいONになってしまうのが少し気になるが、とりあえずはもう大丈夫なはずだ。 もういちどロボットアームを組み立てなおす。試運転である。

 よーし、これまでへたったと思っていた単一電池でも元気よくアームが動いた。いやいや、お疲れさまでした。10個のボタンの制御はとても快適だ。まわりの消しゴムや、電池(単一でも持ち上る)を掴み、所定の位置に運んだりして遊ぶ。

 ロボットアームはワイヤレスで順調に動いた。動かすことが目的なのでこれでプロジェクトは大団円である。しかし、奥歯にものがはさまったように気になるところがまだひとつある。ワイヤレスのタクトスイッチをどれだけ短く打っても、モーターが100から120ms、動きを止めないことである。

 これはオシロで測ったときにわかったことなのだが、人間のタクトスイッチの押下の間隔は最小で50msくらいまで短く出来るはずなのにおかしい。実際の動作には殆ど影響がないのだが、何となく気になっている。

ロジアナでUDPを解析することを決断する(12/25/2017)
 現在クライアントとサーバーの間のUDP通信は17msという中途半端な時間間隔(オリジナルのまま)で送受信を繰り返しているが、この間隔で最小の動作時間が100ms以上というのは解せない。

 こうなってくると、オシロではわからない。もしかすると何かとんでもない動きをしているのかもしれない。データが溢れているのだろうか。UDPのパケットが未読のままだと、どういう状態でデータが残っていくのか、ウェブで調べてもはっきりとしたことはわからない。

 気になるといつまでも尾を引く、いやな性格である。オシロではなくロジアナで各部の動きを調べれば相当なところまでわかると思うが、ロジアナは準備が大変なのでなかなか決心がつかなかった。

 しかし、UDPの動きを知る良い機会でもある。ちょうど年賀状も出し終わって手が空いたところなので,結局、机の奥にしまってあったロジアナ一式を持ち出すことになった。

ロジアナで原因は一発で解明(12/27/2017)
 久しぶりのロジアナである。クライアントとサーバーの双方からプローブを引き出す。スケッチにはGPIO一本をつぶして動作点を記録するコードを追加して再ビルド。幸い双方にはUARTがついているのでこれも利用し、全体の動きを調べることにした。

Udpread  その結果、ロジアナはとても正直に実情を伝えてくれた。グラフを見れば一目瞭然である。受信側のデータの有無を調べる関数UDP.parsePacket()が正しく動いていない。暴走を避けるため、この関数を20msほど休んで再発行しているが、そのあとloop()の先頭に戻るので結果としてこの関数を連続して呼んでいることになる。

 UDP.parsePacket()は、連続して呼ぶと正しいデータを返さないようだ。いくつか空振りしたあとデータが入って処理が再開される。そのあいだの5回くらいの空振りが100msの原因だった。

Udp_read  要するに、Arduinoのloop()の中で、待ち時間を入れずにこのコマンドを実行させるとおかしくなる。まあ、通信関係では良くある、不具合とも言えないトラブルである。それにしても、ロジアナはいとも簡単に原因を解明してくれた。

 いやあ、さすがはロジアナだ。原因がわかれば解決は簡単である。loop()のUDP.parsePacket()が連続しないよう10ms程度の待ち時間を設ける。これでボタンの最小時間は50ms程度まで下げることが出来た。

 ま、しかし、それで動作が目に見えて早くなったわけでもない。完全な自己満足の世界だ。それでも何となくキビキビと動くように感じで(気のせいに違いないが)、気分が良い。

Dsc01276  こんどのスケッチのソースは、殆どが人さまからの借りものなので、ここで公開するのはためらっている。UDPのメッセージを漏らさずGPIOピンに反映させるのに少々手を入れたので、みなさんに使ってもらいたい気もするが、機種依存だろうから余り役に立たないかもしれない。

 もしどうしてもということなら、コメントかメールを頂ければ、ご送付申し上げる。

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

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)

2016年12月22日 (木)

ジャイロセンサーMPU6050とProcessingで飛行機の3D姿勢表示

 前から少しづつ進めていたプロジェクト、6軸の加速度・ジャイロセンサーMPU6050をESP8266のArduinoで動かして、PCの画面に3Dの画像(飛行機)を表示する開発がやっと一段落した。MPU6050の基板を手で動かすと、PCの飛行機がそれに合わせて動く。Dsc00804

 当研究所の大きな縛り「実用品を開発する」ことなら、MPU6050は本来ならドローンや2足歩行のロボット(まあ、これも実用品ではないが)に使って始めて開発と言えるのだが、そこまでの足慣らしということで始めた。ところがこれが思ったより難航したのである。Ws000011

Processingの3Dライブラリーが動かない(12/3/2016)
 Processingそのものは、すでに前回、単独で動くことを確認している。これからやりたいことは、MPU6050で検索すると必ず出てくる3Dの飛行機やティーポットをPCのProcessingの画面上で動かすことである。

 ところが3Dに必要なProcessingのリソースをダウンロードしようとすると、殆どの日本語サイトが紹介しているダウンロード先のAndrocityというサイトが変わってしまっていて、先に進めない。

 片っ端からウェブサイトを探し回って何とかファイルを見つけ、インストールには成功した。toxiclibというライブラリーも見つかった。しかし、動かしてみるとProcessingの3D出力のドライバーOpenGLでエラーが出る。平面図形は至極順調に動くのだが、OpenGLが以下のメッセージを出してエラーとなる。

Framebuffer error (framebuffer unsupported), rendering will probably not work as expected

 調べてみると、PCのグラフィックドライバーが古いと動かないようだ。このライブラリ(OpenGL)だけでなく他の3Dライブラリでもトラブっているようで、エラーメッセージをキーにすると海外のサイトが多数ヒットする。

Ws000009

 回避する方法は、残念ながら紹介されていない。基本的には新しいビデオカードに替えるか、メーカーがビデオドライバーを更新してくれるのを待つしかないようだ。しかし後者はこちらの場合望み薄である。

 現用のPCのビデオインターフェースが古すぎる。マザーに内蔵のビデオインターフェースはIntelのG33で、恐らく7年は経っている。最新のIntel汎用ドライバーに更新しようとしても、メッセージは「これが最新です」と出て、状況は変わらない。

 うーむ、買ってくるしかないか。前のPCで使っていた古いRADEONのボードは部品庫に残っているが、これとてかなり古く、動く保証はない。変なところで頓挫してしまった。余り意地になるのはやめようと思うが、どうも気になって他のことに移る気分にならない。

 本来の工作の方向ではない(単なるMPU6050の動作テスト)ので、潔く他のことをすれば良いと思うのだが、へそ曲がりなもので、出来ないとなると余計悔しくて気持ちが納まらない。因果な性分である。

ビデオボードを買ってきて解決(12/6/2016)
 色々迷ったが、次にやることが見つからないので、くだらない話だけれどビデオカードを更新することに決めた。ということで、買うことは決めたのだが、いざ具体的には何を買えばよいのか見当がつかない。PC自作から遠ざかって15年は経っている。

 ネットで久しぶりに「ビデオカード」をキーワードに検索をかけてみた。おお、出てくるわ出てくるわ。この世界はまだまだ活況のようだ。そのうち全体を俯瞰できる親切なサイトを見つけた。なにー、10万円を超すビデオカードが沢山市販されている。中には30万を越すボードもある。これ業務用ではないよね。ハイエンドPCゲーマー御用達のボードのようだ。

 こんな高いボードにはもとより縁はない。お値段は¥5000以下(さっきのサイトのランクでは5段階の下から2番目)、冷却ファンのない静かなボードが条件である。仕事の帰り、秋葉原に寄り、この前PC電源を買い替えたお馴染みのTwoTopで、適当なボードを物色する。ASUSのGeforce GT710を選んだ。¥4200余り。

 家に帰って久しぶりのPC拡張ボードの工作である。ビデオインターフェースのコネクター規格PCI Expressがえらく複雑になっていて悩ましい。バージョンが1から3まである上、2には枝番としてx1だのx16だのに分かれている。買ったきたビデオカード(2.0 x8)が現用のマザーに入るか心配だ。

 スロットに差してみると、何か接続されないピンの空きが多い。不安がよぎったが、とりあえずはきっちり入ったので試しに動かしてみた。BIOSは今のところ何もいじらない。新しいカードの方にビデオケーブルのコネクターをつけて電源を入れてみる。

 良かった。BIOS画面が映った。ビデオカードを自動認識してこちらを使うようだ。ドライバーを入れていないので、MicroSoftの汎用ドライバーで画像は荒いが、Win10までちゃんと動く。付属のDVDからビデオドライバーをインストールすると、正規の1920ドットの画面になった。やれやれ。

 さあ、目的のOpenGLのProcessingはどうだ。おおう、あっさり飛行機が出た。Arduinoとつないでいないので、飛行機はまだ正面を向いたまま動かないが、3Dの部分は問題なく動いているようだ。

 ビデオカードの効果は他にもあった。これまでMicroSoftの無料ゲームの中に、画像の乱れがあったり、やけに動きが遅かったりしたゲームがあったのだが、これらの不具合がすべて解消された。まあ、お金をかけたことは無駄ではなかった。

Processingで画像がグリグリ動く(12/7/2016)
 3Dが出たので、また暫くProcessingで遊ぶ。それこそティーポットやヨット、シリンダーなどの3D図形がマウスの操作で自由に動く。素晴らしい。

 すごく親切なProcessingのガイドがウェブで見つかった。それを夢中になって試す。いやいや、昔に比べると、良くインタプリターだけでこれだけ滑らかな動きが出来るものだと感心する。

 このサイトにも例の3D飛行機(MPUTeapot)の丁寧なインストール方法の紹介がある。この通り忠実に手順を踏めば簡単に動きそうだが、どうもこの前のスマホの無線操縦のように動いた後、何も出来なくなるような気がしてきた。

 もう少し基本からProcessingとArduinoを勉強した方が、のちのち良いような気がする。少し回り道でも、ひとつづつ段階を経て動作を確認していくことにした。ArduinoでMPU6050をドライブし、そのシリアル出力をPCのProcessingで受けて、画像ルーチンの入力にする過程を確認していこう。

 だいたい、MPU6050の6軸のセンサー値の意味も完全に理解しているわけではない。加速度センサーだけで測れるのは、飛行機で言えば、縦揺れ(ピッチング)と横揺れ(ローリング)だけで、縦軸(Z軸)の回転(ヨーイング)は、角速度センサー(ジャイロセンサー)で値を積分しないと測れないはずなのだが確証はない。ちょっとソースを覗いてみたけれど、全く手も足もでなかった。

 独自開発しようと意気込んでいたが簡単に白旗をあげた。このJeff Rowberg氏の開発したMPU6050関係のライブラリーは膨大で、MPU6050.cppなどは3000ステップを超える。I2Cのドライバーだけでも1000ステップ以上で、これを無償で公開されているのには頭が下がる。

ProcessingとArduinoの連携に目鼻がついた(12/10/2016)
 それでも、単にソースをコピーしてきて動かすことだけは避けたい。理由は、コピペだけでは身につかないProcessingとArduinoの技術を少しでも習得しておきたいからである。センサー、MPU6050のI2Cはライブラリを拝借するが、3Dの画像を出す部分は、せめて少しでも理屈を知っておきたい。

 作業を以下のように細かく分割して、ひとつづつ確認していくことにした。

(1)    Processingの学習  例のこのサイトがとても親切に教えてくれる。
(2)    Arduino スケッチとライブラリ構築の復習 これは上記のサイトのここが詳しい。 
(3)    Processingシリアル入出力のテスト
(4)    ProcessingとArduinoのシリアル連携 ここを参考にさせてもらった     
(5)    ArduinoとMPU6050の接続テスト
(6)    ProcessingとArduinoのハンドシェイクプロトコルの決定
(7)    ProcessingとArduinoの接続テスト
(8)    Processingの画像出力のスケッチ作成
(9)    MPU6050とProcessingのテスト

 現在は、(4)まで済んでいる。(5)が課題だ。ArduinoのシリアルコンソールにMPU6050の数値を出すスケッチはたくさんのサイトで紹介されている。これを試すことにする。

ステップ(5)MPU6050の接続テストまですんだ(12/12/2016)
 簡単に通過するはずだったのだが、意外に手間取った。原因はESP8266のI2Cの接続ピンの勘違いである。以前使ったピンアサインのメモに基づいて配線したのだが、MPU6050を認めないメッセージが出る。 

コピペさせてもらったソースに間違いはない(はずだ)。動かないとなると、途端に何も出来なくなるのがArduinoである。ピンの接触不良や、AD0ピンのプルダウンなどを疑うが問題はない。オシロなどを出して波形を見るまでもなく、何か基本的な間違いだと思うが、最初は以前自分で書いたメモを信じていたので途方に暮れた。

 気を取り直してESP8266の正式なピンアサインをネットで確かめる。あっあっあー、SDAピンが違うぞ。なぜだ。どうして間違ったところにメモしたのだ。正しい方にピンを差しなおしテストする。よーし、いいぞ。それらしい値が出てきた。

ステップ(6)(7)は既製のスケッチを流用(12/14/2016)
 次はArduinoのMPU6050のメッセージがProcessingのテキスト画面に出ることを確認する。これは問題なく動いた。ただし、Processingのテキスト画面はスクロールしないので単に、忙しく数字が変化するだけで、見映えはしない。

Procesingserial  Processingのテキスト画面をスクロールするように直したい気持ちが激しく盛り上がったのだが、やっとのことで自制する。ここで脱線するとまた戻れなくなる。我慢、我慢である。

 とりあえず、これでESP8266につないだMPU6050のデータは正しく、Processingに到着した。残るは最後の関門、画像表示である。既成のスケッチのソースを見て調べるが、そう難しいハンドシェイクはしていない。単にメッセージの頭に特定のキャラクター($)を入れて、それをトリガーに後続データを配分しているだけのようだ。

 難しいのはやはりセンサー値の加工である。色々ネットで調べる。クオータニオン(四元数、しげんすうと読む)という3Dでは常識らしい用語を発見して珍しく興奮し、暫く勉強する。いやあ、奥が深い。 

 これからMPU6050から出てきた数値を気安く加工しようと思っていたが、一筋縄で触れるものではなさそうだ。ここは素直に、既成のスケッチを使わせて貰うことにしよう。まずは動かすことが先決だ。

ステップ(8)(9)はMPUTeapot2のプロジェクトをそのまま使う(12/15/2016)
 人さまの動いたソースを借用するのだから、すんなり動くのかと思っていたが、そうは問屋が卸さなかった。参考にしたサイトは、すでに紹介したここである。

 このサイトは、以前、懸命に探し回ったリソースがちゃんとダウンロードできるようになっており、ここだけですべてが動く(実は大きな落とし穴があったのだが)。順調にMPUTeapot2のライブラリを入れてArduinoとProcessingを動かした。しかし、エラーメッセージが出るだけで機体は動かない。

 例のArduinoの弊害である。 スケッチソースは長大で、ちょっと目検したくらいでは何がおかしいのか見当はつかない。手も足も出ない状態だ。まあ、救いは、散々連携テストをしてきたので、ハードなどの問題はなく、動かない原因は現在入れたアプリケーションソフト(のはずだ)だ。

 ただ、エラーメッセージが奇妙である。つながったことを示すステートメントは出るが、何か(割り込み)を待つというステートメントのあと、タイムアウトが起きてリセットされ、これが延々と続く。

Initializing I2C devices...
Testing device connections...
MPU6050 connection successful

 

Send any character to begin DMP programming and demo:
Initializing DMP...
Enabling DMP...
Enabling interrupt detection (Arduino external interrupt 0)...
DMP ready! Waiting for first interrupt...

 

Soft WDT reset  (以下繰り返し)

 何らかの外部割込みをArduinoが待っているような感じだ。しかし、参考にしたサイトの結線図にはMPU6050の割り込みピンの接続はない。他のサイトを見るとMPU6050のINTピンが結線されている配線図や、動画が見受けられる。

 うーむ、どっちなんだろう。Arduino UNOでは割り込みピン#0に繋ぐという説明があるが、ESP8266には外部割込みピン#0はない(GPIO#0はあるが、これは制御用に使っている)。つまり繋ぐところが見当たらない。 Dsc00802

 こうなったら本当にMPU6050が割り込み付きで動いているのか(ソフトで設定できるようだ)、確かめるのが先決だ。もし、割り込みモードで動いているのなら、先の配線図が誤りということになる。

 オシロを持ち出して、MPU6050のINTピンを観測した。ピンポーン!当たりだった。I2Cのメッセージが出される前後に派手に割り込み信号が上がっているのを確認した。そうか、やはり必要なのだ。しかし、割り込み入力はESP8266のどこに入れたら良いのだ?

 恐る恐るArduinoのスケッチソースを調べ始める。良かった。見つかった。setup()ルーチンの中に、割り込みピンの定義をしているらしい以下のステートメントを発見した。

attachInterrupt(0, dmpDataReady, RISING);
mpuIntStatus = mpu.getIntStatus();

ふーむ、ここが0になっている。ESP8266のピン0は、ファーム書き込みの制御ピンのためプルアップされたままで入力には使えない。

やっとのことで飛行機が動いた(12/16/2016)

 ここを適当なピンに定義し直せば良いのはないか。希望の光が見えてきた。こいつをESP8266の適当なピンにアサインする。とりあえず2にしてみる。あせる手でジャンパーをMPU6050のINTピンの間に飛ばし、再ビルドする。

Ws000010_2  動く予感がする。まず、Processingを動かす。Arduinoはまだ電源を入れない。続いてArduino(ESP8266)の電源を入れる。これまではタイムアウトのメッセージが出るだけだったがどうだ。おおー、コンソールに字化けしたメッセージが出始めた。しかし依然として飛行機は動かない。

 割り込みジャンパーコードを抜き差ししているうち、突然メッセージが規則的なデータ列になった。同時に飛行機がズルッと動いた。何かのタイミングでMPU6050が暴走するようだ。ESP8266を立ち上げてから割り込みを有効にすると暴走しないことが多い。

Dsc00807  やった、やった。MPU6050を載せたミニブレッドボードを動かすと飛行機が姿勢を変える。反応はとても早い。やれやれビデオボードまで新調してやっとのことで、画像を動かすことに成功した。何度も電源を入れ直し動作を確認する。ささやかな達成感で胸が膨らむ。

 最後が少し手間取ったが(サイトの記述を信用しすぎた)、動いてしまえば何の問題もない。冷静になって考えれば、実にくだらない作業なのだが、仮説をたてて、ひとつづつ問題を解消し、それが思い通りになったときは、どんな小さなことでも嬉しい。これが電子工作の醍醐味である。

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

2016年11月28日 (月)

行き当たりばったりの電子工作(2)

 WiFiモジュールESP8266とスマホを組み合わせた玩具のクローラーの無線操縦は、ウェブのソースをそっくり頂戴して、すんなり動いた。しかし、Arduinoによる開発なので経験値はさっぱり上がらない。達成感にも欠けるし、先に進もうという意欲がどうも盛り上がらない。

 そうこうするうちに、前回のブログからもう一か月が経ってしまった。これまでの経験で、記事の間隔をこれ以上開けると内容をまとめるのに苦労する。で、まとまりに欠けるが、これまで書き貯めたメモを元にこれまでの活動をご報告する。相変わらずの行き当たりばったりでごめんなさい。

AtmelStudio7がすんなり入った(10/21/2016)
 ESP8266周りの制作が一段落したので、このあいだうまく行かなかったWin10でのAtmelStudio7のインストールを再度試みてみた。AtmelStudioの中核アプリVisualStudioは好きではないが、一旦動けばデバッグ機能が豊富なので動くことに越したことはない(まあ、AVRあたりのソース量ぐらいではあまりメリットはないが)。

 新しくインストーラーをダウンロードし直し、インストールをやってみた。これが何ということか、全く問題なくインストールが終了したのである。時間もそう長くかからなかった。理由はよくわからない。狐につままれた心境である。Ws000000 確かにWin10は1週間ほど前、更新が入った(不本意ながら)。AtmelStudioのインストーラーのバージョンも以前の、7.0-1006から7.0-1188に上がっている。しかし、どうも、これだけの理由だけとも思えない。動いたのは良いけれどあまり気分は良くない。

 実際にプロジェクトを入れて試してみた。正常に動いた。ただ、以前のAVRStudioのプロジェクトは認めてくれない。古いバージョンのImport/exportができるというのでやってみた。Importそのものは正常に終わったが、ビルドしてみるとmakefileでエラーになる。

 以前のAtmelStudio6のときも、こんなことがあったような記憶がある。ライブラリーのディレクトリ位置が、makefileの中身とずれているようだ。こういう統合環境のデバッグは意外に厄介である。ウェブ上で解決策を探るが、有力な情報は得られなかった。

 当面、includeするソースをカレントルート(main.cがあるところ)に置いておけば、正常にコンパイルできるはずなので、とりあえずそのままにしておくことにする。現在、AVRでの開発プロジェクトはない。

あっけなくDRV8835は稼働。こんな簡単で良いのか(10/29/2016)
 最近、秋月電子では、DRV8835というモータードライバーICが売られている。こいつはひとつだけで、2つのモーターの正逆転を個別に制御でき、容量も一回路あたり1.4Aまで流せる。以前試したBD6211あたりより容量が大きい。しかも今、作っているMP4212などよりはるかに安い(MP4212はひとつだけで¥380、DRV8835は2つ動かせて¥300)。

Dsc00767 モード0、1(2つのピンの1が正転、逆転になるか、一つのピンがON/OFF、もうひとつのピンが正転と逆転)の動作テストもする。これも全く問題なく動いた。

 このあいだ、秋月でMP4212のドライバーのフォトカプラーを買うときに、矛盾するけれどこいつも買ってしまったことは、前の記事ですでに紹介した。ただ、買っただけでテストはしていない。このままにしておくと部品箱の肥やしになってしまいそうなので、動かしておくことにした。

 動かすと言っても、ブレッドボードに刺して、ジャンパーコードで電池とモーターを接続するだけである。部品はいらない。とりあえずシングルモーターでテストする。何の問題もなくモーターは正転逆転した。少々回しっぱなしにしても、クローラーに使ったFA130くらいのモーターなら、チップはちょっと暖かくなる程度で楽勝である。

 MP4212で苦労した配線や、ダンパー抵抗も必要ない。あまりにも簡単に動きすぎて、気が抜ける。基板面積は恐らく1/10くらいだろう。Hブリッジを知らなくても、これくらいのモーターなら何も考える必要がない時代になったのだ。

 今まで秋月C基板の1/4近くを占めて作ったMP4212のモーター基板はいったい何だったのか。まあこれはもっと大きなモーター(数A)に使えるから良いものの、何かやるせなさを感じる。Arduinoと同じ展開だ。モーターの経験値は上がらないし、一旦動かなくなれば対処不能だ。

ジャイロセンサーMPU6050をどう料理するか(11/6/2016)
 スマホなどの普及で、安価なペリフェラルディバイスが大量に市場に出回っている。以前なら考えられない高性能なセンサーが破格の値段で買える時代になった。

 このMPU6050もそのひとつだ。4、5年前なら3軸の加速度センサーだけで数千円していたのが、こいつは、加速度、ジャイロあわせて6軸のセンサーなのに¥1000以下で手に入る。これもアマゾンで、ウェブの話題につられて、使うあてもないのにポチッとして買ってしまった。

 次のプロジェクトは、この部品箱の肥やしになっているジャイロセンサーMPU6050をESP8266に絡ませることにしよう。ウェブサイトには沢山の応用例を見ることが出来る。これはArduinoのおかげである。

 どうもI2Cで簡単に動くようだ。ただ、動かすだけでは面白くない。これまでに何度も懲りている。「入れました。動きました」で終わりたくない。もう少し、手の込んだことをやっておきたい。

 とはいえ、倒立一輪車や、ドローンなどの姿勢制御まで一気に進むのは簡単ではない。最近のスマホなどの動画をブレなく撮影できる手持ちジンバルなども食指をそそられるが、これもすぐに思いついて作れるレベルでもない。

 色々迷ったが、とにかくMPU6050を動かすことを当面の目的とし、結果を少し凝ることにした。単にコンソールに数字を出すだけでなく、PC上でポットや飛行機などの姿勢が変わるシステムを作りたい。Arduinoと連携して、PC上に動画を出すProcessingというアプリがあるらしい。

Processingのインストールなどで参考にしたサイトは、
   http://kimizuka.hatenablog.com/entry/2015/05/01/000000
である。Processingそのものの解説は以下が詳しい。
    http://robo.mydns.jp/Lecture/index.php?Processing

 しかし、構想ばかりが膨らんで、なかなか具体的な計画にならない。メモに構想(妄想)を書き散らすだけの日々が過ぎていく。

本日ESP8266で全くの徒労。最近こういうのが多いな(11/10/2016)

 このところ雑用で忙しかったが、久しぶりにまとまった時間が出来たので、そろそろ次のプロジェクトのハードのため、一つ残っていた予備のESP8266をピッチ変換基板に実装する工作をやった。

 これまでの2つのESP8266には何らかのファームが入っており、これをつぶすのに抵抗があったのと、何か手を動かしていないと落ち着かない性分になってしまったこともある。しかし、これが2日間の泥沼の作業になるとは予想してもいなかった。

 ピッチ変換基板は、Aitendo製で、milピッチのレイアウトがこれまでの一列づつの両側ではなく下に2段にまとまった基板だ。以前、この2種類を2つづつ4枚買ってあった。リセットSWやレギュレーターを配線したブレークアウト基板を共通にしたいため、ブレークアウト基板の方に2段目のソケットを追加して動くようにした。 Dsc00769

 よく考えれば、こんなことはあり得ない(ピンアサインが両側一列と下側2段と同じ)のだが、何を勘違いしたか、両側1列の片側をそっくり寄せてレイアウトして実装してしまったのである。これがまた情けないことに、すべての半田付けを終わって動作テストしたときに始めて気が付いた。

 テスターで調べたら、全くピンアサインが違っている。極く当たり前の話なのだが、これを今頃になって気が付くおのれの愚かさに暫し呆然となる。9本の配線のハンダ付け18か所が全く無駄になった。お馬鹿にもほどがある。

 まあ、ここで自暴自棄にならないところが、自分で自分を褒めてやりたいところだ(と必死に自分をかばう)。叫びたい自分を押し殺し、低温ハンダを持ち出して、ブレークアウト基板に増設したピンソケットをとりはずした。さらに普通のハンダを盛って、ハンダ吸い取り線で丁寧に掃除する。

Dsc00766 ここでさらに失敗をしたら破滅的なことになるので、慎重に作業を進める。やっと前の状態に戻った。このままでは腹の虫が収まらない。愚かな自分を慰めるために汎用基板の切片を取り出してピッチ変換基板のさらに変換基板を作り始めた。

 下段2段のピンアサインは、調べたら両側一列とは全く異なり、通常のピン順序を無視した無茶苦茶な配列で、どうもアートワークを簡単にするためらしい。ということで変換基板の配線はむしろ簡単に済んだ。ちょっと背が高くなったが、問題になるレベルではない。

Dsc00763 ほぼ2日かけて、新しいピッチ変換基板の変換基板が完成した。恐る恐るテストする。最初の誤接続でのESP8266の破損を心配したが問題なく動いた。一安心である。実にくだらない作業だったけれど、何とか事態を収拾した。不思議なことに、こんな後ろ向きの仕事なのに満足感がある。

Processing単体では問題なく動く(11/14/2016)
 MPU6050をテストするのにビジュアルなベンチを用意したいということで始まったProcessingだったが、インストールのあと、本題を忘れて、もっぱらProcessingの画像表示を楽しんでいる。

 当初、PCで動くProcessingは、外見がArduino IDEに似ているので、何かと思ったが、動かしてみれば単なるJAVAのインタープリターで、画像などを簡単に出せるものだということがわかった。Arduinoそのものとは直接の関係はない。

 「Processing 入門」などのキーワードで調べると、沢山のウェブサイトが見つかる。適当なものを選んで演習する。これは楽だ。実にあっけなくPC上で図形を加工しながら動画にできる。また年寄りの繰り言になるが、あのC言語でグラフィックLCDに円を描く関数を開発していたのは何だったのかという気分になる。

 Arduinoとの連携は、単に、Arduinoのデバッグ用のシリアルインターフェースを利用しているだけで、大層なしかけがあるわけではない(と思う)。 要するに、どちらかのトリガーで、あらかじめ決めたデータをArduinoが送り、それによってProcessingの画像が動くと考えれば良い。

 理屈がわかってしまうと、途端に先に進む意欲が低下する悪い癖が出て、開発のテンポが落ちる。適当な応用例がサイトで見つからないのだ。みんな沢山のライブラリーが必要なようで、やってみる気がなかなか起こらない(気位ばかりは高いが実はへたれである)。

筑波山に登ってきた(11/17/2016)
 そこで、電子工作以外の話題をひとつ。所長は関西の出身で、東京に出てきた京都の高校の同級生がここ15年近く健脚自慢のメンバーで定期的に山や街歩きをしている。今回は、筑波山に登るというので仲間に加えてもらった。Dsc00690

 ちょうど紅葉のシーズンなのでそれも楽しみだが、筑波山あたりは関西から東京に出てきた者にとっては全く盲点と言っていいくらい知らないところで、殆ど行く機会がない。しかもつくばエキスプレスという新しい鉄道に乗るのもはじめての経験で、何かわくわくする(所長は元鉄道おたくである)。Dsc00706 Dsc00732

 筑波山に登るといっても、ロープウエイとケーブルカーが整備されており、ほとんど登る行程なしに、男体山、女体山という2つの峰に行くことが出来る。それでも一週間も前に古い軽登山靴を物置から出して磨く。家族から、「まるで小学生の遠足ね」と冷やかされる。

Dsc00735 Dsc00746  朝8時に秋葉原に出る。ウイークデイなので長いエスカレーターは上りの通勤客の大群にはばまれ、地下の深いホームにたどりつくだけで一苦労である。終点のつくば駅からのバスは平日にもかかわらず乗客で満員だった。驚いたことに外国人のパーティが1/3近くおりバスの車内は外国語で溢れていた(彼らは大声ではしゃぐ)。 

Dsc00750  寒いとおどかされていたが、好天に恵まれて絶好の山日和である。男体山は、女体山より標高は7mも低いのに、山道は岩だらけの急坂で、かなり息が上がったが、女体山の方はアプローチが長いので簡単に頂上に出た。

 女体山からは霞ケ浦が一望できる。ただ、もやで残念ながら富士山は見ることはできなかった。それでも、帰りのロープウェイからの極彩色の紅葉は素晴らしかった。

PC連動ACコンセント自作に脱線する(11/21/2016)
 さらに、くだらない寄り道をしている。当研究所のメインPCには、PC電源連動タップが装備されており、メインの電源の入り切りで、周辺の機器(ディスプレイ、スキャナー、オーディオなど)も連動して作動するようになっているのだが、このタップの具合が最近おかしくなってきた。

 足元に置いてあるタップが足で動かされると、偶(たま)にだが、PC本体の電源が瞬断し、PCがリセットしてしまう。作動中のPCの突然の電源断は、Win10では少し丈夫になったようだが(セーフティスタートを強制されない)、この前の電源故障のときに懲りている。何とかしないといけない。

 この連動タップは10年以上経っているので買い替えても良いのだが、電子工作の経験を積んで来ると工作心が刺激されて、ただ買い替えるだけでは芸のない話である。で、脱線して、この連動コンセントを作り始めた。昔のPCならいざ知らず、今はUSB端子があるのでわざわざPC電源から5Vを引き出す必要もない。USBから5Vを出しリレーひとつで出来上がるはずだ。

Dsc00755

 ACインレット、アウトレットなどの工作だけである。プリンター電源のLAN制御のとき使った15Aを入り切りできるメカニカルリレーの予備があるが、せっかくだからもうひとつのAC制御、SSR(Solid State Relay シャープS108T02)を使ってみることにした。

Dsc00761  何の電子工作らしいところはない。単にケースの工作だけのようなものだけど久しぶりのコッピングソーやボール盤(んな大げさのものでなく単なるドリルスタンド)を持ち出しての工作は楽しかった。配線は、単に入力にLEDの制限抵抗を入れ、インレットとアウトレットのACの太い配線をはんだ付けしただけである。

 それでも慎重を期して、10項目に上る作業項目をメモに書き、赤ペンで消していく。SSRを普通のリレーと勘違いして、直接5Vを端子にかけ、ひとつ¥280もするSSRをお釈迦にしたことは秘密である。Dsc00759

 出来合いのヒートシンクをつけ、接合部分には本式に伝熱グリスを塗り、USBソケットを補強し(ソケット部は特に必要)、あれこれ3つ以上買ったケースの中から作りやすいケースを選び、半日かけてSSRによるPC連動スイッチが完成した。

 勇躍テストに入る。ACを扱うのでバラックで事前に動作テストは済んでいるが、PCで動かすのは初めてである。動いた! 念のためオシロでUSBが立ち上がる波形を見る。PCのUSB電源の立ち上がりは、起動スイッチと同時にUSB側も立ち上がるようで、パルス状ではなく徐々に(立ち上がり6ms程度)で5Vになるようだ(電源断も同じカーブ)。

 PCも無事立ち上がり、shutdownで電源も切れる...ん、切れない。えー、どうして?調べた結果、このPCのマザーは、待機時にWake Up LANなどのためにUSBがOFFにならないUSBコネクター部があるようで、USBプラグを待機時にOFFになるところを選んでOKとなった(マザーボード上のピンでOFFにすることもできるようだ)。

 とりあえず、工作の目的は果たした。少々足で電源をいじっても瞬断の心配はなくなった。きりの良い所なので、報告をここらで一段落する。

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

その他のカテゴリー

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