September 01, 2008
モバイルサイトマップの追加 と MT4iの改造
僕の携帯には電話が滅多にかかってこないどころか、メールもほとんど全くこない(せいぜい2日に1通ペースのでメールが来たことすら気づかないことが多い)と、携帯的には圏外な生活をしています。ところが、近頃携帯でブラウザをする頻度が多くなってきました。電車に乗っているちょっとした時間に『はてな』でブックマークコメントを流し読みしたり、アキバにて過去の自分の行動をこのサイトのモバイル版で遡ったりする(特に過去の回路図とかパーツ情報)のが結構多くなりました。そういうわけで、このサイトのモバイル版も使いやすくしようという気になり、2つほど作業をしてみました。なおモバイル版は、MT4iというMovableTypeのデータベースを直接叩いて携帯向けHTMLを生成してくれるcgiを有難く使わせていただいています。
まず一つ目はGoogle先生からモバイルの記事も検索対象になるように、モバイル版のサイトマップを仕込んでみることにしました。方法はGoogle先生のサイトにあるとおりのXMLを作成、登録すればよいのですが、このサイトを生成してくれているMovableTypeにテンプレートを足すことでモバイル版サイトマップも自動生成しようと思います。
MovableType 2.661では管理画面を開いて[Templateの編集]で『新しいインデックステンプレートを作る』を選択、テンプレートの名前、出力ファイル名、自動的に再構築、リンクするファイルをそれぞれ Google Mobile SiteMap、sitemap_mobile.xml、チェック有、空欄にし、テンプレートの中身を以下のようにしました。
<urlset xmlns="http://www.google.com/schemas/sitemap/0.84" xmlns:mobile="http://www.google.com/schemas/sitemap-mobile/1.0">
<url>
<loc><$MTBlogURL encode_xml="1"$>cgi/mt4i/mt4i.cgi</loc>
<mobile:mobile />
</url>
<MTEntries lastn="9999">
<url>
<loc><$MTBlogURL encode_xml="1"$>cgi/mt4i/mt4i.cgi?mode=individual&eid=<$MTEntryID$></loc>
<mobile:mobile/>
</url>
</MTEntries>
</urlset>
あとは保存、再構築でGoogleのウェブマスターツールからこのXMLのURLを登録すれば完了です。少しつまずいたのは、locタグのURLをXMLエンコード(アンド記号&などが使えない)しなければならないことでした。
もう一つ行った改造は、MT4iのリダイレクト機能についてです。MT4iではリンクが本文中に含まれていると、そのリンクのURLを修正しゲートウェイを通すことでPC向けサイトでも携帯で見られるようにする機能があります。外部のサイトなら勿論これで問題がないのですが、自身のサイトでもこの機能が働いてしまい、自身の携帯記事から自身のPC記事へ飛んでしまうのが不快でした。そこでこの機能を実現している部分のプログラムを書き換えことで、この問題を修正しました。MT4i.cgiを修正します。
# Convert sorce URL to redirector
my $tmpurl = &make_href("redirect", $rowid, 0, 0, $eid);
# URL encode
$url = MT4i::Func::url_encode($url);
$url = $tmpurl . '&url=' . $url;
my $archive_url = $blog->archive_url;
if($url =~ /^$archive_url(\d{6})\.html/){
$url = &make_href("individual", $rowid, 0, $1 + 0, 0);
}else{
# Convert sorce URL to redirector
my $tmpurl = &make_href("redirect", $rowid, 0, 0, $eid);
# URL encode
$url = MT4i::Func::url_encode($url);
$url = $tmpurl . '&url=' . $url;
}
このサイトのPC記事は(アーカイブディレクトリ)/(6桁のID番号).htmlで保存されているので、その形式のリンクに突き当たった際は、PC記事のURLから携帯記事をURLを割り出すようにしました。PC記事の保存方法が異なる場合でも似たような方法がとれると思います。
今後もモバイル版ともどもよろしくお願いします。
※後になって、最近のコメントがうまく表示されない問題があることに気づきました。その場合は以下の修正を試みてください。
$args{'limit'} = ((!$_[0] || $cfg{NonDispCat}) && $_[1])
? $_[1] * 10 # Limit for recent comment and non-display category specified.
: ($_[1] && !$cfg{NonDispCat}) ? $_[1] : '';
$args{'limit'} = $_[1] ? ($_[1] * ($cfg{NonDispCat} ? 10 : 1)) : '';
if ($_[0] && !$cfg{NonDispCat}) {
if (!$cfg{NonDispCat}) {
プロダクトには名前を!!
忙しさを理由にするのはよくないことですが、行ってみたかった「ニコニコ技術部関西勉強会」。やはり不在通知Pさんは流石です。あまりにもツボだったので記事にしてしまいます。
中盤から腹筋が(大笑)Super Sylphideに足りないのは、間違いなく『萌え要素』ですね。 誰かに絵でも頼みますか (元ネタにもパロディがあって、そっちは萌えでしたが)
September 08, 2008
パルス頻度をアナログ電圧に変換
以前に似たような名前の記事『サーボ信号をアナログ電圧に変換』という記事を書きましたが、今度は時間あたりに何回かやってくるパルスをアナログ電圧に変換することになりました。というのもラジコンモーター用の回転数を計測(タコメーターの機能)し、それをアナログ電圧として取りこみたいという要望があったためです。
回転数を取りたいというニーズはあるようで、回転する物体に磁石を埋め込んで回転数を検出するラジコン用の部品がありました。例えばEagleTreeという製品の RPM Sensor with 4 magnetsがそれに対応すると思います。原理は単純で、埋め込まれた磁石の磁力をホールICで検出しパルスに変換、あとはそのパルスの頻度を監視すればよい、という訳です。先ほどの製品を分解された方もいるようで、製品で利用しているホールICの仕様を知ることができました。その他にも、光学的な方法(ペラが通ると光がさえぎられる)や電気的な方法(モーターを駆動しているスピコンの出力を監視する)といった方法があるようですが、マグネット方式が一番汎用性が広そうなので、ここではそういったセンサから出力されるパルスの頻度に注目することにしました。
ということで表題のとおり、パルスの頻度をアナログ電圧にマイコンを使って変換することを考えました。ここで2つの方式が思い浮かびました。一つは単位時間あたりのパルスの数を数える方式(波数方式と名づけます)、もう一つがパルス間の時間を計測する方式(同じく波長方式)です。この2つの方式を比較してみました。
結果は波長方式に軍配があがりました。というのも波数方式では回転数の計測精度をあげるためには、監視を行う一定時間、つまりサンプリング間隔を長く取らなければならず、更新頻度と精度が比例の関係にあります。一方の波長方式ではタイマーの解像度があれば、比較的短いサンプリング間隔である程度の精度を維持することができます。
詳しい比較はExcelのファイルに譲りますが、具体的な数値をあげると、8000rpm時に波数方式ではサンプリング間隔=1秒で60rpmの精度に対し、波長方式ではサンプリング間隔=約10msで精度2rpm(PIC16F88に搭載の16bitsタイマーの使用を仮定)と、更新頻度、精度とも波長方式が優れているという結果になりました。
予想はできていたのですが、このようになった理由としては、モーターの回転を検出するパルス頻度はマイコンにとって永遠とも呼べる時間であること(マイコン=数MHz、モーター=数百Hz)、またタイマーの解像度が意外と高い(16bits)こと、があげられると思います。
実装ですが、基板は以前の記事と同じPIC16F88を使った基板に対して、ほぼコードを入れ替えるだけで機能を実現できました(ホールICによってはオープンドレインのものがあるので、センサからの入力をプルアップに修正する必要があります)。コードをこの辺りにおいておきます。
コードで注目すべきは、波長方式においては除算をしなければならない、ということに話はつきます。除算をしなければならないのは (回転数) = 1.0 / (波長) の関係にあるためですが、マイコンにとって割り算は鬼門であり、今回もご多分に漏れずsdcc-2.8.0 (build.5117)においても16bitsどおしの除算を失敗していました。
そのような場合は線形補完(テーラー展開の1次項をとる)+ビットシフト演算で乗り切るのが定石だと思います。簡単な例をあげると、テーラー展開の結果 (差分) (割る 3) がでてきた場合、 (差分) (掛ける 43) (割る 128) つまりは (掛ける 43) (ビットシフト 7)で代用するということです。経験上、掛け算とビットシフト演算はどのマイコンでも問題なく動作するので、安心して使えます。
公開したコードからこのような苦労の片鱗を見ていただけると、少し報われます(笑)。
September 11, 2008
Super Sylphide 進捗状況(21) -- 飛行機の中身
オートパイロットシステム Super Sylphideですが、機体の特性を得るべく黙々と飛行試験と数値解析(システム同定で安定微係数推算)を続けています。同じ作業が続いているので更新を行うような話は特にないのですが、あまりにも更新がないのはさびしいので飛行機の写真を貼っておこうと思います。
外観
中には色々入っているんです(モーター類は一部省略)
変化したことといえば、ノーズ(先端)にH君作3孔ピトー管が水平、垂直方向に1本ずつ、計2本つくようになりました。この管から圧力をFreescale製のゲージ圧(差圧)センサに引き込み、同じくH君作のMSP430基板(MSP430自体は見えないですが、Super Sylphideのとなりにある赤い基板)で迎角と横滑り角、並びに対気速度をはかれるようにしてあります。Super Sylphideとの通信はSPIで行っています。
また、空中から地上への双方向リンクを確保すべく、XBeeの試験もはじめました。地上からデータを送信し、空中で受信、さらに受信したデータをそのまま空中から送信し、地上で受信、という簡単なロープバックテストをしてみましたが、パケットロスはほとんどなく良好な結果でした。障害物がほとんどないのが大きいのかもしれませんが、最大距離で100m超は通信できていることになります(オフレコがあるのですが、想像におまかせします)。写真にもあるとおり、アンテナは双方とも外付けバーアンテナを使いました。
※その後、積年(笑)のUSB周りの問題が、とりあえず解消しました。
| « | September 2008 | » | ||||
|---|---|---|---|---|---|---|
| 日 | 月 | 火 | 水 | 木 | 金 | 土 |
| 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 | ||||