« 2011年2月 | トップページ | 2011年4月 »

2011年3月の3件の記事

2011年3月30日 (水)

Xbee ZB APIモード汎用モニターのソース公開

 遂にXbeeのAPIモードを使ったリモートATコマンドが動いた。親機から送ったコマンドがリモートの子機に伝えられて子機のLEDが点いたり消えたりする。これでラジコンのための機能は実現した。いやあ今度も最後の一歩が長かった。ローカルのATコマンドが動いてから、リモートを動かすまでに3日もかかっている。

P3303742

やっとのことでリモートATコマンド稼動(3/24/2011)
 リモートATコマンドが動かなかった原因は、今度もわかってしまえば何でもないところだった。親機(マイコンにつけたコーディネーター側のXbee)ではAPIフレームに入れたコマンドが動き、続いてパラメーターの入力の開発にとりかかったころ、戯れにX-CTUでリモートコンフィギュレーションの画面を出してみたら、何と子機のアドレスが画面に現れ、パラメーターの読み書きが出来るようになっているではないか。

 これはXbeeのAPIモードでのリモート環境が正常に動いていることを示している。リモートATコマンドが動かないのは、みなこちらのせいだ。原因究明に力が入る。しかしAPIフレームのフォーマットをいくら調べてみても間違っていない。アドレスは何度見ても正しい。無線なので、中のデータを覗くわけにも行かない。これ以上調べるところがない。

 ただ、気になっていることがひとつある。親子に同一の2バイトのPAN(Personal Area Network)ネットワークアドレスを指定しても、返ってくるレスポンスデータには、必ず0xFFFEというブロードキャストアドレスが所定のエリアに載っている。

 無印のXbeeとXbeeZBでは、このあたりのアドレスの取り扱いが大きく変わっており、マニュアルを読み込んでいないので自信はないが、どうもこの2バイトアドレスは、ネットワークがつながる度にダイナミックに決まっているような感じである。ただしX-CTUでは任意に初期設定ができる。

 だめもとで、送信APIフレームのネットワークアドレスの欄を、返ってきた値と同じ、0xFFFEにして動かしてみた。やったー、ビンゴ!である。リモートにコマンドが届き、レスポンスがNo Errorで戻ってきた。

 やっぱり、おかしい、おかしいと思っていたこの2バイトアドレスが張本人だった。もういちど丁寧にマニュアルを読み込む。ZBでのこのアドレスは、無印Xbeeのときのような所定のPANアドレス(PANID)ではなく、ネットワークが確立する度に、コーディネーター(親)がエンドディバイス(子)に対して振り直すようだ。

 それを無視して一定のPANIDでアクセスしても子供は見つからないと言うことか。そう言えば、ログを調べているうち、一回だけ動いていたのを見つけたことがある。これは最初の通信だったからだろうか? それならどうして指定することが出来る。わけがわからない。

 それはとにかく、今のところ本気でXbeeのネットワークを組む気はないので、とりあえず親機でネットワークアドレスを0xFFFEにしておけば、万事解決である。動けばそれで良い。いやいや、久しぶりに解決したときの爽快感を味わう。体の動きが軽い。

リモートのI/Oピンを動かすのに成功!(3/25/2011)
 興奮が納まって次の課題に取り組む。実は、まだ当面の目的に達していない。動いたのはコマンド問い合わせ(query)だけで、コマンドのあとにパラメーターを指定してデジタルピンなどを動かす設定(modify)機能が動いていない。パラメーター指定はUARTからなのでキャラクターを、APIフレームのためにバイナリに換えなければいけない。

 さらにソフト開発を続ける。これが結構難しい。APIフレームのデータレイアウトはアライメントが無視されているので、4バイトバイナリーなどはうっかり使えない。1バイトづつの処理が必要だ。アスキー文字の16進表示を実際のバイナリデータにするのは、1対2でデータをずらしていかなければならない。簡単には行かない(1バイトのデータを得るのに、2バイト分のキャラクターが必要)。

P3303744

 これで良いと思ってテストしても想定したバイナリが入らず、Invalid Parameterのエラーメッセージではねられる。意地になって、久しぶりのコーディングに夢中になる。手当たり次第にprintfで途中経過を表示させながら、何とかATコマンドの後についた16進数キャラクターをパラメーターのバイナリーにするロジックが完成した(出力側のAPIフレームのパラメーターエリアを固定にして最後からデータを入れていくのがミソだった)。

 パラメーター入力はコーディネーター(親機)の方では正常に動いた。次はいよいよリモートだ。あせる手でエンドディバイス(子機)のXbeeのブレッドボードにLEDをデジタルピンD1につけ、PCに戻って親機の方から子機にデジタルピンを上下するコマンド、ATD14(D1ピンをOFF(4)にする)を入れる。点いた!(LEDをVccにつないでいるので負論理) やった、やった。今度は、ATD13(ON)。消えた。けなげに点いたり消えたりするLEDがいとおしい。撫でてやりたい。よしよし、これでXbeeだけでラジコンを動かす機能は実現した。完成まであともう少しである。

100ミリ秒で制御できれば何とか使えるか(3/26/2011)
 ただ喜んでいるわけにはいかない。LEDの点灯や、消灯は、コマンドを入れて一瞬とは行かず、ほんの少しだが一呼吸おいて動作する。どれくらい遅れているのだろう。ラジコンが動かせるくらいの早さでON/OFFが出来ているのだろうか。 

P3243737

 オシロで時間を測ってみることにする。2現象でPCからマイコンに行くUARTと、マイコンからコーディネーターXbeeに行くUARTの2箇所と、実際のエンドディバイスのXbeeのLEDのON/OFFの間を比較する。PCを起点とするUARTからでは200ms、マイコンからXbeeへのUARTからなら50~100msでピンの制御ができることがわかった。思ったより早い。

 ラジコンのコントロールはタクトスイッチでやるとするなら、PCからのUARTの早さでなく、マイコンからXbeeへのUARTの早さでコントロールできるだろう。100ms以内で動きそうだ。車程度ならそう遅れを感じずに制御できるだろう。

 それにしてもAPIモードは難しい。分からない単語が頻発する。もともと省電力化した複雑なネットワークを意識しているので、盛りだくさんの機能がついている。エンドディバイスもデフォルトで、スリープモードに入るようになっている(制御が始まれば暫く動いているが)。今のところラジコンだけが目的なので、当面このあたりは関係ない。

