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

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)

2016年10月20日 (木)

ESP8266とスマホでクローラーの無線操縦をためす

 メインPCの電源故障でWindows10をこわしてしまい、再構築したのだが有力なアプリが全滅してしまった。電子工作どころではない。ブログを書き込むだけの最小限のソフトを再インストールして、前回の記事は何とかアップしたが、その後も悪戦苦闘が続いた。

ロジックアナライザーのドライバーが入らない(9/15/2016)
 この間やっとWindows7からWindows10に切り替えた直後にこの事件である。ワードやエクセルは幸いインストールCDが手元にあったので簡単に戻り、ブログの記事のアップや会社の決算などは無事終わったが、電子工作の開発環境のアプリなどは、ショートカットが残っているだけで本体は殆ど影も形もない無残なありさまだ。

 アプリを使う機会のたび、少しづつ修復作業を続けた。大方のソフトは生き返ってきたが、この前も、てこずったZEROPLUSのロジアナLAP-C16128がうまく入らない。みんなWin10で苦労しているようだ。

 それでも最近は販売元が、win10をサポートする最新版を出しているので大丈夫だという情報を見つけた。しかし何度やっても、その公式インストーラーは変なエラーメッセージではねられる。例のエラーメッセージを直接Googleに喰わせる方式で探索すると、ウェブからは解決法が沢山でてきた。しかしどれを試してもうまくいかない。 Ws000008 何か汎用的な相性問題のようで、特定(ZEROPLUS)のアプリのウェブの記事は少ない。いくつかあるZEROPLUSの記事はみんなWin8時代のものばかりである。最初にWin10に入れる時も苦労している。このときは、何回か失敗したあと、いつのまにか動いた。どうも悪い予感がする。

悪戦苦闘。遂にLAP-C16128のドライバーインストール成功(9/20/2016)
 この1週間、喉に小骨が刺さったように気になっていた、ドライバーのインストールが、どういうはずみかうまく入った。何が原因だったのかはわからない。色々な方法を試すうち、偶然のようにうまく動いた。どうにも気分が悪い。

 製造元のWin10で動くというインストーラーでエラーが出る。このインストーラーはドライバーとアプリケーションを別々にインストールするようになっている。まずドライバーをインストールすると、途中で以下のメッセージが出てインストールが中断される。Win10のディバイスマネージャーのZEROPLUSのアイコンの下のLAP-Cドライバーには故障のマーク(!)がついたままだ。

 アプリケーションは最初の1回はなぜか問題なく入ったが、環境を元にもどすため、一度アンインストールして再度入れようとしたらその後は全く入らなくなった。エラーメッセージは、ドライバーもアプリも同じで以下のようなものである。
  1608: Unable to create InstallDriver instance.
  Return code -2147221021

このエラーメッセージを直接、Googleに放り込んで見ると、海外を含めてさまざまな解決法が出てくる。インストール時の共通のエラーのようで、沢山のソフトでの発生事例が報告されているようだ。どうしてこういうこと起きるのかという説明が不足しているので手探りである。

原因が何かがわからない。何かの拍子にwindowsのインストーラー関係のリンクがおかしくなるのだそうだ。こちらはWindows10を再インストールしているので、このあたりは大いに可能性がある。

 いくつかのサイトをまわるうち、以下の方法(Idriver.exeを独自に実行してから、インストーラーを動かす)をやると、少なくとも上記エラーは出ないで先に進むことがわかった。しかし、ドライバーは正常にインストールされない。

c:\Program Files\Common Files\InstallShield\Driver\1150\Intel 32>idriver

 レジストリーを綺麗にするユーティリティ(CCleaner)を見つけたので、これで不審なレジストリーを消去するが変わらない。仕事場のノートPCで試しにインストールしたら、何の問題もなくドライバーが入った。やはり、この自宅のPCの固有の問題であることは明らかだ。

 自宅にもどり再度挑戦する。こういうのは気になったら止められない性分である。CCleanerのメニューの中に、レジストリーだけでなく不要なプログラムを消す機能がある。これを見ていると、消したはずのLAP-Cのドライバーが存在していた。これは怪しい。とりあえず、それを消した。

 これが良かったのかもしれない。インストーラー始動前に、必ずこれ(Idriver.exeの実行)をやるようにし、さらに管理者権限で必ず、setup.exeを始動するようにした。何度目かのトライで何と、インストーラーが順調に動き、ディバイスマネージャーのアイコンから!マークが消えた!

 LAP-Cが問題なく動いた。ふー、やれやれ。決め手がなんであったのか確証がないのが心残りだが、とにかくこれで他のことに移れる。それにしてもOSの変更は大型機の時代からユーザーにとっては実に厄介なイベントである。

 昔は、性能が良くて安価な新しいハード機器を動かすために、渋々替えてきた(これはメーカーの戦略)。バージョンアップはそれなりにユーザーに利益をもたらしたのだが、今や、バージョンアップは、ユーザーにとって何の役にも立たない作業になり果てている。ベンダー、メーカーの都合に付き合わされるのは、もうそろそろ止めて貰いたい。

今度はAtmelStudioが入らない。これは少し静観(9/24/2016)

 次のAVRの開発環境、AtmelStudioは、結局、諦めた。これがなければAVRを動かせないわけではない。あの愚鈍な象のように重いVisual Studioは正直言って、あまり愉快な環境ではない。

 当研究所は、AtmelStudioで使っているのはエディターとビルドだけで、書き込みは、ChaNさん謹製の超軽いAVRSPである。コマンドプロンプトに一旦入れておけば、コマンドのリピートキー一発で何度でもビルドを繰り返せる。

 それでも一応は入れておこうと、最新版のAtmelStudioをダウンロードし、インストールを始めた。延々とVisualStudioをインストールし始める。そのうちインストーラーがハングアップしたようで、一時間近くほっておいても終わらなくなった。リソースマネージャーで見ると、どこかでループしていることは明らかだ。

 サイトの情報にも、いくつかハングアップの事例が報告されている。抜本的な解決策は見つかっていないようだ。まあ、AtmelStudioは必須の環境ではない。なければAVRtool Chainをインストールして裸でmakeしてもかまわない。これは少し静観することにする。

 そのうちWindows10に入っている無料のゲームソフトが思いのほか面白く、PCを立ち上げても、それに時間をとられて、まともなことをやる気力が盛り上がらなくなった。ゲームにはまって気が付いたら深夜という繰り返しの毎日で、電子工作そのものの動きが停滞してしまった。

久しぶりに秋葉原に行きモータードライバーなどを調達(9/30/2016)
 それでも、Win10のインストール騒ぎの最中、実は少しづつ続けていたハード工作がある。8月に面白がって買ったアームクローラーの工作である。モータードライバーをMP4212で作っていた。ブレッドボードでのテストでは問題なく動いた。

 クローラーにESP8266基板と、MP4212を2つ載せたモータドライバー基板を2階建てで取り付けるつもりで準備を進める。ブレッドボードから汎用基板に部品を移して配線する。久しぶりのはんだ付けを楽しむ。

Pa207520 クローラーについているモーター程度(マブチのFA-130)でMP4212を使うのは少し勿体ないが、以前、1Aまで流せるというBD6211というモータードライバーをこのモーターに使っておかしくしてしまったことがある。モーターが止まるほどの過負荷をかけると、こんな小さいモーターでも1A以上が流れこわれてしまったらしい。用心に越したことはない。

 このサイトの情報を参考に、最終的には、ESP8266とスマホでラジコン化するのが当面の目的だ。片側のMP4212の実装が済んだので、実際にモーターの電源を利用してHブリッジの動作を確認する。電源は、ニッケル水素電池2つか、800mAhのリチウム電池である。

 ところがMP4212のモータードライバーの動きがどうもおかしい。4Vのリチウム電池では何か瞬間的に貫通電流が流れるらしく、瞬断してうまく回らない(動くときもある)。回路的に悪いのか。あのフォトカプラーを直接論理回路化した回路が悪いのか。

 FETの動作原理を復習する。どうも、直接、ロジックだけであのHブリッジを動かすのは無理な感じがしてきた。あのままでは、FETのゲートに電荷が溜り誤動作するような。要するに単なるスイッチではドライブが出来ない感じがする。

 念のため、オリジナルが正しく動くどうか、フォトカプラー(TLP250)を試してみたくなった。久しぶりに秋葉原の秋月にでかける。行ったついでに、1.4Aまで動くというデュアルモータードライバーモジュールDRV8835(¥300)を買った。これはひとつで2つのモーターを動かせる。さっきのフォトカプラーの回路ならフォトカプラーだけで4つ(¥150X4=¥600)もいるところでこちらは断然お得だ。

 しかし、MP4212のモータードライバーの片側も実装し、電源の接続ピンを新しくしたら、Hブリッジは全くトラブルなく快調に動いた。MP4212モータードライバーの不可思議な動きは、どうもピンヘッダーの接触不良の疑いが濃厚だ。今、別個にテストしているが何の問題もない。

