3domain.hkがサービス休止

ここのドメインnaruoka.orgはDynamics DNSの3domain.hkを使って運用していたのですが、2009年5月1日をもってサービスが休止した模様です。休止に関して事前通告のメールがあったようですが、読み落としてしまっており、IPが引けなくなった今現在になって気づきました。急いで別のDDNSのMyDNS.jpに移行してみたところです。もし不具合などありましたら、教えていただけると助かります。

3domain.hkはその前進のminiDNS.netの頃から愛用しており、サポートツールを作った僕としては、休止のお知らせはなんとも寂しいものです。ネットのインフラを提供してくれる方たちの有難さは本当に感謝に尽きません。

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

シリアルポートをstd::iostreamと同等に扱う

マイコンを扱っているとシリアルポートで通信を扱う機会がよくあるのですが、標準入出力やファイルと同等にシリアルポートを扱いたいという要望があります。例えば何かの入力を拾ってきて、それを加工し出力するC++プログラムがあったとします。このC++プログラム、当初はファイルに記録されたログをfstreamで読み込み、後から処理させることを想定していました。しかしとある事情で、シリアルポートからリアルタイムで情報を取得し、それを加工して出力する必要がでてきました。さてどうすれば変更を最小限に留められるでしょうか、というのが今回のお題です。

まずですが、プラットフォームはWindowsを想定することにします。なぜなら*NIXなら/dev/ttyS0等のスペシャルデバイスによってシリアルポートはファイルとかなり同等に扱えますので、あえて茨の道を進みます(笑)。ちなみにWindowsにインストールしたCygwinなら/dev/ttyS0等が使えるので問題なし、と思った方へ、僕も試しましたが動作がいまいちでした。

Windowsでシリアルポートを扱う際の作法としては、WindowsAPIにあるCreateFileでCOMn(nは番号)と名前のついた特別なデバイスをオープンし、ハンドルを取得、その後ReadFileやWriteFileで読み書きという寸法です。これらのAPIをうまく隠蔽し、C++標準のIO環境であるstd::iostreamにうまくマップできれば本体の処理プログラムの変更は最小限で済みそうです。

このような時にはstd::iostreamのうち、n文字の読み書きといった低レベルの入出力を担当しているstd::streambufを継承したカスタムバッファを作成するのが王道のようです(Codianの『カスタムバッファ』の説明がわかりやすいと思います)。

方法がわかってしまえば、あとは調べて実装するのみです。C++の仕様がまとめられたcplusplus.comのstreambufの解説ページ、『C++ iostream 実装資料2』等を参考にしました。

結果としてできたのがcomstream.hで、WindowsAPIによるシリアルポートの同期読み書きをラップしたカスタムstd::streambufのComportStreambuf、ならびにそれに処理を委譲したカスタムstd::iostreamのComportStreamです。std::iostreamライクなエコーバックするだけのテストプログラムcomstream_test.cppも書いてみましたが、gcc3.3.4とVC9(VS2008 Express Edition)で動作確認しました。

正常動作しているもののひとつ疑問なのが、std::streambufの定義をオーバーライドしているuflow()とunderflow()です。読み込み用内部バッファのポインタ操作で両者の違いを出す必要があるようですが、今回は内部バッファがないのでこの定義をどうすればよいのか、いまいちつかめていません。M$提供のヘッダをみる限りではuflow()が内部でunderflow()を呼び出しているようなので、underflow()だけ定義があればいいのかもしれません。

今後の拡張の展望としては、読み戻しのサポート(現在、pbackfail()は常に失敗するので読み戻しできません)や非同期化(いわゆるノンブロッキングIO)がありますが、両者とも僕としてはマイナーな用途なので実装する機会が訪れるかは不明です。

※MacOSXをサポート(多分*NIX系全てOK)し、クロスプラットフォームになりました。上記リンクは最新版です。

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

2009 雲取山

先日、東京都の最高峰、雲取山に行ってきました。かれこれ6回目くらいになるのですが、なかなか晴れないのがこの山の特徴です。しかしながら今回の山行中の2日間とも晴天に恵まれ、写真には写らないほどうっすらでしたが、富士山を拝むことができました。

七つ石山より雲取山

お昼はセブンブランドで統一

今回のコースですが、僕の中で定番となりつつある、埼玉県の三峰(大血川沿いのお清平付近)から入って、雲取山、七つ石山、石尾根経由の奥多摩駅です。1日目は晴天のおかげもあり調子がよく、奥多摩小屋までを予定していたところを鷹ノ巣山非難小屋で泊まりました。この非難小屋は非難小屋と思えないくらい綺麗でとても快適でした。

さて次はどの山に行こうか、とわくわくしています。

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

MTM03

風にも負けず、というかインフルエンザ騒動にも負けず(笑えない)、行ってきましたよ!! Make Tokyo Meeting 03。どれも面白かったのですが、写真をいくつか撮ってきたのでアップしてみます。