P3243738

 マニュアルを読んでいると、あまり詳しく設定しなくても、エンドディバイスを兼ねたルーターをいくつも介して、遠方にいるXbeeとメッセージ交換ができるようで興味をそそられるが、暫くはお預けにする。

 こういう性格なので、いちどのめりこむと元へ戻るのに時間がかかる。だいたいXbeeだってモーター制御をやろうとして、ラジコン制御に気が移り、寄り道した完全な道草だ。それよりAPIモードのモニターの完成度をもう少し高めようと思う。今のままではとても人さまに使ってもらえる状態ではない。

汎用的なAPIモニターの制作へ(3/27/2011)
 汎用的なとは言ったものの、現在のプログラムは、PCにつなぐUARTは、ChaNさんのシリアルISPプログラムライターのケーブルを利用した特殊なUARTだし、子機のアドレスはプログラム決めうちでコンパイルしなければ変更できない。とても汎用的とは言えない。

 しかし、ウェブを見ているとXbeeのAPIモードでの取り扱いはみな苦労している。頼りのユーティリティX-CTUはAPIモードになってしまうとコマンドはいちいちフレームを作らないと動かせないからだ。

 X-CTUでは、パラメーターの設定はリモートまで出来るが、ファームに全部の設定をバッチジョブ的に書きこむだけで、ATモードのときのように適当なコマンドを入れて確かめたり、設定を臨時に変えたりすることは出来ない。

 これに対して、今のプログラムは、少なくともコーディネーター配下につながる全てのAPIモードのXbeeに対し、任意のコマンドとメッセージを送ることができる。アドレスをプログラムで換えられるようにするなど、あともう少し機能を追加すれば、みんなの役に立つツールになるのではないかと考えた。道草ついでに少し時間をかけてみることにする。

 そこで、まずAPIモードのもうひとつの方法、Escapeモード(ATAP=2)も実装することにする。今度のラジコンには関係ないが、アナログセンサーなどにXbeeをAPIモードで使うときは、普通のAPIモードでは実用的ではない。フレームのヘッダー文字0x7Eがデータの中に現れたら、そのフレームは目茶目茶になる。 

まあ、APIフレームにはデータレングスがあるので、すべてのソフトが注意深く作られていれば問題ないはずだが、ちゃんと守らない奴が中継する経路のどこかに居るとデータの保全は保証されない。エスケープしておくことに越したことはない。

 この実装は、思ったより簡単に出来た。1バイト送受信の一番フロントにロジックを入れてやれば良い。あとは変更する必要がない。エスケープする文字は、ヘッダーの0x7Eだけでなく、エスケープ文字そのもの0x7Dと、シリアルのフロー制御文字XON(0x11)、XOFF(0x13)まで必要とマニュアルにはある。いまどき、XON、XOFFでフロー制御しているところもなさそうだが、言われるまま全部エスケープする。勢いに乗って、APIモードも動作中に切り替えられるようにする。

 ソフトが出来たのでテストである。まずXbeeの双方をX-CTUでAPIのEscape付きモードに変更する。ビクビクしてX-CTUを動かしたのだが、2ヶともファーム復活をさせられることもなく、writeだけで問題なくEscapeモードになった。だいぶX-CTUの動かし方にも慣れてきたようだ。Escapeモードでも問題なく動いた。よーし、これで一歩、完成に近づいた。すべてキャラクターベースのインターフェース(CUI)だが、あとは64ビットアドレスの入力だ。

Xbee329

汎用モニターひととおり完成(3/28/2011)
 EEPROMにリモートの64ビットアドレスを収容し、プログラムをコンパイルし直さないで、コマンドからの入力でアドレスを設定するルーチンがやっとのことで動いた。8バイトの16進アドレスをキーボードから入力させるロジックは結構面倒である。

 ATOIなどの標準ライブラリには、16進数のキャラクターをバイナリに変換する関数もあるようだが、使い方が難しく、今愛用させて貰っているChaNさんのxatoiにはその機能がない(あることはあるのだが、0xというプリフィックスをつける必要がある)。全部自作するしかない。

 フラッシュに余裕があるとはいえ(まだ5KB少々)、同じようなロジックの繰り返しは避けたい。8バイトをすべて入れさせるのは、キャラクターベースでは間違いやすいので、4バイトづつ分けて2回に入力をさせるようにしたため、これをまとめるのに苦労した。

 Windowsのような画面からの入力に慣れていると、多バイトの入力は気にならないが、CUIでは難しい。昔を思い出しながら、せっせとコーディングする。繰り返される入力の部分は関数に切り出した。このあたりは力仕事に近い。

夜半、ついに完成した。出来たソフトを動かして、一人で満足する。デバッグのための送受信のテストメッセージが延々と出てくるが、むしろこれは残しておいた方が便利かもしれない。現在のAPIフレームモニターの機能は以下の通りである。

コーディネーター及び、リモートのXbeeにAPIモードで任意のコマンドが送れる。
リターン キーでコマンドを確定すると、それぞれ、所定のフォーマットで結果が
戻されてくる。

tABnnn コーディネーター(親機)にABというコマンドを送る。nnnは設定するときの
             パラメーター。コマンドABとnnnの間にブランクを入れない。nnnは、
             8文字(4バイト)までの16進数。右詰めで左の0は省略可能。

rABnnn リモートにあるエンドディバイス(子機)へのATコマンド。仕様は上と同じ。

リモートにはメッセージが送れる。

;ABCDEF    リモートディバイスに;以下のテキストを送る(1パケット40文字まで)。
                  リターンキーがテキスト終了を示す文字なので、リターンキー(0x0D)は
                  送れない。