ESP8266の復習を始める。フラッシュファイルシステムも戻った(10/4/2016)    
 ESP8266をおさらいする。まずは、棚からとりだしたESP8266モジュールの埃をはらい、動作の確認をする。これまでやった実験(フラッシュファイルシステム、RTC、ATコマンドファームの書き戻しなど)を次々に追試した。

 フラッシュファイルシステムが動かなかったが、これはATコマンドモードに戻したとき、ファイル本体とディレクトリのリンクが切れてしまうらしく、フラッシュファイルをもう一度書き込んだらOKになった。こうしたリハビリでESP8266周りの視界が広がり、最終目的(スマホでラジコン)開発の体制が整ってきた。Dsc00584 最終目的は、ESP8266はソフトAPモードにして、peer to peerでスマホとつなぎ、ラジコン化することだ。このウェブ記事のソースをそのまま借用することにしている。このスケッチのスマホのボタンで、クローラーの前後進、左右移動が、ボタンのタップで出来るはずだ。

 まずは、ATコマンドでソフトAPモードにする。これは問題ない。簡単にスマホにサイト名が出た。勢いに乗って参考サイトのコマンドを入れて、スマホと接続。ESP8266のコンソールから接続を知らせるメッセージが出た。しかし、このあとのHTMLシーケンスはないので何もできない。これはここまで。

ESP8266とスマホでクローラーの無線操縦ができた(10/13/2016)
 人様のソフトをそっくりいただいて、ESP8266をAPモードにし、スマホとpeer to peerで結んだリモコンで、めでたく、このあいだ作ったアームクローラーが動いた。スマホのタップによる動作指示は、やはり少し遅れるので本格的な操縦というより「動きます」というのを確認できる程度と考えて良い。スマホのタッチスクリーンの操作をこれからマスターしていかないと実用にはならない。Dsc00588

 電源は、モーターをニッケル水素の乾電池2つ(2.8V)、ESP8266の方はリチウム電池(3.7V)に独立させた。ESP8266基板に、低ドロップレギュレーター(AMS1117)を実装して3.3Vにしている。

 このニッケル水素乾電池のフォルダーをシャーシーに固定するのにえらい時間がかかった。始めはフォルダーをかっこ良くはめ込み止めにしようと、アクリル曲げ機まで動員して、アクリル加工をしようと試みたのだが、意外に難しく(薄いアクリル板は曲げるとそこが極度に弱くなる)、バッテリーフォルダーの素材が瞬間接着剤を受け付けないタイプ(ポリスチロールか)で接着はあきらめた。Dsc00590

 かわりにリアフェンダー(アームクローラーは角度をつけて動くので)に、アクリル小片でバッテリーフォルダーをはさみ、ねじ止めした方法が、簡略だがとても具合よくバッテリーを固定することが出来た。始めから奇をてらわずこうしておけば良かったのだ。

 今回もソフトウエアはAruduinoのスケッチをそっくり拝借したので、全く経験値は上がらなかった。まあ、一旦決めたこと「ESP8266とスマホでラジコン」という命題を何とか挫折なく最後までやりとげたことが救いといえば救いだ。

 次のテーマが問題だ。折角買ったDRV8835はまだ動かせていない。いまだに、あの「ときめき」が電子工作では復活していない。当研究所の活動にはまだまだ暗雲が垂れ込めている。

また新東名を走ってきた(10/16/2016)
 ここで電子工作以外の話題をひとつご報告。車で関西に法事と墓参りのため、帰省した。3年近く前、亡くなった長姉の見舞いに来て以来の長距離ドライブである。例の新東名(第二東名から名を替えたらしい)は以前に比べると車の量が増えたが相変わらず快適だ。Dsc00632

 しかし、トンネルなどの一部は十分な3車線の広さがあるのに、速度超過を心配したのか、路側帯を広くしてわざと2車線にしている。確かに次元を超えたスピードが出るので何とか速度を落とさせようという魂胆なのだろうが、せっかくの機能を台無しにする、いかにも日本の行政らしい「余計なお世話」である。

Dsc00648 お墓は大阪(豊中)にあるが、法事は京都で行われた。いつも、京都では錦市場でおみやげを買って帰るだけだが、今回は珍しく市内の行事を調べて銀閣寺で特別公開があるというので、何十年ぶりかに東山の銀閣(慈照寺)に足を延ばした。

 特別公開は、足利義政の持仏堂で書院造りの原点といわれる東求堂(とうぐどう)の内部と与謝蕪村などの襖絵である。「写真はとるな。角のある持ち物をふりまわすな。壁にもたれるな」とやけにうるさい。まあ、国宝なのだから仕方あるまい。

Dsc00643

 ちょうど雨上がりで、庭園の緑がとても美しかった。義政は西の苔寺(西芳寺)を愛していたらしく、豊富に苔が各所に使われて庭を引き立てている。有名な砂の山や、砂の海原は江戸時代の考案らしく、義政本人の趣向には見えない。

 錦市場で、いつもの、三木鶏卵の卵焼き、打田の漬物、丹波の栗などをしこたま買い込んで、機嫌よく、秋の京都をあとにした。それにしても外国人の数はすさまじい。初日のホテル(ノク京都)は外資系もあるが、90%は外国人で、日本人の数に入れていた隣の夫婦連れは、近くを通ったら日本語を喋っていなかった。

Dsc00641 前回と違い、帰りの東名は幸い大きな渋滞にもあわず(海老名で30分くらいの事故渋滞だけ)、5時間余りで東京に戻ってきた。昔、正月一日に、がらがらの東名をしゃかりきに飛ばした私のコースレコード5時間ちょうどに迫る記録だ(もっともそのときの距離は506キロ、今は480キロ)。

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

2016年4月11日 (月)

ESP8266の冒険(3)は一段落。Raspberry Pi 3に手を出す

ESP8266モジュールのWiFi接続のキャンセルには成功(3/20/2016)
 安価なWiFiモジュールであるESP8266で色々遊んできた。その結果だが、こいつはブラウザーなどの重いネットワークの仕事はさすがにちょっと無理なことがわかった。深く解析したわけではないが、デフォルトの状態では画像の表示や中継転送速度は話にならないくらい遅い(前記事参照)。

 32ビットのCPUなので期待していたのだが、CPUクロックが80Mhz程度ではやはり力不足のようだ。リモートセンサーの数値データの送信や、リモート機器の制御などに使うのが無難だ。ただこちらとして問題なのは、このなかに、作りたいと思うアプリケーションが見つからないことである。02p1257479

 温度・湿度センサーに今のRTC(リアルタイマークロック)のデータを足してサーバーに送る携帯型の温湿度ロガーあたりが、差し当たっての有力候補なのだけれど、これをすぐ作ってみようという気分にどうもならない。

 当研究所のモットーは「実用に役に立つものを作る」ことである。なるべく「作りました、動きました、おわり。」というのは避けるようにしている。目的がないときは強引に目的を作る。これはなぜかというと、目的のない機械(しかけ)は制作努力を何にかけるかの焦点がぼけるため、圧倒的に開発効率が悪い。作った後の達成感にも欠ける。

 その意味で、温・湿度ロガーは目的ではある。しかし、無理に目的を作った感じなので、どうしてもその気になれない。とはいえ、折角、新しい世界であるESP8266(というかArduino環境)に慣れてきたのだから、もう少し付き合ってやろうと、これまで気になっていた細かい課題を解決することにした。

 それは、立ち上がりのときのUARTモニターのゴミ(字化け)と、バックグラウンドで自動的に動きだすWiFi接続のメッセージである。双方ともUARTを使わない限り何の支障もないし、無視してしまえば良いのだが、UARTを出力画面にしているときは何となく目障りだ。

 リセット直後のUART開始メッセージのゴミは、ESP8266のROMモニターが出している。ボーレートが74800bpsという中途半端な値なために字が化ける。調べたところでは、ユーザープログラムで、これを制御することは出来ないようだ。

 もうひとつのWiFiが勝手に立ち上がる問題である。これは、Arduino IDE環境におけるプログラム開発特有の問題だと思うが、LED点滅のような簡単なプログラムでも、必ず背後でWiFiが動きだし、WiFiの開始メッセージがUARTに出てくる。

