February 12, 2009
Super Sylphide 進捗状況(23) -- 下位プロトコルの策定
オートパイロットシステム Super Sylphideですが、地上側のソフトウェアが整備されつつあり、通信環境に関する作業を中心に行っています。そこで問題となったのが、通信プロトコルや通信回線の太さといった極めて泥臭い話、すなわち試行錯誤が要求される部分を決定しなければならないということでした。今回のその試行錯誤の一端として、決定した下位レベルのプロトコルの話を紹介したいと思います。
現在Super Sylphideのログデータは32bytesの固定長で一つの意味単位(仮にページと呼ぶことにします)を形成しています。その32bytesの先頭バイトがそのページの性格を示しており、例えば'A'ならばセンサのA/D変換結果、'G'ならばGPSからの情報が中には入っているよ、ということを示す仕様にしてありました。
余談になりますが、この32bytes固定長がどこから生まれたのかというと、SDカードのセクタ単位(512bytes)の公約数に由来しています。SDカードはセクタ単位で読み書きを行うこと、また32bytesという長さがだいたいの情報を記録しやすい、さらには内部メモリが少ないマイコンのスタック(多くは256bytes)にも収まるという優れた特長を持っています。
SDカードに記録されたログデータを解析する分には頭出し、つまりどこからページがはじまるかわかっており、なおかつデータの完全性も保障されているのでパースが簡単です。しかしこの32bytes固定長仕様のログデータを、リアルタイムに通信でやり取りしようとすると、どこが先頭なのか認識できない、ましてや途中でデータが途切れるおそれがあります。そこでこのデータを包み、頭出しとデータの完全性を確認する機能を追加する下位プロトコルを策定することになりました。色々と検討した結果、以下の図のような仕様としました。
ヘッダ(12bits、0xF7E)は頭出しを簡単に行えるようにするためのもので、いままでのログデータから最も出現頻度が低い組み合わせを選びました。ヘッダに続く4bitsはこの意味単位の性格づけ(要返答など)をするために予約としました。続く2bytesはシーケンス番号で、トランザクションを構成する際に利用します。その後には32bytes固定長ページが続き、最後に付加したCRC-16によってデータの破損がないか検出できるようにしました。データの破損は付加されているCRC-16と受信側で新たに計算したCRC-16を比較し、不一致の場合はデータが破損していると判断、次のヘッダがでてくるまで受信結果を破棄するようにしました。
この下位プロトコルを用いた通信の実験をSuper SylphideをUSBでパソコンに接続し行った結果、良好に動作していることを確認しました。データの破損検出については、通信に使うエンドポイント以外をbulk転送で埋めると、転送速度が落ちデータの歯抜けがおきることを利用して確認しました。通信回線を無線のXBeeに置き換えた場合どうなるかが、最大の山場です。近いうちに実験をしてみたいと考えています。
※DSPの開発が一段落したので、DSPの開発遍歴についてまとめました。
高速ディジタル伝送では、最下位層のパケットヘッダに単純なパターンの繰り返しからなるプリアンブルを付加します。こうすると、簡単なステートマシンでヘッダの到来を検地できます。もちろんプリアンブルのパターンはヘッダおよびボディ中に現れないようにするのが理想です。
プリアンブルの検出だけに頼ると、ロストするたびに検出に時間がかかりますが、パケット送信間隔を固定にすることでいったんロストした後も速やかに同期を回復できます。「この時間にヘッダーが到着するはず」とあらかじめ分かっているからです。
「走行中のラジコンカーの、エンジン温度等をモニタしたい」と思い立ち、某ストロベーリさんの500円AMモジュールを使った簡易テレメトリのようなものを開発しています。
が、猛スピードで走り回るラジコンからの送信では条件が厳しいのか、データは途切れるのが当たり前、といった感じです。送信側のマイコンは8ピンPICとあって、あまり複雑なプロトコルが載せられない中、エラー排除vs転送レートの落とし所を探っている段階です。
酔漢さんの仰るヘッダーの推定は全く考慮していませんでした。タイムリーにヒントを頂けた事に感謝です。ありがとうございました。
このシステム、机上では問題なく通信できてしまうので困っています。解決策は部屋でラジコンを走らせるか、サーキットでコーディングするか、でしょうか。
Posted by: kanki : February 14, 2009 02:03 AMfenrirです。
>酔漢さん
仕様をきめるにあたって、データリンク層のプロトコル(PPPとかEtherとか)を参考にしようかとも思いましたが、教えていただいた方法はそれに近いものを感じます。今回は転送効率をあげる(9600bps程度の細い回線にも適用可能なことを考えています)、また回線ではバイト単位の転送が保証されている(に違いない、笑)という想定があったので、このような仕様にしてみました。
>kankiさん
はじめまして。無線は鬼門ですよね。特にアナログの無線だと、色々と周辺環境に依存する(モーターを回しただけでも回線品質が著しく落ちたこともありました)ので、飛行機は現在2.4GHzのデジタル無線を使うようにしています。Xbeeは手軽に使える(3000円くらい?)デジタル2.4GHz無線なので、導入を検討されてみてはいかがでしょうか。
Xbeeを使いたいのは山々なんですが、2.4GHz帯の操縦装置（いわゆるプロポ）への干渉が心配なんです。無線LANや、R/C用の装置同士でも他社間で共存できないトラブルを起こした例もあるので、あえて別の周波数を選択しました。作業中は「Xbeeなら･･･」なんて考えてるんですけどね。
500円モジュールでは3000bpsで通信できています。温度測定には十分でも、ジャイロやGセンサで走りを解析するには不足しそうなので、Xbeeは別バージョンとして検討してみます。
>kankiさん
現在、こちらの飛行機は2.4GHzのラジコンプロポ-受信機とXBeeを同時に使用していますが、ほぼ問題なく通信できているようです。同じ周波数を使っているという点で気持ち悪いことは確かなのですが、周波数ホッピングやキャリアセンス等の技術を信頼するしかないと割り切っています。電波が目で見えればもう少し安心できるのですがね(笑)