最近のWindows、やたらタスクマネージャが不安定がち。1日くらい起動しっぱなしだと固まる。幸いにして多重起動が可能なので、別のタスクマネージャを起動して固まった方を強制的に殺せばなんとかなるが、完全に回復しているかは怪しい(グラフの描画がちょっと怪しい気がする)。
あとは、いつものことだけど、Windows Searchが時々大量のディスクアクセスを行う。明らかにPCの動作が遅くなるので、たいていは気がつくけど、気がつくまでにCドライブに50GBくらいのファイルが作成されている。Windows Searchはしぶとくて、殺そうとしてももなかなか死んでくれない。作成されたファイルを削除するにはインデックスの再生成をさせる必要があるので、いちいち設定画面を開くのが面倒。
ディスクアクセス量を把握するにはタスクマネージャを見るのが手っ取り早いけど、最近はタスクマネージャが不安定なので、この2つが組み合わさるとちょっと不都合だな、といった感じ。
Win11はOSの安定性はかなり高いけど、OS付属アプリの安定性が若干低下している印象。
AmazonのPrime Videoのウォッチリスト、前まではウォッチリストをprimeでフィルタできてたから、とりあえずウォッチリストに突っ込んでおいてアマプラで見れるようになったら見る、みたいな使い方ができてたんだけど、最近はその機能がなくなって、ぐちゃぐちゃなウォッチリストが丸見えになってしまった。
AmazonのPrimeサービス、最近迷走しがち(Prime Musicとか)。ロケット開発になんてうつつを抜かすからこんなことに。。。(ラノベ作家の悪口はやめろ!)
いつも以上に妄想するけど、脅威度の高い大型の害獣を駆除するので、いよいよ手がかりがないって状況であれば海保のMQ-9を借りるって手も考えても良さそうな気がする。八戸から釧路なら人口密集地を飛ぶ必要がない(海の上を移動できる)し、低速の無人機を使うにしてもそう遠い距離じゃないし。
日本は国土が全周海に囲まれてるからなー。アメリカの国境で麻薬密輸犯を追いかけるような、陸上で隠れながら逃げ回る人間やら動物やらを陸空連携で追いかけるような状況はそうそう発生しなさそう。海で人を探すようなスキルは高いだろうけど、陸上だと物陰とか地表の物体の放射率の差とか色々感覚が違いそう。
切削加工ってこんなに静かにできるんか。
Int-Ball2が宇宙に旅立ちました！ | JAXA 有人宇宙技術部門
丸っこいツルツルの1号機に比べてだいぶメカメカしくなった印象。個人的には1号機のほうが好きかな。2号機はなんか悪役っぽさというか、ちょっと口が悪そうなキャラのイメージ。とはいえ、2号機は耳はついたけど口はついてないはず。WiFiでリアルタイムに映像や音声を下ろせるなら地上からの声を出したりできたほうが便利だろうけど、NASAとしてはNASA管理外の回線で音声通すのは嫌だろうし。アルテミスIにAlexaが同乗したし、同じような感じでInt-Ballにも会話機能乗らないかな。小さいファンだけだと推力も少ないだろうからパタパタ動く羽も4枚くらい追加して……
ところで、'19年3月に3号機の話がちらっと出てきていたので、その頃には2号機の開発はある程度進んでいたはずなんだけど、ようやく打上げられた。だいぶ時間がかかった感じだ。
HYFLEX('96年打上げ)やALFLEX('96年飛行実験)やHSFD('02年飛行実験)、飛行制御系のデータバスにMIL-STD-1553Bを使っていたらしい(HYやALはMHIが担当)。実験機なので宇宙機やロケットほどの信頼性が求められなかったので、比較的新しい技術を使いやすかったとのこと。
H-IIAの誘導には32bitMPUを使用しているけど、これはHYFLEXで使用したV70をH-IIAにも適用したもの。第2段では3重冗長で使用(第1段およびLRBは1重とも3重とも取れるような書き方)。25MHzで、RAM2MB(内1MBをROMとして使用可能)、ROM128kB。H-IIAではオンボードのデータバスに1553を使用(アンビリカルはEthernet)。
'84年の資料では1553に関連して日本電気の名前が出てきている。ググってもほとんど出てこないのはググり方が悪いのかそれ以降ほとんど触っていなかったのか。しかし、NECと1553ってあんまり印象ないなぁ。1990年代中盤以降になるとNECはJEMやALOS、WINDSやSELENEといった宇宙分野で1553を使っているけど。
飛鳥(STOL実験機)の飛行制御はメカニカル+デジタル支援かな? HUD周りでARINC-429を使っていたらしいけど、飛行制御には使っていないっぽい。1773を乗せるみたいな話があったような気がするけど、あくまでも飛行実験にコンポーネントを載せて実環境で動作確認を行った、くらいなのかも。
日本で1553が本格的に使われ始めたのってどのあたりなんだろう? XF-2の1995年あたりとか、それから数年遅れてF-15J(J-MSIP)とかのあたりなのかな。同じ頃にHYFLEXとかALFLEXが飛んでいて、F-2もF-15もHYFLEXもALFLEXも全部MHIだけど、さすがに有人戦闘機と無人実験機は、全く別とまではいかずとも、別のチームで管理してるだろうし。MELCOも遅くとも99年にはAAM-4で1553を使っているはずだから、それ以前に研究は行っているはず(DS2000系で1553を使い始めたのはもう少しあと)。やはり90年代前半から中盤頃に日本のメーカー各社が本格的に使い始めたのかな。
日本で最初にMIL-STD-1773を使い始めたのは1997年打上げのTRMMに載せられた降雨レーダ(NEC/東芝)のはず。ただ、これはNASAの衛星なので、日本側で1773を触っていたのかは不明だけど。
F-2のジャイロは直交3軸+スキューの4個らしい(加速度も)。ただ、墜落事故の原因を伝え聞く感じ、整合しない入力が与えられても上位で故障検出ができるわけではなく、あくまでも自己申告で故障を通知されたら入力を切り替える程度のロジックなのかな。RLGみたいに故障率が十分に低いセンサであれば、下手に複雑なロジックでFDIRするより、自己診断を波及させていくほうがいいのかも。処理能力とか諸々の条件で最適化しているんだろうけど。
自己申告で故障を分離するなら故障側を切り離せばいいけど、上位で故障検出するためにはどちらが故障しているから判定する必要があるから、さらに多くのセンサが必要になる。故障率とかコストとかを考えるとそこまでするほどでも……という感じか。
C-1輸送機、荷物や人員を空中投下する関係でかなり大規模に風洞試験をやっていて、当然1箇所の施設では足りないので様々な風洞で実験を行っている。で、同じような試験をやった際に、風洞によって2倍程度の差が出ることもあったらしい。
D-SEND#2の1号機は風洞試験の計測誤差(あと制御則の安定性の少なさ)で飛行制御に失敗してたよな。D-SEND#2は機体後端のデザインが重要な機体なのだけど、風洞実験用のモデルの後端に取り付けたスティングの誤差を無視していたので適切にモデル化できず、適切なモデルがないのでシミュレーションも適切にできなかった。
日本で航空機開発がもっと活発であれば風洞の計測誤差のノウハウとかもいろいろ残っていたんだろうけども。一旦ノウハウが失われはじめると急速に失われていく。少しでも技術が失われると失敗する確率が増え、一度失敗すると大きなコストが発生し、それで開発が停滞するとさらにノウハウが失われる。修練を一度止めれば得た技量は倍の速度で錆びていくってめっちゃんが言ってた。
767や777の開発を順調に行ったボーイングが787では計画が大きくずれ込んだのは、787までに期間が空きすぎて開発経験が失われた(技術者の退職含む)のが原因という話もあるらしい(他にも基礎研究とかプロジェクトマネジメントとかも言及されてるけど)。777から787までの15年(当初計画ではもっと短い)でもそういう事態になるんだから、ねぇ。経営判断で支出削減のために新規開発を中断していると次の開発で追加のコストがかかるという。追加の開発や納入の遅延みたいな直接的なコストだけじゃなくて、エアラインや旅客からの印象の問題もあるし。
https://www.jstage.jst.go.jp/article/jjsass1969/32/369/32_369_593/_pdf/-char/ja
飛行機の自動着陸はかなり歴史が古くて、'70年代とかのあたりで結構実用的なところに入っていたらしい。当時はILSだけど、10年から20年程度でMLSに切り替わるだろう、とも(結局ILSの高精度化でしのぎきった感はあるけど)。この当時の飛行制御はMTBF500hとか、極めて信頼性が悪くて、パイロットから嫌われていたらしい。自動着陸を実用化するためにはこの信頼性がネックで、冗長構成を始めとして高信頼化を進めた結果、自動着陸のみならず、フライ・バイ・ワイヤのように極めて高い信頼性が求められる用途への道がひらけてきた。デジタル飛行制御が行われるようになると複雑な制御も行えるようになって、燃費改善みたいな方向性も(オイルショックから数年後とかの時代だからな)。
この当時は実現していないが、ILS Cat IIICでは視程0ftでの着陸が可能。視程がゼロだからコックピットから滑走路や誘導路を視認できない状態でも運用が可能で、それを実現するために自動着陸だけでなく、タキシングやボーディングブリッジへの接続まですべて自動にする必要があると考えられていた。
FBWの耐雷性の低さ(冗長系があっても全部が同時に影響を受ける)からFBLの研究も行われているが、さらなる燃費改善を目的として推力以外の全電化の要求もある。抽気や油圧を全廃して、ヒータやアクチュエータを電動化する。電化はB787でようやくある程度のところまで来た感じかな。油圧に関しては、例えば配管が損傷して作動油が抜けると全体の数割のアクチュエータを失うけど、電動化されていれば作動油抜け自体が無いし、アクチュエータ単体の故障が他に波及することもない。配管類を大幅に削除して構造もシンプルになる。
アクティブな飛行制御はロケットに端を発しているらしい。従来の航空機のように空力中心を質量中心より後ろに置いた設計から、ロケットでは質量中心が後ろにあり、エンジンをジンバリングすることでアクティブに安定化させる。フライバイワイヤも宇宙機から航空機へ応用された(アポロコンピュータをF-8へ載せた実験機とか)。
https://www.jstage.jst.go.jp/article/jjsass1969/38/433/38_433_77/_pdf/-char/ja
パワー・バイ・ワイヤ用EHA(Electro-Hydrostatic Actuator)の試作例。昭和63年である。実用化されるまで長かったなー。
オンボードのSAR画像化って、例えば月の着陸誘導に応用したりできるのかな? 垂直降下前のコースティング中(数秒間の慣性飛行)でSARを取得してオンボードで画像化、高解像度のレーダ画像を得て、内蔵している地形情報と相関させてサブメートルで測位、とか。DEMの精度次第だけど、地形を面で認識できるから、統計的にDEMの分解能以上の精度が得られそう。オンボードでSAR画像化ができるなら着陸前の周回で自分で地図データを作るという手もある。火星みたいな大気を持つ天体に使うのは厳しいけど。
あるいは、月有人活動が活発化する時代を見越して、月SAR衛星を飛ばして大量に画像化&ダウンリンク、ミッション末期に月面に落とすついでにSAR誘導の実験を行う、とか。レーダの出力的に小型衛星だとちょっと厳しいけど、とはいえ100kgもあれば地球のSAR衛星は作れるわけだから、低高度を飛行する月ならもっと小規模になるわけで。他にもRainCubeみたいに6Uのアクティブレーダ衛星もあったわけだから、場合によっては6Uキューブで月面のSARマッピング&SAR測位実験(誘導制御は行わない)みたいなこともできそう。
画像認識と比べて日照条件(月齢)の影響を受けないのが利点。着陸時期に対して測位側からの要求がないので、打上げ時期が指定できない相乗りミッションにも良さそう(月面は月齢による熱環境の差が厳しいので結局はある程度拘束されるけど)。カラッカラに乾いた月面でのレーダ画像は懸念事項か。まぁ、HF帯とかを使うわけじゃないので……
アクション作品(映画とかゲームとか)で時々出てくる、CIA等の人間が世界中で無線を使って本部とやり取りしているシチュエーション。そういえば、TDRSはスペクトル拡散とかビームフォーミングとかで通信できるわけだから、TDRSを使えばそういう事ができるんだな。少なくとも80年代末以降は、アメリカの政府組織は必要があれば世界中で(高緯度地域と一部の経度を除いて)通信を確保できるわけか。元々無指向性の比較的低い出力の衛星相手のシステムだから、ユーザ側に大型の端末がなくても通信できる。
あと、TDRSのSバンドは2.2GHzあたりのはずだから、多少のフィクション的な部分で2.45GHzを受信して、現地調達した電子レンジを改造して2.45GHz,500W,CWを放射すれば、いくら無指向・インコヒーレントとはいえ、TDRSのSMAからでも十分に見えるはず。ボーレートはめちゃくちゃ低いとしてもモールス符号で数ワードくらいは送れるから、フィクション世界ならいろいろ遊べそう。
しかし、Sバンドなのがちょっと不便ではある。普通のトランシーバはせいぜい数百MHzあたりまでしか出せないから、ちょっと厳しい。PRC-152でも500MHzあたりまでだし、117でも2GHzあたりまでで、わずかに及ばない。事前に準備して周波数コンバータを持っていくとかでもなければ、緊急に位置を知らせる必要が発生したときに電子レンジを改造して、くらいしか使い道がない。アクション作品だと創意工夫で頑張るみたいな状況で電子レジを使うのは便利そうではあるが。最近だと官民問わず通信衛星は大量に運用されているので、わざわざTDRSを使うならうまいこと設定を考えないといけない。
最近のC#、CollectionMarshal.AsSpanでList<T>をSpan<T>に持ってきたり、MemoryMarshal.Cast<byte, T>でbyte[]をSpan<T>に持ってきたりできるけど、Span<T>をReadOnlySpan<T>に変換するのが面倒でちょっと不便。
静的クラスでpublic static ReadOnlySpan<T> AsReadOnlySpan<T>(this Span<T> src) => src;みたいに定義すればいいんだけど、これくらいの機能は標準で用意してても良さそうなのになぁ。
もしかしたらSpan<T>とReadOnlySpan<T>って大して違いはないから区別する必要はない(積極的にReadOnlySpanに書き換える必要がない)みたいなことなんだろうか。メソッドに渡すときに、受け取ったSpanを書き換えないことを表明するためにReadOnlySpanを使う、みたいな用途とか。
0 件のコメント:
コメントを投稿