2017年7月31日月曜日

Cの関数に多次元配列

 * 関数
static void hogeFunc(int y, int x, int arr[y][x])
{
    int i, j;

    printf("arr[%d][%d]\n", y, x);

    for (i = 0; i < y; i++)
    {
        for (j = 0; j < x; j++)
        {
            printf("%d ", arr[i][j]);
        }

        printf("\n");
    }

    printf("****\n");
}

 * 呼び出し
int arr[2][4] =
    {
        {
            1, 2, 3, 4,
        },
        {
            5, 6, 7, 8,
        },
    };
hogeFunc(sizeof(arr) / sizeof(arr[0]), sizeof(arr[0]) / sizeof(arr[0][0]), arr);

 * 結果
arr[2][4]
1 2 3 4
5 6 7 8


C言語の引数に多次元配列を渡す - Qiita
BohYoh.com-C/C++ FAQ 2次元配列の要素数を取得するにはどうすればよいですか。

 関数呼び出しでsizeofが多くて面倒な気はする。あと呼び出し先関数でsizeofを使うとうまく動かない(配列じゃなくてポインタ扱い?)。
 この書き方はC99以降だそうだ。WSLのarm-none-eabi-gccの4.xだとgnu99を指定してコンパイルできる。
 組み込み界隈で本当に可変長の多次元配列が必用なのかという話は置いておいて。。。

2017年7月30日日曜日

フルカラー7セグLED

 秋月で売ってるフルカラー7セグメントLEDで遊んでみました。
 モノとしては、WS2812Bを内蔵した7+1セグメントLEDです。数字部の7セグに加え、右下にドットがあり、計8セグメントです。
 一般的に、7セグメントLEDを駆動するには、8chや16chといったLEDドライバを使用します。これにより、7セグLED1個を駆動できますが、複数個の7セグLEDを並べたい場合、例えば時計なら少なくとも4個、年月日も含めれば12個ですが、それだけの数を表示する場合、いくつかの方法があります。1つは、1個のドライバを使用し、複数のLEDを逐次切り替えて表示するという方法。もう1つは、7セグLED1個に対して1個のドライバを使用するという方法です。前者は比較的配線が少なくてよく、消費電流も比較的少なくて済みます。代わりに7セグLEDの輝度は低くなります。対して後者は、LEDの輝度を高くできますが、配線が多く、コストも高くなります。どちらにしろ、配線数は膨大になります。
 WS2812B内蔵7セグLEDの場合、電源の2本とシリアルバスの1本の計3本の配線があれば、任意個数の7セグLEDを表示することができます。今回試した限りでは、十分な輝度があり、表現性もかなり高いと感じました。
 一般的な7セグLEDは、輝度を変えるのは不可能ではありませんが、色を変えるのはかなり難しいです。一方、シリアルバスLEDの場合は24bitで色を指定できますから、自由に色を表現できます。もちろん輝度も自由です。
 ただし、2個で全点灯3.5W程度消費すること、全点灯だとそれなりに発熱すること、といった問題があります。また、単価がかなり高いのも問題でしょうか。値段については、複数個のLEDを並べた際の地獄のような配線作業を考えれば、4個程度までなら耐えられるでしょうか。それ以上になると地獄の配線作業のほうが安いような。。。

 7セグでも充分に表現力がありますが、理想を言えば16+2セグくらい有ると良いかな、という気がします。16セグあればアルファベットの表示も可能ですし、シリアルバスの利点も効いてきます。でも凄まじい値段になるんだろうなぁ。







 最後の1枚は輝度255,255,255の設定。それ以外は0以上32未満の乱数で設定。最大輝度だと明るすぎて撮影には不向き。

 他のWS2812Bを使ったモジュールと同様、FT232(Inv)から制御することができます。PCに接続してCPU使用率を表示して、使用率が低い時は緑、高い時は赤に近い色とか、数字でCPU使用率、色でCPU温度、とか、いろいろと表示ができると思います。
 もちろん複数個並べてワールドクロックとかもできますが、7セグLEDが帯に短したすきに長しな大きさで、時計に使うには小さいかもしれません。枕元に置く時計くらいの大きさでしょうか。少なくとも壁掛けの大きさではありません。

2017年7月22日土曜日

