***
温泉だ、温泉だ! 温泉出た～～
小惑星探査機でも落ちてきたのかな? ちょうど甲子園の時期だしな……
***
PocketNCはPenta Machineに社名が変わりましたよ～
ペンタックスとかペンタゴンのペンタね。テトラの次、ヘキサの前。言うまでもなく、5軸加工機に由来する名前。
Webサイト曰く、9月中旬のIMTSで大型の機械を公開予定らしい。大型と言ってもHaas CompactMillよりははるかに小さいものだろうけども。Tormach 440に最初から5軸能力があるような機械になるのかな? お高いんでしょうねぇ。
***
エアベンチャー・オシュコシュでのホンダグループのモビリティに関する展示
高価格帯の製品の展示が多いなー。
HondaJetにスーパーカブのっけてツーリングみたいな遊びやってる人いないんかな? 機内にガソリンを持ち込むのは嫌な感じはするが。ジェット燃料で走るように改造されたスーパーカブ…… 甲高い音が響き渡るんだろうな。
***
「リコリコラジオ」第5回（ゲスト：ClariS）｜TVアニメ『リコリス・リコイル』公式ラジオ - YouTube
殺せんせー並みにヌルヌルしてるラジオ。ゲスト回も当然……
原案の人が北海道出身で、OP歌ってるのが北海道のグループで、作中で舞台になる喫茶店と同名の喫茶店が北海道に有って。怪しい機関の暗躍が疑われる案件ですね…… 北海道の美味いもの食べ歩きツアーが始まるのかな?
*
ポポポポ～ン。シリアス&コミカルな第6話。
殺された4人…… やっぱり死んでるんだな。。。
政府専用の回線。リコリス専用の回線網持ってるの? インフラの優先使用権の話どうなったし。
専用OS? TRONかな? いくらなんでもOSから作るのはさすがに手間かけすぎじゃねって気が。というか、専用にシステム全部作るならFPGAとかハードウェアベースで作ったほうが良さそう。日本全国にばら撒くならASIC化すればいいだろうし、本格的にハッキングも不可能になるから安心。
スマートフォンは民生品を使ってるのかな? 通信プロトコルレベルでは民間と同様なんだろうか。あるいは、スマートフォンで使ってるプロトコル類もDAから出てきたようなモノなんだろうか? 一般人が使うスマフォもDA仕込みのバックドアが……
配達に行く途中で襲われて、配達が遅れたおじさんは、さてどういう反応を示すかな? 手下を大勢引き連れて……
次回予告動画の公開スケジュール変更で妄想のネタが供給不足。アテにしてたのに。。。8割方妄想や空想で構成されている当ブログには致命的。
そういえば、5年前くらいはあらゆるアニメ等のグッズでベルクロワッペンを売ってた気がするけど、最近も売ってるのかな? リコリスのワッペンめちゃくちゃ欲しい。作品の世界観とは合わないけど、それはそれ、これはこれ。1stと2ndの赤と青と、ロービジっぽいグレーも欲しいな。
***
PETZLの「TACTIKKA」というヘッドライトを買ってみた。単4電池を使うタイプで赤色LEDがついてる最安モデル(おそらく)。いくつかカラバリがあるけど、今回はブラックを購入(若干安かった)。他にマルチカムっぽいやつとFDEっぽいやつの3種類がある。
今までは謎メーカーの2400円くらいのやつを使っていて、これは操作感が良くて好きだったんだけど、ヒンジがヘタってきて、ちょっとした衝撃や顔の動きで倒れ込んでくるので、通常使用にも支障が出てきた。7年ほど前に買ったやつだけど、樹脂のツメが劣化して折れたっぽい。
今まで使っていたやつは単4電池3本で最大90lmまで、タクティカも単4電池3本だが、最大300lmまで出せるらしい。めちゃくちゃ明るい。PETZL独自?のリチャージャブルバッテリーも使えるようだけど、そこまで使用頻度は高くないので、当面はeneloopを突っ込む予定。
最安モデルとは言えどもPETZL製なので、最低限のスペックは一通りそろっているはず。SOSモールスとかは無いけど(赤色ストロボは有る)。
タクティカの場合、電源短押しでは前回モード(白or赤)を復帰し、長押しでは赤が点灯する。白が欲しいときは短押しで起動し、白で起動すればそのまま使用し、赤で起動すれば長押しして白に変更する。白色はLowで起動し、ボタンを短押しすることでMid、Highへ切り替えられる(Highの次、あるいは一定時間後の短押しでOFF)。前回が赤だった場合、白Highで点灯するためには単・長・単・単の4回の押し込みが必要になる。
以前使っていた物は起動時のロジックが優秀で、前回モードにかかわらずボタン1回の押下で白と赤を任意に選択できた(もっとも、白のワイドとナローの切り替えは不便だったが)。タクティカはスイッチの操作パターンが複雑で使いづらい。
白色は3段階、ビーム切り替えは無し。ビームパターンは白も赤も綺麗。ただ、ビームが素直すぎるかな、というきらいはある。例えば白色光は高仰角(遠く)ほど強く照らしてほしいし、赤色光は手元を照らしてほしい。タクティカは白色も赤色もほぼ同軸のフラットなビームなので、白色と赤色を切り替えながら使うときは不便。
白色LEDのPWMは500Hzで、低輝度の時に顔の前で手を振ればフリッカーが見える。実用上は問題はない程度。輝度変更や消灯時はいきなり変わるのではなく、短い時間をかけてジワっと輝度が変わるのが、やはりブランド品という感じがする。ちゃんと制御してる感。
純粋な赤色スペクトルだと、白地に赤やオレンジで書かれた警告文みたいなものが完璧に見えなくなるので、安全性を考えたら若干の青や緑のスペクトルも欲しくはある。例えば電源ボタンを10秒くらい押せば赤LEDと一緒に白LEDも薄く点灯するモードに変更する、みたいな機能があれば嬉しかった。せっかくキッチリ制御してるんだから、安物には無い安全性が欲しかった。最安モデル買っておいて何言ってるんだって話だけど。
***
またまたEGSを撮影
5日23時頃。f250mm、シャッター30秒、ISO2500で撮影(35mm画素にF4のレンズ)。
下の方に見える点線がEGSのもの(薄く衛星本体の実線も写ってる)。上の枠の中(およびその下に拡大したもの)はおそらくQZS-2のはず。場所と動き(線の向き)からして間違いないと思う。QZSからすればEGSは大先輩にあたる衛星(運用の手軽さではGNSSに劣るけど、海洋測地ではRTK-GNSSを大きく超える範囲で使用できる)。
EGSは22秒くらいで通過するので、シャッターを30秒に設定して手動でレリーズ。とりあえず端から端まで写ってるので、タイミング精度は5秒未満には収まっているはず。
左側、EGSの上にある明るい物体は、少なくともSpaceTrackからは公開されていない物体だと思う。近い場所にはIridium 44やCOSMOS 593がいるはずだけど、30秒でこんなに小さく写るはずがない。かなり傾斜角が大きく、離心率の大きい、平均運動1前後程度のロケット上段?
***
ETS8/QZS4狙いで撮影(ISO6400以外は従前)
8日1時頃。目立つところだと、MSAT M1, GARUDA 1, USA 169, ETS8, 2x ARIANE 5 R/B, BREEZE-M R/B, QZS-4の8物体が写ってる。右側のARIANの右下に薄くSL-12(21221)も見えるかな?
今回は写真を目で見て探しているので、色の薄い(=速度の早い)物体は見つけられないけど、うまいこと画像処理を書いてインターバル撮影したデータを食わせればマッチドフィルタみたいにSNRを稼げるはず。かなり面倒なことになりそうだけど、そのうちこのプログラムも書かなくちゃ。。。
カメラ側のバグ?っぽいやつの切り分け・復旧(電池抜いてシステムリセット)に手間取ってしまったけど、事前に撮影計画を立案して待ち受け撮影みたいな流れはかなり安定して動くようになってきた。安物の天体望遠鏡に付属してた微動ハンドル付きの雲台を使っているので、グリップ雲台よりは細かく調整できるようになったし(軸周りの回転はできないけど)。現地で使うソフトが使いづらいのでこっちもどうにかせねば。
撮影中、やたら流星が多くて、小さいやつは頻繁に、大きいやつも2個ほど見えたんだけど、そういえばペルセウス座流星群の極大が間近なのか。
別の撮影中にRLFL14というのが結構明るく写り込んでた。Rocket LabのPhotonだと思うんだけど、直径1mくらいのパンケーキ型。こんな小さい物体が明るく写るものかな? どの程度の大きさの物体まで撮影できるんだろうか。
***
[C#] (long)x << 32 | y をDictionaryのキーにすると性能が悪化して死ぬ
衛星の位置計算(Sgp4や座標変換の三角関数、方位・仰角のためのatan2)が遅すぎるので、DictionaryにDateTimeOffsetのUtcTicksをキーにしてキャッシュしてるんだけど、どうもTryGetValueが遅い感じがする。が、Ticksを上下2個のintに分割してタプルにすると更に遅くなるので、longが特に遅いような感じはしない。
DictionaryはGetHashCodeのintをキャパシティ(素数)でmod取ってるので、空き率が下がると衝突しやすくなると予想される。ということで、コンストラクタで大きめの容量を指定しておくと、気休め程度に早くなる。ただ、衛星数が数万個あるので、全部に大量のテーブルを割り当てると簡単に16GBとかパクパク食べられてしまう。本当に気休め程度にしか早くならないし。
そもそも、Int32を2個パックしたlongをキーにすると性能が悪くなるのは、long自体が悪いのではなく、long.GetHashCodeとの相性が悪いだけっぽい。Ticksみたいに変化の大きい値ならそれほど問題にはならなさそう。
TryGetValueが遅いと言っても、毎秒400万回も呼んでいるのが悪いのだが。CPUリソースを100%使っていたとしても1回の呼び出しに250nsだし、実際には10%未満とかなので10nsくらいだろうし、CPUが3GHzとして10nsなら30クロックしかかかってないわけで、おそらくCPUダイのキャッシュには乗らない大きさだから一旦はRAMスティックから拾ってきているはずだし、そう考えれば連想配列のアクセスが数十クロックというのはめちゃくちゃ早いのであろう。
描画処理が遅いならTask.Runに突っ込めば早くなるんべ?と思って描画周りだけ取り出してマルチスレッド化してみたのだが、ものすごい遅くなった。キャッシュの衝突対策でDictionaryをConcurrentDictionaryに変えたらこれがめちゃくちゃ遅いらしい。
キャッシュをstaticで共有せず、画面ごとに専用のインスタンスを持たせれば衝突はしなくなるけど、メモリ消費量はN倍になるし、並列化したところで描画が早くなってる感じもないし、せっかく苦労して描画周り分離した割に全然改善してなくて、まさに踏んだり蹴ったりって感じ。キャッシュを競合アクセスしないように改造……と思っても予想以上に複雑に絡み合ってたりして、気軽に手を出せない感じ。改めて設計の大切さを痛感。。。後から変えるのは大変。
*
せっかく苦労してFoVと天球のレンダリングを分離したので、パフォーマンス改善しないからとそのまま捨てるのももったいないし、PDFでエクスポートする機能を実装。
文字や図はベクターで持ってるので、PC等なら拡大して表示したりもできる。今のところ未実装だけど、通過する衛星の一覧を書いておけばテキストで検索できるので、観測計画のPDFをフォルダに突っ込んでおけば、例えば衛星名で検索して過去の観測歴を調べたりもできる。
***
日本測地学会20周年記念特別公演 時と測地 -測地衛星と月レーザ観測のすすめ-
1954年を起点とするなら1974年になるのかな。LLR、口径2.7mの望遠鏡から3Jのレーザーを打って将来的に1-2cmくらいの精度を期待、だそうだ。
1928年に、飛島(日本海側の島)を高精度に観測して、100年後の再観測で移動を検出する予定だったそうだ。あと数年で2028年になるわけだが、再観測の計画とかはあるのかな? プレート運動等の直接観測はすでに(別の観測手段で)達成してしまったわけだが、記念事業的な感じで再観測をやったら面白そうだ。当時の観測手段に近い機材と最新の機材で比較実験とかやっても面白いだろうし。
1970年の日立の資料。’68年末頃から試験を実施して、’69年6月に最初の測距に成功。/* ルビーレーザーの最初の発振は’60年、アポロ11号月面着陸は’69年7月、「おおすみ」打上げは’70年2月 */
レーザはキセノンランプに3.6kJを突っ込んでルビーを励起し、20MW 50ns (1J)のパルスを得るそうだ。衛星の軌道は紙テープに出力しておいて、自動で追尾するシステム。当時、スミソニアン天文台では30秒程度の間隔で測距を行って、その合間に人間が手動で方位・仰角を合わせていたらしい(NASAは自動追尾)。
最近のSLRに比べてエネルギーが高いのは、検出素子の感度とかの関係なのかな? 光電子増倍管とルビーレーザの赤色光の組み合わせだと、量子効率は数%程度しかないらしい。
小型・低価格な衛星レーザ測距システム Omni-SLR | RISE月惑星探査 プロジェクト
国立天文台や一橋大学がSELENEやHAYABUSA2向けに開発したレーザ高度計の光学系を応用して、安価なSLRシステムを開発中、23年度までには実際に測距を行いたい、とのこと。将来的には極地研に南極で運用してもらいたい、みたいな話も。
極地研はVLBIも運用しているし、SLRができれば便利そう。ただ、せっかく南極でVLBIとSLRができるなら、GEO(QZS)まで見える設備があったら嬉しいよね、みたいな話は出てきそうな気がする。まぁ、まずはLEOで運用してみて、というところか。
Omni-SLR、開発成果はオープンにして使いやすく、というような方向性らしいけど、軽くググって出てくる範囲では上記ページ以外は見当たらない。どんなシステムになるんだろうか。
写真を見る限り、4軸の赤道儀を流用しているっぽいけども、うーん…… NICTが昔SLRかレーザー通信に使ってたシステムが4軸の赤道儀に乗ってた気がするが。小型の赤道儀は市販の駆動システムを流用できる利点があるけど、相手は恒星より3桁くらい早く動く人工衛星だからなぁ。慣性空間の軌道面を追尾するのに赤道儀を使う利点も少ないだろうし。/* そういえば、たしか福岡大が小型衛星を画像認識して自動追尾するシステムを作っていたはずなんだけど、あれはどうなってるんだろう? */
SOLISSってSLRに応用できないんかな? 一般的なSLRのピコ秒パルスレーザ(PRF数Hz-数kHz)と違って変調信号を送受信できるから、レーダーのパルス圧縮やFMCWみたいにSNRを稼げるはずだけど、さすがにLEO下端の1way用をLEO上端の2wayに使うのは厳しいか。SOLISSの時間ジッタってどの程度なんだろうか。再生型の光トランスポンダみたいに使って衛星・地上間や衛星・衛星間の測距ができるような仕組みになっていないのかな? デジタル変調だと距離分解能はせいぜい数m程度までしか出ないのかな。RFなら十分だろうけどSLRだともう一声欲しい。通信用のレーザ光学系をそのまま測距に使うのは厳しそうだな。「TLEよりはマシ」程度に小型衛星の軌道決定を行いたい、くらいの要求なら、SOLISSクラスのハードウェアでも対応できるのかな?
***
小ネタ中の小ネタ
8月4日(UTC)、20時間くらいの間にロケットが5機打たれてるんだな。長征系が2機、エレクトロンとアトラスVとファルコン9。サブオービタルも含めるとニューシェパードも飛んでるので、合わせて6機。
C#のレコード、record Hoge(int a, int b) { public int c = a * b; } みたいにプライマリに依存したプロパティがあって、Hoge a = new(1, 2), b = a with { a = 3 }; みたいなことをやったときに、b.cの値は6になって欲しいのに、そういう挙動にならない。結局、Hoge a = new(1, 2), b = new(3, a.b); みたいに手動でコピーしなきゃいけないので、withが役に立たない。プライマリコンストラクタに含まれる変数の数が増えてくると面倒なことになる。どうにかならんのかな。/* 実際はreadonlyな構造体レコード */
withはプロパティをクローンしたあとに特定のプロパティだけ書き換える、みたいな挙動らしい。なかなか不便。自前のプロパティなんか作るな(中でデータ書き換えたりするなら素直にclassとか使え)みたいなことなんだろうか?
空軍が使う兵器類、正式に採用する前に空力特性の確認とかする必要がある、というのはそのとおりなんだけど、必ずしも緊急時にその手順に従う必要があるかというと、ケースバイケースなのでわ。湾岸戦争の頃にはF-15Eへの正式承認が間に合わなくて緊急承認で一部の兵器を使っていた例もあるようだし。特にF-14/AIM-7やF-18/A-4みたいにドロップ式でなく、レールランチャーから撃つタイプなら、機体からの拘束が外れた時点ですでに十分に機体から離れているし、最低限α/βが小さいように気をつける程度で問題なく発射できそう。提供する側が「空力特性の確認をしないと……」とか渋っても、要求してる側が「そんなの撃ってみりゃわかるだろ。撃てなきゃこっちが死ぬんだ」とかゴネれば「勝手にしろ」とか言いながらも渡すだろうし。
0 件のコメント:
コメントを投稿