このサイトは、航空・宇宙やコンピュータ、電子工作といった時代の最先端のことから、登山といった文明生活から遥かにかけ離れたことまで、思うがままに書いてあります。写真も大好きです。
興味がある方にしかおもしろくないと思いますが、どうぞ楽しんでいってください。あと、MovableTypeのカスタマイズ情報を提供しています。

If you are interested in "Super Sylphide", an autopilot system for small UAVs, please visit this page.



最後に、はてなアンテナやRSSリーダーで読む場合はこちらからどうぞ。

Super Sylphide 進捗状況(51) -- しまなみ海道 with TinyFeather

先日のゴールデンウィークの前半で、ツイッター仲間で尾道今治間を結ぶしまなみ海道を自転車で漕いできました。とってもいい道ですね! 景色よかったし、温泉や食べ物屋さんなど、周辺観光もとっても充実していました。自転車の旅行記を書きたいところでもあるのですが、僕の残念な文章力と写真では魅力を損なってしまうかもしれない(笑)ので、今回の自転車旅行にお供につれていったオートパイロットシステム TinyFeatherの話を書こうと思います。ええ、またいつもの話です、すいません。

TinyFeatherは航法装置として動作するので、自転車で移動している様子がログできます。ログにはいくつか種類があって、(1): 内蔵しているGPS(u-blox LEA-6T)のデータ、(2): (1)に加速度計やジャイロを足すことでその場で複合演算をしたオンライン版INS/GPSデータ、(3): (2)と同じデータを後処理の複合演算をして得られたオフライン版INS/GPSデータ、の3つをとることができます。よくあるGPSロガーのデータは(1)に相当するものです。(2),(3)にもなると、傾きなどをとることができ、どこで転んだかがわかります(笑)。

動作不良(先日のDMAの話)があったため、一部ログを失ってしまっているのが後からわかったのですが、取れている範囲でログをざっくりと紹介したいと思います。一回激しく自転車からこけたのですが、その部分のログもなくなっていました。はからずも体を張ってしまったのにデータを欠損していてとてもショックです。

では気をとりなおして(1)のGPSデータ。緯度経度を示してみます。

u-bloxのGPSデータは、同社が配布しているu-centerというツールを使うことによって、Google Earthのデータ形式であるKMLに変換できます。上記の画像もGoogle Earth上に表示させたのをとってきました。

そして(3)のデータ。(2)と(3)はほぼ同じものが得られるので、より精度がよいであろう(3)のデータを示してみます。こちらも緯度経度。上のGPSデータのうち、北側に相当する部分です。

(1)のGPSデータと形がよく一致しています。が、一部を拡大してみると違いがあります。順に(1)GPSデータ、(3)オフラインデータ。

GPSのみ(1)

INS/GPSオフライン(3)

GPSが途切れてしまっている中央のところ(上画像で赤点の発生している部分)もINS/GPSだと滑らかにつながっています。(3)のINS/GPSでは補間がちゃんと効いています。このように加速度計やジャイロを搭載してうまく処理をすることでより妥当な結果が得られます。

(2),(3)でとれた姿勢データもあるのですが、これを面白く表示する方法が思いつかないので、今回はパスとさせてください。転んだところのデータが残っていれば…、とっても惜しいです。またのこける機会があるはずなので、そのときにでも…

TinyFeatherの自転車への搭載ですが、料理用の容器に本体とバッテリーを詰め込んで、雨対策をしました。GPSアンテナだけを外部に露出する方法で、雨程度の防水でしたらこれで十分に機能しました。

外観

中身

ケースには『タケヤ化学 ツイストパック3 TX-18B 270ml』を、バッテリーにはエネループ QE-PL101を使っています。黒いのはホームセンターで買ったウレタンフォーム材で、隙間を埋めるのに使っています。

今回はこの防水状態で本体をサドルバックの中に詰め込み、GPSアンテナをバッグの外に張っておきました。GPSの受信も良好でした。姿勢データを検証するためには本当はもっとしっかりとした固定をしなければいけないので、今後の課題としたいと思います。今のところ、ドリンクホルダーをうまく使えないか検討中です。

DMAとFIFOの難しい関係

オートパイロットシステム TinyFeatherのなかなか再現しないバグが最近ようやく解消したので、どういう問題であったのかということを、自分への備忘録として残しておきたいと思います。なかなか気づきにくい種類のバグでしたが、理屈がわかってしまえばとても納得のいく問題でしたので、スッキリしたついので勢いで記事を書いています。

バグを抱えていたのはDSPのUARTの受信部分でした。DSPのUARTは受信用のハードウェアバッファ(FIFO)を持っており、FIFOに一定量のデータがたまるとDMAが動作するようになっています。本体の計算能力を奪わないためにも、また、FIFOの容量より大きなデータを受信できるようにするためにも、DMAを活用してFIFOの内容をメインメモリに転送することにしました。メインメモリ上にはリングバッファが形成されており、その他のポーリングルーチンなどから任意のタイミングで受信データを読み出せるようにしてあります。図示すると以下のようになっています。

