2段式水ロケットの高度記録。コールドガスジェットの低比推力に由来する超高加速度。7MPa(1000PSI)だってよ。ペットボトルロケットの10倍くらい。
SLAの3Dプリンタで小型の燃焼室を作成。ロケットエンジンのイグナイタに使う燃焼器の想定。FDMのような熱可塑性樹脂を使うわけではないので、耐熱性の高い樹脂を使える。短時間(数秒程度)の燃焼試験なら問題なく使えるし、透明な樹脂を使えば燃焼の様子も外から見えるから便利だよ、とのこと。
ブルーオリジンのニューグレン(エンジンを除いた機体部分)を作っている工場。
CNCエリア、いろんなメーカーのマシニングセンタとかターニングセンタが混在していてすごい。どういう基準で選んでるんだろう。これだけメーカーがバラバラだとプログラミング作業は方言だらけで大変じゃなかろうか。Mastercamを使えば工作機械メーカーの違いは気にせず使えるよ、みたいなことなんだろうか。/* ハンツビルのエンジン工場もマシニングセンタはいろいろなメーカーの製品が導入されているけど、とはいえ圧倒的にDMGが多い印象 */
ガスジェネレータからのガスを同軸反転のタービンで2つの回転エネルギーに変換するのは、ジェットエンジン(除ターボジェットエンジン)でよく見るような気がするわね。Hill GT50(ターボシャフトエンジン)みたいな小型のやつだとコンプレッサー駆動用の高圧タービン1段とシャフト出力用の低圧タービン1段を並べて反転させるような構造。ホンダジェットのHF120(ターボファンエンジン)も同様(高圧1段、低圧2段)の構造で、逆回転させることで高効率化を行ったと説明している。PT6(ターボプロップエンジン)も同様に高圧タービンと低圧タービンが逆回転(PT6はコンフィグによって高圧・低圧タービンの段数にいくつかの種類がある)。もっと大きなエンジンだとタービン段数が増えるから逆回転で得られる効率は相対的に低下しそうだけど、とはいえGNex(B787とかに積んでるやつ)でも逆回転させて効率化させたと説明しているから、ある程度は効果があるんだろうし。GNexでも売り文句として書くくらいには意味があるとしても、PT6(1960年代前半から量産開始)で使ってる程度には、2段のタービンを逆回転させるのは昔からある方式(当時から逆回転だったのか、途中で逆回転になったのかまでは確認していないけど)。よそで使っている効率化技術をうまく適用したという点では新しいとしても。
某動画サイト、今の時代にPIP再生できなかったやつ、フルスクラッチで作り直したおかげでPIP再生できるようになって便利になったな。連続再生すると2個目以降はブラウザで再生されるとか、広告が出ているときにPIPを起動するとPIPに広告が残ってメインの動画がブラウザで再生されるとか、まだちょっとアホの子仕様だけど。ブラウザサイズで最大化する機能って削除されたのかな? この機能好きだったのに。/* 久しぶりにマイリス覗いてみると昔の自分って楽しめるコンテンツの許容範囲広かったんだなーって実感して落ち込む */
4月か5月あたりに3ヶ月分支払ってるはずなんだけど、一般会員扱いになってる。その後に催促のメールも来てないから払い忘れで自動解約とかではないはずなんだけど。登録ページは未実装だから、プレミアム会員周り全体が未実装なのかな。惰性で払い続けてただけだし、この際だから一般会員に戻しても……とは思いつつ、たまにマイリスを連続再生とかしようとすると合間に挟まる広告がウザいのよなぁ。
Fr24で家の周りを飛んでいるヘリコプターの一部が表示されるようになったんだけど、一般的な旅客機等に比べて表示される情報がかなり少なくて、緯度経度と高度周り、対地速度、くらいしか表示されない。スコークとかも無し。ADS-BでなくMLATが表示されてるんだろうか? MLATにしろスコーク(モードA)は得ているはずだから、スコークスすら表示されないってことはまた別の情報源なのかもしれないけど。こんなクソ田舎にMLATを構築できるほど受信局があるとも思えないしなぁ。1090MHzのブロードキャストをデコードせず、単に広帯域信号源としてだけ見るならスコークは得られずLatLngAltGSあたりが表示されるのは辻褄が合うけど、とはいえFr24のデコーダにそういう機能は乗ってないはず…… いや、どんなアルゴリズムで処理してるのかわからないので実は乗ってるのかもしれないけど。
ロケットの打上でFr24にフィードされた例ってあるんだろうか? ロケットに1090MHzビーコン(orトランスポンダ)を乗せる実用的な意味は無い(NOTAMで飛行機が接近しない、対空レーダで監視されている)けど、1090MHz以外の他のルート経由でフィードしたりしないんだろうか。これだけ空飛ぶものを(トナカイとかまで)表示するFr24だし、ロケットとかも表示しても面白そう。Starshipの旅客輸送とかはFr24で見れるようになったりするんだろうか。
ちょろっと気になったのでSELENE後続ミッションの話題をググってみたんだけど、SELENE-2, SELENE-3, SELENE-X, SELENE-B, SELENE-R, SELENE-RP, etc...いろいろ出てくるな(これに並行してSLIM等が提案されている)。大量に検討だけぶち上げた挙げ句、一個も実現しなかったんだな。。。当時の計画では2で中緯度への着陸とその場観測、3で極地への着陸とサンプルリターン、その後(X)で月裏面への着陸とサンプルリターン、等が提案されていたみたい。20年くらい放置してる間にいろいろ中国が実現しちゃった感じだなぁ。
SELENE-RPはNASAのResource Prospectorローバーを日本の巡航モジュール・着陸機に乗せてFalcon 9で打とう、みたいな案。Resource Prospectorはen.wikipediaにも記事があるけど、’18年にキャンセルされたとのこと。ちなみにこの記事には日本との関係は一切書かれていないから、SELENE-RPは日本側が勝手に言ってただけかな。
何日か前に、夜中(23時頃)に夜空で変な発光現象を見かけた。かなりゆっくりと動きながら数秒に1回程度ピカッと光るけど、移動速度はかなり遅くて、飛行機や衛星という感じではなさそう。その時刻をFr24で見ても何も飛んでいない。
大体の方向をスマホで撮影しておいたので、その画像の時刻と方向に衛星の軌道を重ねてみた。
写真に写った星の位置で姿勢を合わせている。方位角315度、仰角56度、りゅう座の首元あたりが画像の中心。とりあえず10分程度の軌道を表示。すでに消滅済みの(弾道係数の大きい)衛星もカタログに残っているから、明らかに不自然なパスもいくつかあるけど、それらは無視するとして。
最初は打上げ直後のコンステレーションが連続してフレアしたフラッシュに見えているのかな、と思っていたけど、それっぽいパスはなさそう。結局正体は不明という結論(軽く眺めただけなので、もう少し詳しく探せば見つかるかもしれないけど)。
Pixel 6aの夜景モード、おそらく大量の画像(or動画データ)を重ねて中央値を取ってノイズを減らすようなアルゴリズムだと思うんだけど、肉眼で見えるような明るい物体でも、衛星みたいに背景に対して速度の大きい物体はノイズとして消されてしまうし、もちろんフラッシュみたいな単発的な発光も消えてしまうので、「UFO(を後で同定するため)の記録」みたいな用途には使えないんだよなー。タイムスタンプ、観測位置、姿勢の目安は手軽に記録できるけど、衛星を同定するうえで重要な運動方向が記録できないのがつらい。なんとも不便なことよ。こうしてアルゴリズムが発達するとUFOの写真とかも減っていくんだろうか。あるいは「肉眼では見えるのに写真には映らない」という怪物体として口伝で広まるんだろうか。◯◯◯(3文字の任意の政府機関)が開発したカメラに写らなくするステルス飛行物体の技術だ!!とか。あるいは、政府の偵察衛星が写真に写らないようにGoogleに圧力をかけてカメラアプリに細工をさせているのだ、みたいな陰謀論も作れる。
Microsoft製のリモートデスクトップアプリをスマホに入れてみたけど、結構便利。画面サイズ的に小さい文字とかを読むのが大変だけど、とはいえゲームみたいに動く画面じゃないし、画素数はFHD以上あるから、ちょっとしたUIの操作程度であれば特に問題はない(デフォルトだと低解像度をスケーリングして表示するので表示領域がかなり狭いけど)。不満な点を挙げるとすれば、トラックパッドモードのときにマウスカーソルが慣性を持つのが使いづらい。
WiFiモジュールを積んでいるマシンであればPC自身でアクセスポイントを立てることができるので、ネットワーク環境がない場所(屋外とか)でもNUC等とスマホを接続できる(WiFi運用のスマホだとインターネット接続がなくなるけど)。ただ、PC側で立てたAPはなにかの拍子にOFFになるらしく(自動OFFを無効にしてもそうなる)、完全にネットワークがない場所で使うには難がある(再現性が悪くて、しばらく放置していてもAPが立ったままの場合もある。油断できない)。Type-Cの有線LANアダプタとかを持ち歩いておけば最初にAP立てるときに使うなり、常時有線でリモートデスクトップするなりできるはず。NUCを野外で使おうとするとモバイルディスプレイとかキーボード・マウス類が必要になるから、Type-Cのアダプタ1個で簡易的に操作できればいろいろ便利そう。
NUCでSDR受信機みたいな構成
NUCをモバイルバッテリーで駆動して、ドングルを3本接続、rtl_tcpを起動。2時間程度は持ちそう。rtl_tcpしか走らせてないから、SSDへの書き込みも含めたらもっと悪化するかもしれないけど。5Ah7.2Vの電池で3h持つなら消費電力は12W程度(15Vのはずなので出力は0.8A程度)。N100ならそんなものだろう。
***
せっかくスマホを買ったんだし、せっかく3Dプリンタを持ってるんだから、この際だしスマホケースを自作してみた
チャチャッとノギスで適当に測って作った割にはきれいにフィットしている。カメラの高さが1.0mmくらいなので、ケースの厚さを1.5mmにして、カメラが机に当たらないような感じに(机にベタ置きしたときに水平になるように)している。表側はスマホの表面とツライチなので、裏向きに置くと机と画面が接する。適当な箇所に突起を配置しておけば(平面に置く限りは)画面と机が接触しなくなるので、次に作る機会があればそれもやってみよう。
スキンが浮いてるのでサポートを入れてもあんまり綺麗に造形できないのよなー。なぜかフィラメントの向きも乱雑になるし。まあ、「そういうデザイン」と言い張ることもできる。これはこれでアリ。
厚さが16%以上増えるので持ってもなんとなく厚くなった感じがわかるけど、でも裏面のパターンはスマホを持つうえで結構快適。リブの高さは1mm程度だけど、ちゃんと滑り止めとして効果がある。平らだと滑ったかどうか触覚でわからないから安全側に持とうとしてつい必要以上に力を入れて持つけど、裏面に適当な凹凸があれば滑っていないことが触覚でわかるから、あまり力を入れずに持てる。
理想を言えばキックスタンドが欲しいところだけど、背面はフラットにしたいので、厚さ的にかなり厳しい。キックスタンドの強度もそうだし、ヒンジの構造もそうだし。側面(ボタンの下辺り)を膨らませて、そこにヒンジを入れるみたいな構造も考えられるけど、ケースの構造には少なくとも1mmくらいは割り当てたいから、キックスタンドの厚さを3mmとしても全体で5mm近くの厚さになってしまう。スマホ本体の厚さが9mmだから、厚さが56%増えるのはさすがに許容できない。
横のボタンは切り欠きでむき出しにしている。Kindleとかが音量ボタンでページめくりができたりするけど、Pixel 6aのボタンは結構硬いので、あまり操作性が良くない。ということで、ボタンの表面積を増やすような構造があれば操作しやすくなるかな、と思ったり。音量下げ(Kindleで次のページ)だけでも軽く押せるようになれば使いやすくなりそう。標準カメラアプリも音量ボタンでシャッター操作ができるから、シャッター時の手ブレ対策にもなるし。あまり音量ボタンの操作回数が増えすぎても劣化するだけだと考えると、そう頻繁に使うのも怖いけど。
スマートフォンの音量ボタン、iOSもAndroidもカメラのシャッターとして使えるけど、iPhoneは左側の上の方にボタンがあるから底辺を左側にして持つと右手の人差し指で操作できて、普通のカメラの操作感と同じ。一方でAndroidの音量ボタンは右側にあるから、右手の親指で押すか左手の人差し指で押すか、いずれにしろ普通のカメラとだいぶ操作感が異なる。
音量ボタンでシャッター操作、Bluetoothイヤホンとかの音量操作でも行うことができれば三脚においたスマホをリモートでシャッター切れたりして便利そうだけど、少なくともPixel 6aとEcho Buds2の組み合わせだとそういう操作はできない。Bluetoothの場合は直接DAC(or PGA)へコマンドを送って、その結果を本体側に通知するみたいな挙動なんだろうけど。昔の(3.5mmジャックが付いていた頃の)iPhoneってイヤホンをカメラのレリーズ代わりに使えたから、シャッター機能の無い自撮り棒でも普通に撮影できてたけど、最近のiPhoneってそういう操作はどうなってるんだろうか。素直にセルフタイマーなり使えって話か。
今どきのロケットはアイソグリッドなんて使わねーよ、とは思いつつ、デザインとしてはオルソグリッドよりアイソグリッドのほうがカッコいいんだよなー。圧力容器に使うならノード中央の穴は非貫通穴にするべきだけど、スマホケースとかに使うのであれば貫通穴にして本体の色をアクセントに使うといい感じになる。オルソグリッドだとノードが小さいので穴を開けられない。
最近のロケット、ヴァルカンとかニューグレンはタンクにオルソグリッドを使っているけど、H3はアイソグリッドなのかな? ジェフ・ベゾス曰く「アイソグリッドは板材を曲げてから5軸加工機で切削する必要があるので加工が大変。オルソグリッドなら3軸機で切削してから曲げられるからコスト的に有利」だそう。とはいえ、H-IIAの製造中という写真ではアイソグリッドを3軸機で(もちろん平面の状態で)削っているから、必ずしも5軸機で削る必要はないんだろうけど(一旦埋め戻して曲げてから洗浄して、みたいな手順でコストがかかるみたいな方向性はありそうだけど)。
なお、ファルコン9はアイソグリッドとかオルソグリッドは使わず、ストリンガをFSWで溶接してるらしいね。「9割以上も削るのはアホらしい」みたいな理由らしい。もっとも、この話は10年前のフォーラムに書いてあった話なので、最近の機体が同じ設計思想なのかはわからないけど。当時は製造コストの低いストリンガ溶接が有利かもしれないけど、何十回も再使用するブロック5等では多少の製造コストをかけても溶接を避けたい、みたいな方向性もあるかもしれないし。
/* 今どきのロケットは～というのは、あくまでも燃料タンクの円筒部のような面積比で最も大きい場所でアイソグリッドを使うロケットが減った、という意味で、オルソグリッドを採用したロケットでも、例えば鏡板の補強のためにアイソグリッドに似た構造を使う例はある。ただし同心円状に三角形を配置した場合は二等辺三角形的な形状になるので完全なアイソ(等方的)グリッドではないけど */
***
Androidの印刷機能の謎挙動
左から、オリジナルの画像、A4で印刷するときのプレビュー、A6で印刷するときのプレビュー、A6(モノクロ)で印刷するときのプレビュー(斜めに撮ったほうが見やすかったな。。。)。カラーで明らかに色合いが違うじゃねーかよ、みたいなツッコミは置いておくとして。よく見るとA4カラーの1-6の文字が潰れていて、A6(カラー)だと1-1も潰れているし、全体的にジャギーになっている(下のUSAFの字が顕著)。他の写真でも同様で、Androidのカメラで撮影した写真は印刷しようとするとジャギーになる。ただ、モノクロの場合はジャギーにはならず、A6のプレビューでもA4より解像度が高い(A4では潰れている1-6の文字も、A6モノクロでは問題なく読める)。
左から、A4、L版、L版(モノクロ)。風景写真とかも印刷しようとすると潰れるし、印刷してもちゃんとジャギーに印刷される。L版で印刷するとだいたい0.5mm/pixくらいの解像度になっている感じ。
左から、ローカルに保存したテストチャート、OneDriveアプリで撮影した画像、Android標準カメラで撮影した画像をPC(Paint.Net)で読み込んでそのまま上書き保存した画像、Android標準カメラで撮影した画像を「フォト」アプリで編集した後ローカルに保存した画像。いずれも問題なくプレビューできている。
以上の結果から
1) Android標準カメラで撮影した写真をカラーで印刷するとジャギーが発生する
2) 標準カメラ以外で撮影した画像は問題ない
3) 標準カメラで撮影した画像でも、編集して保存した場合、その画像は印刷に問題はない(ただし一切の編集なしに別名保存はできないから、例えば明るさを1%変えるとか、何らかの破壊操作が必要)
という結果。
ジャギーになる画像か否かの判断は、PDFでA10に対してプレビューすると解像度が非常に低くなるので確認しやすい。
編集して開き直すのが手間だけど、とりあえずAndroid(Pixel 6a、AP2A.240805.005.F1)で撮影した写真を直接印刷する方法は把握できた。いちいちPCに取り込んで印刷しなきゃだめかと思ってたので、それに比べればかなり手軽に印刷できる。撮った写真を印刷する機会なんて年に何回あるかわからないけど、「印刷できない」と「印刷できるけどしない」では全く違うからな。
しかしこんなバグがどこから入ったんだろう&なんで放置されてるんだろう。スマホで撮影した写真をわざわざ印刷する人なんていないよ、みたいなことなんだろうか。そんなことないと思うけどなぁ…… 標準カメラという条件を加えるとだいぶ減りそうか。あと、写真を撮って印刷する人はバグレポートを出す人と重ならないという理由もありそう?
***
.NET MAUIで画像をAssemblyのGetManifestResourceStreamで取り出す方法がわからなくてめちゃくちゃ悩んだ。結局、画像ファイルのプロパティからビルドアクションに埋め込みリソースを設定してやる必要があった。デフォルトではMauiImageで、この場合はおそらくファイル形式とか解像度をいい感じに調整して、MAUI専用(例えばImageコントロールに使える)として埋め込んでいるっぽい(例えばSVGファイルを与えてやれば、ターゲットデバイスに合わせて適当な解像度のPNGファイルに変換して埋め込んでくれる)。
GetManifestResourceStream("ProjectName.Resources.Images.hoge.png")でStreamが得られるので、あとはPlatformImage.FromStreamに渡してやればIImageが得られるから、ICanvasのDrawImageで書き込める。
ICanvasのConcatenateTransformが変な挙動な気がする。特に平行移動のX/Yが入れ替わっているような感じがするのが謎い。あと、内部の行列が取得できないので、UIを作るときに困る気がする(というか、いいやり方が見つからずに困っている)。
とりあえず、並行移動+正方形の(XとYの倍率が同じ)スケーリングであればICanvas.Translate(mtx.M31,mtx.M32);ICanvas.Scale(mtx.M11,mtx.M22);みたいな感じで渡せる。回転が入ると面倒なことになりそう。Atan2(mtx.M21,mtx.M11)で回転角が取れるから、Translateの後にICanvas.Rotate(rad/float.Pi*180);var mtx2=mtx*Matrix3x2.CreateRotation(rad);ICanvas.Scale(mtx2.M11,mtx2.M22);みたいな感じでスケーリングを設定できるはず。剪断が入ると厳しそうだけど、そもそもICanvasには剪断を受け取るようなメソッドは見当たらないから、個別には与えられないはず。
移動とか拡大の行列の積はそう複雑なものでもないけど、回転が入ると結構面倒な感じ。具体的には回転中心の設定とか。数学的に考えれば自明なんだろうけども。結局、移動・スケール・回転は個別に処理したほうが便利のような気がしないでもない。ICanvasには個別に渡す必要があるわけだし。
PinchGestureRecognizerとPanGestureRecognizerを組み合わせて使うと、Pinch入力のあとにPanが誤入力されることがあるような気がする。通常、PanはStartedとCompletedの間にRunningが入って、RunningにPanのペイロードが入るけど、Pinchの直後の誤入力の場合はStartedがなくていきなりRunningが来るので、StartedとCompletedでフラグをON/OFFさせて、フラグを見てからRunningの処理を行えば問題なさそう。とはいえ、手間がかかる。
ダブルタップで2回目に離さずに上下にスワイプするとPinch入力がされるのはMAUIの仕様なのかな? 少なくとも他の(非MAUIであろう)アプリでは、そういう挙動は無い。ピンチの中心点をしっかり入力できて便利ではあるけど、感度が高すぎて使いづらい。低い確率で、ダブルタップしたときに負数が入ることがある(普通、倍率は正数しかとらない)。行列のスケーリングに適当な係数をかけて丸投げすると上下左右が反転するので困る。負数なら無視するみたいなロジックで解決できるけど。
MAUIでPinchGestureRecognizerを設定している領域が狭い場合(特に上下が狭い場合)、Pinch入力がすごい不自然な気がする。ひっかかるというか、なんというか。
MAUIはC#で書けるのは便利だけど、とはいえいろいろ不便なんだよなー。特にWindows Formを使っていた場合GUI周りは全く互換性が無い。GUI周りだけ学習し直せばいい代わりにあちこち不自然な挙動のあるMAUIか、開発環境を新しく入れて言語から学習する必要がある代わりにおそらく一通りのバグフィックスが済んでいるであろうJava/Kotlinか。悩ましい。
C#のGraphics.DrawImageがパフォーマンスでなくて悩むなど。
DrawImageのマルチスレッドパフォーマンス: TiltCorrector
DrawImageはマルチスレッドに非対応で、Graphicsの個別のインスタンスに対しても、1プロセスあたり同時に1スレッドでしか走らない、みたいなことらしい。なぜに……
C#でメソッドを他のプロセスで走らせる(Taskのプロセスを分離するようなイメージ?)って、ググってもやり方が出てこない。できても良さそうなのにな。どうしても必要なら、必要な処理を別のコンソールプログラムとかで作って、同じディレクトリにおいておくなり、埋め込みリソースを一時フォルダに展開するなりして、Process.Startで読んでIPCでデータ渡して、とかやればいいんだろうけど、かなり冗長な感じ。
試しにCSharpScriptingを使ってみたけど、これはスクリプトも親と同じプロセスで走るっぽい。あと、Createで作ったスクリプトのインスタンスは、並列でRunAsyncできないっぽい。
PreviSat、しばらく使ってなかったけど、いろいろ機能増えてるような気がする。忘れてるだけかもしれないけど。
SGP4でTLEを計算した結果とPreviSatの結果が合わないの、なんのことはない、WGS72を使えと指示されたとおりにWGS72を使えばいいだけの話だった。WGS72とWGS84って地球楕円体の大きさだけ見ると小さな差だけど、SGP4の計算に使うとkmオーダーに迫る程度にはズレる。
WGS72で計算すると、PreviSatとの計算結果とECI, ECEF共に最終桁(1m)まで一致する。緯度経度や方位仰角に関しても、Wikipediaの計算式を参考に求めたもので最終桁(1秒角)まで一致する。ECEFは地球姿勢(グリニッジ恒星時)の計算も入ってくるけど、一致しているということはPreviSatでも同様の計算を行っているんだろう。ECI/ECEF計算に使用する時刻を1秒ずらすと数百m程度(衛星の高度や緯度に依存)の差が出るから、閏秒とかΔUT1とかは特に気にしなくても良いのかな? 太陽時と原子時計の差を一定以内に維持するのが閏秒の目的なんだから、閏秒を適用したUTCを使えばいい感じの結果が得られる、ってことだろうか。
PreviSatのECEF速度がECI速度の単純な座標回転じゃないの、ECEFの速度には地球回転分(座標系回転分)の速度が乗っているからということらしい。ECEF XY平面の距離に応じた速度を加算してやれば、PreviSatのECEF速度とほぼ同じ結果になる。角速度の定数を2π/86164(=7.29212351699037e-5rad/sec)で計算するとPreviSatと最終桁まで一致する感じ。地球の角速度の定数って7.2921150e-5rad/sを使ってそうな感じがあるけど、まあ、地上から電波観測する程度ならmm/s程度の誤差なんて関係ないし、使いたいものを使えばよかろう。
0 件のコメント:
コメントを投稿