Esp8266rtc  ウェブを探すと、WiFiをステーションモードにすれば、これが止められるという情報が見つかった。早速これを試してみた。しかし、ステーションモードにしても( WiFi.mode(WIFI_STA);)、止めることは出来なかった。

 出来ないとなると、余計気になるというのが当研究所の所長の性分である。さらにしつこく、あれこれサイトを探索する。すると、開発ライブラリーキット(SDK Sytem Developpment Kit)に、色々なモードを設定するAPIを見つけた。

 ここには必ずWiFiを制御するAPI(関数)があるはずだ。しかし一通り調べたが、見つけることは出来なかった。そもそも、このSDKは良くわからないところがある。実ライブラリーの所在がArduino IDEの中で不明である(バイナリーをどこにリンクする?)。サンプルソースには、このincludeステートメント(#include "user_interface.h")が入っているだけである。これだけでSDKのAPIが動くのか。

 半信半疑でテストしてみた。なんと、簡単にSDKバージョンを示す関数が動いた。しかし動かない関数もある(os_printfなどは動かない)。何やら問題としては奥深い、キーワードを頼りに、さまざま資料を探し回るが糸口が見えない。オープンソースという割には、情報がネットで不足している。

 良い加減飽きてきて、別のことをやっているうち、偶然、SDKの関数群の中に見つけた。何ということはない、その名もずばり、Wifi_station_disconnect()という関数があるではないか。今までの俺の目は節穴だったのか。

Ws000002  早速、これを持ってきてテストしてみた。ビンゴ!であった。見事にWiFiが止まって、無用な接続メッセージが止まった。久しぶりの達成感に幸せになる(安い娯楽だ。この項4/1/2016)。

RTCは恐ろしく正確だった(3/25/2016)
 ESP8266につけたRTC(リアルタイマークロック)のテストを続けている。これまでのところ、このI2CでつないだRTC(DS3231)の精度は極めて高い。3日連続で、1秒(0.5秒以下)行かない。このままでいくと月差は数秒と市販のクオーツ時計並みの正確さになる。

 遅ればせながらDS3231のスペックで確かめる。スペックによれば、±2 ppm(0~40℃)ということである。月差を調べてみる。1か月は、24 * 365 * 60 * 60 / 12(秒)なので、2,628,000秒。2ppmとはこの50万分の一で5.256秒となる。実機はこれを上回りそうだ。

 当初はESP8266の実用的なアプリケーションとして、このI2CのRTCに同じようなI2Cの温湿度センサーを加え、可搬型の温湿度ロガーを作ることを考えていた。好きなところに放り出しておけば、勝手にデータを記録し、蓄積する。定期的にネットに接続して送信する。

 どうせならウェブでグラフを出したい。データの蓄積は、ESP8266のフラッシュで十分か、省電力設計をどうするか、ウェブサイトにあるように何かIOT用の中継サーバーを利用するのか。あれこれ迷う。なかなか仕様が決まらない。これを作ってESP8266をそろそろおしまいにしたいのだが、いつまでも決まらない。

 そのうち赤外線のコードを記憶して再生するプロジェクトを見つけた。スマホを入力端末にして、赤外線リモコン(エアコン)を簡単に、ネットを通して遠隔操作が出来る。おお、これなら、温湿度ロガーより実用的だ。寝室のエアコンを居間から制御できる。

 仕様の決まらない温湿度ロガーは棚上げにして、このスマホを端末にしたリモコンの遠隔操縦をESP8266の卒業制作にすることにした。実は他のプロジェクトが待っている。最近、秋月でも売り出したRaspberry Pi 3である。

無線(WiFi)ルーターにはまる(3/27/2016)
 その前に、別の騒ぎを1つ紹介しておこう。ESP8266を本格的に運用するために、我が家のWiFi環境を整備しようと、手頃な無線ルーターを増設することにした。

 これが、めたらやたら設定の難しい無線ルーターにあたったのである。恐らくどのメーカーでも同じと思うので公平を期すため、ここではメーカーの名前は出さない。まともにつなぐのに2日以上かかった。 Dsc004150001_2

 現在、我が家のメインの無線ルーターは地下室と1Fをつなぐオープンスペースに設置され、1F居間と、地下のPCルームをカバーしている。このままでは、2Fが不感地帯となり、ESP8266を実用的に2Fのエアコンのリモコンにすることができない。

 従って、無線ルーターを1Fに上げ(こうすると2Fはカバーする)、地下は中継ルーターにすれば全域がカバーできる。ついでに1Fトイレのような難接続地域も解消できる。

 どうせ組み込み機器は最新のプロトコルはサポートしていないので高いものを買う必要はない。量販店で在庫切れになる寸前のルーターを探した。大体最大で600Mbps程度のものを選ぶ。値段も定価の半額以下の¥3000台で手に入る。

 設定を難しくしたのは、一般的なルーター設定ではなく、アクセスポイントとして使っている無線ルーターの中継(リピーター)機能の設定だったので、余計難しかったのかもしれない。

 始めは、単なる中継機能なので、簡単に設定できると思ったのだが、説明が少なく難航した。設定自体も、いくつもの手法があるのが、そもそもの混乱のもとなのだが、その内容が説明書だけでなく、ネット上の解説でも少しづつ違うのが問題だ。

 会社のサイトの情報は豊富なのだが、これがことごとくその解説どおりに動かないのである。説明されている画面が実際の画面と少しづつ違う。類推を利かせながら先に進むが、たいていはどの手順でも途中でエラーになってしまう。

 メーカーとしては何とかお手伝いしたいという誠意は感じるのだが(情報は多い)、どうしても先に進めない。特にやろうしていることが通常のルーター機能ではなく、中継(リピーター)機能なので余計混乱する。

 Netブック(WiFi機能あり)、メインのPC(WiFi機能なし)、スマホの3台を総動員し、だましだまし工場出荷リセットを10回近く繰り返してやっとのことで成功した。

 成功したと言ってもリピート機能は確認が難しい。SSIDが同じになってしまうからだ。正常に動いているように見えるが、新設した中継ルーターの電源を切っても通信速度が変わらなかったり、どうもおかしい。

 しかも、設定しようとした2.4Ghz帯(802.11/g)の中継がどうしてもうまく行かず、5GHz(802.11/a)にしかつながらない(リピート機能は単一バンド単位しか効かない)。5Ghzは自宅では速度は早いのだが、感度不足で、問題の地下や1F洗面所などの難接続地帯を解消できない。

 最後は少し離れた場所からのスマホでの設定で、やっと2.4GHz帯のリピート機能に成功した。偶然、スマホが2.4GHz帯のSSIDを発見した。何故、スマホでの接続に成功したのはわからない。まあ、動いたのだから、そっとしておこう。

RaspberryPi 3を衝動買い。OSのダウンロードに2時間以上かかる(4/1/2016)
 RaspberryPi 3である(以降RasPi3)。このブログを振り返るとRaspberryPiにはまっていたのは、もう3年前のことである。こいつにウェブカメラをつけたときの記事は今でもアクセス上位を占める当ブログの人気ページでもある。

 あれからRaspi 2というのが出たが、これは導入せず、IntelEdisonにした。今度のRaspi3は、飛躍的に性能の上がったRaspi2に較べれば、1.5倍の性能比だが、初代からは10倍もあるという。何しろクロック1.2GHzのQuad CPUなのだ。

 それに、WiFiやBlueToothも実装済みである。WiFiは技適が心配だが、ウェブ情報によれば、これもクリアし、先ほど秋月電子でも販売を開始したというニュースが飛び込んだ(即、売り切れたそうで、現在も在庫切れ)。

 ESP8266の冒険も一段落したので、目的もないのだが急に欲しくなった。どれだけ性能が上がったのが自分の目で確かめたい。売り切れと聞くとなおのこと物欲を刺激する。大所の店は売り切れのようだが、最近は、アマゾンなどの通販でも電子部品を手に入れることができる。

「Raspi3 販売」で検索すると、沢山ヒットした。秋月より少し高いがいくつものショップが売り出している。WiFiの技適が通っているのか一抹の心配はあったが、アマゾンが一番安かった(¥6458)ので、早速ポチッとしてしまった。

 数日後アマゾンからRaspi3が早くも届いた。心配していたが、技適マークがちゃんとついた正規品だった。

Dsc004170001 Raspiのインストールの案内はウェブサイトに山のようにあるが、意外にRaspi3のものは少ない。でもソフト的には2と全く同じだというので、サイトの情報を頼りに、手始めにOS(Raspbian)のイメージのダウンロードを気楽に始めた。しかし、これがえらい時間がかかったのである。

 総量は1.5GBだから大したことはないのだが、先方のサーバーが遅い。午前0時ごろから気楽に始めて終われなくなってしまった。次の日は出勤日なので、早く寝ないといけないのだが、こういう時に限って止められない。せまい道で電信柱とすれ違うときに何故か対抗車が来る感じである。

 結局、2時間以上かかって、やっとのことでイメージファイルのzipがとれた。これを解凍すると4GB近いイメージファイルが出来る。メインPCで、マイクロSDカードにコピーする。

Raspi3の描画能力は素晴らしい(4/8/2016)
 SDカードへの書き込みは、次の日だったが、4G近いサイズのイメージのコピーは結構時間がかかった。といってもダウンロードに較べればあっと言う間に終わる。ソフトの準備はあっけない。これだけである。次はハードだ。

Dsc004100001_2 初代のRaspiで使ったHDMIケーブルや、ワイヤレスキーボードをつなぎ、電源は手製のUSB AタイプコネクターとDCジャックの変換基板に秋月の5V 3AのACアダプターをつなぐ。

 メインPCのディスプレイを借りてスタートする。立ち上げる。おおお、出た!いやあ、早い早い。ブートメッセージが矢のように流れる。4CPUなのでラズベリーのアイコンが4つでるところがご愛嬌である。Dsc004130004_2 何事もなくデスクトップが立ち上がった。色々な整備を始める。日本語を設定して、立ち上げ直したら、デスクトップが豆腐のような盛大な文字化けで先に進めない。いけない日本語フォントが入っていないではないか。localeを戻そうとするが、どうもうまくいかない。

 誰もがやる失敗のようで、ウェブ上には回避策が沢山出ている。いずれも面倒なので、SDカードにイメージファイルを焼き直し、最初からやり直した。これが一番楽だ。raspi-configで初期設定をしたら再起動する前に、必ずapt-getで日本語フォントをインストールする。フォントのインストール方法もウェブサイトにちゃんと出ている。Dsc004110002_2

 ブラウザーは特別な軽いもの(Epiphany)が入っているようだ。日本語フォントが少し気に入らないが、ブラウザーも問題なくスムーズに動く。いやあ、初代のRaspiに較べれば雲泥の差だ。そりゃ、CPUの数が4倍、クロックもほぼ倍近くになっている。早いのは当たり前だ。下手をすると今のNetブックより早いかも。

Dsc004120003  殆どストレスなしに大きな画面(1920X1080)を制御できている。FireFoxもいれてみる(RaspbianではIceWeaselという名になっている)。これはさすがに心持ち遅い感じだ。しかし、これはサブマシンとして十分使える早さだ。音もすんなり出る。進歩の激しさに眩暈がする。

Dsc004160001_2  ワイヤレスキーボードでは前回同様、又少し手こずった。電池が完全に抜けていた。そりゃそうだ3年も放置しておけば待機電流だけで抜けるのは当たり前か。頭に来たので、久しぶりの基板工作とばかり、このキーボードにスライドスイッチを取り付けることにした。結果は、こんなもの。あまり褒められる品質ではないが、まあ、工作欲を満たすことはできた。

 さて、これで何をするのか。やれやれ、何か、前にもこんなことがあったような。誰かが言っていたが、結局電子工作って、作ることが楽しみなのだろうな。

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

2016年3月16日 (水)

ESP8266の冒険は続く(2) SDカードブラウザーやRTCで遊ぶ

 このブログは2ヶ月近いご無沙汰である。実は6年ぶりに海外旅行に出かけて電子工作をお休みしていた。旅行は70才以上の方々とスキーを楽しむツアーである。場所は念願のスイスのツエルマット。スイスからイタリアまでスキーで滑り込める。結論から言えば、猛烈に楽しかったが疲れた。

 4日以上連続してスキーするのは日本でも20代の学生の時以来始めてである。疲れるのは当たり前と言えば当たり前のことだが、帰ってきてすぐ風邪を引いて熱を出し寝込んだくらい疲れた。でも、昔からいつかは行きたい行きたいと願っていた所だったので、今は深い満足感がある。

Dsc001000001 そんなことで、電子工作は、半かけのまま放置されていた。体調が戻って、やりかけていたプログラム開発を細々と再開した。ESP8266のRTC(リアルタイマークロック)である。想定通り動き始めたので、ブログに報告することにする。

 この趣味を止める気はない。ここ10年の楽しみだったので未使用の在庫部品が相当溜まっている。今止めればすべてが無駄になる。とても止めるわけにはいかない(笑)。ということで、電子工作の話は少し古くなってしまったが、以下から順を追って報告する。

SDカードの不具合は前にも経験したお粗末エラー(1/28/2016)
 前回のテーマはWiFiモジュールのESP8266でフラッシュメモリに仮想ファイルを作り、画像付きのウェブサーバーを動かすことで、これはうまくいった。ESP8266のArduinoスケッチライブラリーには、SDカードのサポートがある。勢いに乗って、こいつも試してみたが、さすがにSDカードはすぐには動かなかった。

Dsc003850003 ブログに書いた後、本腰を入れてSDカードを動かす作業に入る、色々試したが、がんとしてSDカードは言うことを聞いてくれない。Arduinoのプログラムは動くときはあっと言う間だが、動かないとなると何をいじって行けば良いのか全く見当がつかなくなる。良くも悪くも情報隠蔽がうまく行われているので手がかりがつかめない。

 散々苦労した挙句、動かすことには成功したのだが、何のことはない、原因は昔のドジなミスの再現であった。トラブルシューティングとは、こんなものである。自分を責めてみても仕方がない。苦笑いするだけである。

 使っているハードのSDカードアダプターは、電子工作を始めた8年前、ルネサスの16ビットCPUボードH8/3069FやAVRのMega128などで、汎用的に動かすことを目的に作ったものである。リセットなどがソフトでできるようにするため、電源をFETで切れるようになっている。

 電源ONは、FETからの制御線をGNDに落とさなければならないのだが、これを完全に忘れていて、端子が浮いたまま(未配線)動かそうとしてエラーを起こしていた。確か、このミスは、H8/3069Fのときも全く同じ状況だったはずだ。要は電源が入っていない状態で動かそうとしていたことになる。

 究明のきっかけは、動作中の入念な電圧測定である。このFETスイッチは前のトラブルのあと、バイパスしてあるものだとばかり思いこんでいた。電源電圧がかかっていることを確認し、そうだとばかり勘違いしていた。このときの電圧測定が不十分だったのである。

 どうしても動かないので、もう一度、各部の電圧を念入りに測り直した。すると、規定より少し電圧が低いことが分かった。3Vであるべきところが、2.5Vしかない。ふーむ、これはおかしい。どこにも熱を持っているところはない。過大電流で下がっているのではない。

 それなのに、どうしてこんなに低い?色々調べるうち、このFETスイッチがOFFになっていることを突き止めた。で、どうして2.5Vが上がる。犯人は、ESP8266からのChipSelectの結線であった。これによって電源がOFF(ハイサイドで)でも、制御線を通して機器側に回り込んで電源電圧をあげてしまう。

 ちょうどAVRで電源を切っても、USB-UARTのプルアップされたRX(受信)から電流が本体に流れ込んで、PowerOnResetが出来なくなる現象と同じである。SDカードアダプターの制御線をしっかりGNDに落とし、SDカードが正常に動いたことは言うまでもない。

 やれやれ、解決したのは良いが、前のH8/3069Fのときも制御線をGNDに落とすのを忘れ、半年近くSDカードが動かない事件を起こしている。これとそっくり同じミスをするとは。年は取るものではない。

SDカードのウェブファイラー動く。しかし、実用には耐えなさそう(1/30/2016)
 SDカードが動いたので、その応用であるSDカードの中身をウェブから見られるウェブファイラーの実験に入る。使ったソースは、ここから頂いた。大したソース量ではないので、コピペ一発でスケッチを作り、動かしてみる。

Esp8266_sdcard  ビルドはNO ERRORだったが、実際の動作は、HTMLのエラーでまともに動かない。WiFiやサーバーの起動部分は正常に動いているようだ。用意されたSdrootというフォルダーの中のindex.htmlを読むが、どうもこのファイルではファイラーになっていないような気がする。

 GitHubの該当のディレクトリを見ていたら、Sdrootの下にさらにeditというサブディレクトリの中に別のindex.htmlがあった。中を見ると、どうもこちらの方が最新のようだ。試しに前のindex.htmlファイルと交換してみた。

 あてずっぽうだったが、見事にこれが当たりだった。ちゃんとブラウザーの画面にSDカードのファイル一覧が表示された。いやあ、たいしたものだ。スケッチソースを調べると、jpegファイルなどが画面に直接表示できるようである。 

 早速やってみた。出た。うーむ、出ることはでたが、目茶目茶遅い。以前のH8/3069F程度の遅さだ。測ってみたら、4KB/秒もかかっていた。SDカードの読み込みが遅いのか、ESP8266の中のスループットが低いのか今のところはわからない。しかし、これでは実用的にこのSDカードファイラーを使うのは殆ど無理だ。

Esp8266sdfiler  なるほどね。これが、ESP8266で画像の話題が出て来ない理由のようだ。なぜこんなに遅いんだろう。writeブロックが、1460バイト程度(HTTP_DOWNLOAD_UNIT_SIZE)では、こんなものなのかなあ。

 今のところ差し迫ったファイラーへのニーズがないので、追及に力が入らない。SDカードの実験はどうも先に進みそうにない。ESP8266への情熱が急速に冷めて行く。

ESP8266のアクセスポイント(AP)モードも超遅い(2/2/2016)
 長い間買うのを我慢していた、スマホ(iPhone 6s)を遂に導入した。海外旅行に向けて色々準備していることの一環だ。料金プランは月々の通話料を抑えるため端末を買い取ったが、長い間、単一ガラケーの所有者だったので、ポイントがかなり貯まっていて、思ったより安く手に入れることが出来た。それでも6万を超す出費だ。

 海外では4Gは通らないが、WiFiなら海外でも使えるルーターがレンタルできる。例えばスイスなら、swisscomというプロバイダーと契約したルーターが一日¥1000前後で借りられる。レンタルを申し込んで旅行に備える。

 自宅でWiFiのテストしていたときである。トイレに持ち込んでアクセスしたら、なんとここだけ我が家のWiFiが通らない。こういうときのESP8266である。こいつのWiFiモードには中継をするAP(アクセスポイント)モードというのがあると聞いている。早速試してみた。

 作業はとても簡単で、ATモードのとき以下のコマンドを入れるだけである。何でもない2ステップだ。動いたようだ。スマホにはちゃんとアクセスポイントとしてESP8266が表示される。
AT+CWMODE=2                     動作をアクセスポイント(AP)モードのみにする
AT+CWSAP="ssid","pass", chn, ecn 
ssid(id名)
pass(パスワード) 
chn(チャンネルID、1でよい)
ecn(エンコード 1= WEP, 2 WPA_PSK, 3 WPA2_PSK, 4 WPA_WPA2_PSK)

 いやいや、簡単なものである。繋いでみた。繋がることはつながった。しかし、残念。とても遅い。メールくらいならともかく、音声、画像は全く無理といってよい。

 WiFiの物理層のスループットがそもそも大きくないのか、組み込まれた32bitプロセッサーが遅いのか、それとも何か他に原因があるのかどうかはわからない。pingが1ms以上かかっていることから考えると、プロセッサーの論理層の処理が余り早くないのかもしれない。

 少し、ウェブで探してみたが、このあたりに言及するサイトは見つけられなかった。いずれにしても、ESP8266のWiFi中継は、デフォルトで動かす限り実用には程遠いレベルであることだけはわかった。そりゃそうだよね。¥500少々では無理な話だ。

ESP8266にI2C機器(DS3231)をつなぐ(2/8/2016)
 今度は、リアルタイマークロック(RTC)である。これもウェブあたりで沢山紹介されているI2CのRTC(DS3231)をアマゾンで手に入れた。このチップは、Arduinoで簡単に動くようである。I2Cなので結線もわずかである。これもあっけなく動いた。 

Dsc003890001  I2Cの部分はそっくり、人さまのソースを参考にしたのでこれに関しては、全く経験値は上がらない。手持無沙汰なので、Arduinoのコーディングの勉強を兼ねて、UARTで時刻の初期設定をするルーチンを組み込むことにした。

 簡単に行くと思ったがこれが難儀したのである。このArduinoの言語仕様がいまひとつ理解できていない。C++だというが、とても簡単なところでコンパイルエラーになる。それは、文字配列をストリング型に移すステートメントで言う事を聞かない。

 char buf[32];

として、新しいStringクラスのインスタンスstrに入れようと

   String str = new String(buf);

とするが、

error: conversion from 'String*' to non-scalar type 'String' requested

というエラーになる。どうもおかしい。Arduinoでは、newという命令が違う意味に使われているようなのだが、このあたりを解説するウェブサイトが見つからない。結局、このステートメントをあきらめ、最初からstring型で受信バッファーを作って、ごまかした。

 それに、Arduino IDEに付属しているシリアルモニターと、TeraTermなどのPCコンソールとは入力の状況がかなり違う。どちらも快調に動くしかけがなかなか作れない。これも、何とかArduinoの方に合わせ、初期入力が出来るところまで行った。

Dsc003860002  やっとのことでRTCの時刻設定が動き始めた。アマゾンで買ったこのDS3231基板には、時刻保持のためのボタン電池のフォルダーが裏に用意されている。良くわからないがボタン電池を入れて動かしてみた。電源を切って暫くしてもう一度電源を入れ直す。

 問題なく正しい時刻を表示した。これで当面RTCも動いた。 しかし、繰り返しになるが、どうも経験値が上がってこない。Arduinoの開発というのはこんなものなのだろうか。よく言われる諺の「靴を隔てて足を掻く(隔靴搔痒)」感が否めない。

あいついで新ディバイスの導入(2/15/2016)
 海外旅行のため、スマホに続いて思い切ってカメラも刷新した。ほぼ10年ぶりの更新である。撮像素子がほどほど大きく(APS-C)、軽量のミラーレスをチョイスした(Sony α6000)。これまでのデジタル一眼レフ(オリンパスE510)に較べれば、遥かに軽いうえに高性能である。

Sony_a6000  ISO感光度がとんでもなく高くなっているのに驚く(ASA25600)。夜の光景が真昼のように撮れる。WiFiでデータが送れる。ピント合わせが瞬間で終わる。いやいやここ10年の進歩はすさまじい。

 あれやこれやの新機器で周辺の整備に気を取られ電子工作どころではない。スマホやこのカメラを触ってみて、これまでの電子工作で驚いていた技術の進歩は、着実にこうした実社会にも反映されていることを実感した。

 スマホの方はGPSの進歩に感動である。何と地下鉄の中でもトレースするのだ。通勤の経路がほぼ完全にトレースできている。聞くところによると、a-GPSと言って、携帯基地局の場所から換算したGPSデータを送っているらしい。

 10年前、日本橋の事務所のビルの谷間では、現在地さえ把握できなかったGPSの性能に比べると格段の進歩だ。いや、車の無人運転が間もなく実用になるような時代だ。21世紀は着実に歩みを進めていることは間違いない。

15年ぶりの海外スキー。もう思い残すことはない(2/29/2016)
 海外スキーの話である。カナダで海外スキーしたのが15年前の話で、それ以来である。結論から言えば、やっぱり年だ。ヨーロッパまでの旅はいくら早くなったとはいえ、まだ10時間以上かかる。行き帰りの空の旅だけで相当体力を消費する。海外旅行はやはり若いうちに行っておくべきだ。

 搭乗するときビジネスクラス席を通過する。ゆったりとした席が用意されているようだが、いくら広くなると言っても、所要時間がエコノミーに比べて少なくなるわけではない。金をかけてもこの時間は少なくならないのだ。しかも時差で体の調子は一ぺんにおかしくなる。

Dsc002060003  20年ぶりのヨーロッパは、列車が新しくなって、さらに快適に早くなっていた。ツエルマットからインターラーケンという主要な観光地は昔、一日で回ることが出来なかったが、長大なトンネル(長さ34.5kmレッチュベルグベース)が出来て一時間以上短縮され、ツエルマットから日帰りで、ヨーロッパ最高標高列車地点のユングフラウヨッホまで行けるようになっていた。

 ここはほぼ30年ぶりの訪問である。しかし、今度も運命の女神はユングフラウヨッホで晴天をくれなかった。マッターホルンは2回とも微笑んでくれたのに、ユングフラウヨッホは2回ともはずれだ。最高点のレストランでワインを飲んでうさをはらす(気圧が低いので用心して一杯だけ)。

 氷河上のスキーは、日本とはスケールの違う滑り方ができる。何十年もスキーをやってきたが、至福の滑降を楽しんだ。もう思い残すことはない。ツエルマットからはリフト、ゴンドラを乗り継ぎ、国境を超えてイタリアまで行くことが出来る。この往復の一本だけで日本の2日分の滑走距離になる(30キロ以上)。

Dsc001470002  スマホのGPSは上空(成層圏以上か)では無効になることがわかった。成田から飛び上がり新潟方面に進路をとると間もなくトレースが止まる。しかし最寄りのチューリッヒ空港で復活した。日本で借りてきたスイスのWiFiルーターが動き、スイス国内のルート地図があらわれた。

 GoogleMapで現在地が把握できる。夢のような話である。いや、スマホに買い替えて良かった。スキー場での場所の把握も簡単に出来る。スイスのスキー場は大抵のコース上でWiFiが効く。もっとも、コース上ではガイドについていくのに精いっぱいで、これをゆっくり見ている暇はとてもなかった。

 帰りに、添付写真のような立体地図を高速道路のサービスエリアでみつけ思い切って買って来た(117スイスフラン、1万3千円程度)。枠が大きすぎて機内持ち込みは出来なかったが、添乗員の計らいで「こわれもの」として別送してくれた。感謝、感謝である。Dsc003910001

帰国してからの電子工作。ArduinoでRTC時刻設定部を整備する(3/15/2016)
 日本に帰ってきてすぐ、風邪を引き、電子工作の再開はさらに延びた。参加者の人たちにOneDriveで、撮りためた写真を配布する。先方からも写真が届く。写真を見る度に、その場の雰囲気が思い出され、気分が高揚する。

 海外旅行好きの親父が良く言っていたのを思い出した。「海外旅行は、行く前と行った後が楽しい。最中は疲れる」というのだ。父はいまの私の年齢と同じころ盛んに海外旅行を楽しんでいた。 まさしくその気分である。行く前は、期待と不安で胸が膨らみ、帰ってからは楽しかったことだけが残る。途中は既に書いた通り、疲れることが多い。

 事務所に出たり、久しぶりにジムに出てステップで汗を流したり、日常の生活が戻ってきた。そろそろ電子工作に戻る時期だ。机の前を片づけて、PCを開き、Arduino IDEを立ち上げて以前のソースを眺める。

 一応、UARTから年月日や時刻が設定できるようになっているが、現在の設定は、年月日時分秒をただ直列に文字列に並べ、一気に定義する方法で人間にやさしくない。ウェブでもっと親切な時刻設定のスケッチを探したが、簡単には見つからなかった。それなら自分で作ってやろう。このあたりは力仕事なので、適当なところを関数に切り出してやらないと冗長なソースになる。

Esp8266rtc  うーむ、まだ、ArduinoのC++に慣れないな。stringというデータタイプは便利だが、他のデータタイプがCとはずいぶん違う。1バイトのバイナリ―を定義するため、データタイプをbyteと定義すると、コンソール出力が十進数字で出てくるのには参った(余計なお世話だ)。

 何とかひねくり回し、一応I2Cのリアルタイマークロックの時刻をコンソールから設定するArduinoのスケッチが完成した。年と月日、時分秒の3つを別々に設定できる。既に設定したところはリターンキーで素通りできるのがちょっと工夫したところだ。曜日の設定は、ウェブから変換式を手に入れたので改めて入力する必要はない。
 以下に、DS3231を使ったRTCスケッチのソースを.inoファイルの形で置きます。適当なプロジェクトフォルダーに入れてArdluino IDEでコンパイルしてください。

「sketch_DS3231.ino」をダウンロード

  これを公開してブログ再開の節目としよう。まだ、WiFiモードがバックグラウンドで動くのが気に入らないし、立ち上がりの時のボーレートの違うメッセージのゴミも気になるが、これはいずれ直すことにする。

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

2016年1月26日 (火)

ESP8266の冒険は続く(画像付きのサイトにする)

 お正月というにはもう日が経ちすぎてしまいましたが、遅ればせながらみなさま明けましておめでとうございます本年最初のブログ記事を掲載いたします。内容は昨年暮れからのESP8266まわりのお話の続きです。やりだすと止まらない性質(たち)で、すっかりこのWiFiモジュールにはまっています。

 少し脱線気味なのですがArduino IDEで、とうとうページに画像の出るWebサーバーまでESP8266で作ってしまいました。ESP8266は結構大きなフラッシュメモリを持っていますので、これをファイル替わりに使うと、ちょっとしたJPEGデータを入れたページを作ることが出来ます。

 しかしさらに欲を出してSDカードにまで拡張しようとして頓挫しました。やっぱりハードがからむとArduinoと言えどもそう簡単には動いてくれません。ともあれ、暮れからここまでのESP8266によるWebサーバーの実験の数々をご紹介いたします。

Arduinoは楽だけど、こんな電子工作で良いのだろうか(1/3/2016)
 新年が来た。今年は家族が酷い風邪をひいてちょっとお正月どころではなかったのだが、電子工作は絶好調である。ESP8266に簡単なウェブサーバーを入れ、ネットを通してLEDの点滅が出来るまでになった。ウェブには他にも沢山の応用例が紹介されまだまだ色々なことができそうである。

02p1257479  出来たと言っても、今度のサーバーのLEDの点滅は、IPアドレスのあとにいちいち違ったリンク名を加えないと変わらない(/gpio/0か/gpio/1)。ここまで来たら一般の画面と同様、ON/OFFのボタンのクリックでLEDが点いたり消えたりするようにしたい。

 GitHubなどからサーバーのサンプルコードを片っ端から持ち込んで調べる。Arduinoのスケッチは、基本はオブジェクト指向言語のC++なので、Nodeのときにも愚痴ったように、この種の言語はデータの抽象化が大規模なので、ソースはとても追いにくい。

 そのうえライブラリーの公開がどうも一部だけなので(探せばあるのだろうが)、少し詳しく調べようとするとすぐ壁にぶつかって先に進めなくなる。それでも、ウェブ記事の中で、これからやろうとしている、hrefタグの文字列のクリックで候補を選ばせるようなっているスケッチを見つけた(ここのサーボモーター制御のところ)。

 半日かかってHTMLをもう一度勉強し直し、このソースを参考に、スケッチを修正し始めた。そのコーディングの最中、長年疑問に思っていた謎が突然解決したのである。謎というのは、ファイルの概念のないサーバーでどうやって別の画面へリンクしているのかが分からなかった。

 画面そのものは、あのタグの沢山入ったHTMLテキストをプログラムで作れば出るはずだが、画面から画面のリンクや、画像送出のロジックをファイルなしにどうやって実現するのかが謎だったのだ。

 考えてみれば、HTMLのタグ<href=リンク先>や<src=ファイル名>は、そのリンクをクリックすれば、クライアントはリンク先をこれにしたGET要求レスポンスをサーバーに返してくる。これらは単なる文字列なので、これを調べるだけで、サーバーはこれから何をすべきかが判断できる。

 そうか、何もファイルを用意する必要はないのだ。わかってしまえば何ということもない話だが、わからないときはこんなものである。今までもやもやしていた謎がすっかり晴れた。目から鱗が落ちた気分である。

 それはともかく、参考にしたスケッチを少しだけいじって、LEDの点滅が画面の文字のクリックで出来るように修正した。出来た。ちゃんと動いた。あきれた。7年前にドイツのソースコードを導入して、えんこらえんこら作ったAC電源コントローラーのしかけは、ものの見事に1時間もしないうちにESP8266の中で完動した。

Esp8266_led  これはESP8266がすごいということに加え、Arduinoのしかけが優れているということなのだろう。シリアルポートの開設にしても、GPIOの設定にしても、全くハードを知る必要がない。何も考えないで楽々とI/Oディバイスを動かせる。

 それに文字列の検索でも、文字列の中から所定の単語を拾い出す多様な関数が最初から用意されており、簡単にリンク先を選別するコードが書ける。文字数やデータタイプを気にする必要もない。

 しかし、これで本当に電子工作をやったことになるのだろうか。車の楽しみと同じなのかもしれない。昔は、中古自動車を整備して箱根の峠を超えられるかどうかが、一人前のドライバーの証しだと言われていた(昔のポンコツ車は坂で簡単にオーバーヒートして箱根を登りきれなかったのである)。

 電子工作でも同じだ。AVRやARMで、データシートを穴が開くまで読み、制御レジスターを設定し、せっせとコーディングしていた。UARTだけでも字化けせず通信出来るまで結構な手間と努力を必要としたのである。成功すればそれだけで美味しい酒が飲めた。車と同じで、電子工作の楽しみの場所がどんどん変わっているのだと考えるしかない。

フラッシュメモリーにファイルシステムを構築。本格的サーバーへ(1/8/2015)
 Webサーバーはファイルが使えれば本格的になる。ウェブによれば、ESP8266でもSDカードが読み書き出来るようだ。しかしハードの実装はそう簡単ではない。その前に、ESP8266が持っている豊富なフラッシュメモリーを利用したフラッシュファイルシステムを試してみることにした。

 index.htmlファイル位ならこの程度で十分だし、ちょっとした画像がESP8266のページに載るとお洒落ではないだろうか。日本語のサイト(http://blog.boochow.com/article/427214036.html)に、このフラッシュファイルシステム(SPIFFS)を丁寧に説明しているところがあったので、やってみる気になった。

 導入はこのサイトにあるように、1)まず、Arduino IDEのバージョンを開発用に換え、2)フラッシュメモリにファイルシステムをアップロードするプラグインをArduino IDEに加える。3)それを使ってESP8266のフラッシュにファイルシステムを作る。4)それを対象に、いくつかの関数群で、ファイルを登録したり、削除したり、中身を読み書きする。

 早速、指示通り作業を進める。2)のArduinoのプラグインのダウンロードとインストールまでは順調に進んだ。Arduinoの「ツール」メニューに、ESP8266 Sketch Data Uploadというプラグインのメニューが出来る。

 しかし次のステップ3)で止まった。プラグインを実行するとエラーメッセージが出て、ファイルシステムが出来ない。プラグインのバイナリ(.jarファイル)を入れる場所を替えたり(ユーザーディレクトリ内でもArduinoのシステムディレクトリでも動く)、プラグインのダウンロードをしなおしたり、色々やるが同じエラーだ。

 簡単にあきらめないのが所長の取り柄である。あきらめずに試行錯誤するうち、遂にプラグインが通り、ファイルのアップロードに成功した。原因はプラグインのバージョンが最新のArtduino IDEと合っていなかったためであった。

 日本語サイトが紹介した、プラグインのURLは、http://arduino.esp8266.com/ESP8266FS-1.6.5-1105-g98d2458.zipで、9/9/2015のタイムスタンプがあるが、これは少し古く、最新のSPIFFSのサイトにあるESP8266FS-0.1.3.zip(タイムスタンプは11/13/2015)だとArduino1.6.7でも動く。

 このプラグインは、カレントスケッチのフォルダー(現在の作業場所で.inoファイルのあるところ)の中に作ったdataフォルダーに収容されたファイルすべてをフラッシュメモリー内にインストールする。うまく行ったかどうかは、このdataフォルダー内のファイルの名前がアップロードの際に表示されるので簡単に確認できる。

