2016年2月27日土曜日

SDRでラジコンのバンドチェック

今時VHFかよ、って気もしますが、SDR#でラジコンのバンドチェックが可能です。
27MHz、40MHz、72MHzの周波数は同時に複数の送信機がONになるとマズイので、ちゃんとしたラジコンの飛行場とかは周波数管理もちゃんとしていますが、周りに使ってる人がいないとも限らないので、ノートPC1台あれば簡単にチェックできますよ ということで。
もっともそれぞれの周波数帯が離れすぎてるのでSDR1個あたりバンド1個しかチェックできませんが。空物の飛行場の場合はワンセグチューナを2個用意するか、1つのバンドしか許可しないみたいな運用になると思います。
田舎で自分の敷地で遊ぶ 周りにはラジコンやってる人はいないけど念のため という風にサクッとチェックすることもできます。

周波数多重で同時通信が可能なモノ(ラジコン・特小無線等)はSDRでチェックするとどこを使ってるか一発でわかるので便利ですね。




2016年2月25日木曜日

C#の文字列の指定位置を置換する

C#の文字列で一部を置換したかったのだけど、欲しい機能が無いっぽいので作ってみた。

やりたいこと
入力: "012345679", 2, "ABC"
出力: "01ABC56789"

とりあえず拡張メソッドで作った。"0123456789".Replace(2, "ABC") で"01ABC56789"が出力される(はず)。動作チェックはあんまりしてないので間違ってるかも。


public static string Replace(this string Before, int Start, string Insert)
{
    if (string.IsNullOrEmpty(Insert))
    {
        return (Before);
    }

    if (Start < 0)
    {
        Insert = Insert.Substring(-Start);
        Start = 0;
    }

    {
        int hoge = Before.Length - (Start + Insert.Length);
        if (hoge < 0)
        {
            Insert = Insert.Substring(0, Insert.Length + hoge);
        }
    }

    string s1 = Before.Substring(0, Start);
    string s2 = Before.Substring(Start + Insert.Length);

    return (s1 + Insert + s2);
}

2016年2月20日土曜日

鳳龍4号

先日のH-IIA F30でASTRO-Hが打ち上げられ、同時に3機のキューブサットも打ち上げられました。
現時点ではH-2A R/BとASTRO-Hの他に4物体の計6物体がTLEに掲載されています。
JavaS Orbit
そのうちキューブサットは3個ですが、これらについてはまだ確定していません。

さて、そのキューブサットですが、3機とも430MHz帯のビーコンがあります。ということでその辺りを受信してみました。バンドプランでは衛星の帯域は3MHzが確保されていますが、今回打ち上げられた3機は0.3MHz程の距離なので、SDRの0.900001MHzでカバーすることができます。

受信環境はワンセグチューナに市販の430MHz15エレの9エレのみを直結し、SDR#でIQを受信、受信完了後にスペクトルを可視化しCWをデコード、という手順です。今回の打ち上げでは軌道傾斜角は31度で、北海道からは好条件でも仰角10度前後までしか上がってきません。衛星との距離もかなり離れているので、固定アンテナでもアンテナの視界にいる間にかなり受信できます。自宅の窓の方向、南西に向けてインシュロックでベランダに固定したアンテナでも綺麗に受信できました。

以下の図はかろうじて鳳龍4のコールサインの一部が読み取れる状態です。


別のパスでは"JG6YBW HORYU4"と、コールサインと名称の両方を明瞭に受信できました。


一番条件が良かった時はChubSat-2のあたりにも小さなピークが見えたので、それも今後デコードしてみようと思っています。

それと、仰角がほとんど無いせいか、ベランダに設置してある市販のダイポールアンテナでもそれっぽいピークを受信することができました。今回打ち上げられた衛星は高緯度地域からはほとんど水平方向に見えますから、トラッキングする機材が無くても狙い目だと思います。

2016年2月15日月曜日

Windowsのショートカットで起動オプション

WindowsのEXEは右クリックからショートカットを作成できる。そのショートカットにはリンク先のテキストボックスに起動するEXEのパスがあり、そこにオプションを追加すれば起動オプションとして渡すことができる。

参照:クラウドサービスプラットフォーム Cosminexus:eclipse.exeの-cleanオプションをショートカットに設定する:ソフトウェア:日立

じゃぁスクリーンセーバーにも起動オプションを渡せるのか?と思って試してみた。
御存知の通り、WindowsのスクリーンセーバーはEXEの拡張子をSCRに変更したものだ(そのため中身はEXEと全く同じであり、EXEと同じ動作が可能。なのでウイルスソフトウェア等がスクリーンセーバーに擬態して入ってくることが可能)。
リンク先のEXEをコピーしてSCRに変更、同時にリンク先のファイルもEXEからSCRに変更する。そうすればそのショートカットはスクリーンセーバーになりインストールすることが可能。次にEXEと同じようにリンク先に起動オプションを追加して起動する。そうすると、起動オプションは無視され、実行したファイルパスと"/S"という文字列の2個が渡された。ということで、SCRというショートカットにオプションをつけてもWindows側で不要な文字列は削除するらしい。

