2017年12月29日金曜日

Mk41

 Mk41 strike-lengthを紹介するPDFを簡単に訳してみました。
 よみづらいけどごめんね!


Missiles
SM-2
Blk II
VLA
ASROC
種類 対空 対潜
最大重量(kg) 707.6 635
最大長(m) 4.76 5.08
最大直径(mm) 355.6 355.6
トマホーク
AUR
シースパロー
VL/RIM-7
種類 対地/対水上 対空
最大重量(kg) 1814.4 244.9
最大長(m) 6.27 3.86
最大直径(mm) 584.2 203.2
システムサイズ - 61Cell 発射機
長さ 8.71m
6.32m
高さ 7.70m
発射機 RM&A - 8Module 発射機
平均故障間隔 1936時間(80日)
平均修理時間 3.2時間
平均保守時間 30分/1日
intrinsic availability 0.978
ストライクダウン
平均失敗サイクル
200
必要な電力(61Cell VLS 発射機)
440Vac 60Hz 3phase 200kW
115Vac 60Hz 1phase
(lighting)
8kW
115Vac 60Hz 3phase
(backup power for 440Vac)
10kW
115Vac 60Hz 1phase
(発射制御装置)
5kW
115Vac 400Hz 3phase 45kW
必要な船舶からのサービス
低圧空気 1.5MPa  
淡水 210リットル  
海水    
  Deluge 1.2kL/毎分 at 0.73MPa
  散水 4.0kL/毎分 at 0.5MPa
  排水 5.2kL/毎分  
冷却 40kW  
加熱 20kW  
環境条件
発射機内の条件 13℃/95%RH
から
30℃/55%RH
システム重量
空の発射機 117t
空のMk13キャニスターとアダプター 178t
61発のSM-2 Blk II 217t
48発のSM-2 Blk IIと
13発のトマホーク
230t
空のMk22キャニスターとアダプター 195t
VL/RIM-7 210t
キャニスター重量
Mk13
  空 675.9kg
  SM-2 Blk 2(ミサイルのみ) 1383kg
  PHS&T (空キャニスター) 1211kg
  SM-2 Blk 2とアダプタ 1800kg
Mk14
  空 912kg
  トマホークAUR 2726kg
  PHS&T (空キャニスター) 1424kg
  トマホークAUR(sill assembly) 2781kg
Mk15
  空 757kg
  VLA 1497kg
  PHS&T (空キャニスター) 1293kg
  VLAとアダプタ 1769kg
  VLA(max, growth)とPHS&T 2032kg
Mk22
  空 966kg
  VL/RIM-7 1216kg
  PHS&T 1501kg
  VL/RIM-7とアダプタ 1497kg
発射制御システムの寸法と重量
ステータスパネル
  長さ 29.12cm
  幅 45.72cm
  高さ 60.96cm
Remote launche enable panel
  長さ 20.32cm
  幅 25.4cm
  高さ 33.02cm
発射制御装置
  長さ 86.36cm
  幅 111.76cm
  高さ 203.2cm
ストライクダウンの重量
strongback, horizontal transfer assembly 95.7kg
vertical strongback 21.3kg
Cell guide assembly 23.1kg
Steady rest assembly 24.5kg
Pivot fixture 167.4kg
Beam weld steady rest 74.4kg
Beam weldment locator receiver 136.6kg
Lift adapter, truck assembly 128.8kg
Chock 60.3kg
Other assemblies 110.2kg
Total 842.3kg
安全性
restrained firing
拘束されたミサイルの完全なモーター燃焼で
生き残ることができるランチャー
warhead deluge
弾頭の爆発を防ぐために提供される洪水
(1.21kL/min at 0.7MPaゲージ)
* トンはlong ton(英国トン)を使用
* PHS&T:Packaging Handling Storage and Transportation


 このPDFでは、タイコンデロガ級を基準としているようです。タイコンデロガ級は、前後に8モジュール(64セル)のMk41を搭載しており、全体で122セルがあります。前後共にストライクダウンクレーンがあり、これが3セル分を占めているのはアーレイ・バーク級フライトII以前と同様です。

 Missilesの重量は、ミサイル単体の重量かな?wikipediaによると、RIM-66の重量は707kgだそうで、PDFの値と一致しています。


 RM&AはReliability, Maintainability and Availabilityの頭文字で、"信頼性、保守性および可用性"みたいな意味だそうです。8-Module Launcherとのことなので、61発分のランチャ全体の話だと思います。平均して80日に1回は前後どちらかの発射機の修理が必要になる、みたいな意味かと。また、この際は3.2時間の修理が必要になるということでしょうか。
 intrinsic availabilityってどういう意味だろう?単位が書いてないので何かの比率だろうけど、何の。
 ストライクダウン平均失敗サイクルというのは、ストライクダウンクレーンで失敗する確率でしょうか。200回に1回失敗する。でもちょっと位置合わせに失敗したくらいならやり直せばいいだけで、カウントはしないでしょうから、何らかの致命的な失敗のカウント?200回に1回、ミサイルを破損させるような失敗をする、とか。でもこの値ってどれくらい信用して良いんだろうか。ストライクダウンって統計取れるほど使ってるのかなぁ。


 電力はいまいちよくわかりません。


 圧縮空気が1.5MPa必要だそうです。Low-pressureと書いてありますが、日本で言うと法規制される高圧です。何に使うのか不明。空気だから排煙に使うのかなーと思うけど、でもそれなら流量も併記されてるはずです。
 水は何に使うのか不明。淡水は流量が書いてないので、そんなに大量に使うものではなさそうです。
 海水は流量が書いてあるので、それなりに大量に必要になるんでしょう。
 
 冷却は高温地域、加熱は寒冷地での温度制御だと思います。おそらくVLS発射時に冷却が必要な場合は、水が使われるはずです。


 環境条件は、これもよくわかりません。
 発射機内がこの範囲に収まる必要がある、ということかな?セルではなく、発射機全体っぽいです。主に船舶のエアコンで制御する数値でしょうか。


 重量はいろいろ書いてありますが、大きく分けてシステム重量とキャニスター重量があります。他にサブシステムの仕様にもかかれていますが。
 こまかく計算していくと、だいぶ計算が合いません。ま、あんまり細かく考えないように。。
 キャニスターは、SM-2がMk13、トマホークがMk14、VL ASROCがMk15、VL/RIM-7がMk22、となっているようです。中身(ミサイル)に合わせてそれぞれ作っているのでしょう。
 strike-lengthとtactical-lengthではセルの長さが違いますが、tactical-lengthでもMk13キャニスターの重量は変わりません。wikipediaのイラストではtactical-lengthにはSM-2は入らないような感じですが、実際には搭載できるようです(追記:SM-3と取り違えてました。あと最後にもうちょっと書き加えています)。キャニスターの長さは共通で、より大きいVLSに搭載する場合は、キャニスターの下にゲタを履かせているのでしょう。とはいえ、排煙の経路だったりが必要なので、単純な高さ合わせだけでは足りないと思いますが。


 安全性の項目は2種類書いてあります。

 一つ目は、何らかの理由でミサイルが発射されずに、ランチャー内でモーター(固体燃料ロケット)が燃え尽きても、危険にはならないことが求められています。
 ミサイルに限らず、固体燃料は燃焼温度がとても高く、運動エネルギーも大きいです(熱エネルギー/運動エネルギーが高いほど、高性能)。例えばH-IIAに使われるSRB-Aの燃焼温度は3000℃を超えるそうです。ミサイルのモーターは、ブースター等であれば燃焼時間は数秒ですが、SM-2のメインモーターのような、デュアルスラスト型では燃焼時間は40秒ほどあるようです。
 「3000℃のガスを40秒浴びても抜けない防火壁」というのを考えてみると、かなり大変な要求だと思います。そもそも3000℃というのが想像の埒外ですね。

 もう一つは、弾頭の爆発を防ぐための仕組みだそうです。原文では"prevent warhead explosion"とあるので、耐爆ではなく、防爆を指しています。
 おそらく、キャニスター内でモーターが燃焼して弾頭が加熱されて自然発火/起爆することを防ぐための機能でしょう。大量の水をキャニスターに流し込んで加熱を防ぐ、ということだと思います。
 1.2kL毎分、0.7MPaというのは、"船舶からのサービス"の海水のDelugeを使うのでしょう。Deluge、洪水や氾濫という意味だそうですが、キャニスター内を洪水にしてしまう、という用途でしょう。
「上は洪水、下は大火事ってなーんだ」
「Mk41に装填されたMk13でモーターが異常燃焼してる状態!」
 上っていうか、キャニスター全体が洪水ですけどね。
 当然ですが、SM-2のブースター/メインモーター、VLAやトマホークのブースターが燃えても、水をかけても消化は不可能です。発泡系の消火剤でも同様です。これは固体燃料の中に酸化剤が含まれているからです。逆に、トマホークのジェット燃料が漏れて燃えている場合は、ある程度の消化が期待できます。

***

 ということで、簡単にMk41のことを書いてあるPDFを読んでみました。A4紙で1枚分程度ですし、4分の1はイラスト(解像度低くて数値読めない!)なので、情報量はあまり多くないですが。

 昔、ディスカバリーチャンネルだったかでアーレイ・バーク級の建造を手伝う、みたいな番組があったはずなんですが、再放送してないっぽいです。見たいんだけどなぁ。Mk41の設置作業とかやってた気がします。
 ナショジオのライリーは修理中!もそうですが、向こうの番組は「手伝いに行く」というテイが多いですよね。日本でもこういうのやらないかなぁ。


追記:2017/12/30
 イージス艦辞典47pに各キャニスターのイラストがありますが、ここにはSM-2MRとSM-2ERの2種類が書かれています。SM-2MRはtactical-length(図中ではlengthではなくmodule、以下同様)の長さで、SM-2ERはstrike-lengthです。
 おそらく、strikeのPDFに書いてあるMk13キャニスターはSM-2MR専用のものだと思います。
 wikipediaの図は左から3番目がSM-3とSM-2ER、右から3番目がSM-2MRで、SM-2MRサイズはMk13、SM-2ERサイズはMk21だそうです。PDF翻訳しなくてもwikipediaに書いてあったよorz この図、見覚えあるから読んでるはずなんだけどなぁ。。。

2017年12月28日木曜日

Iron palette

 いつも起きるの遅いから、乱数の試行回数を増やして寝たら、今日に限っていつもより早く起きてしまい、プログラムが終了していない。ということで、amazonでハイエナ・ロードを見て終了待ち。いやぁ、切ない映画だ。
 primeに登録してから、最近見た映画はprimeばっかりだなぁ。最近聞く音楽もprimeばっかりだし、嗜好がamazonに制御される。

***

 さて、本題のIron palette。前回、最後にちらっと書いた、「正弦波2個じゃなくて、正弦波1個と直線で良いんじゃね?」をやってみました。



 いい感じです。
 FLIRのスペクトルとよく似ているので、FLIRも正弦波+直線で作っているのかもしれません。

 正弦波2個を作るには、パラメータが4+4で8個必要でした。正弦波1個だと、パラメータは4+2で6個で済みます。3割ほど、パラメータで使うROM領域が少なくて済みます。96byteが72byteになったところで、誤差の範囲ですけど。チープな組み込みなら24byteも大きいですが、なら三角関数とか使うな、という話で。

***

 C# src

public class Iron_palette
{
    protected const float R_f = 1.5879f;
    protected const float G_f = 4.2124f;
    protected const float B_f = 2.2251f;

    protected const float R_p = 3.161f;
    protected const float G_p = 0.8156f;
    protected const float B_p = 3.1285f;

    protected const float R_g = 0.4042f;
    protected const float G_g = 1.0976f;
    protected const float B_g = 1.9342f;

    protected const float R_o = 0.0027f;
    protected const float G_o = -1.5174f;
    protected const float B_o = 1.9635f;

    protected const float R_a = 1.9869f;
    protected const float G_a = -0.1639f;
    protected const float B_a = 2.2419f;

    protected const float R_b = -3.9506f;
    protected const float G_b = -0.17f;
    protected const float B_b = 0.1099f;

    public static Color to_color(double value)
    {
        if (value < 0 || value > 1)
        {
            throw (new ArgumentOutOfRangeException());
        }

        return (Color.FromArgb(
            (int)(
                (Math.Sin(value * R_f + R_p) * R_g + R_o) *
                (value * R_a + R_b) *
                255),
            (int)(
                (Math.Sin(value * G_f + G_p) * G_g + G_o) *
                (value * G_a + G_b) *
                255),
            (int)(
                (Math.Sin(value * B_f + B_p) * B_g + B_o) *
                (value * B_a + B_b) *
                255)));
    }
}

2017年12月24日日曜日

