衛星プロジェクトが変わった場合にパラメータ変更できるようにする about c2a-aobc

[suzuki-toshihir0]

もともとは複数衛星に拡張するときにどういうSWの切り分け方がよいか考えあぐねていたのですが，最近別のissueでも議論した中で見通しが立ってきたので，一度しっかり作業のマイルストーンを整理してお出しします（ので，少々お待ちください）．

作業時間という点では，私がAEでのもともとの契約条件よりも働き過ぎてしまっているところはあるので，私が東大側として必要な作業時間が取れるように調整します．

[200km]

@suzuki-toshihir0 ありがとうございます。方針についてコメントさせていただきます。

src_user/Settings/SatelliteParameters/ というフォルダを作って，そこに入れていく想定です

場所については、衛星プロジェクト専用のレポジトリを作り、プロジェクト毎にパラメータを変更できるように設定するにも関わる気がするので、そこを先に決めたほうが良いですね。
名前としてSatelliteParametersが良いのかですが、UserDefinedParametersとかでも良い気がしました。

"Sample"，"HogeSat"などのフォルダでわける

これもプロジェクト専用で分けるときの分け方に依存しますね。

CMakeファイルで変更パラメータを集めたディレクトリへのパスを設定できるようにする

これもプロジェクト専用で分けるときの分け方に依存しますが、今のように実装例のように別レポジトリになる前提のものの場合は、Settings/CMakeLists.txtではなく別のCMakeListを用意した方が良いと思いました。

[200km]

まずは、初期軌道情報から取り組む。

[suzuki-toshihir0]

コンポが一部差し替わったとしても，柔軟に切り替えられるようにしたいという要望があるということが以下で出ている

https://github.com/arkedge/c2a-aobc-0th/issues/8

[200km]

一応、GitLabのissueについては、コンポが一部差し替わったの話も書いているので、見ておいてください。

[suzuki-toshihir0]

いまGitLabのissueにそちらの記述があるのを確認しました．ただこちらのGitHubのissueではその記述がなかったので，そういう話はなくなったのかなと思っていたところでした．

[suzuki-toshihir0]

コンポが一部差し替わったときの対応をしっかりやっていきたいという方針はAEも東大も同意見だと思うので，ひとまずそれはそれで大丈夫だと思います．

[200km]

@suzuki-toshihir0 こちらについて、GitLabでは前からアサインしてましたが中々進んでいない状況なので、方針などを確認したほうが良いと思っています。どうしようと考えているのか教えてもらえると助かります。
方針について今一度議論が必要なら、@sksat　さんも含めて議論しても良いと思っています。

作業時間がないということなら言っていただければ私の方で引き取ります。

[suzuki-toshihir0]

だいぶ遅くなってしまいましたが，c2a-aobcの開発もしっかり進めていけそうになってきたのでこちらも作業していきます．

なんとなくのイメージはついている一方，具体的な完成形についてもう少ししっかり議論したいので，Descriptionの詳細のところに書いてくださっている進め方について具体化していきたいです．以下の実装のイメージを書いているので，想定と違うところなどあればお教え頂けると嬉しいです． @200km @sksat @meltingrabbit

変更パラメータを集めたディレクトリを作る

• いまのところ， src_user/Settings/SatelliteParameters/ というフォルダを作って，そこに入れていく想定です．

ディレクトリにパラメータをマクロで定義したデフォルトヘッダファイルを作る

• GitLab側でもコメントありましたが，ここは型付きでextern constで書いても良い気がしますね．

/* Settings/SatelliteParameters/orbit_parameters.h */
/* ここに変数宣言を型付きで書く */
extern const double ORBIT_PARAMETERS_sat_pos_obs_ecef_m;

/* Settings/SatelliteParameters/Sample/orbit_parameters.c */
/* ここに変数の値を型付きで書く．衛星を区別するために，"Sample"，"HogeSat"などのフォルダでわける．Sample/にはデフォルトの値が入ることを想定している */
const double ORBIT_PARAMETERS_sat_pos_obs_ecef_m = 5.0e6;

ヘッダを読み出してパラメータを設定するようにする

/* aocs_manager.c */

#include "../../../Settings/SatelliteParameters/orbit_parameters.h"

