March 02, 2013

Super Sylphide 進捗状況(59) -- TinyFeather データフロー図

オートパイロットシステムTinyFeatherですが、データの流れが複雑化しつつあるので、そのまとめの図を作ってみることにしました。簡潔にまとめようと努力した結果、カラフルになってしまいました(笑)。以下、説明と共に図を示したいと思います。

まずは航法装置としての部分。

tinyfeather_data_flow_data_matrix.png

加速度計とジャイロを合わせた慣性センサ(IMU Sensors)、およびGPS受信機、 地磁気センサから、Data Matrixを経由してNavigationにデータが流れます。NavigationからはINS/GPS航法の演算結果が出力されます。図の全体的な説明になりますが、Data matrixおよびNavigationは対応するDSPのコードで、その他Guidance ControlというDSPコードがあります。その他の丸で囲まれたユニットは、Maeve(地上局ソフト)を除いて、TinyFeather内に搭載または接続された機器を表しています。

次は誘導制御の部分です。

tinyfeather_data_flow_guidance_control.png

Guidance Controlにて誘導制御が行われ、その結果がServo PWMに反映されます。計算にあたっては、航法情報に加え、地上から送信されたウェイポイントなどのXBeeからの情報、加速度ジャイロの生センサ情報、対気速度当のADS(Air data sensor)情報が入力として用いられます。さらにR/Cの受信機からPWM信号を取り込む機能もTinyFeatherあるので、赤色の千で示されるPWM Servoユニットとの通信は、出力だけでなく入力方向もあります。機体に合わせたオートパイロットを実装するには、Guidance Controlのコードを変更するだけです。

ログ機能です。SDカードへの記録となります。

tinyfeather_data_flow_sd.png

様々な情報をSDに流しています。この際情報は、Sylphide (ログ)データ形式に準じた形でSDカードへ書き込まれます。SDにはファーム書き換えや設定読み込みなど、システム全体への入力となる機能もありますが、この図では省略しました。

デバックのために、USBへも全ての情報を出力しています。

tinyfeather_data_flow_usb.png

USBへ情報を書き出す際は、頭だしやチェックサムの機能を備えるSylphide通信プロトコルに準拠した形で送信されます。Sylphide通信プロトコルは、(ログ)データをヘッダやフッタで包んだパケット形式になっていますので、上述のSDの図に示したものを斜線で包んで図示しています。

最後となりますが、通信用のXBee(等)です。

tinyfeather_data_flow_xbee.png

XBeeにも様々なデータを書き出していますが、通信速度がSDやUSBに比べて遥かに遅いので、データの更新頻度を落とした形で流し込んでいます。USBと同様、Sylphide通信プロトコルに準拠したデータ形式です。

イラストレータを触って図を描きました。時間はかかりましたが、楽しかったです。

データの流れがこの他にもあることを次の進捗記事で書きました。

23:59 fenrir が投稿 : 固定リンク | | このエントリーを含むはてなブックマーク | コメント (0) | トラックバック
このエントリーのトラックバックURL: https://fenrir.naruoka.org/mt/mt-tb.cgi/875

March 09, 2013

Super Sylphide 進捗状況(60) -- TinyFeather USB Bridge

オートパイロットシステムTinyFeatherですが、前回の進捗記事で取り扱ったデータの流れに加えて、USBシリアルを他のUART機器に送受信直接つなげるというデバック機能『USB Bridge』のデータの流れがあります。設定ファイルを書き込んだSDカードを挿入した状態で起動することで、このデバック機能が有効になります。現在のところGPSとXBeeにつながるようになっています。流れ図で書くと以下のとおりです。

tinyfeather_usb_bridge_gps.png
GPSと直接

tinyfeather_usb_bridge_xbee.png
XBeeと直接

いずれの場合もdata_matrixは経由せずに、別のコード(kernel内)が中継をしています。

このUSB Bridge機能があると、GPSやXBeeの単体テストが大変しやすくなります。特に以下2つの点が使い勝手として大変良くなります。
1つ、GPSについては、GPS自身のファームウェアの書き換えが発生することがあるのですが、基板上に半田付けされたGPSモジュールに書き換えのためだけのジャンパ配線をわざわざする必要がなくなります。
2つ、XBeeなどの無線機器は事前に通信可能距離の確認を行う必要があるのですが、わざわざXBeeをUSBに変換する機器を用意する必要がなくなります。

将来的にはUSB Bridge機能を拡張して、TinyFeatherにシェルコンソールを用意しようと考えています。そうするとPCとTinyFeatherの協調動作がしやすくなるのではと考えています。

※シェルを作るどころか、mrubyが動作するようになりました。

23:59 fenrir が投稿 : 固定リンク | | このエントリーを含むはてなブックマーク | コメント (0) | トラックバック
このエントリーのトラックバックURL: https://fenrir.naruoka.org/mt/mt-tb.cgi/876

March 16, 2013

NV08C-MCM Storegis(8.0.1.0)の不思議