Iron palettes

 FLIRの画像でよく使われる、青紫っぽい熱画像のスケール。

 熱画像だと、温かいところが赤、冷たいところが青、中間が緑、というのがよくあるが、これは輝度と値が比例しないので、慣れないと理解しづらいという問題がある。また、印刷する際にカラーで印刷しないと情報が失われてしまうので、紙ベースで処理してコストを気にするようなところでは、モノクロで印刷しても情報が失われないIron paletteのほうが良い。輝度と値が比例するので、慣れていなくてもぱっと見て理解できる、という利点もある。


 javascript - Thermal imaging palette - Stack Overflow
 適当な大きさのパレットで持って、中間は補完しろ、みたいなことが書いてある。

***

 色をグラフ化すると、なんとなく波形っぽいので、とりあえず正弦波で近似してみた。


 1色あたり、8個のパラメータが必要になる。C#で乱数を作って、FLIRの画像から取り出したスケールとの差を最小になるパラメータを書き出した。500万セットくらい乱数を作っているが、5分位で処理できる。アルゴリズム上の問題で500万セットくらいしか処理できないが、アルゴリズムを修正すれば寝てる間に500倍くらいの乱数セットを処理できそう。
 ただ、今は1色ごとをFLIRの値と比較しているが、本来であれば輝度へ変換した上で、輝度のリニアリティを優先するべき。このあたりは追々。


 値から色に変換するには、値を0-1で正規化して、(sin(値*周期1+位相1)*ゲイン1+オフセット1)*(sin(値*周期2+位相2)*ゲイン2*オフセット2)で計算できる。

 上記のパラメータではこんな感じ。


 かなり綺麗に表現できてる気がする。
 三角関数が6個必要なので、組み込みだと計算負荷が高め。ま、組み込みでこういうスケールが必要な事態は少ないだろうし、問題ないはず。PCとかで処理するなら、三角関数で好きなだけ分解能を増やせる。

 緑の片方はゲインが0に近いので、正弦波5個で計算できるかも。


 最初はパラメータを手動で設定していたけど、乱数で設定したら簡単にそれっぽい値にできた。それなりに時間はかかるけど、放置しておけば終わるので楽。
 もうちょっと色々試してみる予定。


追記:2017/12/25
 アルゴリズムを変えて生成してみた。



 微妙に直線性が悪い気がするのと、グレーがなんとなくガタガタしてる気がする。
 とりあえず0で輝度が10%、1で輝度が85%になるような値になっている。0が完全な黒ではなく、1も完全な白ではない。背景が真っ黒のページにグラフを表示しても境界がわかりやすいし、真っ白な紙に印刷しても同様。
 なんとなく1側が青白くて、輝度が低い気がする。

 とりあえず以下のソースコードは別言語への移植も含めて自由に使っていいです。完全無保証無サポートですけど。あとFLIR Systemsとかに怒られても知らないけど(あ、怒られたら怒られたって教えてくれると助かります)。

 C# src
public class Iron_palette
{
    protected const double R_f1 = 0.5107;
    protected const double R_f2 = 0.6085;
    protected const double G_f1 = 2.9332;
    protected const double G_f2 = 0.0599;
    protected const double B_f1 = 4.6611;
    protected const double B_f2 = 0.646;

    protected const double R_p1 = 1.0094;
    protected const double R_p2 = 2.8977;
    protected const double G_p1 = 1.193;
    protected const double G_p2 = 0.8202;
    protected const double B_p1 = 1.5839;
    protected const double B_p2 = 1.0357;

    protected const double R_g1 = 3.8616;
    protected const double R_g2 = 2.3461;
    protected const double G_g1 = 4.2843;
    protected const double G_g2 = 0.2103;
    protected const double B_g1 = 2.7105;
    protected const double B_g2 = 1.6943;

    protected const double R_o1 = -3.2597;
    protected const double R_o2 = 2.1916;
    protected const double G_o1 = -4.9513;
    protected const double G_o2 = -0.2657;
    protected const double B_o1 = 2.8918;
    protected const double B_o2 = -1.4018;

    public static Color to_color(double value)
    {
        if (value < 0 || value > 1)
        {
            throw (new ArgumentOutOfRangeException());
        }

        return (Color.FromArgb(
            (int)(
                (Math.Sin(value * R_f1 + R_p1) * R_g1 + R_o1) *
                (Math.Sin(value * R_f2 + R_p2) * R_g2 + R_o2) *
                255),
            (int)(
                (Math.Sin(value * G_f1 + G_p1) * G_g1 + G_o1) *
                (Math.Sin(value * G_f2 + G_p2) * G_g2 + G_o2) *
                255),
            (int)(
                (Math.Sin(value * B_f1 + B_p1) * B_g1 + B_o1) *
                (Math.Sin(value * B_f2 + B_p2) * B_g2 + B_o2) *
                255)));
    }
}

 それぞれの三角関数の値。左上の、ガタガタしてるのはFLIRの画像から拾ってきた輝度。


 ざっと眺める感じ、1個の直線+1個の三角関数、で近似できそうな気がしてきた。Rs2はほとんど直線っぽいし、Gs2もほとんど直線。Bs2は微妙に曲線だけど、これくらいなら直線で近似できるんじゃないかなぁ。
 あとで片方直線、片方三角関数、でパラメータを探ってみよう。
 何かのシミュレーション結果をIron palettesで動画化する場合、4k動画なら1枚で約50M回のsin計算が必要になる。60fpsで1分の動画なら180G回のsin計算が必要になる。これが半分になれば結構大きい気がする。

しきさい&つばめ



 2017/12/24 12:30:00 JST

JS Orbit

 43065/82AがGCOM-C、43066/82BがSLATS、それ以外の3個がH-2A DEBです。
 とりあえず衛星名はこれで確定じゃないかなーって気がします。

 82CがH-2Aの2段目、82Dがつばめ搭載アダプタだと思います。82Eもデブリですが、以前に公開されたJAXAのシーケンス動画ではGCOM-Cの付近にはデブリはありません。このあたりはGCOM-Cの動画だと何か書いてあるかもしれません。


 とりあえずはしばらく待ちの体制です。次のネタはSLATSの高度が下がってからになるかな。

2017年12月23日土曜日

しきさい&つばめ


 結構前にTLEが更新されていたみたいです。

 JS Orbit

 今回の打ち上げでは、"しきさい"と"つばめ"の他に、ロケットボディと"しきさい"を載せる円筒形のアダプタがあります。
 43065/82Aか43066/82Eのどちらかが"しきさい"だと思います。
 他に43066/82Bと43067/82C、43068/82Dがあります。おそらくDが"つばめ搭載アダプタ"、B/Cのどちらかが"つばめ"、もう一方がロケットボディ、だと思います。

 軌道投入される物体は衛星2個、ロケットボディ、アダプタの4個のはずですが、実際には5個の物体が登録されています。
 A/Eはかなり近いので、"しきさい"に関係する部品なのかもしれません。あるいは5個の内のどれかが偽データか。


 最近はTLEのグラフ化をやっていませんが、つばめはダイナミックに高度が変わるはずなので、ある程度データが溜まったらグラフ化もやってみようと思っています。近いうちにSS-520でTRICOMも打ち上げられますから、そちらも合わせて。

CIWS

 CIWS ファランクスの制御方式とか。

 ファランクスは戦闘機に搭載されていた、M61バルカン ガトリング砲をベースとして作られたシステム。バルカンの下に弾倉、上部に火器管制レーダー、更にその上に捜索用のレーダーが搭載されている。
 レーダーはどちらもKuバンド(12-18GHz / 25-16mm)帯を使用している。捜索レーダーは5.6km、追尾レーダーは4.3kmの探知距離と言われている。
 使用する弾薬は20x102mm弾を使用する。これは戦闘機に使用される一般的な種類。薬莢長こそ対物ライフルや重機関銃の12.7x99mm弾と近い大きさだが、弾丸の長さは倍程度の違いがあり、直径が大きいことから、装薬量も大幅に増やせる。
 ファランクスの銃口初速は1.1km/s程度、有効射程は1.5km程度。弾丸が最大射程まで到達するには1.7秒くらいか?

 ファランクスの制御は、クローズドループフィードバックで行われている。撃った弾丸をレーダーで追尾し、目標との差を計測し、それを補正した上で次の弾丸を発射する。
 この場合、弾丸の追尾の方法によって、制御分解能が変わる(レーダーの角分解能を無視する場合)。
 弾丸の未来予測を行わない場合、目標と同じ距離にある弾丸と目標の差と、その弾丸を発射した際の照準を使用し、次の射撃の諸元を得る。この場合、最大射程で撃つと、最初のフィードバックは1.5秒後くらいになる。ファランクスは毎秒75発以上を発射するから、最初の110発程度は無駄打ちになってしまう。
 弾丸の未来予測を行う場合、弾丸の未来位置はある程度物理法則に忠実だから、目標と同じ距離に達した際の位置を計算することができる。ある程度の距離を飛んだ時点で、例えば最遠500mとした場合、7割程度の性能改善が見込める。
 クローズドループではある程度の時定数が必要だから、無闇矢鱈と連射速度を上げればいい、というものでもない(VADSのように適当にバラけさせて撃つなら、高連射速度は意味があるかもしれないが、当のVADSもかなり発射レートを下げてるから、あんまり意味ないのかも)。

 ファランクスで200m/s程度の目標を迎撃する場合、射撃機会は7.5secほどになる。弾倉は20sec程度の容量だから、2-3回程度の迎撃で弾倉がカラになる(早い時点で迎撃を終了する、あるいはある程度接近してから迎撃を開始するなら、5-10回程度)。複数のファランクスを並べれば、飽和攻撃で撃ち漏らした目標を迎撃するのにはいいかもしれない。しかし、一時期はアーレイ・バーク級でもCIWSを減らしたこと、最近では飽和攻撃を食らう危険が減っていること、を考えると、あまりCIWSを増やしたところで、導入・維持コストがかかるばっかりになってしまう。


 前回のエントリでもちらっと書いたが、「最強の装備」を考える場合、ただ単に火器を増やせばいい、という話ではない。VLSを増やしたところで、レーダーやイルミネーターの性能が変わらなければ、飽和攻撃を食らった際の能力は変化しない。長射程のミサイルを追加したところで、それを観測する手段がなければ、宝の持ち腐れになる。
 また、あまりに過剰な装備の搭載は、初期コスト・運用コストの増大という結果を招く。コストを考えないなら、いくらでも自由に装備を追加すればいいが、そんなことをするなら「研究開発にコストを回せ(未来装備の実用化)」という話になってしまう。
 他にも、あまりに大きな火力を持つと、政治的な問題を引き起こす可能性もある。
 「最強の装備」を考えるときは、コストや政治的な面、用途や使用頻度、と言った点を踏まえ、また、本当にその重量を艦に搭載できるか、と言った点も考えてみると、面白いはず。もっとも、「そんなのは俺の勝手だ!」と、好きなように盛るのも、それは個人の自由なのだが。

スタンダードミサイル

 他人の妄想に突っ込むのは野暮だと思うけど。

 スタンダードミサイルにはいくつかの種類があります。
 代表的なところでは、SM-1, SM-2, SM-3, SM-6です。それぞれサブモデルが存在し、場合によっては魔改造を受けて艦対空ミサイルから空対地ミサイル(性格には空対レーダーミサイル)にされた、というモデルもあります。が、今回は扱いません。

 SM-1はRIM-66 SM-1MRと、RIM-67 SM-1ERの2種類があります。同様に、SM-2はRIM-66 SM-2MRとRIM-67 SM-2ERの2種類があります。SM-3はRIM-161 SM-3、SM-6はRIM-174 SM ERAMの、それぞれ1種類ずつです。
 型番から分かる通り、SM-2はSM-1のサブモデルという扱いです。
 ではSM-1とSM-2は相互運用が可能かというと、そんなことはなく、SM-2は撃てるがSM-1は撃てない、というプラットフォームがあります。


 とりあえず先にMRとERの違いを説明しておきます。
 MRはMedium Rangeの略、ERはExtended Rangeの略で、それぞれ中距離、長距離の意味です(たいてい、ミサイルの最初か最後についてるERは長距離型の意味が多いです。SM-6ERAMのERも長距離の意味です)。
 基本的にMRもERも同じ弾体を使用しており、ERにはブースターが追加されている、という点が異なります。

Standard Missile

