AR.Drone BLC プロトコル

空飛ぶおもちゃAR.Droneですが、それをiPhoneなどではなくラジコンとしてプロポで操縦すべく、いろいろといじっています。そのためにモータの回転数を制御しているBLC(Brushless Controller)と、中央基板(マザーボード/ナビゲーションボード)の間でどのような通信が行われているのか知る必要があったのですが、ようやくその内容を理解することができたのでここに記録を残しておきたいと思います。
なお今回は通信方式(プロトコル)そのものに着目しますので、ハードウェア上、どのような接続になっているかは以前の記事『AR.Drone モータまわり』および『AR.Drone BLCとのI/Fで悩む』をご覧ください。
またプロトコルを調査するにあたっては、シリアルポートの送受信を監視するプログラムであるinterceptty、および実機にオシロをつないで信号を見る、ソフトウェアとハードウェアの両面から進めました。

以下、AR.Droneの電源投入時、および飛行直前、そして飛行中という3つの時系列にわけて調査結果を示しますが、下図のように大きく分けて2つの操作があります。

BLCはプロペラの個数分、つまり全部で4個ありますが、ここでBLCごとに行う操作(unicast)と、全てのBLCに対して一斉に送信される操作(broadcast)の2つの操作があります。以下、この2つを区別しつつ説明をしておこうと思いますが、ハードウェア的には1つのシリアルポートで事足ります。
というのもハードウェアに関して記した『AR.Drone BLCとのI/Fで悩む』にあるとおり、中央からBLCへの送信操作は、1つのシリアルポートの送信チャネルをマルチプレクスして行えばよいと思います。操作によっては逆にBLCから中央へ返答をしてくるものがあるのですが、その受信処理については全てのBLCからの信号線についてANDをとって受信すれば、1つのシリアルポートで可能(無通信時HなのでLを検出すれば十分)です。

電源投入時は以下の操作が行われています。なおこのときは全てunicast、つまり各BLCごとに順に行われます。

BLCから中央への返答については緑色の # =>で示してあります。各操作の推測した意味もあわせて示してありますが、ここで一番重要なのが0x01を送信している部分で、各BLCに通し番号を割り振っていると思われる部分です。ここが2番目のBLCでは0x02に、3番目のBLCでは0x03、最後のBLCでは0x04に変化していました。
また0x91で返却される結果ですが、これでBLC内のファームウェアを確認しているものと思われます。BLCのソフトウェアリビジョンが違うもので試したところ、違う結果が返却されてきました。ここから推測するに、BLCのファームウェアは中央から書き換え可能だと思われます。それを補強する事実として、AR.Droneにtelnetでアクセスしてみると /firmware/BLC.hex.backup というファイルがあります。

飛行開始前には次の操作が行われます。これも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から変化し、プロトコルが変更される可能性があると思います。

※とうとうプロポで操縦できました。

09:17 fenrir が投稿 : 固定リンク | | | コメント (0) | トラックバック
このエントリーのトラックバックURL: https://fenrir.naruoka.org/mt/mt-tb.cgi/795

Super Sylphide 進捗状況(39) -- XDS100 による Tiny Feather のデバック

無人航空機(UAV)用のオートパイロットシステムSuper Sylphideですが、その続編Tiny Featherの開発を続けています。両者とも最も重い計算をさせる半導体はどちらもTIのC67xシリーズDSP、すなわちSuper SylphideはTMS320C6713B、Tiny FeatherはTMS320C6745Bを使っているため、開発環境としては同じ環境を使うことができます。開発環境はハードウェア(エミュレータ)とソフトウェア(Code Composer Studio、以下CCS)で構成されますが、Tiny Featherは後発であるがゆえ、それらのうちハードウェアについて100ドル未満の安価なものを使えるようになっています。それが表題のXDS100クラスエミュレータというものです。

XDS100クラスエミュレータは、それ自体は製品の名前ではなく、『クラス』と名前がついていることからも想像できるように一連の製品群のことをさしています。というのもXDS100というのがTIが供給している純製品の名前で、TI以外の他社からも互換品が販売されているという次第です。