Ws000002  この最新のプラグインの提供サイトは、最初の日本語サイトで紹介されたがリンクが行方不明(404)になっているサイトらしく、これを発見できたのは、例の「エラーメッセージの丸ごとサーチ」によるところが大きい。同様なエラーで悩んでいる人がポストした海外のフォーラムが見つかり、その中で紹介されていたサイトが上記のGitHubのサイトだった。

フラッシュ内のディスク読み出しは成功(1/9/2015)
 3)のファイル組み込みがうまく行ったので、次の4)のステップに入る。ESP8266のスケッチで、フラッシュファイルシステムを起動させ、ファイルが読めるかどうかのテストである。

 先ほどのdataフォルダーに適当なテキストファイルを入れた。Arduino IDEのプラグインを始動させ、フラッシュに書き込む。そのあと、このテキストファイルを読むスケッチを書く。表示先はシリアルモニターである。動かしてみた。問題なくテキストファイルの内容がモニターに表示された。

 よーし、快調だ。このファイルシステムの最終目的が決まっていないので何をもって成功と言えるのか、はっきりしないところだが、少なくともやろうと決めたことが確実に実現していくことは、とても気分が良いものである。次はいよいよHTMLの中への画像埋め込みである。

 ESP8266は、2MBのフラッシュメモリがあり、通常は半分も使っていない。さしずめ、JavaScriptなどを使った派手な制御画面のindex.htmlを作ることが第一の目標だが、もうひとつは画像の表示である。ページの背景画像にもなる。ただアップロードが遅い(11520bps 1.4KB/s)ので、テストのため小さな画像を探す。

 昔、携帯にいれていた先代の猫の絵が見つかったのでこれを選ぶ(12KB)。HTMLにおける画像の表示のロジックを調べ始める。どうもこれまでのArduinoスケッチのWebサーバーに関する関数群(メソッド、メンバー)の対象はすべてが文字列で、jpegファイルのようなバイナリーファイルは出来ないようだ。

 また、ネットで色々調べる。原理は、先ほどのGET要求レスポンスからファイル名を拾って、文字列のときと同様にファイルの中味を送れば良いはずだ。しかし具体的なコード例が見つからない。やっとpythonのページでやりかたを見つけた。

 何だ、やり方はとても単純だった。content type: image/jpegなどのヘッダーデータの改行文字のあとに、バイナリを送れば良いだけだ。しかし、これまでの使っていたArduino IDEのWebサーバーの関数で試してみたが、みなうまく動かない。