STM32F4で1Wire

 STM32F4で1Wireの温度センサを使ってみた。

 例によってロジアナキャプチャ。







 上から、全景、AD変化開始付近、データ読み出し付近、全景、ADC変換開始付近、データ読み出し付近。最初の3枚はロジアナ、残りの3枚はオシロ。

 ZEROPLUS LAP-Cは最近になってプロトコル解析が全て無料で行えるようになった。1Wireも含まれているので、データ転送を見るだけなら便利。ただしLAP-CではSEARCH ROM COMMANDの、アドレスツリー探索は正常にデコードできない。まぁアドレスツリー探索は例外的な動作ということで、脳内デバッグをすれば。とても面倒だけど。
 あと、LAP-Cの1Wire解析はデフォルトでMSBファーストとなっている。1WireはLSBファーストな仕様なので、ちゃんと設定しておくこと。

 1Wireはだいぶ前にFT232で温度センサを試したことが有る。1Wire通信だけなら問題ないが、パラサイトパワーではAD変換時にストロングプルアップ機能が必要になり、FT232ではこれを実現できないので、あんまり作り込んでいなかった。

 今回はSTM32F4のUART4を使用して1Wire通信を行っている。手持ちのセンサはパラサイトパワーのタイプなので、ストロングプルアップが必用。
 UART4はAF_ODで初期化するが、AD変換コマンドを送信後にOUT_PPに変更する。予めOutputはSetしてあるので、OUT_PPにすればマイコンからおよそ20mA(66mW)程度の電力を取り出すことができる。DS18B20のAD変換/EEPROM書き込み時の電流はtyp1mA max1.5mA @5Vとのことなので、マイコンからの出力でも問題ない。はず。
 本来はオープンエミッタ、あるいはオープンソースのようなピンモードがあれば楽なのだが、STM32F4にはそういう機能はない。ぐぐってもそういう使い方はないようだ。大体オープンコレクタ・オープンドレインで事足りるもんね。
 
 今回はDQを3.3Vに4.7kOhmで釣り上げ、20kOhmでGNDに落として、約2.7Vになっている。またストロングプルアップの時は3.3Vに短絡状態となるため、3.3Vになる。
 実際、オシロの波形ではAD変換中は3.3V、それ以外は2.6V程度となっている。
 ちなみにDS18B20の動作範囲は3.0-5.5Vなので、仕様どおりに使いたいなら分圧抵抗は外す必要がある。とりあえずストロングプルアップの動作確認に一時的に装着してるということで。

 1Wireはかなりアナログ寄りなデジタル通信なので、オシロとかあると便利。ロジアナも有ったほうがわかりやすいけど。
 アナログ寄りのデジタル通信というと、I2Cがあるが、それよりもさらにアナログ寄りだと思う。I2Cはクロックストレッチは有るが大抵のデバイスは必要ないし、クロックストレッチだってロジアナである程度把握することができるはず。ストロングプルアップを分圧抵抗で見ようとするとオシロスコープが必須。まぁ、I2Cのレベル変換ICとかはインピーダンスで自分の信号かほかデバイスの信号かを切り分けてるから、そのあたりは超アナログだけど、少なくともセンサをちょっと使いたいくらいなら気にする必要ないし。

 1Wireの通信は、今回はリセットパルスの生成に18.75kbaud、送信に125kbaud、受信に180kbaudを使っている。
 送信時は、0を出す時は0x00、1を出す時は0xFFを送る。受信時は0xFFを送り、0xFF以外なら0、0xFFなら1と認識する。
 リセットパルスは0x00を送信し、2バイトを受信できればデバイス有り、1バイトしか受信できなければデバイスなし、1バイトも受信できなければハードウェアに不具合がある。不具合の種類は1) 送信の問題、2) 受信の問題、3) 送受信間の接続の問題、等が考えられる。だいたいCANバスの自己診断に近い感じ。

 この通信方法では1Wireの1bitを送るのに、TTL232の10bitを送る必要がある。送信は12.5kbit/sec、受信は18kbit/secくらいの速度になる。
 デバイスの指定に64bitが必要だし、コマンドを送るのにも8bitが必用。データの読み出しの場合はさらに72bitが必要になる。AD変換開始コマンドを送るには約6ミリ秒、データの受信には約10ミリ秒がかかる。ただしDMAやNVICを使えるので、CPU負荷はあまり大きくない。
 すべてソフトウェアで作るとなると数マイクロ秒の精度で制御する必要があるので、ソフトウェアで回す必要があるし、割り込みを禁止したりとかする必要もあるだろうから、かなり厳しいと思う。その点、UARTモジュールを使うのは理にかなったやり方だと思う。


 ということで、STM32で1Wireを使ってみたよ、という話でした。
 今のところ、手持ちのデバイスがDS18B20が1個しか無いので、あんまり1Wireらしくないけど。もうしばらくしたら秋月でいくつか買って、多点温度計測をやってみたいなーと思う次第。

 ちなみに現在の室温は30.5±0.5℃くらいらしい。今日は曇ってるので日照は強くないけど、暑いことに変わりはない。



2017年7月21日金曜日

