2017年4月24日月曜日

JS Orbitで日照を表示


 日照といっても、地上の話ではなく。衛星が太陽に照らされているはずの部分はオレンジで、地球の影に入っているはずの時は茶色で表示するようになっています。configのorbit lineからSunLightを設定すれば表示できます。

 この表示はかなり端折った計算です。
 まず太陽は無限遠にある無限小とし、地球は完全な球体と想定、衛星は無限小です。また、計算間隔は1分毎で、移動速度に対してかなり離散的です。
 おそらく大きく外しているわけではないと思いますが、ほんとに正しいかはわかりません。あくまで、目安程度にお願いします。

2017年4月23日日曜日

SAO星カタログ


なんとなく星を扱いたい気分だったので、SAOカタログを読み込んで表示するやつをC#で作ってみた。
 画面上が北、下が南、右が西、という星座盤みたいな感じで、中央下半分あたり、真南仰角45度くらいのところにオリオン座が有る。僕は全く星を見ない人間なので、オリオン座しか見つけられなかった。肉眼ならもっと見えるのに。

 さすがに生のSAOカタログはデカくて、ロードに2.4秒くらいかかる。不要なデータは解析しなければ良いのだろうけど、それもなんだか。
 今回は単純に赤緯赤経から計算しているだけなので、固有運動とかは計算していない。

 SAOカタログは正式にはスミソニアン天文台星表と言うらしいのだが、「ネット上で入手できる」とアチコチに書いてある割に、どこから入手できるかはどこにも書いてない。結局、SAOカタログのwikipediaの英語ページから外部リンクに有るNASAの圧縮データを引っ張ってきた。

 星の位置を計算したりするならSAOカタログで充分なのだけど、星座盤みたいなのを作ろうとすると星と星をつなぐリストが必要になる。そういうのってどこに有るんだろうか。あと天球を分割する継ぎ目とか。 

 スタートラッカーとか作ってみたいけど、あれってどういう計算をやってるんだろう。

2017年4月20日木曜日

C#: 文字列を数字とそれ以外で区切る


 ということをやりたかったので、つくってみた。
 こういうのは正規表現とかで使うと柔軟にできるんだろうけど、面倒くさいそこまで高機能なの必用じゃなかったので。
 数字(0-9)の連続を1グループとして、それ以外の部分も1グループとして、分割して返してくれる。数字しか識別しないので、空白で区切りとかはされない。もちろん数字と数字の間に空白があれば区切られるけど。

 いつもの通り、使うときは自己責任で。

2017年4月19日水曜日

レーザープロジェクター(みたいな名状しがたいナニカ)


 最近、こういうモノを作っています↑

 見ての通り、ステッピングモータでジンバル作ってWebカメラを乗っけてるだけですが。

 で、せっかく方位仰角を制御できるので、撮影だけじゃなくてもっと遊びたいということで、レーザーポインターを載せてみました。


 上は8秒で1周、下は2秒で1周です。
 レーザープロジェクターとして使うには致命的に遅いですが、カメラとかいろいろ重量物が乗っててモーメントが大きいのであんまり早くできません。
 ステッピングモータの軸に鏡を付けてガルバノミラーみたいなふうにすればかなり高速化できるんでしょうが。

 モーターの制御はPIDで行っています。現在でもかなりPを大きくしてIは小さいはずなんですが、それでもそれなりにオーバーシュートしてしまいます。と思っていたんですが、この写真を見る感じ、もうちょっと素早く立ち上げても良いかもしれませんね。

 レーザーポインターを載せたのはただ面白そうだというだけではなく、オーバーシュートとかアンダーシュートを見れるように、という狙いがあります。

 ということで、ブログに書くほどでもない細々した作業ばっかりの今日このごろでしたが、とりあえずネタになりそうな気がしたので久しぶりにブログを書いた次第。
 カメラジンバルを作っていろいろ制御するネタをブログに書いておけば、あと数年くらいしてキリト君がこのブログを見つけて明日奈の肩に乗れると思うと、俄然やる気が出ますね(って思っておかないと続かないくらいにはモチベーションが低いです)。


 追記
 ちょっとパラメータをいじってみました。