JPEGファイルの送出が難しい。バイナリ―データを送れない(1/14/2016)
 ESP8266の紹介サイトでも、このあたりになると日本語サイトは少ない。英語サイトにはあるのだろうが、つい無精して日本語版ばかり探す。ATコマンドでの動作など、入門部分を紹介するサイトは山ほどあるのだが、こうしたちょっと先に進んだ具体的な応用例を紹介するページは見当たらない。

 一方では、ここのサイトのように、かなり高度な開発を紹介しているところもある。IOTの最先端の部分でもあり、情報は少し閉じた所で流れているのかもしれない。まあ、ESP8266で画像を出すホームページの需要などは殆どないだろうから、当たり前と言えば当たり前か。

 ESP8266のWebサーバーのコードは、何種類かあって(ArduinoのEtherシールドからの派生もあるようだ)、その差を調べようとするが、参考になるサイトは見つからない。こうなると、紹介されているサイトのソースコードをしらみつぶしに調べて、バイナリを送っているコード例を探すしかない。で、片っ端から中味を調べる。

 すると、このサイト(ソース後半)で、こういう使い方をしているところが見つかった。

   client.write(dataFile, HTTP_DOWNLOAD_UNIT_SIZE);

 まず、printではなくwriteというメソッド(メンバー関数?)と、このHTTP_DOWNLOAD_UNIT_SIZEという定数があやしい。clientというwebサーバーのオブジェクトの仕様がどこを捜しても見当たらないので確実ではないが、どうみてもこれは、HTTP_DOWNLOAD_UNIT_SIZEの長さ単位にバイナリファイルを送っているように見える。

