小ネタ

 

　THERMOSのマグカップ、底面形状があんまり良くなくて、エネルギー発散が悪い。内容物の液滴が顔に跳ね返ってくる。底部に小さい角Rが無いので洗うときは便利なんだけど、飲むときは不便。

　一時期多発していた、Windowsのインデックス作成の暴走現象、最近は全く発生していない。再現させて確認したわけじゃないので確定ではないけど、Visual Studioとの相性問題っぽい。インデックスが暴走するときはたいていVisual Studioでプロジェクトを作成したあとだったし、インデックスの対象からreposを外して以降は暴走していない。

　ドキュメントとか書かず行き当たりばったりでコードを書くタイプの人間なので、コード内の文字列とかを検索できれば便利かな、と思ってreposをインデックスの対象にしていたけど、実際のところ検索機能でコードを探したりって全く使っていないので、なくても支障は感じていない。毎回発生するわけではないとはいえ、ある程度の頻度で発生するインデックス作成の暴走(知らない間にCドライブを食い尽くす)のほうが有害。

　最近Razerマウスのイルミネーションがバグりがち。イルミネーションはOFFにしているんだけど、毎日々々、カラフルに光りやがる。誤入力もそこそこの頻度で発生するし。こんな不安定なソフトウェアを供給するようなメーカーの製品をプロゲーマーの人たちが使うってマジなのですか?

　USBメモリが見当たらないと思ったらポケットに入れたまま洗濯していたでござる。Gコード移動するときにたまに使う程度で重要なデータなんて一切入ってないから壊れたところであまり問題ないし、乾かしてPCに接続したらちゃんと認識したけど。

　最近のUSBメモリ小さくなりすぎ。存在感よ必要最小限に巨大であれ。小さくなったと言ってもUSBコネクタに挿していて引っかかったりしないほど小さいわけではないからなぁ。

　フィラメントを入れているケース、シリカゲルを交換したら、一瞬37%とかまで下がって、そこから上昇傾向。20g入れているけど、1週間とかで交換する必要がありそう。ここ最近は比較的涼しく低湿な感じだと思うんだけど。どうせケースからプリンタまでむき出しで引っ張ってるんだから最終的には雰囲気中に常時晒されるんだし乾燥剤とか意味ないだろ、というような気もしつつ。

　頭部に何かを固定するやつ、OPS-COREライクなエアソフトヘルメットを流用する場合、シュラウドをFMAのアルミダイキャストのやつに交換して、FMAのアダプタープレートを流用すると便利。M5用の長穴が掘ってあるから、適当な間隔で4箇所のM5タップを用意しておけばいいし、クイックデタッチできるから取り扱いも楽。何より変な角度のネジ穴とかを考えなくていい。垂直から20度くらい傾けた平面を用意するだけでいい。

　シュラウドを交換する場合、既存の穴と微妙に合わないことがある(メーカーによって数mm程度ズレている)から、ちょっと穴を広げてワッシャーでごまかすとかする必要がある。

　2台のUSBカメラから動画を持ってきて横に並べてファイルに保存、ffmpegで以下のコマンドでできる

ffmpeg -hide_banner -y -rtbufsize 64M -f dshow -i video="Stereo Vision 1" -f dshow -i video="Stereo Vision 2" -filter_complex "hstack" -pix_fmt yuv420p -vcodec h264_nvenc output.mp4

　エンコーダは環境によって適当に。

　問題点は、USBカメラを順番に起動するような感じらしく、タイミングがかなりズレる。

　とりあえず、hstackでサイドバイサイドに並べたので、

ffmpeg -hide_banner -y -i output.mp4 -vf stereo3d=sbs2l:arcc -aspect "16:9" -pix_fmt yuv420p -vcodec h264_nvenc output2.mp4

　のようなコマンドで、3D映像(アナグリフ)へ変換したりもできる。タイミングがズレているので映像としては見るに耐えないけど。

/* hstack、めっちゃ解像度高そうだな。視力300万くらいありそう…… それはhaystackや */

　ドキュメントだと、-f dshow -i video="hoge" -f dshow -i video"fuga"を、-f dshow -i video="hoge":video="fuga"のように複数デバイス(最大2個まで)を連続して指定すれば同期エラーを回避できるとのことなんだけど、そういうふうにしても期待通りに動かない。