エレキットのタッチセンサ

 エレキットのタッチセンサを買ってみた。


 ↑コレは手持ちの部品でだいぶ改造してるけども。

 大雑把に説明すると、PIC12F1822のタッチセンサ機能を使ったモジュール。ピンアサインとかはamazonカスタマーレビューに書いてあるので省略。
 PIC使う人ならコレ単体でもコードを書き換えていろいろ遊べると思う。

 電圧範囲は3-5V。PIC自体は1.8Vから動作するけど、このモジュールは3Vからなので注意。
 ジャンパピンを開放すればモーメンタリスイッチ、短絡すればオルタネートスイッチとして動作する。モード切替は起動中でも変更できる。
 タッチスイッチは一瞬触れた程度では反応しない。短い一呼吸程度、気持ち程度のディレイが必用。

 タッチセンサのパッドはミシン目で切り離せる。ワイヤで延長するためのパッドもあるので、ちょっとした距離なら延長できる。

 短時間触れて遊ぶ程度なら誤動作とかは特に無い。
 10個とか15個とか並べればキーパッドを作れると思う。凄まじい値段になると思うけど。
 電源スイッチ1個だけとか、せいぜい2,3個程度までのモノを作るのに使えば良いんじゃないかな。

 タッチセンサーキットの基板はかなり単純なパターン。必用とあらばテキトーなユニ基板とか、空中配線とかでも使えると思う。ここまで来るとプログラム書き込み済みのPIC単体を売ってくれとか、そういう話になってきてしまうけども。

 僕の使いたいものは、電池駆動でタッチセンサを使って起動するみたいなモノだけど、自分で電源を切ったりもできるようなのがいい。
 ということはLDOとかでタッチセンサを駆動して、モーメンタリの出力でメインのDCDCのENを駆動、DCDCの出力を使ってENを自己保持、マイコンからbreak、みたいな感じになるのかな。
 このあたりはいろいろ試す必要があるだろうが。 




#if 0
 今更だけど、4月期のアニメを見始めた。1話だけみて面白そうだと思って録画してたんだけど、結局2話以降全然見てなかった。2クールやるらしいのでまだ放送中。だいぶいい感じだ。でも僕がこういう好みのベクトルのやつ見始めると終盤ろくなことがないからなぁ。

 最近いろんなアニメの再放送をやってる。SAOとか、涼宮ハルヒの憂鬱とか。この際にと録画してるけど、HDDの空き容量がやばい。
 DIGA買った時は1TBあれば充分とか思ってたけど、あっという間に埋まってしまった。外付けの3TBを買って今度こそ安心!と思ったらこの世代のDIGAは外付けHDDに1k本までしか録画できない仕様(当時の型落ちで安いやつを買ったけど、現行モデルはもうちょっと緩和されてる、はず)。

 そう言えばナイツ&マジックのアニメ化も見てる。Web版で途中まで読んでたけど、途中までしか読んでないってことは、微妙に僕の好みと違ってたんだろうなぁ。
 オーディオコメンタリーで「ロボットに乗るかどうかを葛藤するアニメはよくあるが、自分から乗るような作品は少ない」みたいな話をしてた。さもありなん。
 アルドノア・ゼロは進んで乗ってた気がする。まぁ上官が葛藤してたが。でもA/Zはロボットが好きだから乗る、じゃなくて、最適解がロボットだからそれを使う、みたいな感じかも。
 カタフラクトくらいの地上にへばりついたロボットは好きかな。ガスタービンエンジンで発電?して走り回るってのもエネルギー的に無理がなくて良さそう。人形で空を飛んだりしちゃうとちょっと僕の想像の埒外でつらいかんじ。
 そう言えばカタフラクトは空を飛ばないんだよな。ちょーっと長い距離を跳ねたりとか、パラシュートで降下したりはするけど。あと宇宙に行くけど。地上を歩き回ってる限りならはいふり縛りでもできそうだ。はいふり世界にカタフラクト出して何に使うかって問題は有るけど。はいふり世界にも揚陸艦ってあるのかな。海岸から侵攻とかしない世界だと揚陸艦はなさそう。でも水害が多い地域だと救難その他で使えそうだし、海面とか地盤とか動いて沈み込むような世界なら揚陸艦は発展するかも。ならブルーマーメイドが操艦する揚陸艦でカタフラクトがを輸送するみたいな妄想も……
#endif