Ws000003  だめもとである。このdataFileオブジェクトに例の猫の絵のファイルを入れ、テストしてみた。
ビンゴ!である。ESP8266のLEDのon/off指示画面の下に見事に猫の画像が表示された。いやあ、嬉しい。表示速度は少し遅いが、まぎれもなく先代の猫の絵だ。

画像付きホームページ完成。スケッチソース公開(1/18/2016)
 いくつかのサイトのスケッチソースを参考にしながら、画像付きのLED点滅のホームページが完成した。制御方式は、最初はイベント駆動のような形をしたserver.on("リンク文字列",割り込みエントリ)で、割り込み先を作り、loop()の中は割り込みハンドラーだけにする方式だったが、途中で変えた。

 割り込み方式では、エラーが、どうやっても取れなかったことや(プロセスが終了しない)、共通する処理をすべての割り込み部に書く必要があり、コードに無駄が多かったので、普通のloop(){}の中にすべての処理を入れる方式に変えた。

 スケッチソースを参考までに以下に掲載する。この前に、jpegファイルは、esp8266.jpgとして前記のフラッシュファイルシステムに登録しておかないと動かないのでご注意。不慣れなC++コーディングなので無駄なところがあることはご勘弁ねがいたい(とりあえずはこれで動いている)。

/* フラッシュファイルシステムを使った画像の出るサーバー
 *  1/11/2016    (C) 2016 LABO Gataro
 *  ref. http://qiita.com/tadfmac/items/17448a2d96bd56373a66
*/
#include <Arduino.h>
#include <ESP8266WiFi.h>
#include <WiFiClient.h>
#include <ESP8266WebServer.h>
#include <FS.h>