　video="hoge":video="fuga"をファイルに書き出したら最初の"hoge"の映像しか出力されないし、-map 0:0 -map 0:1や-map 0:0 -map 1:0ではエラーになる。-filter_complex "hstack"も同様。

　video="hoge":audio="foo"みたいなふうにすれば、-map等で指定しなくても、ffprobeではビデオストリームとオーディオストリームが一つずつ入ったファイルとして見えるから、おそらくdshow -iの複数デバイスの指定はvideoとaudioの組み合わせだけが有効なんだと思う。あと、こうやって作った映像と音声のファイルでも、明らかに映像と音が同期していない。video="hoge":video="fuga"が使えたとしても、望み薄な感じ。

　-f dshow -i video="hoge" -copyts -f dshow -i video="fuga" -copyts -filter_complex "[0:0][1:0]hstack"みたいな感じにすると、映像間の遅延は目に見えて少なくなる。ただ、それでも多少のズレはあって、かつ出力された映像ファイルの長さが、PC起動時間を基準にしている感じになる(現在PC起動時間が4日と11時間程度で107h+だが、作成した動画(10秒程度)の時間が107時間数十分になっていて、一部の再生ソフトで開くと動画の長さが107時間数十分になる)。

　USBカメラの映像は、例えばOpenCv(Sharp4)のReadで読み込んだ画像をファイルに保存すると、概ね1フレーム未満のズレで画像を読み込める。つまり、最初に数秒待ってバッファを捨てればある程度同期できるはずなんだけど、ffmpegでそういう処理が可能なのかは不明。

　hstackを指定せずに書き出すと、複数のストリームとして書き出される。後からこのファイルをffmpegに与えてhstackで並べれば、ひと手間かかるかわりに右と左を個別の映像として取り扱える。実際、後からhstackとsbs2l:arccでステレオカメラをアナグリフに変換できる。ただ、複数のストリームの位置合わせを行う方法が思いつかない。例えば時刻をQRコードで画像(動画)化して最初にカメラで映すとかで複数のカメラのタイミングをある程度合わせることは可能なはずだけど、それを簡単に解析する方法が見当たらない。この手の処理はOpenCvを使うと楽そうだけど、OpenCvの動画ファイル読み込みでは動画ファイル内のストリームを指定することはできないらしい? 一旦ffmpegでストリームを分離して一時ファイルを作るとか、ひと手間必要になる。まぁ、そういうプログラムを書けばいいだけの話ではあるのだけど。。。

　こういう用途、例えばカチンコと同じ使い方なわけで、探せば既存のアプリやライブラリで対応できそう。あるいは「時刻をQRコードで表示する時計アプリ」みたいなものがあれば、それを使えば動画内に画像としてタイムスタンプを埋め込めるので後処理に便利そう。機械可読性だけを追求した時計アプリは地味に便利そう。ついでにDTMFとかチャープ信号でタイムスタンプが出ていると音声と同期するのも楽。

　試しにユニークな文字列のQRコードを1Hzくらいで切り替える動画を作成して、それを2台のUSBカメラで撮影し、後処理でQRコードが変化したタイミングを検出して、動画間の時間方向のズレを計測してみたら、動きのない映像であれば比較的いい感じに時間合わせができる。ただ、最初に確実にQRコードを読ませる必要があるので、ちょっと手間がかかる。あと、当たり前だけど、動きの大きい(30ms以下でも大きく動く)映像は合わせきれない。

　ffmpegの-filter_complexは-mapを参照しないというのに気がつくまでにめちゃくちゃ時間がかかった。-itsoffsetでずらすには複数の入力を与える必要があるけど、-filter_complexは-mapの影響を受けないから、-itsoffsetが反映されない(1つ目のファイルに2つの映像ストリームがあればそれが採用される)。例えば -map 0:0 -map 1:1 みたいな選択をさせるには、-filter_complex "[0:0][1:1] hstack"みたいに指定してやる必要がある。

　ffmpeg、オプションでいろいろ指定するの面倒くさすぎる。ノードベースエディタみたいな感じで起動オプションを生成できるようなやつ欲しい。

　ところで、ffmpegはパーサヴィアランスでも使われているんだそうだ。降下・着陸シーケンスとか、かなりの数のカメラで動画撮影していたからな。ヒューマンフレンドリーな動画の宇宙機用の圧縮ソフトウェアなんてアセットはないだろうし、ミッションクリティカルでない場所で使うならわざわざリソースを割いて動画圧縮ライブラリを書くよりOSS使おうって話にもなるだろうし。NASAならOSSの活用も積極的だろうし、それがミッションクリティカルでない場所で実績を詰めるならなおさら。

