探査機自作ゼミ応募課題晒し_セキュリティ・キャンプ全国大会2024
はじめに
こんにちはこんにちは、Chisenonです！
この記事は、セキュリティ・キャンプ全国大会に参加してきので、その伝統文化である 応募課題晒し をやってみたものです。
目的
-
あーしのように「プログラミングを主軸にしてない人間」でも、参加出来る事を知ってもらいたい！
-
今後参加しようと考えている人に、少しでも自信を持ってチャレンジしてもらえる助けになれば良いなぁ～
という目的で作成しております。
⚠️ 必ずしも正しいことが書いてあるとは限りませんので、ご了承ください...
P.S.
やばい結局公開するのがゼミ内で最後になってしまったぁ...
(もう半年くらい前だぞ！ごめんなさい)
(あけてしまいましたおめでとうございます！許してください...)
セキュリティ・キャンプ全国大会2024 公式サイト
そもそも、探査機自作ゼミって何？？？
今回あーしは、セキュリティ・キャンプ全国大会2024 開発コース 「S17_探査機自作ゼミ」に参加してきました！
こちらが探査機自作ゼミの概要なのですが...
うわああああぁぁぁぁ～長いっ！！！
ですが、重要な事はちゃんと最初に書いてあって...
一緒に探査機を作ってみませんか？
このゼミでは惑星探査機の開発を題材として、複雑なシステム開発 への向き合い方を、実際に手を動かしながら考えます。
ということで、探査機自作ゼミでは、
複雑なシステム(惑星探査機)のチーム開発 を行っていきます。
ちなみに、実際の講義で使われていたスライドのまとめは sksat先生 が公開しているので興味がある方はぜひ見てみてください！
セキュリティ・キャンプ全国大会2024 S17 探査機自作ゼミ 事前学習・当日資料
同ゼミ受講生の記事へのリンク
同ゼミ、他受講生さんの書いた記事へのリンクを貼っておきます
気になる方はぜひ見てみてください！
- 標準偏差さん
- ohnoさん
探査機自作ゼミ_応募課題
実際の応募課題2024はこちらです。
応募課題
はじめに・評価について
この中にも結構重要な事が書いてあって、
評価は加点方式で行います．
あなたが考えた道筋やあなたの熱意を重視します．
不正確なことを書いても減点するようなことはしません．
とあるように、今まで得てきた知見から生み出される 自分の考えや熱意 をどれだけ相手に伝えられるかが大事です。
自分もそうなのですが、「正確なことを書かなきゃ！」とか「見当違いの事を書いたら落とされる...」という考えが先に来て、ビビって応募を先延ばしにしがちです...
実際、選考終了に公開された竹迫講師主査から次回のセキュリティ・キャンプ全国大会を目指す方へのメッセージにもあるように、
わかる・わからないで考えるのではなく、手を動かして調べて、こう調べてみた、これを試してみたという、手を動かした結果を書いてみましょう。
正解を答えようとするのでなく、そうした手を動かした結果をアピールするものと考えて書いてみましょう。
そうすれば、わからないので何も書けないということは無くなるでしょう。
そのうえで、その手を動かした結果を、ブログなどに書いたり、どこかで発表してみたりして、アウトプットしてみましょう。
とにかく手を動かして、○○についてココまで調べてみたが、××の部分がわからなかった。ということを書くのでも問題ないと思います。
結果も大事ですけど、その間でどのような過程を踏んだかも同じくらい重要になってきますね！
Q1
問題
回答
（未公開情報もバレるので、見出し＋α にさせてください...）
チーム開発（大会参加系）
- Lego Mindstorms NXT を使用した演劇ロボット
- Lego Mindstorms EV3 を使用した災害救助ロボット
- Lego Mindstorms EV3 を使用した宇宙エレベーター
- Web サイトの脆弱性診断用クローラーの作成
個人開発・ハッカソン参加・その他
- SecHack365 採択
- AI 学習用画像収集ソフト_icra-collecter（初めての公開アプリケーション作成）
- Live2D に興味が出て自分でセットアップしてみる
- 3D モデリング
- 低レイヤプログラミング
- 自作OSやってみて、低レイヤ興味あります的な話
(Q1だけで5000文字くらい書いてたらしい、マジか...)
コメント(解説)
出ました恒例(ゼミによっては無いかも)の実績紹介？(イキリオタクコーナー)です。
あーしは今まで、プログラミングではなくハードウェア系に長い事触れてきたので、その経験や趣味で作った公開しているものを、 実際に動くもの(動画とか) と一緒に紹介しました。
意識した事としては、ゼミがグループ開発という事もあり自分よりも優秀なプログラマーが絶対に来てくれるという想定で、
「ハードウェア寄りだがなんとなくプログラムも少しはやれる人間だぞ！」という事がフンワリ伝わるものを選んで書いたつもりです。
みなさんも今までやって来た事をバシバシ書くといいと思います！
(減点されないって書いてあるんだし、情報はあって損しないよねという気持ち)
Q2
問題
回答
今までの経験で一番印象に残っている壁は、「レイヤの違い」です。
私は今までハードウェアの設計を長くやっており、プログラミングには苦手意識を持ち他の人に任せっきりでした。
その結果、中学生の時にロボットを作っているときプログラマとの間で方向性の違いや喧嘩が多々あり、偏った視点が問題であることを身をもって体験しました。
そのため、高校に入学する際にこの壁を少しでも低くできるようプログラミングを始めました。Arduino での電子工作に興味を持ちはじめ、自分でプログラムを作成する１人での開発を始めました。
どうにか壁が低くなると期待していましたが、そう簡単にはいかず経験の問題だと改めて感じました。
このような経験から、色々なことに挑戦し手を動かすことでいずれこの壁もどうにかなるだろうと考え、今もなおプログラミングを習慣化させて続けています。また最近は、さまざまな経験を積むことで周囲に優秀な人が増え、その人々とのコミュニケーションを円滑にするためにもこの壁を低くできるよう日々努力しています。
現状としては、「何もわからない」から「チョットわかる」程度には以前より成長できてると思います！
コメント(解説)
この問いに関しては、セキュリティ・キャンプ全国大会後も自走して開発を続けられるかということが聞かれてるのではないかと思います。
事前学習期間も結構な時間がある(十分にあるとは言っていない)ため、一人でもある程度進めて行けるかや、キャンプ終了後に経験を生かして成長できるかなどを事前に見極めるための質問だと思います。
進捗がいまいち出ないときの状況分析・対応などの力を持ち合わせているかみたいなことの確認なのでしょうかね？
まぁ、なんでも手を動かしてみないと始まらないので、どんどん壁にぶち当たってぶっ壊していきましょう！
Q3
問題
回答
最近特に便利だと感じているのは ChatGPT などの LLM（大規模言語モデル）です。
なのでコレを便利なものとして紹介しようと思いましたが、ここではあえてそう言った有名なものではなく、「リードベンダー」という製品を便利なモノとして紹介したいと思います。リードベンダーは、電子工作に用いられる抵抗などの電子部品の足を曲げる専用の工具です。
この工具に初めて出会ったのは高校生の時で、部活で電子工作をしているときでした。
ブレッドボードにパーツを乗せる際、抵抗やトランジスタの足の間隔が目視ではうまく決まらず、毎回時間がかかり苦労していました。
そんな時に学校の先生が教えてくれたのが、このリードベンダーでした。これを使うと、毎回決まった間隔でパーツを配置することができ、足を曲げる速度もブレッドボードにパーツを取り付けるのも一瞬で完了します。
当時感動した私は自分でも購入してしまうほど感動し便利だと感じました。確かにこれは基板実装を自分でするようなごく少数の人にしか必要ないかもしれません。
しかしそのような少数の誰かの些細な悩みを解決するニッチな道具が私はとても大好きです。
コメント(解説)
これに関しては、「sksat先生が知らない」かつ「便利なもの」を紹介できたらいいなと思いリードベンダーを紹介しました。
講師の先生が課題を読んでいて「おっ！？」と、その時一瞬でも記憶に残るような文章を書こうと思って課題をやっていたりしなかったり？？？
Q3-1（発展課題）
問題
回答
自分が昔から思っていて実践しているのは、「とにかく形にして残す」ことです。
学校に行っているときや、食事をしているとき、お風呂に入っているときなど、日常のさまざまな瞬間で何か不便なことに出会ったり、アイデアが浮かんだりします。
そんなアイディアを思っただけで終わらせず、スマホでも PC でも紙でも何でもいいからメモして形に残すことが重要だと考えています。そうすると、今は時間や力がなくてできなかったことでも、次にそれを見た自分は、できるようになっているかもしれません。
そのためにも、とにかくアイデアを形に残して消えないようにする事が、「誰かの役に立つ物を作る」の第一歩になるかもしれないと私は考えています。しかし、これにも壁があります。
自分の場合アイデアはたくさん生まれるけれども、一人だとどうしても実装方法わからないことが多く、調べているうちにどんどん時間がかかってしまい、結果ほかのことを初めてしまいます。
その壁の高さを低くするためにも、今回のようなハッカソンで色々な世界を見てきた活気のある人と一緒に何かを作り、刺激を受け技術を吸収したいと考えています。後者の自分で作った便利なものという問いに関しては、Q1 の個人開発で紹介した「AI 学習用画像収集ソフト」が当てはまると思います。
これは高校時代、画像認識を一緒に勉強している友人から「検索エンジンで学習用の画像を一個一個集めるのが面倒だ」という悩みを聞き、生まれました。今考えれば、画像収集のシステムはたくさんあります。
しかし当時の自分は友人のためにも、自分の経験のためにも、助けてあげたいと思い試行錯誤しながら作り上げました。個人的に便利なものを作るためにはアイディアの新規性よりも、とにかく手を動かしたくさん作って試行錯誤することが一番の近道なのではないかと考えています。
また集団にばかり目を配るのではなく、”個”の悩みを解決するための「便利」も絶対に忘れてはいけないと考えています。
コメント(解説)
ここでは結構自分のモノづくりに対しての思想が漏れ出していますね...
みなさんもとりあえずメモに残す 習慣 をつけておくと、いざという時にもしかしたら役に立つかもしれませんよ！？！？！？
（マジでネタが多いに越したことは無い！！！）
Q4
問題
回答
この問題に関して、ソフトウェアとハードウェアの二つに分けて、それぞれのメリット・デメリットについて述べていきたいと思います。
1. ソフトウェア以外（ハードウェア）で古い技術を使用する場合
メリット
問題として提示されているマイコンやハードウェアは、すでに長い歴史があり枯れ切っているため、これまでの実績から宇宙空間での温度差や放射線に耐える性能が十分に証明されています。
また、現状で動作しているものもその枯れた技術を使用して作成されているものが多いため、それらとの互換性や連携が取りやすいという利点もあります。
ほかにも、古い技術に関しては機能が限定されているため最新のものに比べたらコストを抑えられるという利点もあります。宇宙空間という何が起こるかわからない環境において、余分な機能は極力減らしたいと私なら考えます。
デメリット
ハードウェアなどの形あるものには寿命があり、いずれ必ず壊れます。
また、古い技術を使っているということは、現在の最新技術よりも性能が劣っていることも意味しています。
調べたところによると、国際宇宙ステーションも 2030 年頃には役目を終えるという話を見つけました。また、宇宙ステーションも場所によっては修復困難な欠損があるという話もありました。では小型の CPU に関しては、より高性能なものを宇宙空間に持ち込めばよいという意見もあります。しかし宇宙空間では真空や極端な温度変化など、CPU を破壊しうる現象が多数存在します。
例えば「銀河宇宙線」と呼ばれる放射線が CPU に衝突すると、ビットが反転する「Single Event Upset（SEU）」という現象が発生します。正直これを聞いただけではあまりイメージやどこが問題なのか分かりませんでした。
しかし最近、任天堂のゲーム「スーパーマリオ 64」にて、その宇宙線によるビット反転を利用たバグ技が話題になりました。
目に見えない放射線ひとつで計算が狂い、最悪の場合命が脅かされることを考えると、簡単に新しい技術を導入することも躊躇してしまいます。以上のことから、ソフトウェア以外（ハードウェア）に関しては、コストや信頼性などの点で、現時点では枯れた技術を使用するしかないという結論に至りました。
2. ソフトウェアで古い技術を使用する場合
メリット
ソフトウェアに関しても、C89 や XML などの言語は昔から使用されており、これまでの宇宙空間でのミッションを成功させてきたという実績の信頼性が非常に大きいと思います。
また、これらの言語は他のプログラミング言語に比べてポインタやメモリ管理が細かく制御できる利点があります。さらに、実行速度が速いことも大きなメリットだといえます。
宇宙空間という何が起こるか分からない環境では、可能な限り人間があらかじめ細かく制御できることが重要であるため、これらが古い技術が選ばれる理由の一つと考えられます。デメリット
まず古い技術を使用する際には開発者に高い技術力が求められます。
メモリ管理や低レイヤのデバッグを限られたハードウェアリソースの中で効率的に処理を実装する必要があるからです。
また、枯れた技術特有の保守の難しさも問題だと思います。
例えば、金融機関のシステムで使用されている「COBOL」は、その長年の運用で蓄積された膨大なシステムを他の技術で作り直すことがほぼ不可能なほど複雑に膨れ上がっています。C 言語に関してはRustにはあるガベージコレクションがないため、メモリリークの問題も考慮する必要があります。
また、マルチスレッドプログラミングを直接サポートしていないため複雑な処理を行う際には自前で対応する必要があります。
XML に関しては、どうしても大規模なシステムになると冗長になってしまい、通信帯域や CPU リソースが限られている宇宙開発でそのような大量のデータをやり取りするのは効率がいいとは言えないと私は考えます。以上の結果から、ソフトウェアに関して古い技術を使用することは過去の実績から安全であるかもしれませんが、保守性が低下し、結果として人間が扱いにくいものになる可能性があります。
これらの機能面や保守面の脆弱性は今後の宇宙開発において致命的なリスク担ってくる可能性があるため、ソフトウェアに関しては最新の技術を採用する方が良いのではないかと私は考えます。と、以上のようにいろいろと述べてきましたが、近年の宇宙開発や衛星開発には民間企業もチャレンジするようになってきています。
そのため、クラウドファンディングなどで資金を集め様々な技術にチャレンジしている事例も見受けられます。
個人的には、NASA などの大規模プロジェクトに比べて周囲からの責任が軽いことから、いつまでも枯れた技術とその信頼に頼らず、ソフトウェアやハードウェアにおいて新しい技術にどんどん挑戦していくのは非常に良いことだと考えています。
コメント(解説)
ココに関しては、無難にソフトウェアとハードウェアのメリット・デメリットを挙げて、最後に自分の意見を述べるという形で回答しました。（教科書通りのやつ）
あーしも普段から枯れた技術を好きで使っている人間であり、そろそろ新しい技術に手を出そうかと思っていた時期なのでいろいろ考えが深まる良い課題でした。
Q4-1（発展課題）
問題
回答
現在、私も Rust を学んでいるので、sksat 先生の意見には非常に賛同できます。
以前は C 言語でモノづくりをしていましたが、そのたびに「まだそんな時代遅れの言語を使ってるの？」と複数のエンジニア（友人）に言われました。
そのため、Rust の学習を始め、今も気の向くままにいろいろと学習しながら作っています。ここでは、そんな自分が思った疑問を少し残そうと思います。ぜひ回答を聞かせていただきたいです。
Q1. 安定している技術があるのにもかかわらず、あえて新しいことに挑戦する先生なりの理由は何でしょうか？
衛星開発には多くの人と大きな資金が関わってきます。
さらに、宇宙開発全体も急いで進めるものではないと私は考えています。
そういった状況下で、現在しっかり動作しているシステムを受け継ぐのではなく、あえて新しい技術に挑戦する必要があるのでしょうか？（私は新しい技術に挑戦することに賛成の立場です。理由は、ある程度限界が見えている枯れた技術よりも、これからの可能性がある新しい技術に賭けてみたいからです。）
Q2. sksat 先生は衛星開発に限らず、宇宙開発全体で枯れた技術ではなく新しい技術に変えていく必要があると思われますか？また、どのような理由で Rust を選ばれたのでしょうか？
確かに、枯れた技術にも新しい技術にもそれぞれ良い部分が存在します。
しかし、そのまま枯れた技術を鼓する流れに身を任せ続けると、COBOL の二の舞になる気がします。
現状、いくつかの民間宇宙開発企業が Ada や Rust、Go などを使用してチャレンジしているという記事を読みました。私は前述のとおり、今のうちから新しい技術に置き換えていくべきと考えますが、実際に開発をされている現場の意見を聞いてみたいと思いました。
コメント(解説)
え～、質問に質問を返すという事をしていますね(ヤバすぎる...)
でも今の自分と同じ状況(新しい技術を学ぶか、枯れた技術を続けるか悩んでいる)であったので、結構自分の思っている素直な質問をぶつけたつもりではいます。
コーユーちょっと捻った事をしてみるのもいいかもしれませんよ！？！？！？
Q5
問題
回答
現在、実際に行われているのは、UDP 通信のようにできるだけ多くのデータをたくさん送信するという手法らしい。
この技術を今後も使用していくにあたって、送信される情報の内容をより密にする、つまり情報の圧縮率を高めることが現在できる対策として考えられています。ここから考えられる現状の最大の課題は、データの通信回数と量が限定されていることです。
これは地球から衛星までの距離が離れてしまうからである。この問題へのアプローチとして、「スペースデブリ」の利用を利用した方法を提案します。
以前からスペースデブリの増加が問題になっていることは認識しており、何かに利用できるのではないかと考えていました。
具体的な手法としては、不要になった宇宙機や衛星などのスペースデブリを電波リピータとして活用することです。
これらのスペースデブリを宇宙に放置せず、通信の中継や増幅を行うための電波塔として配置します。
これにより、通信回数や量の制限を克服し、宇宙通信の効率を向上させることができます。つまり、デブリの存在に有用な理由を作るということです。
具体的には、金属製のスペースデブリに電波リピータの機能を持ったマイコンを取り付け、地球からの通信を中継するという案です。
役目を終えた衛星なども、電波の送受信ができる機能が当然備わってるためそれをリピーターとして再利用できるのではないか？？？
細かい設計について詳しくは決まっていませんが、最低限必要なのはアンテナ、送信・受信機、電源、マイコンだと考えています。
電源問題に関しては、太陽光などの光を利用したいと考えています。
例えば、消費電力が100mW程度のマイコンの場合は、
必要な太陽光面積 = 消費電力 / (太陽光の照度 × 太陽電池の効率)
で求められるため、効率20%の太陽光発電をする場合地球上で発電する計算をしたとしても
必要な太陽光面積 = 0.1W / (1000W/m² × 0.20) = 0.0005 m² = 5 cm²
となるため太陽光の照度 5 cm²ほどあればいいのではないかと思われます。
ここに関しては調べた情報なので正確なものではないかもしれません（そんなにちっさいので動くのか？？？）次に、送信・受信機ですが、衛星に比べて増幅機はそれほど難しい構造ではないため、壊れにくいと思います。ここについてはどの距離までカバーするかも含めてさらに詳しく調べる必要があります。
宇宙空間でも同様の結果になるかはわかりませんが、地下にある電波時計時間を修正する専用のリピータはいくつか発見することができました。
そのためこの技術に似たものを応用していけばいいのではないかと思いました。最後に、マイコンについては、Raspberry Pi シリーズでも動作するのではないかと考えています。
宇宙空間でも動作する「Astro PI」という製品も存在しており、Raspberry Pi Zero W が宇宙空間で動作した実績もあります。
リピーターがどれだけの距離をカバーするかによっても変わってくると思いますが、そういった小型のマイコンを搭載しデブリをアンテナとして利用しているものをいくつか浮遊させて中継局として機能させることを考えました。個人的に良いと思っているのは、このリピーターは１か所にとどまる必要がない点です。
もともとはスペースデブリのため、流れに任せて移動すれば、将来どこかで役に立つかもしれません。つまりは、人間が生きていくために水が必要であるのと同じように、宇宙空間では電波が必要です。
確かにコストはかかるかもしれませんが、何事も最初はインフラを整備するところから始めるべきだと考えています。正直宇宙空間は分からないことが多すぎるため漠然とした内容になってしまいましたが、現実味を持たせるにはさらに専門的な知識を持っている人と考える必要があると改めて感じました。
コメント(解説)
文末表現が統一されていないっ！！！(結構最後まで悩んで内容をいじってた気がする...)
正直、この問題が一番考えていて面白かったです。
現実では圧縮方法や伝送方法をどうにかするタイプの手法がとられているらしいですが、ここでは 自分からの視点 で好きに書こうと思い気楽に好きなことを書きました。(変に長くなってしまったが...)
つまり何が言いたかったかと言うと、
「宇宙空間に電波の中継器を生やして、インフラを整備しよう」
という構想です。
自分の文章の最後に書いてあるように、
正直宇宙空間は分からないことが多すぎるため漠然とした内容になってしまいましたが、現実味を持たせるにはさらに専門的な知識を持っている人と考える必要があると改めて感じました。
宇宙空間は調べれば調べるほど対応しなきゃいけない問題が増えていって、難しすぎる！！！(もっと勉強しないと)
終わりに / 振り返り
課題としては全部で10,000字くらいの文章を先生に送り付けたわけですけども...
決して プログラミングつよつよ人間 でも、宇宙を完全に理解している必要がる わけではありません！！！(少なくともあーしはどっちもわからん。)
今まで自分のやってきたことが、証拠とともに相手に伝えることが出来て、これからも頑張れます！
という熱意がある程度伝わる文章を書ければ問題ないんじゃないかとあーしは思います！
(もし通らなかったとしても、その課題を解いてる過程は勉強になるし、考え方の整理にもなりますからね)
あとコレはナイショなのですが、
講師の先生についてめちゃくちゃ調べる(OSINTする)と良いと思いますよ！
(実は今回の応募課題の自分なりのテーマは 個性(自我)を出す だったりします)
ここまで駄文に付き合っていただきありがとうございました！！！
記事のデプロイがめちゃくちゃ遅くなってごめんなさい。
これを読んでいる皆さんも、課題は早めにとりかかりましょう...
Discussion