1周2秒です。若干発振していますが、上の画像と比べて四角形に近づいています。



 矩形を表示した時の様子です。1枚目は下から立ち上げて左右のパルス、2枚目は左から動いて上下のパルスです。
 上下方向はほとんど発振も見られず、かなり綺麗です。対して、左右方向はかなり発振しており、汚い線になっています。
 これは、上下方向はカメラ(+レーザーポインタ)の重さしか無く、回転軸と重心がかなり近いところにあるのと、左右方向はさらにステッピングモータの重さが加わり、さらに重心と回転軸が離れているために慣性モーメントが大きくなっているためだと思われます。
 PIDパラメータやモーターの加速度を最適化すればもっと良くなるのかもしれませんが、そもそもここまでの高速域で使う予定はないので、とりあえず今回はこの程度で許してやります。//次は覚えてろよッ!

 おそらく、肩の上に載せて使うような状況では、シェイクリダクションはモーターで全体を振っては間に合わないはずで、必要に応じて画素自体を動かしたり、少し広角気味に撮影してトリミングでSRを行ったり、といった感じになるんだと思います。これからますます高解像度機材が充実していくでしょうから、広角で撮影しておいてトリミングでSRというのはアリだと思います。それにVRの追従性はハードウェア(モーターの強化)ではなく、ソフトウェア(広めで撮ってトリミング)で対応するのが楽なはずです。
 でも実際に肩に載せるならRICOH Thetaあたりになるんだろうなぁ。

 あと何週間かすれば暖かくなってくるでしょうから、そうなれば屋外で色々撮影できます。ADS-Bから飛行機をトラッキングしたり、TLEから人工衛星をトラッキングしたり。ISSならWebカメラでも充分に撮影できるはずですし、イリジウムフレアとかも面白いかもしれません。

2017年4月7日金曜日

Webカメラ的なモノを買ってみた


 ガワの無い、その割に普通のWebカメラと比べても特別安いわけでもない、どっかの横流しみたいなWebカメラを買ってみました。それと、焦点距離35mmのCマウントレンズと、Cマウント-12mm変換アダプタも買いました。
 ちゃんと計算したわけじゃないですが、およそ35mm換算で250mmとかそれくらいじゃないかなーという気がします。かなり狭角ですね。


 画面から90cmほどのところからキャプチャした画像です。90cmでこの範囲しか撮れないんですから、相当に狭角です。3mほど離れた壁を撮っても、数センチ角程度しか撮影できません。

 フレームレートはQQVGAで33fpsくらい、VGAで33fpsくらい、SVGAで18fpsくらい、FHDで22fpsくらいでした。本来はフレームサイズに反比例してフレームレートが変わるはずですが、SVGAはFHDよりもフレームレートが低いという結果でした。何か重い変換処理が行われているのかもしれません。およそVGAが最高fpsで、QVGAやQQVGAにするメリットはありません。もっとも、PCに入ってからの処理はデータ量が少ないに越したことはないので、QQVGAで足りるならQQVGAに設定するべきですが。
 一般的なWebカメラと違い、低照度でもフレームレートが低下しないのが便利かもしれません。とはいえ、もちろん照度を上げればシャッタースピードが遅くなり、照度を最大にすればフレームレートも5fps程度まで低下します。とはいえ明るい環境なら20fps程度は出ますし、解像度によってはさらに高FPSも得られるので、遊びで画像解析程度なら使えると思います。


 UVCでOpenCVから叩けるカメラって、かなり少なくて、実質的にはWebカメラ程度しかありません。他にはファクトリーオートメーション向けのカメラがありますが、Webカメラより1-2桁高価です。
 今回買ったメーカーでは同じように基板剥き出しのWebカメラを、画素やレンズの組み合わせで色々な種類で売っていますが、自前で光学系を用意するなら、分解する手間もかからず、ネジ穴等もちゃんとついてるので、画像認識とかに向いている気がします。意外と基板も綺麗なので、基板剥き出しから感じる粗悪な感じはありません。本当に良いものかはわかりませんが。
 むしろ、一緒に買ったレンズの方がパッケージが汚れていたりして、あぁ、安物ってこういうのだよなぁ、という感じです。


2017年4月3日月曜日

