// 数日分書き溜めたら思いの外長くなった
Vixenの赤道儀って衛星も追尾できるんね。望遠鏡載せて恒星追尾できるんだからUHFのヤギくらいなら載せれそう。
ただ、衛星を追尾するだけなら赤道儀を採用する利点は無いんだよなぁ。経緯台で十分。
NICTの地上局だったか、特殊なやつだと最終段の軸を衛星の公転面に直立させて、軸を回して追尾する方式があるけど、この方式だと4軸くらい必要そうな気がする。追尾能力や安定性は高そうだけど、トータルでのコスパは悪そうな感じ。それに地べたに張り付いている以上は軌道面に平行な固定面を作ることは不可能だし、結局複数軸を同時に制御するなら、経緯台で良さそう。
CNCのロータリーテーブルを追尾用に転用できないかなーと思ったけど、追加2軸で安いやつでも200万くらいするのね(+ドライバが必要)。防塵防滴高精度高耐久やべぇ。クッソ高いぞ。。。
中華CNCのオプションとしてのロータリーテーブルは、ないわけじゃないけど、さほど選択肢は多くない。そもそもこの種のCNCはZストロークが狭いからロータリー入れれるほど動かないだろうし。
DIY向けの追加軸もクラウドファウンディングとかで出てるらしいけど、今の所5軸に対応したCAMが少ない(ライセンス料が高い)ので、そのあたりが課題になりそう。Autodeskが「ウチのCAM、同時5軸も無料で使い放題でっせ！！」とか言い始めたら急激に普及しそうな感もあるが。
***
2010年代前半にISS放出されたとあるキューブサットの報告書を読んでる。長い。。。
400km前後の衛星は運用終了時期が明確なので報告書は書きやすいかも。800kmあたりだと全然落ちてこないので「報告書はもう少し運用してから……」という感じになりやすそう。「もう少し」運用したときには開発メンバーは全員卒業、初期運用を経験したメンバーが残ってれば御の字、気がつけば年に4回くらいしか運用したことない学生しかいない、みたいな事態も……
まぁ、「打上ビークル待ちしてたら、気がついたら開発メンバー全員卒業してた」よりはマシだろうけど。。。
閑話休題
前半は技術的な話題がメインで、回路図とか踏み込んだ情報が多い。後半は実際に運用したときとか、地上局の話とか。
ところどころ突っ込みたいところが出てくるなぁ。
「これまでに人類が何百個も人工衛星を上げてきたが、衛星が光ったという話は一度も聞いたことがない」とか、「星が光って人の役に立つことが、歴史的にひとつの例外を除いて(ベツレヘムの星)、考えられなかったことによる」とか。
光る衛星というと、有名所ではイリジウムフレアがある。光ることが目的の衛星ではないけど、様々な人達が観測や撮影を行っていた。ISSもよく光る。宇宙関係のイベントとかだとISSを見ようみたいな奴はそこそこありそうな気がする。
光ることを目的とした衛星でも、日本のOICETSを始めとして様々打ち上げられている。「自分で光って、かつ集光せずに(広範囲に)放射する衛星」というのはあまりない気もするが、それにしたってETS-7のドッキング用照明とか、MUSES-Cのターゲットマーカー撮影用フラッシュとか、いろいろ思い浮かぶ。
「星が光っても役に立たない」というのに関しては、「天測航法ナメんな」という話に終止する。時間を知りたい? 太陽を探せ。方位を知りたい? 北極星を探せ。北極星がどこにあるかわからない? 適当な方向を向いて星座を探して参考にしろ。目視観測だけでも役に立つ例なんて掃いて捨てるほどあるぞ。
もう少し技術的なところだと、TLEの計算で、「TLEが発行された瞬間の位置は計算できるが、時間が経つと太陽や地球や衛星の輻射によって計算できなくなる」みたいな話が出てくる。月刊誌に書かれたような何週間も経ったTLEならともかく、SpaceTrackから取ってきた最新のTLEで計算できないわけがなかろう。どんな計算してるんだよ。
地上設備も、かなり冗長なことやってるイメージ。30年前とかならその方法がベストプラクティスかもしれないけど、ここ15年くらいだともっといい方法がありそう。GHz帯のトランシーバは独自開発してる一方で、DC周りはものすごいアナログな手法を使ってたりとか、なんかちぐはぐ。
普通の衛星開発だと全体の技術レベルをある程度揃えて開発するはずだけど、キューブサットだとそれを作る研究室が得意な部分は最先端の方式な一方で、それ以外は古臭い方法を続けている、って感じになりやすいのかも。
***
気分転換に国際単位系のライブラリを作ってる。各単位ごとのクラスを定義して、不正な演算を行うとコンパイルエラーが出るように。ただ、すべての単位に対して和差や各種単位変換を実装しなきゃいけないので、ちゃんと使おうとするとかなり大変。
例えばRadian<T> radとSecond<T> secがある場合、Radian_per_second<T> rad_per_sec = rad / sec;みたいに計算が行える。Meter * MeterだとSquare_meterになるし、Meter * Meter * Meterや、Square_meter * MeterだとCubic_meterが得られる。その他の単位系も追加していけば使えるし、不注意によって不正な計算を防止できる。ただ、実装するのが凄まじく面倒くさいが。
例えばRadianとDegreeを作って、RadianからDegreeに変換することはできる。が、RadianとRadian_per_second、DegreeとDegree_per_secondは別物だから、Radian_per_secondをDegree_per_secondにするには、そのためのコードを書く必要がある。一旦書けば済むとはいえ、組み合わせは膨大だからなぁ。。。
必要になったら追加すればいいや、とか考えてると、いざ必要になったときにメンドクセと思ってfloatとかでベタ書きしちゃうんだよねぇ。。。
今の所、1つの単位は1つのヘッダで定義していて、単位ごとに別のヘッダを用意している。最初はすべての単位をまとめて読み込めるヘッダを定義しようかと思っていたけど、今の方法も結構便利な感じ。
ファイルの先頭で「このソースファイルではこの単位系を使います」という宣言があるので、不用意にそれ以外の単位系を使う危険性が少ない。新規開発中はいちいち使う単位を明記するのが面倒だけど。あと、他のヘッダが読み込んでたりすると、includeで明示してなくても使えちゃうし。
角度とかを扱う処理をしていると、引数がdegかradかrevかわからなくなる、というのが往々にしてあるので、変数の型で単位系を拘束する(不正な単位系が与えられたらコンパイルエラーになる)というのは便利かな、と思ってる。
変数の型で拘束できるので、オーバーロードが使える。基本はradを受けて、degを受けたらキャストしてradに投げる、みたいな処理も書ける。ただ、この場合は無意識に誤差を生む演算が入り込んでくるので、わざわざ暗黙変換を禁じてる意味がなくなってしまう。「この関数が使われる場合はwarningを出してね」みたいな機能があればいいんだけど、無さそう。
ただ、フィルタの処理とかだとdistance = distance * 0.9 + sampling_data * 0.1;みたいな処理もよくあるが、こういう処理を許可しようとすると浮動小数点との演算子を定義する必要があって、そうするとちょっと良くない気がする。フィルタ以外にも、オフセットやゲインの補正でも浮動小数点との四則演算は使いがちなので、その部分をどうやって補正するかも課題か。
リテラルを直接与える演算は実装せずに、何らかの中間形式(FilterとかCoeffみたいな型?)を経由して演算させる、あたりが落としどころかなぁ。
「Volt = Volt * Volt + Volt」=「サンプリングデータの補正」と考えるのは無理があるので、「Volt = Volt * Gain + Offset」みたいな型の拘束を作ったほうが良さそう。GainとOffsetの中で、他の型に対してそれぞれMul, Add演算だけを実装しておく、みたいな感じにすればいいか？ そうすれば他の型を使いたい時でもいちいち追加せずに使えるし。
まぁ、とりあえず一通り使える程度には実装してみて、実際に使いながら判断、かなぁ。
***
F-35、開発が始まったのが2000年代初頭で、JSF++は2005年に発行されている。当時のC++は98とか03だが、それ以降に数回のアップデートが行われている。F-35の開発スケジュールで行けば、今後もあと数回、C＋＋のアップデートを経験するはず。
JSF++では、例外の機能は使用禁止とか、constexprに対応していなかったりとか、現代的ではない決まり事がいくつかある。おそらくF-35のコンパイラもある程度の頻度でアップデートされているはずだから、03にしか対応していない、ということはないはずで、とすればJSF++もそれなりにアップデートされているはずなんだけど、どうなんだろうか。
JSF++の事を知りたくても、「F-35はC++で開発されているよ。コーディング規約はJSF++で決められていて、誰でも見れるよ」みたいな話は時々出てくるけど、ではJSF++を読んでみよう！というのはあんまり見かけない気がする。
商用の静的テストツールでJSF++に対応しているやつがあるけど、JSF++のバージョン情報とかの話は無さそう。
商用テストツールでJSF++に対応していても、「対応してます！」以上にアピールできるものじゃないだろうし、ということは、このツールはF-35本体とか、あるいはそれと同程度に信頼性が求められるモノの開発現場で、実際に使われている、ということかなぁ。とすると、米軍から「JSF++アップデートしたからテストツール更新しとけよ！」って言われたら更新せざるを得ないだろうし、そうすれば一般向けの部分も更新が入るはずだから、「20XX年の更新に対応！」くらいの表記はありそうなもんだが。
そういうのを一切見かけないということは、JSF++は更新されておらず、F-35のコンパイラはC++98あるいはC++03のまま、ということなのか？
0 件のコメント:
コメントを投稿