　しかし、惑星間ミッションのOSSライセンス表示とかどうなってるんだろうか。側面パネルを開けたら中にCRTがついていてボタンを押すとライセンス表示のテキストが…… SF映画とかで時々人工衛星に液晶パネルがついてたりする描写があるけど、どうなんだろう。宇宙で液晶って使えるのかな? 『火星の人』作中ではノートPCに「火星大気圧で使ったら液晶が沸騰しました」みたいな低評価レビューがあったような。あるいは、『ミニスカ宇宙海賊』ではWBRGBのメカニカルなドットが機械仕掛けで動く表示デバイスがあって、曰く一部が故障しても他の場所は故障しないから信頼性が高い、みたいな話だったけど、機械可動部があるとそれだけでMTBFやばそうよね。あ、いや、DLPディスとかじゃなくて…… 実際のところ、ISSのEVAで「GoProの液晶にNO SDって書いてあるんだけどこれってマズイの?」みたいな会話があったはずなので、ちゃんとしたケースに突っ込んでやれば問題ないんだろうけど。

　簡単なジグを作って、USBカメラの消費電流を計測

　Vbusに1Ω±5%の抵抗を挟んで、オシロでサンプリング。ch2(紫)が上流側、ch1(黄)が下流側。

　50ms(20Hz)くらいの周期で間欠的に消費電力の増減がある。これは31ms(32.3Hz)程度だったり、60ms(16.67..Hz)程度だったりすることもある。この周期は明らかに輝度に影響を受けていて、手で覆って暗くすれば伸びたり、視野に照明を入れたら短くなったりする。フラットな部分のパルス幅は30ms、20ms、0.5ms、くらいかな。パルス幅が変わるタイミングで画質も変化するから、これが露光時間に相当している可能性はありそう。

　OpenCvのExposureで数値を指定すると、-1で周期500ms、-2で250ms、-3で125ms、-4で62ms、-5以降で31.2ms、といった感じで、(1/2^n)secに一致しているから、露光時間が見ているっぽい。30fpsの場合、-5以降は33.33..ms周期で固定しても良さそうだけど、このカメラの場合は31.25ms(32Hz)で固定されている? 映像は30fpsで記録されるはずだけど、どうやって吸収しているんだろうか。

　電圧差は、フラットなところは0.16V(160mA)程度。ノイジーな所は電圧の計測が難しいけど、オシロのMeasureでMeanを計測すると0.22mV(220mA)程度。カメラの基板にはインダクタを含むスイッチング回路みたいなのが乗っているから、適当なバックコンバータみたいなのが乗っているはず。抵抗で電圧降下しているけど、5Vを突っ込めばもう少し消費電力が減るかも。消費電力が大きい部分のノイズはおそらくDCDC由来だと思う。

　とりあえず、電源ラインを監視すれば露光タイミングは把握できそうな雰囲気は掴めたかな。例えばSi5351で12MHzを作って、フレームのタイミング差をフィードバックしてやれば、二つのUSBカメラのフレームを同期させたりはできそう。USBの精度要求があるからあまり大きなΔfは与えられないけど、それでも例えば10秒かけて20ms動かすくらいはできるだろうから、フィードバック制御としては問題ないはず。

　ジグの様子

　片面にマイクロBの、反対側にAのレセプタクルがついていて、GND, D-, D+は直結、VBUSは1Ωで接続。マイクロBの基板上には100mA(トリップ200mA)のリセッタブルヒューズが乗っているけど、USBカメラの消費電力がトリップ電流より高く、接続が安定しなかったため、ジャンパを飛ばしている。

　はんだごてもオシロスコープも使うの久しぶり。オシロは去年11月のファミコン以来? はんだごてはそれ以上?? うぎゃー。最近全く電子回路触ってないなぁ。。。

　USBカメラのクロック周り

　左側の水晶の周りに2個のCと1個のRがついていて、右側のICの上辺左端の2ピンがRに伸びている。12MHzの水晶を使った平凡な発振回路という感じ。それだけに改造が面倒そうだ。水晶を剥がしてパッドにクロックを突っ込むみたいな改造が必要。

