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

by sksat

Slide 1

Slide 1 text

S17探査機自作ゼミオリエンテーション sksat

Slide 2

Slide 2 text

今日のゴール・ミニマム: 自己紹介 + 雑談しつつお互いを知る・フル: これ以降のスライド・エクストラ: ソフトウェアエンジニア向け宇宙開発入門

Slide 3

Slide 3 text

自己紹介タイム・話すことに迷ったら見る欄・呼び方（本名でもハンドルネームでも可）・興味範囲や今までやってきたことなど・得意な技術や分野・今はあまり得意じゃないけどできるようになりたいこと・今話してない人が見る欄・気になったことや知らないことがあったら聞いてみよう

Slide 4

Slide 4 text

講師自己紹介・sksat（えすけーさっと）・ArkEdge Space Inc. コンピューティング基盤部　/　筑波大学情報科学類（休学中）・宇宙オタク -> パソコンオタク -> 宇宙パソコン野郎・やってた: OS、x86エミュレータ、数値計算、小型ハイブリッドロケット、自宅サーバ・やってる: （超小型人工衛星の）OS/Framework、シミュレーション基盤、CI/CD、姿勢制御系、社内システム・趣味: 自宅サーバのオーバーエンジニアリング、VRChat ・気持ちがあるところ: 実在する複雑性の咀嚼と妥当な対処の案組み ↖これ中指じゃないです

Slide 5

Slide 5 text

このゼミの目的複雑なものづくりへの立ち向かい方を体感してほしい

Slide 6

Slide 6 text

このゼミの目的複雑なものづくりへの立ち向かい方を体感してほしい考えることが多いどう手札を用意するか 0 -> 1 やってみなくちゃわからない

Slide 7

Slide 7 text

注意事項: このゼミでの sksat のふるまい・sksat は立場上は「講師」ですが、別に偉い人ではありません・sksat は「答えを知っている人」ではありません（「答え」はまだ存在しないかもしれません！）・sksat は以下のようにふるまいます・セキュリティ・キャンプ2024の講師: ゼミとしての連絡や、当日の物品の用意などをします。・調整相手: 親機や地上局ハードウェアの担当者です。・探査機のハードウェア開発の主担当: 時間などの都合上 HW はある程度準備しています。・便利な経験者: 宇宙開発や組み込み Rust の経験者です。叩くと便利な情報が出がちです。・座学的な話をする時もどちらかというとこのふるまいと思ってください

Slide 8

Slide 8 text

時間を有効活用しよう・重要: セキュリティ・キャンプは長いようで短い・非同期コミュニケーションを有効活用しよう・sksat を使い倒そう

Slide 9

Slide 9 text

「雑」なコミュニケーションをしよう・雑に発言をしよう・思い付いたり気になったりしたことを失ってしまうのはもったいない立場がどうとか仕事がどうとか全く関係なく、我々は今後行うべき行動について何が正解か、何も分かっていません。全然わかっていません。だからこそ互いに雑な発言を投げつけ合いうなかで、分かっている事実とわかっていない領域を整理して、真に自分たちが取り組むべき問題と解決の方向を見いだすのは、現実的な手段です。雑な認識からはじめましょう。雑に言い合いましょう。雑な発言を許容しましょう。

Slide 10

Slide 10 text

ゼミの進め方・週１ぐらいで同期的な会話の場を設けます・まずはこの時間を決めましょう・座学的なこと、ディスカッション、ペアプロなど

Slide 11

Slide 11 text

開発の準備・GitHub organization ・要確認: みなさん GitHub 使えますか？（規約など的に）・Rust 開発環境・rustup ・VSCode ・エディタの強制はしません（なんなら僕も普段は Neovim です）・それはそれとして最近はかなり便利なので、知っておくと手札が増えます

Slide 12

Slide 12 text

ミッション・惑星探査機に相乗りする子機（のローバー）・目的: 環境情報取得、将来の探査のための技術実証、サンプル・リターン Image credit: Go Miyazaki Photo: © CNSA/CLEP

Slide 13

Slide 13 text

次回予告「設計」をしよう

Slide 14

Slide 14 text

宿題（？）・探査機の大雑把な設計を考えてみよう・自律的に動作してデータを貯める、親機・地上にデータを送信する、地上からコマンドを受けて動作を変える、サンプルを親機に持ち帰る・これらを実現するためにどのような機能が必要か・機能をどう分割するか

Slide 15

Slide 15 text

S17探査機自作ゼミ 01-「設計」をしよう sksat

Slide 16

Slide 16 text