/* 中略 */

static void APP_AOCS_MANAGER_init_(void)
{
  /* 中略 */
  VECTOR3_initialize_double(aocs_manager_.sat_pos_obs_ecef_m,    ORBIT_PARAMETERS_sat_pos_obs_ecef_m);
}

CMakeファイルで変更パラメータを集めたディレクトリへのパスを設定できるようにする

/* Settings/CMakeLists.txt */
set(C2A_SRCS
  /* 中略 */
  # SatelliteParameters
  SatelliteParameters/Sample/orbit_parameters.c  // 衛星が変わったら，ここも変わる
)

衛星プロジェクト専用のレポジトリを作り、プロジェクト毎にパラメータを変更できるように設定する

• 各プロジェクト専用のリポジトリはissl/c2a-aobcのフォークとして扱う？
• いったんフォークしたら，Settings/SatelliteParameters/ と Settings/CMakeLists.txt
• 基本的に，機能のアップデートはissl/c2a-aobcに対して行ない，アップデートがあったらフォーク先のリポジトリはその変更を取り込む？

[suzuki-toshihir0]

ところで，

衛星プロジェクト専用のレポジトリを作り、プロジェクト毎にパラメータを変更できるように設定する

についてなのですが，プロジェクトごとにリポジトリを分けたくないという話も聞いています．そのあたり，前議論した関係者内できちんと方針の合意は取れてるのでしょうか？？

[suzuki-toshihir0]

@200km ありがとうございます．まずは衛星ごとにリポジトリを分けるかどうかのポリシーについて考えたいので，ミーティングもうけたいですね．AE側は5/1，2に有給取る人も多いと思うので，GW明けにセッティングします．

[200km]

@suzuki-toshihir0 @meltingrabbit @sksat

各プロジェクト専用のリポジトリはissl/c2a-aobcのフォークとして扱う？

これは重要ポイントになると思いますが、具体的な手順・開発フローがどのようになるかもう少し確認して決めたいと思うので、想定を教えて下さい。

各プロジェクトで専用レポジトリを作る場合

• イメージはc2a-aobcとc2a-coreのような感じと思われる
  • c2a-hoge-satというリポジトリを作って、その中でsubmoduleとしてc2a-aobcをつないだりする?
  • CMakeや実機ビルド環境設定などをc2a-hoge-sat側が管理することになり、面倒にも思えるし逆に自由度が増えて追加実装などは簡単そう?
• c2a-aobcのアップデートを取り込む方法
  • submodule updateして、その後ユーザー側で修正が必要な部分をしゅうせしていく
• ユーザー側で新規実装したものをc2a-aobcに取り込む方法
  • submodule側でブランチ切ってそのままPRなどすればよい？
• ユーザー側で非公開の機能を実装する方法
  • アプリ追加、コンポ変更・追加、テレコマ変更なども自由にできそうな感じではあるが、自由にしすぎるとc2a-aobcとの連携が複雑になり、分岐が深くなっていきそう

各プロジェクトで専用レポジトリはc2a-aobcのforkとして扱う場合

• GitHubでforkしたらpublicレポジトリになってしまうので、この方法などで新しくprivateレポジトリを作る?
  • よく分かっていないので他のより適切な手法があったら教えて下さい
  • CMakeや実機ビルド環境設定などもc2a-aobcで定義したものをそのまま使えるので、c2a-aobcのアップデートを取り込むのが楽そう
• c2a-aobcのアップデートを取り込む
  • fork先なのでupstreamマージすればよい
• ユーザー側で新規実装したものをc2a-aobcに取り込む方法
  • これもupstreamへのPRを出せば良いので簡単にできる？
  • でも、この時に非公開の更新と公開したい更新が混ざったPRにならないかが少し心配？
• ユーザー側で非公開の機能を実装する方法
  • アプリ追加、コンポ変更・追加、テレコマ変更なども自由にできそうな感じではあるが、上記のupstreamへのPRのときに混ざってしまわないかが気になる？

気になるところ