いくつかの設定用コマンド

d0 d1 Xbeeからの受信APIフレームを、16進表示だけの文字列(d0)にするか、
         一定のレスポンス(5種類)については、アドレスやパラメーターを
         フォーマットして出力する(d1)かを決める。デフォルトはd1。

a1 a2  APIモードにおける、通常APIモード(a1)か、エスケープ付き(a2)かを
     選択する。デフォルトはa2(エスケープ付き)。
     ATモードにはならない(そもそも意味がない)。 

ad    エンドディバイス(子機)の64ビットアドレスを設定する。adだけ入れて
   リターンキーを押すと、現在設定中のアドレスが表示されるので、それを
   参考に1バイトづつブランクを空けて入力する。

   00は0でも良く、上位0は省略できる。上位(Higher)の4バイトと、下位(lower)の
   4バイトを分けて入力する。リターンキーだけのときは変更しない。

       最後に64ビットすべてが表示され確認を求められる。Yかyを入れると
   EEPROMに書かれ、以後はそのアドレスが使われる。

   プログラムの最初にはこの設定が必ず必要である(EEPROMには
   ダミーアドレスが入っている)。なおフューズビットはEEPROMを保存する
   ようにしておくと便利である。 

h       以上のコマンドの簡単な紹介。

 Xbeeからの受信メッセージはdコマンドに従って、画面に表示される。d1を選んでもコマンドレスポンスなど良く出てくるメッセージ以外は、すべて16進コードで表示される。

 なお、このプログラムは、ChaNさんのシリアルISPライターがないとUARTが動作しない。同じ仕様の市販のライターもあるようなので、とりあえずはこのままにすることにした。ソースコードを公開するので、普通のUARTに換えるときは、soft_uart.cを変更してほしい。

 ただ、このISP-UARTはChaNさんのオリジナルUARTソースを大幅に変更して、受信待ちをせず、データをバッファーに蓄える改良が施され、ピンチェンジ割り込みで動くようになっているので、簡単には移植できないかもしれない。そのときはブログにコメントを頂ければ、改良版を作りたいと思っている。

ここに例によってAVRStudioのフォルダーを固めたソース一式を置きます。無印Xbeeも動きますが、色々なところでAPIフレームのフォーマットが異なるので注意が必要です。

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

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

2011年3月25日 (金)

Xbee ZB APIモードにはまる

 モーター制御のついでに、以前試したことのあるXbeeを使って簡単なラジコンを作ろうとXbeeを新しく買ってきたのは良かったが、ラジコンそっちのけで、Xbeeにはまってしまった。

 そもそもは、Xbeeの遠方の子機にコマンドを送る機能(リモートATコマンド)を使って子機のデジタルI/Oを動かしそれでラジコンカーのモーター制御をするつもりだった。Xbeeはシリアルの無線通信の替わりに使うだけなら至極簡単で楽なのだが、少しネットワークっぽくやろうとか、センサー機能をAPIモードで使ってやろうなどと考えると、途端にとんでもなく難しくなる。このAPIモードというのが曲者(くせもの)である。今度も気楽に始めたが、泥沼に足をとられて収拾がつかなくなってしまった。

大きな勘違いをしていた(3/10/2011)
 秋月から買ってきた新しいXbee(ZB)2つをあやうくお釈迦にしてしまうところを、何とかDigi Internationalさんの支援で元へ戻し、不勉強を反省してXbeeをあらためてウェブで真剣に調べ始めた。2年前に較べるとウェブ上にもたくさんXbeeの話題が載っている。読んでいくうち自分が大きな勘違いをしていたことに気がつく。