さて、"/S"というオプションだが、これは「あなたはスクリーンセーバーとして起動しなさい」とEXEに知らせるためのものらしい。他にはPやCがあり、それぞれ「プレビューモードで動作しなさい」と「コンフィグモードで動作しなさい」という意味らしい(プレビューは基本的にSとして理解していいようだ)。

普段から使用できるソフトウェア(EXE)だが、起動方法によってはスクリーンセーバーとして動作し、起動オプションで設定を渡す、という動作を行いたかったが、そのような動作はできないようだ。正しい動作としては/Cで設定アイアログを表示し、適当なフォルダに設定ファイルを保存、/Sで起動された場合は設定ファイルを読み込んでスクリーンセーバーとして動作、オプションがない場合は通常のEXEとして動作する、あたりが落とし所かもしれない。

2016年2月6日土曜日

レプEoTechをバラしてみた

7千円くらいのレプEoTechをバラしてみた。



ネジを数本外せば簡単にバラすことができる。基板はメインとスイッチ部の2枚で、その間はフラットケーブルで接続されている。メインの基盤には14ピンのマイコンとその他抵抗やコンデンサなどが実装されている。14ピンのICは表面が汚れていたために拭いてみたが、刻印は消えていて全く読むことができなかった。Pin4がVBAT+に直結、Pin11がVBAT-に直結されている。

LEDの周りはこんな回路になっている。



RED点灯時は2.22VでGND側の抵抗に350mVが、GREEN点灯時は2.85VでGND側の抵抗に60mVがかかっている。REDは6.8mA、GREENは1.2mA程度で点灯していることになる。LEDは550HzのPWMで調光され、最高輝度で99%、最低輝度で5%くらいだった。大抵のLEDは20mAくらいまで流せるだろうから、これもそれくらい流せばかなり高輝度になりそう。もっともチップ抵抗を交換するのはかなり面倒だろうけども。GND側の抵抗値を減らし、GREENの抵抗を増やせば、REDを高輝度化しつつ、GREENを低輝度にしてNV対応、みたいにできるかもしれない。それと、REDがGREENよりも電圧が低いのが気になる。どこかに100Ωくらいの抵抗が入ってるのかもしれない。

EoTechの高輝度化は、当面のところ抵抗のあたりをいじるだけで良さそうだ。それで足りないならLEDを20cdのモノに交換して電流も50mAくらい流してやれば相当に高輝度化されるだろう。バッテリーライフがものすごい短くなるだろうけど。

2016年2月3日水曜日

IR誘導ミサイルのレティクル

初期の赤外線誘導ミサイルは画像としては認識できず、赤外線を点として認識していた。しかし点では偶然に発見できる可能性は低いだろうし、発見できたとしてもすぐにロストしてしまうだろう。そのため実際のミサイルでは焦電型センサの前に扇風機の羽のようなレティクルを置くことで目標の位置を探している。

参照:http://homepage3.nifty.com/kubota01/navigation.htm <レティクル走査方式>

ということで、簡易的ながらどうなるのかを試してみた。といっても焦電型センサや羽を用意するのは大変なので、PCの中で。

今回使用したレティクルは以下の2個。

左と右は基本的に同じだが、右側には中央に半円の不透過、透過エリアが付いている。

以下がそのレティクルで見た目標(緑の丸)の大きさ。左側にレティクルの形状と目標の位置を、右側に見えている目標の大きさのグラフがある。大きさのグラフは縦が大きさ、横が時間で、右に行くほどレティクルが回転し、右端で2周分回転している、という状態。



上から、右側のレティクルで目標が中央、右側のレティクルで目標が中央からほんの少しずれてる、左側のレティクルで目標が視野外側、左側のレティクルで目標が視野の中心付近、となっている。3段目はレティクルの外側なので、中央部の切り欠きの有無は関係ない。
今回はレティクルは固定して、目標をレティクルの中心から同心円で移動した時の目標の大きさをグラフにした。
一番下のグラフはとりあえず無視しとくとして、3段では上に行くほどレティクルの中央よりとなる。ざっと見た感じ、中央に近づくほどピークが小さくなり、レティクルの全周で強度が変わらなくなるようだ。対して外側に目標がいる3段目では、目標の有無によるピークが鋭く出ており、レティクルが不透過の半円部分では目標は全く見えていない。
ということで目標の大きさのピークの形状はレティクルの中心からの距離に相関がありそうだということはわかった。次は目標の位置について。中心からの距離がわかっても、角度がわからないとどこに向かえばいいかがわからない。角度を知るためにはレティクルの半分が隠れているというのがポイント。3段目では2箇所、全くピークが見えないところがある、このピークが見えないところはレティクルの半円が不透過になっている部分に隠れている、と考えることができそうだ。つまりターゲットが長期間見えなくなった時のレティクルの角度と比較することにより、目標がどの方向にいるかがわかる。これで目標までの中心からの角度と、方向を把握することができそうだ。あとはシーカーをジンバルに乗せて、目標がシーカーの中央に来るように修正し、シーカーの角度がゼロになるようにミサイルを動かせば目標の方向に向かって飛ぶことが可能となる。