• 上に書いた 非公開の更新と公開したい更新が混ざったPRにならないか の部分が本当にそうなのか？うまく運用すればそんな事にならないように適切な処置ができるのか？
• 別レポの場合は、修正できる・するべき範囲が明確に絞られるので、管理が楽にみえる？
  • (これまでc2a-coreをsubmoduleとして扱ってきた経験から)submodule内を修正しようとは中々思わないが、forkしたあとのレポジトリだと全部修正できる・しても良いように見えてしまうという部分が気になる

[suzuki-toshihir0]

以前にもコメントをしている通り，現状の私の想定は 各プロジェクトで専用レポジトリはc2a-aobcのforkとして扱う場合 にあたります．そのうえでコメントお返しします．

各プロジェクトで専用レポジトリを作る場合

• これについては，いまいちsubmoduleとしてc2a-aobcを扱うというのが想像ついていないです（少なくとも僕の想定には全くなかったです）．この場合の c2a-hoge-sat に何が含まれるかの想定が知りたいなと思います．
• アップデートの取り込みと，ユーザー側の新規実装をc2a-aobcに取り込む方法については問題ないと思います．
• 非公開の機能については， c2a-hoge-sat に何が含まれるかの想定次第でどう実装するかが変わってくると思います．

各プロジェクトで専用レポジトリはc2a-aobcのforkとして扱う場合

• privateリポジトリにする方法については，私は特にいい方法を知っているわけではないです．すみません．
• アップデートの取り込みについては問題ないと思います．
• ユーザー側で新規実装したものをc2a-aobcに取り込む際には，普通にやると非公開の更新と公開の更新が混ざってしまいますね．基本的にユーザー側→c2a-aobcへの取り込みはなくしたいと思っているのですが，そういう運用が成立するのかは相談したいですね．

気になるところについて

• 非公開の更新と公開の更新が混ざったPRにならないか，については
  1. ユーザー側→c2a-aobcへの取り込みをそもそもなくせるかどうか
  2. なくせないとして，公開部分だけを選択してユーザー側→c2a-aobcのPRを発行できるかどうか
  • が争点になりそうですね．これはMTGしたほうが早い気もします．
• 別レポについても構成をどうするか次第になりそうなので，こちらもMTGで相談させてください．MTG設定しなおします．

[200km]

返信ありがとうございます。
submoduleとしてc2a-aobcを扱うについては、まさにこのレポジトリがc2a-coreをsubmoduleとして取り込んでいるのと同じようなことを想定してもらえると良いかなと思います。c2a-hoge-satには、コンパイル設定、衛星ごとの設定、c2a-aobcが持っていないコード等が管理されることになると思います。

各プロジェクトで専用レポジトリはc2a-aobcのforkとして扱う場合の懸念点は、

• privateレポジトリにうまくする方法
• 非公開の更新と公開の更新が混ざったPRにならないか
  ですね。前者がうまくできないとかなり厳しいので、前者についてまずどんな方法を考えているのか教えて下さい。

基本的にユーザー側→c2a-aobcへの取り込みはなくしたいと思っているというのはなぜでしょうか？いきなりOSSであるc2a-aobcをいじるのはハードルが高い、レビューに時間がかかり取り込まれるのに時間がかかるなどがあると思います。その場合はまずは小さな影響範囲である特定プロジェクトのprivateレポジトリで実装してみて、それが洗練化されてきたらOSS化されているメインのものに取り込もうというのもありえる考え方かなと思います。
(例えばs2e-coreとs2e-ffの関係等がそれに当たります)
あとは、当初はOSS化するつもりはなくprivateで開発していたけれど、OSS化する方針になったなどもあり得るかなと思います。
やり方はさておき、ユーザー側→c2a-aobcへの取り込みはあったほうが便利だと思って議論を進めたほうが良いのではないかな？と思っています。

[suzuki-toshihir0]

• submoduleとしてc2a-aobcを扱う については，たとえば公開したくない新しい姿勢制御アルゴリズムを書いたとして，それを新しいリポジトリでどのように配置するか（つまり，どういうフォルダ構造になるか）の想像がついていなかったです．

  • c2a-aobcをさらにsubmoduleとして持つという形になると，フォルダの構造も他のOBCとは大きく変わることになりそうですが，それで問題ないかは確認したいですね．
    • 僕はそこで大きな問題が起きるとは思わないものの，C2A全体のポリシーとしてそういうリポジトリを許容するかどうかが争点になると思います．
  • MOBCなども衛星ごとにパラメータを変えたいみたいな要求は持っている気がするので，そちらでどうしたいかというのも聞きながら考えたいです（これは @meltingrabbit @sksat ？）