　東芝テリーあたりのFA用カメラとか使ってみたい。amazonで3.5万くらいか…… で、それが2個か。。。1ヶ月位貸してくれないかなー。

　キングジム、勤怠管理用“QRコード時計”を発売 - ITmedia ビジネスオンライン

　2005年だって。ドコモのフィーチャーフォンのカメラで読み込めばクラウドで勤怠管理が行えるシステム。

　最近でもQRコードを読み込むタイプの勤怠管理システムはあるけど、印刷物で掲示していたりとか。電子的に表示するのってどういう理由だったんだろうか。時刻情報とかはサーバー側で管理すればいいはずだし。

　QRコードをスキャンするタイプの勤怠管理は、その場所じゃないと打刻できないから不正防止に役立つ、とのこと。QRコードの写真を撮るなりコピーして持ち帰れば不正し放題では?という気もするけど。電子的に表示するQRコードならオンラインで鍵を共有するなり、あるいは簡易的にはタイムスタンプを埋め込む程度でも不正防止には役立ちそうだけど。QRコード時計がタイムスタンプを埋め込んでいるのかはさておき。

　最近だとコピーできないQRコードみたいな話もあるけど、最終的にカメラ可読である必要があるQRコードをどうやったら非可読にできるのかは謎いところ。特殊な機器でのみ読み取れる(それ以外の機器では非可読)みたいなことなんだろうか。

　試しにYouTubeで3Dコンテンツを探してみたけど、あまり多くない印象。VR180が結構多いけど、アナグリフだと見れない。アナグリフで見れるのは8-12年くらい前のコンテンツが多い。アバターが2009年の映画で今から14年前だから、そこから数年後くらいがピークだったのかな。

　アナグリフは色再現性に問題があるとはいえ、実際に映像を見てみると、やはり3Dで見えるのが面白い。アナグリフは視聴環境が非常に低コストだからもう少し普及していても良さそうな気がするけど。赤青メガネは古臭いイメージが先に来ちゃうのかな? そりゃ150年くらい前のテクノロジーだから古臭いカビの生えた技術であることに間違いはないけど……

　アナグリフは国土地理院のオンライン地図が面白いのでおすすめ。ちょっと面倒な場所にあるけど、グレースケールのアナグリフを表示してみると真上から見ている視点になって、かなり強調されたような表現だけど、見やすいし、身近な場所とか有名な場所を見てみると面白い。

　アナグリフの赤青メガネ、左が赤で右が青(orシアン)、船舶や航空機の灯火と似た配置だと思うんだけど、左が赤って何か基準があったんだろうか? それとも色の三原色を左右に割り当てたらたいてい1/2の確率で赤が左になるだけなんだろうか? RCA端子は赤が右だしな。信号機も日本では赤が右だし。単に確率の問題なんだろうか。

　美笹54mのペーパークラフトが公開されていたので、作ってみた

　タイトルは「親子で作る54mパラボラアンテナ1/580模型」だけど、対象は「アンテナマニア、熟練者向け」だそう。

　プロジェクトチーム長がゴールデンウィークを利用して作ったものだそうだ。あちこち合わない場所もあるけど、ご愛嬌。構造はある程度分かったし、今回は間違って組んでしまったところもあるので、もう一度作ればもっと綺麗に作れるだろうけど、作るの結構大変だからなぁ。。。

　なお、A4に印刷したけど、実測で直径85mmくらいなので、85mm/54m=1/635くらいだった。

　あまり大きくはないけど、置いておくと意外と存在感がある。

　https://www.isas.jaxa.jp/home/great/99_blank_pc.html

　美笹54mの画像っていまいち見当たらないんだよなぁ。JDAにも建設途中の写真とか動画はあるけど、完成後の写真はあまり多くない。

　副反射鏡から入ってくるところ、VERAとかだとフィドームがついてる部分、美笹だとスカスカなんだな。少なくともペーパークラフトでは部品がないから内部がむきむき出しで、実際の写真を見ても穴が空いているように見える(建設中の写真だと覆われている)。美笹はKa帯(32GHz)まで使うから少しでも損失減らしたいってことかな? そんなこと言ったらVERAは43GHzまで使うらしいけど。VERAの場合はフィドームの中に受信機があるけど、美笹の場合は折り返すから損失が大きい分、少しでも稼ぎたいってことなのかな。あるいはX帯の送信耐力の問題かもしれないけど。