Comments (27)
もともとは複数衛星に拡張するときにどういうSWの切り分け方がよいか考えあぐねていたのですが,最近別のissueでも議論した中で見通しが立ってきたので,一度しっかり作業のマイルストーンを整理してお出しします(ので,少々お待ちください).
作業時間という点では,私がAEでのもともとの契約条件よりも働き過ぎてしまっているところはあるので,私が東大側として必要な作業時間が取れるように調整します.
from c2a-aobc.
@suzuki-toshihir0 ありがとうございます。方針についてコメントさせていただきます。
src_user/Settings/SatelliteParameters/ というフォルダを作って,そこに入れていく想定です
場所については、衛星プロジェクト専用のレポジトリを作り、プロジェクト毎にパラメータを変更できるように設定する
にも関わる気がするので、そこを先に決めたほうが良いですね。
名前としてSatelliteParameters
が良いのかですが、UserDefinedParameters
とかでも良い気がしました。
"Sample","HogeSat"などのフォルダでわける
これもプロジェクト専用で分けるときの分け方に依存しますね。
CMakeファイルで変更パラメータを集めたディレクトリへのパスを設定できるようにする
これもプロジェクト専用で分けるときの分け方に依存しますが、今のように実装例のように別レポジトリになる前提のものの場合は、Settings/CMakeLists.txt
ではなく別のCMakeListを用意した方が良いと思いました。
from c2a-aobc.
まずは、初期軌道情報から取り組む。
from c2a-aobc.
コンポが一部差し替わったとしても,柔軟に切り替えられるようにしたいという要望があるということが以下で出ている
https://github.com/arkedge/c2a-aobc-0th/issues/8
from c2a-aobc.
一応、GitLabのissueについては、コンポが一部差し替わった
の話も書いているので、見ておいてください。
from c2a-aobc.
いまGitLabのissueにそちらの記述があるのを確認しました.ただこちらのGitHubのissueではその記述がなかったので,そういう話はなくなったのかなと思っていたところでした.
from c2a-aobc.
コンポが一部差し替わったときの対応をしっかりやっていきたいという方針はAEも東大も同意見だと思うので,ひとまずそれはそれで大丈夫だと思います.
from c2a-aobc.
@suzuki-toshihir0 こちらについて、GitLabでは前からアサインしてましたが中々進んでいない状況なので、方針などを確認したほうが良いと思っています。どうしようと考えているのか教えてもらえると助かります。
方針について今一度議論が必要なら、@sksat さんも含めて議論しても良いと思っています。
作業時間がないということなら言っていただければ私の方で引き取ります。
from c2a-aobc.
だいぶ遅くなってしまいましたが,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に対して行ない,アップデートがあったらフォーク先のリポジトリはその変更を取り込む?
from c2a-aobc.
ところで,
衛星プロジェクト専用のレポジトリを作り、プロジェクト毎にパラメータを変更できるように設定する
についてなのですが,プロジェクトごとにリポジトリを分けたくないという話も聞いています.そのあたり,前議論した関係者内できちんと方針の合意は取れてるのでしょうか??
from c2a-aobc.
@200km ありがとうございます.まずは衛星ごとにリポジトリを分けるかどうかのポリシーについて考えたいので,ミーティングもうけたいですね.AE側は5/1,2に有給取る人も多いと思うので,GW明けにセッティングします.
from c2a-aobc.
@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したあとのレポジトリだと全部修正できる・しても良いように見えてしまうという部分が気になる
from c2a-aobc.
以前にもコメントをしている通り,現状の私の想定は 各プロジェクトで専用レポジトリはc2a-aobcのforkとして扱う場合
にあたります.そのうえでコメントお返しします.
各プロジェクトで専用レポジトリを作る場合
- これについては,いまいちsubmoduleとしてc2a-aobcを扱うというのが想像ついていないです(少なくとも僕の想定には全くなかったです).この場合の
c2a-hoge-sat
に何が含まれるかの想定が知りたいなと思います. - アップデートの取り込みと,ユーザー側の新規実装をc2a-aobcに取り込む方法については問題ないと思います.
- 非公開の機能については,
c2a-hoge-sat
に何が含まれるかの想定次第でどう実装するかが変わってくると思います.
各プロジェクトで専用レポジトリはc2a-aobcのforkとして扱う場合
- privateリポジトリにする方法については,私は特にいい方法を知っているわけではないです.すみません.
- アップデートの取り込みについては問題ないと思います.
- ユーザー側で新規実装したものをc2a-aobcに取り込む際には,普通にやると非公開の更新と公開の更新が混ざってしまいますね.基本的にユーザー側→c2a-aobcへの取り込みはなくしたいと思っているのですが,そういう運用が成立するのかは相談したいですね.
気になるところについて
- 非公開の更新と公開の更新が混ざったPRにならないか,については
- ユーザー側→c2a-aobcへの取り込みをそもそもなくせるかどうか
- なくせないとして,公開部分だけを選択してユーザー側→c2a-aobcのPRを発行できるかどうか
- が争点になりそうですね.これはMTGしたほうが早い気もします.
- 別レポについても構成をどうするか次第になりそうなので,こちらもMTGで相談させてください.MTG設定しなおします.
from c2a-aobc.
返信ありがとうございます。
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への取り込み
はあったほうが便利だと思って議論を進めたほうが良いのではないかな?と思っています。
from c2a-aobc.
-
submoduleとしてc2a-aobcを扱う
については,たとえば公開したくない新しい姿勢制御アルゴリズムを書いたとして,それを新しいリポジトリでどのように配置するか(つまり,どういうフォルダ構造になるか)の想像がついていなかったです.- c2a-aobcをさらにsubmoduleとして持つという形になると,フォルダの構造も他のOBCとは大きく変わることになりそうですが,それで問題ないかは確認したいですね.
- 僕はそこで大きな問題が起きるとは思わないものの,C2A全体のポリシーとしてそういうリポジトリを許容するかどうかが争点になると思います.
- MOBCなども衛星ごとにパラメータを変えたいみたいな要求は持っている気がするので,そちらでどうしたいかというのも聞きながら考えたいです(これは @meltingrabbit @sksat ?)
- c2a-aobcをさらにsubmoduleとして持つという形になると,フォルダの構造も他のOBCとは大きく変わることになりそうですが,それで問題ないかは確認したいですね.
-
フォークしたリポジトリをprivateリポジトリで持つ方法は,五十里先生が提案されている方法くらいしか僕の中にはないです.ただAE orgでのprivate forkした例があった気がするので,可能ではあると思っています(この辺は @sksat が詳しい?)
-
基本的にユーザー側→c2a-aobcへの取り込みはなくしたいと思っている
については,非公開と公開の編集が混ざってしまうくらいならその方向の取り込みはなるべくなくなるようにしたいというくらいのイメージでした.うまく回避できるならユーザー側→c2a-aobcの方向の取り込みはあってよいと思います.ユーザー側→c2a-aobcへの取り込みはあったほうが便利だと思って議論を進めたほうが良いのではないかな?と思っています。
についてはいったん了解です.なるべくそうできるように方法を考えたほうがいいと私も思います.
from c2a-aobc.
c2a-aobcをさらにsubmoduleとして持つ
場合はsubmoduleが入れ子になって複雑に見えるというのが問題の一つかなとは思います。一方で、aobcのユーザーからすると、c2a-aobc内部のc2a-coreがどうか
は気にする必要はない気もするので、深入りするのは結局は我々主開発者だけなのかなと思っています。
MOBC側の方針もたしかに重要ですが、スケジュール的にこちらが急ぎな気もするので、
- 短期的にAOBC用の暫定方針に対応する
- 長期的にMOBCやc2a-coreの方でアップデートがあったらそちらに追従する
という手もあるとは思います。もちろん、すぐに見通しが立つなら、最初からMOBCやc2a-coreに寄せて進めても良いとは思いますので、スケジュール感が知りたいですね。
from c2a-aobc.
はい,一つ
短期的にAOBC用の暫定方針に対応する
という手はあると思います.スケジュール感についても本日のMTGで確認しましょう.
from c2a-aobc.
議事録のまとめです.
複数の話が混ざっている
c2a-aobcを扱う人間をいくつかに分類したい.
- 主たる開発者であるISSL
- 東大はc2a-aobcだけ使う.privateな設定値は4の人と同じように扱う
- リポジトリの扱い方としては,4の人か3の人と同じようなことになる
- 主たる開発者に近いAE
- リポジトリの扱い方としては,4の人か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として持てば良い
- パラメータだけを変えたいユーザ
- いったん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を作る.
from c2a-aobc.
@200km @sksat
実作業を進めていくにあたりちょっと確認したいのですが,c2a-aobc
をsubmoduleとして持つということは,c2a-aobc
にアップデートが入ったら実際に衛星に書き込むC2Aのリポジトリ(これを仮に c2a-aobc-hoge
と呼ぶことにする )もそれに合わせて手動アップデートが必要ということでよいですか?
つまり,c2a-core
のアップデートに伴って c2a-aobc
のアップデートをしている作業(=いわゆる「core update」)に相当するものが,c2a-aobc
と c2a-aobc-hoge
の間でも必要になりそうですが,そういう認識でよいでしょうか?
from c2a-aobc.
手動アップデートが必要
ユーザー側がそのアップデートを取り込みたいと思った場合、submodule側でバージョン変更する必要があります。
patchやminorアップデートの場合は、submoduleのバージョン変更のみで、その他の面倒な作業は発生しないと思いますが、majorバージョンアップデートでパラメータ設定部分も変える必要が出てくると、面倒な作業は発生してしまいます。
ただ、これはどんなやり方でも避けられないものだとは思います。
from c2a-aobc.
ありがとうございます.たとえば c2a-aobc
に新しいファイルが追加されるような変更が入って,そのを c2a-aobc-hoge
に取り込みたくなったら CMakeや c2a-aobc-hoge.vcxproj
などの修正が必要になってしまいますが,もはやこれはどんなやり方でも避けられないということですよね.
from c2a-aobc.
そうであれば今の僕の理解と合っていそうなので,問題なく作業進められそうです
from c2a-aobc.
ファイル追加だけなら、CMakeFileの責任範囲をsubdirectoryで適切に分けていけば影響が少ないようにできるはずです。s2e-coreやc2a-coreでそうしていると思うので、確認して見てください。
vMicro用のvcxproj
はまた別ですが、これはCMakeから自動で生成できるようにするのが理想的ですね。(あとは、vMicro使わないようにできたら。。。とかですね。)
from c2a-aobc.
ありがとうございます.CMakeについてはそこまで心配していなかったのですが,どちらかといえばvcxprojの方がどうするのかなと気になっていた質問でした.ファイル追加のたびに手で追加するのは大変なので,CMakeで自動生成できるならそうするのに賛成です.vMicro使わなくて良くなる見込みについては, @sksat が考えてくれているところ...だと思います.
from c2a-aobc.
@suzuki-toshihir0 @sksat @meltingrabbit コンポI2Cアドレスについてどう変更していこうかと言うのを迷っています。
I2Cアドレスはここで定義されているので、うまく活かしたいのですが、どうしようかなと言う感じです。
c2a-coreとc2a-userの間のパラメータ設定などと同じような方針でも良いのかなとも思っているのですが、いかがでしょう?
from c2a-aobc.
私としてはcoreとuserの間のパラメータ設定管理方法(同じ名前でマクロを持っておいて,ユーザー側では読み出すものを切り替える)でよいと思います.
from c2a-aobc.
@suzuki-toshihir0 @sksat @meltingrabbit コメントを元にPR出してみましたので、確認をお願いします。
from c2a-aobc.
Related Issues (20)
- RWステータス取得コマンドのコメントを外し、ステータスチェックELを実装する HOT 1
- アプリタイムの再調整 HOT 1
- 磁気排他制御仕様更新に伴う三軸姿勢制御の検証
- 磁気排他制御仕様変更に伴うMTQ電気試験の実施
- 自動モード遷移カウンタをゼロクリアできるようにする
- 目標計算に対地表面相対速度を入れる HOT 4
- IGRF計算時の閾値を可変にする
- Bdotモードおよび太陽捕捉モードでGPSRを使えるようにする
- STT ON BCのbootまでの時間を延長する
- BC数の最大値を増やすことを検討する HOT 8
- EL/EHを整理する
- テレメエラーを出すコンポに対してはテレメ要求をしないようにFDIRを改修するか検討する
- devでvMicro buildができない HOT 2
- SagittaのVersion Telemetryがサブスクリプションできない
- BdotモードでMTQがまったく出力されない場合がある HOT 4
- 磁気センサバイアスの挙動がおかしい
- EL low noteのテレメの追加
- TLCのエラーカウンタテレメがない
- CONTROLテレメパケットが容量オーバーで下ろせない
- タイムラインが溢れることがあるかもしれない
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from c2a-aobc.