こんにちは.B4の猿渡です.

学生でいる期間もあと1日となったので急いでアメブロを書いています.

1年前に書きかけていた「GSE開発の記録」シリーズの続きです.

 

前回までの記事はこちら

 GSE開発の記録①

 GSE開発の記録②

 GSE開発の記録③

 

 

まずはこちらの動画をご覧ください.

 

 

これは2023年2月に行ったハイブリッドロケットエンジンの燃焼試験の様子です.

この燃焼試験に至るまでの開発の記録で,今日は2022年3月~7月くらいの活動内容をお伝えします.

 

当初は7月の初旬に福岡で燃焼試験を行う予定でした(後に再延期されました).そのため,この時期は燃焼試験に向けて急ピッチでGSEや運用手順を作成していました.

 

過去の資料などを見直していたら,配管をどう箱に収めるかといった設計や部品の発注を行っていました.私たちCOLOURSのGSEは配管や空圧弁,電磁弁を繋ぐGSEの中心部分をひとつの大きな箱に入れるという設計方針です.このメリットとして,

  • 現地で配管を繋ぐ作業を省けるためGSE展開の時間短縮が図れる
  • 運搬時に弁や管がぶつかることを防止できる
  • 管を箱で覆うことで砂埃やロケット打ち上げ時の火花から配管を保護できる

ということが挙げられます.

当然ながらまだ実物がない状態で配置を決めなくてはならないため,CADを用いて仮決めしていきました.作業をする際に管の間に手を入れる必要があるため,かなりスペースも確保して設計しました.(実物を見ながら今振り返ってみると,少しスペースが広すぎた感じがします…車での運搬時に場所を取ってしまうため,今後小型にしていくかもしれません.)使い方を想定しながら設計したのですが,完成してみるとイメージと違う部分があり設計の難しさを感じました.

 

3月~5月にかけては亜酸化窒素,酸素,窒素の3種類の高圧ガスの手配を行いました.酸素と窒素は手に入りやすいのですが,亜酸化窒素が少し特殊なため苦労した点ではあります.そもそも現役メンバーは誰もガスを購入したことがなかったことに加え,ガスの保管に関する法令や学内の規則についても理解する必要がありました.ガスを倉庫に保管するにあたって,保管するガス種を掲示したりボンベを固定できるように設備を整えたりしました.

 

運用手順書については,以前他大学からいただいたものを参考にしながらCOLOURS用の手順書を作成していましたが,この頃はまだGSEの実物が完成していなかったため,詳細な部分が書けずにいました.結局,この時期の進捗はほとんどなく2022年後半に持ち越されました.

 

また,大阪府立大学の後援会事業であるチャレンジくんに採択されていたため,いただいた資金を部品の購入に利用させていただきました.この場を借りてお礼申し上げます.ありがとうございました.

 

続きは明日の記事で書こうと思います.

 

猫しっぽ猫からだ猫からだ猫からだ猫からだ猫あたま

みなさ〜ん、こんこんこんあ〜るし〜!

 

あともうちょっとだけB3の黒川です.

こっちは、せっかく考えたので流行るまでは擦り続けようと思っている挨拶です.(あと何度擦る機会があるんだろう…?)

 

梅の見頃も過ぎ、じきに桜の降る季節ですね.

 

何某の花粉も猛威を振るっているとのことですが、みなさんに於かれましてはいかがお過ごしでしょうか?

自分はというと、桜はもう少し待って欲しいような、ちょっと複雑な気分です.

時間はどうしようもなく過ぎてしまうもので、この頃はやり残した色々が気になってきたり…

 

な〜んて、おセンチはほどほどにしまして.

近頃の我らがSSSRCといえば、新入生の系・委員会配属なども経て、新しいサイクルがぎこちないながらも回り出してます.

 

そんな中、日頃仕事がないことで名高い我々イベント委員も春だけは忙しなく駆け回っております.

このひと月だけでも倉庫の大掃除・追いコン・新歓準備とイベントごとの連続で、目も回る心地です.

たまの機会によ〜く働いておかないと他の時期に白い目で見られるので、春先は頑張りどきです!

イベント委員に春休みなし!(そんなことはない)

 

  黒川めちゃんこショック!

 

今日はそんなイベント委員春休み大作戦の中でも、

「OB・OGを●●●●したあと△△△△してやりたくなった無益で悲惨な戦い」こと倉庫の大掃除について書いてやるぜ!

震えて眠れ! OB・OGども!

と、息巻いていたのですが…

 

倉庫のBefore 写真を撮り損ねる痛恨のミス…!

 

黒川めちゃんこショック! です

 

なんということでしょう…

そんな訳で悔しいですが、倉庫ビフォーアフターの企画はぽしゃってしまいました…

やりたかった…

 

このネタで4千字越えの長文記事を書き上げる所存だったので、本当に残念です

あー悔しい

クヤシイナー

 

ということで実に口惜しいですが、温めていたネタがおじゃんになってしまったので、今日はこれぐらいで…

 

と、いうのもあんまりなので、好きな観光地の紹介とか軽くしちゃいます!

