GPS-R関連のリファクタ

[200km]

概要

GPS-R関連のリファクタ

詳細

• GPS時刻構造体を作る
  • Week, msecで独立変数となっているGPS時刻について，Week, msecを統合した構造体を定義する
• ボーレート変更コマンドに関するバグ修正 #155
• エラーフラグFDIR実装検討 #156
• GPS時刻のspikeフィルタ実装 (含 uint32型spike filter実装)
• AOCS managerでのreference_jday更新部分を修正する

close条件

リファクタしたら

備考

NA

注意

NA

[t-hosonuma]

@200km @seki-hiro
こちらの，AOCS managerでのreference_jday更新部分を修正するについて，実装方針どうするかご意見伺いたく…．
この話は，下記3点の内容で，Jdayの更新頻度に関する仮定に齟齬があることが問題という認識です．

1. APP_TIME_SPACE_CALC_exec_やAOCS_MANAGER_set_reference_jdayが10Hzで呼ばれて，その中でaocs_manager_.reference_jdayをGPSデータを用いて更新している
2. それに対し，現状，GPSのTLMデータは1Hzでしか更新されないため，aocs_manager_.reference_jdayが実質1Hz更新になっている（GPSが可視の際には，1．の処理が，10回同じ値をaocs_manager_.reference_jdayに書くことになる）
3. その上で，例えば，APP_GPSROP_exec_等の，aocs_manager_.reference_jdayを参照する関数が10Hzで呼ばれているため， 軌道位置計算等も10Hz更新が期待されている様に見えるのに対し，実質1Hz更新になっている

当初は単純に，1の中で，GPSのTLMデータが1Hz頻度なことを加味して，TLM受信時のOBC時刻と現在のOBC時刻の差分を基に，10Hz分は内挿することが考えられる様に思いました．
が，下記の様な理由から，1の処理はこのままにして，3の時刻更新以外のアプリ内でJdayを参照する側で対応した方が拡張性が高い気もし始めたのですが，どういう方針が良いでしょうか…？

• 1の処理を直す当初の方針だと，結局，3の処理は1の処理以下の実行頻度に抑えないと，参照時に時刻の齟齬が出る
• 一方で，1の処理では，最後にJday更新につかったGPSのTLMデータを受信した時のOBC時刻をaocs_manager_.reference_jdayとセットでAOCSマネージャに渡しているため，reference_jdayを使うアプリ側で現在時刻を参照すれば，アプリ実行時のjdayの値は1の処理頻度に関係なく更新できる
• そうすると，むしろ1の処理はあくまで，GPS時刻を，他のアプリで使う際の時刻の参照起点となるJday (reference_jday)に変換するだけと割り切って，実際の他アプリ実行時のJday (current_jday)はreference_jdayとその値更新時のOBC時刻を基に，各アプリで計算する方が，アプリ間の実行頻度制約を気にせずに今後の実装作業ができて，齟齬を防ぎやすいかも？

ただ，各アプリは各々実行時のcurrent_jdayを使う，という方針は，これはこれで時刻の一元管理を放棄しているので，ちょっと微妙かもしれないと思っており，正直どうするのがベスト，という意見は個人的には持っていないですが…

[seki-hiro]

GPSのTLMデータは1Hzでしか更新されない

GPSのDIは10Hzで呼び出されていますが、コンポーネント側で出力するTLMが1Hzということでしょうか？

個人的には、各アプリで時刻の計算を入れるのは手間な気がしていて、1の処理を直す当初の方針でどうにかなるなら、それで時刻の一元管理ができるとベストな気がしています。あとは、3の処理を1の処理よりも高頻度にしたい需要が、どれだけあるかという話になりそうです。現状アプリの最高頻度は10Hzと思うので、需要はあまりない気もしましたが、いかがでしょうか？

[t-hosonuma]

コンポーネント側で出力するTLMが1Hz

です．

3の処理を1の処理よりも高頻度にしたい需要

3の処理を100Hzにしたい，とかよりは，1の処理を（他処理とのローテータ―にする等で）10Hz以外にしたい，みたいな話はアプリの数によってはあり得なくはない気がしています．
（実際，過去の衛星等では1Hzのものもあった気がしますし．）
直近の研究室衛星については1,3の処理いずれも同じ10Hz頻度で呼ぶ前提で良いがしますが，Opensourceという観点からは，前提について制約が少ない方が良いかも，思わなくはないです．

[t-hosonuma]

@200km @seki-hiro

GPS時刻構造体を作る

について，色んなところで使っていて，改修範囲が広いので，どこで該当構造体を定義すべきか，改修前に決めさせて下さい．
OEMに限らない一般的なものなので，oem7600.hでOEM7600_GPS_Time_OF_WEEKみたいな感じで定義するのは少し違和感があります．（あちこちでoem7600.hをincludeすることになりそうでそれも違和感）
ので，anoce_manager.hでAOCS_MANAGER_GPS_Time_OF_WEEKみたいな感じで定義するので良いでしょうか？
（或いは，coreのobc_time.hで定義するという方針もありえる…？）

[200km]

バッファサイズを個別指定できるようになったので、その部分も含めてリファクタをお願いします。