Standard Missile-2 on launcher, National Museum of Nuclear Science & History  

 この2枚の写真は、上がSM-2MR、下がSM-2ERです。ERのほうはMRの倍くらいの長さがあります。ERの後ろの青い部分がブースターで、これが付いていれば長距離型(ER)、なければ中距離型(MR)です。


 さて、SM-1とSM-2の違いについて。
 SM-1は全期間に渡り、セミアクティブレーダー誘導です。一方、SM-2は慣性/指令誘導による中間誘導と、セミアクティブレーダーによる終末誘導の組み合わせになります。
 全期間でセミアクティブによるロックオンが必要なSM-1では、ミサイルの発射前からロックオンしておく必要があります。そのため、発射する前からミサイルを目標へ指向しておく必要があります。これは、旧来の旋回式発射機では特に問題にはなりません。
 一方、SM-2は慣性誘導による中間誘導が追加されたため、「とりあえずこの方向へ飛んでいけ(ロックオンは後でやる)」という指示を与えるだけで発射することができます。この方式では、発射時にはロックオンする必要がない、というのが直接的な利点ですが、同時にミサイルを目標に指向しなくてもいいという利点があります。中間誘導の採用には同時に飛行できるミサイル数が増えるという利点もありますが、一番大きな利点は、この好きな方向に撃っておける、という点にあります。

 旋回式発射機は、発射前に目標に指向できるという利点がありますが、逆に目標に指向するまでの時間がかかるという欠点も生み出します。また、発射機は前甲板に1基、後甲板に1基、合わせて2基程度しかありません。万が一敵の攻撃(艦砲やミサイルの破片等)が発射機に命中した場合、その発射機が使用できなくなる危険があります。それでなくても、機械的なトラブルで攻撃力が半減、あるいは全滅といった事態になる危険性があります。
 これらの欠点を解決できるのが、Mk 41を始めとした垂直発射システム(VLS: Vertical Launch System)です。VLSであれば、ミサイル1発ごとに発射機1個が割り当てられている、と考えることができます。そのため、発射機1個が使えなくなっても、戦力の損失は100分の1程度に抑えることができます。また発射の指向が不要なので、準備ができ次第、次々と発射できます。他に、甲板上の発射機が無くなることによるステルス性の向上、セル(発射機)がカバーに覆われることにより被弾時の被害を抑えられる、といった利点もあります。
 もちろん、VLSにも欠点がないわけではありません。一番大きな欠点は、発射時はミサイルが上を向いており、発射時にはロックオンできない、という点です。この欠点は「発射前にロックオンが必要」というミサイルにのみ発生することであり、どの方向にでも撃てる(後からロックオンできる)慣性誘導を使用すれば、この欠点は存在しません。

 ということで、SM-2の中間誘導はVLSから発射するために作られた能力、とも言うことができます。もちろん、イルミネータの専有期間を減らして同時に発射できる弾数を増やす、飛翔経路を最適化して射程を延長する、といった利点もあるのですが。


 ここまで読んでくれば、「VLSからSM-1, SM-2, SM-3を撃てるようにしよう!」という「僕の考えた最強の戦闘艦」は実現不可能なことがわかると思います。もちろん、SM-1に中間誘導能力を追加すれば可能ですが、そんなことをするよりもSM-1を捨ててSM-2に絞ったほうが楽です(SM-1に中間誘導を追加したのがSM-2なのですから)。
 場合によっては、SM-2でも限定的ながら弾道ミサイル防衛が可能ですから、SM-3すらも捨てることもできます。まぁ、この場合はSM-6に一本化したほうがいいのですが。

 以上、SM-1とSM-2の違いとかの話でした。


 なお、上では書いていませんが、VLSの欠点は他にもあり、一旦真上に飛び出てから向きを変えるため、あまりに近い目標に対しては発射できない、という欠点があります。
 このため、RAM(Rolling Airframe Missile)は旋回式発射機を使用しています。一方で、同じ個艦防空に供されるESSMはVLSから発射されます。初期のRAMは最短射程0.8km、最大射程が9km程度だそうです。VLS方式に由来する最短射程は5km-10kmくらいかな、と思います。
 RAMは旋回式発射機に特有の、指向時間という問題がありますが、基本的にRAMは最後の砦であり、RAMの前にESSMやSM-2による迎撃を試みています。例えばSM-2で迎撃できずにESSMが必要になった場合は、RAMを使うことに備えて旋回を開始する、といった運用にすれば、ESSMの結果を待つ間に旋回を行えるはずです。
 高速な対艦ミサイルが低高度で接近してきた、という場合は旋回が間に合わない可能性もありますが、その場合はVLSから発射しても姿勢変更が間に合わない距離のはずです。

***

 最強の戦闘艦を作るにはどんな装備があればいいか、というネタは面白いのですが、最近は複数の戦闘システムを組み合わせて能力を拡張する、という方向に発展しています。例えばSM-6では水平線以遠まで発射できますが、当然水平線の向こうはイージスのレーダーでも見えません。この場合、目標を探すにはE-2等からのデータリンクを使用します。そのため、SM-6の射程を活かすにはE-2のような観測手段が必要であり、E-2を運用するには陸上の飛行場か、洋上の航空母艦が必要になります。そうなると、戦艦○○にVLSを追加する、という話では済まなくなります。

「僕が考えた最強の戦闘艦」という妄想を行う場合、どういう制約を課すか、といった事も決める必要があります。例えば、「仮想装備も使える」という、いわば「現代兵器縛り」を外した場合、光速で攻撃できるレーザー(光学)兵器が最強の装備になってしまいます。攻撃されたことがわかるのは攻撃を食らってからですし、予防的な回避行動も意味ないのですから、光学兵器が最強なのは当然でしょう(ま、銀を蒸着するとかいろいろ対応はできますが)。
 逆に、「現在実用化された装備のみしか使えない」となった場合は、タイコンデロガ級やアーレイ・バーク級といった、現存する戦闘艦の中で一番強いのはどれか、という話になってしまいます。