折角の春休みですしね!

まあイベント委員には春休みとかないんですが…(嘘だよ)(本当はそんなこと思ってないよ)(全部嘘だよ)

  宇治に行け

 

関西圏の観光地といえば、やはり宇治ですよね.

字面もちょっと宇宙に通じるところあるので、この団体のブログで紹介されるのにこれほどうってつけの観光地もない!

宇宙ノルマ達成!(そんなものはない)

はい.なんせ好きです.宇治

あるアニメの聖地で、そのアニメのファンの友人に何度も何度もスタンプラリーに付き合わされて訪れたんですが、今では宇治中毒です.

貴族の別荘地として栄えたことからも窺えるように風光明媚で、四季折々違った姿を見せる飽きない観光地です.

 

そんな宇治のおすすめポイントを3つご紹介!(諸事情で写真はなし 読ませます!)

 

  抜群の知名度! 平等院鳳凰堂

 

やはり外せない平等院鳳凰堂! 10円玉のあれです

藤原頼通公がその父道長公の別荘を寺社としたもので、さすがに栄華を極めた時代のものとあってとてつもなく立派です.

現世に極楽浄土を再現せんとしたその佇まいも去ることながら、併設されている展示施設もかなりの迫力で、なんか大量に仏像がありますよ! (なんて馬鹿っぽい説明…!)

大きい寺社を見るときには、往々にして感動とともにそんなものを作り上げてしまうこと自体に畏怖を感じるものですが、壁にずら〜、と並んだ仏像はいっそ病的に感じる圧巻の光景です

それだけのものを作るに至ったその時代への恐怖、今にも通ずる死への恐怖について、思いを馳せてみるのも一興かと

好きです.

 

  なんかよく分からないものまで緑色! 抹茶づくし

 

宇治といえばそりゃあもう抹茶ですよね

たこ焼きまで緑だったのを見たときは、平等院鳳凰堂とはまた別の恐怖を感じたものです.

抹茶ソフトに抹茶団子、さらには抹茶餃子まで(?)

なんせ抹茶づくしな宇治ですが、宇治茶の山田園茶舗では50円で甘〜いグリーンティーが飲めるのでおすすめです

くぅ〜ってなります.

大好きです.

 

  これが何より大事! 交通アクセスの良さ

先に紹介した宇治の観光スポットはJR宇治駅、京阪宇治駅から徒歩圏内で、京都の山寺たちとは違い交通の便が◎です

宇治の観光地は比較的狭いエリアに集中しているので、とりあえず電車に乗って宇治まで行ってしまえば特に旅程とか考えなくても楽しめてしまうんだ! すごい!

最高です!

 

  最後に

以上、宇治のご紹介でした

春休みはみんなで宇治にいこう!

イベント委員はダメだけどな!(春休みとかないので)

 

さてさて、オチもついたのでこの辺りで.

卒業がちょっと寂しい黒川でした.

学年が上がるごとにキツくなりますね…

今回は、mbedを使う際のオンライン開発環境Keil Studio Cloudの使い方のうち、プロジェクトの共有についての説明をしていきたいと思います。

そもそもKeilってなんぞや、とか、とりあえずプログラムを動かしたい、という方は入門編をご覧ください。

 

 はじめに

従来型のmbed compilerでは、mbedのサイト上にプロジェクトをパブリッシュすることで、プロジェクトの他のメンバーと共有しながら開発ができたのですが、Keil Studio Cloudでは、githubを用いた共有が推奨されています。

そのマニュアルが英語版である上、画像なども少なくわかりにくいと感じたので、共有方法について引継ぎ資料としてここに残しておきたいと思います。

他にも同じことで困っている方がいらっしゃったら参考にしていただければ幸いです。

 

 

 GitHubアカウントとの連携

まずは、keil StudioとGitHubのアカウントを連携させます。

前準備として、GitHubのアカウントを持ってない方は作ってください。(以下割愛)

GitHubのアカウントを作ったら、Keilを開き、左下にある人のマークから、人のマーク>Show User Profile>Connect to GitHub とクリックします。

すると、GitHubが立ち上がります。そこで自分のGithubアカウントにログインして、画面の指示に従ってポチポチしていくと、GitHubアカウントとの連携ができるようになります。

これが完了した状態で、人のマーク>Show User Profile をクリックすると、同期されたGitHubのアカウント名が出てきます。

 

 MercurialをGitに変換しよう

 

KeilではGitでの共有を推奨しているのですが、mbed compilerから移植してきたものや、元々パブリッシュしてあったものについては、デフォルトでMercurialでの共有となっています。

そこで、MercurialをGitに変換する必要があります。

まず、エクスプローラーのActive Projectで共有したいプロジェクトを選択します。

 

左端のメニューの上から3番目の赤で囲った枝みたいなマーク(以後、共有マークと呼びます、界隈で呼び方あるのかな)をクリックすると、Source Controlページに移動します。

ここで、上の表示のSource Control: の横に書いてあるのが共有形式です。これが、Gitである場合はこの章はとばして「マスターに中身を追加する」まで進んでください。