まずは大雑把にやってみる・エイヤで色々言ってみる（ブレスト）（雑に！）・目的から深堀りする・どんな環境情報が取得できるとうれしそう？・どんな技術は「次」にも役立つ？・どうやってサンプルを採取する？・どうやって親機までサンプルを持ち帰る？・技術（手札）から深堀りする・どんなマイコン・センサ・アクチュエータが使えそう？

Slide 17

Slide 17 text

惑星探査機を設計してみよう・目的・環境情報取得・将来の探査のための技術実証・サンプルリターン Photo: © CNSA/CLEP

Slide 18

Slide 18 text

そもそも「設計」とは？

Slide 19

Slide 19 text

「設計」とは？「どうやるか」を考え、言語化していく営み

Slide 20

Slide 20 text

「どうやるか」を考え続ける・一度やったらハイそれで終わり、なんてことはない・設計レベルからのやり直しは大変（手戻りが大きい）・もう実装していたらそれも作り直しになるかもしれない・とはいえ、大なり小なり考え直さないといけなくなる時は多くの場合来る -> 手戻りが発生する可能性はちゃんと受け入れる -> 「どうなったら考え直さないといけないか？」を意識する・手戻りが発生してもコストを抑えられる構造を作ることができると便利

Slide 21

Slide 21 text

設計の対象になるもの（開発対象だけじゃない！）・開発対象（それはそう）・ゴール・時系列：計画ともいう・やらないこと：やる範囲（責務）の明示・開発体制・組織構造　…etc

Slide 22

Slide 22 text

宇宙機の開発スタイル・BBM（Bread Board Model）：初期段階の試作・EM（Engineering Model）：詳細は詰め切っていないが実機と同等の仕様の試作・FM（Flight Model）：実際に飛ばすやつ・BBM -> EM -> FM と開発を進める・必ずしもこの通りではない（PM とか PFM とか EFM とかも出てくる）・規模が大きくとも（大きいからこそ）試作してみないとわからない、という性質が色濃く出ている・（なお、予算や開発期間の都合で圧縮されることもよくある）

Slide 23

Slide 23 text

設計の妥当性・設計の後には実装と運用がある・あるある・「ぼくのかんがえた最強の設計」→いやそれ開発/運用できないが...... ・やれないことはないけどめっちゃつらい・妥当であるための前提が明らかではない -> 何が起きたら設計レベルから棄却するべきか？・鶏卵問題: やったことがないと設計が妥当かわからない

Slide 24

Slide 24 text

やったことがないと設計が妥当かわからない

Slide 25

Slide 25 text

「やったことがあったら設計が妥当かわかる」？・７割ぐらいは真（なので経験者とのコネクションや臆せずに聞きにいくのが大事）・偽なことも（多々）ある・その経験者は妥当性をどう評価しているか？・あるある：やってみたらたまたまうまくいっただけ（正常性バイアス）・重要なのは「なぜうまくいったか」「なぜうまくいかなかったか」の解釈・そもそも完全に同一のことを「やったことがある」わけではない・ex: 「あなた」が「今」やる、という時点で状況は確実に少しは異なる・経験者を過信せず議論できるとベスト

Slide 26

Slide 26 text

気付いていること・理解していること Unknown Unknowns 知らないことを知らない Known Unknown 知らないと知っている Unknown Knowns 知っていると知らない Known Knowns 知っていると知っている理解している気付いている

Slide 27

Slide 27 text

鶏卵問題：やったことがないと設計が妥当かわからない・解決策1：経験者に聞く・メリット：妥当性判断オラクルとして使える、経験するコストを削減できる・デメリット：自分で妥当性を判断できなくなる（≒「枯れた技術」への信仰）、常に真とは限らない・解決策2：妥当性を丁寧に分解して考える・メリット：誰もやったことがなくてもできる、（分野によっては）体系的な理論や経験則がある・デメリット：考えるのがものすごく大変、unknown-unknown には対処できない・解決策3：高速に自分（のチーム）を「やったことがある」状態に持ち込む・メリット：経験を積める、unknown-unknown を見つけられる・デメリット：やるのが大変（ex: 金がかかる）、計画を立てるのが難しい、理解を得にくい

Slide 28

Slide 28 text

高速に「やったことがある」状態に持ち込む・やってみないとわからないことは本当に多い・複雑なモノは特に unknown-unknown が多い・事前の想定が良くも悪くも覆ることがある・やったことを評価して次に活かす・想定が覆る -> 手戻りが発生する・前回の経験が古すぎると役に立たない・高速に細かく Iteration を回す必要がある SpaceX (2012). System Engineering: A Traditional Discipline in a Non-Traditional Organization