自作MP3プレーヤー Timpyのchiakiさん。歴代Timpyです。私信ですが、カメラモジュール活用させていただきます。

尻P先生のカルマン渦ミク。工学的に非常に深い現象だったりします。カルマンフィルタのカルマンさんとは、違うカルマンさん(笑)

実物見ることができるとは思っていませんでした。桁ごとクロック KetaClock。桁ごとに独立して売られていて集める楽しみがあるのだとか、ないのだとか(笑)。

タコルカ帽。かぶれます。仕様どおり浮いていますよ。

澪ちゃん…、ではなくて、ビーズは多色でいいですね(意味深い)

他にもアレやコレがあるわけで、興味がある方は明日もありますので是非どうぞ!!

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

Super Sylphide 進捗状況(24) -- DSP航法ファームウェア開発遍歴

しばらく更新をしていなかったオートパイロットシステム Super Sylphide関連の話です。色々と大人の事情(世の中こういえば許されるらしい?、笑)があって記事を更新していなかったのですが、自分で設計したDSP基板で自分が考えた航法アルゴリズム(注:リンク先は搭載されているアルゴリズムの一部に過ぎません)が走るというのは気持ちがいいものです、という状況にようやく到達しました。そこで現在に至るまでDSPの開発遍歴をまとめておきたいと思います。

まずは象徴的な図を一枚あげます。

番号1～3の順に開発が進行してきた

当初いきなりDSPで動くアルゴリズムをプログラムするのは難しいと考えました。そこでSylphideから取得したセンサの生データをPCで後から処理するためのプログラム analyze.exeをまずは書きました。analyze.exeは最も時間的制約が緩く、データを都合のよい順に並べ替えて処理しているので、オフラインでの解析に相当します。
ここで並べ替えをしている理由について軽く触れておきます。A/D変換を行う加速度計、ジャイロから出力されるデータは時間遅れが無視できるほど小さいため問題がないのですが、GPSなど内部で複雑な処理を行うものについては無視できない時間遅れが発生するため、データの到着時刻と、そのデータが表現する状態の時刻は一致していません。そのためanalyze.exeでは並べ替えによってこの問題に対応しました。
なおanalyze.exeについてはその後高機能化し、複数GPSアンテナによる解析等を行えるようにしました。

その後、それをリアルタイム化したanalyzeRT.exeというPCで動くプログラムをリリースしました。analyzeRT.exeでは、データの到達順に逐次処理、言い換えれば遅れて入ってきたデータについても最新の状態まで追いかけ処理することによって、時間的に常に最新の状態が出力されるようにしてあります。このプログラムは入力として、analyze.exeと同じSylphideで取得された生データログファイル、あるいはSylphideをPCにUSB経由で接続する際に作られる仮想COMポートから流れてくる生データストリーム、の両者を受け取れるようにしてあります。これでリアルタイムのアルゴリズム的な動作検証を行いました。

最後にDSPへのanalyzeRT.exeの移植をし、NAV2_Coreファームウェアを作成しました。行列計算等の基本演算部分はDSPの特性が生かせるPCのコードを変更しましたが、肝心のアルゴリズム部分はPCと共通のヘッダとし、新たな問題がうきる可能性をできうる限り回避しました。PCとコードを共通化できたのは、使用したDSPがC++でコーディング可能であることによっています。
DSPのデバックフェーズでは検証のしやすさを優先させ、Sylphideのデータを直接処理させずに、DSPの統合開発環境(IDE)であるCode Composer Studio (CCS)に搭載されたRTDX(Real-time Data Exchange)の機能を活用し、PCからデータを送りつけてDSPでそれを処理、またPCに回収するという流れを使いました。行ったのは2つの検証です。1つはanalyzeRT.exeの結果と比べことによるDSP内での処理の妥当性、もう1つはCCSに搭載されたプロファイラによる負荷の見積もりです。両内容ともクリアし、後者によれば加速度計、ジャイロによる20Hzの時間更新(行列の積算、加算が中心)と、GPSによる4Hzの観測更新(行列の加算、逆行列計算が中心)で、最適化オプション-O2で約20Mticks/secの演算量でした。使用しているDSPは200MHzで200Mticks/secの演算能力があるのですが、更新レートが同じであればオーバーヘッドを考えても最大でDSPの演算能力の3割以内くらいで済むと予想しています。これなら航法の後に続く誘導、制御にも相当の能力を割り当てられそう、とほっと胸を撫で下ろしています。

文章にまとめてしまうと量をあまりこなしているようには見えませんが、試行錯誤、紆余曲折をしつつ現在に至っていますので、かけた時間はかなりのものになりました。今後の誘導、制御ルーチンの開発では今回までに獲得した検証スキームを有効活用して効率化をはかりたいと思います。

※その後、この時点での航法ルーチンには通信の問題があることが発覚、解消しました。

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