正常時

正常に動作している場合は、流れるようにFIFOへの受信、FIFOからメインメモリ上リングバッファへのDMA転送、リングバッファからの読み出しが行えています。

しかし偶発的に計算負荷があがり、リングバッファからの読み出しをサボる事態が発生すると、リングバッファに空きがなくなります。さらにDMAもリングバッファ上の空きがないことを知って、休眠状態に入ってしまいます。ここからいかに回復するか、というところにバグが含まれていました。状態と解決方法を整理した図を以下に示します。

異常時

リングバッファに新たに空きができても、DMAが動作しないことが問題でした。上から4番目の図に青字でしめしたとおり、DMAを手動で起こしに行く必要があります。今回のDSP(TMS320C6745)の場合、DMAを起こすためには、FIFOを一旦空にして、DMAトリガーが再びかかるようにする必要がありました。

繰り返しになりますが、気づいてしまえばなんということはない問題です。FIFO、DMA、リングバッファと登場人物が多かったのが、解決への道のりを長くしていたのだと思います。

Xperia Active ST17i を買ったよ!

最近のマイブームはAndroidのアプリを作ることなのですが、それのデバッグ用に端末を一台購入しました。Sony EricssonのXperia Active (ST17i) という国内未発売のモデルです。いわゆるSIMフリー端末というヤツですね。電波関係のことはこれ以上書くと(ウワナニヲスルヤメロ)なので、使用感を書いておこうと思います。

ST17iを持って撮影

一番気に入っているのがその小ささです。別に一台所有しているG-shockスマホ(Casio IS11CA)ですと、画面の幅が結構あるので、掴んでいる側と反対側をタップするときに結構親指を伸ばさなければいけなかったり、あるいは別の手で入力、ということで少々大変でした。ST17iでは上記の写真にあるとおり、片手で余裕で操作できる大きさで、そこがとても気に入っています。

防水仕様なのもいいですね。手が多少ぬれていてもタップに対して反応してくれます。IS11CAよりも感度がよいと思いました。

カメラ用のシャッターボタンも気に入っています。普通のカメラと同じ構造で、半押しでフォーカス/AEロック、全押しでシャッターという2段階ボタンなので、構図をいじりやすいです。

使用感はこんなところでしょうか。後はどっちかというとこっちの方が本題だったりするのですが、自分メモとして何をやったか記録を残しておこうと思います。

• OpenWnnフリック入力対応 を導入。同梱されているPOBoxでは、変換候補まで表示されてしまうと、テキスト入力エリアが十分に映らなくなり、不便。小さいソフトキーボードを探してOpenWnnにいきついた。
• root化。購入時点で4.0.2.A.0.62というビルド番号だったが、これはroot化が困難らしい。ということで4.0.2.A.0.42にダウングレードしrootをとって、4.0.2.A.0.62にアップデートした。root化は維持されている。いちおうオリジナルの62もバックアップとして取得しておいた。
• FM Radioを日本の周波数帯にあわせた。/system以下にある設定ファイルを書き換えで対応。
• フォントをメイリオに変えた。購入時の中華フォントでは漢字が一部異なることに違和感を覚えたため。
• セルスタンバイ問題の解消。データ専用SIMを使っていてビックリマークのアイコンが気になったことが発端。結果電力消費を抑えることにも役に立つらしいので満足。

バリバリ使っていく予定です。

Super Sylphide 進捗状況(50) -- Sylphideデータ形式

前回の進捗記事ではオートパイロットシステムSuper SylphideおよびTinyFeatherの通信プロトコルについて紹介しましたが、今回はそのペイロードとして載ってくるデータの形式について記事を書きたいと思います。このデータ形式は32bytesの固定長で、通信のペイロードとして載ってくる以外に、SDカードに保存されるログの形式としても使っています。

データ形式の構造は単純で、先頭1byteによって残り31bytesにどのようなデータが含まれているかを示しています。種類ごとに『ページ』という呼び方をしており、現在のところ以下のようなものがあります。

ページ種類	内容
Nページ	航法情報
Gページ	GPS情報(中身はu-bloxのubx形式)
Aページ	A/D変換データ
Fページ	PWM入出力情報
Mページ	地磁気情報
Pページ	ADS情報
Cページ	コマンド
Dページ	デバック情報

ページが違えば、内部の形式はまた定義が異なるのですが、例えば、航法情報を保存しているNページは以下のような形式になっています。