Mercurialだった場合は以下のように変換を行います。

 

 

Source Control: の行の一番右にある...をクリック(めちゃくちゃ見つけにくい)

新たに表示された Convert to a Git Repository and Fork on GitHub をクリック

すると、このような表示が出てくるので、レポジトリの名前と説明を記載しNextをクリックします。プライベートかパブリックかは各自設定してください。

 

すると、次にダイアログが出てきます。

mbedプロジェクトを編集した全作者の一覧が出てくるので、GitHubのユーザー名がわかる場合は入力しておきます(任意)。そして、Migrate nowボタンを押すことで、変換が完了します。

これでGitに変換してGitにあげることができました。

 

 

 新たなプロジェクトをGitHubに投稿する

 

続いては、新しいプロジェクトの場合です。

この場合、共有ボタンを押してSource Controlを開くと以下のように表示されます。

ここで、Publish Projectをクリックします。

出てきたダイアログにプロジェクト名や説明を入力してPublishボタンを押すと完了です。

Source Control: の横にGitという表示が出てきます。

 

 

 マスターに中身を追加する

さあ、ここまできてやっと下ごしらえが終わりです。

この状態では、プロジェクトという箱はできたものの、中にファイルは入っていない状態です。

共有ボタンを押して再度 ”Source Control: Git” と表示されることを確認してください。

 

 

確認出来たら、Changeと書いてある横の+マーク(Stage All Changes)をクリックします。すると、全てのファイルがStaged changesに入ります。

(ここでファイルを一つずつ+マークを押して、一部のファイルだけStageに含めることもできます)

 

追加(変更)したいファイルをStaged changesに入れたら、”Staged changes”と書いてある上にあるMessageと書いてある部分にプロジェクトのマスターの説明を記載します。

その後、その上にある✓マーク(commitボタン)をクリックすることでマスターのコミットが完了し、プロジェクトに中身が入ります。

 

 

 ブランチを編集する

見事、プロジェクトと中身をGitHubに共有できてめでたしめでたし!と思いきや、これはまだ序の口です。

そもそも何のためにプロジェクトを共有したのかといったら共同で編集するためです。

共同編集するのにはマスターではなくブランチを編集してそれをマージすることが推奨されているので、これをやっていきたいと思います。

というか、ここまで何の説明もなくマスターとかブランチとか用語を使っていたのですが、「マスターって何だよ」って思った方、疑問を放っておけない姿勢は大事です。

ただ、連日ブログを書いている筆者のエネルギーの都合で割愛します。googleで”GitHub マスター”とかで調べてみてください。

 

では、本題のブランチの編集に移ります。

まずは編集するブランチを作成せねばなりません。

 

 

下の青いラベルの所にあるmaster(あるいはmain)をクリックします。

(このボタンがまじで見つかりにくい)

 

 

すると、上の部分にcreate new branchというボタンが現れるので、ボタンをクリックして、その上にあるワードボックスにブランチ名を記載してからエンターを押すことでブランチが作れ、自動的に今作ったブランチに移動します。

この時、先ほどmaster(あるいはmain)と書いてあったラベル部分が新しいブランチの名前になっていると思います。

今回はsampleという名前のブランチにしました。

 

そして、Sみたいなボタンを押してエクスプローラーを開き、好きなようにプロジェクトを編集します。

 

 

編集が終わったら共有ボタンを押してSource Controlを開きます。

 

 

すると、Changesの欄に編集したファイルの一覧が表示されていると思います。

今回はmain.cppを編集しました。

 

 

ここまでできたら、masterをGitHubにあげたときと同様に、編集したファイルの+ボタンを押して、Staged changesにあげ、コミットの際のメッセージを入れてcommitボタンを押すことでコミットが完了します。

 

また、Source Controlの…ボタンを押すと出てくるメニューから、色々なことができます(雑)。

 

 

 ブランチをマスターに統合する

さあ、ついに最終盤です。

ここまでブランチを編集してきましたが、編集したブランチの内容で決定したら、ブランチをマスターに統合します。

 

 

画面下の青いメニューのブランチ名をクリックすると、ブランチの切り替えの選択が出てくるのでmasterに切り替えます。

 

 

そして、Source Controlの…ボタンを押すと出てくるメニューからMergeを選択すると、どのブランチをMergeするのか選択できるようになるので、ここでは先ほど編集したsampleを選択します。

すると、Mergeすることができました。

そして、最後にSource Controlの…ボタンを押すと出てくるメニューから、Pushを押すことで、リモートリポジトリを更新することができます。

 

 

 終わりに

 

mbed compilerの廃止によって大きな変化があったオンラインでの共同開発環境ですが、GitHubを推奨するようになったことで、見方によってはGitHubの学習になると捉えることもできます。

最初の使い方こそ難しいですが、使い方に慣れれば便利な点もたくさんあります。

これからもmbedなどを使って開発する場合には、ぜひKeil Studioだけでなく、GitHubの使い方もマスターして、苦しい楽しい開発ライフを送ってください!