【近畿霊務局】ファイティングポーズを取るタイプの怪異をシメるお仕事【にじさんじ/ベルモンド・バンデラス】 - YouTube
っぱベルさんなんだよなぁ！
宇宙から帰還のＮＡＳＡ飛行士、地球への再順応の苦労語る 「座るのがきつい」(1/2) - CNN.co.jp
誰も本に書いてない? お前が書くんだよ!!
「気象衛星ひまわり」の「赤外画像」で障害 復旧見通し立たず | NHK | 気象
「ひまわり9号」トラブル半日余りで復旧 センサー温度上昇原因 | NHK | 気象
唯一のミッション機器が外国(L3H)から買ってきたセンサーってのは、トラブったときに面倒そうよね。最近の日本の宇宙開発は国産化を頑張っている気がするけど、日本の宇宙機の中で国民の生活に一番直結している気象衛星の唯一無二の観測装置が外国製ってのはちょっと最近の日本らしくないというか。
/* 28年度頃打上げ予定の10号機も追加の観測機器(サウンダ)含めL3H製。次期(10号機)までは時間がないから国際競争入札だけど、その後は国産したいよね、みたいな話はあるらしいが */
テレビ朝日、7月の障害の原因は「中性子線の衝突」 半導体の進化でソフトエラー発生率は上昇 - ITmedia NEWS
SEUはその他の原因の障害(サイバー攻撃とか、EMP攻撃とか)と比べて、同時に複数発生する確率は極めて低いから、本来であれば同構成の冗長系で緩和できるはずなんだよな。ただ、普通の冗長系は適切にハンドリングできる障害、大抵の場合はソフトウェアが投げた例外をキャッチしたシステムが正常にシャットダウンしたりして主系が使えなくなったことを従系が検出する、みたいなロジックだろうから、ちゃんと落ちず、ゾンビみたいに生き残るようなトラブルを綺麗に回避するのは結構大変そう。
確率で言えばRAMみたいに総ビット量が多いところに突っ込んでくるような場合が多いだろうから、ECCメモリ使えみたいな話になるんだろうけど、とはいえECCで保護できない領域(メモリの外側はたいてい該当)に衝突する確率だって無視できないだろうし。根本的にはソフトエラーフリーのプロセスを使って全部ハードウェアで実装する(Xilinxの宇宙用グレードFPGAをメインで使うとか、理想的にはASIC化)になるんだろうけど、コストとか柔軟性とか考えるとそんなわけにもいかないし、WindowsとかmacOSで動くソフトウェアはどうにもならないし。WindowsとかLinuxはソフトエラー対策を頑張ったハードウェア(ECCメモリを使うとか、ソフトエラー対策を行ったARMプロセッサを開発してもらうとか)で対応できるとしても、macOSはそういうことは不可能だし。結局「調子悪かったら電源引っこ抜いて無理やり冗長系に切り替える」的なマニュアルを用意するしかないんだろうな。で、データの破損とかサービス中断を怖がって手順通りに作業できず、大規模化するみたいな繰り返しになるんだろう。/* Appleってプロセッサを自社で設計しているけど、ソフトエラー対策設計はどの程度力を入れているんだろう? */
The Universe is Hostile to Computers - YouTube
SEUとかの解説の動画。Veritasiumは何でも知ってるな。
JAXA協力の宇宙ステーションシム『ISS Simulator』Steamにて無料公開。緻密に再現された船内を、自由に探索し放題 - AUTOMATON
Int-Ball(初号機)や宇宙服の三人称視点や一人称視点でISSの内外を動き回ることができる。Int-Ballと宇宙服はXboxビューボタンで切り替えられる(ローディング時間がアホほど長い)。船内はNode1まで、つまりアメリカ側のモジュールだけ動き回れる。
グラフィックはレイトレで表現されているので、グラフィック設定を落とすとかなりノイズ感が出る。グラフィック設定をUltraに設定すれば、RTX3060 FHDで30fps、ほぼノイズなしで描画できる。とはいえ、内部はテクスチャの解像度が低いし、テクスチャがないモデルは真っ白とかのっぺりした感じだから、Graphics Presetを上げて動くのでも、Graphical QualityはMediumとかに落としてザラザラにレンダリングさせたほうが雰囲気が壊れなくていいかもしれない。
運動モデルはニュートン力学とは違う挙動で、宇宙機の動きとしておかしい。自分が操作するInt-Ball以外は、船内に浮いている物体を含めてすべてが一つの剛体としてモデル化されているから、ぶつかっても相互干渉しない(Xbox Bボタンで別のInt-Ballを5個まで呼べて、それらは相互干渉する)。当たり判定もかなり簡略化したモデルを使っているっぽい。姿勢はオイラー角で管理しているらしくて、ヨーの符号が変わる場所は360度近くグルンと回る事がある。ジンバルロックもあるから、真上とか真下を向くとそれ以上ピッチングできないし、ゲッタンする。
例えるなら「リアルに再現された世界で自由に飛び回れるフライトシミュレーターという売り文句のゲームを遊んでみたら、エースコンバットのSTANDARDの操作モードしか対応していなかった」みたいな感じ。操作の次元が一つ少ない、という感じかな。車で言うなら「レースゲームを遊んでみたらアクセルとブレーキしかなかった(横軸の操作が欠如している)」みたいな感じか。同じように表現するなら、「電車のゲームを遊んでみたら「進む」と「止まる」のボタンしかなかった」とか。とにかく、そんな感じ。ゲームとしてインタラクティブではあるけど、ユーザーの自由度が本来よりも低い。
窓(JEM or キューポラ)から見える地球もおかしい。ISSの高度が高すぎるし、ISS底面(ローカル座標Z+)も地心方向からズレている。おそらくJEMの窓からほぼ正面近くに地球が見えるように、という理由でこういう無理やりな配置になっているのであろう。ISSの位置は日本海上空あたりで固定かな? もちろんこんな位置(高度・緯度)に静止衛星なんて配置できるわけもなく。日時は4月1日or10月1日から±1ヶ月程度の19時JST頃かな? 影の幅がちょっと狭い気もする。雲は地面とは別のテクスチャで西向きに等角速度運動している。偏西風を考えるなら逆向き。背景に恒星は見えない。まあ、恒星カタログの再利用とか手続き面倒くさそうだもんね。
現状、「宇宙機開発や宇宙実験のツールとしての使用も想定している」と言うにはお粗末な出来。今後のアップデートで運動モデルが改善されればあるいは、といったところか。せめて四元数なり、回転行列なり、ジンバルロックフリーの姿勢を使って、慣性や慣性モーメントを現実に即したモデルに改善してほしい。最低限、物理的に正しい挙動を実装して初めて「宇宙機開発のツール」としての入口に立てると思う。
さらに言えば、キーマウやゲームコントローラーだけでなく、TCPでコマンドを送ったり、テレメトリを受信したり、Int-Ballのカメラ座標系で見た画像を受け取ったりできるようになれば、ロボット制御とか画像認識とかの学習にも使えるツールになりそう。SteamでサクッとインストールしてTCPでコマンドを叩けるKibo-RPC的なシミュレータとして使えれば色々と使い道がありそう。PRCはJava(APK)専用でシミュレータは登録したユーザーのみ、実行に数十分、といった感じらしいけど、SteamからインストールできてTCPで叩ける、誰でも使えるISSシミュレータがあれば色々と便利そう。宇宙はモデルに忠実(外乱が少ない)だから、現実に則ったモデルを内蔵した手軽に使えるシミュレータがあればそれなりに需要がありそう。ISSの中のInt-Ballのモデルもそうだし、さらに言えばHTV-Xみたいに軌道上で動き回れるモデルがあれば宇宙機(軌道)制御のシミュレータや学習用の機材としても使えるようになる。
今のところは「アセットを配置してモーションのサンプルスクリプトを適用しました」程度の機能しか無い感じがする。これが地上の建物に人型ロボットとか(「いかにもゲームのキャラクターです」的なアセット)を置いたのであれば違和感は少ないのかもしれないけど、宇宙という環境では違和感がある。JAXA提供のデータとかISSのアセットはともかくとして、やる気とか運さえあれば高校生でも作れそうな感じ。JAXAから気温や湿度のデータも提供を受けた、と言っているけど、そんな要素どこに反映されているんだ。。。
仕事でデジタル空間を扱う会社が、新入社員の練習用に作ったとかでもないのに、こういう簡素な(違和感のある)ゲームを配布すると会社の技術力に疑問がつくから気をつけたほうがいいと思う。特にこの会社は宇宙関連の仕事に力をいれたいらしいが、そういう意気込みの会社がこういうものしか作れないとなると、宇宙に興味はあるけど知識はない人(会社)を騙して仕事をする会社なのか?と勘ぐってしまう。
スペースデータ、宇宙ステーション開発基盤「Space Station OS」を公開 | TECH+（テックプラス）
ISS Simulatorの会社。ISS Simが11月7日に公開、S.S.OSが同月11日に公開。
うーん……
JAXAからデータの提供を受けた、とかはSSOS側の話であって、ISS Simとはまた別件の話なのかな? ISS Simはあくまでもアウトリーチ用の簡素化したゲームであって、宇宙を再現することは重要ではない、みたいな。
SPACEX - ISS Docking Simulator
4年ほど前にSpace Xが公開したブラウザゲーム。ジンバルロックもないし、運動モデルもある程度リアルに作り込まれているはず(GUIはオイラー角だけど、それはしょうがないね)。ISSの周りを飛び回ろうと思ったら推力が小さいとか、かといって精密にドッキングしようと思ったらインパルスビットがデカすぎとか、あちこち見て回ろうとすると範囲外判定でゲームオーバーになるとか、細かいところでは遊びづらいけど。
あと、地球のテクスチャは解像度が低いし、ISSの飛行方向が逆な気がする(西向きに飛んでいる気がする)。飛行速度も結構早い? もちろんISSのリアルタイムの位置とも連動していない。
京浜ラムテック －SSW（同期撹拌接合）Tool Holder ー【日本語版】 - YouTube
SSW Amazing Welding speed - YouTube
SSW（同期撹拌接合）事業 | 事業紹介 | 京浜ラムテック
摩擦攪拌接合(FSW)は強い反力がかかるため、高剛性なFSW対応工作機械を導入する必要がある。SSWでは反力を抑えられるため、一般的なマシニングセンタやフライス盤で加工ができる。FSWに比べて2倍の加工速度、FSWより低い加工温度、FSWより高い接合強度、というふうに、FSWよりも高い性能が得られる、とのこと。アルミに深さ1mmで21m/min程度の加工速度が出るらしい。
何が「同期(Synchronized)」なのかよくわからない。SSWは回転だけでなく、軸方向の振動もミソらしい。ただ、「マイクロ波」と言っているけど、機械振動でマイクロ波レベル(GHzオーダー)の振動ってけっこう大変じゃね?という気がする。「振幅がマイクロメートルサイズの波」みたいな意味でマイクロ波と言っているのかな。
https://ilrs.gsfc.nasa.gov/docs/2024/NESC_Slides_0215_2024.pdf
Omni-SLR関係の資料。英語だけど。順調に開発が進んでいるようでなにより。
SLRってリターンを検出できれば国際的な地図に登録してもらえるのかな? 当面はともかくとして、数年か10年かすればアメリカとかEUあたりのYouTuberがSLR地上局を作りそうな気もするけど、そういうのも妥当性のある結果を報告すれば登録されるんだろうか。Omni-SLRだと4.6kWくらいのレーザだから当面は気軽にアクセスできるものではないとしても、最近のガチのYouTuberはやることがいちいち本気だからなぁ。
最近だと50万円くらいの小さい発振器でも10kW程度のパルスレーザーを出せるものもあるらしいし、アメリカの方だと研究室が放出した機材を確保する個人も多そうだし、ある程度のものなら作れそうな気がする。アクティブな光学系(レーザー発振器)とパッシブな大型光学系(受信開口)、それと機械構造(追尾用装置)、それらを制御する電子回路やソフトウェア、等々、SLRは結構幅広い領域である程度の技術力が必要だから、仕事でSLRを触っているわけではない個人が自力で作ろうとするとちょっと大変そうではあるけど。とはいえ、最初は小さな開口(TX用とか)だけで衛星を追尾する機構を作って、追尾を実証した後に大型の経緯台に交換して、それで追尾精度を高めつつ大型の開口を乗せて、追尾信号に1Hzくらいの振動を与えたうえでフォトンカウンタで検出できるように引き込んで、最後にレーザーを追加して、みたいな流れで、ある程度段階的に作れるはず。トータルのコストは、まあ、大して変わらんだろ。最初から大型の経緯台を使えば最終的に全部必要になる機材しか使わないし。全部新品で揃えて数百万、eBayで買えば数分の1、くらいで、欧米のYouTuberなら十分手が届くレンジな気がする。
マイナビのテック系のニュース、数年前から会員限定コンテンツがちらほらあったけど、ここ最近で急に増えてきた感がある。会員登録してみようと思ったんだけど、メールアドレスが「勤務先メールアドレス」と明記してあるのが不思議。個人が自宅で契約したISPから付与されたメールアドレスとか、あるいはフリーメールとかは駄目ってことなんだろうか? 利用規約とか会員規約を読んでみても「個人の登録は禁止」みたいな記述はなさそうだが。
マイナビにもフリーのライターが書いた記事があるはずだけど、彼らは自分が書いた記事をどうやって読んでいるんだろう? 自分が書いた記事は当面は書きっぱなしでいいとしても、他のライターが書いた記事とか、あるいは自分が書いた記事をあとから参照する必要がある場合もあるだろうに。マイナビと契約したらマイナビから仕事用のメールアドレスが割り当てられる、みたいな仕組みがあるんだろうか。
会員規約で「当社から付与された会員IDおよびパスワード」と書いてあるのが面白い。会員IDはともかく、パスワードはユーザーが入力するんだから、「当社から付与された」ではないだろうに。ゲームだと「ユーザーが作ったコンテンツは当社の管理下に入るよ」みたいな規約があったりするけど、同じように「ユーザーのパスワード等は当社の管理下に入るよ」ということなんだろうか。
Mac miniの底面のアレ。MacってCPUの外で細かい処理をするチップが乗ってるはずだし、電源OFFでもキーボードとは常に接続しておいてキーボードのTouch IDを押したら起動できる、みたいな感じになるのかと思ってたけど、そういうわけでもないんだな。その程度の機能は簡単につけれるだろうに、なんでついてないんだろ。
Fireタブレット10でAcrobatを2画面表示。さすがに表示サイズが小さくなるので見づらいけど、並べて表示できるので便利。
Androidの画面の下に表示される3個のボタンの右側の■ってダブルタップすればアプリが切り替えられるんだな。わかれば便利だけど、普通気づかんだろ…… スマホの機能、古代遺跡並みに謎解きが多い。
作業PCは正面のメインディスプレイ(4K)と、その右側にサブディスプレイ(FHD)が置いてあるけど、視線の左右移動は結構疲れる。16:9モニタだから横方向は離角が大きいという理由もある。メインディスプレイの下、机の上にタブレットを置くと視線の移動量が少なくて住むから、頻繁に視線を移動するのも苦にならない。タブレットでPDFを表示するのは思ったより快適。まあ、そんな事言い始めたらメインディスプレイの下(手前)に大きめのモバイルモニタ置いたらいいじゃん、という話になるんだけど。
***
QZSS SLAS、復調率はかなり悪いけど、いくつかのパラメータは取り出すことができて、札幌のDGPSの補正項(擬似距離に対する補正値)も得られたので、測位計算に適用(とりあえず大気遅延の補正は省略)。分布の大きさは変わらないけど、中心位置は結構変わる。単独測位(SLAS DGPS非適用)の場合、Pixel6aで受信した位置との差分ではほぼ誤差が無いけど、SLAS DGPSで補正するとそこから大きく(10m程度)ずれる。Pixel6aは単純な単独測位だろうから、確度としてはさほど高くはなくて、SLASで補正したほうが正しい位置、という可能性もあるけど、判断に悩む。
正解位置を、地理院地図の写真から、実際にアンテナを設置した場所の座標を得ると、Pixel6aで得た値と若干ずれる。ただ、それはSLASの補正と同じ方向にずれるから、SLASの補正を合わせるとより大きくズレる。SLASの補正の符号を逆にすると少し戻るけど、まだ多少は残るし、高度方向はより大きくズレる。地理院地図の精度は17.5mとのことだから、今回の測位計算で得られる精度(半径15m程度)に比べてあまり高いとは言えない。地理院地図の精度は保証値だから実際にはもう少し高いとしても、微妙なところ。結局、精度を確認しようとすると、三角点みたいに正確な位置が求まっている場所でサンプリングするしかないんだろうな。
SLASの仕様書によると、観測局と距離が遠い場合は対流圏遅延の補正を行う必要があるし、最小二乗法を解く際にも衛星ごとに重みを設定しろというふうに書いてある。重み付けは衛星ごとに誤差の量を推定して誤差の少ない衛星を優先的に使うようなパラメータだけど、この計算がかなり複雑で、1ページ丸々重みの説明に使われている。この重みはDGPSを使わない、通常のGPS単独測位でも使われるものだけど、DGPSの場合は地上局との距離とかも含めるので、もう少し複雑。
IS-QZSS-L1Sの式5.5-4、重み付きの最小二乗法を解くものだけど、POS = (G^T・W・G)^-1・G^T・W・dPRcorrectedという形。ここでPOS:User positionが直接出てきているのが謎い。この計算で得られるのって移動量(POSへ加算する量)じゃない?
SLASの復調率が悪すぎるので、ビット復調のアルゴリズムを変更。遅延検波を使うようにしてみた。以前は1フレーム6メッセージで復調率0/6が連続するのが当たり前みたいなタイミングもあったけど、新しい方法では数分間程度ならすべて復調率6/6でメッセージが取り出せるようになった。
SLASのメッセージはIODの組み合わせを取り扱うのが面倒そうな気がする。SLASのIODも何種類かあるし、その中ではエフェメリスのIODを指定する部分もあるし。衛星から特定のメッセージを受信した場合は過去のメッセージと続く一定時間のメッセージを破棄するようにも求められているから、SLASは衛星ごとに管理する必要がある(ハンドオーバー時も次の衛星ですべて必要なメッセージを受信したあとで切り替えることが求められている)。すべてのIODの組み合わせを適切に処理しないとだめなので、取り扱いが大変。どうやって処理するのがいいんだろうか。
SLASのDCとかDCXを復調すると地震情報とか海上気象とかの情報が得られるので、これらのメッセージを貯めるような機能も作りたいな。
適当なタイミングでサンプリングしたIQファイルから、C/Aコードの相関値
右側に184,185,186,189,194,195,196が出ている。189はQZS-3から放送されているもで、中程の137も同じくQZS-3から出ているもの。一方で、QZS-3から出ている他の129と199はピークが出ていない。他にも、可視範囲にいるはずなのにピークが出ていないものがいくつか(これはアンテナの指向性の可能性もあるけど)。
準天頂衛星の仰角
衛星配置がちょっとズレていて、10時半頃に深めのノッチがある(時刻は1日あたり4分程度の速度で移動する)。この隙間に5号機が入るのかな?
試しに、人工衛星の軌道を描画。横軸がXY平面の距離、縦軸がZ軸の距離。
↑左端が地心、右端が8万km、上下が±4万km。左端のグレーの丸が地球の大きさ。
橙がQZS、緑がIRNSS、赤がBEIDOU、青がNAVSTAR、黒がそれ以外の物体。
こうしてみるとGPSが結構上下方向に広く分散しているのがわかる。そりゃ相対論的補正も効いてくるだろうて……
↑中央が静止軌道付近、左右が±300km、上下が±3000kmの範囲。
外側の赤や緑は傾斜角の大きいBeiDouやNavICを表している。静止軌道の外側を回るように(静止衛星が濃集している領域を高速で通過しないように)飛んでいる。QZSSも静止衛星が濃集している領域をある程度避けて通過している(傾斜角が大きい衛星グループの断面を通過する形ではある)。
ついでに、静止軌道付近で上下左右とも±100kmを拡大(各測位衛星もすべて黒で表示)。大部分の静止衛星も南北方向に若干(50km弱)ふらついている。0.1度にも満たないような軌道傾斜角だけど。
GPSの記事で、衛星が出力する電波が「一般的な電球と同じ程度」という説明があるけど、うーん、って感じ。GPSのL1 C/Aの送信電力と電球の消費電力は確かに近いんだろうけど、電球はスペクトル幅がアホみたいに広いので、人間の目が持つバンド幅では全放射電力の10%程度しか検出できない。その10％を指して「これが2万km先で光っていると考えてください」というのは、ちょっと乱暴。まあ、「一般的な電球10個分の明るさが2万km先で光っていると考えてください」と言われても、大して違いはないわけだが。ランダウ記号で定数倍を無視しているのと同じと考えれば、当たらずとも遠からずとも言えるか。
例えばEQUULEUSは1W(豆電球の数分の1)で150万kmまで64kbpsで通信できるわけだから(受信側でアホみたいな利得を確保しているとはいえ)、電気通信の電力を人間の視覚に当てはめてもあんまり納得はできないような気がする。人間はコヒーレント積分なんてできないし、宇宙通信はコヒーレンシーに依存してるし。
周波数と通信距離が反比例すると考えれば、GHz帯とnm帯では6桁近い差があるし。
GPSのC/Aコード、Coarse/Aqcuisitionの略だと思うんだけど、松浦さんの本とか記事(例えば 航法の歴史（4）SAの廃止｜衛星測位入門｜みちびき（準天頂衛星システム：QZSS）公式サイト - 内閣府)ではClear and Acquisitionの略として書かれている。Clear and Acquisitionでググってもあまり出てこない。全く出てこないわけではなく、例えばPseudorange Error Correction of Clear/Acquisition Code for civil users of CPSとか、ちらほらとは出てくる。内閣府の仕事でもこの表記が使われているのは、内閣府がその表記を承認しているのか、単に誰もチェックしていないだけなのか。後者だろうなぁ。
ちなみに、本家本元のICD-GPS-200CやIS-GPS-200Nでは、3.2.1 Ranging Codesの中で「coarse/acquisiton (C/A) code」と書かれている。IS-GPS-200Nの中では「clear」という単語は1回も出てこない。
準天頂衛星に対する批判の中で、GPSに比べて2倍の高さを飛ぶから4倍の送信出力が必要で衛星が大型化し、衛星や打上げコストの高騰を招いている、という物があるけど(例えば松浦さんの9784594095741とか)、ちょっと違う気がする。
対地同期軌道を選択しない場合、地域測位システムとしては成立しないわけで、全地球測位システムではなく地域測位システムを作りたい場合、衛星の配置は対地同期軌道(GPSの2倍の高度)が唯一の選択肢となる。少なくとも30機弱が必要な全地球測位システムと、10機程度(システム単独で測位する場合)で済む地域測位システムでは、衛星の構成にもよるだろうけど、地域測位システムのほうが安く作れるはず。
他の測位システムと比べると、GPS Block IやGalileo、GLONASS-Kの750kg前後やGPS Block IIの1500-2000kgと比べると、QZSの4000kg超は非常に重いと言わざるを得ない。一方で、NavIC衛星が1500kg弱程度であることを考えると、対地同期軌道という距離の遠さによって衛星が大型化した、という批判は正しくないと思う。
どちらかといえば、対地同期軌道で使用できる信頼性のある衛星バスが日本には三菱電機のDS2000系しかなく、DRTSを除けばDS2000は5トン前後の衛星しか作ってこなかったから、準天頂衛星もそれに倣った規模にならざるを得なかった、という流れのような気がする。
DS2000はもう少し小型の衛星も想定しているから、本来であればDRTSの様な比較的小型の対地同期衛星を作ることもできたはずだが、ではなぜDS2000が4-5トンクラスしか作ってこなかったかといえば、それこそ本の中で書かれていたように、スーパー301条の影響であろうし、301制限下でも小型化した衛星で低価格を武器に民間市場で勝負するといった方針を推進しなかった政府の宇宙政策の問題でもあるはず。
QZSが測位衛星の基準ではかなり巨大でゆえに高コスト化したという批判は、「軌道高度が高いから」ではなく、「日本国内で作れる人工衛星がそれしかなかったから」という感じになるんじゃないだろうか。それに対して「地域測位システムはNavICが最適な形であって、日本もNavIC型を採用するべきである」というのは、ちょっと違う気がする。そもそもGPS衛星より高い高度を採用したという理由でQZSを批判すると同時に「NavICを見習うべきだ」という書き方は主張に一貫性がない。
あと、NavICの開発は軍事的な要求が少なからず存在したという点を留意する必要がある。1999年に印パ間で起きたカルギル戦争の際に、インドは米国へGPSを含む宇宙技術の使用を求めたが、米国はこれを拒否した。それによってインドは早急に独自の測位衛星を必要とし、NavICの開発につながった。それが比較的小型の衛星を対地同期軌道へ投入する形で実現した。少なくとも、パキスタンや中国との領土問題を抱えるインドの宇宙開発は軍事的な側面がより強いと考えるべきなはず。
対して日本は独自の測位システムを早急には必要としておらず、それゆえに大型の衛星に実験機材を多く搭載して、「これは実験用の衛星ですよ」という建前を全面に押し出した衛星を1機打上げた。あるいは、301だけでなく、兵器を誘導するシステムとしての意味合いが強い測位衛星の特色を最大限避けるという狙いもあったのかもしれない。
宇宙技術の側面から見ると、準天頂衛星は政争とか301以降の事なかれ主義や主体性のない意思決定を続けた政府の宇宙開発方針の問題といえばそれまでだけど、もう少し別の方向からも見たほうがいい気がする。軍事面から見れば「平和ボケ」という形になるのだろうし、政治面から見れば「アメリカからの横槍(あるいは周辺国からの強い反発)を防ぐ」という形にもなるだろうし。
あとは、最近の小型衛星コンステの文脈で、高度を下げると送信出力を大幅に下げられるから小さな衛星で構成できて、衛星単価や打上げコストを削減できる(安価に測位衛星システムを構築できる)、みたいな話を見かけることがあるけど、GPS互換に近い信号(CDMA)を使おうとした場合は遠近問題が出てくるので、おそらくシステムとして成立しなくなると思う。CDMAに関するもう一つの問題は、大量の衛星(数百機以上)から信号を放送する以上はアメリカの猛反発が予想されるから、放送帯域もGPSから移動する必要がある。結局、受信機もRF周りから多重化方式まで、そこまでやるなら測位計算まで含めて全部作り直しになるから、おそらく誰も乗ってこない。既存のGNSSに強い不満があって、かつ莫大な費用を許容できるユーザーであれば採用するかもしれないけど、全世界に対して宣戦布告して全地球規模で交戦を行い、なおかつそれに勝って地球全体を支配下に置く、位の見込みがないと、今更全く新しい測位システムを作る、なんてことはできないはず。敵性エイリアンが地球に侵攻してきたら、彼らの測位システムはGPSとは非互換だよね、位のイメージ。まあ、ココ・ヘクマティアルあたりなら作るかもしれないが(あいつは既存のGNSS自体クラッキングするなり撃墜する形の方向性だからな。。。)。
逆に言えば、全く新しい衛星を大量に打上げて、それ用の受信機が普及してしまえば、問題はない。例えばスターリンクは衛星が大量に打上げ済みだし、それと通信できるスマートフォンもあと数年程度で大量に普及するだろうから、スターリンクのビーコンを使って測位する機能は数年で普及しそう。スターリンクはTDMAやビームフォーミングで地上局の位置情報がほしいだろうから、自身の信号でユーザー局を測位できるなら、GPSを使わずに自身のシステムで測位するはず。とはいえ、これはLEO測位衛星コンステレーションを普及させようとして作ったものではない。
***
最近のVisual Studio、インテリセンスがちょっと進化してて、「最後に選択した項目」じゃなくて、「最後に使った項目」が次に使われる。例えばhoge[]があったとして、hoge.Selectをインテリセンスで選んで手動でManyを入力して、hoge.SelectManyを使った場合、古いVisualStudioでは次にhoge.Sel[Enter]を行うとhoge.Selectが選択される。一方で最近のVisualStudioでは同様の操作を行うとhoge.SelectManyが選択される。
自分はSelectを使うことが非常に多くてSelectManyを使う機会はかなり少ないから、次回にSelectManyが入力されると面倒なので、Manyは手動で入力することでインテリセンスにはSelectを記憶させていた。最近のVisual Studioでは手動で入力した項目が記憶されているから、次回Selectを使いたいときにちょっと面倒くさい。
0 件のコメント:
コメントを投稿