オフセット	例	備考	変換例
0	0x4E	ヘッダ	`N'
1	0x03	シーケンス番号	3
2	0x00	(予約)	0
3	0x00	(予約)	0
[4-7]	0xD0 0x1B 0x00 0x00	GPS時刻, Little Endian, 単位はmsec	7120
[8-11]	0xC8 0x6F 0x49 0x15	緯度, Little Endian, signed, 単位は[0.0000001deg]	35.713428
[12-15]	0x28 0x09 0x4E 0x53	経度, Little Endian, signed, 単位は[0.0000001deg]	139.762308
[16-19]	0x00 0x35 0x0C 0x00	高度, Little Endian, signed, 単位は[0.0001m]	80
[20-21]	0x32 0x00	北方向速度, Little Endian, signed, 単位は[0.01m]	0.5
[22-23]	0x9C 0xFF	東方向速度, Little Endian, signed, 単位は[0.01m]	-1.0
[24-25]	0x05 0x00	下方向速度, Little Endian, signed, 単位は[0.01m]	0.05
[26-27]	0x39 0x30	ヘディング(ヨー), Little Endian, signed, 単位は[0.01deg]	123.45
[28-29]	0x2E 0xFF	ロール, Little Endian, signed, 単位は[0.01deg]	-2.1
[30-31]	0x7B 0x00	ピッチ, Little Endian, signed, 単位は[0.01deg]	1.23

その他ページの定義についてはコードを見ていただくのが一番だと思いますので、このデータ形式を処理するC++ソースとJavaソースを公開したいと思います。

なおデータ形式を32byutes固定長にしたのは、2の乗数にすると効果的にログ保存ができるためです。SDカードに記録する際にはセクタサイズ(512bytes)等を意識して書き込みをするとよいので、その長さを効率よく使えるよう32bytesとしました。また、通信プロトコルに32bytesの固定長モードがあるというのも、データ形式が32bytes固定長を効率よく転送できるようにするためです。

※その後、TinyFeatherを自転車のロガーとして使ってみました。

石垣島

石垣島に先日行ってきました。あいにくのお天気だったのですが、持っていった自転車で様々な場所を巡ることができました。たまたま天気が良かった日の写真を一枚、貼ってみます。

IS11CAで撮影

海がとても綺麗でした。写真は石垣島北側で撮ったもので、島内を自転車でほぼ一周した際に撮りました。川平湾や○○ビーチといった名所もいいのですが、こういった何気ない風景も大好きです。

Super Sylphide 進捗状況(49) -- Sylphide通信プロトコル

ご無沙汰しています。オートパイロットシステム Super Sylphide、およびその後継機のTiny Featherでは、無線を使って地上からモニタおよび指令を行うことができますが、独自規格ながら通信データのプロトコルを定めて運用してきました。このたび @henshiru 氏がメインで開発していたSuper Sylphide用地上モニタソフトのMaeve(メイヴ)がオープンソース化(MIT Licenseだと思う)されたことを受けて、このプロトコルの話を少し書こうと思います。

動作中のMeave

世の中には色々なプロトコルがあるので、既存の規格にあわせることも考えたのですが、なかなかお手ごろなシンプルなものがありません。僕が欲しいと思ったのは、流れてくるデータを意味単位に切り分けられること、簡単なエラー検出、この2つがあればいいと思いました。エラー訂正など、より機能を充実させるためにはTCP/IP方式で、このプロトコルをさらに上位プロトコルで包んであげればよいという思想も背景にあります。

結局、独自規格として以下に定めるSylphideプロトコル(固定長と可変長の2タイプ)を定めました。

0/32bytes 固定長プロトコル

インデックス	内容
0	0xF7 (ヘッダ, 8bits)
1	0xE (ヘッダ, 4bits) & 4 bits (ACK要求,ACK返答,ペイロード非所有,RESERVED='0')
2, 3	シーケンス番号(2bytes)
(4 - 35)	ペイロード(32 bytes)
(36, 37) or (4, 5 : ペイロードなしの場合)	CRC-16 2bytes (CRCの計算範囲はインデックス2から直前(3か35)まで)

N bytes 可変長プロトコル

インデックス	内容
0	0xF7 (ヘッダ, 8bits)
1	0xE (ヘッダ, 4bits) & 4 bits (ACK要求,ACK返答,ペイロード非所有,RESERVED='1')
2, 3	シーケンス番号(2bytes)
4, 5	ペイロードサイズ
(6 - (6 + (N - 1)))	ペイロード(N bytes)
(6 + N, 6 + (N + 1))	CRC-16 2bytes (CRCの計算範囲はインデックス2から直前(6 + (N - 1))まで)

転送効率やエラー検出能力について詳細に検証したことはないのですが、これまで使ってきて大きな問題は発生していません。ちよっとした補足としては、ヘッダ(0xF7, 0xEX)については、ペイロードを調べて出現確率が最も低い組み合わせを算出しました。

現在、このプロトコルのパーサとしてC++版、およびJava版があります。拡張は簡単にできるよう、それぞれstd::[i/o]streamとJava.io.Filter[Input/Output]Streamに準拠させてました。なおJava版は、ある目的のために最近作ったもので、近いうちに成果物をださればよいなと考えています。

※次の進捗記事は、通信プロトコルのペイロードにあたる部分について書きました。

野沢 スキー

先日、野沢温泉にスキーに行ってきました。まずまずの天気でした。

(注)右下の板は違う方のです(笑)

今季はもう打ち止めな気がします。結局、5回(白馬五竜、水上、ガーラ(石内丸山)、高畑、野沢)です。一番滑ったのは高畑かな。穴場的なとても滑りやすいスキー場でした。次点は水上。