17042

 夜空に最も明るい星が新たに誕生? - その正体はロシアの宇宙灯台「Mayak」 | マイナビニュース

 こんなのが打ち上がってたんですねぇ。

 毎度のJS Orbitリンク

 同時に投入された物体が70個以上あり、一部は未確定です。おそらく、名前が出た後も正しいラベリングになるには相当時間がかかると思います。

 件の衛星の名前はMayak(マヤーク)だそうです。まだそれらしい名前は軌道情報にはありません。


 打ち上げられてからそれなりの日数が経っているため、かなり散らばってしまっています。真っ先に展開に成功していれば、一番先頭にいるのがMayakでしょうが、展開がトラブっててまだ展開してから時間が経っていない、とかであれば中途半端な位置にいる可能性が高いです。
 ある程度時間が経てば、軌道半径の経過からMayakを特定することは可能でしょう。実際、膜展開を行ったFREEDOMというキューブサットは、同時期に投入された他のキューブサットと比べ、明らかに落下が早かったです。
 でもまぁファーストライトの観測を目指すなら、そんな悠長な事はしてられませんから、総当たりで行くしか無いかもしれません。


 僕がやるならベランダにα7s放置で30分くらい撮影かなぁ。本当にVmag-10になるなら比較明合成をすれば一発でわかるはずですし、そこにいるのがわかれば30分の動画を見れば済むことですから。
 でも家のあたりは来週中頃まで曇りとか雨の予報ですから、しばらくは静観ということで。


 軌道高度は約600kmのほぼ円軌道ですから、日照条件はISSよりはマシだと思います。地上がある程度暗く、かつ軌道上は日照状態、となる時間が、ISSよりも長いはずです。ということは、ISSの肉眼観測よりは観測可能ウインドウが広いはずです。

 しかし、日本上空で地上が暗く、上空が日照という条件は、少なくとも半月ほどはかなり厳しい感じです。


 地上が暗く衛星が日照になるのは、日本では北海道の北端付近しかありません。今後半月ほどはこの調子のようです。
 北米大陸や南米大陸はかなり条件が良さそうです。

 とはいえ、衛星の反射膜の素材によって、輝点が見える範囲も変わるはずです。乱反射するような素材であれば広範囲で暗く見えるし、綺麗に反射する素材であれば狭い範囲で明るく見えるはずです。イリジウムよりも明るいということは、可視範囲はかなり狭いはずです。また反射膜の写真を見ると、アルミホイルみたいな感じですから、反射光はかなり狭い範囲にしか届かないと思われます。
 望遠鏡で追尾すれば乱反射成分でも見えるかもしれませんが、衛星を追尾でき、かつ暗い目標でも見える望遠鏡となると数が限られますし、候補が70個以上ありますから、1個1個調べるだけでも一苦労だと思います。


 とりあえず、数日で落ちてくるような衛星ではないでしょうから、もうちょっと様子を見てみましょう。


追記:2017/07/23

 2017-42で打ち上がった物体の軌道半径をプロットしたグラフ。中央に1個物体が有り、上下に2組有る。実際に軌道を地図にプロットしてみると、中間に物体が1個あり、前後に物体が有る。
 少なくとも5日程度のプロットで目に見えて高度が下がってる物体はない感じ。
 それにしてもこんな軌道にどうやって投入したんだろうか。軌道進行方向側に放り投げた物体と、後方側に放り投げた物体の違いなのかな。

 このグラフを作るのに、自前のTLEデータを捜索するプログラムと、エクセルのファイルを2個、使っている。
 TLEデータは過去1年分ほどのTLEファイルがあるが、テキストファイルで350MB、2万5千ファイルくらいある。コレだけのファイルを全部開いてチェックするとなると、アンチウイルスソフトのチェックのほうがボトルネックになってる感じ。
 エクセルの方は1つめが26MBほど、2つめが73MBくらいある。開くのにはちょっと時間かかるが、まぁほっとけばちゃんと表示できるし。

 今日は今のところ晴れてる。けどウチの上空を通るパスは23時頃か。どっちにしろ日照条件が悪いけども。ISS放出なら少なくともISSは写るだろうけど、ロケット放出だとそれもないからなぁ。
 そう言えば今回のロケットの上段ってどれくらいの規模なんだろうか。少なくともキューブサットよりは遥かにデカいだろうし、高感度で撮影しておけば映り込むかも。
 件のキューブサットとの切り分けが面倒そうだねぇ。こっちは理想条件ならvmag-10とからしいけど、そんな明るさはめったに出ないだろうし。

2017年7月17日月曜日