• フォークしたリポジトリをprivateリポジトリで持つ方法は，五十里先生が提案されている方法くらいしか僕の中にはないです．ただAE orgでのprivate forkした例があった気がするので，可能ではあると思っています（この辺は @sksat が詳しい？）

• 基本的にユーザー側→c2a-aobcへの取り込みはなくしたいと思っている については，非公開と公開の編集が混ざってしまうくらいならその方向の取り込みはなるべくなくなるようにしたいというくらいのイメージでした．うまく回避できるならユーザー側→c2a-aobcの方向の取り込みはあってよいと思います．

  • ユーザー側→c2a-aobcへの取り込みはあったほうが便利だと思って議論を進めたほうが良いのではないかな？と思っています。 についてはいったん了解です．なるべくそうできるように方法を考えたほうがいいと私も思います．

[200km]

c2a-aobcをさらにsubmoduleとして持つ 場合はsubmoduleが入れ子になって複雑に見えるというのが問題の一つかなとは思います。一方で、aobcのユーザーからすると、c2a-aobc内部のc2a-coreがどうかは気にする必要はない気もするので、深入りするのは結局は我々主開発者だけなのかなと思っています。

MOBC側の方針もたしかに重要ですが、スケジュール的にこちらが急ぎな気もするので、

• 短期的にAOBC用の暫定方針に対応する
• 長期的にMOBCやc2a-coreの方でアップデートがあったらそちらに追従する

という手もあるとは思います。もちろん、すぐに見通しが立つなら、最初からMOBCやc2a-coreに寄せて進めても良いとは思いますので、スケジュール感が知りたいですね。

[suzuki-toshihir0]

はい，一つ

短期的にAOBC用の暫定方針に対応する

という手はあると思います．スケジュール感についても本日のMTGで確認しましょう．

[suzuki-toshihir0]

議事録のまとめです．

複数の話が混ざっている

c2a-aobcを扱う人間をいくつかに分類したい．

1. 主たる開発者であるISSL

• 東大はc2a-aobcだけ使う．privateな設定値は4の人と同じように扱う
• リポジトリの扱い方としては，4の人か3の人と同じようなことになる

2. 主たる開発者に近いAE

• リポジトリの扱い方としては，4の人か3の人と同じようなことになる

3. それ以外で，c2a-aobcに手を入れて使いたいユーザ

• c2a-aobcがオープンになったら発生する．この人たちには，c2a-aobcそのものをフォークして作業してもらう
• c2a-aobcを使いたくて中をいじりたくなったら，東大でもAEでもこれをやるべき
• パッチを本家c2a-aobcに送りたくなったらPR発行すればよいだろう
• この人たちは自分の非公開部分も持ちたいだろう．4に近い立場で作業しているうちに，c2a-aobcを修正したいという要求が生まれうる．
• このときはc2a-aobcをまずforkする（a）．本体に対する改修のみをfork先のリポジトリでやる．実際に書き込むものの開発はその人たちのorgに設定値だけのリポジトリを作る（b）．(b)のなかでは，本家c2a-aobcではなく(a)をsubmoduleとして持てば良い

4. パラメータだけを変えたいユーザ

• いったんsubmoduleで取り込むのがよいだろう

c2a-aobcをフォークしたリポジトリが乱立する話

AEはプロジェクトをprivateで進めざるを得ないものがおおいため，c2a-aobcのフォーク的なものが乱立しそうだが，大丈夫か？
-直感的にはAEとしてはうまくいかなそう
-issl/c2a-aobcに一緒くたにドライバを入れて，どれをビルドするかは設定側で変えられるような実装がよいだろう．

• もっというと，private側のリポジトリに隠したいドライバを書いて，それを設定側でビルドできるようにしたい．ただこれはCでは言語機能が弱いのでやりにくそう
• いまパラメータ変更のissueをやっていくためには，いったんivのユーザーを想定するのがよいだろう．

