Sunset, Speed and Flares | Mindil Beach 2026 Flying Display - Flypast Finale! - YouTube
オーストラリア空軍のF/A-18が夕方に展示飛行したときの機内動画。カメラから見える位置のMFDにHUDを表示してあるの良いな。
コウモリは飛行中の渡り鳥を捕食していた――世界で初めて空中捕食の瞬間を目視観察・記録―― | 東京大学大学院農学生命科学研究科・農学部
最近だとLiDARの長距離化・高解像度化も進んでいるし、夜間の鳥類(含哺乳類)の観察とかも便利になったりするのかな。適当なモデルで種類を判定したり、複数物体の急接近を検知した場合はフラッシュを焚いて撮影するとか、あるいはSPADをトリガするとか。東大なんてちょっと歩き回るだけでLiDARやSPADなんていくらでも転がってそうよね。あるいは最近のデバイスの高価格化と大学の予算削減で新しいデバイスは手持ちにないという可能性も……
国産“タルコフ風”少女PvE脱出シューター『限界サバイ部！』発表。飢えや「尿意」とも戦う、銃撃ゆる過酷サバイバル - AUTOMATON
見た目からは『シューターズ レディ！』っぽい感じがあるけど、でもタルコフプレイヤーが開発した過酷脱出ゲーか……
Q.「パソコンが重いとき何をしますか?」
ちょっと面倒な理系「サーマルスロットリングで動作が遅くなっている可能性が考えられます。まずは冷やしてみましょう」
だいぶ面倒な理系「光速に近い速度で運動することによる相対論的な重さの増加が考えられます。まずは冷やしてみましょう」
運動量を質量に含める解釈は正しくないらしいので、後者の前半は正しい表現ではない。ただ、系の運動エネルギーがゼロに近い状態でミクロに運動エネルギーが高い状態、つまり静止物体の温度が高い場合は質量が増えると考えられるので、熱い物体は重い、冷やせば軽くなる、という後半部分は極端に間違っているかというとそうでもないらしい。
フィクションに出てくる軍事組織(特に海軍)のキャラクター設定で、指揮官だけ有能でそれ以外は平凡(or無能)な表現ってあんまり好きじゃないのよな。キャラクターとして出す以上はちゃんと個性があってほしい。「◯◯はあの人に任せておけば大丈夫」みたいなキャラ設定が欲しいわけだ。指揮官が一方的に上意下達してそれに従う(orトラブルを起こす)だけならそれはモブであって、組織として運用する意味が無い。
指揮官だけが超人的に正しく状況を把握していて、部下は状況を正しく認識していない、というようなシチュエーションが好きじゃない。例えば強い敵を相手にして艦長以外の全員が恐怖に怯えながら、艦長だけは尊大に(絶対に勝てる、というように)振る舞っている状況とか。カリスマ的な指揮官を表すには楽な描写だけど、組織としては間違っていると思う。
確かＬ・デビッド・マルケの本で読んだものだと思うけど、作戦行動中の攻撃原潜の艦長が操舵手に対して回頭を命じて、それに対して操舵手が「あなた(艦長)が間違っている」と返答して、艦長は別の作業を行っていたために状況を正しく認識できていなかった、みたいなエピソードがあった。隊員がそれぞれの役割・権限を全うして、上位者が間違っていれば直ちに指摘する、というチームを構築した例。
航空機は、哨戒機を除けば大人数で役割分担して作業するというシーンが少ないし、哨戒機にしたって飛行しながらジェットエンジンを修理する、なんてこともしない。陸上部隊は人数は多いにしても全員が歩兵として似たような役割をすることが多い。海軍の艦艇はシステムとして巨大だからいろいろな役割がある。キャラクターが立っている設定を作り込めるのは海軍(艦艇)を題材にした作品が得意そうだけど、これらを扱った作品でこういう表現は、うまくされているものもあるけど、あるいは全く無いものも多い。
映画だと『バトルシップ』がキャラが立ってるかな。とはいえ艦内でしっかりと個性があるのは4,5人くらいだけど。ただ、主人公は最初は無能なキャラクターだし、終盤では周囲が追いつけないような奇想天外なアイディアを使うから、そのあたりは上述の基準に照らすと満点評価ではない。とはいえ、部下の能力も高いので高評価。映画の枠(主に時間)に収めようとするとキャラが増えても大変だしな。その点、はいふり(アニメ)は12話5時間弱あるから、ある程度の人数を掘り下げて描ける。
小説の場合、登場人物が増えすぎるとキャラクターを区別するのが難しくなるし、漫画の場合は週刊誌とかで連載していると1話はかなり短いからキャラの区別のためにコマを割けないみたいな理由もあるのかな。そう考えると、アニメとかドラマみたいに1クールで5時間から10時間くらいを使ってストーリーを広げたりキャラクターを書き分けたりできるメディアってあんまりないのかな。ドラマオリジナルのストーリーでもカリスマ的な指揮官と足を引っ張る部下、みたいな作品もあるし、時間がたくさんあれば丁寧にストーリーを作れる、というものでもないんだろうけど。
7基本単位の解説で、カンデラが唯一人間に合わせた尺度である、みたいな説明があるんだけど、これって本当だろうか?
キログラムは人間が持つのにちょうどいい程度の重さだし、メートルは人間が取り扱うのにちょうどいい程度の長さだし、時間は人間が数えるのにちょうどいい周期だと思うのだが。温度単位だって大雑把に人間が扱うのに不都合のない間隔になっているし、モルだって人間が扱いやすい量になっている(例えば試験管1本分の水分子の量くらいの大きさ)。電流はメートル・秒・キログラムを組み合わせたうえで、恣意的にスケールしているから、人間が扱いやすい大きさに設定されている。
ということで、SI基本単位の7つはすべて人間に合わせたスケールで定義されている、と理解するのが正しい気がするのだが。
ただ、これは(一部の単位は)あくまでもオーダー(桁)を調整したものであって、1桁を見ると、メートルは赤道から極までの弧の1万分の1、みたいに、人類が作ったものではない由来ではあるから、そういう意味では基本単位は人間が恣意的に決めた量ではない、とも言えるのかな。それにしてもカンデラだけじゃなくてモルやアンペアだって恣意的な気がするけど。
久しぶりにOH-1を見た気がする。もしかして飛行停止明け以来初? そもそもの数が少ないのに加えて、改修が進まずに運用中の機体も少ない、ということで見かけなかったのかな。あるいは、飛んでいたけど気がついていなかった、という可能性もあるが。
最近サボりがちだった、週1の定期的なWindowsの再起動を実施。えー、シャットダウン中に画面が真っ暗になってハングアップしました。。。過去にも極稀に起きている挙動なので、30分程度放置したあとにアクセスランプが明滅していないことを確認して、電源ボタン長押しで強制終了させた後に数分待ってから起動。念のため起動後にもう一度再起動を行い、正常に立ち上がったので、使用を再開。/* そういえば、fl2kドングルをつけっぱなしだと正常にシャットダウンできなかったような気がしないでもないような? */
しかし、Windowsの再起動ってやたら早くなった気がする。起動しているアプリケーションがない状態で再起動したからというのもあるのかもしれないけど、再起動を開始して一瞬目を離したらログイン画面が出ている、みたいな速度感で立ち上がる。
再起動後、またFH6のスプラッシュスクリーンでクラッシュログ。再度起動するとちゃんと起動する不思議な挙動。その後も1回別のエラーコードでクラッシュしたり。やはり前のPCクラッシュ以降不安定な気がする。
いまさらする話でもないけど、眠いときにFH6で走ってるとものすごい頻度でぶつけまくる。やはりわずかでも眠気があるときに運転するのは危険。いくらゲーム内とはいえ、何度もぶつけても運転をやめようとも思わないあたり、判断力が鈍っている状態は本当に危険。
そういえば、2000年代頃までの電子工作界隈では秋月のモジュールを組み合わせてテレビを作るのが一定程度流行っていたはず。僕が本格的に電子工作を始めた頃にはもうほとんど終息していたはずだけど。
おそらくここで使っているモジュールはRFからCVBSを出すものであって、IFを取り出す(広帯域ダウンコンバータとして使う)ことはできないモジュールのはず。そう集積度の高いモジュールでもないし、適当なところでピックアップすればIFも取れるんだろうけど。
***
fl2kでアナログテレビ信号の出力。
インターポレーションの処理(スパースなFIR的計算)を並列化して、5秒分の波形を吐き出すのに50秒程度かかっていた処理が45秒程度まで微減。手間の割にほとんど成果が得られない。ブロックサイズを大きくしてスレッド周りのオーバーヘッドを減らそうとすると、ものすごい遅くなる。おそらくFIRに使うバッファがCPUのキャッシュに乗らなくなって、メモリアクセスが遅いんだと思う。
今のところ、データバッファだけで26.4MiB/処理ブロックくらいあるので、これでもCPUのL3キャッシュから溢れる。今回作ったインターポレーション処理のブロックサイズには結構強い制限があって(係数長がRの整数倍かつブロックサイズが係数長の整数倍)、それが44.056ksps→8fscと8fsc→16fscの2段だから、ブロックサイズの自由度がかなり低い。適当な妥協点を探してブロックサイズを小さく(必要な配列全体がL3に乗る程度に)しても、速度の改善はほとんどない。
Debugビルドだと40秒程度で、Releaseビルドだと10秒程度だから、これだけで4倍程度早くなる。とはいえ、まだ実速度には足りない。
タスクマネージャーで見るとCPU全体の使用率はかなり低いから、並列処理がうまく乗り切ってないんだと思う。下手にFIRの中身を並列化するのでなく、もっと上のレイヤでパイプライン化/並列化したほうがいい気がする。ただ、データ管理がかなり面倒になるので、うまくやらないと簡単に壊れてしまうが。
いろいろ並列化して、Releaseで5秒程度まで短縮。かろうじて1倍速に触れるか否か、くらい。もう少し早くなってくれると嬉しいのだが。
FIR(インターポレーション)をブロック単位で並列処理するようにしたので、本来であれば数スレッド分まとまって走ってくれるとありがたいのだが、実際には1,2スレッド程度しか並列化されない。
簡単に手がつけられそうなところを最適化して、エンコード処理
横軸がデータの長さ、縦軸が処理時間。綺麗な直線に乗る。例えば45秒の信号を作成するのに19.5秒かかっているから、2倍程度のスループットが得られている。
タスクマネージャーでもアイドル15%程度のところ、エンコード中は安定して95%程度出ているから、パイプラインにボトルネックはなさそう。ちゃんと実装すれば100％に張り付くだろうから、もう少し改善の余地はあるんだろうけど、それらを探す手間で5%弱の処理速度は……
元々は0秒に外挿した場所で2秒程度のオフセットがあった。C#のThreadPoolは少なめの数から始まるから、大きなバッファをプロセッサ数で分割して並列処理、みたいな仕事を複数個同時に始めると、スレッド数が足りなくて、それを増やすのに時間がかかる。
曰くThreadPool.GetMinThreads(out _,out var minio);ThreadPool.SetMinThreads(N, minio);で一気に増やせるらしいんだけど、ここで最小値を増やしても実際にスレッドを使わないと増えないらしい(スレッドを起動するのに多少の時間がかかる)。ということで、信号処理の前にfor(int i=0;i<N;i++)Task.Run(()=>Thread.Sleep(100));みたいに適当なタスクを作成して、メインスレッドでもこれらのタスクが終わるのをまってやると、使えるスレッドがプールに入る(技巧的にやるならInterlocked.Incrementで全スレッドの起動を待って、その後全スレッドが終了するまで待つ、とか)。真面目にやるなら、そもそもスレッド数がプロセッサ数を超えないようにタスクを割り振る必要があるが、配分が難しい。
あとはアルゴリズムの最適化とかで稼いでいけばもう少し早くはなるんだろうけど、とりあえず実速度以上の速度が安定して出ているなら満足な感じもする。
手元のCVBS→HDMIアダプタ、4.5MHzの音声キャリアがあるとカラーを復調できない。それと音声が出ている間はものすごい輝度ノイズが出る。音声が無い場合は市松模様は出ないから、FMの幅が広い場所がfscに引っかかっているんだと思うけど。
アナログテレビの3.58MHzのfscと4.5MHzの音声キャリア(0.92MHz間隔)は結構狭いし、不要なら(CVBS想定なら)LPFを入れたりはしないんだろうな。
あるいは音声の帯域が広すぎるのか。
アナログTVチューナーを再度セットアップして、スキャンをやり直し
無事カラー映像が見えるようになった。音声もちゃんと聞こえる。ということで、アナログテレビの変調は、少なくともこの受信機で受信できる程度には、正しく行えているはず。
映像も音声も非常にノイジーだけど、これは原因不明。単に信号強度の問題のような気もする。fl2kからチューナーに直結するわけにもいかないので、確認が難しいけど。fl2kからはDCオフセットがあって、低周波側にも強い信号のある、全体的に非常に強度の高い信号が出ているから、これをチューナーに入れるためには色々とフィルタが必要になる。
まず、ゾーン1,2の強い信号を消すためのBPFが必要で、これはFMラジオ用の市販のフィルタを流用できる。非通電型を選べばDCオフセットも除去できる。信号レベルはDC付近で0.7Vpp@75Ωだから110dBuV程度、BPFでゾーン4を取り出して100dBuV程度、アナログテレビの適正信号レベルが60dBuV程度として40dB程度のアッテネータが必要になる。100MHzくらいで性能を求めないなら炭素被膜抵抗でπ型アッテネータを組んでもいいし、それが面倒なら市販のテレビ用のアッテネータセットを使うという手もある。amazonで売ってるセットだと減衰量が数dB程度物足りないけど、そのくらいならチューナー側で吸収してくれるんじゃなかろうか。
ということで、残りは札束で解決できるような問題かな、という感じ。札束と言っても、千円札数枚、1万円札換算1枚弱、位のものだけど。あとは、欲を言えばチューナーの電源に今はベンチトップ型の安定化電源を引っ張り出してきているので、これが邪魔だな、という感じ。15Vのトリガーケーブルと適当なコネクタを買って組み立てれば数千円で解決できるんだけど、また出費が。。。ちょっと前に六分儀用に部品を色々買って出費がかさんで、しばらくは出費のないソフトウェア周りを、とか思って始めた遊びなのに、変な場所に手を出したせいでまた出費がかさむ。そのうち、気が向いたらね。
今回は比較的マルチスレッド化が容易な信号処理だったけど、パイプラインの組み方とか勉強になった気がする。信号が変わればまた色々と変わって大変なんだろうけど。
そもそもFL2000って元々PC側(CPU)で映像をRGB/Hs/Vsにエンコードして吐き出すわけで、何やってんだ、という感じもある。
DP-1BS ミニD-Sub15ピン-BNC変換コネクタ 1本 イメージニクス 【通販モノタロウ】
D-sub15pin端子でコンポジット入力を考える | 音響・映像・電気設備が好き
VGA端子で映像を受けるデバイス(ある程度フレキシブルなデバイス)に対してコンポジットを入れるためのものらしい。GreenとBNCのセンターと、Green RTNとBNCのリングを直結したようなもの。
fl2kのデフォルト(付属のexeとか)はRed出しなのでこの変換コネクタは使えない。DLLを叩くならRGBの好きなチャンネルから出せるので、この変換コネクタでシンプルにBNCにすることはできる。fl2k→VGA→BNC→F端子→ATT→BPF→PAL→アナログチューナー、みたいな感じでカスケードできる。ATTは3,4個組み合わせるから、いくらケーブルなしで直結できるとはいえ、すさまじい見た目になりそうだけど。
C#でwhile(!f(out var hoge)){Thread.Yield();}みたいな感じでポーリングするとループの外からhogeが見えなくて、いちいちT hoge;while(!f(out hoge))みたいに宣言しなきゃいけないの、地味に不便なんだよなー。for(int i=0;i<10;i++);のiが外に見えないのと整合性を取るために、whileの条件の中も見えないようになってるんだろうけど。
試しにffmpegのDLLの使い方をググってみたけど、かなりデカい構造体の中身に触らなきゃだめっぽくて、サクッと使えるものではなさそう。そのためのラッパーもあるらしいけど、それにしたってポインタ経由だからユーザーコード側でもunsafeが必須。
C#の設計思想としてしょうがないんだろうけど、アクセサのないDLL(構造体を直接触る必要があるもの)はかなり不便な感じ。ライブラリを作っている側からすれば、膨大な操作に対していちいちアクセサを作るのも面倒だろうし、だったら構造体に勝手に触れってことになるんだろうな。Cの構造体だとアクセスを制限することもできないし。
Google AI曰く、最近のトレンドは構造体をブラックボックスとして扱って各種数値を得たり設定したりはアクセサ経由が基本だよ、とのことで、試しにその方針でサンプルプログラムを見せてもらったところ、Googleで検索しても1件もヒットしない謎関数を多用した不思議プログラムが出力された。これだからAIは(ry
気分転換に読む本を探したくて「こういう内容の本って無い?」って聞いたら実在しないタイトルを出してきたこともあったし。Google AIって結構ファンタジーな世界に生きてる。
0 件のコメント:
コメントを投稿