TOBはいわば公開ラブレター、ニデックが経緯と見解を改めて表明：製造マネジメントニュース - MONOist
相手が嫌がっても札束で殴って逃げ道塞ぐタイプのラブレターは笑えない。
バーチャルISS内で球形ロボット操り、実機と比較検証。KDDI×スペースデータ | TECH+（テックプラス）
スペースデータのISSシミュ、実機と比較するまでもなく、物理エンジンとしてだいぶひどい実装だというのは1分も触れば十分わかると思うんだけど、一体何を比較するんだろう? もしかして更新入ったのかな?と思ってアップデートしてみても相変わらずだし。
宇宙に興味はあるけど詳しくはない、みたいな人にSteam経由で遊ばせるならともかく、こんなクソみたいなエンジンをありがたがって使うって、日本の宇宙開発のレベルはそこまで低くないと思いたいんだけど、実は結構ヤバいんか? それとも、Steam版は「素人向け」であって、実際に使っているやつはもっとマシなんだろうか? じゃあそれを公開してくれよ、と思うのだが。Int-Ballの推力だとまともに動けないから、とかなら推力等のパラメータだけ調整すればいいわけで、なんでわざわざオイラー角で演算したりロール軸を拘束したりするねん。新入社員の研修用に自分でググらせて書かせたコードじゃねーんだぞ。
体験版が公開されたよ(製品版のリリースは8月の予定)。
ざっくり最後まで遊んでみたけど、面白かった。
ストーリーの進み方が冗長(説明が多い)だったり急展開(途中をすっ飛ばしたり)といった印象があるけど、ゲームとして作ろうとするとどうしてもしょうがない部分なのかな、という感じ。未知のビットストリーム(2値x2次元空間)の解析とかいちいち全部手順追って説明してたらそれだけで飽きられるだろうしな。
あとは誤っている点とか、あるいは誤っているというほどではないけど適切ではないような点がいくつか。体験版プレイ後アンケートで「宇宙開発や理論物理を専攻している人に協力してほしいからそういう人は連絡先ちょうだい」みたいな記入欄があるから、設定考証はこれから作業するのかな。今から作業したらストーリーの根幹部とかはさわれないだろうし、表面的な部分だけ直して終わりって感じになりそうだけど。
今まで使っていたキーボードは65％キーボードみたいな感じで、Enterキーの下に矢印キーがあった。テキスト入力中に矢印キーを使いたいときに、手の移動をあまりしなてくても矢印キーに届くのが利点。新しいキーボードはEnterの外側に矢印キーがあるのでちょっと遠い。
新しいキーボードはキーピッチが8%近く大きいのと、Enterの右側に矢印キーがあるので、キーボードの幅も今まで使っていたものに比べて27％ほど大きい。普通に作業する分には特に問題ないけど、FPSとか、マウスを広く使いたいときは邪魔。
今まで使っていたキーボードはZキーの下にWinキーがあるけど、新しいキーボードはZキーより左側(今までのキーボードではFnキーが有る場所)にWinキーがついている。自分のブラウザの使い方として、新しいウインドウを開いてから検索ワードを入力して、読み込んでいる間にWin-矢印で画面の適当な場所に配置する、という操作が多いんだけど、今までWinキーだった場所がAltキーになっているので、ウインドウを左に移動しようとしてWin-←を入力したつもりがAlt-←を入力していて、ホーム画面に戻ってしまう、という挙動が度々発生する。結構不便。
ゲーミングキーボードは普段遣いには向かないよね、という当たり前の結論が得られそう。
あと、HMIデバイスを通販で買ってはいけない、という、HMIを買うたびに実感しているやつを再確認。まあ、実店舗で買うと交通費で値段がほぼ倍になるから、半額で買えたと考えれば。。。
適当な台をパームレスト代わりに使うと、一見楽なようで、実は文字入力速度が結構遅いような気がする。手を浮かせて入力するより、むしろ机につけて入力したほうがいいかも。というか、立って入力する高さだと、かなり文字入力しやすい気がする。座って文字入力するより誤入力が少ない気がする。実際、立った状態で寿司打をやるとスコアが結構上がる。とはいえ前のキーボードでガチってた頃よりは落ちるけど。
そういえば、このキーボード、根本がType-Cなので、C-Cケーブルを使えば(OTG変換とかを使わず)スマホに直結できる。パソコンがなくてもどこでも寿司打が遊べるぞ! こんなクソ重いもの持ち運べんが。。。
SELENE(’07年10月に月軌道投入)のホイールアンローディング、定常運用中は1日2回、RW1基故障(’08年7月)以降は1日4回行っていたらしいけど、地球周回衛星に比べてやたらと高頻度な気がする。地球(LEO)だとそもそも外乱トルクの平均値を吸収できるようにMTQを設定しているからRCSアンローディング自体が不要という可能性もありそだけど。1周120分として、アンローディングは6周毎くらい。月重力場の解析とかをやるためにはある程度長い安定した軌道があったほうが便利だろうけど、この程度でも十分なのかな。
2008年10月上旬までは南極上空でアンローディング運用。高電圧を使用する機器(e.g. LALT)はアンローディング直前からある程度の時間は使用できないから、南極付近に観測頻度が低い範囲が発生する。’08年10月以降は北極でアンローディングすることで、南極付近の観測が増えた。
人工衛星のアンローディングの頻度って情報ほとんど見当たらないような気がする。情報公開に消極的な準天頂衛星が数少ないアンローディング周期の情報源。アンローディングに由来するΔVは測位精度やサービス可用性の悪化に直結するので、QZS-1で評価が行われていて、それによるとアンローディングの頻度は実績値平均92日間隔とのこと。静止衛星だとスロットの維持でΔVを吹く機会が多いとか、そのついでにアンローディングも行うとか、色々違いはあるだろうけど。
ASTRO-HはEOB伸展が2月28日、通信異常が3月26日で、この間1ヶ月はMTQでアンローディングを行い、RCSを吹いていない。科学衛星だから姿勢変更もある程度多めに想定していて、ホイールの容量が大きいというのもあるだろうし。特殊な例だとMUSES-Cとかはや2はIESをジンバリングできるので、加速中の2軸はそれでアンローディングできる。残りの1軸はRCSでのアンローディングが必要だし、小惑星ランデブ中はRCSで安定化させる必要があるとしても。
NOVA衛星のドラッグフリー制御の名前がDISCOSなの、もしかして衛星内で浮かせた金属球をミラーボール(英語でdisco ball)に見立ててつけた名前ってことなのかな? ボールの位置計測とかは光学的にやっているわけではないと思うので(検出は静電容量のはず)、ミラーボールみたいに光を反射するようなものではないはずだけど。
見た目的にも機能的にもミラーボールっぽいのはEGSとか。EGSは太陽光を反射するために普通の鏡(平面ではなく多少のR)を貼ってあるけど、それ以外のSLR用ターゲット衛星、たとえばLAGEOSなんかはCCRしか貼ってないので、ミラーボールみたいな反射はしない。ECHOみたいな風船はたぶん一定輝度で反射していて、ミラーボールみたいにキラキラするわけではないはず。
キューブサットの放出機構、例えば3Uだと長軸方向に速度をつけて放出するけど、角運動量を与えて放出してくれるポッドってないんだろうか。3Uなら長軸の両端で持っておいて、片方のラッチを外してバネで跳ね起こして、立ち上がったら反対端のラッチが外れてそのまま運動量が与えられて分離する、みたいな。3U程度の大きさなら姿勢安定化を(能動にしろ受動にしろ)行わない衛星もあるだろうし、どっちを向くか(スピン軸がどうなるか)わからないくらいなら、多少のスピン安定を与えて分離してくれたほうが便利な場合もありそう。後で外れる方のラッチの設計が難しそうだが。
軌道面が回転するとスピン軸と軌道面の関係も変わるけど、スラスタを1個積んでおけば修正できるから、3軸制御(最低4器のスラスタ)に比べればかなりシンプルな構成になる。電力配線の通し方次第でトルクが出てスピン軸とか周期が変わりそうだから、長期的には不安定な安定化方式なのが難点。スピン周期を変えるなら2器のスラスタが必要になる。MTQで打ち消すなら気にならないけど、それなら最初から3軸安定で設計しろって話になるし。
やっぱり分離機構の機械的な複雑さが嫌がられるのかな。あるいはキューブサットの放出機構はもう規格化されているから、みたいな理由もありそう。スピン放出の場合、ポッドにいれる必要がないから、少なくとも大面積3面+小面積1面は比較的自由に突起物を作れるという利点がある。例えばスピン軸と同軸にアンテナ素子を突き出しておけば、展開機構無しに安定した通信ができる(無指向性ゆえのデータレートの低さはさておき)。Dawn/Duskのrolling-wheelなら回転軸方向に太陽があるから、うまく作れば3Uで30x30cmくらいの発電面が作れそう。
電子基準点の南側10m位の場所で取ったサンプルの再解析
前回、サニャック効果を含めるのを忘れていた。それを含めると基準点の真南13m位の場所に中心がある分散になる。ということで、東側にズレて出ていたのはこれが原因。上にずれる原因は不明だが、VDOPの問題かな?
適当なサンプルデータが欲しくて、アンテナを持って外で取ってみたんだけど、うまく復調できない。クイックルックでもスペクトル全体が時系列で暴れるので変な発振が起きてたっぽい。前回移動中にサンプリングした組み合わせなのであんまり問題はないはずなんだけどな。前回は車の屋根にマグネットで貼り付けて、今回は手で持っていたので、GNDの有無が問題なのかな? 何回かサンプリングしてみたんだけど、なかなか安定して受信できない。この時期はまだ寒すぎて外でアンテナとノートPCを持ってサンプリングするのは結構きつい。寒いというか痛い。
amazonで数千円で売ってるポールマウントのGPSアンテナ(船用想定?)ってGND無しでサクッと使えるようなものなんだろうか。ポールマウントってことはその下に金属プレートをいれるような想定ではないはずなんだけど。ある程度大きさがあるから開口面積もありそうだけど、中国製の安物だとセラミックアンテナとか車載用のアンテナをケースに突っ込んだだけって可能性も捨てきれないのがなぁ。。。
rtl-sdrで設定できるサンプリングレート(1kHz分解能)と、2^13と2^14で割った値
1.6Msps以下であれば2^13ptsで200Hz未満の周波数分解能が得られる。1.8Mspsより高いサンプリングレートの場合は2^14ptsFFTが必要になる。FFT窓が2倍になると同じ範囲をスキャンするのに2倍のIFFTが必要になるし、FFT自体の計算量も増える。2^13と2^14ではスキャンに必要な時間がだいぶ違う。
2.4Mspsをドロップ無しでサンプリングできたとして、それを単純に(CICとかFIR無しに)2分の1にデシメーションして2^13ptsでスキャンしたりってできるんだろうか。あるいは2点の単純加算でLPF特性とか。
ただ、FFTで畳み込んでからコヒーレント積分する場合、FFT窓が狭くなるとその分SNRが落ちるデメリットが有る。窓が狭くなって計算が早くなる利点がデカいので、とりあえず端から端までスキャンして、一番相関値が高いところを長い窓でもう一度相関取って、みたいな処理にしてもいい。
相関器のロスト判定ってどうやってやるのがいいんだろうか。現状はサブフレームを受信したタイミングでパリティチェックを行ってエラーでロスト判定を行っているけど、最悪6秒の遅れがあるし、その間に相関器がフリーランするから位置誤差が急激に発散する。Early,Prompt,Lateを一定程度(0.5秒程度?)平均化したうえで、最大値と最小値の比が一定以下になったらロストと判断する、みたいなロジックとか?
GPSの相関器に入っているDLL、今どきのシリアルバスだと必要ないだろうし、GPSに名前を残すだけの古の回路なのかな、と思っていたけど、どうやらDDR-SDRAMにもDLLが入っているらしい。DDR5の資料にもDLLの字面は出てくるから、最近のメモリにも入っているようだ。ただ、あくまでもクロックとデータのズレを吸収するのが目的であって、32bitとか64bitのデータバス全体にDLLが入っているわけではない? データバスは等長配線で頑張って、それとは独立に引き回すクロックはDLLでズレを吸収する、というようなことなのかな。
CDRにもDLLが入っているらしいけど、ググってもいまいち出てこない。CDRは用途(プロトコル)によっても実装はまちまちだろうし。
