ロビンソン、お前もか…… いや、順当な方向だとは思うけど。
飛行制御はシコルスキーのシステムだそうで。ってことは、ガワが違うだけで中身(&管理システム)はU-Hawk(UH-60無人化バージョン)と同じってことになるのかな。米軍向けにU-Hawkを売り込んで、同じシステムが使える低コストのソリューションも一緒に売り込もう、みたいなことを考えてるんかしら。
シコルスキーの強み(他の無人輸送ドローンに無い点)は何十年も作り続けてきた機体がすでにあって、ロジスティクスも確立されているという点。大量生産のノウハウもあるし、製造ラインもある。機体を運用できる環境も熟知しているだろうし、やはり強そう。
理想的には腹が開いていて、高度5m程度の場所でホバリングしてウインチで荷物を積み下ろしできればいいんだろうけど、ロビンソンの床下は制御系が通っているし、無人化で追加したアクチュエータは床下に入っているだろうから、底面から荷物を出し入れできるような構造は難しいんだろうな。
ロビンソンはマストが長いから平均的な身長の人ならメインローターに巻き込まれる危険性は低いけど、テールローターに叩かれるような事態はあり得るし、災害時に支援物資を空輸するような用途を考えると、地上作業が必要な形はちょっと大変そうだが。ウインチで自動で荷物を下ろすような機能があると、緊急事態では下に人がいないか確認する程度の安全管理でも運用できるけど、荷物を下ろすための作業が多かったり、テールローターに巻き込まれる可能性があると、送り先に対応できる人間が必要になる。
あとは、軍の荷物の輸送とかを考えても、自動で荷物を下ろす機能があるなら、適当な広場に自動で着陸して直ちに荷物を下ろしてすぐ飛んで、みたいな運用ができるけど、人間が降ろさなきゃいけない場合は広場でそこそこの時間の作業を行う必要がある。迫撃砲とかで狙われると危ない。まあ、自動で荷物をおろしたって、その場所に照準して拾いに来たところを撃たれたら同じだけど。
ニデック不正会計問題 “カリスマ経営者”永守重信氏 いったい何が | NHKニュース | 企業・経営、東京証券取引所、京都府
小型高機能科学衛星「れいめい」の運用終了について | 宇宙科学研究所
人工衛星の帯電を「光」で検知するシリコンフォトニクスセンサを開発～宇宙開発を悩ませてきた静電気トラブルに新方式で挑む～ - 国立大学法人 岡山大学
電位に応じて透過率が変わるデバイス。人工衛星を想定したセンサの話だけど、電気の話なので、電位差の意味でΔVが出てくる。
細い光ファイバ2本を引き回せば好きな場所の電位(デバイスに含まれる電子の数)を測定できるのは、他のセンサ(電気信号を出すようなセンサ)に比べれば、引き回しは便利かもしれないけど、計測点ごとに光源と受光素子を用意しなきゃいけないので、光電変換が面倒そうだ。とはいえ、光源は1個を配分してもいいだろうし、受光は適当なイメージセンサとかに突っ込めばいいと考えれば、比較的小型に作れるのかな? あるいは、サブナノ秒の光源/光量センサがあれば、ファイバの長さを数十cmずつ変えて、ファイバ自身を遅延線として使って、計測点1箇所あたり1本のファイバで時分割測定ができそうだが。
光(ファイバ)の分岐や結合デバイスってどれくらい研究されているんだろうか? 現在の光通信は基本的に送受信機を1対1で接続して、多対多接続する場合でも基本的には周波数分割だから、一つの波長を均等に分けたり統合したり、みたいなデバイスはあんまりなさそうな気がする。フライ・バイ・ライトの黎明期にはこういうデバイスもいくつか研究していたような気がするけど、そもそもFBL自体それほど研究されていないからな。
あと、宇宙機内の光ファイバでアナログ量を通す使い方ってどれくらいされているんだろう? 放射線の影響でファイバの損失が大きくなると経年で信頼性が下がりそう。宇宙機内の光ファイバはデジタル通信とかが多そうだが。光ファイバジャイロだと干渉の強さを見るから、ファイバでの損失の影響も受けると考えれば、宇宙でアナログ光量を通すような使い方も実績はあるのかな? FOGは変化の少ないバイアスはSTTで吸収している可能性もあるけど。
ソニー、PlayStation独占作のPC移植を停止か その理由とは - CNET Japan
自社ハードを売るために独占タイトルの別ハードへの移植をやめた可能性、という話。
任天堂は昔から自社ハード専用でしか売ってないから別として、それ以外の勢力(具体的にはプレステ、Xbox、PC)がそれぞれ独占タイトルを売ると、不景気の時代には複数のハードを購入できる資金力のあるプレイヤーはあまり多くなくて、マルチプラットフォームタイトル+どれか1個のハードで遊べる独占タイトルを買うだけになって、独占タイトルを増やす方向は販売本数が減る方向になりそうな気がするけどな。
あるいは、複数ハードを買い揃えられる(ゲームに使う金額が大きい)層狙いでゲームハード・ソフト共に高価格化するか。その場合も加速度的に売上が減るポジティブフィードバックだと思うが。
あとは、独占タイトルを数年後に移植しても思ったほど売れない、というのは、最近はゲーム実況を見て、それで遊んだ気になって、わざわざ数年後にフルプライスで買おうと思わない、みたいな理由もある程度あるんじゃないだろうか。かといって配信禁止にすると、話題にならないから売れないし。配信時代だと、ストーリー重視のゲームは厳しそうよね。かといってゲーム性重視だとプレイヤーを選ぶし。集客力の強いストーリーなら配信で見ずに自分でプレイしたい、というユーザーを集められるんだろうけど、よほどのネームバリューがないと難しいだろうし。
任天堂は「任天堂」という超巨大IPがあるから独自のエコシステムが成立するけど、他のメーカーが後追いで独占タイトルに依存したハードの売り方をやるのはかなりハードな気がする。
ゲームが売れないというのは、「本が売れない」とか「音楽が売れない」とか、そういうのと同じで、コンテンツが多様化してそれぞれのパイが小さくなっているだけで(スマホゲーで満足する層も多いだろうからそことも食い合いになるし)、小手先の工夫程度じゃどうにもならなそう。最終的には汎用マシン(Windows or Linux)あるいはクラウドゲーミングに収束して、任天堂みたいな特殊な製品を除けばゲーム専用コンソールってのは将来的には無くなりそう。でも四半世紀も売り続けてきたブランドを捨てる判断は難しいだろうなぁ。プレステはやはりメーカーを背負うブランド力があるだろうし。
α(デジイチ)とかを認知するのはよほどカメラが好きな子供でなければ、大人でも知らない人のほうがほとんどだろうし、テレビメーカーなんて世界中にいくらでもあるけど、PlayStationのブランドは子供の頃から刷り込まれるし、たとえ自分や友だちが持っていなくても名前は知っているという人も多いだろうし、SONY製品としての知名度は抜群だろうからな。
いくら任天堂が強くたって、将来的に汎用計算機orクラウドゲーミングに収束した場合、わざわざ任天堂のハードに最適化させたゲームソフトを作ろうというインセンティブもなくなるから、そのうち任天堂のハードもなくなるんだろうか? それとも、任天堂の独占タイトルでハードを普及させている限りは、その普及台数を見込んで移植が続けられるんだろうか?
あるいは、最終的にはLinuxベースのOSを積んで、ARM/Linuxみたいな実行環境になる可能性もあるか。任天堂独占タイトルの実行はハードウェアベースのライセンス管理で他のシステムでは走らないようにしたうえで、他のシステムで走るゲームも実行可能、みたいな。
Intelがゲームハードを作ったらちょっと面白そうな気はするが。自社で半導体ファブを持っているし、CoreやArcみたいなプロセッサも自社で設計しているし。Steam Machineみたいに別の収入源が無いからゲームハードで稼ぐしかないのがちょっと辛いけど。既存のx86系PCと全く同じアーキテクチャだから、WindowsやLinuxを入れればゲーム以外にも、そこそこの計算リソースを持ったコンパクトな計算機としても売れる。計算能力が中途半端で売りづらそうだが。
クラウドゲーミングは、StarlinkとかLeoに計算機が乗った宇宙データセンターが作られると数百kmゼロホップで直結できるから、往復10ms未満で通信できて、手元にちょっと描画の早いモニタ(OLEDとか)があればほとんど相殺できる。それにゲームはプレイヤーに紐付いたデータがかなり小さいから、衛星のハンドオーバーでのオーバーヘッドもほとんど無い。と考えると、宇宙データセンターを使ったクラウドゲーミングはかなり優位性が高い。あまりにユーザー密度が高いと計算能力が不足するので、1衛星あたりのユーザー数の少ない過疎地域ほど宇宙ゲームセンターとの相性がいいということになる(逆に人口密度がバカ高いエリアは直近の地上DCで計算するほうが色々と楽)。
そういう時代になると、世界中のどんな隔絶した場所にいても、空が見えている限り、STBにアンテナと適当な画面、それとゲームパッド(orキーマウ)を接続すれば、映像デコーダだけが乗っている程度のチープな機材で最新のゲームが遊べるようになる。そういう環境の人からどうやってサービス料を徴収するかは別にしても、「ネット環境が弱いからゲームを遊ぶにはゲーミングPC(orコンソール)を買う必要がある」という状況ではなくなる。
都心部なら地元のデータセンターで、地元にデータセンターがなくても宇宙DCで、クラウドゲーミングが遊べる時代になると、任天堂みたいに自社IP専用ハードを売るモデルはどうなるのか。衛星通信の性能にもよるけど、スマホを直結して高速通信ができる、みたいな話が本当なら、スマホ単体で高品質なゲームが遊べる時代に、手元でレンダリングしなきゃいけない携帯ゲームコンソールは重いだけで画質は悪いし電池の持ちも悪いしと不評になりそう。
*
英語圏の人のFH6のリアクション動画で時々「バックファイア」というのが出てくるけど、ja.wikipediaだとエキゾーストから出てくるのは「アフターファイア(内燃機関で燃焼室の後(after)に出てくる炎)」であって、バックファイアは燃焼室の前(back、系を戻る)で起きる異常燃焼のことである、みたいなニュアンスの説明が書いてある。でも英語圏の車にそこそこうるさいであろう人が何人もエキゾーストから出る炎を「バックファイア」と言っているということは、やはり車の後ろから出る炎はバックファイアで良いんだろうか?
en.wikipediaを読む限り、エキゾーストパイプで燃えるのがバックファイア(backfire)あるいはアフターバーン(afterburn)、吸気側で燃えるのがアフターファイア(afterfire)あるいはポップバック(popback)、という感じっぽい? 前も後ろもどっちもbackあるいはafterがあるの曖昧すぎるだろ。
ただ、燃焼室の前後どちらでも鋭い音がして、俗にバックファイアと呼ばれるが、エンジンメカニックによるトラブルシューティングでは、排気システムではバックファイア、吸気システムではポップバック、とより厳密(more strictly)に定義している、と書いてある。
ja.wikipediaに書いてあるのはen.wikipediaに書いてあることと完全に逆だな。
日本語の資料だと、バックファイアという用語は明らかに吸気系での異常燃焼を指して使っている。車(自動車)の分野だけでなく、それ以外のエンジン機器、例えば芝刈り機とかプレジャーボートでも同様で、JTSBのレシプロ機のエンジンに由来する事故の報告書でも、注釈で「「バックファイア」とは、(中略)、吸気管内の混合気に着火し、その炎が吸気系統まで逆に伝わることをいう」と書かれている資料がある。
日本語と英語で全く同じワードなのに意味が真逆になっているんだな。
*
ロケットの新規開発って、模試無し滑り止め無しの一発受験、天候不良や機材トラブルがあれば数日順延、失敗したら来年再挑戦、みたいな感じなのがねぇ。特に日本の民間開発は観光需要まで含めて予算調達しているから、その方面に迷惑をかけないように、できるだけ期日通りに打上げたいみたいなプレッシャーもあるし。
あらかじめ模試みたいな感じで、例えば第1段だけ作って上段はダミーウエイトを積むとか、あるいは第1段を省略して第2段を地上から打つとか、そういう感じでいくつかに分けて開発する手順だってあるはずだけど、でもその場合はそのロケットは絶対に宇宙(周回軌道)までは行かないわけだから、観光需要が取り込めなくなる。そうすると観光需要に当て込んだ地元からの投資が得られなくなる。MOMOだって集客できてるんだから、サブオービタルだってある程度の観光需要はあるんだろうけど。
要素毎の試験を飛ばしていきなり本物の衛星を積んで打上げると、あとはまあ言わずもがな。SpaceXだって同じだろと言われるとぐうの音も出ないが。
ある程度の資金力があって、すぐに事業化する必要のないところ、具体的にはホンダとかのあたりは着実に一歩一歩やっているんだろうけど、そういうところは基本的に情報は出てこないからあまり話題にはならず。
あとは、某社に関して言えば、頑なに失敗を認めない企業文化がちょっと違和感あるなー。言葉狩りに近いやり方は危うさを感じる。社内の誰かが怪しい点を発見して「これは失敗に繋がる可能性があるから細かく確認したほうがいいかもしれない」と思ったときに、社長が「失敗という言葉は使うな!」と訓示していると、言い出せなかったり、とか。社内の雰囲気は外からはうかがい知れないから、実際はどうかわからないけど。
あと、初めてだから安全寄りに、という判断はわからないでもないけど、でもそれでフルスケール機(実機)を何度も落とすくらいなら、むしろペイロードは多少減らしてでも追加の保安系機材で厳重に管理したうえで、オンボードの保安ロジックはルーズに設定して、in flightのデータを確実に取得しつつ試験機の実際の保安系は地上からコマンドする、みたいなコンフィグでやったほうが、実績を積むという点では良かった気がする。そういうコンフィグなら少なくとも1号機や3号機はもっと先までシーケンスが進んでいただろうし。オンボードロジックの誤判断で第1段燃焼中に2回も落としたとなると、次もそのロジックの微修正で打つのか、あるいは根本的に違う方向に行くのか。
でも、日本の民間企業が使える機材で、コマンドベース(非自立型)の保安系を作るとなると、大変なんだろうな。射点から見える範囲ならJAXAの可搬機材をいくつか借りればシステムとしては組めるだろうけど、地平線を超えたところをカバーできる、海上or空中の通信システムはあまり思いつかない。
DRTSみたいな衛星があれば、適当な場所に衛星と直結できる地上局を作ってロケットの保安に使うこともできるだろうけど、JDRSでロケットの追尾は厳しいだろうし。種子島や内之浦の敷地を借りてそこから打てば地上RF系はそのまま丸ごと借りて使えるけど、でも和歌山から打つと大々的に謳っている以上はそういう事もできないだろうし。
結果論だけど、JAXAがTDRSみたいにロケットの追尾もできる中継衛星の保有を続けていて、かつ射点設備も既存の設備を民間に貸し出すようなスキームを用意しておけば、もっと楽に民間ロケットの開発が進んでいたんだろうな。種子島空港は南東向きで人口密集池の上空を通らずに比較的すぐに海に出るような場所にあるから、飛行機形態で離陸する機体の試験もできるだろうし。ロケットを追尾できる中継衛星はJAXAだって持ってれば便利だろうに。打上げ用の重要設備が手が届かない場所にあるのは怖いけど。
***
重い腰を上げて、AirspyでIFF Mark Xを受信/解析するソフトを作成中。とりあえずキャリアスケルチだけ実装して、信号をWAVファイルに保存。
ファイルフォーマットとしては、通常の32bitWAV形式で、dataチャンクの中にさらにサブチャンクを追加する形にしている。たとえばdateチャンクでタイムスタンプを保存し、waveチャンクで実際の波形を保存する、といった形。
IQ信号は16bitなので4byte/サンプル、dateチャンクの中身を4バイトアライメントで保存すれば、サブチャンクのヘッダがゴミに見えるけど、通常のWAVファイルを取り扱うソフトで開くことができる。
現状はdateとwaveしか保存していないけど、例えばiffxとかjsonみたいなチャンクに解析結果を保存しておけば、後でファイルを開くときにいちいち再解析しなくても済む。ファイルサイズが増えるのと、それほど複雑な信号じゃないからファイルを開いたときに(必要に応じてパラメータを変更しつつ)再解析するほうが便利じゃねって可能性もあるけど。
スケルチは2段階のレベルを設定して、H1を超えた場合はT1遡って最初にH2に達した場所からT2遡った場所から記録を開始し、一定期間(T3)の間H2を超えなかった場合は、最後にH2を超えた場所からT4経った場所で記録を終了する。
WAVファイルのwaveチャンクから振幅をグラフ化
縦軸が振幅、横軸は時間(マイクロ秒)。補助目盛線は、上のふたつが1.45us、下は2us。
上段は1723でモードCに割当がないのでモード3/A応答。
中段は3410でモードCに割当があるのでFL153の可能性。
下段は恐らくモードS応答。全体の長さがプリアンブル(8us)+56bit(56us)=64usと整合的。
当該の時刻をFr24で確認すると、モード3/A応答は値が確認できる。高度についてはBARO.ALT.で比較的近い値が得られている(上昇フェーズなので多少の時刻差で大きく高度が変わる)。モードSはドキュメントが少なくてデコードが難しい。
試しにRasPiの30002ポート(dump1090の生ビット列)と同時に保存したIQファイルを読んで、モードSらしい波形を目視でデコードし、30002を保存したファイルでテキスト検索すると、そのビット列が見つかる。ということで、少なくともIQ信号から生ビット列へ変換するのはできそう。10Msps(ビットレート*10、ボーレート*5)なので、マンチェスタ符号の復号もそう面倒ではないはず。
現在走らせているRTLベースのロガーは、一定の信号強度を検出したらその前後の固定長を保存するだけのもので、12bit応答にSPI分の余裕を見た長さに設定しているから、Mode-S系の信号が入ると正しく保存できない問題があった。RTLの2.76Mspsの場合はMode-Sの復調はできないので実質的に問題はないんだけど、Airspyの10MspsではMode-Sも復調できるから、その信号は正しく保存する必要がある。というかMode-Sを適切に復調したいからAirspyを買ったまであるので、保存できないと本末転倒。
RTLは2.76MspsIQ8bitで、1日辺り300MB前後の容量になる。Airspyは10MspsIQ16bitで、単純計算で7倍のデータ量になるので、1日あたり2GBを超える可能性がある。1年と少しで1TBですよ…… まあ、そのあたりの心配は追々。
IFFにはローマ数字でMark IIやMark IVとするものと、experimentalを意味するMark Xや、それの発展型のMark XIIAのように、いろいろな種類がある。Mark XIIA(マーク・エックス・ツー・エー)は「実験用の2つ目の発展型」というようなニュアンスだけど、たまにIFF Mark 12Aというような書き方がされることもある。
SDR#のベースバンド信号をWAV(32bit)に保存する機能、ファイルサイズが4GiBを超えると自動的に分割されるけど、このときにどうやら最後の1バイトが捨てられているらしい(最大ファイルサイズが2^32-1バイト)。残りの1バイトが次のファイルに引き継がれる、みたいな実装ではない(次のファイルにもWAVヘッダが付いてるんだから当たり前か)。WAVはリトルエンディアンなので、最後の1バイトが捨てられると、例えばゼロ埋めで戻すとかなり大きな誤差が発生することになる。
C#でif (_hoge is Hoge hoge){}はブロックの外でhogeに触れるのに、while(_hoge is Hoge hoge){}はブロック外でhogeに触れないの、地味に不便。例えばwhile(_hoge is not Hoge hoge){await Task.Delay(10);}みたいに待ち合わせしようとするとHoge?hoge;while((hoge=_hoge)is null){await Task.Delay(10);}みたいにしなきゃいけない。
0 件のコメント:
コメントを投稿