Slide 29

Slide 29 text

じゃあ、やっていきましょう

Slide 30

Slide 30 text

今回の HW 設計：要件定義・安価・組み立てが容易・再現性の確保・拡張性の確保・ローバーとして駆動できる・サンプル採取のための機構・無線通信できる・時系列データを保存できるストレージ・Embedded Rust がこなれているマイコン・事前学習期間中ははんだ付け不要・sksat が隙間時間で選定、設計できる（重要） sksat：HW 主担当ロール

Slide 31

Slide 31 text

今回の HW 設計：技術選定・ローバー部分: 楽しい工作シリーズ No.1 クローラタイプ・電源: 乾電池・マイコン: Raspberry Pi Pico（RP2040）・センサ: 超音波、加速度、温湿度、照度、赤外線、カメラ・無線通信: TWE-Lite（特小2.4GHz）・データ保存: MicroSD ・基本的に DIP 部品のみ・プリント基板（ピンソケット付けまくる、GPIO, i2c 引き出せる） sksat：HW 主担当ロール

Slide 32

Slide 32 text

今回の HW 設計：基本設計・タミヤのクローラタイプを流用・二層化する　・メイン層：・ローバ駆動系・データハンドリング（保存・送信）系　・ミッション層・アーム系・センサ系タミヤの板メイン基板タミヤの板進行方向ギヤボックスギヤボックス超音波（距離計測）電池ボックスカメラ赤外線 micro SD TWE- Lite 無線通信（2.4GHz）モータドライバ Pico sksat：HW 主担当ロール

Slide 33

Slide 33 text

今回の HW 開発状況（2024/06/15）・メイン基板・成立性確認用基板：開発完了 -> 基板の分割・２層構造の設計に確定　（+ sksat の基板設計能力習得）・部品選定：完了・EM：開発完了（送付予定）・FM：開発中（キャンプ当日使用）・ミッション基板・部品選定：ほぼ完了（気持ちがあればまだ変えられる）・EFM：開発中（キャンプ当日使用）・to SW チーム：事前学習期間中の SW 開発は BBM でお願いします sksat：HW 主担当ロール

Slide 34

Slide 34 text

今回の HW 設計：メイン基板・電源・乾電池・主電源とモータ電源のポートは分割・マイコン：Raspberry Pi Pico ・モータドライバ：DRV8833（２個）・左右輪用とアーム用・無線通信機：TWE-Lite（特定省電力無線 2.4 GHz）・親機接続ピン・接続検出ピン・拡張用２ピン sksat：HW 主担当ロール・GPIO 引き出し用ピンソケット：BBM 的にも使用可能・ミッション基板間接続：UART ・i2c 引き出し用ピンソケット：拡張性のため・超音波距離計：HC-SR04 ・ストレージ：microSD ・９軸センサ：BNO055 ・照度センサ：（３個）

Slide 35

Slide 35 text

今回の HW 設計：ミッション基板・電源：乾電池・マイコン：Raspberry Pi Pico もしくは Seeduino XIAO RP2040（小型化のため検討中）・メイン基板間接続：UART ・カメラ：選定中・赤外線アレイセンサ：AMMG8833 Grid-EYE ・温湿度センサ：DHT20 ・地磁気センサ：AE-BM1422AGMV ・サンプルアーム用測距センサ：GP2Y0A21YK sksat：HW 主担当ロール

Slide 36

Slide 36 text

今回の HW 設計：論理的接続 sksat：HW 主担当ロールメイン基板ミッション基板モータドライバモータドライバ超音波距離計９軸センサ無線機 microSD UART UART SPI I2C センサ類 I2C カメラ SPI 無線機地上局 UART 無線（2.4GHz）

Slide 37

Slide 37 text

スモールスタートする・今回の制約：みなさんの手元にモノが届くまで時間がかかる・実際の宇宙開発でもこれはよくある（高いコンポを買うとか、契約や製造に時間がかかるとか）・じゃあソフトウェアは最後の最後にならないと作り始められないのか？・そんなことを言っていると HW 側の事情に無限に振り回されて開発時間が無になる・あるある：全体の計画を考える人に SW 開発の感覚が無くて最後に崩壊する・ソフトウェアはソフトなので、事前にやれることは結構ある

Slide 38

Slide 38 text

今回事前に作れそうなところ・メイン基板・ミッション基板の状態設計・メイン基板 - ミッション基板間の通信プロトコル・メイン基板 - 地上局間の通信プロトコル・取得した環境情報を microSD カードに保存するフォーマット・地上局とりあえず思い付くところから：Discord で話したり、Issue を立てたりしてみよう

