April 03, 2011AR.Drone BLC プロトコル空飛ぶおもちゃAR.Droneですが、それをiPhoneなどではなくラジコンとしてプロポで操縦すべく、いろいろといじっています。そのためにモータの回転数を制御しているBLC(Brushless Controller)と、中央基板(マザーボード/ナビゲーションボード)の間でどのような通信が行われているのか知る必要があったのですが、ようやくその内容を理解することができたのでここに記録を残しておきたいと思います。 以下、AR.Droneの電源投入時、および飛行直前、そして飛行中という3つの時系列にわけて調査結果を示しますが、下図のように大きく分けて2つの操作があります。 BLCはプロペラの個数分、つまり全部で4個ありますが、ここでBLCごとに行う操作(unicast)と、全てのBLCに対して一斉に送信される操作(broadcast)の2つの操作があります。以下、この2つを区別しつつ説明をしておこうと思いますが、ハードウェア的には1つのシリアルポートで事足ります。 電源投入時は以下の操作が行われています。なおこのときは全てunicast、つまり各BLCごとに順に行われます。 BLCから中央への返答については緑色の # =>で示してあります。各操作の推測した意味もあわせて示してありますが、ここで一番重要なのが0x01を送信している部分で、各BLCに通し番号を割り振っていると思われる部分です。ここが2番目のBLCでは0x02に、3番目のBLCでは0x03、最後のBLCでは0x04に変化していました。 飛行開始前には次の操作が行われます。これもunicastで、起動時と同じ順でBLC毎に操作を行い、2番目の0x01操作についてはBLC毎にインクリメントする必要があるようです。 また補足ですが、以上のunicast操作が各BLC毎に行われた後、0xA0が6回、broadcastで配信されていました。これは飛行中に入る前の同期用の操作で特に意味はないと思います。 そして飛行中ですが、これは全て4つのBLCに一斉に行うbroadcastタイプの操作です。例えば以下のような操作が行われています。 ここで一番重要なのが、頻出している0x2Xで始まる5bytesの操作です。この操作は各BLCの回転速度を調整する操作のようです。この操作について各ビットを変化させてモータの動きを見たところ、以下のような構成になっていることが更にわかりました。 各BLC(番号は電源投入時に割り振った通し番号と同じ)が9bitsで制御されているようです。ということは解像度512ですね。この操作は5msごと、つまり200Hzで行われていました。 また0x89で始まる1byteの操作ですが、この操作がないとBLCが緊急停止をしてしまいます。おそらくBLCの生存確認を行っているのだと思います。0x89以外にも0x8A,0x8B,0x8Cという操作も継続的にされていることから、0x89はBLCの1番に対する生存確認なのでしょう。さらに、まだ調査をしていないのですが、0x60はLEDに関する操作ではないかと思います。 ここまでの内容でAR.Droneのモータを本来のマザーボードなしで動かすことができます。プロポへの直接対応も間近になったと思います。また別のプランとして、中央のマザーボードはそのまま生かし、BLCを市販のラジコンのスピコンに変えるといった芸当もできると思います。これによってAR.Droneのペイロード重量が増やせるかもしれません。 最後にですが、調査を行ったAR.DroneにつなげていたのはiPodで、そのソフトウェアバージョンは1.7.1でした。このバージョンが変わるとBLC側のファームウェアも1.15から変化し、プロトコルが変更される可能性があると思います。 ※とうとうプロポで操縦できました。 おまけですが、オシロで停止時と回転時の波形をとってみました。 オシロで波形を見るといった物理的な方法が解析の初期にはとても役に立ちました。 コメント
コメントする
|
スポンサード リンク
|