LEDストリング

 WS2812BというLEDチップを内蔵した、テープ状のLEDストリングを買ってみた。以前にも同じチップを内蔵した物を試したが、その時はマイコンのGPIOで操作していた。
 今回はマイコンのプログラムを書くのが面倒だったので、FT232とC#で制御してみた。FT232H(高速品)が必要かと思ったが、昔からあるチップでも制御できた。ただしTTL RS232は負論理のため、WS2812Bの正論理の信号を作れない。
 NOT回路を作ろうかと思ったが、ちょうどいいFETの手持ちがなく、手持ちのトランジスタでは6MHzの矩形波は通らないので、FT progでFT232の論理を反転させた。
 ボーレートは最大の3Mbaudに設定し、1バイトで2bitを送信するタイミングで信号を送信した。本来のタイミングからはそれなりに逸脱しているが、WS2812Bはかなり信号幅に余裕がようで、とりあえず動作確認程度に制御するなら問題なさそう。

 今回試したストリングは1mあたり60個のチップが実装されており、1.66...cmピッチとなる。
 5m(300個)で非点灯時の消費電流が約0.12A(4V時)、20個点灯させて0.9A(4V時)くらいだった。静止電流が0.4mA/個/4V、点灯時に40mA/個/4Vくらいかな。
 5m全体を点灯させると12Aくらいになる。50Wくらい。そんなに流せる電源は持ってない。手持ちの電源だと最大でも80個くらいしか表示させられない。電圧範囲は5Vくらいまで有るが、5Vで動作させるなら100Wクラスの電源が必用かも。
 とはいえ今回買ったLEDストリングの電源ラインはめっちゃ細いので、連続で10A流すのは無理だと思う。せいぜい1mで分割してそれぞれ電源を接続する感じかなぁ。電線を太いのに交換することも可能だろうが、そもそもフレキ基板の細いパターンだから数Aが限界じゃないかな。
 1mだと2.5Aくらいなので、6Aまで流せるPOL降圧DCDCを使えば2m分を駆動できそうだ。降圧DCDCを通すならLiPoやNiMHのような不安定な電源でも問題ないかも。いろいろ遊べそうだ。


2017年7月16日日曜日

メモ:MacBook Pro (13-inch, Early 2011)で外部液晶が表示されない

 MacBook Pro (13-inch, Early 2011)で外部液晶を使用しようとしたところ、表示されなくなった。症状は、外部液晶を接続したところ、内蔵モニタのバックライトが消え、外部液晶の信号入力もない。つまりすべてのディスプレイが無信号状態。
 数日前には別の液晶を使っていたので、ここ数日で壊れたとかでもない限りは問題ないはずなのだが。
 液晶の問題かと思って型番でググっても特にクレームとかは見つからなかった、ということでPC側を疑う。

 結局、BootCampで入れたWin7に入ってるIntel Graphicsの関係だったっぽい。

 設定方法としては、タスクバーのアイコンでインテルHDグラフィックスのアイコンをクリックして、”グラフィックプロパテイ”を選択。
 ”インテル(R)グラフィック/メディア・コントロール・パネル”で”詳細設定モード”を選択し”OK”をクリック。
 左側の”オプションとサポート”で”ホットキーマネージャー”から”内蔵ディスプレイの有効化”のキーを確認する。デフォルトではCtrl-Alt-F3だが、MBPではFキーが使えないのでテキトーなキーを割り当てた。
 そして外部液晶を接続する。まだ何も対策をしていないので、内蔵ディスプレイも外部ディプレイも沈黙する。その時点で先程の”内蔵ディスプレイの有効化”キーを押す。そうすると内蔵ディスプレイの表示が復活する。
 あとはWin-Pを押して、外部ディスプレイのモード(切断・複製・拡張・外部のみ)を選択する。
 最後にホットキーの設定画面で”デフォルトの復元”をクリックしてキーコンフィグを戻す。


 運良く短時間で解決することができた。どうして外部液晶接続時に内部・外部両方共OFFになる設定になったのかは分からないが。

 それにしても、このノートPCも6年以上使ってるのかぁ。いや、特に不満とかないんだけど。
 次はTOUGHBOOKとかほしいなぁ。トカイッテミル

VL53L0X

 VL53L0Xというセンサを試してみた。
 STMicro製で、ToF(Time of Flight)というタイプの距離センサ。ざっくり説明すると、超音波距離計の光波バージョン。
 以前にSTMが似たセンサを出していたが、そっちはレンジがかなり狭かった。VL53L0Xでは最大2m程度までレンジングできるらしい。



 テスト環境。STBee F4miniの上にVL53L0X変換基板を載せてる。穴位置がかなりちょうどいい。センサ本体はかなり小型だけど、付加回路がいろいろ必用だったりコネクタが大きかったりで、結局DIP16の変換基板くらいの規模。

上からIRで撮影。さすがにレーザーなので明るい。焼付きが怖いので真上からは撮影しなかった。

ちょっと斜めから撮影。すぐ見えなくなる。

