セキュリティ・キャンプ全国大会2024 S17 探査機自作ゼミ 事前学習・当日資料

セキュリティ・キャンプ全国大会2024 開発コースで開講した「探査機自作ゼミ」の事前学習と当日に使った資料です。
ゼミ概要：https://www.ipa.go.jp/jinzai/security-camp/2024/camp/zenkoku/program/kaihatsu.html#s17

Transcript

1. S17探査機自作ゼミ オリエンテーション sksat
2. 今日のゴール ・ミニマム: 自己紹介 + 雑談しつつお互いを知る ・フル: これ以降のスライド ・エクストラ: ソフトウェアエンジニア向け宇宙開発入門
3. 自己紹介タイム ・話すことに迷ったら見る欄 ・呼び方（本名でもハンドルネームでも可） ・興味範囲や今までやってきたことなど ・得意な技術や分野 ・今はあまり得意じゃないけどできるようになりたいこと ・今話してない人が見る欄 ・気になったことや知らないことがあったら聞いてみよう
4. 講師自己紹介 ・sksat（えすけーさっと） ・ArkEdge Space Inc. コンピューティング基盤部　/　筑波大学情報科学類（休学中） ・宇宙オタク -> パソコンオタク -> 宇宙パソコン野郎 ・やってた: OS、x86エミュレータ、数値計算、小型ハイブリッドロケット、自宅サーバ ・やってる: （超小型人工衛星の）OS/Framework、シミュレーション基盤、CI/CD、姿勢制御系、社内システム ・趣味: 自宅サーバのオーバーエンジニアリング、VRChat ・気持ちがあるところ: 実在する複雑性の咀嚼と妥当な対処の案組み ↖これ中指じゃないです
5. このゼミの目的 複雑なものづくりへの 立ち向かい方を体感してほしい
6. このゼミの目的 複雑なものづくりへの 立ち向かい方を体感してほしい 考えることが多い どう手札を用意するか 0 -> 1 やってみなくちゃ わからない
7. 注意事項: このゼミでの sksat のふるまい ・sksat は立場上は「講師」ですが、別に偉い人ではありません ・sksat は「答えを知っている人」ではありません（「答え」はまだ存在しないかもしれません！） ・sksat は以下のようにふるまいます ・セキュリティ・キャンプ2024の講師: ゼミとしての連絡や、当日の物品の用意などをします。 ・調整相手: 親機や地上局ハードウェアの担当者です。 ・探査機のハードウェア開発の主担当: 時間などの都合上 HW はある程度準備しています。 ・便利な経験者: 宇宙開発や組み込み Rust の経験者です。叩くと便利な情報が出がちです。 ・座学的な話をする時もどちらかというとこのふるまいと思ってください
8. 時間を有効活用しよう ・重要: セキュリティ・キャンプは長いようで短い ・非同期コミュニケーションを有効活用しよう ・sksat を使い倒そう
9. 「雑」なコミュニケーションをしよう ・雑に発言をしよう ・思い付いたり気になったりしたことを失ってしまうのはもったいない 立場がどうとか仕事がどうとか全く関係なく、我々は今後行うべき行動について何が正解か、何も分かっていませ ん。全然わかっていません。 だからこそ互いに雑な発言を投げつけ合いうなかで、分かっている事実とわかってい ない領域を整理して、真に自分たちが取り組むべき問題と解決の方向を見いだすのは、現実的な手段です。 雑な認識からはじめましょう。雑に言い合いましょう。雑な発言を許容しましょう。
10. ゼミの進め方 ・週１ぐらいで同期的な会話の場を設けます ・まずはこの時間を決めましょう ・座学的なこと、ディスカッション、ペアプロなど
11. 開発の準備 ・GitHub organization ・要確認: みなさん GitHub 使えますか？（規約など的に） ・Rust 開発環境 ・rustup ・VSCode ・エディタの強制はしません（なんなら僕も普段は Neovim です） ・それはそれとして最近はかなり便利なので、知っておくと手札が増えます
12. ミッション ・惑星探査機に相乗りする子機（のローバー） ・目的: 環境情報取得、将来の探査のための技術実証、サンプル・リターン Image credit: Go Miyazaki Photo: © CNSA/CLEP
13. 次回予告 「設計」をしよう
14. 宿題（？） ・探査機の大雑把な設計を考えてみよう ・自律的に動作してデータを貯める、親機・地上にデータを送信する、地上からコマンドを受 けて動作を変える、サンプルを親機に持ち帰る ・これらを実現するためにどのような機能が必要か ・機能をどう分割するか
15. S17探査機自作ゼミ 01-「設計」をしよう sksat
16. まずは大雑把にやってみる ・エイヤで色々言ってみる（ブレスト）（雑に！） ・目的から深堀りする ・どんな環境情報が取得できるとうれしそう？ ・どんな技術は「次」にも役立つ？ ・どうやってサンプルを採取する？ ・どうやって親機までサンプルを持ち帰る？ ・技術（手札）から深堀りする ・どんなマイコン・センサ・アクチュエータが使えそう？
17. 惑星探査機を設計してみよう ・目的 ・環境情報取得 ・将来の探査のための技術実証 ・サンプルリターン Photo: © CNSA/CLEP
18. そもそも「設計」とは？
19. 「設計」とは？ 「どうやるか」を考え、言語化していく営み
20. 「どうやるか」を考え続ける ・一度やったらハイそれで終わり、なんてことはない ・設計レベルからのやり直しは大変（手戻りが大きい） ・もう実装していたらそれも作り直しになるかもしれない ・とはいえ、大なり小なり考え直さないといけなくなる時は多くの場合来る -> 手戻りが発生する可能性はちゃんと受け入れる -> 「どうなったら考え直さないといけないか？」を意識する ・手戻りが発生してもコストを抑えられる構造を作ることができると便利
21. 設計の対象になるもの（開発対象だけじゃない！） ・開発対象（それはそう） ・ゴール ・時系列：計画ともいう ・やらないこと：やる範囲（責務）の明示 ・開発体制 ・組織構造 　…etc
22. 宇宙機の開発スタイル ・BBM（Bread Board Model）：初期段階の試作 ・EM（Engineering Model）：詳細は詰め切っていないが実機と同等の仕様の試作 ・FM（Flight Model）：実際に飛ばすやつ ・BBM -> EM -> FM と開発を進める ・必ずしもこの通りではない（PM とか PFM とか EFM とかも出てくる） ・規模が大きくとも（大きいからこそ）試作してみないとわからない、という性質が色濃く出ている ・（なお、予算や開発期間の都合で圧縮されることもよくある）
23. 設計の妥当性 ・設計の後には実装と運用がある ・あるある ・「ぼくのかんがえた最強の設計」→いやそれ開発/運用できないが...... ・やれないことはないけどめっちゃつらい ・妥当であるための前提が明らかではない -> 何が起きたら設計レベルから棄却するべきか？ ・鶏卵問題: やったことがないと設計が妥当かわからない
24. やったことがないと設計が妥当かわからない
25. 「やったことがあったら設計が妥当かわかる」？ ・７割ぐらいは真（なので経験者とのコネクションや臆せずに聞きにいくのが大事） ・偽なことも（多々）ある ・その経験者は妥当性をどう評価しているか？ ・あるある：やってみたらたまたまうまくいっただけ（正常性バイアス） ・重要なのは「なぜうまくいったか」「なぜうまくいかなかったか」の解釈 ・そもそも完全に同一のことを「やったことがある」わけではない ・ex: 「あなた」が「今」やる、という時点で状況は確実に少しは異なる ・経験者を過信せず議論できるとベスト
26. 気付いていること・理解していること Unknown Unknowns 知らないことを知らない Known Unknown 知らないと知っている Unknown Knowns 知っていると知らない Known Knowns 知っていると知っている 理解している 気 付 い て い る
27. 鶏卵問題：やったことがないと設計が妥当かわからない ・解決策1：経験者に聞く ・メリット：妥当性判断オラクルとして使える、経験するコストを削減できる ・デメリット：自分で妥当性を判断できなくなる（≒「枯れた技術」への信仰）、常に真とは限らない ・解決策2：妥当性を丁寧に分解して考える ・メリット：誰もやったことがなくてもできる、（分野によっては）体系的な理論や経験則がある ・デメリット：考えるのがものすごく大変、unknown-unknown には対処できない ・解決策3：高速に自分（のチーム）を「やったことがある」状態に持ち込む ・メリット：経験を積める、unknown-unknown を見つけられる ・デメリット：やるのが大変（ex: 金がかかる）、計画を立てるのが難しい、理解を得にくい
28. 高速に「やったことがある」状態に持ち込む ・やってみないとわからないことは本当に多い ・複雑なモノは特に unknown-unknown が多い ・事前の想定が良くも悪くも覆ることがある ・やったことを評価して次に活かす ・想定が覆る -> 手戻りが発生する ・前回の経験が古すぎると役に立たない ・高速に細かく Iteration を回す必要がある SpaceX (2012). System Engineering: A Traditional Discipline in a Non-Traditional Organization
29. じゃあ、やっていきましょう
30. 今回の HW 設計：要件定義 ・安価 ・組み立てが容易 ・再現性の確保 ・拡張性の確保 ・ローバーとして駆動できる ・サンプル採取のための機構 ・無線通信できる ・時系列データを保存できるストレージ ・Embedded Rust がこなれているマイコン ・事前学習期間中ははんだ付け不要 ・sksat が隙間時間で選定、設計できる（重要） sksat：HW 主担当ロール
31. 今回の HW 設計：技術選定 ・ローバー部分: 楽しい工作シリーズ No.1 クローラタイプ ・電源: 乾電池 ・マイコン: Raspberry Pi Pico（RP2040） ・センサ: 超音波、加速度、温湿度、照度、赤外線、カメラ ・無線通信: TWE-Lite（特小2.4GHz） ・データ保存: MicroSD ・基本的に DIP 部品のみ ・プリント基板（ピンソケット付けまくる、GPIO, i2c 引き出せる） sksat：HW 主担当ロール
32. 今回の HW 設計：基本設計 ・タミヤのクローラタイプを流用 ・二層化する 　・メイン層： ・ローバ駆動系 ・データハンドリング（保存・送信）系 　・ミッション層 ・アーム系 ・センサ系 タミヤの板 メイン基板 タミヤの板 進行方向 ギヤボックス ギヤボックス 超音波 （距離計測） 電池ボックス カメラ 赤外線 micro SD TWE- Lite 無線通信（2.4GHz） モータ ドライバ Pico sksat：HW 主担当ロール
33. 今回の HW 開発状況（2024/06/15） ・メイン基板 ・成立性確認用基板：開発完了 -> 基板の分割・２層構造の設計に確定　（+ sksat の基板設計能力習得） ・部品選定：完了 ・EM：開発完了（送付予定） ・FM：開発中（キャンプ当日使用） ・ミッション基板 ・部品選定：ほぼ完了（気持ちがあればまだ変えられる） ・EFM：開発中（キャンプ当日使用） ・to SW チーム：事前学習期間中の SW 開発は BBM でお願いします sksat：HW 主担当ロール
34. 今回の HW 設計：メイン基板 ・電源 ・乾電池 ・主電源とモータ電源のポートは分割 ・マイコン：Raspberry Pi Pico ・モータドライバ：DRV8833（２個） ・左右輪用とアーム用 ・無線通信機：TWE-Lite（特定省電力無線 2.4 GHz） ・親機接続ピン ・接続検出ピン ・拡張用２ピン sksat：HW 主担当ロール ・GPIO 引き出し用ピンソケット：BBM 的にも使用可能 ・ミッション基板間接続：UART ・i2c 引き出し用ピンソケット：拡張性のため ・超音波距離計：HC-SR04 ・ストレージ：microSD ・９軸センサ：BNO055 ・照度センサ：（３個）
35. 今回の HW 設計：ミッション基板 ・電源：乾電池 ・マイコン：Raspberry Pi Pico もしくは Seeduino XIAO RP2040（小型化のため検討中） ・メイン基板間接続：UART ・カメラ：選定中 ・赤外線アレイセンサ：AMMG8833 Grid-EYE ・温湿度センサ：DHT20 ・地磁気センサ：AE-BM1422AGMV ・サンプルアーム用測距センサ：GP2Y0A21YK sksat：HW 主担当ロール
36. 今回の HW 設計：論理的接続 sksat：HW 主担当ロール メイン基板 ミッション基板 モータドライバ モータドライバ 超音波距離計 ９軸センサ 無線機 microSD UART UART SPI I2C センサ類 I2C カメラ SPI 無線機 地上局 UART 無線（2.4GHz）
37. スモールスタートする ・今回の制約：みなさんの手元にモノが届くまで時間がかかる ・実際の宇宙開発でもこれはよくある（高いコンポを買うとか、契約や製造に時間がかかるとか） ・じゃあソフトウェアは最後の最後にならないと作り始められないのか？ ・そんなことを言っていると HW 側の事情に無限に振り回されて開発時間が無になる ・あるある：全体の計画を考える人に SW 開発の感覚が無くて最後に崩壊する ・ソフトウェアは ソフト なので、事前にやれることは結構ある
38. 今回事前に作れそうなところ ・メイン基板・ミッション基板の状態設計 ・メイン基板 - ミッション基板間の通信プロトコル ・メイン基板 - 地上局間の通信プロトコル ・取得した環境情報を microSD カードに保存するフォーマット ・地上局 とりあえず思い付くところから：Discord で話したり、Issue を立てたりしてみよう
39. ソフトウェアの柔軟性 ・ソフトウェアはレイヤー構造 ・重要な性質：インターフェースが同じであれば同じように扱える ・ex: 標準入出力やファイルは Windows でも macOS でも Linux でも同様に使える ・今回の場合、Rust で書いたロジックは実機にも移植できる（embedded Rust） ・no_std 対応なものであればライブラリも結構使える 移植 このインターフェースが 揃っていれば移植できる！！！
40. 下回りを雑に模擬する ・そうは言ってもモノが無いのにどう作り始めたらいいの？ ・まず考えたい/考えられるのは上のレイヤ（通信プロトコルとか、データフォーマットとか） ・上のレイヤだけの検討/実装をする時、実は下のレイヤはさほど重要ではない -> めちゃめちゃ雑に模擬しても開発は結構回る ・たとえば...... ・UART で通信するモノのプロトコル：標準出力に出して標準入力で受けてパースする ・取得した環境情報の microSD への保存：素朴にファイルに吐く ・インターフェースさえ揃えておけば、モノが来た時に下回りだけ実装すればくっつけられる（ソフト！）
41. 探査機自作ゼミ 02-組み込みシステム入門 sksat
42. 組み込みシステムって何
43. 組み込みシステム ・ようは「特定の目的のための汎用的じゃないシステム」 ・汎用的なやつ：お手元の PC など ・曖昧な語なのであんまり「組み込みだから～」みたいなことを言っても仕方ない ・わざわざ特定の目的のために専用のものを作っているので、色々と課題がありがち ・あるある：電力・空間・質量・予算などが限られている、信頼性が求められる ・電子レンジ作るのにゲーミングPCを突っ込むようなことはしない/できない
44. 普通のOSが無い、という不便さ ・たとえば、今回使う Raspberry Pi Pico ・RAM は 264KB、フラッシュメモリは2MB ・Windows などは動かない！！！（そもそもメモリに載らない） ・OS がやってくれていたことを自分でやる必要がある（or スペック的にできない） ・メモリ管理、HW の直接操作、...etc ・例えば「標準出力に “Hello, World!” と出力する」とかができない ・まずターミナルアプリが無い（画面も無い）
45. まずはLチカ ・Hello, World! できないならまず何をするのか ・LED をチカチカさせる ・Wokwi: https://wokwi.com/projects/401288015258586113 ・まずは Arduino（マイコン用フレームワーク）でやってみる ・言語としてはほぼC言語※1 ※1: 正確には勝手に Arduino.h が include される C++ だが、少なくとも初期設定は C++03 がちだし ちょっとヘンなC言語、ぐらいに思っておくのがちょうどよい
46. Lチカに必要なこと ・光らせる時：LED に電気が突っ込まれている ・消す時：LED に電気が突っ込まれていない ・↑の２つの状態を繰り返す（これでチカチカする） ・↑の２状態の間で待ち時間を設ける（Arduino では delay() が使えます） ・マイコンとはいっても人間に知覚不可能なレベルで高速に動作している（133MHz） →待ち時間を入れないと爆速でチカチカして人間が点滅を知覚できない（光り続けているように見える）
47. 結局何をやったのか？ ・HIGH とか LOW とかってなに？ ・ピンの電圧を設定した（HIGH：3.3V、LOW：0V） ・”HIGH” が何Vかはマイコンが何Vで動作しているかによる（ラズピコは3.3V） ・HIGH と LOW の２値が設定できるので、”digitalWrite” ・察せられること１：digital があるなら analog もあるのでは？ ・察せられること２：Write があるなら Read もあるのでは？
48. デジタル信号 ・HIGH と LOW の２値があると書いたが、世界はそんなに綺麗ではない ・実際は「だいたい3.3V」「だいたい0V」みたいなかんじになる ・もし完璧な HIGH と LOW を出せても、切り替わる瞬間は中途半端な電圧になる ・実際はしきい値を決めて「～Vより高いと HIGH」「～Vより低いと LOW」と定義する ・２値を定義できた → どちらかを１、どちらかを０とすると２進数として扱える → digitalWrite() して別のマイコンで digitalRead() したら２進数として情報を送ることができる！！！ José Luis Gálvez - Dibujo propio (Own drawing), CC 表示-継承 3.0
49. シリアル通信とパラレル通信 ・シリアル通信：１本の線で１bit ずつピコピコ送って読む ・実装がシンプル、配線数が少なくて済む ・SATA、UART、SPI、I2C など ・パラレル通信：１本の線で１bit が表現できるならN本線を並べたら Nbit 表現できるじゃん ・配線数は多くなるが一度にたくさんデータを送ることができる ・CPU の内部バス、ATA、PCI など FPGA入門ブログ ~初心者がSPI通信を設計してみた ~その１~ - 半導体事業 - マクニカ より引用
50. UART ・２本の線をそれぞれピコピコして通信する規格（シリアル通信） ・１対１での通信 ・送信側が TX※1、受信側が RX ・ピコピコする部分は UART コントローラがやってくれる ・使うときに２進数をガチャガチャやる必要は無い ・よく文字列の送受信に使われる ・デバッグに便利 ※1：つくばエクスプレスのことではない 画像は Reverse engineering UART to gain shell | by Shubham Golam | Medium より引用
51. ようやく Hello, World! ・UART があれば Hello, World! ができる！ ・Arduino だと Serial を使うだけ ・Wokwi でやってみよう
52. やってみよう ・シンプルな火星探査機（着陸機）のモデルを考えてみる ・電源：太陽光電池（角度が可変）と蓄電池 ・センサ：温度、照度 ・ドキュメントや example を見てみよう ・ミッション ・発電量を最大化する ・夜間は蓄電池をいたわる ・温度データを地球に送信
53. Wokwi で模擬してみる ・https://wokwi.com/projects/401283184277430273 ・温湿度センサ：時系列ログを取りたい ・とりあえず文字列で出力すれば OK（UART） ・サーボモータ：太陽光パネルの傾きを制御する ・照度センサ（左と右） ・明るさが分かる -> 発電量を推定できる ・２箇所の照度が分かる -> 太陽光の方向を推定できる
54. I2C ・シリアル通信の規格 ・SCL：通信のタイミング調整のための信号を流す（クロック） ・SDA：データ線 ・１対Nでの通信 ・「今からAさんと喋りまーす」みたいなかんじで通信する ・喋る相手を区別するための値として slave address（7bit）がある ・センサとの通信でよく使う（１個のマイコンとN個のセンサを繋げられる） ・Wokwi だと MPU6050 というジャイロ・加速度センサが使える（試してみよう！） Wikipedia: Cburnett - Own work made with Inkscape, CC BY-SA 3.0
55. Arduino ってなんなん ・「全部自分でやらないといけない」割には簡単では？ ・Arduino は簡単なモノを簡単（easy）に作るためのフレームワーク ・今回みたいな入門や、雑な試作にはよい ・裏側で何やってるかわからない（気になったら読んでみよう） ・性能を出せない（Arduino core やライブラリの実装のパフォーマンスは大抵かなり低い） ・C言語：効率のよい/安全性の高い抽象化ができない、ライブラリを使い回しにくい ・このゼミの主題は「組み込み Rust をやること」ではないので、適宜使って OK（Arduino に限らず） ・Rust だとこういうこともできるよ（+ Cだとこれはできないよ）、みたいな話は適宜します
56. 組み込み Rust ・Rust の利便性：rustup で一発で環境構築、cargo で一発でビルドとパッケージ管理 ・Rust のエコシステム：no_std な crate、ドキュメントの自動生成、組み込みコミュニティ （embedded-hal など） ・所有権：「どのメモリを誰が持っているか」を厳密にコンパイラがチェックしてくれる ・強い静的型 ・Option 型や Result 型：「エラーの時は -1 を返す」とはおさらば ・代数的データ型：「複数種類の型/関数を void* で抽象化」とはおさらば ・ゼロコスト抽象化：↑のようなコードにも最適化が効く ・相互運用性：C言語のライブラリを持ってきてくっつけられる
57. 組み込み Rust のはじめかた ・ラズピコ + wokwi + Rust のテンプレ: sksat/pico-wokwi-playground/hello-blinky-rs ・たぶん、Arduino より行数が多くてギョッとするはず ・これは Arduino（core）が裏で勝手にやっていたことが少し表に出てきているから ・もちろん大半はライブラリの中にある → 重要なので裏側に隠しすぎたらよくないところ ・ライブラリのリポジトリの example（rp-pico）を見ながらガチャガチャ弄ってみよう ・ライブラリのドキュメント（rp2040-hal など）やデータシート（ラズピコ、RP2040）を見てみよう ・The Embedded Rust Book を見てみよう ・sksat や他のゼミの講師に聞いてみよう（#rust でもいいかも）
58. 探査機自作ゼミ 03-通信プロトコル sksat
59. 通信の開始 ・受信側は「どこから通信が始まるか」をどうにかして認識しないといけない ・途中から読んでしまったらめちゃくちゃになる ・「通信を始めます」というメッセージを決めておく ・低レイヤでの戦略：通信開始をお知らせする信号線を生やす、専用のチップで処理する ・ソフトウェアでの戦略： ・短いメッセージだけで頑張る：AとBだけだったら AAAAAABBBBABBBBBABAAA とかでも OK ・ヘッダを用意する：ヘッダを”S” として、SOKSHELLOSNGSHIGH みたいにやる
60. フレーミング ・フレーム：データの流れから取り出したい１発の通信（ヘッダ込み） ・ペイロード：１発の通信の中身（「コマンド」とか「テレメトリ」とか） ・ヘッダさえあればフレームをちゃんと切り出せる？ 　　Q．ペイロード中にたまたまヘッダと同じデータが入ったらどうする？ A1．ペイロード中ではエスケープする：SHOGES\S\TARTSFUGA A2．ヘッダにペイロード長を入れる：S4HOGES5STARTS4FUGA 　　Q．（S5）S1A RT S4FUGA -> A．～RT まではよくわからんのであきらめる
61. データは破損する ・基本的にあらゆるデータは通信経路上で壊れる 　　・電気的・電磁的なノイズ、信号が弱くて区別できなかった、接続不良、バグ、放射線、...... ・ヘッダとペイロード長があるだけ -> 壊れたことが分からない 　　・HOGE と HOGA に違う意味を持たせて使っていたら挙動も壊れうる ・誤り検知：parity bit、チェックサム、 CRCなど 　　・壊れてることが分かったデータはどうする？ -> 諦める ・誤り訂正：多少壊れても本当の値を取り出せるように符号化する
62. 誤りに対するトレードオフ ・なんもしない：壊れた時のリスクはあるが、実装はラク ・誤り検知して読み飛ばす：壊れた時はデータを捨てないといけないが、実装や計算量は小さい 　　・アルゴリズムによっては検知できない誤りパターンがある 　　　<-> たくさん検知できるやつはムズい／ダルい ・誤り訂正してがんばる：ある程度壊れてもデータを回復できるが、実装や計算量は大きい 　　・アルゴリズムによっては（ry 　　　<-> たくさん訂正できるやつは（ry
63. 再送 ・壊れてたらまた送ればいいじゃん ・TCP とか ・通信コストが安く、再送によるレイテンシが許容できる時に取れる手段 ・動画の配信とか：一つ前のデータを訂正する意味が薄い -> UDP ・深宇宙との通信とか：通信コストが十分高い -> 誤り訂正がペイする
64. 通信に関わるコスト ・通信経路の特性上のコスト ・通信モジュールの電力、光速（が遅くて困る）、通信経路の長さ ・通信データの処理コスト ・割り込み、フレーミング、誤り検知／訂正 ・メモリ確保：大きなバッファが必要になりがち
65. 宇宙機の通信 ・通信コストが大きい：通信機会が少ない（地球などで影になる）、レイテンシが大きい（深宇宙） ・送信と受信が非対称な構造 ・無線機や周波数から別なことも 　　・送信：かなり確実に届いてほしい・データ量は受信と比べて小さい 　　・受信：できるだけたくさんのデータが欲しい
66. コマンドの設計 ・要求 　　・何が起きるかわからない 　　・どのようなロジックで動かしたくなるか事前に分からない ・手札 　　・細かい単位のコマンドをたくさん用意しておく 　　・コマンドを組み合わせることで表現力を確保する（シェルコマンドみたいな）
67. テレメトリの設計 ・要求 　　・通信機会が限られ、帯域は小さいが、意味のあるデータをできるだけ落としたい 　　・宇宙機が持つデータにはたくさん種類がある 　　・何が起きているかをテレメトリのみから判断しなければならない（判断できるデータが必要） ・手札 　　・存続のために重要な情報は高頻度で常に落とす（HK：House Keeping） 　　・その時の目的によって落とすデータを変える 　　・過去のデータを落とせるようにする
68. 探査機自作ゼミ 04-実機で遊ぶ sksat
69. 送った物 ・タミヤのキット ・NCボックス ・構造部材：ユニバーサルプレート、モーター、電池ボックス、スペーサー、ナット ・main board ・DIP 部品セット ・便利ワイヤセット ・電子部品セット
70. レンタル品 ・Raspberry Pi 3B ・Raspberry Pi 3B 電源 ・ブレッドボード（小） ラズパイは GPIO が生えてる便利な Linux マシンとして自由に使ってください（ex: 地上局）
71. main board 超音波センサ 照度センサ （接続先） モータ （接続先） モータドライバ （接続先） 主電源 （接続先） モータ電源 （接続先） ラズピコ （接続先） リセットスイッチ BNO055 （接続先） microSD スロット （接続先） 親機接続ピン 無線機 （接続先） mission board 接続 詳しい接続は 回路図などを参照
72. DIP 部品セット ・足が生えてるやつ ・スポンジに刺してある Raspberry Pi Pico x3 MicroSD カード DIP 化キット BNO055 モータドライバ （DRV8833）
73. 便利ワイヤセット
74. 電子部品セット（1） 照度センサ NJL7502L 無線機 TWELITE UART アンテナ カメラ （可視光・高解像度） ArduCAM MEGA 3MP 赤外線アレイセンサ AMG8833 Grid-EYE
75. 電子部品セット（2） USBシリアル変換基板 （CH340） ロジックアナライザ （8ch, 24MHz） microSD カード
76. まずはLチカ ・Wokwi でやったやつ：https://github.com/sksat/pico-wokwi-playground ・最初はボード上の LED（GP25）を光らせてみる
77. 実機への書き込み（UF2） ・必要な物：Raspberry Pi Pico１個 ・Pico のボタンを押した状態で USB ケーブルを繋ぐ ・ファイラから「RPI-RP2」みたいなデバイスが見える ・USB メモリのノリで uf2 ファイルを D&D すれば書き込み完了
78. UART 出力を見たい ・見たい！！！ ・現代の PC にはシリアルポートが生えてない（残念！） ・UART は UART なので、直接 PC からやりとりできない！！！ ・Raspberry Pi 3B は直接やりとりできるので便利 ・でも PC から見たい -> USB シリアル変換基板を使う ・PC から直接シリアルデバイスとして見えるようになる ・Windows の場合：COM ポートとして見える ・Linux などの場合：デバイスファイル（ex: /dev/ttyUSB0）として見える
79. ・必要な物：Pico、USBシリアル変換、ジャンパワイヤ（メス-メス） ・TX と RX を配線する ・USB シリアル変換を PC に繋ぐ UART 出力を見る TX RX やってみよう 　　・出力が見えている状態でそれぞれの線を抜き刺し 　　・入力
80. 実機への書き込み（SWD） ・必要な物：Pico（デバッガ用）、Pico（ターゲット）、ジャンパワイヤ（メス-メス） ・Pico をデバッガにする（rust-dap を焼く） ・デバッガからターゲットに配線する（ピン配置）
81. probe-rs での書き込み ・probe-rs list でデバッガを認識しているか確認 ・probe-rs run –chip RP2040 ./target/thumbv6m-none-eabi/debug/pico-wokwi-playground
82. 実機で cargo run！ ・実は .cargo/config.toml に probe-rs のコマンドが書いてある ・cargo run でそのまま走る
83. VSCode（probe-rs）でデバッグ ・VSCode に probe-rs のエディタ拡張 を入れる ・https://probe.rs/docs/getting-started/probe-setup/ を見てセットアップ 　　・Linux の場合、udev rule が必要
84. キャンプ当日までにやっておいてほしいこと ・タミヤのキットの組み立て ・２階建てにするので、最低限キャタピラ部分だけで OK ・UF2 でのファームウェア書き込みができる ・どれか一つのラズピコをデバッガ（rust-dap）にしてファームウェア書き込みができる ・USBシリアル変換を使って PC から UART への入出力をしてみる ・適当なコンポ（センサでもモータでも）のデータシートを読んで実際に使ってみる
85. 諸注意 ・レンタル品は後で事務局に返さないといけない ・DIP 部品のピンヘッダを曲げないように ・特にラズピコはブレッドボードから抜く時に注意！ ・タミヤのキットの組み立てでグリスを使用する ・機械油等にアレルギーがある場合は手袋をすること
86. S17 探査機自作ゼミ 当日資料 sksat
87. 講師自己紹介 ・sksat（えすけーさっと） ・ArkEdge Space Inc. コンピューティング基盤部　/　筑波大学情報科学類（休学中） ・宇宙オタク -> パソコンオタク -> 宇宙パソコン野郎 ・やってた: OS、x86エミュレータ、数値計算、小型ハイブリッドロケット、自宅サーバ ・やってる: （超小型人工衛星の）OS/Framework、シミュレーション基盤、CI/CD、姿勢制御系、社内システム ・趣味: 自宅サーバのオーバーエンジニアリング、VRChat ・気持ちがあるところ: 実在する複雑性の咀嚼と妥当な対処の案組み ↖これ中指じゃないです
88. このゼミの目的 複雑なものづくりへの 立ち向かい方を体感してほしい
89. このゼミの目的 複雑なものづくりへの 立ち向かい方を体感してほしい 考えることが多い どう手札を用意するか 0 -> 1 やってみなくちゃ わからない
90. 複雑なシステム：宇宙機 ・デプロイ先が過酷（真空、宇宙放射線、熱収支、電力収支、...） ・デプロイまでも過酷（ロケットによる振動・音響） ・非修理系 ・考えることが多い ・ex: 機構設計、熱設計、電力設計、ソフトウェア設計、地上局、運用方法、どう開発するか ・しかも、これらが相互に影響する！！！
91. 気付いていること・理解していること Unknown Unknowns 知らないことを知らない Known Unknown 知らないと知っている Unknown Knowns 知っていると知らない Known Knowns 知っていると知っている 理解している 気 付 い て い る
92. 気付いていること・理解していること Unknown Unknowns 知らないことを知らない Known Unknown 知らないと知っている Unknown Knowns 知っていると知らない Known Knowns 知っていると知っている 理解している 気 付 い て い る どんどん気付く どんどん知る
93. 「雑」なコミュニケーションをしよう ・雑に発言をしよう ・思い付いたり気になったりしたことを失ってしまうのはもったいない 立場がどうとか仕事がどうとか全く関係なく、我々は今後行うべき行動について何が正解か、何も分かっていませ ん。全然わかっていません。 だからこそ互いに雑な発言を投げつけ合いうなかで、分かっている事実とわかってい ない領域を整理して、真に自分たちが取り組むべき問題と解決の方向を見いだすのは、現実的な手段です。 雑な認識からはじめましょう。雑に言い合いましょう。雑な発言を許容しましょう。
94. 高速に「やったことがある」状態に持ち込む ・やってみないとわからないことは本当に多い ・複雑なモノは特に unknown-unknown が多い ・事前の想定が良くも悪くも覆ることがある ・やったことを評価して次に活かす ・想定が覆る -> 手戻りが発生する ・前回の経験が古すぎると役に立たない ・高速に細かく Iteration を回す必要がある SpaceX (2012). System Engineering: A Traditional Discipline in a Non-Traditional Organization
95. 何がなんだかわからん ・複雑なミッション ・複雑な組織 ・複雑なシステム ・複雑な ToDo ・複雑なバグ ・複雑なエラー
96. 何がなんだかわからん ・複雑なミッション ・複雑な組織 ・複雑なシステム ・複雑な ToDo ・複雑なバグ ・複雑なエラー 解きほぐす 大きな方針 大きな方針 大きな方針
97. 事実を観察せよ！ ・推測しすぎない ・事象Aが起きている時、まず「たぶんBで〜」と言っていないか？ ・事実関係を区別してコミュニケーションしよう ・起きている事象／事象が発生する前提条件／前提条件を満たす仮説／事象の仮説 ・事実をできるだけ観測せよ！ ・導線は導通してる？信号は流れてる？マイコンは連続動作してる？変数の値は？ ・手札（観測手段）の例：テスター、ロジックアナライザ、lldb、defmt、USBシリアル変換、...
98. シンプルに作る ・複雑な目的や状況 -> すぐに解決も複雑になる ・「アレをああしてこうするとコレもソレもできる！！！」 ・それって結局なにをどう解決してるんだっけ？ ・最適化の法則：「まだするな！」 ・認知負荷が大きい -> コンテキストスイッチのコストが大きくなる ・ex: 次の日、別の人に託す、「次」のイテレーション、開発 -> 運用　のときに困る ・複雑なことも、まずはじめはシンプルに ・ex: ブレッドボードでやる、ユニットテスト、 Rules of Optimization: Rule 1: Don't do it. Rule 2 (for experts only): Don't do it yet.
99. やることが......やることが多い......！！ ・時間が無い！！！ ・ex: セキュキャンは正味丸3日！ ・扱うモノがたくさんある！！！ ・ex: たくさんのセンサ ・焦れば焦るほど効率が下がる（意外と盲点） https://alu.jp/series/金田一少年の事件簿外伝_犯人たちの事件簿 /crop/uxivvfocbWTUJ3NAWw2w
100. 「やること」は DAG ・「やること」は１次元のリストではない！！！ ・それぞれに依存関係がある ・依存が被らない実行経路が発生する／作ることができる →複数人で並列実行できる ・ex: B->C と B->D は同時にできる ・実行中にノードや依存関係を増やすこともできる（タスクの分割／解像度が上がった） ・並列度の高いタスク分割ができると、チームの「実行効率」を高められる ・こういうグラフに所要時間を描くアローダイアグラム（PRET 図）というものもある
101. 「やらないこと」を決める ・「やること」「やらなきゃいけないこと」を決めるのは簡単 ・やるのはとても大変 ・同時にあれもこれもやっていると混乱する ・コンテキストスイッチのコストが大きい ・強い気持ちで「何をやらないか」を決める ・注意：「やらない」にも「金輪際やらない」「余裕があったらやる」のようなグラデーションがある
102. 2日目以降用
103. デプロイ ・†現地†にデプロイしてみよう ・まだできてない？ものづくりはいつだってそう！！ ・やってみなくちゃわからない！！！ ・準備／撤収にも時間がかかります（意外と盲点。気をつけよう。）
104. 成果報告 ・注意：個人の成果報告とゼミとしての成果報告は別 ・個人の成果報告（修了認定用）：スライド提出 2024/08/15 21:00（JST） まで ・PDF, pptx, Google Slide のいずれか ・コース別成果発表：スライド提出 2024/08/16 08:00（JST）まで ・Google Slide ・1ゼミあたり3分
105. スライドの作り方 ・まずファイルを作る！１枚目を生やす！！！ ・見る人／読む人はコンテキストを共有していない ・このゼミはどんなゼミだったっけ？なんのために何をしたっけ？どうしたら何ができたっけ？ ・ストーリー構成を考える ・起承転結があると伝わりやすい ・目次を考えながらスライドの枚数だけ増やす（中身は期限までに埋めればいい） ・画像／動画を使おう（百聞は一見にしかず）