220429 基礎設計メモ
図面を書く
設計や加工の最初の基準になる部位を決める
- 精度が必要な場所を基準にする
- 加工するときに基準としやすいような平面を基準にする
- 何もないところを基準にしない（例えば、リングの真ん中）
図面を書く時のポイント
図面を描くときは横長に紙を使う
正面の選択は形状がわかる方向を選ぶ
外形線は太めに描く
寸法線は細目に描く
どこに精度が必要かをしっかり理解する（ネジ穴、軸が入るところ）
2重寸法を避ける。（一つの寸法の基準から同一方向に伸ばす）
設計上の注意
ボルトの穴のサイズを決めるとネジの頭の大きさが決まってしまうため、工具で締めこむ作業ができないということが無いように注意して設計する。
材料の選定
・構造用炭素鋼ーー鋳鉄（cast iron)
・高張力鋼：軽くて、加工しやすくて、強度がある程度ある
普段は軽いが、衝突したときにやわらかくボディが変形するため、安全性も高い
じん性、溶接性が良い
→自動車、船舶、橋などの大型機械・構造物
kotobank.jp
・耐熱鋼および耐熱合金
ジェットエンジン、ガスタービン
高温下、クリープと酸化が少ない
・構造用アルミニウム、マグネシウム、チタン合金
航空機、自動車
軽量と高強度
・プラスチック
軽量
高温で使用できない
・ファインセラミックス
高温に強い。耐摩耗性、耐食性がすぐれる。
じん性、加工性が低い
応力解析
安全率は部品の寿命、交換時期を自ら定義して決める。見かけの大小で判断しない。よく使っている安全率は表がある。
自動車：部品の交換頻度低め→安全率高め→部品が大きくなる→空飛ぶクルマは難しい
220426 ISDPメモ
Space Mission Engineering
ミッションには二通りの考え方がある。
Needs-Driven: 問題から始まって方法を考える方法。多くの宇宙ミッションがこの形を解く。
例）宇宙の中で調べたい天体がある
Capability-Driven: 新しい技術・方法論から始まってそれらでできることを考える方法。
例）イオンエンジンを開発していてそれを使って何かしたい
Space Mission Engineering Process
宇宙ミッションの設計では、これらのプロセスを行き来する必要がある。
① 要求・制約を定義する
a. 大きな（量的な）目標・制約を定義。具体的な数値はあとからついてくるので数に固執しない。
b. 主要なプレイヤーを定義（誰がそのミッションの影響を受けるのか）→これを考えることでよりよい要求につながることがある。
c. プログラムのタイムスケールを定義：スケジュール
技術的なプロジェクトの計画・スケジューリング・想定は非常に難しい。
d. 量的なニーズ、要求と制約を推定する。
例）
○○ロケットを使わなければならない→質的（qualitative)
○○ロケットを使うので、ペイロードは□□キロ以下にしなければならない→量的（quantitative)
② Mission Architectures, Conceptsを定義
Mission Architecture: ミッションで何が使うことができるか。
例）どんな装置が使えるのか、どんな地上局の機能があるのか
Mission Concepts: それらの機能を組み合わせてどのようなことをするのか。
a. mission architecturesを定義
b. mission conceptsを定義
c. どれが大きな課題になるかを考え、主要な制約を定義
例）電気推進を使う→多くの電力を使用するが、その電力はどうやって得るのか？
③ さまざまなMission Conceptsを評価する。
a. 機能の評価＆システムの変更。質的な評価も十分に有効。
b. ミッションの効用を計算。たくさんの計算が必要。
c. ベースラインとなるmission conceptとarchitectureを定義。ここから実際に物を作ってテストを始めることができる。試験をしていくうちに前に戻って改善することがある。
d. 量的な制約を要求を改善する。
e. iterate and explore other alternatives
Q. What is the difference between constraints and requirements?
Constraints: Limitation (power, mass, size) on your spacecraft. Borderline of the designing space.
Requirements: Specification to the system. Targets the systems need to meet.
④ どのサブシステムがどの仕事をするのか、どのシステムが何をしなければならないのかを定義
a. システムの制約を定義
b. それらの制約をシステムの要素に割り当て
Introduction to Mission Elements
Mission Elementsの種類
・Subjects（≒Target） 例）サンプルリターンの場合：訪れる天体、
・End users：誰が恩恵を受けるのか 例）通信衛星の場合：インターネット利用者（この場合Subjectsでもある）
・Mission Operations (≒Schedule, Timescale)：いつ検査をするのか、いつエンジンを使うのか
・Orbit/Trajectory：とても重要。どこに行くか。どれくらい速く移動するか。宇宙機自体の設計ではないが、非常に大切。
非常に大事な役職の一つに：Astrodynamicistsがある。
・Launch Vehicle：これにより行ける場所、持っていける重量、打ち上げ時の衝撃などが決まる
・Ground Segment：通信システム（アンテナなど）
System Boundary：この内側にあるものはコントロールできるもの。
上の中でコントロールできないもの：Subjects, End users
・Spacecraft Subsystems
- Payload
- Propulsion：
- Attitude Determination & Control (ADCS)：微小重力環境でどこを向いているかを知る
- Guidance, Navigation & Control (GNC)：位置を変える
- Command & Data Handling (C&DH)：例）頭脳＋神経、郵便局のようなもの。計算してその結果出てくる命令を分配する
- Telemetry, Tracking & Command (TT&C)：通信システム。宇宙機が地上と通信する。基本的にはラジオ。
Communicationという単語を使わない理由は以下のような二つの通信があるため。
External：地上局との通信
Inernal：他のサブシステムの部分に対する通信
- Electrical Power System (EPS)：どうやってパワーを得るか。ソーラーパネルだけでなくバッテリーやpower distribution systemなどの機能もここに含まれる。
- Bus/Structure：構造。宇宙機の骨格。
- Thermal Control：熱の移動・利用。
このように役割分担することで、管理がやりやすくなる。仕事量はサブシステムによって異なるため、実際の役割分担はもっと工夫する必要がある。
Systems Engineering
How do you eat an elephant?→ One bite at a time!
Mission Concepts: どのようなことを成し遂げたいのかという質的な目標。
↓
System Requirements: Mission Conceptsを達成するための要求。
例）どれくらいの画質、どれくらいのスパンで撮影するのか、赤外線なのか
Types of requirements:
- Performance Requirements: 宇宙機がどのような機能をもっていなければならいのか
- Operational Requirements: 宇宙機をどのような環境で動かさなければならないのか
- Constraints: 設計上の制限
Requirements should be:
- Necessary：要求には理由がないといけない
- Quantitative：数値のような量的な基準がなければならない
- Verifiable：数値・条件で明確に評価できなければならない
新出用語:
EPS: Electric Power System
BOL: Beginning Of Life
↓
機能の割り当て
どのサブシステムがこれらの要求を達成するのか。
例）どの部品が地球との交信を担うのか
基本的に部品それぞれが明確な一つの役割を持っているためやりやすいことが多い。
↓
サブシステムの要求
どのような
↓
詳細設計
基本的な工学・応用科学の法則に基づいて設計。
- Structural mechanics & vibrations
- Electronics & EM
- thermodynamics & heat transfer
- Control theory & software
Use common techniques
- Simple analysis/ calculation
- CAD/ 3D Modeling
- Numerical analysis & simulation
詳細設計がV-modelの底。ここから統合がはじまる。
↓
Subsystem Verification & Validation
それぞれのサブシステムを評価する。
↓
System integration
"Putting it all together"
サブシステムが干渉せず、互換性があることを確認する。
統合の際に確認する部分
- Communication/ Data
例）そのフォーマットは対応しているか、ハーネス・コネクタはちゃんとつながるか
- Functional
例）太陽パネルは十分な電力を供給しているか
- Physical
例）物理的に接触している部分が緩んでいないか
- Vibrational：
例）振動がサブシステムをどのように影響するか
- EM Radiation
例）信号・電波が干渉していないか
- Charge/Grounding
例）片側に電荷がたまったときにどうするか
- Thermal
例）ある部品は低温に保たなければいけないかもしれない vice versa
Verification & Validation
Verification: "Does the design meet the specification?"
Validation: "Does the specification meet the mission concept?"
Verification methods:
- Analysis:
- Test: run the component
- Inspection: measuring the hardware
- Demonstration: test for software
- Similarity: looking at similar systems that worked in the past
XPLANE TALK メモ
高校のときにインディアナ州に10カ月ホームステイしてたので、Purdue Universityの航空宇宙にはすごく興味があって参加してみました！ホストファザーも憧れた先生もケネディー宇宙センターで話した宇宙飛行士もPurdue Universityの卒業生だったのでこの大学には思い入れがあります。
五十嵐さん自己紹介
研究内容：テーマ「地球外での建設のシステム安全（System Safety)」
地球外での建設→宇宙ステーション、月面基地など
System Safety：日本語だと近いのはビジネス分野での失敗学
⇔ Occupational Safety：労働災害
事故を防ぐときに、人間にフォーカスをあてるのがOccupational Safety。
例）人の不注意、飲酒運転などの人為
モノ・環境にフォーカスをあてるのがSystem Safety。
例）安全装置、標識など
宇宙でモノを作るときにどのようにしくらないようにするかを研究。
しくじりそうなところを可視化する。分かったうえでリスクをとるのと、何も分からないでリスクに突っ込むのでは大きな違いがある。
まず、どういう仕組みやメカニズムで事故や失敗が起こるかを考えないと、対策は分からない。
Accident Model（事故モデル）を立てる。いつでも計算可能ではない。
線形モデル
例）ドミノモデル→しくじりがパタパタと連鎖して事故につながる
作るものが複雑になってくるとこのモデルでは説明できないことが増えてくる。
非線形モデル
社会の仕組みを構造化して、影響しているfactorを分析したい。
これらを研究することによって、地球外で建設をするときにどのようなことに気をつけている。
アメリカの大学院って大変？
土山さんの意見
日本の大学院：「優秀な人」という像に向かって合わせていくイメージ。
アメリカの大学院：多少研究が伸びてなくてもいろいろな観点で評価してくれる。
日本の方が自由度が大きいというのが正直なところ。
五十嵐さんの意見
授業の課題は多いが、日本もアメリカも大変だった。
忙しいかといわれると比較できない。
加藤さんの意見
アメリカはカリキュラムがしっかりしているが、逆にそのレールに乗っていれば良い方に行く。
Campus Visitは絶対言ったほうが良い。
そこにいる先輩から生の大学院生の声を聴いておいたほうが良い。（だいたいそれがラボの本当の姿）
指導教員との相性
加藤さんの意見
実際自分が学生になって一緒に働いてみないと相性は分からない。
進学先選びをしている人→万が一その人と合わなくてもサブの候補がいるところに行く
アメリカの大学の方が教員が多いので、教員を変えるのは日本よりやりやすそう。
土山さんの意見
日本での指導教官もよかったので、そこを出てまでやる意味があるかは考えた。
「この人の研究するかもしれないんだけどこの人どういう人？っていうのを同じ学会でその人を良く知っている人から聞いたりした」
五十嵐さんの意見
全く確認しなかった。受かったのが修士で論文なしコースでしか合格をもらえなかった。→指導教官は基本的にいない。指導教官が見つかればコース変更できる。
評判うんぬんの前に指導してもらえる人を見つけるのが第一優先。
相性を考える余裕がなかった。
宇宙で何か組み立てる系なら何でもいいので探すという気持ち。
ピンポイントでそこをやっている人を見つけることができた。
加藤さんの意見
指導教官からお金をもらっている学生は指導教官変えにくそう。
全員一致の意見
修士1, 2年は誤差だから学部卒にこだわらず幅広い選択肢を持つのが大事。
アメリカ来るとすごくそれを感じるようになった（多数）
今学部卒で奨学金をとったりするのがとても難しくなっている。
日本の修士でじっくり経験を積んでから来るのも全然良い！
0419 ISDPメモ
英語で衛星設計をする授業をとりはじめたのでメモ
このレクチャーは航空宇宙を勉強していない人向けなのでレベルはそこまで高くないですが、いざノーヒントで聞かれるとすぐに出てこなかったのでいい復習になりました。あと英語で航空宇宙を勉強できるのは本当に貴重な経験です。
宇宙開発は難しい！
質量：mass
宇宙にいるために必要なこと→ 高く・速く
微小重力：microgravity
流体を動かすのが難しくなる。常にpressurizationが必要になる。
例）無重力で濡れタオルを絞っても水が抜けない
人体にも影響
真空：vacuum
heat transferにおいて問題になる（対流・伝導が起こらない）
cold welding 2つの金属が近づくと、間に全く物がないので、金属結合ができてしまう。
例）展開するアンテナが付着して展開しなくなった
outgassing：気体漏れ
電力：power
多くのものを運べないので、発電量も限られる
1.0 m^2のソーラーパネルでできることは？ 1400W
→電子レンジ、トースターなどと同じぐらいの電力
これが木星だと、、、距離は5倍になるから得られるのは5Wだけ！
これが冥王星だと、、、距離は40倍になるから得られるのは0.6Wだけ！
→小さいLEDを光らせるぐらいの電力
したがって、深宇宙探査のためには、ソーラーパネルに頼らない衛星設計が必須！
温度：Temperature
寒暖差が非常に大きい
例）衛星の片面だけ温度が非常に高くなったり低くなったりする
デブリ：Micrometeoroids & Debris
違う軌道で動いていたら相対速度は10km/s以上にも
→ 弾丸よりも速い
狭い範囲にとてつもない運動エネルギー
Kessler Syndrome: いつ起こるかわからない。
「デブリが宇宙機に当たる→デブリが発生する→さらにデブリが当たりやすくなる」という悪循環が始まって、cascading effect（カスケード現象）が起こる現象。
最悪のケースの場合、低軌道でこれが起こるとどこにもロケットを打ち上げることができなくなる。
Radiation & Charged Particles
UV Radiation
→ component degradation
例）ソーラーパネルの発電効率が落ちる
Solar Wind, Cosmic Rays
→ Charging
例）グラウンドがないので電荷がたまる
→ Sputtering：low mass but high velocity 表面を傷つけることがある。
例）天体観測衛星の鏡の表面が傷ついて正常な観測ができなくなる
→ Single Event Phenomena：電子機器に荷電粒子が衝突→電子機器の信号が変わったりする。実際にはあまり起こっていない。
例）制御などに悪影響。
宇宙でできること
communications
→ typically commercial
代替案→宇宙本当に必要？
Terrestrial communications
Undersea cables
例）
Indium：電話
Starlink：衛星によるインターネット
静止軌道（GEO）→ずっと同じ場所に衛星がいる
コンステレーション→何個も衛星が回っている
position, navigation & timing
a.k.a (also known as) Global Navigation Satellite System（GNSS)
Not only for navigation!
timingは非常に大事！高速で移動しているため、相対性理論を考慮しなければならないときがある。高速で移動しているために時間を補正しなければならない。例えば、ATMでの時間の管理はGNSSの衛星から得ている。
remote sensing & earth observation
Traditionally government (e.g. Landsat), Becoming commercial (e.g. Axelspace)
商用衛星が盛んになってきている。
考慮しなければならないこと
Timing
Resolution
EM Spectrum
代替案
Drones, aircraft
コンステレーション衛星によって、何回も航空機を飛ばして少しずつ撮影していた上空からの映像が高頻度で撮影できるようになる。
science & exploration
知識・理解を広げる
有人・無人ミッション
無人の問題
・火星のような遠い場所では信号の往復に非常に長い時間がかかる
・壊れたらだれも直せないので、探索が遅い
→有人だと無人よりも圧倒的に速く動くことができる
有人の問題
・人が帰ってくることを考えなければならない
・生命維持装置が必要
データ収集
・リモートセンシング
・その場での(in-situ)サンプル収集
・サンプルリターン
→一番良い機器でサンプルを分析することができる！
education & training
学生ミッション
Cubesat
Cansat
military
"Space is the ultimate high ground"
Reconnaissance：偵察
Anti-Satellite：衛星を破壊 試験中に大量のスペースデブリが発生。
Space Weapons??
resource utilization
Concepts/ Proposals Only
他の応用
Space Tourism
Space Burials
Space Art
Orbital Servicing
etc...
220418 アカデミックライティング メモ
明確で簡潔な表現を心掛ける
- 同じこと言うなら短い方がいい→受動態が必要ないのなら避ける
- 主語：WeやYouを避ける
- 主張（We believe...のような場合）は使う場合がある
- methodologyの部分では例外的にWeを使う場合がある。→誰が何をやったかが重要であるため、主語をWeにすることがよくある。
- 動作の名詞形：使わなくてもいい場合は使わない
- Rust is formed as a consequence of a reaction of iron with oxygen.→ Iron reacts with oxygen to form (produce) rust.
- 動作の名詞形は、潜在的な意味として主語を含むので、必要かどうか明確に意識する
- e.g.) The use of the program saves time. → The program saves time.で十分
- phrasal verb (e.g. go on, check out etc.)を避ける
- 具体的内容を表す動詞を使う
- 動作動詞を使って文をコンパクトにする
- 直接疑問文（How good has it been?)は避ける
- 読み手を引き付ける効果はあるが、ジャーナルによって許しているところと許していないところがある
- 間接疑問文を使う必要がない場合は削除
- 曖昧なことを避ける (e.g. good, a lot of)
- 正確な語彙を使う
- ダイレクトな表現を使う
- 事実と意見は分ける
Q. 著者が一人の場合は？
昔：一人の場合でもWeを使っていた。
最近：著者が一人のときはIでもいい業界もあるらしい。
→自分の分野の論文を見る
→一人の著者でジャーナル論文が出てくる業界も限られる
難しかったパラフレーズ
The data, which we thought could possibly be correct, led to a result we did not expect.
→The seemingly correct data resulted in an unexpected outcome.
According to new research, it is certain that female lemon sharks give birth at the place where they were born.
→ New research has revealed that female lemon sharks give birth at their own birthplace.
Because these natural resources have excellent properties, they will be used in many applications.
→ The excellent properties of these natural resources will lead to their widespread use in many applications.
開発環境構築についてのメモ
今日は会社のPCでゼロから環境構築をしたのでハマったところをメモします。
ポイント１ Windowsに直接環境構築をせずWSLを使う
Windowsに直接インストールしようとすると、PyTorchが入らなくて困った。
WSLを使ってLinuxをWindows上で動かすことで無事インストールすることができた。
エディタはVSCodeを使っており、Remote-WSLというExtentionをインストールしてWSLを使えるようにした。
ポイント２ Linux環境を立ち上げたらまず「sudo apt update」を実行
これを行わずにpipをインストールしようとしたらバージョンが合っていないのかうまくインストールすることができた。
これはラズパイやJetson nanoで開発した時にも有効な手段だったにもかかわらずまた忘れてしまった。
衛星の基本設計
宇宙工学入門で説明されたの設計の重要な考え方をまとめます。
Heritageの重要性：なるべく前作と同じ機器を使うことで安定性を高める。
Budgeting：成立性を早く明確にする。
- 太陽電池パネルで得る電力で衛星を運用することができるかをしっかり考える。消費量の方が多いときは、太陽電池パネルを大きくするか、運用のシナリオを変える（例えば、通信時間を短くする）。
- バッテリーは空っぽにすると傷むため、余裕を持つ（ただし、バッテリーを大きくすると重さは増えてしまう）。
Cansatの場合の手順
① ミッションシークエンスを参照
② 総電力消費量を計算
③ マージンを足す（1.5倍など）
④ 必要なバッテリータイプとサイズを決定
⑤ 本番の環境で実験
Water flow Type Project Management：できるだけ早く欠陥を見つける
- プロジェクトマネジメントを早くしていくのも研究課題
- 下から上には戻らないことでお金と時間を節約
① ミッション作成：システムレベルでデザイン
ーMDR (Mission Definition Review)
② Breadboard Model Phase (BBM)：詳細設計のための実験を重ねる
ーPDR (Preliminary Design Review)ー：フィージビリティを検査するためのレビュー会
③ Engineering Model Phase (EM)：何個か試作機を作る。宇宙環境での機能を確実にする。
ーCDR (Critical Design Review)ー：設計を見直して確認
④ Flight Model Phase (FM)：設計通りに制作
ーLRD (Launch readiness Review)
⑤ Launch & Operation
Monitoring and Reset（おかしい動作をしているものは電源を切る）
衛星の難しい点：一度上がると修理できない→相互監視、リセットの有効活用、Dead Batteryからの復活能力が必要
リセット活用によるロバスト化：永久故障以外はリセットで復帰することが確実だという前提に立てば、冗長系よりもリセットを確実にしたほうが効果的。
- CPUの相互監視
- システム内に「神」を置く
- 過去の衛星で確実に動いたものを「神」として搭載して、新規の要素の監視役にする。
- 「神」にバス作業をさせ、裏で新規のCPUをミッションで試す。
- 「神」が不安であれば、相互監視によりさらに強化
衛星の動作の管理（モードとモード遷移）
モード：それぞれに特徴を持った「衛星のあるタイプの動作」を表現したもの
- 初期モード：ロケットから分離した直後のダンブリング状態
- セーフモード（サバイバルモード）：電力消費を最小にし、「耐える」モード
→何か起こって、状況の把握に時間がかかりそうな際に、まずはここに入れて死なないようにする。
→原因追及、一部試行錯誤などで解決策を探す。
モードごとに何が違うか
- 姿勢制御の目的
- 使う機器
- CPU,通信などの機器の作業内容
モード遷移：「ある条件」が満たされると「手動」ないし「自動」で遷移する。
その他の留意点
複雑さを排除する
- 複雑さの指標として、コンテクスト数という概念が提案されている
- 異なる地上試験を必要とし、人間がそれぞれの状況での危機の動作の健全性を考えないといけないコンテクストの数
どんな姿勢でも太陽電力確保できる設計
再現性を高める
- EM→FMの移行時に再現性に注意する
- 電源系などは各機器の電力が変われば変わる。：値をスケーラブルに帰られて試験しなくてもよい設計にする
- FMで設計変更したものは検証の必要性がある
- 機器ごとの個別FM試験だけで済むようにしたい：他とのインタラクション（コンテクスト数）ができるだけ少ない設計にしたい。
- 再現性が問題になる機器
- 作り手の個性への依存性をできるだけ避ける
- 作り手が変わると性質が変わるような設計を避ける