Slide 39

Slide 39 text

ソフトウェアの柔軟性・ソフトウェアはレイヤー構造・重要な性質：インターフェースが同じであれば同じように扱える・ex: 標準入出力やファイルは Windows でも macOS でも Linux でも同様に使える・今回の場合、Rust で書いたロジックは実機にも移植できる（embedded Rust）・no_std 対応なものであればライブラリも結構使える移植このインターフェースが揃っていれば移植できる！！！

Slide 40

Slide 40 text

下回りを雑に模擬する・そうは言ってもモノが無いのにどう作り始めたらいいの？・まず考えたい/考えられるのは上のレイヤ（通信プロトコルとか、データフォーマットとか）・上のレイヤだけの検討/実装をする時、実は下のレイヤはさほど重要ではない -> めちゃめちゃ雑に模擬しても開発は結構回る・たとえば...... ・UART で通信するモノのプロトコル：標準出力に出して標準入力で受けてパースする・取得した環境情報の microSD への保存：素朴にファイルに吐く・インターフェースさえ揃えておけば、モノが来た時に下回りだけ実装すればくっつけられる（ソフト！）

Slide 41

Slide 41 text

探査機自作ゼミ 02-組み込みシステム入門 sksat

Slide 42

Slide 42 text

組み込みシステムって何

Slide 43

Slide 43 text

組み込みシステム・ようは「特定の目的のための汎用的じゃないシステム」・汎用的なやつ：お手元の PC など・曖昧な語なのであんまり「組み込みだから～」みたいなことを言っても仕方ない・わざわざ特定の目的のために専用のものを作っているので、色々と課題がありがち・あるある：電力・空間・質量・予算などが限られている、信頼性が求められる・電子レンジ作るのにゲーミングPCを突っ込むようなことはしない/できない

Slide 44

Slide 44 text

普通のOSが無い、という不便さ・たとえば、今回使う Raspberry Pi Pico ・RAM は 264KB、フラッシュメモリは2MB ・Windows などは動かない！！！（そもそもメモリに載らない）・OS がやってくれていたことを自分でやる必要がある（or スペック的にできない）・メモリ管理、HW の直接操作、...etc ・例えば「標準出力に “Hello, World!” と出力する」とかができない・まずターミナルアプリが無い（画面も無い）

Slide 45

Slide 45 text

まずはLチカ・Hello, World! できないならまず何をするのか・LED をチカチカさせる・Wokwi: https://wokwi.com/projects/401288015258586113 ・まずは Arduino（マイコン用フレームワーク）でやってみる・言語としてはほぼC言語※1 ※1: 正確には勝手に Arduino.h が include される C++ だが、少なくとも初期設定は C++03 がちだしちょっとヘンなC言語、ぐらいに思っておくのがちょうどよい

Slide 46

Slide 46 text

Lチカに必要なこと・光らせる時：LED に電気が突っ込まれている・消す時：LED に電気が突っ込まれていない・↑の２つの状態を繰り返す（これでチカチカする）・↑の２状態の間で待ち時間を設ける（Arduino では delay() が使えます）・マイコンとはいっても人間に知覚不可能なレベルで高速に動作している（133MHz） →待ち時間を入れないと爆速でチカチカして人間が点滅を知覚できない（光り続けているように見える）

Slide 47

Slide 47 text

結局何をやったのか？・HIGH とか LOW とかってなに？・ピンの電圧を設定した（HIGH：3.3V、LOW：0V）・”HIGH” が何Vかはマイコンが何Vで動作しているかによる（ラズピコは3.3V）・HIGH と LOW の２値が設定できるので、”digitalWrite” ・察せられること１：digital があるなら analog もあるのでは？・察せられること２：Write があるなら Read もあるのでは？

Slide 48

Slide 48 text

デジタル信号・HIGH と LOW の２値があると書いたが、世界はそんなに綺麗ではない・実際は「だいたい3.3V」「だいたい0V」みたいなかんじになる・もし完璧な HIGH と LOW を出せても、切り替わる瞬間は中途半端な電圧になる・実際はしきい値を決めて「～Vより高いと HIGH」「～Vより低いと LOW」と定義する・２値を定義できた → どちらかを１、どちらかを０とすると２進数として扱える → digitalWrite() して別のマイコンで digitalRead() したら２進数として情報を送ることができる！！！ José Luis Gálvez - Dibujo propio (Own drawing), CC 表示-継承 3.0

Slide 49

Slide 49 text