実際にミサイルに使うレティクルはもっと複雑な形状のようだが、とりあえず考え方はなんとなく分かった。焦電型センサなんて性能を無視すれば1個100円とかで買うことができるから、あとはレティクルを作る方法を考えればロウソクの位置を探す赤外線シーカーくらいは作ることができそうな気がする。レティクルはかなり小さく作る必要があるが、今なら精密な加工機があるからなんとかなるかもしれない。

OpenCvSharpでレンズ補正っぽいことをする

OpenCvでレンズ補正を行うプログラムをC#に移植してみた。といってもほとんど全く同じコードで動くわけだが。OpenCvSharpすぎょい。(ただし本気でSharpにするならいろいろ最適化できるが)

カメラはiBUFFALO マイク内蔵320万画素WEBカメラ F2.2ガラスレンズ搭載モデル ブ ラック BSW32KM03BKを使用した。

修正したサンプル 上が補正済み、下が未補正。


元画像がほとんど歪みのない画像なのであまり違いがわからない。Webカメラすぎょい。

チェッカーボードは本来印刷したりして使うんだろうが、プリンタが無いのでとりあえず画面に表示して代用した。



この画像は24インチの1920x1080液晶で表示することで1マスが25.0mmのROW9,COL18なチェッカーボードとして使用することができる。ROWとCOLはコマの数ではなく、交差しているところの数であることに注意。

補正情報を拾うための画像は適当にいろいろな角度や距離から撮影しておく。距離や向きに多様性がある方がいいと思うが、チェッカーボードが一部でも隠れていると解析に失敗してしまうので、すべての領域が撮影されている必要がある。

情報はXMLで書きだされ、今回はこんな感じになった。

<?xml version="1.0"?>
<opencv_storage>
<intrinsic type_id="opencv-matrix">
  <rows>3</rows>
  <cols>3</cols>
  <dt>f</dt>
  <data>
    1.04094995e+003 0. 6.19313538e+002 0. 1.15699170e+003
    3.98739349e+002 0. 0. 1.</data></intrinsic>
<rotation type_id="opencv-matrix">
  <rows>1</rows>
  <cols>3</cols>
  <dt>f</dt>
  <data>
    -2.04190898e+000 -2.19732761e+000 2.56176054e-001</data></rotation>
<translation type_id="opencv-matrix">
  <rows>1</rows>
  <cols>3</cols>
  <dt>f</dt>
  <data>
    -1.47931931e+002 -1.17953056e+002 6.39266296e+002</data></translation>
<distortion type_id="opencv-matrix">
  <rows>1</rows>
  <cols>4</cols>
  <dt>f</dt>
  <data>
    8.36658627e-002 -6.74404874e-002 -1.06694188e-003 -7.54280773e-005</data></distortion>
</opencv_storage>


さて、とりあえずオプティカルフローでカメラの動きを検出することができるようになった。それからレンズ歪みも補正できるようになった。あとはオプティカルフローでシェイクリダクションをできるようになれば、ウェアラブルカメラの補正とかができて楽しいかな。


2016年2月2日火曜日

OpenCv(Sharp)でオプティカルフロー



OpenCvSharpでオプティカルフローを行ってみた。ソースコードは"実践OpenCV 2.4―映像処理&解析"のオプティカルフロー、178ページのC++のコードをほぼそのまま使用している。
サンプルには検出しやすそうなキーボードを使ってみた。キーボードのバックライトで表示された文字もちゃんと文字として認識できるのが面白い。
それとオリジナルの処理として画像の下側に移動の長さの量を表示している。上の画像は平行移動しているので鋭いスペクトルが出ている。ということで出現回数が多い移動を平均すれば移動方向が把握できる。と思ったのだけど、流石にそんな簡単じゃない。



上の画像は平行移動ではなく、カメラを回転させたサンプル。回転中心が移動量最小で、中心から離れる程に移動量が多くなる。なので鋭いスペクトルは出ず、様々な長さの移動が検出される。
とりあえずシェイクリダクションでもやってみようかと思っていたけど、かなり大変のようだ。とりあえずオプティカルフローで遊ぶという目的は達成したけど、もうちょっといろいろ調べてみよう。