#define BUFFER_SIZE 16384
const char *ssid = "XXXXXXX";      //"ここには無線ルーターのSSIDを記述";
const char *password = "YYYYYY";   //"ここには無線ルーターのパスワードを記述";
unsigned char buf[BUFFER_SIZE];
String s;
int val;
File jpegFile;
WiFiClient client;

//ESP8266WebServer server(80);
WiFiServer server(80);

boolean readFFS(){
   jpegFile = SPIFFS.open("/esp8266.JPG", "r");
   if(!jpegFile){
    Serial.print("Failed to open /esp8266.jpg");
    return false;
   }
   size_t size = jpegFile.size();
  if(size >= BUFFER_SIZE){
    Serial.print("File Size Error:");
    Serial.println((int)size);
  }else{
    Serial.print("File Size OK:");
    Serial.println((int)size);
  }
  return true;
}

void Drawjpg(){
  jpegFile = SPIFFS.open("/esp8266.JPG", "r");   // test test test
  size_t totalSize = jpegFile.size();
  delay(1);
  Serial.print("JPEG proc size=");
  Serial.print(String(totalSize) + "\n");
  client.write(jpegFile, HTTP_DOWNLOAD_UNIT_SIZE);  // send a binary file 
  jpegFile.close();
}

void setup() {
 Serial.begin(115200);
 delay(10);

 pinMode(2, OUTPUT); 
 digitalWrite(2, 0);
 
 Serial.println();
 Serial.println();
 Serial.print("Connecting to ");
 Serial.println(ssid);
 
 WiFi.begin(ssid, password);

 SPIFFS.begin();     // フラッシュFSを開く
 if(!readFFS()){
  Serial.println("Read FFS error");
 }
 
 while (WiFi.status() != WL_CONNECTED) {
   delay(1000);
   Serial.print(".");
 }
 // Solid IP http://ashiyu.cocolog-nifty.com/blog/2015/08/indexhtml-8dfa.html
 WiFi.config(IPAddress(192,168,NNN,MMM),WiFi.gatewayIP(),WiFi.subnetMask());
 Serial.println("");
 Serial.println("WiFi connected");
  
 server.begin();
 Serial.println("Server started");
 Serial.println(WiFi.localIP()); 
}