シリアル通信とパラレル通信・シリアル通信：１本の線で１bit ずつピコピコ送って読む・実装がシンプル、配線数が少なくて済む・SATA、UART、SPI、I2C など・パラレル通信：１本の線で１bit が表現できるならN本線を並べたら Nbit 表現できるじゃん・配線数は多くなるが一度にたくさんデータを送ることができる・CPU の内部バス、ATA、PCI など FPGA入門ブログ ~初心者がSPI通信を設計してみた ~その１~ - 半導体事業 - マクニカより引用

Slide 50

Slide 50 text

UART ・２本の線をそれぞれピコピコして通信する規格（シリアル通信）・１対１での通信・送信側が TX※1、受信側が RX ・ピコピコする部分は UART コントローラがやってくれる・使うときに２進数をガチャガチャやる必要は無い・よく文字列の送受信に使われる・デバッグに便利 ※1：つくばエクスプレスのことではない画像は Reverse engineering UART to gain shell | by Shubham Golam | Medium より引用

Slide 51

Slide 51 text

ようやく Hello, World! ・UART があれば Hello, World! ができる！・Arduino だと Serial を使うだけ・Wokwi でやってみよう

Slide 52

Slide 52 text

やってみよう・シンプルな火星探査機（着陸機）のモデルを考えてみる・電源：太陽光電池（角度が可変）と蓄電池・センサ：温度、照度・ドキュメントや example を見てみよう・ミッション・発電量を最大化する・夜間は蓄電池をいたわる・温度データを地球に送信

Slide 53

Slide 53 text

Wokwi で模擬してみる・https://wokwi.com/projects/401283184277430273 ・温湿度センサ：時系列ログを取りたい・とりあえず文字列で出力すれば OK（UART）・サーボモータ：太陽光パネルの傾きを制御する・照度センサ（左と右）・明るさが分かる -> 発電量を推定できる・２箇所の照度が分かる -> 太陽光の方向を推定できる

Slide 54

Slide 54 text

I2C ・シリアル通信の規格・SCL：通信のタイミング調整のための信号を流す（クロック）・SDA：データ線・１対Nでの通信・「今からAさんと喋りまーす」みたいなかんじで通信する・喋る相手を区別するための値として slave address（7bit）がある・センサとの通信でよく使う（１個のマイコンとN個のセンサを繋げられる）・Wokwi だと MPU6050 というジャイロ・加速度センサが使える（試してみよう！） Wikipedia: Cburnett - Own work made with Inkscape, CC BY-SA 3.0

Slide 55

Slide 55 text

Arduino ってなんなん・「全部自分でやらないといけない」割には簡単では？・Arduino は簡単なモノを簡単（easy）に作るためのフレームワーク・今回みたいな入門や、雑な試作にはよい・裏側で何やってるかわからない（気になったら読んでみよう）・性能を出せない（Arduino core やライブラリの実装のパフォーマンスは大抵かなり低い）・C言語：効率のよい/安全性の高い抽象化ができない、ライブラリを使い回しにくい・このゼミの主題は「組み込み Rust をやること」ではないので、適宜使って OK（Arduino に限らず）・Rust だとこういうこともできるよ（+ Cだとこれはできないよ）、みたいな話は適宜します

Slide 56

Slide 56 text

組み込み Rust ・Rust の利便性：rustup で一発で環境構築、cargo で一発でビルドとパッケージ管理・Rust のエコシステム：no_std な crate、ドキュメントの自動生成、組み込みコミュニティ（embedded-hal など）・所有権：「どのメモリを誰が持っているか」を厳密にコンパイラがチェックしてくれる・強い静的型・Option 型や Result 型：「エラーの時は -1 を返す」とはおさらば・代数的データ型：「複数種類の型/関数を void* で抽象化」とはおさらば・ゼロコスト抽象化：↑のようなコードにも最適化が効く・相互運用性：C言語のライブラリを持ってきてくっつけられる

Slide 57

Slide 57 text

組み込み 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 でもいいかも）

Slide 58

Slide 58 text

探査機自作ゼミ 03-通信プロトコル sksat

Slide 59

Slide 59 text

通信の開始・受信側は「どこから通信が始まるか」をどうにかして認識しないといけない・途中から読んでしまったらめちゃくちゃになる・「通信を始めます」というメッセージを決めておく・低レイヤでの戦略：通信開始をお知らせする信号線を生やす、専用のチップで処理する・ソフトウェアでの戦略：・短いメッセージだけで頑張る：AとBだけだったら AAAAAABBBBABBBBBABAAA とかでも OK ・ヘッダを用意する：ヘッダを”S” として、SOKSHELLOSNGSHIGH みたいにやる