ところでこのXDS100クラスエミュレータ、機能によってバージョンが2タイプあります。XDS100とXDS100v2というもので、v2のほうが高機能、ただしCCSのバージョンに依存性があってv2ではCCSの新しいバージョンである4.xのみ対応で、古い3.3では使えません。ソフトによって対応するハードを変えなければならないのは、いささか不便です。ましてや1ユーザとして僕が見るところ、CCSは開発環境としての安定性がいまいちで、新しい4.xのCCSが必ずしも古い3.3よりも優れているとはいい難いと考えています。というわけで、CCSは3.3と4.xを両方とも使いたいという要求があり、XDS100とXDS100v2の両方が手元にほしくなりました。

しかしいくら安いとはいえ、似たエミュレータを2個購入するのには気が引けます。そこでよくよく探してみると、中身をソフト的に書き換えることによってXDS100にもXDS100v2にもなる互換品を発見しました。Blackhawk XDS100v2D というのがその互換品で、どうやら搭載されたCPLDを書き換えることによってこの機能を実現しているようです。

早速、MouserにてXDS100v2Dを購入し使ってみましたが、うまくTiny Featherをデバックすることができました。接続している様子を示します。

CCS3.3で接続している様子

XDS100クラスのエミュレータは、上位機種でより高価なXDS510、XDS560クラスと比べるとコードのダウンロードスピードが遅かったり、と安いなりの欠点がありますが、十分に使える治具だと思います。これでDSPユーザが増えてくれると面白いのですが、Cortex-M4に期待している僕もいます。

※次の進捗状況では、Tiny Featherの設計データを公開しています。

06:53 fenrir が投稿 : 固定リンク | | | コメント (0) | トラックバック
このエントリーのトラックバックURL: https://fenrir.naruoka.org/mt/mt-tb.cgi/796

Super Sylphide 進捗状況(40) -- Tiny Featherの回路図、アートワーク

無人航空機(UAV)用のオートパイロットシステムSuper Sylphideの小型改良版Tiny Featherですが、基本的な機能の確認がほぼ終わりました。例えばDSPで計算をまわす、MicroSD上のファイルを読み書きする、サーボが動く、ラジコン受信機から指令値であるパルス幅を読み取る、オートパイロットを手動で強制的に切断する、といったことが可能になりました。

ということで、まだまだ改良する部分があるものの、基板や部品といったハードの部分はほぼ固まったかな、という印象を得ています。ということで、これらの設計データを公開することにしました。tf_r5884.zipというファイルにまとめてあります。公開しているのはEagleの回路図とアートワークで、DSP基板とセンサ+サーボI/F基板にわかれています。

Eagleで4層の基板を設計してみたい方など、参考になれば幸いです。

※続いてCPLDの中身を公開しました。

19:54 fenrir が投稿 : 固定リンク | | | コメント (0) | トラックバック
このエントリーのトラックバックURL: https://fenrir.naruoka.org/mt/mt-tb.cgi/797

AR.Drone プロポで手動操縦

iPhoneなど操縦できる空飛ぶおもちゃ AR.Drone ですが、『iPhoneで操縦できるラジコンが許されるのは小学生までだよねー』という声が天から聞こえたような気がしたので、純粋にラジコンとして楽しめるように検討を重ねてきました。この中でモータを制御しているBLC(Brushless Controller)の配線状況やプロトコルを把握できたことにより、ラジコンの一般的な方法であるプロポでの操縦ができそうな状況までもっていくことができました。

そしてこの度、プロポでAR.Droneを操縦することができました。『AR.Drone用何か Rev.B』基板を使っています。ソースコードはこのあたりにあります。

仕様機材: 緑の基板は自作。

ちょっとガッカリな動画かもしれませんが、スロットルで全体のペラの回転数を制御しているのが確認いただけると思います。動画にはありませんが、機能的には他の三舵(エルロン、エレベータ、ラダー)も操縦に加えてあり、それぞれ4つのモータの回転数に差をつけるよう働かせることで、ロール、ピッチ、ヨーの動きがでるようにしてあります。

次は広いところで実験をしてみたいのですが、おそらくプロポからの操縦だけでは安定して飛ぶことはできないと思います。ラジコン用のジャイロをいれてピッチやロールがふらふらしないように制御する必要がありそうです。

06:38 fenrir が投稿 : 固定リンク | | | コメント (6) | トラックバック
このエントリーのトラックバックURL: https://fenrir.naruoka.org/mt/mt-tb.cgi/798