軌道のグラフ化

 このネタも久しぶりですね。ISS放出物体のグラフ化を行いました。


 およそ2016年10月頃から2017年3月末頃までの、軌道長半径のプロットです。
 個人的にアーカイブしているデータは、17年1月中頃までは1日に1回、それ以降は1日に2回のデータを保存していますが、実際にはTLEの更新は数日置きに行われたりするので、そんなにデータ量は多くはありません。
 とはいえ、6ヶ月間でおよそ70物体、データ数にして1万以上のTLEデータがあります。
 さすがにこの量になると、TLEの解析からグラフ化までをExcelで自動的に行うのは無理があるようです。解析等はそんなに大変ではなく、待ち時間さえ許容すれば今の数倍程度までは問題ないはずです。しかし、データの出力方法が悪いので、グラフ化の処理に失敗しています。折れ線グラフにするにあたり、衛星数xデータ数のマトリクスを生成し、そこからグラフ化しているのですが、現状で70万くらいのマトリクスになっています。もうちょっとスマートな方法があると楽なんですが、別アプリでグラフ化する必要があるのかなぁ。


 さて、愚痴っててもしょうがないので、ちょっとだけデータのおさらいをしましょう。縦軸は地心からの距離、横軸は時間で、それぞれ単位はkmと日です。縦軸の下端はおおよそ地表の位置、上端は上空500kmあたりです。横軸は20日/div 4日/divの目盛りになっています。日数は固定ですが、カレンダーの仕様上わかりずらいですね。このあたりの文句は歴代権力者に言ってもらうとして。

 グラフの一番上に常にいる濃い青の線はISS本体です。たまにリブーストしたりして高度を維持しています。
 その他の物体はすべてキューブサットなどです。
 濃い赤の、比較的なだらかな線を描き、17年3月上旬に再突入したのは、SPINSATという、かなり重くて球体な衛星です。重量がある、プラス、球体で空気抵抗が少ない、という物体のため、ISS放出衛星のなかではかなり長生きしていました。
 その他の衛星でも、キューブサットの大きさによって落下速度は変わりますが、1月末あたりにものすごい速度で落下している物体があります。これがFREEDOMで、膜展開により素早くDeOrbit(軌道離脱)しているのがよくわかります。

 おおよそ、300kmを下回ると加速度的に落下しているのがわかります。飛行機が飛べるのはおおよそ10kmまでで、それ以上は空気が薄くて大変ですが、小型衛星から見ると300km未満は空気が濃すぎて長生きできません。
 また、傾向として200kmを下回ると軌道追尾が終了しているようですね。


 こう言っては何ですが、キューブサットは結構あっさりと落ちてくるので、高度のプロットを見るのは面白いと思います。軌道を維持できる衛星はずーっと直線ですからね。

2017年3月28日火曜日