Slide 60

Slide 60 text

フレーミング・フレーム：データの流れから取り出したい１発の通信（ヘッダ込み）・ペイロード：１発の通信の中身（「コマンド」とか「テレメトリ」とか）・ヘッダさえあればフレームをちゃんと切り出せる？　　Q．ペイロード中にたまたまヘッダと同じデータが入ったらどうする？ A1．ペイロード中ではエスケープする：SHOGES\S\TARTSFUGA A2．ヘッダにペイロード長を入れる：S4HOGES5STARTS4FUGA 　　Q．（S5）S1A RT S4FUGA -> A．～RT まではよくわからんのであきらめる

Slide 61

Slide 61 text

データは破損する・基本的にあらゆるデータは通信経路上で壊れる　　・電気的・電磁的なノイズ、信号が弱くて区別できなかった、接続不良、バグ、放射線、...... ・ヘッダとペイロード長があるだけ -> 壊れたことが分からない　　・HOGE と HOGA に違う意味を持たせて使っていたら挙動も壊れうる・誤り検知：parity bit、チェックサム、 CRCなど　　・壊れてることが分かったデータはどうする？ -> 諦める・誤り訂正：多少壊れても本当の値を取り出せるように符号化する

Slide 62

Slide 62 text

誤りに対するトレードオフ・なんもしない：壊れた時のリスクはあるが、実装はラク・誤り検知して読み飛ばす：壊れた時はデータを捨てないといけないが、実装や計算量は小さい　　・アルゴリズムによっては検知できない誤りパターンがある　　　<-> たくさん検知できるやつはムズい／ダルい・誤り訂正してがんばる：ある程度壊れてもデータを回復できるが、実装や計算量は大きい　　・アルゴリズムによっては（ry 　　　<-> たくさん訂正できるやつは（ry

Slide 63

Slide 63 text

再送・壊れてたらまた送ればいいじゃん・TCP とか・通信コストが安く、再送によるレイテンシが許容できる時に取れる手段・動画の配信とか：一つ前のデータを訂正する意味が薄い -> UDP ・深宇宙との通信とか：通信コストが十分高い -> 誤り訂正がペイする

Slide 64

Slide 64 text

通信に関わるコスト・通信経路の特性上のコスト・通信モジュールの電力、光速（が遅くて困る）、通信経路の長さ・通信データの処理コスト・割り込み、フレーミング、誤り検知／訂正・メモリ確保：大きなバッファが必要になりがち

Slide 65

Slide 65 text

宇宙機の通信・通信コストが大きい：通信機会が少ない（地球などで影になる）、レイテンシが大きい（深宇宙）・送信と受信が非対称な構造・無線機や周波数から別なことも　　・送信：かなり確実に届いてほしい・データ量は受信と比べて小さい　　・受信：できるだけたくさんのデータが欲しい

Slide 66

Slide 66 text

コマンドの設計・要求　　・何が起きるかわからない　　・どのようなロジックで動かしたくなるか事前に分からない・手札　　・細かい単位のコマンドをたくさん用意しておく　　・コマンドを組み合わせることで表現力を確保する（シェルコマンドみたいな）

Slide 67

Slide 67 text

テレメトリの設計・要求　　・通信機会が限られ、帯域は小さいが、意味のあるデータをできるだけ落としたい　　・宇宙機が持つデータにはたくさん種類がある　　・何が起きているかをテレメトリのみから判断しなければならない（判断できるデータが必要）・手札　　・存続のために重要な情報は高頻度で常に落とす（HK：House Keeping）　　・その時の目的によって落とすデータを変える　　・過去のデータを落とせるようにする

Slide 68

Slide 68 text

探査機自作ゼミ 04-実機で遊ぶ sksat

Slide 69

Slide 69 text

送った物・タミヤのキット・NCボックス・構造部材：ユニバーサルプレート、モーター、電池ボックス、スペーサー、ナット・main board ・DIP 部品セット・便利ワイヤセット・電子部品セット

Slide 70

Slide 70 text

レンタル品・Raspberry Pi 3B ・Raspberry Pi 3B 電源・ブレッドボード（小）ラズパイは GPIO が生えてる便利な Linux マシンとして自由に使ってください（ex: 地上局）

Slide 71

Slide 71 text

main board 超音波センサ照度センサ（接続先）モータ（接続先）モータドライバ（接続先）主電源（接続先）モータ電源（接続先）ラズピコ（接続先）リセットスイッチ BNO055 （接続先） microSD スロット（接続先）親機接続ピン無線機（接続先） mission board 接続詳しい接続は回路図などを参照