中央右下にセンサ、左上に手のひら。距離は5-10cmくらい? これくらいの距離ならIRで照らされてるのがわかるけど、指向性が低いのでちょっと離れればすぐわからなくなる。


 このセンサはSTMicro製でありながら、わかりやすいデータシートというのが一切ない。曰く「わかりやすいAPIを用意したからそっちを使ってね」ということらしいが、僕が試した限りではAPIは初期化でコケて動作しなかった。
 今回はサードパーティのArduinoライブラリをC言語で書き換えて移植した。一応測距はできるし、距離に応じて値も変化するが、精度はあんまり出ていない感じ。
 結局本家APIを動くようにする必要がありそうな気がする。メンドクサイ。


 センサ自体は0.94umの赤外線レーザーで、データシートにもeye safeとか書いてあるが、0.94umは網膜に結構吸収されるらしいので、あんまり直視しないほうが良いと思う。と言っても非可視光だから、レーザーが目に入っても全く気が付かないのだが。


 なつやすみのじゆうこうさく でVL53L0Xを使いたかったのだが、結構大変そうだ。本当に夏の間に終わるんだろうか。下手したら来年の夏とかになってしまうんじゃなかろうか。。。


追記:2017/07/19
 APIに付属するLinuxDriverMassMarket_1.0.6/kerner/drivers/input/misc/vl53L0X以下のソースを使ったらいちおうレンジングできた。移植するのがとっても、とっても!面倒くさいけど。

 あとLinuxってCCI(Camera Control Interface)にVL53L0Xを突っ込んで動作確認できるみたい。映像出力端子にもI2Cバスは出てるけど、こっちは標準化以外の信号は通すの大変なのかも。カメラインターフェースならメーカー独自機能とかを実装する余地があるとか? とにかく、Winみたいな、外部にマイコンを置いて、それ経由でI2Cを叩いて、みたいな七面倒臭いことはしなくていいらしい。
 それなら最初からマイコンで動くコードを公開しておけよ、という気もするけど。せいぜいI2C R/W回りの関数2個を書き換えれば移植できるだろうから、いちいちプラットフォームに依存した変なサンプルとか作らなくても良いはずなんだが。


追記:2017/07/20

 I2Cバスのパケットをキャプチャ。I2Cは200kbaud。立ち上げに250msecかかっており、1回のデータ転送にも35msecほどかかっている。とにかく1回のデータ転送でのパケット転送量が多い。

 あとLongRangeモードのExampleを試してみた。屋内でたぶん2mくらいまで計測できてるんじゃないかなぁ。だいたい150cmくらいは取れてるし、手のひらをかざせばそれに応じて結果も変化する。ただ精度は不明。

 今回の用途だともうちょっと狭角のほうが使いやすいんだけど、センサの本来の用途としてはこれくらいの角度が良いんだろうなぁ。
 データシートのApplicationsにUser detection for Personal Computers/Laptops/Tabletsとか書いてあって、顔の真正面からレーザーをガンガン浴びせるつもりでいてちょっとアレ。いくらアイセーフ(?)とは言えさぁ。
 でもVL53L0Xはレンジング中以外はレーザーを止めるので、人間がいない時は照射間隔を100msecとか500msecで応答性重視、近くに人間がいそうであれば5000msec周期くらいで照射間隔を広げて、みたいな安全策はできるかも。どこまで効果あるのか走らんけど。
 はっ、このレーザーを浴びれば虹彩の色が抜けて…?


 とにかく、VL53L0Xは使用コストがかなり高そうだ。特に30msec周期近い高レートで測距を行う場合、I2Cバスはほぼ100%近くの使用率になる。当然ポーリングで通信を書いているとCPU使用率も同程度になる。
 I2Cバスに他のセンサをつけたり、VL53L0Xを複数個使おうとすると、相当面倒なことになりそうだ。高レートで2-4個使いたいと思ってたんだけどなぁ。I2C転送中も大抵は1バイト単位での転送だから、DMAとか使ってもほとんどCPU使用率は変わらなそう。1バイトの転送はせいぜい数十usecだから、割り込みとか使ってもOSのオーバーヘッドであんまり効果なさそう。

2017年7月8日土曜日