2015年7月に発生したSM-2爆発のはなし

 画像:CNNの記事より

 すこし前の話ですが、2015年7月18日に行われたスタンダードミサイル2発射試験にて、発射直後に爆発するという事故がありました。前々から気になっていたのですが、ちょっと調べてみたのでまとめです。
 僕は壊滅的に英語ができないので、変な理解で書いてたらごめんなさい。艦や兵装等についても素人なので、そのあたりも間違ってたらごめんね。



 2015年7月18日に米国大西洋岸で行われたスタンダードミサイル2 Block3A(Standard Missile-2、以下SM-2)ミサイルの発射試験において、発射直後にSM-2が爆発するという事故がありました。発射を行った艦はアーレイ・バーク級ミサイル駆逐艦のDDG-68 ザ・サリヴァンズ(USS The Sullivans)です。
 爆発による負傷者は報告されていませんが、小規模な火災が発生したとのことです。
 数週間後に掲載されたニュース記事では、ザ・サリヴァンズの修理におよそ$100k(当時のレートで約1250万円)を要するとのことです。爆発によるダメージは上部に集中しており、艦の構造に及ぶ影響は無かったとのことです。
 事故後、ザ・サリヴァンズは大西洋側の海軍基地で修理を受けており、事故後1ヶ月程度で修理は終わるようです。


 ザ・サリヴァンズはフライト1という、アーレイ・バーク級の初期に建造されたグループです(現在まで、フライト1, 2, 2Aの3種類が就役しており、現在フライト3が計画中です)。フライト1では前部甲板にミサイル発射機が29セル、後部甲板に61セルあり、このSM-2は前部左側の発射機から発射されたようです。
 アーレイ・バーク級のSM-2は垂直に発射されるため、この高さであれば、前部甲板の直上で爆発したということになるはずです。距離的には艦橋部分の直近ですが、おそらく大半の艦橋要員は直接爆発を見ることはなかったはずです(もちろん爆音には晒されたでしょうし、閃光も見えたはずですが)。
 手元にある資料によれば、アーレイ・バーク級のマストにはHF, VHF, UHFの各種アンテナと、赤外線光学系が搭載されているようです。
 アーレイ・バーク級は艦橋構造物が鋼製のため、多少の熱には耐えられるようになっています(過去の火災事故の教訓で、耐熱性が強化されています)。一方、マスト部分はアルミで作られているので、「ダメージは上部に集中している」というのは、熱や衝撃に弱いアルミには影響し、鋼で作られた船体には影響が少なかった、ということかもしれません。

 スタンダードミサイルを始めとして、現在多用されているミサイルは基本的に固体燃料ロケットを使っています。上画像でも爆散した破片が白く発光していますが、これは燃料が燃えているためです。
 固体燃料は酸素を自分で持っていることから、液状・泡状などの消火剤によって酸素の供給を停止しても、燃焼を止めることができません。燃焼にも高発熱を伴うため、冷却しての消火も困難でしょう。おそらく小規模な火災というのは、燃え残った燃料が甲板上に落下したことによるものだと思いますが、これを消化するのは非常に大変だと思います。ただし、量はそれほどでもないと思うので、燃え尽きるまでにそれほど時間は必用としなかったはずです。

 蛇足ですが、固体燃料の内、白煙を引くタイプは、燃料にアルミニウムが含まれ、高温で燃焼するタイプの燃料です。高性能な固体燃料を作るには高精度でアルミニウム粉末を作る技術が必要となります。逆に、最近は赤外線センサに悪影響を与えないために、あるいは敵から発見されづらいように、低排煙な固体燃料も使われてはいます。ただ上画像では白煙が見えており、また高温で燃焼しているので、破片が真っ白に発光しています。


 事故の原因は、SM-2に使用されているMk 104 Mod 2 デュアルスラストロケットモーター(Dual Thrust Rocket Motor)に欠陥があったとのことです。このモーターはThiokol(サイオコール、あるいはチオコール)社、現在のATKランチ・システムズ・グループで25年ほど前に製造されたものだそうです。この会社は様々な固体燃料を製造していますが、死者7名となったスペースシャトル・チャレンジャー号の爆発事故もこのこの会社が製造した固体燃料ロケットに原因の一端があります。
 このロケットモーターを使用したいくつかのSM-2は「戦時限定」の制限が加えられたそうです。つまり、平時の訓練では使うな、ということのようです。
 ミサイル防衛で使用されているスタンダードミサイル3や、新型のスタンダードミサイル6もMk 104を使用していますが、これらは異なるデザインであるため、影響は無いとのことです。

 今回はある程度の高い位置で爆発したため、上部構造物にダメージが出た程度で済みましたし、負傷者もなかったとのことです。
 しかし、もしも見張り台に人間が出ていればかなりの怪我になったはずですし、もっと艦橋に近い位置であればさらに広範囲に被害が広がっていたでしょう。もしかしたらイージスシステムの要であるAN/SPY-1レーダーにも悪影響が有ったかもしれません。
 さらに言えば、万が一、VLSセルの中で爆発した場合、艦の内側に爆風が閉じ込められ、燃え残りの燃料も艦内に残り、周辺のミサイルも高熱にさらされていたかもしれません。そのような事態になってしまえば、1960年台に発生した空母フォレスタルの火災事故のような大惨事になっていたかもしれません。
 そういう意味では、人的被害もなく、修理費も新造に比べれば非常に安く抑えられており、より深刻な事故が発生する前に問題のあるミサイルを発見し、使用に制限を出せたことは、ある意味では幸運とも言えそうです。

 この事故は同盟国で発生した事故、というだけでは済みません。アーレイ・バーク級を原型とした船は、日本でもこんごう型護衛艦、あたご型護衛艦として、現在6隻が就役しています。また、これらの艦艇にはSM-2ミサイルも搭載されています。
 海上自衛隊はあまり実弾演習を行いませんが、それでも皆無というわけではないでしょうし、有事の際にはしっかりと使える状態のものである必要があります。


 個人的に、この事故の事は気になっていたのですが、速報的に騒ぎ立ててるところはあれど、その後を書いているところは見つからなかったので、素人ながらすこしまとめてみました。最初にも書きましたが、何分英語はチンプンカンプンで防衛装備等も素人ですので、間違っていたらごめんなさい。