« 2017年11月 | トップページ | 2018年1月 »

2017年12月の2件の記事

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月 | トップページ | 2018年1月 »