OpenCvSharpのVideoWriter覚書

 OpenCvSharp2のVideoWriterでファイルを書き出す際の注意点とか。

 VideoWriter.WriteではMat形式の画像を受け取るので、Matで渡す必要がある。OpenCVで画像をいじるだけなら問題ないが、C#のGraphicsで図形を書いたりしようとすると、System.Drawing.Imageから変換する必要がある。
 OpenCvSharp.Extensions.BitmapConverterでToMatやToBitmapがあるが、なぜかToMatで変換した画像をVideoWriter.Writeに渡しても保存されなかった。
 適当なファイルにImage.Saveで保存し、new Matで開いても良いのだが、ディスクアクセスは極力避けるべきであり、工夫する必要がある。
 とりあえず、MemoryStreamを作成し、Image.SaveでStreamを指定、その後Mat.FromStreamでStreamを読み込み、という手順で変換することができ、動画として正常に保存できる。また、逆の方法でMatからImageにすることもできるはず。とはいえ、OpenCvSharp.Extensions.BitmapConverter.ToBitmapでSystem.Drawing.Bitmapに変換してSystem.Drawing.Graphics.FromImageに渡すのは問題ないから、Mat→BitmapはToBitmapで問題ないと思う。


 動画ファイルはAVIやMP4でも大体ヘッダにS32bitとかでファイルサイズが書いてあり、2GB(or4GB?)を超えるファイルは作成できない。しかしFHDのMJPGとかだと数分で2GBを超えてしまう。
 とりあえず、VideoWriter.Write後にFileInfo.Lengthでファイルサイズを確認し、閾値を超えるようであれば新たな動画ファイルを作成する、というクラスを作ってみた。たぶんうまく動いてると思う。


 いつぞやの、OpenCvSharpのオプティカルフローで手ブレ補正に再挑戦してる。まだ上下左右の2軸しか補正してないが、かなり見やすくなる。ブレ補正は米軍のドローンでよく使われてるタイプの補正方法。
 本来は回転方向のブレも修正すれば見やすくなるのであろうが、なかなかうまくいかない。特徴点から回転を検出するのはスタートラッカで作ったので、その応用で簡単に作れそうだなと思ったんだけど、そうは問屋がおろさない。コマッタ。

2017年7月4日火曜日

上富良野駐屯地62周年行事

 地元駐屯地の行事に行ってきた。2017年7月2日開催。
 去年は行ってないので2年ぶり。おおよそ例年通りだと思うけど、第14施設群が新設されたこと、習志野から第1空挺団が展示に来ていたこと、といった違いが有る。細かいところを挙げると、2年前までは有った小火器や無反動砲の展示がなくなっていた。


92式地雷原処理車のライト。右上カドの天守閣みたいなのが箱型ランチャーと本体をつなぐ蛇腹部分。

10式戦車左側後方から砲塔壁面の荷物入れとかセンサとか。荷物入れというかスペースドアーマー。中段右側の3個並んだ窓がセンサー部。その上の丸い円筒がアンテナの基部。

10式戦車のバックカメラ。

バックカメラの部分を拡大したもの。かなり頑丈な雰囲気。

砲塔壁面のセンサの拡大(4箇所の内どこかは忘れた)。防衛装備品で基板やら電子部品やらむき出しってのはあんまりない気がするので面白い。画素むき出しだけどどういう光学系になってるんだろうね。部品はあんまり微細化されてない感じ。

履帯の拡大。ピンぼけしててわかりづらいけど、右側の突起が若干削れてる。

フロントカメラ部分。

観閲式・訓練展示等の放送席? アンテナがいっぱい生えたトラックとか。 駐屯地内ではマンパックの無線機を背負った隊員をよく見かけた。駐屯地内でしか通信しないだろうからもっと小型でも良いと思うんだけど、特小じゃ厳しいだろうし、となるとマンパックのHFとかになるのかな。単体で背負える利点は大きそう。

後ろの黄色いリボンは吹き流し。感度はかなり高い。

こちらも風向を調べるためと思われる風船。等間隔に並んでるのは、上空から見て風船の間隔で傾き具合がわかるように?

風船の右下。風向風速計とかいろいろ。

観閲式の始まり。

結構風強そうだけど、体感ではほとんど無風だったと思う。

空挺降下の展示。3人がスクウェアでフリーフォール。いきなり空中に人が現れたり、しばらくそのまま浮かんでたり、と思えばパラシュートを開いたり、Arma3のパラシュートModと全く同じ雰囲気だった。

パラシュートの前側↑、後ろ側↓。


3人中2人はグラウンドに着地、最後の1人は目の前の道路に着地。

パラシュート回収して集合。

空挺降下が終わると吹き流しは回収。

 








↑ここから5枚ほど、新設された第14施設群の地面をえぐる(orえぐっちゃう)系の装備品。





10式戦車に旭日旗、 96式装輪装甲車に町の町章。

90式戦車と、その後ろに10式戦車 。そう言えば74式はいなかった。


演習展示の開始。

敵役は相変わらずの74式。

偵察にUH-1。3年前はOH-6だったはず。2年前はちょうどOH-6の飛行停止期間で、UH-1のラペリング降下をやった気がする。

82式指揮通信車がM2で空砲射撃。2両いたけど、片方は不発が多かったみたい。



発砲とか、大きな音がする際は隊員が警棒を持ち上げて教えてくれる。といっても、来賓席の前にしかいないので、端の方にいると気が付かない。