NVS社のマルチGNSSモジュールNV08C-MCMの評価を行っています。自分で設計した基板が間に合えば良かったのですが、現在は@HirakuTOIDA 氏のXBee型モジュール(ファームは現在最新のパッチバージョンv02.05)を借用して評価を進めています。その評価中に、NVS社の純正ビューワソフトStoregis(バージョン 8.0.1.0)を使っていて、2つほど不思議なことが起きましたので、備忘録を残しておこうと思います。

まず1つですが、StoregisをBINRプロトコル、RAWモードで運用した場合(下のスクリーンショット参考)です。

storegis_raw.png

このときシリアルでは以下のデータがNV08C-MCMに送られていました。パケット単位で記述してみます。

送信データ(16進)説明
0x10,0x0B,0x00,0x00,0xC2,0x01,
0x00,0x04,0x10,0x03,
Port setting(115200,BINR)
0x10,0x1B,0x10,0x03,Software version
0x10,0x0E,0x10,0x03,Cancellation of all transmission requests
0x10,0x1B,0x10,0x03,Software version
0x10,0xA0,0x03,0x01,0x10,0x03,Request for group delay
0x10,0xA0,0x03,0x04,0x10,0x03,Request for group delay
0x10,0xA0,0x03,0x02,0x10,0x03,Request for group delay
0x10,0xA0,0x03,0x05,0x10,0x03,Request for group delay
0x10,0xA0,0x03,0x03,0x10,0x03,Request for group delay
0x10,0xA0,0x03,0x06,0x10,0x03,Request for group delay
0x10,0x0C,0x01,0x10,0x03,Start debug information?
0x10,0x21,0x01,0x10,0x03,Request for the number of satellites used and DOP
0x10,0x27,0x01,0x10,0x03,Request for PVT vector
0x10,0x35,0x01,0x10,0x03,Request for information about used and blocked satellites
0x10,0x24,0x01,0x10,0x03,Request for visible satellites

印をつけた0x10,0x0cで始まるパケットがデータシートにはなく、何をしているのか、よくわかりません。さらに0x10,0x0cのバケットが送られると、即時に0x10,0x02ではじまるレスポンスパケットを大量に、連続的に受信することになるのですが、0x10,0x02のパケットについてもデータシートにはなく、何等かのデバック情報ではないか、という結論にいたりました。なお0x10,0x0c,0x00,0x10,0x03を送ることで、0x10,0x02ではじまるパケットは止めることができることを確認しました。これが不思議その1です。

もう1つの不思議ですが、BINRプロトコルでサポートされているチェックサムを各パケットにつける方法でデータを取得し、それをstoregisに読み込ませてみたところ、エラーが頻出しました。チェックサム付加は0x10,0xB2,0x06,0x00,0x10,0x03をモジュールに送信して設定しています。検証した結果、取得したデータから各パケットのチェックサムの部分(0x10,0xFF,CS1,CS2)を除去したうえでStoregisに読み込ませると、正常に動作をします。ここから想像するに、Storegisはチェックサムが付加されていることを前提としていないようです。

いずれも仕様がらみの話ですが、データシートにもところどころ明らかな間違いがありましたし、しばらくすれば以上の不思議点も解消するのではないか、と期待しています。

23:59 fenrir が投稿 : 固定リンク | | このエントリーを含むはてなブックマーク | コメント (0) | トラックバック
このエントリーのトラックバックURL: https://fenrir.naruoka.org/mt/mt-tb.cgi/877

March 30, 2013

BGAのリボール

最近は簡単に半田付けできないタイプの半導体を扱うことが多く、半田付けに失敗することがそれなりにあります。特にBGAパッケージはとても嫌いなパッケージです。そこで失敗してもやり直しがきくよう、BGAの裏の半田ボールを再生するリボールの環境を整え、リボールをやってみました。

用意したのは、ホットエアー(FR-803)が大物で、その他にリボール用の専用台、ステンシル、半田ボール、フラックスです。大物以外はすべてebayで購入し、全部合わせても30ドル程度でした。

以下、写真で紹介します。

reball_stage.jpg

リボール用の専用台は、上下に分かれていて、BGAパッケージを下側にセットした後、ステンシルがはめ込まれた上側で挟み込みます。(ステンシルの四隅が汚れているのは違う目的で使ったためです、新品では当然汚れていませんでした。)

reball_before.jpg

リボール台にフラックスを塗ったBGAパッケージ、ステンシルをセットし、その上に半田ボールを置きます。このとき半田ボールは多少位置がずれていても大丈夫です。ステンシルを写真のような汎用でなく、パッケージにあった専用のものを使えば、半田ボールは刷毛で流し込むことができ作業効率を上げられると思います。汎用のステンシルでもマスキングをすれば刷毛で流し込みができますが、 今回はピンセットでおいてみました。

あとはホットエアーで加熱をすると、半田ボールがセルフアライメントして綺麗に整列してくれます。

reball_after.jpg

コツとしてはフラックスをちゃんと塗ることだと思いました。またいくつか半田ボールがかけた場合は、ステンシルを使わずとも、直接フラックスの粘着力に頼ることで、リボール作業を行うことができたのは発見でした。

23:59 fenrir が投稿 : 固定リンク | | このエントリーを含むはてなブックマーク | コメント (3) | トラックバック
このエントリーのトラックバックURL: https://fenrir.naruoka.org/mt/mt-tb.cgi/878