AOBCだけでなく，他のOBCにもありえる問題なのでは？

• よく使う実装をまとめたいという要求がでて，それをみんなで使いたいという視点が最初に生まれてきたのがAOBCで，他のOBCでも後追いで生まれてくる

c2a-aobc-minumum-userみたいなリポジトリを作るべき？

• examplesみたいなフォルダをもっておく？
• ディレクトリ階層がこうなっているべき，みたいなので動くべきではない．
• c2a-minimum-userを参考にするのがよいだろう．
• c2a-coreと同じようにしておくのがよい？
• c2a-coreの中にexamplesがあるので，それを使うのがよさそう
• 自分自身をsubmoduleとして持つことはできないので，そのためにscriptを作る．

[suzuki-toshihir0]

@200km @sksat
実作業を進めていくにあたりちょっと確認したいのですが，c2a-aobc をsubmoduleとして持つということは，c2a-aobc にアップデートが入ったら実際に衛星に書き込むC2Aのリポジトリ（これを仮に c2a-aobc-hoge と呼ぶことにする ）もそれに合わせて手動アップデートが必要ということでよいですか？
つまり，c2a-core のアップデートに伴って c2a-aobc のアップデートをしている作業（=いわゆる「core update」）に相当するものが，c2a-aobc と c2a-aobc-hoge の間でも必要になりそうですが，そういう認識でよいでしょうか？

[200km]

手動アップデートが必要

ユーザー側がそのアップデートを取り込みたいと思った場合、submodule側でバージョン変更する必要があります。
patchやminorアップデートの場合は、submoduleのバージョン変更のみで、その他の面倒な作業は発生しないと思いますが、majorバージョンアップデートでパラメータ設定部分も変える必要が出てくると、面倒な作業は発生してしまいます。　　

ただ、これはどんなやり方でも避けられないものだとは思います。

[suzuki-toshihir0]

ありがとうございます．たとえば c2a-aobc に新しいファイルが追加されるような変更が入って，そのを c2a-aobc-hoge に取り込みたくなったら CMakeや c2a-aobc-hoge.vcxproj などの修正が必要になってしまいますが，もはやこれはどんなやり方でも避けられないということですよね．

[suzuki-toshihir0]

そうであれば今の僕の理解と合っていそうなので，問題なく作業進められそうです

[200km]

ファイル追加だけなら、CMakeFileの責任範囲をsubdirectoryで適切に分けていけば影響が少ないようにできるはずです。s2e-coreやc2a-coreでそうしていると思うので、確認して見てください。
vMicro用のvcxprojはまた別ですが、これはCMakeから自動で生成できるようにするのが理想的ですね。(あとは、vMicro使わないようにできたら。。。とかですね。)

[suzuki-toshihir0]

ありがとうございます．CMakeについてはそこまで心配していなかったのですが，どちらかといえばvcxprojの方がどうするのかなと気になっていた質問でした．ファイル追加のたびに手で追加するのは大変なので，CMakeで自動生成できるならそうするのに賛成です．vMicro使わなくて良くなる見込みについては， @sksat が考えてくれているところ．．．だと思います．

[200km]

@suzuki-toshihir0 @sksat @meltingrabbit コンポI2Cアドレスについてどう変更していこうかと言うのを迷っています。
I2Cアドレスはここで定義されているので、うまく活かしたいのですが、どうしようかなと言う感じです。

c2a-coreとc2a-userの間のパラメータ設定などと同じような方針でも良いのかなとも思っているのですが、いかがでしょう？

c2a-aobc/src/src_user/Settings/TlmCmd/block_command_table_params.h

Line 16 in 82ec550

#define BCT_MAX_CMD_NUM (16)

https://github.com/ut-issl/c2a-core/blob/042cdfa15b0056880398e857cdd5d5a430562fd1/TlmCmd/block_command_table.h#L26

[suzuki-toshihir0]

私としてはcoreとuserの間のパラメータ設定管理方法（同じ名前でマクロを持っておいて，ユーザー側では読み出すものを切り替える）でよいと思います．

[200km]

@suzuki-toshihir0 @sksat @meltingrabbit コメントを元にPR出してみましたので、確認をお願いします。