203mm自走榴弾砲と、右側にいるのが地雷原処理車。マインスイーパーは今年新設された部隊のもの。

↑投擲する前。
 ↓投擲した瞬間。
  演出用のスモークグレネードやスタングレネード?を偽装網の中から投げ投げ込んでる。


右2両が90式、左2両が10式、兄弟というか親子というか。後ろの方には指揮通信車も。

手前の10式と奥の90式。 見分け方は、笑窪が有る方が10式。


ある程度制圧できたら普通科が射撃。




敵に見立てたターゲットプレートの方まで走り込んで、そのまま窪地にフェードアウト。
 敵陣を制圧して、演習展示は終了。

雨に打たれる10式。

10式の車輪止め。

軽装甲機動車の窓。

グラウンドの隅にある吹き流し。グラウンドの真ん中にはヘリパッドがある。

上富良野駐屯地のカレーは美味しいらしい。「美味しいらしい」という噂はちらほら聞こえてくるけど、「美味しい」という話はあんまり聞かない。気がする。今年はじめて食べた。たぶん美味しかった。

入り口から進んで向かって右側に手前から203mmの弾薬輸送車、203mm自走榴弾砲、MLRS、88式地対艦誘導弾、マインスイーパー、という感じ。
 左側には軽装甲機動車や90式戦車、10式戦車が置いてあり、他にNVの体験や災害救助用の装備が展示してある。ここにも74式戦車はなかった。

軽装甲機動車の 前輪回り。

203mmに乗ってる消化器。基本的に密閉空間(車内等)は粉末型、開放空間はCO2型が搭載されてる(気がする)。

  小型のボートがたくさん積んであった。

戦車の体験搭乗。といっても車体後部のかごに座るだけだが。 結構人が並んでたので今回は乗らなかった。



 ということで写真は一通り終了。

 開始直後あたりは全天が曇ってる感じ。第1空挺団の人と話してても「空挺降下はたぶんできると思うんですけどね~」みたいな感じだった。
 空挺降下が終わって、演習展示が始まった後くらいからポツポツと雨が降り始めて、一時はちょっと強く降ってた。でも演習展示が終わった後はあんまり降ってなかったと思う。曇りで直射日光はなかったので、そんなに暑くなく、過ごしやすいという感じの天気だった。
 降下は「最低高度の1000mから」と言っていた。説明には最低高度は600mあたりと書いてあったけど、平時と戦時や訓練時の基準は違うんであろう。
 降下時はUH-1が若干雲に入ってるように見えたので、もう少し雲底が低かったら中止になってたかも?あるいは雲底付近まで高度を上げた可能性もあるけど。


当日のGPSログ。だいたい歩いたとおりに記録されてる。中央左上寄りのグラウンドが出店の会場。西側から南に出たところが車両の展示。さらに南に下って広い土面が演習展示の会場で、その北側が観客席。

 普段僕はForetrex 401で時間しか表示してないので、大抵の人には腕時計だと思われるんだけど、第1空挺団の人はひと目見てGPSとわかったらしい。さすが精鋭無比の第1空挺団。
 でも彼らは米軍と共同訓練とかすると、大抵の米軍空挺とかはForetrexつけてる気がするし、そういうので見慣れてるのかも。あるいは自分たちも使ってるのかな。そこまでは聞かなかった。

 ちらっと話を聞いた限りでは、空路で潜入した場合は、パラシュートは各自必要な分を切り取って、あとは放置らしい。もちろん訓練の時は回収するけど。
 各自必要な分というのは、ロープとしてのパラコードだったり、防寒としての布部分だったり。マンハントでジョエルがアリゾナでやったような感じ。


 今回はImpact Sport(電子イヤマフ)を持参してみた。203mmの空砲とかでも、耳に痛いような音ではないし、大きな音が消えればちゃんと回りの音も聞こえるので、2年前のSurefire EP4とくらべて状況認識は改善したと思う。とはいえアナウンスの低音量はそのままで、電子イヤマフとはいえSNRは改善できないので、EP4でも十分かなーという感じ。


 北海道防衛局のブースではいろいろお土産をくれた。といってもペラペラからかなりの厚さまでのパンフレットや、ボールペンくらいだけども。自衛隊以上に影の薄い組織っぽいので、アウトリーチに苦労してそう。

 第1空挺団の人はかなり気さくな感じで話しやすかった。上富良野駐屯地の展示は話しやすい人もいれば話しづらい人も色々。やはりコミュ力高そうな人が対応してくれると色々話せるので楽しい。そもそもこっち側のコミュ力が足りないだけじゃないかという気もするけど。


 ということで今回はここまで。