Slide 72

Slide 72 text

DIP 部品セット・足が生えてるやつ・スポンジに刺してある Raspberry Pi Pico x3 MicroSD カード DIP 化キット BNO055 モータドライバ（DRV8833）

Slide 73

Slide 73 text

便利ワイヤセット

Slide 74

Slide 74 text

電子部品セット（1）照度センサ NJL7502L 無線機 TWELITE UART アンテナカメラ（可視光・高解像度） ArduCAM MEGA 3MP 赤外線アレイセンサ AMG8833 Grid-EYE

Slide 75

Slide 75 text

電子部品セット（2） USBシリアル変換基板（CH340）ロジックアナライザ（8ch, 24MHz） microSD カード

Slide 76

Slide 76 text

まずはLチカ・Wokwi でやったやつ：https://github.com/sksat/pico-wokwi-playground ・最初はボード上の LED（GP25）を光らせてみる

Slide 77

Slide 77 text

実機への書き込み（UF2）・必要な物：Raspberry Pi Pico１個・Pico のボタンを押した状態で USB ケーブルを繋ぐ・ファイラから「RPI-RP2」みたいなデバイスが見える・USB メモリのノリで uf2 ファイルを D&D すれば書き込み完了

Slide 78

Slide 78 text

UART 出力を見たい・見たい！！！・現代の PC にはシリアルポートが生えてない（残念！）・UART は UART なので、直接 PC からやりとりできない！！！・Raspberry Pi 3B は直接やりとりできるので便利・でも PC から見たい -> USB シリアル変換基板を使う・PC から直接シリアルデバイスとして見えるようになる・Windows の場合：COM ポートとして見える・Linux などの場合：デバイスファイル（ex: /dev/ttyUSB0）として見える

Slide 79

Slide 79 text

・必要な物：Pico、USBシリアル変換、ジャンパワイヤ（メス-メス）・TX と RX を配線する・USB シリアル変換を PC に繋ぐ UART 出力を見る TX RX やってみよう　　・出力が見えている状態でそれぞれの線を抜き刺し　　・入力

Slide 80

Slide 80 text

実機への書き込み（SWD）・必要な物：Pico（デバッガ用）、Pico（ターゲット）、ジャンパワイヤ（メス-メス）・Pico をデバッガにする（rust-dap を焼く）・デバッガからターゲットに配線する（ピン配置）

Slide 81

Slide 81 text

probe-rs での書き込み・probe-rs list でデバッガを認識しているか確認・probe-rs run –chip RP2040 ./target/thumbv6m-none-eabi/debug/pico-wokwi-playground

Slide 82

Slide 82 text

実機で cargo run！・実は .cargo/conﬁg.toml に probe-rs のコマンドが書いてある・cargo run でそのまま走る

Slide 83

Slide 83 text

VSCode（probe-rs）でデバッグ・VSCode に probe-rs のエディタ拡張を入れる・https://probe.rs/docs/getting-started/probe-setup/ を見てセットアップ　　・Linux の場合、udev rule が必要

Slide 84

Slide 84 text

キャンプ当日までにやっておいてほしいこと・タミヤのキットの組み立て・２階建てにするので、最低限キャタピラ部分だけで OK ・UF2 でのファームウェア書き込みができる・どれか一つのラズピコをデバッガ（rust-dap）にしてファームウェア書き込みができる・USBシリアル変換を使って PC から UART への入出力をしてみる・適当なコンポ（センサでもモータでも）のデータシートを読んで実際に使ってみる

Slide 85

Slide 85 text

諸注意・レンタル品は後で事務局に返さないといけない・DIP 部品のピンヘッダを曲げないように・特にラズピコはブレッドボードから抜く時に注意！・タミヤのキットの組み立てでグリスを使用する・機械油等にアレルギーがある場合は手袋をすること

Slide 86

Slide 86 text

S17 探査機自作ゼミ当日資料 sksat

Slide 87

Slide 87 text

Slide 88

Slide 88 text

このゼミの目的複雑なものづくりへの立ち向かい方を体感してほしい

Slide 89

Slide 89 text

このゼミの目的複雑なものづくりへの立ち向かい方を体感してほしい考えることが多いどう手札を用意するか 0 -> 1 やってみなくちゃわからない

Slide 90

Slide 90 text

複雑なシステム：宇宙機・デプロイ先が過酷（真空、宇宙放射線、熱収支、電力収支、...）・デプロイまでも過酷（ロケットによる振動・音響）・非修理系・考えることが多い・ex: 機構設計、熱設計、電力設計、ソフトウェア設計、地上局、運用方法、どう開発するか・しかも、これらが相互に影響する！！！