「僕が考えた(ry」なので、このあたりはてきとーに縛ったり、緩めたり、自由にすればいいのですけども。。
 とはいえ、やはり「最強の戦闘艦」では、現在でも戦闘艦単艦では能力が不足している以上、単艦では「最強」とはいえなくなってしまいます。そうすると、最強の組み合わせは何になるか(空母にE-2を載せてタイコンデロガにSM-6とトマホークを満載、とか)みたいな話になってしまいます。
 面倒くさい。。。(by コンゴウ)

***

 なお、ここに書いたことはwikipediaからてきとーに拾ってきて自分なりに咀嚼した情報なので、間違ってたらごめんなさい。(おまじない)

2017年12月17日日曜日

あなたが落としたのは

 金の斧ですか? 銀の斧ですか?
 それとも、このハイカーボンスチールを鍛造した斧ですか?

 正直者のあなたにはこのハイカーボンスチール鍛造の斧を差し上げましょう。あなたが落とした方の斧ですか? 見つけられませんでした。。。
 このようなものは受け取れない? ご安心を、親戚筋の鍛冶屋が時々送ってくるのです。ウチは石油ストーブにしたばかりで…

 ***

 という電波を受信した。

 どうも、お久しぶりです。生存報告まで(というほど開いてないけど)。

 最近は見てないけど、ナショジオの工業系番組で工具とか紹介するときは、ほとんど高炭素鋼だよね。高炭素鋼を讃えよ! あ、いや、叩けよッ! 鉄は熱いうちに!

2017年12月12日火曜日

HIP

 ここ何日か、他のことにかまけてジンバルが全く進んでいません。はやく再開しないとソースコードの読み方忘れちゃう。。




 青が人工衛星、赤が恒星です。
 恒星もマウスオーバーで名前が表示されますが、星の名前のデータベースを探してくるのが面倒だったので、とりあえずヒッパルコスカタログのIdを表示しています。

 天球の方位は、0時が北、3時が東、という感じです。実際、TLEでは東の静止軌道がスカスカになっています。
 一方、北を0時、東を9時で表示するプラネタリウムソフトと、この図の星の配置が一致します。ということは、恒星位置は東西が逆に処理されている可能性が高いということです。


 今のところ、右画面でHIPを表示すれば連動して左画面でも表示されてしまいます。しかし、この挙動はかなり使いづらいです。例えば、右画面は衛星だけ、左画面は恒星だけ、といった表示ができれば使いやすい気がします。
 とはいえ、そうするとContextMenuItemの使い回しができないという問題が出てきます。もしかしたらDeepCopyとか使えばなんとかなるかな?
 開発PCはディスプレイが広いので、2画面だけじゃなく、他にも色々表示させたくなります。例えばADS-Bを表示する予定がありますが、天球にADS-Bを表示するのと、PPIに表示するのと、他に恒星や衛星、コンフィグ画面等で、6画面くらい欲しくなります。
 4k液晶なら18枚くらいは余裕で表示できますが、ノートPCだと2画面が限界です。
 FormにMFDを1個だけ配置して、必要なだけWindowを表示する、という方法もありますが、そうすると上記のそれぞれでモードを切り替える、というのが面倒になります。
 このあたりはうまいやり方を探す必要がありそうです。

 あと、表示の座標もちゃんと確定しておく必要がありますね。
 戦闘機のディスプレイなら北が0時、東が3時が自然だと思いますが、今回は高仰角がメインの用途なので、上から見下ろした表示は向かないかもしれません。
 他にも、ジンバルが向いている方向が6時になるような表示とか、そういうのも欲しくなります。
 とはいえ、あんまり複雑にすると作るのが大変だし、という問題なども有って、後回しになっています。後回しにすると、修正作業が大変になって、結局途中で辞めるという結果になりそうな気も。
 行き当たりばったりはダメですね。

2017年12月10日日曜日

メモ:SketchUpで面が切断される




 SketchUpを使っていると、上の画像のように、物が切断されて表示されてしまうことがある(時空が乱れた感じ)。
 根本的な解決方法は見つけていないが、とりあえず、ツールバーのカメラ→視野を選択し、視野角を狭くすれば多少改善する。
 ただしこの方法では遠近感が変化してしまうので、イメージ図を作ったりといった場合は、適切な視野角に戻すこと。


 根本的な原因は、3Dグラフィックでは、"最短撮影距離"と"最遠撮影距離"というものがある(名前は間違えてるかも)。最短撮影距離はカメラのレンズにもあるが、それとは全く別の問題。
 コンピューターグラフィックスでは、あまりに遠い物体は「遠すぎて見えないはずだ」という仮定に基づいて、描画処理を省略する。見えないものの色や影を計算したところでリソースの無駄だからね。
 同時に、あまりに近すぎる物体も、画面に表示しきれないし、ポリゴンの粗さが目立ったり、いろいろな理由により、描画を省略する。

 SketchUpの場合、最短撮影距離が長すぎるので、視点で物体に近づくと、物体の描画が省略されてしまう。視野角を変更すると、同じ範囲を描画するのでも、カメラの位置が変わり、視野角を狭くすれば、カメラを遠くに配置する必要があるから、最短撮影距離を相対的に縮めることができる。

 あまりにも視野角を小さくすると、パースペクティブが無くなり、平行投影に近づいていく。とりあえず、18度とか15度くらいがいいかな、という感じ。
 裏技?として、視野角を170とかにすれば、魚眼レンズで撮影したような感じになる。もちろん、時空の乱れはより悪化するが。

イージス艦のCICのスケール

USSTiconderoga(CG-47)CIC

 タイコンデロガ級イージス巡洋艦1番艦 CG-47"タイコンデロガ"のCICの写真。
 1984年3月1日、あるいは1984年3月13日17字29分撮影(前者はファイルの説明に書いてあった日付、後者はディスプレイに表示されている日時)。


 左から2番めのディスプレイ、AAW(対空戦闘)の状況表示だが、レンジは256NM(海里:ノーティカルマイル/Nautical Mile)と書いてある。
 レバノンで作戦行動中の写真だそうだ。
 ということで、ほい、レバノン周辺の衛星写真。


 黄色い円は、半径256海里の円。おおよそ、ディスプレイに表示された海岸線と一致している。
 ということで、RANGE SCALE 256NMというのは、「半径256NMの円に内接する正方形の範囲」(正方形:ディスプレイのアス比に依存?)という感じらしい。対角で512海里、辺方向で約360NMの範囲を表示している?


 表示されたアイコンは海軍戦術情報システム(NTDS: Naval Tactical Data System)に準拠しているが、wikipediaのアイコンとは違い、単色で表示されている。
 味方は円、的は辺が斜めな正方形、敵味方不明は辺が水平・垂直な正方形、中立は辺が水平・垂直な多角形、で表示される。
 海軍のシステムなので、洋上目標(船舶)が基準。船なら円形、航空目標なら円の上半分だけ、水中目標なら円の下半分だけ。ミサイルなら噴射炎っぽい記号が増えたり、ヘリコプターならローターっぽい記号が増えたり。魚雷は円形に水平線が追加される。魚雷は水中目標ではなく、水面目標の扱いになってる。地上目標はクロスで表され、仲間はずれ感がすごい。
 上の写真では、マップに水上目標や空中目標がいくつか書いてある。地上目標のアイコンもある。いくつかの空中目標は破線で表現されてるけど、どういう意味なんだろうか。
 ASWディスプレイでは、対潜戦なので水上だと思うんだけど、水上にも地上目標のアイコンが有る。あと円形の味方や正方形のアンノウン以外に、斜め四角の敵アイコンもいくつかある。

 ASWディスプレイはスケール64海里で、海岸線の形からして、左上はキプロス島の半島の付け根南側で、右下の線はレバノン南西部(中西部?)の海岸線と思われる。画面の中央部大部分は洋上で、画面の中心は34d8'N、34d24'Eあたりかな。
 左上の海岸線上から伸びる線は長さが25海里くらいかな?25海里/1分なら約2800km/h(1500kt)、25海里/5分なら約550km/h(300kt)、25海里/10分なら約280km/h(150kt)くらい。
 同じ画面の洋上目標は、最大で3分の1くらいの長さなので、それぞれ500kt、100kt、50ktくらいか。船舶と考えると、アーレイ・バーク級で最大30ktくらい、フリーダム球でも最大50ktくらいなので、80年台前半ということを考えると、もっと遅くても良さそう。となると、30分後として30km/h(16kt)とか、長いやつは90km/h(50kt)とか? でもたかが100km/hでこの長さだと、イージス艦のコンセプトだった、対艦ミサイルの迎撃とかをやろうとすると、線の長さはこの10倍くらいになってしまう。

 必要に応じて速度スケールは変更できるのかもしれないけど、それにしては速度の説明が書いてあるようには見えないし、そもそも頻繁に変更しては状況認識に問題がありそうだから、ちょっと考えづらい気がする。

 うーむ、謎は深まるばかり。。。

2段ベッド


 2x4材で下にテーブルの入ったベッドを作ろうと、いろいろ考えています。こういうのって正式名称はなんていうんだろう? 上下で寝るわけじゃないから2段ベッドじゃないし、空間的には3段分あるし。

 今使っているベッドも、形状は同じ感じですが、下側の空間がうまく活用できていません。ということで、まるっと作り変えてしまえ、と思い始めました。
 ということで、少し大きめの机にして、死蔵してる24インチを1枚出してきて、全体で3面ディスプレイにできないかな、と考えています。GTX950とGT520の計2枚差しだけど、3画面ってできるのかな? できたとしても、GeForceって1GPUでマルチディスプレイを組むと変なエラッタが出たはずだけど。
 探せばもう1枚くらいGT520出てくるはずなので、どうせWebブラウザやメディアプレイヤーくらいしか使わないから、PCI Ex x1でも問題ないと思ってますが。グラボ3枚差しかぁ。すげーな。内2枚はGT520だけど。


 SketchUp上で見ると、はしごがかなり邪魔っぽいですが、実際の位置関係で柱の横に座ってみると、あんまり気にならない感じです。顔から柱まで40cmくらいあるので、多少圧迫感があるかな、という程度。どうしても気になるなら、2ディスプレイにして余裕のある配置にしてもいいですし。

 寝る部分は、一応せん断応力を減らすような組み方にしています。すのこ状のフレームも上下に重なった形状にして、圧縮応力になるようにしています。が、youtubeの動画とか見てみると、みんなビスのせん断方向で作ってるんだよなぁ。意外とビスって高強度なのかもしれません。でも心配なので、やっぱり圧縮で作りたい感じです。
 四隅で圧縮ですが、すのこは2x4と2x6をそれぞれ2本ずつ縦で支えてるので、耐えれるはずです。本来は破壊試験とかして勘所を掴んだほうがいいんでしょうけど。
 一方で、はしご部分はビスのせん断だけで支えています。寝るところが落ちるとPCとか損失が大きいですが、はしごが壊れても自分が落ちるだけだし、はしごに乗ってるときはある程度即応でバランスを取れるだろう、という期待もあります。重心を考えると確実に自由落下で背骨から落ちるんですけどね。
 あとスノコは静荷重ですが、はしごは動荷重なので、はしごのほうが強度的には厳しいです。また外側に引っ張られる方向の荷重があるので、ちゃんと作るなら、踏み台が柱の向こう側になるように作るべきかな、という気もします。まぁ、それは壊れたときに考える、ということで。古いハシゴとか釘2本で止まってたりしますしね。多分そこまで気にすることじゃないんでしょう。


 SketchUpなので、日照のシミュレーションができます。今の案では、10月から4月あたりまで、モニタ上に日照があります。カーテン閉めるなりすれば多少は改善するでしょうし、イザとなれば黒い模造紙でも窓際においておけば、入射エネルギーは熱に変換しつつ、十分遮光できそうな気がしてるのと、それでもダメならアルミ蒸着シートを使えばいいだけなので、この部分はあまり気にしていません。
 それよりも、現状の窓際に机を配置していて、寒気が入ってくる、というほうが厳しいです。左右が板で囲まれ、窓際はサッシの隙間があって、直接足に気流が来る配置なので、かなり寒いです。


 ということで、目標は寒い時期に間に合うように作ることですが、どうなるかなぁ。
 材料はホーマックで買えますし、垂木でエアガンのターゲットを色々作ったときに買った卓上丸ノコがあるので、材料の切断も気軽にできます。
 ということで、ベッドを分解して搬出し、新しい材料を搬入して組み立てて、を1日でやりきる覚悟ができれば、いつでもできるはずですが、その気になるまでが大変だなぁ。
 一応、PCやHDDレコーダーも移動する予定ですが、これは現状の配置のままでもベッドを入れ替えるのはできるはずなので、そのあたりはあんまり心配していません。心配事があるといえば、3ディスプレイ化とかするとコンセントが圧倒的に足りない、というくらいでしょうか。ただでさえ古い家でテーブルタップ大量に使ってるのに。。。
 そういえば、小学生の頃は切り売りの電線と埋め込みのコンセントを買ってきて配線したりしてたので(どんな小学生だw)、ベッドにコンセントを大量に生やしてもいいんだな。机の天板はコンパネを使う予定ですが、奥の隅はディスプレイを斜めに置くので、デッドスペースになります。その部分に穴を開けて、コンセントを設置するとか。まぁ、法的な云々は置いておいて。。。


 上の図ではPCだけですが、他にもHDDレコーダやXbox 360を置かなければいけませんし、近いうちにXbox Oneも買う予定なので、そのスペースも作る必要があります。しかし机の上はかなり厳しい感じで、かと言ってスノコの下の空間を使おうにも、そこも厳しそうな気がしています。じゃぁ足元かというと、あんまり足に近いところに置くと蹴飛ばしそうで怖いです。
 あとせっかくなので、寝ながらにして手が届くような棚もほしいなぁとか、色々要求が増えています。

***

 まだ先の話ですが、中華CNCを買おうかと思っています。amazonで3万円くらいで売ってる、CNC2417とかですね。しかし、今はどこにも置くスペースが無いのと、買っても使うかなぁ、という心配が有って、かなり消極的です。
 でも、ベッドの下の空間を有効に使えるようになれば、空いたスペース(今PCを置いてる位置)にCNCを置けるくらいの空間は確保できるはずなので、そうなったら買いたいなぁって。

F-16風(続きのつづき)


 とりあえずジンバルのコントローラを作っています。
 いちおうTLE(人工衛星)とHIP(恒星)のボタンがありますが、HIPは未実装です。

 MENUを押せばメニューページになり、天球表示以外にコンフィグ画面があります。コンフィグは今のところシリアルポートの接続/切断だけです。ポートの選択とかは別のタブに作っています。

 TLEをONにすると、直下にあるテキストファイルに入っているすべての衛星が表示されます。今のところ1800個ほどでしょうか。1800個のTLEの 位置計算、方位仰角計算、Graphicsへの書き込み、をやっても、10-25msecくらいしかかかりません。衛星1個あたり10マイクロ秒で計算してる、ということでしょうか。確かに衛星の計算って複雑なだけで計算量は多くないんだけど、いくらなんでも早すぎでしょ。ARMだと、計算だけでも1msecかかるのに。

 天球全体で見てみると、静止軌道がかなり濃い感じです。しかし、東側は太平洋上なので、静止衛星は少ないですね。

 ディスプレイにマウスカーソルを重ねると、一番近い衛星の名前が表示されるようになっています(左側のディスプレイにカーソルを重ねています)。
 今のところ、ディスプレイをクリックすれば、無条件にジンバルがその方向を向きます。本来であれば、マニュアル操作ならジンバル指向、TLEモードなら衛星を選択して継続追尾、HIPモードなら恒星を選択して継続追尾、みたいな感じにするべきでしょう。


 衛星1800個ならテキストファイルでも500KiB未満ですから、SDカードに楽勝で入ります。HIPカタログもテキストデータですが、恒星約12万個分でも容量は50MB程度です。SDカードに余裕ですね。
 TLEの計算自体はマイコンでできることも確認済みなので、スタンドアロン動作は問題ないはずです。恒星位置の計算はマイコンではしたことないですが、あまり計算量は多くないですし、衛星ほど素早く動くわけでもないので、なんとかなるでしょう。


 TLEは、一応、データ長は固定ですが、衛星番号は間欠なので、衛星番号から直接ファイル位置を計算することができません。一番簡単なのは、TLEフォルダに、TLE1個毎に衛星番号をファイル名にしたファイルを1個ずつを作る、という感じになると思います。FAT16なら6万個くらいファイルを作れるらしいので、デブリとかを除けば、十分収納できます。

 HIPは空白埋めの固定長なので、特定のデータを取り出すのはそれほど大変ではないはずです。HIPもやはり間欠データですが、12万セットに対して100セット程度の不足なので、HIP番号を受け取って、目的のデータが来るまでファイルの前方にシーク、という程度でも問題ないはずです。もしそれが許容できないなら、ヌル行を追加したテキストファイルを作ればいいだけですし。


 ということで、なんとなくコントロールソフトも見た目はちゃんとしてきました。でも、かなり面倒です。
 最初は「参照渡しだから1個作れば複数の表示ができるね!」と思ってたんですが、その方法では、片方でズームするともう一方もズームする、という感じで、かなり使いづらいです。一応、表示内容は別々に選べるので、それだけが救いです。
 しょうがないので、ディスプレイごとにインスタンスを作って、別々にズーム・移動ができるようにしましたが、個別に登録しなければいけないし、UIハンドラも個別に作る必要があるので、面倒です。

 あと、MFDからペイントイベントを受け取ったら、現在表示中の画面のレンダーを呼び出して、そのレンダーは表示内容に応じて下位レイヤーのレンダーを呼び出して、という感じになっています。
 下位レイヤーでは、例えば天球レンダーからTLEレンダーを呼び出した場合、衛星位置は天球レンダーの表示位置に応じて衛星位置も表示することになります。しかし、天球を拡大しても、フォントは拡大されずに常に同じ大きさで表示する必要があります。さもなくば、天球を拡大すると、衛星名が画面の外に飛び出してしまいます。これは衛星のアイコンも同じで、ズームしても衛星のシンボルは一定の大きさで表示されたほうが便利です。
 ということで、衛星の位置を表示する際は上位レイヤーの座標変換行列を使い、衛星の名前を表示するときはスケールが違う行列を作り、という動作が必要で、しかも衛星の情報(軌道高度とか)は画面の左上とかに固定されたほうが読みやすいでしょうから、そういう表示は新しく行列を作って、という感じの処理を、都度書く必要があります。
 これがかなり手間なので、もっとスマートな方法を使いたいのですが、なかなかいい方法が思いつきません。

 こういう処理は、例えばUnityの3Dゲームが近いかな、という気がしています。ゲームフィールドは3Dで表示し、キャラの名前等は相対位置で2D表示し、ステータス等は絶対値で表示し、という感じで。
 ということで、ゲーム制作関係の参考書とかを読めばいいのかな、とも思ったりしますが、多分Unityは抽象化しすぎて参考にならないでしょうから、ゲームエンジンを作るような本が必要なのかな。


 そういえば、F-15ってASAT兵器を使えるけど、MFDに衛星を一覧表示したりするんだろうか?イージス艦もやはり対衛星ミッションを行っているから、衛星の表示もできるはずです。
 F-15の場合は、飛行前に地上で目的の軌道を入力して、飛行時はそれ以外の物は表示されないようなインターフェースになってるはずです。ASATの試験はF-15Aで行われましたが、一人乗りで操縦しながら衛星を選択するとかは大変ですし、そもそもF-15Aに気が利いた表示ができるシステムを載せれるとも思えないし。

 イージス艦の場合は、NTDSのアイコンで目標の速度や移動方向がわかるようになっていますが、低速なヘリコプター等も表示することを考えると、同じスケールでマッハ25とかを表示すると、速度スケールが画面外に出てしまい、かえって速度がわからなくなってしまいます。低速な目標から超音速ミサイルまでを表示したりすることを考えると、速度スケールは対数スケールかな、という気もしますが、常識的に考えれば、こういう表示は「何分後の未来位置まで引いた直線」とかでしょうから、やはり対数スケールってことは無いでしょう。
 例えば5分後の未来位置なら、ISSの場合は5分で日本列島縦断するかしないかくらいなので、1画面で日本を端から端まで表示できるイージス艦のディスプレイなら、衛星も十分に表示できそうな気がします。
 特に弾道ミサイルを追尾できるイージス艦では、ミサイルの現在位置、落着予想地点、迎撃までの猶予、といった情報を表示する必要があるので、少なくともBMDの際の意思決定が問題なく行えるくらいの表示はできるはずです(って、何日か前にもこんな話書いたな)。

 イージスのCICで衛星がどのように表示されるかなんて、わざわざ隠すことでもないでしょうが、かと言って、わざわざ表に出すことでもないでしょうから、当分は見れないだろうなぁ。最近だとICBMとか色々で、イージスで宇宙空間見ることも多いだろうし、センシティブな話題だろうからなぁ。

2017年12月8日金曜日

F-16風(続き)


 24インチFHD(本物の3割増しの大きさ)でスイッチを押してみたけど、意外と押しづらかったのでボタンを大型化したのが前回からの見た目の違いかな。前回はclassだったけど、UserControlになってたり、いろいろ変わってるのだが。

 ボタンの表示や操作内容はContextMenuStripで渡すが、C#は参照渡しなので、複数のパネルで同じ内容を表示できる。1箇所でも違う内容を表示したいなら面倒だけど。
 本物のF-16等でも、左右のMFDで全く同じ内容を表示できるので、複数のパネルで操作できるのは実物準拠という感じ。実機の場合は、もし片方が壊れても大丈夫なように、万が一片方が被弾しても大丈夫なように、という事なんであろう。

 ただし、片方のpaintイベントがもう片方に波及しないので、片方でCheckedを変えたりしても、もう片方は反映されない。paintハンドラでもう片方をrefreshすると、無限ループになってしまうので、うまいやり方を考えないと。
 現実的には、ディスプレイの内容は20fpsとか30fpsで書き換えることになるだろうから、タイマで定期的にrefreshすれば無問題、という気がする。

 1280x800のノートPCでは、ディスプレイを2面表示することは可能。
 左右で別の情報を表示するようなインターフェースにしてもいいし、片方を情報表示、片方をコンフィグページ、みたいにしてもいい。

 ジンバルのコントロールパネルを作ってるが、マニュアル操作をどうするかが問題になってる。アナログ入力があればいいんだが、C#で簡単に使えるアナログUIは意外と少ない。Xbox360のコントローラであればXNA経由で使えるが、すでに入手性が悪くなってる。Xbox oneもXNAから扱えるんだろうか?
 一応C#でもジョイスティック等は読み出せるが、製品によってボタンやスティックの割当が違うから、このあたりをうまく吸収してくれるように作る必要がある。


 さっき、一瞬、F-15のディスプレイも調べてみたが、あまり良くわからなかった。
 F-15A/B/C/Dはいかにもなアナログ計器のコックピットだが、F-15Eではグラスコックピット化されている。
 EF(E型フロント席)はMFD3面と、HUD下に6行キャラクタディスプレイがある。ER(E型リア席)はMFD4面と、右側に小さなパネルがあるらしい。ERは兵装士官(WSO: Weapon Systems Officer)が乗るが、戦闘機とは思えないくらい簡素化されてる感じ。操縦桿があるのが飛行機らしい点。もっとも、F-35は電源OFFならのっぺらぼうだが、アレは「そういうもの」という思い込みがあるし。

 F-15の操縦桿には親指で操作する「キャッスルスイッチ」という物がある。滑らないようにする突起が、西洋の城の見張り台(身を隠す突起があるやつ)に似ているから、「キャッスル」スイッチと言うんだそうだ。
 ゲーム用のジョイスティックでは、ここにはPoVスイッチ(あるいはハットスイッチ)と呼ばれるスイッチが付いていて、主に視点操作に使われる。これは基本的に「開放」と「操作」の2値を受け付ける(開放と8方向で9値?)。
 F-15では、これはFLIRの視線方向操作に使うらしい。ということでゲームと同じく視点操作なのだが、ON/OFFで望遠のFLIRを操作するのは大変だろうから、おそらくアナログ入力になっているはず。
 一方で、操縦桿にはハットスイッチみたいなスイッチがもう一つ有って、これはトリムの調整に使われるらしい。これはアナログ入力が必要なほど敏感じゃないはずだから、2値(9値?)で足りるはず。


 ジンバルの操作でも、やはりアナログ入力がほしいのだけど、どうやって作るかなぁ。
 スタンドアロン重視ならマイコンにジョイスティックを追加すればいいんだけど、PS2のコントローラに入ってるようなやつでは気分が出ないし、かと言って工業用のタイプになると値段が2桁上がってしまう。
 F4ならUSBホストもハードウェアでできるけど、USBを実装するのはとても面倒くさい。気がする(USBって使ったこと無いので不明)。
 適当なUSBジョイスティックのXYをC#で読めばいいじゃないか、とも思うけど、せっかくジョイスティックを使うならHOTASっぽくしたい。スロットルデバイスは持ってないから、HOSになっちゃうけど。

 他の方法としては、JHMCS風の「見た方に向く」とか、短SAM風の「覗いた方に向く」とかもあるけど、どちらも作るのは面倒そう。

 当面は、MFDで「アナログモード」みたいな設定を作って、それがtrueのときにMFD上を左クリックしたままドラッグしたりすれば、それが入力になる、みたいな感じかなぁ。
 PC画面なら本物のMFDと違って、画面座標の直接入力が可能だけど、あんまり多用しすぎるとプログラムが大変になる。
 これはF-35でも同様なはず。もっとも、F-35は振動や加速度の条件が厳しい戦闘機のシステムだから、「振動で指が動いてしまった」とかで誤った入力にならないように、フリックやらスワイプやらの操作は無いらしい。ということで、画面をタッチした座標と、単押しか長押しか、くらいの判定しか無いはず。

 暖かくなるまでに動くようになればいいから、とか余裕かましてたけど、大変そうだ。

2017年12月7日木曜日

F-16風の


 F-16のMulti Function Displayっぽい画面をC#で作ってみました。もちろんボタンは操作可能です。


 F-16のMDFを調べてみると、Honeywellの表紙含めて4p分くらいのPDFが出てきました。日付は2006年になっています。

 F-16A/Bではコックピットにはレーダー/HUDレピータのディスプレイが1基と、兵装用の9セグ(12セグ?)LEDx5行のディスプレイが使用されているようです。
 F-16C/D(Block 25)では単色のディスプレイ2枚に置き換わり、多用途化されたようです。さらにBlock 5xではこれが多色化されたようです。
 UAEに輸出されたF-16E/F(Block 6x)では大型のカラータッチ液晶を搭載したようですが、写真を見つけられませんでした。大型タッチ液晶というと、同じロッキード・マーティンのF-35が思い浮かびますが、おそらく同じようなものだと思います。


 先のカタログはカラーMFDのものですが、解像度は480x480pxで4x4インチだそうです。密度的には、24インチFHDの3割増し、18.5インチFHDや13.3インチWXGAくらいです。11年に買ったノートPCが13.3インチWXGAなので、民間の普及品よりちょっと高密度、くらいでしょうか。
 ただしコントラスト比は航空機用だけあり高く、5750対1らしいです(読み間違えてるかも)。また輝度も非常に高く、約790cd/m^2だそうです。参考までに、この間買った4k液晶(HDR非対応)は300cd/m^2でした。
 また、戦闘機では夜間はナイトビジョンゴーグルを使用しますが、新月の星明りだけで敵の戦闘機を見つけれるくらいの高感度なものですから、直接高輝度な画面を見てしまっては簡単にリミッターが働いてしまいます。なので、バックライトにも相当なダイナミックレンジがあると思われます。カタログにも「under all lighting conditions, from night-vision goggles to full sunlight」と書いてあります。簡単に訳せば、「直射日光から暗視装置まで、どのような光環境でも」みたいな感じでしょうか。

 液晶の起動には1分@-20℃と、ちょっと時間がかかります。とはいえ、ウチの液晶でも冬に1日家を開けて室温が10℃を下回ってしまうと、自己発熱でコントラストが正しくなるまではしばらくかかりますから、-20℃で1分というのはかなり優秀かもしれません。ヒーターでも入ってるのかな。

 この液晶は13ポンド(約6kg)のモジュールですが、映像を生成するシステムが他に必要になるようです。映像を生成するモジュールは31ポンド(約14kg)で、メインのシステムにはPowerPCベースのカスタムCPUが使われているようです。クロックは400MHz、メモリは4MB(8MBまで増設可能)、バッテリーバックアップされた64MBのメモリ(オプション)、といった感じで、更にグラフィック用に240MHzのPowerPCが乗っていて、こちらは32MBのRAMと16MBのFlash、16MBのテクスチャメモリと15MBのフレームメモリが乗っているそうです。
 メインの計算モジュールより描画モジュールのほうがメモリが大きいあたり、グラフィックの負荷がいかに高いかが伺えます。
 この描画モジュールはC言語で開発されているようです(C言語で開発可能、の意?)。メインシステムはJOVIALとCだそうです。JOVIALは聞いたことも無かったのですが、F-15やC-130、F-117等、かなりいろいろ使われているようです(wikipediaで、プラットホームに、other legacy systemsと書いてあって笑ってしまった)。

 このシステム、5GB(拡張可能)のストレージを持っており、航空機に搭載したままで書き換えが可能なようです(地上で整備士が書き換える、くらいの意味でしょう)。

 地図の倍率は125万分の1と50万分の1の2段階を選べるようです。125万分で127km四方、50万分で約51km四方、くらいの範囲を表示できます。125万分は巡航で9分、50万分は同4分くらいの距離でしょうか。50万分では1pxあたり100mくらいですから、遷音速なら1秒に3ピクセルくらいの分解能です。
 CASに使うには50万分では荒いし、洋上に出て迎撃するには125万分でも狭いし、みたいなとても使いづらそうな気がしますが、そもそもF-16のコンセプトからすれば、これくらいでも問題ないのでしょう。
 表示モードは北が上、ヘディングが上の両方を選べるようです。

 インターフェースはNTSCといった身近な物がある反面、MIL-STD-1553が5本入力可能だったりと、軍用な面もあります。また、イーサーネット100BaseTでデータ通信ができたり、デバッグ用に10BaseTが付いてたりもするそうです。

 他にも、画像をアップロード/ダウンロードする機能があったり、地形を3Dレンダリングで表示できたり、といった機能もあるそうです。


 興味本位で見つけたペラッペラなパンフレットくらいのPDFですが、真面目に読んでみるといろいろおもしろいですね。

***

 さて、一番最初のC#のヤツですが、コントロールではなく、クラスとして作っています(後から気づきましたが、これはコントロールとして作るべきでした)。
 コンストラクタにはContextMenuStripを与えており、ボタンで操作できる項目はVisualStudioのGUIで編集可能です。
 もちろん項目のボタンを押せばその下の階層に移動できますし、上に戻るタグを付けておけば勝手に階層を遡ってくれます。
 今のところ、ボタンの数(20個)以上の項目が有った際は、それ以上は表示しない、という挙動です。ContextMenuStripは動的に生成可能ですが、動的に作って20個超えても知らないよ、というスタンスです。
 クラスの中でClickハンドラを追加して移動していますが、もちろん外部でClickを登録しておけば、それに応じて処理もできます。
 またMDFの描画イベントを外にも出しているので、必要に応じて外部で描画できます。同時に現在選択しているToolStripMenuItemも参照できるので、外部はそれに応じて描画内容を変更する、という動作にしています。

 もともとは気分転換に作り始めたGUIですが、タッチ液晶で使えば意外と便利そうな気がします。
  もうちょっと色々使いやすいようにして、FSXの情報を表示したり、ジンバルの制御ソフトに組み込んでも面白いかな、と思っています。


追伸
 Arma3でマップに使えるアイコンみたいなやつ、MIL-STD-2525Bという規格らしい。2013年にオープンソースとして開放された模様。

 Test Multipointをクリックするとアイコンが表示される。

2017年12月6日水曜日

星座の境界

 星座(天球を88分割した領域)の境界線データ。

 IAU(国際天文学連合)のページに有る。
 The Constellations | IAU
 Charts and tablesにTXTというリンクがあるが、これに境界線の赤経赤緯の点がリストになっている。

 図にするとこんな感じになった。


まぁだいたいこんなもんかな、という感じなので、大きく外してはいないはず。
 最初は4等星より明るい星を表示してたけど、6時/20度の領域に1個も星がなかったので、4.5等星以上に変更した。この領域ってこんなに星が少ないところなのかな。

 それにしてもこの分割、怪しい古代文明の遺跡にある扉の鍵みたいな感じだ。88個のカケラを集めなければ入れないボス部屋、とか。

 星座の星をつなぐ線のリストとかもほしいけど、どこにあるんだろう。プラネタリウムソフトによって表示が違うので、統一したデータとかはないのかもしれないけど。

2017年12月5日火曜日

じんばる

 ファームウェア・コントロールソフト共にジワジワと進化しています。


 とりあえず天球を上下2分して仰角と俯角の表示をつけています。あと影になってるけど、モーターの速度を表すグラフもあります。
 他にいくつかのパラメータを設定したり、RTCを設定する機能とか。
 TLEの指定はコントロール側にはつけていませんが、ファームウェアでは実装済みで、ターミナルソフトを使えば指定できます。RTCで現在時刻を基準に計算できますが、観測地点はまだべた書きの状態です。TLEと観測地点をコントロール側で指定できるようになれば、最低限使えるようにはなります。

 とりあえず仰角と俯角の図は同じ大きさですが、基本的に俯角で使うことはないので、このあたりはもうちょっと工夫したいところ。
 あと天球図は色々機能を追加したいです。例えば可視の人工衛星を表示したり、スターカタログを表示したり、それらをクリックして目標に指定できるようにしたり。
 ただ今回はスタンドアロンで動くことを主目的としているので、PC側のソフトばっかり強化するのもなぁ、と思っています。ま、結局メイン機材はWebカメラなので、PCは必須になるんですけども。

 前回作った時は、マイコンはステップ位置を受け取ってモーターをその位置に指向するだけの機能でした。それ以外の計算はすべてPCで処理していたので、自然な流れでコントロールソフトが肥大化していきました(プラグインとして実装して、TLEやスターカタログ、ADS-Bをデータソースとして使えるようになりました)。ただ、そのときはSTM32F1の84MHzだったので、あまり凝ったファームウェアは動かないだろう、という予想があったので、PCメインとしました。
 今回はSTM32F4の上でC++で書いているので、ある程度複雑な処理も可能になっています(フルスペックのC++じゃないので、制限も大きいですが。new deleteが使えないとか)。自前で計算できるので、TLEやスターカタログなら(データの読み込みを別にすれば)スタンドアロンで処理できます。一方で、ADS-BはPCのサポートが必要になりますし、満足なUIを作るにはやはりPCで作るのが楽でしょう。

 そういえば、Cortex-M4FのSTM32F4とはいえ、実際はdoubleのソフトウェア演算ですから、実質的にはSTM32F1との違いはクロック周波数だけのはずです。で、衛星位置の計算が1msec未満ですから、F1でも2msecで計算できるはずです。ということは、STM32F1でも十分にスタンドアロンで衛星を追尾できそうですね。


 開発環境は4k液晶ですが、実運用のときはノートPCを使う予定で、画面解像度は1280x800です。なので、制御ソフトもその大きさで足りるように作る必要があります。今の制御ソフトがだいたいそれくらいの大きさなので、コレ以上は大きくできません。
 パラメータ画面とか、目標選択画面とか、タブにわけるにしても、かなり狭い気がします。天球を表示してスターカタログとか衛星をクリックできるようにするには、かなり心もとない解像度ですね。

 例えば初期のイージス艦は、おそらく低解像度なブラウン管の見づらい画面なわけですが、その画面でも最大で200個程度のターゲットが表示される想定のはずで、そういったときに必要な情報を表示できるようなインターフェースというのが作られているはずです。高度や速度の情報を含め、脅威度の推定とかも適切に表示できているはずですが、どうやってるのかなぁ。
 もっとも、その表示がうまくできなくて民間人およそ300人の犠牲が発生してしまった、といえるのかもしれませんが。実際、当該機が上昇しているにも関わらず、それを監視していた乗員は降下していると判断した瞬間がありました。ということは、その時点でのイージス艦では、そのあたりの情報は人間が判断しづらい表示だったということでしょう。


 とりあえず、実際に運用に入るのは暖かい季節になってからですから、しばらく時間があります。その間にいろいろと考えてみようと思います。

メモ:軌道計算のコスト

 STM32F4でTLEの計算、最低限方位仰角を計算するのに1msec未満@168MHz。ここからジンバルの補正とかが必要だけど、そんなに計算コストは高くない。ただしISSの軌道なので、離心率が大きい軌道では収束まで時間がかかるから、もうちょっとかかるはず。
 STM32F4はFPUを内蔵しているが、それは単精度で、軌道計算には全く足りない。例えばTLEは時間を日単位で与えられるから、年末になると精度は80秒程度に悪化する。8km/sec*80sec=640kmの誤差となり、高さ400kmに対して誤差が大きすぎる。
 そこで今回はすべての計算をdoubleで行った。本来は精度が不要な部分をfloatにするといった工夫をすべきだが、今回は動作確認が最優先。それでも1msec以内に計算できるので、しばらくはこのままで。

 ワンチップで軌道計算ができるので、あとはGPSで自分の位置と時間を得て、SDカードからTLEを読み出せば、スタンドアロンで軌道計算を行える。TLEはSDカードに入れるようになるはずなので、数日置きに更新する必要がある。場合によっては、FlashAirでWiFi経由で更新させたり、TCPに対応させたりできるはず。僻地に設置して使うなら、イリジウムのSBDでもTLEの更新には十分。そんなところに置いてどんなミッションができるかという問題はあるが。
 TLEは衛星打ち上げ情報部分を除いてアルファベットは不要だから、テンキーとスペース、ピリオドと正負記号だけで入力ができる。小さな液晶とキーパッドをつけておけば単体で打ち込みもできる。F/A-18のテンキー風インターフェースとかつけても面白いんじゃないかと。さすがにパンチカードは大変そう。

前回、衛星追尾をやったときにはPCのC#アプリで方位仰角を計算してシリアルポートで転送していたが、次回はスタンドアロンで動作できるようになる予定。

 衛星追尾そりゅーしょんをご用意しておりますので、キューブサットの追尾等のご入用の際はご連絡をお待ちしております。(嘘)

2017年12月4日月曜日

中間誘導とVLS

 VLSから発射するには中間誘導が必須である。
 (シリアス口調ここまで)

 中間誘導が使えるミサイル、例えばAIM-9Xは中間誘導が可能で、発射後ロックオン(LOAL:Lock-On After Launch)ができる。AIM-9M等は中間誘導ができず、発射前ロックオン(LOBL:Lock-On Before Launch)のみとなる。
 LOALをするためには「どの方向へ向え」という情報だけで発射する必要があり、その方向へ飛翔するにはなんらかの中間誘導が必要になる。中間誘導ができない場合は、発射前に確実に方向が決まっている必要があり、LOBLのみの運用となる。
 中間誘導の方式はたぶんなんでもいい。AIM-9XならJHMCSの正面方向へ飛翔するだけなので、角度の操作量だけを得ているはず。この場合は慣性誘導でいい。AIM-120は基本的にLOALの運用のはずだが、自分のシーカーでロックオンするのは目標に近づいてからのはずだから、「メインのシーカーがロックオンするのは発射した後」ということでLOBLの一種と考えられる。この際、目標が遠くにいた場合は、目標に接近する間に目標が移動してしまう可能性が高いから、慣性誘導だけでは足りず、途中で目標位置の情報をアップリンクする必要があるはず。だから中間誘導にデータリンクが必要になるはず。

 VLSから発射する場合、ミサイルのシーカーは真上しか見えない。また発射前はフタが閉まっているから、どっちにしろシーカーの目は塞がれていることになる。なので、発射してからシーカーがロックするまで、何らかの方法で中間誘導が必要になる。
 中間誘導を持たないスタンダード1は旋回式ランチャーからしか発射できず、VLSから発射するスタンダード2は中間誘導が追加されている。旋回式ランチャーは撃つ前に目標の方向へミサイルを指向できるから、発射前にロックオンが可能。
 SM-2はVLSから発射するという要求のために中間誘導を追加したが、このためにイルミネーターは終端誘導時のみで済むようになったため、同時に複数のミサイルを飛翔させることができるようになった。
 とはいえ、同時に週末誘導できるのはイルミネーターの数に制限されてしまう。例えば、遠くの航空機と近くの航空機がいて、遠距離目標のほうが優先度が高い、と判断した場合、遠くの目標へミサイルを撃ち、続いて近くの目標へミサイルを撃つことになる。この場合、イルミネーターが1個しか無いと仮定すると、イルミネーターはまず遠距離目標を照射する。最初に撃ったミサイルはこの目標へ誘導されるが、その間に近距離目標に撃ったミサイルも目標へ到達してしまうかもしれない。しかしその時点ではイルミネーターは高優先目標に対して使用中だから、近距離目標への誘導が行えない。イルミネーターが使えるようになったときには、近距離目標へ向かったミサイルは目標の向こう側へ飛んでいってしまった。というようなことが予想されるので、優先順位決定アルゴリズムは、単純に脅威度のみならず、将来的に使えるリソースも考えて撃つ必要がある。上記の場合、遠距離目標に撃ってから近距離目標を撃つと、同じタイミングで目標の終端誘導が必要になってしまうから、ワザと近距離目標に撃つタイミングを遅らせる、とか、そういうような処理が必要になるはず。

 なかなか大変そうだ。武器システムは一日にしてならず。

国際衛星識別符号(International Designator)

 どれくらいの範囲を表せるのか。総当りで吐いてみた(C#)。

StringBuilder sb = new StringBuilder();

for (int i = 1; i <= 26; i++)
{
    sb.AppendLine(
        (char)('A' + i - 1) + "" +
        "," + i);
}

for (int i = 1; i <= 26; i++)
{
    for (int j = 1; j <= 26; j++)
    {
        sb.AppendLine(
            (char)('A' + i - 1) + "" +
            (char)('A' + j - 1) + "" +
            "," + (i * 26 + j));
    }
}

for (int i = 1; i <= 26; i++)
{
    for (int j = 1; j <= 26; j++)
    {
        for (int k = 1; k <= 26; k++)
        {
            sb.AppendLine(
                (char)('A' + i - 1) + "" +
                (char)('A' + j - 1) + "" +
                (char)('A' + k - 1) + "" +
                "," + (i * 26 * 26 + j * 26 + k));
        }
    }
}

 A__が1で、B__が2、C__が3と続き、Z__が26で、AA_が27、AB_が28、BA_が53、ZZ_が702、AAAが703、ZZZが18278まで。
 約1万8千個を扱える。

 中国のASATの試験では、「観測可能なものだけで2,841個以上」(wikipedia)ということなので、かなり余裕ありそう。とはいえ、2桁だと700個ほどしか扱えないから、やはり3桁は必要なんだろうな。
 文字3桁分を整数で書こうとすると5桁必要だから、TLEに押し込むには文字を使うしかなかったんだろうなぁ。26進数恐るべし。
 1958年頃から使われ始めたらしいが、当時の人はどうして700個じゃ足りないと思ったんだろうか。IPv4しかり、大抵は後から桁数が足りなくなるもんだけど。米軍のASATが59年だそうだから、当時からデブリとかは色々考えられてたんだろうか。

 Cでコレを計算する場合、初期値をpiece = 0として、piece *= 26; piece += ch - 'A' + 1;を必要桁数分回せば文字列からintに戻せそう。

2017年12月1日金曜日

空港へ行きたい

 FS MSXでF/A-18を飛ばしながらVOR(コックピットパネルはTACAN)を操作しつつ、「VORってどういう仕組なのかな」と思ったのが運の尽き。調べても出てこない。

 いちおうwikipediaに簡単に書いてあるが、簡単に書きすぎてさっぱりわからない。

 ざっくり解読してみると、主搬送波に可聴信号(モールス符号orその他)がAM変調され、副搬送波がFM変調され、副搬送波に基準位相がFM変調され、副搬送波に可変位相がAM変調されているのかな、という気がする。どこまで合ってるかわからないけど。

 AM/FM変調だけなら、解析するのはそんなに難しくない気がする。ということで、VORを実際に受信してみればいいのだが、あいにくウチの周りで受信できるVORは無い。ということで、空港まで行かなきゃならない。かなり面倒。
 実際に取りにいくなら、SDRでIQを記録する、という感じになるんだろうな。となるとGPSで位置情報を取りつつ、VHF帯を記録することになるのであろう。なんとなく、ゼロ・ダーク・サーティーのCOMINTっぽい雰囲気。こっちはレーダーだから、ELINTになるのかな。


 VORを使うのは航空機だけじゃなく、流星観測にも使われるらしい。曰く、流星が通ったところは電離して電波を反射するので、VHFが上空から返ってくるんだとか(この理解で合ってる?)。VORが受信できるなら、VORのラジアルから、VOR局から流星までの方角がわかるんじゃないか、という気がするけど、35msecくらい持続しなきゃいけないし、AM変調だからかなり厳しそう。
 開口合成受信アンテナを上空に向けておけば、反射波の入射角がわかるから、送信局の位置と送信地点からの方位、受信地点の位置と受信地点からの方位で、流星の位置を特定したり、というのもできそうな気がするけど、流星の反射波ってどれくらいのモノなんだろうか。

***

 あんまり関係ないけど、気が向いたのでIQファイルを生成してみた。データとしては余弦波/正弦波をWAVEファイルに記録するだけなので、思ったより簡単につくれた。変調も、AM/FMでなんとなく出来てる気がする。CWは言わずもがな。
 でも変調できるのと復調できるのは別問題だからなぁ。FMってどうやって復調するんだろうか。

 IQファイルを作る際、最初に間違って256kSPSで作ってしまった。SDR#に食わせるとクラッシュしてしまった。250kSPじゃないとダメ。1.024MSPSとか2.048MSPSとかあるから、256kSPSだと信じて疑わなかったよ。。。

***

 いろいろやりたいことは溜まってるんだが、気力が出ない今日このごろ。

 そういえば、昨日でplalaのモバイル回線の提供が終了したね。同時にWiMAX2の制限が解除されたので、WiMAXに戻した。
 サービス終了ギリギリまで使い続けていたけど、異世界中世魔法ファンタジーに飛ばされるとかはなかったヨ。いや、ネトゲならともかく、回線使ってるだけで飛ばされても、あんまり強いチートもらえなさそうだし、どうでもいいんだけど。
 サービス終了間際の回線は予想以上に快適でした。他の人は早々に使い終わって帯域が空いたからかな?

2017年11月30日木曜日

MEDEVAC

 調べ物してたらた偶然見つけたので、ちょっと調べてみた。


 MEDEVACはMEDical EVAcuationの略で、負傷者を移動する手段、みたいなのを指すらしい。ヘリに限らず、車とかでもいい。

 基本的に9行(9種類)のパラメーターで交信するが、場合によっては最初の5行だけでもいい、という感じ?

 各パラメータはこのページに書いてある。
 9 Line MEDEVAC Request (ArmyStudyGuide.com)

Line 1:位置(MGRS:2桁のアルファベットと8桁の数字)
Line 2:周波数とコールサイン
Line 3:負傷者の状態と数
Line 4:必要な機材
Line 5:負傷者の状態
Line 6:周辺の安全状態
Line 7:マーキング方法
Line 8:負傷者の国籍
Line 9:汚染状況

 Line 1:位置
 位置は、そのままの意味。どこにヘリが来てほしいか、という位置。

 Line 2:周波数とコールサイン
 周波数とコールサインは、自分の物を伝える。
 要請に使っている周波数は戦闘地域全体からMEDEVACを要請するためのものだから、回収に来たヘリコプターと話す場合は別の周波数を使う必要がある。このため自分たちが使っている周波数とコールサインを伝える必要がある。
 動画では、相手・自分共にコールサインは3桁の英数を使っている。どちらもアルファベット・数字・アルファベットの並びだが、すべての組み合わせだと6760通りになるから、多分3文字で足りるんであろう。ただし、部隊内で一つの周波数を使うから、搬送用のために接尾辞を追加して、計5文字となる。サフィックスは数字2桁っぽい。

 Line 3:負傷者の状態と数
 負傷者の状態はAからEに分類され、Aは緊急、Bは外科治療が必要、Cは優先的、といった感じらしい。
 ナショジオのPJ番組で「n CAT Alpha」とか言ってるのは、この部分。「ワン キャット アルファ、ツー キャット ブラボー」ならカテゴリーA(緊急)が1人とカテゴリーB(手術が必要)が2人、といった感じの意味。

 Line 4必要な機材
 機材は、ホイストが必要か、とか、人工呼吸器が必要か、とか、そういう情報。今だと人工呼吸器くらいは初期装備な気もするけど、60年代前後とかならこういう機材を備えていたヘリも少なかったんだろう。

 Line 5:負傷者の状態
 自力で歩けるか否か。Aなら担架が必要、Bなら不要。

 Line 6:周辺の安全状態
  N:エリア内に敵兵はいない
  P:エリア内に敵がいる可能性がある(慎重に接近せよ)
  E:エリア内に敵がいる(慎重に接近せよ)
  X:エリア内に敵がいる(武装が必要)
 他に症状を伝えたりするらしい?

 Line 7:マーキング方法
 自分の居場所を知らせる手段。Aなら蛍光色の布を広げる。Bならフレア(信号弾)を使う。Cならスモークを炊く。Dはマーキングなし。Eはその他の手段。

 Line 8:負傷者の国籍
 Aなら米国籍の軍人。Bなら米国籍の民間人。Cは米国籍以外の軍人。Dは米国籍以外の民間人。Eなら敵の捕虜。

 Line 9:汚染状況
 特別な防護が必要かどうか。Nなら放射能で汚染されている。Bなら生物兵器で汚染されている。Cなら化学兵器で汚染されている。
 他に着陸地点の地形等の情報も伝える。そこが湖なのか、山なのか、市街地なのか、みたいな。


 予めホワイトボードみたいなチェックリストがあって、交信を始める前にこれらの情報を書き込んでおく。
 交信する際はまず相手のコールサインを呼び、その後自分のコールサインを言う。そしてMEDEVACを要請することを伝える。
 相手はこちらのコールサインを復唱し、自分のコールサインも言う。これが正しければ、自分と相手で意思疎通ができていることがわかる。
 通信が確立できれば、Line1からLine9までを、何行目かも含めて順に伝えていく。

 動画では、9Lineを伝えた後に、相手は復唱していない。通信状態が明瞭でノイズが少なく、また聞き間違えた可能性もない場合は、そのまま交信を終了する。


 あとはヘリが近くまでくれば、Line2で伝えた周波数とコールサインで通信が来るので、Line7で伝えた方法で自分の場所を示す。
 順調に行けば、負傷者は治療施設まで運んでもらうことができる。

***

 米軍はいろいろな部分で交信内容のフォーマットが決まってるっぽい。言い間違え、聞き間違え等を防ぐこともできるが、文章フォーマットが決まってるなら文字列で送ることもできる。最近の米軍は様々な交信を文字列で行うらしい。文字列ならデータとして残しやすいし、検索もできるし、特定のキーワードに反応してアラームを鳴らしたりもできるし、ということで、音声より扱いやすいんだろう。でも場合によっては銃弾が飛び交う中でチャットをやらなきゃいけないから、なかなか大変そう。
 レッドプラトーンでもチャットを使うシーンが出てくる。ローンサバイバーでもチャットで情報を送ってた気がする(途中でノートPCをぶち壊して、その後はイリジウムを使ってたが)。


 軍の救難ヘリを要請する交信の方法を知ってても一般生活では何の役にも立たないが、サバゲのルールに組み込んでみたりとかするとどうだろうか。
 例えば運営に対して9Lineを送信すればスタッフがやってきて、セーフティーまで連れて帰り、9Lineの内容が正しければ復活できる、とか。すっげー面倒くさいことになりそうだけど。

CASごっこ

 制服の上にリブリーザーを着用して、H&Kが製造したHK417(水鉄砲)とM320(水風船弾)、HK USP(水鉄砲)で武装し、LUCIE初め様々なガチ装備をしたミーちゃんが水路から潜入してくる、という電波を受信。
 水路潜入ならRATt感染の心配が少ない。はず。


 ミーちゃんが拳銃構えてる銃だけで買った価値が…うーん、もうひと押し…。
 キャラ絵オンリーな感じで、メカ類のレンダリングは無し。ファンブックと違い、テキストもほぼ無し。
 リング綴じは手で持って読むのは大変だけど、机において読むとかなら読みやすい。付属カバーもあって、好きなページを開いて置いておけるので、イラスト集とかにはいいと思う。


2017年11月29日水曜日

MS FSXのF/A-18のオートパイロット


 F/A-18のオートパイロットの使い方。

 戦闘機のAPなので、旅客機のそれとは全く別物。あくまで「人間の操縦がメインで、他の作業(交信とか)の合間だけ操縦する手段」というシロモノ。

 基本的にHUD直下のパネルだけで操作できるが、ヘディングを設定するノブだけ、左ラダーペダルのところにある。

 パネル下段には、A/PやILS、ON/OFFというボタンが有る。
 左端のA/Pを押せばオートパイロット設定に入ることができる。右端のON OFFボタンを押せばAPをON/OFFできるが、個人的には使い勝手が悪いと思った(使わなくてもON/OFFできる)。

 AP設定では、パネル右側の5段のディスプレイに、上からATTH, HSEL, BALT, RALT, CPLが表示される。
 ATTHは姿勢保持(Attitude Hold)、HSELは進路保持(Heading Select)、BALTは気圧高度維持(Barometer Altitude hold)、RALTは電波高度維持(Radar Altitude hold)の略だと思う。CPLは不明。
 この内、CPLの使い方は把握できていない。RALTは未実装らしい。

***

 簡単に使えるのは、ATTHモードで、「現在の姿勢を維持する」というモード。アフターバーナを燃やして急上昇しながらATTHをONにしてエンジンを絞れば、失速するまで姿勢を維持する。姿勢を維持するだけなので、例えば200ktでATTHをONにすれば、速度を下げれば降下率が増えるし、速度を上げれば上昇率が増える。
 姿勢維持ではあるが、バンクについてはゆっくりと水平に戻してくれるので、数十秒くらいの期間で見れば上昇率/進路保持となる。

 BALTモードは気圧高度を維持するだけで、進路は維持されない。ある程度の高度を保ちつつ、進路は自分で調整するといった用途。

 HSELは進路保持セレクタで指定した進路を維持する。高度は維持されないので、自分で調整する必要がある。

 使う際は、使用したいモードの左にあるボタンを押せば文字の左側に点々が表示されて、そのモードが動いていることを示す。もう一度ボタンを押せばOFFにできる。
 排他動作の場合は、他のモードがOFFになる。例えばATTHモードが有効なときにBALTを有効にすると、ATTHは無効になる。
 BALTとHSELは同時に使用可能で、両方共ONにすれば高度と進路を維持してくれる。


 使い分けとしては、一時的(無線交信や地図の確認等の合間)な場合はATTHを使い、ある程度の長距離を移動するならBALT/HSELを使う、という感じだと思う。
 BALT/HSELでは進路セレクタを設定する必要があるので、気軽に、という訳にはいかない。レーダーの設定だとか、地図の確認といった、短時間で済む程度の自動操縦ならATTHのほうが便利。

 すべてのモードで、速度は調整されないので、スロットルについてはすべて人間が責任を持つ必要がある。

***

 ILSの使い方。
 ILSボタンを押すと周波数入力モードになるので、テンキーで5桁の周波数を打ち込む(0.01MHzの単位まで)。受信できれば数字ディスプレイにONと表示される。
 ILSをHUDに表示するには、右側のディスプレイの右上にあるILSボタンを押してILSモードを選択する必要がある。
 
***

 せっかくなので、ついでにレーダーの説明も。

 起動時には右の画面に進路等の情報が表示され、左にエンジンの情報が表示されている。基本的に左右どちらも同じ用途で使うことができる。下段中央のMENUボタンを押せばモードを切り替えることができ、HSIなら進路、ENGならエンジンの情報、HUDなら姿勢、RDRならレーダーを表示できる。

 レーダーを使う場合、どちらかの画面でレーダーモードを呼び出す。本物の戦闘機パイロットだと、空対空戦闘と空対地戦闘で表示する場所を変える、といったことをするらしい。ただFSXではせいぜいレーダーを表示するくらいしか戦闘機らしいことが無いので、今回はレーダーを左側に表示する。


 レーダーにはいくつかの設定があるが、上の画像では左上から時計回りに6B、80、IUP、TDN、4833、140、M 0.8、544、といった表示がある。

 順に説明していくと、6Bはレーダーの「6Bar」という動作モードで、80は表示距離が80海里(約150km)、4833は自機の気圧高度(ft)、80はスキャン幅が80度、M 0.8は自機のマッハ数が0.8、544は自機のノット数、という意味。

 また画面の中央あたりに0.3と17、それと四角と直線などの明るいシンボルがあるが、これはレーダーで捕捉した目標を示し、0.3は目標がM0.3で飛んでいて、高度は17000ftということを意味している。
 直線は飛行方向を示していて、この場合は奥から手前に向けて、若干自機の左側に向かって飛んでいる、という状態。
 他に薄い3本の横線がいくつかあるが、これが他の目標の位置を示していて、TUP, TDNで切り替えることができる。


 レーダーを起動すると2バー、40海里、40度のモードになっていると思う。
 とりあえず空域を自機だけでスキャンするなら、6バー、80海里、80度くらいがいいと思う。これは上下方向で20度、横方向で80度の三角錐をスキャンするモード。
 バーは1,2,4,6を切り替えることができ、バーが多いほうが上下方向のスキャンが広い。代わりに、1回あたりのスキャンに余計時間がかかる。
 横方向は20,40,60,80,140から選ぶことができ、数字が大きいほど広い範囲をスキャンできるが、時間が長くかかる。
 距離は5,10,20,40,80から選ぶことができる。

 正直、FSXではバーのシミュレーションはやってないんじゃないかな、という気がする。なので、設定としてはスキャン幅と距離だけで十分。


 面白そうなレーダーシグネチャがあれば接近してみよう。レーダーに表示された目標の高度と速度、進路で会敵位置を予測してそこに接近していく。基本的に、相手の後方下側から接近する。後方から接近する場合は自機のほうが早いので、うまく速度を落とさないと相手の前に出てしまう。下から接近すると、ある程度近づいたところで上昇すれば、速度エネルギーを位置エネルギーに変換して減速することができる。どれくらいの差で近づいて、どのあたりで引き起こすか、というのはかなり難しい。
 退官した空自パイロットがフライトシミュを飛ばす動画がyoutubeにあるけど、感動的なまでにピタッと吸い付いて接近する。プロってすごい。


 うまくすれば、数百mくらいまでは接近できる。目視距離になるとレーダーは使わない(or使えない)ので、レーダーの代わりにHUDを表示するのがおすすめ。
 TrackIRとかを使うなら別だが、PoVスイッチで視点を動かす場合、あっという間に空間失調に陥ってしまう。それを防ぐために、HUDで自分の姿勢を確認しながら操縦する。
 また、引き起こしを掛ける前に目標の速度を確認しておけば、モニタに表示された速度を確認しながら、スロットルを調整できる、という利点もある。

***

 F/A-18には他にもキャノピーハンドルや主翼の格納を始めとした、様々な機能がある。とはいえ、それらを説明すると長くなりすぎるだろうし、僕自身もよくわかっていない部分があるので、とりあえず今回はここまで。

Visual Studio 2015 forWDでSimConnect

 SimConnectはウィンドウハンドルが必要なので、コンソールアプリは作れない、orかなり面倒。Formで作るべし。

 フォームのプロジェクトを作ったら、ソリューションエクスプローラーからプロジェクトのプロパティを開いて、"アプリケーション"タブにある、対象のフレームワークを.Net Framework 2.0にする。"ビルド"タブにある、プラットフォームターゲットをAny CPUからx86に変更する。
 いくつかの参照はリンクが切れているので、警告マークが出た参照は削除しておく。
 Form1.csとProgram.csのusingも、リンク切れを削除しておく。

 C:\Program Files (x86)\Microsoft Games\Microsoft Flight Simulator X SDK\SDK\Core Utilities Kit\SimConnect SDK\lib\managed\Microsoft.FlightSimulator.SimConnect.dllを参照に追加する。

 Microsoft.FlightSimulator.SimConnectとSystem.Runtime.InteropServicesのusingを追加する。


 ソースコードは長い(400行以上ある)ので、続きでどうぞ。

 とりあえず、FSXの情報を取り出すサンプルが2種類と、FSXにコマンドを送るサンプルが1個と、オマケにもう1種類。

 情報を取り出すのは、ギアハンドルが操作されたらFormに表示する、というサンプルと、常に位置情報を取り出して表示する、というサンプルの2種類。
 コマンドを送るのは、フォームからの操作でギアハンドルの位置を変える操作を行う。
 オマケは、SendInputでWin Alt PrintScreenを押す、という動作。

 ちなみにプリントスクリーンだけで120行くらいあるので、SimConnectだけでは300行くらい。
 キャプチャはGeForce ExperienceのAlt F1だと楽なんだけど、WinゲームバーだとWinキーが必要で、これはSendKeys.Sendでうまく送れないので、Win32APIを叩く必要がある。


 SimConnectでできることを網羅した、というには程遠いが、ある程度のことはこのサンプルを改造するだけでできるはず。

 値の名前とか単位とかはLockheed MartinのWebページが詳しいのでそちらを参照のこと。ただしFSXとP3Dでは使える要素に違いがあると思うので、そのあたりはMicrosoftのドキュメントも参照。

電磁石がほしい

 久しぶりにFSXで遊んだ(って、定期的にどっかに書いてるな。長続きしない)。

 やはり視点操作が結構面倒。気軽にやろうとするとFreeTrackだけど、FreeTrackが入ってるとArma 3を起動できない。三日坊主の自分には、TrackIRはコスパが悪い。
 SDKを使えば、FSXの視点を変更することができるが、そのためのソースをどうするか。
 前々から気になってた、OpenPoseを試してみようと思ったが、かなり要求リソースが高い。調べてみると、どうやら機械学習を使っているらしい。さもありなん。4kでフライトシミュをやりながら、その裏で機械学習の処理も行う。無理ゲーっぽい。

 自分で画像処理を作るのは、マーカーを使ったとしても、結構面倒な気がする。あと、画像処理はCPUリソースが大量に必要になる。
 ってことで、CPUリソースをあまり使わない方法が必要になる。
 一番手っ取り早いのは、加速度・角速度センサを使って頭の位置を計算すること。ただし、これだと積分する際に誤差も積み重なる。

 本物ではどうやっているのか。
 例えばJHMCSでは交流磁界を使った位置・角度の検出を行っている。ただし、この方式では磁界を邪魔する物が無い環境でしか使用することができない。F-22では、磁界を邪魔する物があるためにJHMCSが使用できないらしい。
 JHMCS IIでは別の方式となり、ジャイロやら光学系やらを使うらしい。
 ユーロファイター・タイフーンの場合は、ヘルメットに大量の赤外線LEDが埋め込まれて、これを画像解析するらしい。

 JHMCSでは、環境が良ければ交流磁界の周波数でリフレッシュレートが制限されると思われる。
 JHMCS IIでは慣性を使ってるので、慣性センサのサンプリングレートに制限される。ただし、戦闘機では最大10G程度の重力加速度があるから、高G環境でも正確にサンプリングできる慣性センサが必要になる(MEMSジャイロは高Gに弱い)。また機体自体の運動と、頭の運動を切り分ける必要もある(結局角度は機体の外に対してだから、切り分けは不要?)。
 タイフーンの場合はカメラのフレームレートと、画像処理の速度に制限される。

 タイフーンはかなりゴリ押し感がある。
 JHMCS II方式は、固定された椅子に座って使う分には、電子工作的に作りやすそう(ドリフトを考えなければ)。
 JHMCS方式の場合は、積分が無いので、誤差が少ない。ただし磁力を扱ったりとか、いろいろ面倒な気がする。


 気軽に作れるとなると、JHMCS II方式かなぁ。ドリフト対策をどうするか。角度の誤差は地磁気で補正できるかもしれないけど、位置の補正は9DoFでは不可能。数-数十Hzの交流磁界を外部で作って、加速度角速度で位置を計算し、地磁気センサで誤差を補正する、みたいな折衝案はできるかも。

 拾い物のPDFによると、送信コイルが直径5cm、受信コイルが2cmで、距離80cmにおいて位置誤差2cm、角度誤差2.5度くらいらしい。10年以上前のPDFなので、信号処理部が結構でかい。今だと手のひらサイズだろうなぁ。

 固定側で送信、ヘッドセットに受信コイルをつければいいかな、という気がするけど、すぐ横でヘッドセットのスピーカーが動くから、磁気式は厳しいかもしれない。ヘッドセットを送信にすれば、スピーカーからの磁気の影響は防げるかもしれないけど、逆に異音が聞こえてくる可能性もある。
 件のトラッカは100Hzで出るそうで、9軸(3x3軸)の計測を時分割で行うらしい。1msec以内に検出しなきゃいけないから、周波数は少なくとも50kHzから200kHzくらいだろうか。となると超音波の領域だから、スピーカーへの干渉は問題にならないかな?

 もしかしたら、ヘッドセットの入力から外部においた受信コイルの波形と相関を取って、送信コイルレスで6軸検出ができるようなソリューションがあるのかもしれない。このあたりはVRのトラッキングで使われそうな技術だから、調べれば出てきそう。


 で、結局どの方式を使うか。いまいち決めきれない。
 まぁ今回もFSXはすぐ飽きるだろうから、頭の体操程度にもうちょっと考えてみる。

2017年11月28日火曜日

C#でフルスクリーン

 C#のFormをフルスクリーンにするクラス。

 .NET TIPS:Windowsアプリケーションをフルスクリーンで表示するには? - @IT

 基本的にこのページのコピペだが、フルスクリーン/ウィンドウを切り替えるとFormサイズが変化してしまう不具合の部分だけ、修正してある。

 コンストラクタとメソッド3個しかないので、説明しなくても使えるはず。内容もそんなに大変じゃないはず。動作が知りたいなら上記リンクを参照。

public partial class Form1 : Form
{
    readonly Full_screen_controller full_screen;

    public Form1()
    {
        InitializeComponent();

        full_screen = new Full_screen_controller(this);
    }

    private void button1_Click(Object sender, EventArgs e)
    {
        full_screen.toggle_screen_mode();
    }

    private void button2_Click(Object sender, EventArgs e)
    {
        full_screen.to_full_screen();
    }

    private void button3_Click(Object sender, EventArgs e)
    {
        full_screen.to_window();
    }
}

class Full_screen_controller
{
    private readonly Form form = null;
    public bool is_full_screen_mode { get; private set; } = false;
    private FormWindowState previous_form_state;
    private FormBorderStyle previous_form_style;
    private Size previous_form_size;

    public Full_screen_controller(Form form)
    {
        this.form = form;
    }

    public void to_full_screen()
    {
        if (!is_full_screen_mode)
        {
            is_full_screen_mode = true;
            previous_form_state = form.WindowState;
            previous_form_style = form.FormBorderStyle;

            if (form.WindowState == FormWindowState.Maximized)
            {
                form.WindowState = FormWindowState.Normal;
            }

            previous_form_size = form.Size;

            form.FormBorderStyle = FormBorderStyle.None;
            form.WindowState = FormWindowState.Maximized;
        }
    }

    public void to_window()
    {
        if (is_full_screen_mode)
        {
            is_full_screen_mode = false;

            if (previous_form_state == FormWindowState.Maximized)
            {
                form.WindowState = FormWindowState.Normal;
            }
            else
            {
                form.Size = previous_form_size;
            }

            form.FormBorderStyle = previous_form_style;
            form.WindowState = previous_form_state;
        }
    }

    public void toggle_screen_mode()
    {
        if (!is_full_screen_mode)
        {
            to_full_screen();
        }
        else
        {
            to_window();
        }
    }
}


 そういえば、いちおうJSF++に則った雰囲気の書き方?だけど、JSF++だと大文字と小文字で区別しちゃいけないんだよな。ということで、「型名の最初の1文字は常に大文字」+「インスタンスは常に小文字」で区別するのはルール違反のはず。もっとも、基本的にクラス名とインスタンス名を間違えても、大抵はコンパイラでエラーになるので、バグにつながる危険性は少なそう。
 このあたりは実際の使用例を見てみないとなんとも。とはいえF-35のソースコードってオープンソースになってる部分とかあるんだろうか?機密的に言えば、単なる算術ライブラリとかは全く機密には当たらないけど、各国の税金で作ったものを(仮想敵国も含めた)全世界で共有する、というのは無いだろうなぁ。

2017年11月27日月曜日

むしゃくしゃしてやった。後悔はしていない。


 OSを入れ直して、地味に困ったのが、Picasaが終了してしまったことです。
 画像ビューアとしてはとても優秀だったのに。。。

 Windows 10のフォトを始め、様々な画像ビューアがありますが、Picasaほど使いやすいビューアには出会ったことがありません。
 ということで、簡易的なモノを作ってみました。

 最低限欲しい機能は、キー入力で同じフォルダの画像を表示することです。
 Picasaでは矢印キーで隣の画像を表示できますが、フォトではこれができません。Webブラウザも画像ビューアとしては使用できますが、同様に他の画像を見るには、いちいちウインドウを閉じてファイルをダブルクリックしたりする必要がありました。

 ということで、横の画像への移動は実装してあります。
 とはいえ、Picasaのような、エクスプローラーに表示された順番を得るのは、かなり大変な雰囲気です。なので、今回は自然数ソートのコードをもらってきました。
 C# 自然順で文字列をソートする - Qiita

 Picasaは、背景がすりガラス風だった気がしますが、これをC#で実装しようとするとかなり大変です。そもそもGraphics系ではフィルタリングができないので、自分でガウシアンフィルタなりを実装する必要がありますが、解像度が増えれば実用に耐えないほど遅くなってしまいます。特に僕は4k液晶を使っているので、かなり厳しいです。
 という理由と、すりガラス風にする利点がほとんど思い浮かばないので、今回は単色の背景にしました。

 そういえば昔、Win7のスクリーンセーバーのバブルが、ウインドウそのままでセキュリティ的に良くない、ってことでフィルタを実装した記憶がありますが、起動するのに数秒かかった気がする(しかもマルチスレッドで処理してるので、スクリーンセーバー起動時にCPUファンが唸りを上げる)。

 写真の加工はもっぱらLightroomを使っているので、ビューアとしては、本当に画像表示の機能しか必要ありません。印刷や、ましてやシェアなんて全く不要な機能です。ということで、僕の要求を満足するビューアは、かなり簡単につくれました。
 あとは暫定のプログラムに設定すれば完了だねっ!


 もうちょっと最適化は必要そうですが、気長にやっていこうと思います。