void loop() {
 client = server.available(); 
 if(!client) return;
 Serial.println("new client");
 while(!client.available()){
  delay(1);
 }
 String req = client.readStringUntil('\r');
 Serial.println(req);
 client.flush();

 if(req.indexOf("/gpio/0") != -1 ){
  val = 0;
 }
 else if(req.indexOf("/gpio/1") != -1 ){
  val = 1;
 } 
 else if(req.indexOf("/esp8266.jpg") != -1) {
  s = "HTTP/1.1 200 OK\r\nContent-Type: image/jpeg\r\n\r\n";
  client.print(s);
  Drawjpg();
  client.flush();
  delay(1);
  Serial.println("JPEG was sent");
  return;
 }
 s =""; 
 s += "<html lang='ja'><meta charset='UTF-8'>\r\n";
 s +="<style> a{ font-weight: bold; color: #FF6666;} </style>";
 s += "<h1>ESP8266 リモートLEDスイッチ</h1>"; 
 s += "<p>押されたスイッチは ";
 s += (val)?"ON":"OFF";
 s += "<ul>";
 s += "<li><a href='/gpio/0/'>OFF</a></li>\n";
 s += "<li><a href='/gpio/1/'>ON</a></li>\n";
 s += "</ul> \n";
 
 s += "<p> ここに画像を入れるテストをします </p>\n";
 s += "<img alt=\"graph here\" src=\"/esp8266.jpg\" />";    //"内の\はエスケープ
 s += "</html>\n";

 client.print(s);
 digitalWrite(2, val);
 delay(1);
 Serial.println("Client disconnected");
 client.flush(); 
}

SDカードの実装ができない(1/24/2016)
 このあとさらに、SDカードの実装まで挑戦した。以前使っていたリニアPCMプレーヤーのテストベンチから、SDカードアダプターをとりだしESP8266につける。大した配線量ではない、簡単にすんだ。

 次はソースだ。ソースは、すでに色々なところで公開されている。大元のGitHubまで戻り、sdcardinfoのスケッチを頂く。コンパイルも無事終了した。勇躍テストである。適当なSDカードを入れて電源ON。

01p1257472  残念、初期化がエラーで返ってきた。さあ、これからどうする。SDクラスライブラリの解析は資料もないし不可能だ。この種の言語は動けば便利だが、動かないときは全く手も足も出ない。とりあえずはオシロを持ち出して初期化の波形を調べる。

 調べた結果は、ESP8266からのCSや、CMD(MOSI)は正常に出ているが、SDカード側からはレスポンスがないということがわかった。うーむ、これはハードか。時々状態が変わるときがあるので、接触不良の可能性もある。

  オシロではこのあたりが限界だ。ロジアナで徹底的に調べるにしても情報が不足している。やっぱりハードがからむとArduinoでも一筋縄では行かない。このあたりで一区切りつけてブログに報告することにしよう。

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

より以前の記事一覧

その他のカテゴリー

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