Slide 91

Slide 91 text

Slide 92

Slide 92 text

気付いていること・理解していること Unknown Unknowns 知らないことを知らない Known Unknown 知らないと知っている Unknown Knowns 知っていると知らない Known Knowns 知っていると知っている理解している気付いているどんどん気付くどんどん知る

Slide 93

Slide 93 text

Slide 94

Slide 94 text

Slide 95

Slide 95 text

何がなんだかわからん・複雑なミッション・複雑な組織・複雑なシステム・複雑な ToDo ・複雑なバグ・複雑なエラー

Slide 96

Slide 96 text

何がなんだかわからん・複雑なミッション・複雑な組織・複雑なシステム・複雑な ToDo ・複雑なバグ・複雑なエラー解きほぐす大きな方針大きな方針大きな方針

Slide 97

Slide 97 text

事実を観察せよ！・推測しすぎない・事象Aが起きている時、まず「たぶんBで〜」と言っていないか？・事実関係を区別してコミュニケーションしよう・起きている事象／事象が発生する前提条件／前提条件を満たす仮説／事象の仮説・事実をできるだけ観測せよ！・導線は導通してる？信号は流れてる？マイコンは連続動作してる？変数の値は？・手札（観測手段）の例：テスター、ロジックアナライザ、lldb、defmt、USBシリアル変換、...

Slide 98

Slide 98 text

シンプルに作る・複雑な目的や状況 -> すぐに解決も複雑になる・「アレをああしてこうするとコレもソレもできる！！！」・それって結局なにをどう解決してるんだっけ？・最適化の法則：「まだするな！」・認知負荷が大きい -> コンテキストスイッチのコストが大きくなる・ex: 次の日、別の人に託す、「次」のイテレーション、開発 -> 運用　のときに困る・複雑なことも、まずはじめはシンプルに・ex: ブレッドボードでやる、ユニットテスト、 Rules of Optimization: Rule 1: Don't do it. Rule 2 (for experts only): Don't do it yet.

Slide 99

Slide 99 text

やることが......やることが多い......！！・時間が無い！！！・ex: セキュキャンは正味丸3日！・扱うモノがたくさんある！！！・ex: たくさんのセンサ・焦れば焦るほど効率が下がる（意外と盲点） https://alu.jp/series/金田一少年の事件簿外伝_犯人たちの事件簿 /crop/uxivvfocbWTUJ3NAWw2w

Slide 100

Slide 100 text

「やること」は DAG ・「やること」は１次元のリストではない！！！・それぞれに依存関係がある・依存が被らない実行経路が発生する／作ることができる →複数人で並列実行できる・ex: B->C と B->D は同時にできる・実行中にノードや依存関係を増やすこともできる（タスクの分割／解像度が上がった）・並列度の高いタスク分割ができると、チームの「実行効率」を高められる・こういうグラフに所要時間を描くアローダイアグラム（PRET 図）というものもある

Slide 101

Slide 101 text

「やらないこと」を決める・「やること」「やらなきゃいけないこと」を決めるのは簡単・やるのはとても大変・同時にあれもこれもやっていると混乱する・コンテキストスイッチのコストが大きい・強い気持ちで「何をやらないか」を決める・注意：「やらない」にも「金輪際やらない」「余裕があったらやる」のようなグラデーションがある

Slide 102

Slide 102 text

2日目以降用

Slide 103

Slide 103 text

デプロイ・†現地†にデプロイしてみよう・まだできてない？ものづくりはいつだってそう！！・やってみなくちゃわからない！！！・準備／撤収にも時間がかかります（意外と盲点。気をつけよう。）

Slide 104

Slide 104 text

成果報告・注意：個人の成果報告とゼミとしての成果報告は別・個人の成果報告（修了認定用）：スライド提出 2024/08/15 21:00（JST）まで・PDF, pptx, Google Slide のいずれか・コース別成果発表：スライド提出 2024/08/16 08:00（JST）まで・Google Slide ・1ゼミあたり3分

Slide 105

Slide 105 text

スライドの作り方・まずファイルを作る！１枚目を生やす！！！・見る人／読む人はコンテキストを共有していない・このゼミはどんなゼミだったっけ？なんのために何をしたっけ？どうしたら何ができたっけ？・ストーリー構成を考える・起承転結があると伝わりやすい・目次を考えながらスライドの枚数だけ増やす（中身は期限までに埋めればいい）・画像／動画を使おう（百聞は一見にしかず）