Xbeezb_2

 最初に買った無印のXbeeはいわゆるOEM仕様といわれるハードウエア規格だけのIEEE802.15.4仕様というチップで、Zigbee規格というのは、ライセンスを支払ってこの上に載せるソフトウエアプロダクトだと思っていた。ところが、今度買ってきたXbeeは、そのZigbee規格を既にファームで持っているシリーズ2だという(このあたりは、次のブログが詳しい。http://todotani.cocolog-nifty.com/blog/2010/12/xbee-f604.html PS3とLinux、電子工作も

 これまでの理解とは大分違う。今度買ってきたシリーズ2のZBはあのZigBeeそのものなのだ。無印のXbeeは、ソフトで、Zigbeeになれるが(正確にはZnet2.5という独自規格らしい)、シリーズ2のXbee ZBは始めからそうなのだ。

 道理で、XbeeユーティリティのX-CTUで、MyAddressが設定できないわけだ。そもそもZBではコーディネーターと、ルーターと、エンドディバイスのファームが違うので、動作中に役割を変えることが出来ない。しかもATモード(透過モード)とAPIモードとでは、ファームウエアからして違うので、ATコマンドで簡単にAPIモードになれない。アドレスも自由に設定できないし、この前設定した16ビットアドレスも存在しない。これは前(無印Xbee)のチップと、同じような形、同一無線規格で、同じユーティリティ(X-CTU)を使っていても全く違うディバイスのようだ。

 つまりシリーズ2のZBは、これまでソフトで実現していたネットワーク的な機能、自律的(ソフトの助けなしに)にネットワークを作り、勝手に省電力する機能がファームウエアに実装されている。要するに賢くなっているのだ。

 しかし、こちらとしてはあまり嬉しくない事態である。単純なラジコンにするには返って面倒になった。でも、調べているうち、親機をCoordinator、子機をEnd deviceにし、送信相手アドレス(64ビットで始めから決まっている)を決めうちしてしまえば、前と同じようなユニキャストの1対1の関係で通信が出来そうだ。ほっと胸をなでおろす。

もうひとつの変換基板(3/12/2011)
 先に2ミリピッチの変換基板に汎用基板をくっつけてXbee基板を作ったが、別のやり方でもうひとつ作った。素直に市販のピッチ変換基板を使えばよいものを、私と同じようなことを考える人は他にもいるとみえて、秋月で売っている2ミリ汎用基板を利用して、Xbeeの変換基板を作った人がいた。( ここはXbeeそのものについても詳しい)

P3123732

 以前、Xbeeのような2ミリピッチのパーツを2.54ミリピッチの汎用基板にそのまま固定することを考えたことがある。汎用基板のピッチと2ミリのピン配列をつらつら眺めていて、10ピンを固定するのは、1ミリのドリル穴を余分に2つ開けるだけで、他はすべて穴を少し広げるだけで固定できそうなことに気づいた(汎用ピッチの4つめは、10.16ミリ、2ミリピッチの5つめ10ミリと0.16ミリずれているだけ)。 実際に図面まで引いて、工作を始める直前、もう一方のXbeeのピン列の間隔が、22ミリと、mil規格と大きくずれることに気がつき、作るのを諦めた。

P3123734_2

 今度の方法はこれのバリエーションだ。2.54ミリピッチのL型ヘッダーピンをうまく利用して2ミリピッチ基板にハンダ付けしている。ただ、もう少し綺麗に出来るような気がしてきた。ウェブの工作法では隣接したランドにまずL型ヘッダーピンを固定してから所定のピンに配線しているが、空いたランドは全く利用せず、L型ヘッダーピンをペンチで細かく曲げて直接2ミリピッチに合せれば、もっとすっきり出来そうだ。早速試してみることにする。

P3123735

 意外にうまくいった。小さなブレッドボードにとりつけてみる。半田付けの部分は少ないが、10箇所で固定されたハンダ付けというものは意外に丈夫で、少し動かしたくらいではびくともしない。これをミニブレッドボードに差して子機とし、一方の変換基板は大き目のブレッドボードに使い、Xbee ZBのテスト基盤は整った。これでループバックテストが開始できる。

ループバック成功(3/13/2011)
 ブロードキャストでのループバックテストはとても遅いと聞いていたので、決めうちアドレスの設定をX-CTUでした。前に書いたように、X-CTUで送り先のXbeeのアドレス64ビットをDH(Destination High Address)とDL(Destination Low Address)で設定する。

 ファームウエアタイプは、一方をCoordinator AT、もう一方をEnd device AT(テストなのでATコマンドモードのまま)に設定すれば、一対一になる。

 ループバックテストの開始。よーし、アドレスを指定しないブロードキャストでテストしたときは飛び飛びだった受信が完全にきれいに返ってくる。2階の踊り場まで持っていく。ふむ、急にエラーが起きる。

P3253740

 今度はエラーが出ると立て続けにエラーになり、また突然復帰する。無印(IEEE802.15.2)のときのようなポチポチエラーが出るのと大分様子が違う。スペック上は、無印Xbeeより、XbeeZBの方が少し到達範囲が広いはずなのだが(30m->40m)、送信範囲は前と同じくらいなようだ。

 とりあえずは、これでループバックもOKとなった。透過(ATコマンド)モードでは、前の状態と同じになった。いよいよこれからAPIフレームの送信である。これまでAPIフレームの受信はセンサーデータの受信で経験済みだが、送信、特にコマンド送出は始めてである。ブレッドボードを片付けて、マイコンのスペースを作る。

APIフレームの送信モニターの制作(3/18/2011)
 やりたいことは、APIモード上のリモートATコマンドの送出だけなのだが、丁度良い機会なので、任意のローカルATコマンドや、メッセージなども送れるXbeeのAPIモニターみたいなものを作ろうと思っている。ウェブ上にはArduinoシールドの商用製品があるようだが、自作例が見当たらない。これを完成させてソースでも公開すれば喜ばれるかもしれない。

 ターゲットは、AVR Mega168を選ぶ。このまえのXbeeロガーはSDカードアクセスがあったのでMega128にしたが、今度はこれほどのチップは要らないだろう。それにMega128は旧製品だ(最近はMega1284が後継らしい。秋月でも売っている)。2年前に作ったXbee電力ロガーのソースを引っ張り出して思い出しながらソースを作っていく。

 開発の途中で思い出した。この前はAPIフレームを最初のうち構造体で定義して開発したがどうしてもうまく動かず、あきらめて配列の番号でデータをアクセスした経緯がある。受信データフレームは一種類なので、これでも余り問題はなかったが、今度の送信フレームはローカルとリモートで違うし、コマンド送出と、データ送出でも違う。構造体を使わないと複雑になって後が大変だ。

 この前の構造体での不具合はその後原因がわかっている。APIフレームがアラインメントを無視している(奇数バイトオフセットに2バイトバイナリのデータが定義されているなど)ので、まともに構造体を定義すると、実際のメモリ上の位置と構造体の定義がずれてしまうためである。

 所長はアセンブラー育ちなのでDSECT(ダミーセクション、物差しのようなもの)を使ったアセンブラーの構造体的プログラミングはいやというほどやった(というより、OSはそれの固まり)が、Cの構造体には、余り慣れていない。しかし少し規模の大きいソフトを開発する時は、この考え方は必須である。是非Cでもマスターしておきたい。しかも今度は複数のフォーマットを持つ構造体だ。腕が鳴る。

 前回の失敗を踏まえて構造体の中の変数はすべて1バイト変数にして定義する。リモートとローカルで大きさの違うところは、久しぶりに教則本を勉強して、共用体(union)をstructにいれて定義する。

 さらに、このフレームはチェックサムが必要なので、あらかじめ大きめの配列を定義しておいて、構造体のポインターをこの配列アドレスに指定しようとした。これでこの構造体は、配列番号でもアクセスが出来るはずだ。しかしこれがどうしてもうまくいかない。2重に定義しているとコンパイラーに怒られる。アセンブラー育ちには、このCのポインターのキャストが今ひとつ理解できていない。

 結局、ウェブを調べまわった結果、staticでは、2重に定義することは不可能とわかる。考えてみたら確かに同じ実体メモリに重複した変数を定義されることをコンパイラーが許すわけがない。mallocを使っても良いがそこまでやることもない。強引にunionで、同じstructの上に配列を定義すれば良いが、これも大げさすぎる。というのでポインターの加減算でやることにした。

 これが、最後までたたった。所定のデータが出来てから計算するチェックサムがどうしても正しく入らない。考えあぐねたあげく、アドレスから中味まですべての変数をprintfして始めて原因がわかった。

uint8_t *adr;   //1バイトづつ動かすポインターの定義
APID    api_d;  //構造体の定義

adr = &api_d + 3;    //3バイト先に進んだつもりだが

これは、構造体api_d の長さ分を3つ加えたことになる!! &が付くので、構造体ではなく、単なるアドレスデータになると考えるのが普通だが、Cでは、&がついても構造体の性格がなくならない。正しくは、

adr = (uint8_t *) &api_d;
adr = adr + 3;

でないといけないと書いて、このあと気がついた。これはC言語の仕様で、&演算子と+の演算子の優先順位の勘違いに過ぎないだけのことだ。+の方が、&より優先順位が高いので、

adr = &api_d + 3; は、adr = &(api_d + 3); になるのだ(前も同じことをやったか)。

さっきのように2行にしなくても

adr = (uint8_t *) &(api_d) + 3;

で、警告も出ずに何事もなく動いた。いくらブランクで空けていても思いはコンパイラーには通じない。やれやれC言語も難しいものだ。

気難しいX-CTUをあやしてAPIモードの設定(3/18/2011) 
 ソフトが出来た。次はXbeeをATモード(透過モード)からAPIモードにする手順だ。ところが、X-CTUが気難しくて、簡単にAPIモードのファームが書けない。色々なところでエラーが出て先に進まない。ウェブにも、「根性で」とか「活入れしながら」という言葉が出るほど、動作が不安定である。当研究所のPCのOSは今となっては古いXPだが一番安定していると考えられるOSでもこんな状況である。

 リセットボタンを長めに何回か押すとうまくいったり、そうかと思うと画面上のエラーアイテムをクリックするだけでX-CTUが異常終了したりする。下手をするとOSを再起動しないとX-CTUも動かなくなる。しかも、異常終了したときに設定していたXbeeは大抵動かなくなるので、例のファーム復活の手順を繰り返す羽目におちいる。

 根気良く、何度もXbeeのファームの復活手順をやらされながら、だましだましX-CTUを動かして、何とか2枚のXbeeの設定を終えた。余り自信はないが、ポイントらしいものが見つかったので、以下にまとめておく。

(0)成功を祈って斎戒沐浴する(冗談である)。

(1)設定の終わったXbeeを違うファームウエアにそのまま書き直すのは止めたほうが良い。大抵エラーが起きて先に進めなくなる。なるべくファームウエア復活の手順から始める。このとき、DTR、RTS、CTSはUARTと接続し、垂れ流しのUARTにはしない(無印はそれでも動くがZBは駄目)

(2)復活のときはModem Configurationタブ で、Always update firmwareのチェックを必ず入れること。しかし、復活手順後は必ずはずしておくこと(ここがポイントか)

(3)また、その前のPC Settingsタブで、Enable APIのチェックも外しておくことを忘れずに。なおPCチェックの通信テストで、XbeeZBがXbee24-Bと出るのはバグである。

(4)さらに回線速度は、9600bpsが一番エラーが少ない、というよりこのあとの手順はこの速度でないとエラーが起きる確率が格段に高い。

(5)Modemの欄に「XB24-ZB」(秋月で買ったXBeeなら)を選び、Function SetからXXXXXX APIなどを選んでWriteを押す。このときXbeeの電源は入れてはいけない。

(6)リセットしろという画面が出るが無視して、Xbeeの電源を入れる。するとリセット要求画面は自然に消えて、勝手にファームを書き込み始める。

(7)No Errorで各設定が出てきたら、必ず、Always update firmwareのチェックをはずし、必要なパラメーターを設定し、Writeボタンを押して書き込む。リセットしろという画面が何度か出るので、今度はリセットボタンを押して先に進む。

(8)これでNo Errorで帰って来て、パラメータが表示されたら、おめでとう。Xbeeは成功裡に設定された。そうでないときは難儀である。エラーを修正してwriteし直しても、うまく行くときもあるが、改善されないことが多い。また、エラーが出ていても読んでみると直っているときもある。最初の(2)に戻ってファームを書き直したほうが精神衛生上安心である。

(9)一旦、XbeeがAPIモードになったら、PCセッティングタブで、APIをenableにしないとエラーになる。Modem Configurationタブでのパラメーター読み書きもこれが必要(ただし、ファーム復活の時は入れてはならない。このあたりも注意)。

(10)パラメーターの書き込み(Write)の前に、一度リセットしてから書き込むとエラーが少ない。いずれにしても、PC SettingタブのCOMテストも何回か押して突然動いたり、エラーが出ても繰り返すとOKになるときがあるので、それこそ「根気」と「根性」を要求される。

なんとかAPIフレームでコマンドが送れたが(3/22/2011)
 両方のXbeeをAPIモードのCoordinatorとEnd deviceにして、出来上がったソースでテストを開始する。ISPケーブルを使ったChaNさんのUARTはISPアダプターを有効にしたまま(書き込みモード)でないと動かないことを忘れていて、最初あせった(気持ち良く忘れていた)が、無事、オープニングメッセージが出た。おおお、Xbeeからデータが送られてきたぞ。うーむ、ヘルスチェックのフレームのようだ。受信側はOKなようだ。いよいよコマンドから送信のテストだ。

Xbeeapi

 まず、ローカルコマンドを打つ。よーし、レスポンスが返ってきた。ふむふむ、ちゃんとしたデータが返っている。良いぞ。まだ16進コードの羅列にすぎないが、間違いなくさっき送ったATコマンドのレスポンスだ。

 次はいよいよ問題のリモートコマンドだ。簡単なATコマンドを送る。返事がない。やった、暫くしてコマンドが返ってきた。残念。「送ったが受け取っていない」という親側のメッセージだった。

Ws000000

 アソシエーションLEDの点滅に変化があるので、親から子へコマンドを送っていることは間違いなさそうだが、まだデータフォーマットなどがおかしいのかもしれない。ただ、APIモードでのループバックテストが動かないのが気になっている。

 このあと、X-CTUでリモートコンフィギュレーションが可能になった。Xbeeのハードやファームは問題なく動いているようだ。ローカルのATコマンドの方は、APIモードで殆ど確実に送れるようになった。しかし、リモートコマンドはがんとして送信失敗のエラーコードで先に進まない。メッセージ送信も出来ない。先が長そうなので、とりあえずはこのあたりでブログに報告することにする。

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

2011年3月12日 (土)

メカトロニクスの第一歩、モーター制御に踏み出す

 東北地方に大地震と大津波が襲い、大勢の方が亡くなられた。東京も震度5で、経験したことのない長い揺れに驚いたが、テレビの画面で町を次々に飲み込んでいく黒い津波を見て背筋が凍えた。自然の力の前にいかに人間が無力か思い知らされる。亡くなられた方々のご冥福を心から祈りたい。

 それはそうと、このブログの更新が20日以上滞っている。2月末から3月にかけてのこの時期は、例年、行事や仕事が集中し、電子工作どころではないのだが、このブログは自分の備忘録を兼ねている。あまり日を空けてしまうと、あとから何をやっていたのかわからなくなってしまう。たいしたこともやっていないが、とにかく作業記録だけは残しておくことにする。

次のプロジェクトはモーター制御と決める(2/16/2011)
 FPGAのフォトフレームプロジェクトは一段落した。 I2CフラッシュROMを使ったレジューム機能など、部品を買ったまま、残している課題はまだ山ほどあるが、ここらで少し一休みしよう。次のプロジェクトは、いよいよ年初の挨拶でも触れたモーター制御をやってみたい。これまで電子工作と言われるものは手当たり次第、幅広くやってきたが、モーター制御だけは最後まで残っている。

If1001

 前から興味は持っていて、モーター制御特集の雑誌を買ったりしていたのだが、この世界も奥が深い。そう簡単に手をつけられるところではない。というのも、どうせやるならモーター制御だけではなく、自動制御、ロボットの世界まで行きたいからである。いずれにしろ大電流の制御や、距離センサーなどの技術は、慣れ親しんだソフト開発の世界とは全く違う、所長にとっては一大フロンティアである。

このフロンティアの奥の院には、電子工作の最高峰、メカトロニクス、ロボットが聳えている。これまでFPGAやBealeBoardでは、進めば進むほど、パソコンやiPhoneの世界に近づき、苦心の末、出来上がったものを見せても、「で、それがどうしたの?」と聞かれる危険性を常にはらんでいるが、ここはまだ手付かずの世界が残っている。夢は広がる。

 しかし、現実はそう甘くない。ときどき、これらロボット界の現状をウェブで垣間見るが、見る度に想像を絶する発展がアマチュアの世界でも繰り広げられ、新たにやってみようかという意欲を失わせるのに十分だ。

 信じられない速度でマイクロマウスが迷路の中を駆け巡り、相撲ロボットは、圧倒的な迫力で、相手を土俵の外へはじき飛ばす。ロボットが色の違うボールを器用につかんで、色別に整理し、GPSを搭載して実際の町の中を障害物を避けながら通行する。ここも、素人が気楽に遊べるところが急速に失われつつある。

 まあ、上を見ていたらきりがない。そこまで行かなくても面白いことはたくさんある。しかも、実用をモットーとするがた老AVR研究所としては、実用的な目的は既に考えてある。最初の応用例は、ウェブカメラのアングル制御である。BeagleBoardあたりにウェブカメラを載せ、遠隔地からカメラを自由に操作できるようにすれば、ウェブカメラの能力を飛躍的に広げることが出来る。カメラのアングル、ズームなどがサーボモーターによって制御出来れば、とりあえずの実用性は十分だ。

 次のアプリケーションは、お掃除ロボットだ。小型掃除機を改良し、床の障害物を判別して、それを避けながら定期的に歩き回り、電池が減れば、自分でコンセントにつながりに行って充電する。すでに市販品もあるようだが、これが完成できれば、家族の中でも大威張りだ。夢(妄想)は大きい方が楽しい。

行き当たりばったりに部品を買ってくる(2/18/2011)
 夢はどこまでも膨らむが、ただ考えているだけでは何も始まらない。千里の道も一歩からという。仕事の帰り、久しぶりに秋葉原に寄り、ウェブの情報を頼りに、千石3号館で、タミヤのツインモーターギヤ(ライントレーサー用 ¥710)とタイヤ(¥310)、秋月では、評判の良い在庫限りのFETアレイ(MP4401 ¥200)、ステップモーター(¥350)などを買い込んだ。何でも良いから、とりあえずは何か動くものを作ろうという方針である。

P3103704

 帰ってきてすぐ間違ったものを買ったことに気づく。買って来たFETアレイMP4401は、ステップモーター用のNMOS-FETだけのアレイで、一般のモーター用のドライバーではない。このままではタミヤのモーターは制御できない。モーターの正逆転をするにはHブリッジといってトランジスタで言えば、コンプリメンタリなFETアレイが必要なのだ。

 それに、初心者がいきなりFETドライバーで動かすのは、どうもやめたほうが良さそうだ。FETのON抵抗は、0.1オーム台で、下手な制御をすると、一瞬に大電流が流れ機器を壊してしまう。やはり最初は、バイポーラの定番のトランジスタのモータードライバーを使うのが無難なようだ。

 始めは何故、みんな電圧降下の大きい、こんな非効率なバイポーラのモータードライバーを使うのか理解できなかったが、調べるうちに理由がわかった。こちらの方が少々無理な制御をしても簡単には壊れないから安心なのだ。それに、タミヤのツインギヤセットについているモーターの定格の推奨は、1.5Vなので、3.7Vのリチウムバッテリーを使うのなら電圧降下の具合がちょうど良い。なにも損失の少ないFETドライバーを考える必要がない。

 次の日、家族が日本橋に行きたいと言うので、また秋葉原に寄る。秋月で、定番のモータードライバーTA7291P(2つ入り¥300)と、過電流防止のポリスイッチ(1.5A近辺で3種ほど一ヶ¥30)、千石でHブリッジ用のFETモジュールMP4212(これも在庫限りらしいので今のうち ¥340)を仕入れた。

 ライントレーサーなら、モーターを逆転させる必要はないが、まだアプリケーションを何にするか決めていない。とりあえずは気の付いた部品は揃えて置こうというぐらいの気持ちだ。当初は、ARM基板がついたライントレーサーキットを買おう(¥6000以上する)と思っていたくらいだから、少々余剰部品を沢山買ってもおつりがくる。

 回路を真剣に検討し始める。良く調べてみれば、余り難しく考える必要はなかった。Hブリッジとか言っているが、要するに2極双投のスイッチをFETか、トランジスタが替わりをしているだけと考えれば理解が早い。モーターという誘導負荷を動かすので、逆起電電圧とか、両方の素子が導通しないためのデッドタイムとかに気をつければ、そうびびることはない。でも最初はバイポーラで始めることにする(臆病である)。

FETは、やっぱり1.5Vでは動かない(2/20/2011)
 まずは、ブレッドボードで買ってきたパーツの動作確認テストをする。最初は、間違えて5ヶも買ってしまったMP4401である。生産終了なのに人気が高いと言うので、ついわけもわからず大目に買ってしまっている。一ヶ¥200で、モジュールひとつにN-MOSのパワーFETが4ヶも入っている(ステップモーターも買ってあるので無駄にはなるまい)。オペアンプのように最小動作電圧はデータシートにないが、想定している3V近辺でこのFETは動くのだろうか。

 だめもとで、1.5Vの乾電池ひとつでFETをドライブしてみる。さすがに動く気配はない。3VのDCアダプターで実験する。おおー、動いた動いた。3V近く(2.7V)かかっているので、やたらモーターの勢いが良い。ライントレーサーにするには苦労しそうな速さだ。

 結局、安全のため買ってあったバイポーラトランジスタのモータードライバーTA7291Pが思った通りちょうど良い早さになった。(1.4V。1.6Vも電圧降下があることになる非能率)。電池を積んで動かすことを考えれば、慣れてきた時はFETに換えるべきだろう。

 TA7291Pは、単なるトランジスタアレイではなく、ロジックが内蔵されたICで、アナログ電圧(Vref)でモーターの出力電圧を変えられる。半固定抵抗でやってみる。ブレッドボードで組んで、モーターを動かしてみた。電源は車に積めるよう、プレーヤーに使った3.7Vのリチウムバッテリーである。

 うむ、面白い。ちゃんと微速から全速まで無段階で変えられる。ここにPWMでチョッパーした出力をLPFでならせばアクセルが出来るはずだ。石はとりあえず、2313で十分だろう。ライントレーサーの前に、Xbeeか何かでラジコンのテストもしてみたくなってきた。秋月でもXbeeを売り出したことだし。

自走車の制作(2/22/2011)

P2263693

 車(自走車)のシャーシーを適当な汎用基板で作り出したら止まらなくなった。あちこちのウェブを参考に、それらしい形を作る。モーター制御の部分は、このシャーシーには作りこまず、FETとバイポーラの2つにわけてテストできるようにモーター制御のサブ基板を作る。

 これを組み立ててみたらなんとなく自動車らしくなり昔を思い出してはまる。ただ工作の進捗が遅い。これは、この車体をラジコンカーにするのか、ライントレーサーにするのか、それともマイクロマウスのような自走ロボットにするのか方針が決まっていないからだ。

 本来は、何を作るか最初に決めて、まず設計図を引き、次に部品を揃え、それから作らないと、良いものは出来ないのだが、こういう気ままな作り方も、「ゆるくて」面白い。まあ、モーター制御の最初の練習車だ。気楽に考えよう。

 モーター2つで自由に方向を変えるため、もう一つの車輪は、カートのキャスターみたいのもので良いと思って調べてみたら、おあつらえのように、同じタミヤから「ボールキャスター」というのが売られていた(最初は自作しようと意気込んでいた)。ウェブを良く見たら、この部品を使っているサイトはやたらに多いことに気づいた。

 このキャスターは¥400しない。しかしこれだけを買いに都心に出かけるのも何だかなあと思っていたら、最近のアマゾンは、自社直接の注文では、どんな安い商品でも送料を無料にしているのを発見した。早速、ネットで注文した。2日で届いた。

P3103717

 ライントレーサーにするか、ラジコン車にするか、まだ方針が決まらない。マイクロマウスは、その場で回転(両側の車輪を逆にまわす)できるように、大輪の車輪にステップモーターで駆動するのが定番のようで、この形のマイクロマウスはあきらめる。

 とりあえずは、ライントレーサーにしようと、フォトセンサーのひとつ、フォトリフレクター(TPR-105F ¥50)を久しぶりに動かしてみた。このセンサーはライントレーサーを考えていて、たまたま、これを脈拍計にしようとしているサイトを見つけ、面白そうなので衝動買いしたセンサーである。実験をした後ブレッドボードにささったままになっている。

 この実験をブログに載せたら、意外なことにいくつかのサイトで紹介され、ブログのアクセス急増に寄与したことがあるが、脈拍計としては、指の置く位置が微妙で、思うように脈拍がとれず、ちょっとテストしたままそれきりになっている。

 本来のライントレーサーのテストのため、紙にマジックで黒線を入れリフレクターの上をずらせて変化を見る。しかし、どういうわけか思ったように動かない。かなり紙を密着させないと白黒の判定が明確に出ない。ウェブの記事を見ているとライントレーサーは、このセンサーでなく、秋月でのもうひとつの種類、LBR127HLD(TPR-105より少し大きく、フォトTRとLEDが外せる ¥60)を使っていることが多い。

 うーむ、ライントレーサーも今のところ手持ちの部品では実験が進められない(折角あれから3つも買ったのに)。というと残るは、無線操縦くらいか。そういえば、このあいだhamayanさんのブログで、受信側をXbeeモジュールだけで動かすリモコンの実験が載っていた。これはまさしく当所長があたためてきたアイデアである。

 久しぶりに、Xbeeをもう一度調べ始めた。当ブログの最近のアクセスのトップはXbee関連である。何かの縁を感じる。Xbeeは、UARTの通信機能やネットワーク機能以外に、チップにデジタルI/Oピンを8ヶ内蔵している。しかし、これまでこれをラジコンに使っている例はない。みんな慣れたUARTを通してコマンド受信し、受信側にマイコンを置いてモーターを制御している。XbeeモジュールのI/Oピンだけでモーターを制御できればマイコンなしで動かせる。これは少し面白くなってきた。

P3103712

APIモードのXbeeだけでラジコンにする?(2/27/2011)
 確定申告や、恒例の年度末の全国大会の準備など、そろそろ行事が集中してきて、電子工作に時間をかけられない時期がきた。それでも、暇を見ては、自走車(今はこう呼ぶしかない)の工作を続けている。

 とりあえずはバイポーラのモータードライバーTA7291Pで、自走するところまで作ってみた。速度制御は、このドライバーはアナログでできるが、正逆進の切り替えは、2本の制御線の操作がそれぞれ必要である。とりあえず組み立て、少し長いコードをつけて動作テストする。小さなブレッドボードとリチウム電池フォルダー(Xbeeワイヤレス電力センサー子機から流用)を載せた車がビービー動く。下らないけれど楽しい。

P2263689

 勢いに乗って、モーター2つから出てくる4本の制御線を統合して、前進と後進が一挙動で出来るように、トランジスター1ヶをインバーターにして、1本のHLで動くようにする。ブレッドボードで、回路を組む。オシロを使って、2本の制御線が同時にプラスにならないよう、100pFのコンデンサーをかまして遅延させる。

 よし、立ち上がりは、遅延回路のおかげでトランジスタがONになるまで持ちこたえ、OFFのときは、トランジスタの立ち上がりの遅さが効いて、制御線が両方プラスになることが避けられる。モーターは思ったように、正転と逆転を繰り返す。こんな簡単な回路だけれど、思うように動いた時の快感は、複雑なものを完成させたときと同じだ。

 Xbeeのほうである。ラジコンにすると言っても、XbeeのPWMは、出力だけで入力は出来ない。細かい速度調整などには、PWM制御できるマイコンが必要だが、正進、逆進、停止、左右転回程度のラジコン操作ならXbeeのデジタルピンだけで動くはずだ。

 hamayanさんのブログをもういちど仔細に調べてみた。Arduinoを使って、APIフレームを飛ばして、子機側のI/Oを操作している。APIフレームでリモートATコマンドを出せば、子機側のXbeeのI/Oを直接動かせるので、ラジコンが出来る理屈だ。ただ、PWMのような早い切り替えは出来ないだろう。

買ってきたXbeeが二つとも動かなくなる(3/6/2011)
 秋月でもXbeeを売り出している。シリーズ2のXbee ZBが¥2400、Xbee ZB Proが¥3800とやはりどこよりも安い。ちょうど良い機会だ。仕事の出張が終わって一段落したので、帰りにラジコン用に2つ買ってきた。

 ついでに2ミリメッシュの汎用基板を買って、Xbee基板を作り始める。Xbee用の変換基板はいくつかのショップで売っているが、この汎用基板はたったの¥80。変換基板は安いのでも¥315(ストロベリーリナックス)、¥500(スイッチサイエンス)する。根がケチというのか、へそ曲がりというのか、素直に変換基板を買ってくれば良いものを、何か違うことをやりたがる。2ミリピッチの基板を2つに切り、汎用ピッチのピンヘッダーをつけた基板の小片をネジ止めして自前のブレッドボード用の変換基板を作る。簡単に出来た。

P3123726

 例によって、XbeeのユーティリティX-CTUでパラメーターの設定に入った。あれえ、Xbee ZBは、前の無印Xbeeと違って、MY ADDRESSが設定できない。どうしてだろう。と、色々いじっているうち、X-CTUがおかしくなってファームアップデートが終わらなくなった。仕方なく強制終了させたところ、Xbeeそのものが動かなくなってしまった。例の、ファームウエアリカバリーでも駄目。何度やっても元へ戻らない。

 そのうち、動いていたもうひとつのXbeeチップも、X-CTUの異常終了(こいつときどきこける)とともに同じような状態になる。買って間もないチップ2つが全部動かなくなった。大事件である。Xbeeラジコンどころではない。

DigiからのメールでXbee生き返る(3/9/2011)
 思い余って、販売元の日本のDigi Internationalにメールする。余り期待していなかったが、一日もしないうちに返事が来た。しかし、教えてくれたのは、前にやって動かなかった手順である。さらにしつこく情報提供を要請する。無視されると思ったが誠実に回答が来た。好感が持てる。

 なになに、DTRとRTSをつなげとある。DTRはつないであったが、RTSはCTSとジャンパーしてさぼっている。今までのXbeeはこれでも、問題なくリカバリーできていた。しかしhamayanさんのブログでも、ファームの書き込みは、DTRなどの制御線が必要とある。

 そういえば、RTSはUARTのところでジャンパーさせてXbeeには届いていない。XbeeがRTSを聞いているのならつなぐ必要がある。制御線を追加する。

 念のため、CTSとRTSのジャンパーもはずしてCTSをXbeeから送るようにする。あきるほどやったリカバリー手順を、また最初からやりなおし。おおお、何か違うぞ。オシロに受信のパルスが流れる。やった、やった。メッセージがOKになった。2つとも生きかえった。

 いやあ、人の言うことは聞くものだ。こんなにきめ細かく制御していたとは。Xbeeシリーズ2はやはり、大分、無印Xbeeとは様子が違う。

 何とか、Xbee2つを救ったところで一段落し、このあたりでブログに報告することにする。実は、このあと思ってもいない展開になったのだが、それは次回と言うことで。

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

« 2011年2月 | トップページ | 2011年4月 »