April 05, 2009
フライトログの可視化
珍しく飛行機の話題です。飛行機を飛ばして実験をしていると、どのように飛んだかを記録したフライトログが多く溜まるのですが、数値データをプロットしただけのグラフを見たところで何が起きているのか瞬時に理解するのは至難の業です。そこでわかりやすい説得力がある図が作れないものかと、試行錯誤してみました。結果、このような図を生成するに至りました。
クリックすると綺麗なpdf、長周期(フゴイド)モードが励起
飛行機がどのような高度を経由したのかを緑色の線で、飛行機の対地面角度(ピッチ)を機体の傾きで、風に対する角度(迎角)を赤色の弧で表しました。赤色の弧の大きさがあまり変化せずに、緑色の線の上下動と機体の角度変化が連成しているので、長周期モードとわかります。
この図を生成する技術的な話ですが、Ruby + libHaru を使いました。libHaruはCで書かれたPDF生成ライブラリですが、RubyやC#などから呼び出すインターフェイスが付属しています。当初機体の図がepsであったので、epsを直接扱える方法を模索したのですが、うまくいかなかったため、透過pngを扱えるlibHaruをRubyから扱うことにしました。生成スクリプト longitudinal.rbをおいておきますので、参考にどうぞ。
なお断念した方法もいくつか紹介しておきますと、epsの配置を記述したTeXを生成してPDF化(座標を指定して配置する方法が不明、overpicが近い?)がや、Matlabのpatchコマンド利用(座標で配置したいオブジェクトを作る必要がある?)を考えていました。
April 14, 2009
April 21, 2009
奇数割の分周器VHDL
以前、猫カメラ向けにSDRAMのコントローラ等をVHDLで作成したことをお伝えしましたが、その際に紹介したVHDLに含まれていた分周器(divider.vhd)が論理合成不可能なコードを使っていたため、修正しましたのでお知らせします(リンクは修正済みの最新版です)。
もともと分周器のコードは偶数割(例えば1/2とか1/4とか)と奇数割(1/3とか1/5とか)で違うインスタンスが生成されるようにgenerate構文で制御していたのですが、シミュレーションでは偶数割、奇数割の両方を行ったにもかかわらず、CPLDやFPGAに実装するために必要となる論理合成は偶数割しか試していなかったことが問題発覚が遅れた原因です。シミュレーションで実証できても全てが論理合成できるわけではないという基礎を疎かにしていました。
というわけで問題があったのは奇数割のコードなのですが、修正前(r3008.divider.vhd)はエッジの検出を立上り(L to H)と立下り(H to L)の両方で行い、カウンタはインクリメントするものでした。ダイジェスト版を以下に示します。
gen_odd: if (divide_value mod 2 = 1) generate
process(clk, clk_n, reset) begin
if reset = '1' then
timer <= (others => '0');
elsif (clk'event and clk = '1') or (clk_n'event and clk_n = '1') then
if timer < conv_std_logic_vector((divide_value * 2) - 1, required_bits) then
timer <= timer + 1;
else
timer <= (others => '0');
end if;
end if;
end process;
clk_out <= '1' when timer < conv_std_logic_vector(divide_value, required_bits) else '0';
end generate;
timerは指定した分周比の2倍まで数えられるカウンタです。このコードで論理合成を行うと、立上りと立下りのエッジをorでつなぐことができないと文句を言われてしまいました。orでつなぐことができないなら、と、elsifで分離したり、processを分けて試行錯誤してみましたが、両方のエッジで同じレジスタの値を変更することができないという別のエラーが発生しました。こういった両方のエッジで論理合成を可能にするためには、立上りと立下りでカウンタを2つ用意するのがよいようです。
しかし何とかレジスタ数を減らしたかったので、カウントの方法を工夫しカウンタを1つにした結果できたのが今回のコードです。立上りでは最下位ビットのみをコントロールします。立下りでは最下位以外のビット列の加算を行います。このようにすることで、立上りと立下りで同じレジスタをいじることを防いでいます。
もしかしたら論理合成を行う際の最適化によって、カウンタが2つの場合でも変わらないコードが生成されているかもしれません。とりあえずは、奇数割の際にも機能を達成できたということで満足しています。
※(2010/7/6)以前公開していたコード(r3383)はジッタフリーでなく、クロック源として使うには問題があるとの指摘をうけました。シミュレーション上問題なかったので見落としていたようです。リンクは最新版で既にこの問題が解消されています。
April 29, 2009
HandBrakeのビルド用パッチ
iPodなどの携帯プレーヤ買いたいと思ったのが半年前で、なかなか踏ん切りがつかず月日が流れていったのですが、この度ようやくiPod touchを購入しました。Apple storeに行って弄ったのがきっかけで、マルチタッチに感動しつつ、これで自分のアプリを作れば楽しいに違いないと感じた次第です。
どうやら新製品が投入されるとの噂もあるようですが、潮流がえらく速い電気モノは、欲しいと思ったときが買い時なのは間違いないので、購入に踏み切りました。買ったのはApple純正の整備済製品(新品同等、但し1世代古い)というもので32GBモデル 33,800円(現行品の定価に比べると1万円程度安い)でした。購入時から1世代古ければ新製品でてもそれほど悔しくない、っていう心理も働いています(笑)。
アプリも作ってやる、ということで買ったiPod touchは現在、全力で動画プレーヤとして活躍しています(笑)。ひたすらDVDやらフラッシュファイルといった映像ソースをエンコードしまくってはiPod touchに入れて見ています。携帯を換えずにワンセグと縁がないまま今まできてしまった僕からすると、動画が外で見られることにかなり衝撃を受けて嵌ってしまいました。iPodで動く銀塩カメラのサポートツール(F値とかシャッタースピードなどの露出を記録したい)を作りたいと考えているのですが、開発は当分先送りされそうです。
ようやく本題です。iPodに動画をいれるにあたって利用しているエンコードソフトは、タイトルにあるHandBrakeというソフトを利用しています。無償であること(ソースも公開されている)、DVDディスクとファイルの両方から動画をエンコードできること、iPod用の設定が元々あるので変換が簡単なこと、コマンドラインからも操作できること(まとめて処理したいときはGUIよりもCLIが便利)、これらの点を気に入って使っています。
しかしながら使っていて気づいたのは、この記事を書いている時点での現行のバージョン0.9.3ではwmv(Windows Media Video)を正しく読み込めず、スタックダンプをしてしまうようでした。0.9.3は昨年にリリースされたバージョンのようなので、デコーダ、エンコーダ等の依存ライブラリを最新のものに変更した上で、ソースからビルドすれば状況が変わるかも、と思い試してみました。
HandBrakeのソースを眺めたところ、入力部分はffmpegが提供しているlibavcodecに依存しているようです。この部分を最新にした上でビルドをしてみました。おおまかなビルド方法はHandBrakeのWikiに書いてありますが、残念ながらこのままではうまくいかなかったので細かい修正を重ねつつビルドを成功させました。修正点をまとめたパッチ handbrake-0.9.3.patchをおいておきます。使い方はjam等の必須ツールを入れた後、HandBrakeのmakeを実行する直前でパッチを適用してください。
新しくビルドしたHandBrakeではwmvも正常に扱えており、目論見はあたっていたようです。これで快適なiPod生活を続けられます。
| « | April 2009 | » | ||||
|---|---|---|---|---|---|---|
| 日 | 月 | 火 | 水 | 木 | 金 | 土 |
| 1 | 2 | 3 | 4 | |||
| 5 | 6 | 7 | 8 | 9 | 10 | 11 |
| 12 | 13 | 14 | 15 | 16 | 17 | 18 |
| 19 | 20 | 21 | 22 | 23 | 24 | 25 |
| 26 | 27 | 28 | 29 | 30 | ||