Fix component algorithm

[TomokiMochizuki]

概要

Fix component algorithm

Issue

• N/A

詳細

相対位置・姿勢観測センサに関するコンポーネントのアルゴリズムを改善

• corner cube reflector と laser emitterに関して
  • コンポーネントクラスを継承させて各ステップごとにposition_i_mなどを計算させるようにした。
  • 理由：
    • 今までの状況だと、複数衛星間で情報をやり取りする際に、その時点のposition_i_mではなく、1ステップ前や1ステップ後のposition_i_mを使用する場合があった。
      • 具体的に言うと、今の状態だとlaser_emitterがsatellite 1にあり、qpd_positioning_sensorが satellite 0にあるが、これを逆に搭載するとsatellite 1のqpd_positioning_sensorが状態量を更新するタイミングでlaser_emitterの状態量を更新するが、この時点において、S2E-FFの計算順序の観点から、すでにsatellite 0は1ステップ後の軌道情報を計算しているので、その値を用いてlaser_emitterの位置が計算されてしまう。このように、複数衛星間での情報をやり取りする際に、その時点での位置を確実に計算させることが重要であるので、Componentクラスを継承させて、衛星のdynamics_が更新されるタイミングとほとんど同じタイミングでコンポーネントを更新させるようにした。
        • このとき、上記に付随してまた別の問題が生じた。それは、番号の小さいsatelliteのコンポーネントから順番に計算するというアルゴリズムになっているため、番号の小さいsatelliteがlaser_emitterなどのデータを用いて相対位置を計算しようとしたときに、laser_emitterの位置はまだ更新されておらず、1ステップ前の値が残ってしまっている。そこで、Update関数を作成し、コンポを使用する際にはUpdate関数をたたくようにした。このUpdate関数は引数にcountを用いているため、異なるステップの状態のdynamicsを用いて計算することを防止している。
• qpd_positioning_sensorに関して
  • 位置を計算する際、配列を最初から順番に計算していて計算コストが高かったため、二分探索のアルゴリズムに変更した。

検証結果

影響範囲

XX系の動作がガラッと変わる，とか．

補足

何かあれば

注意

• 関連する Projects が存在する場合，それの紐付けを行うこと
• Assignees を設定すること
• 可能ならば Reviewers を設定すること
• 可能ならば priority ラベルを付けること

[200km]

こちら、元々のconer_cube_reflectorとlaser_distance_meterの方針では、

• coner_cube_reflectorの位置情報は、ConerCubeReflector::GetReflectorPosition_i_mの中で計算している
• laser_distance_meterでConerCubeReflector::GetReflectorPosition_i_mを呼び出していて、そこで相手衛星の位置・姿勢踏まえて計算されるので、最新の値が使われるはず

と思っています。なので、1step前のデータで計算されると言うことがないようにししたつもりなんですよね。

逆にConerCubeReflectorでComponentを継承して、情報更新アップデートを決めてしまうと、コンポーネントの更新頻度によっては過去のデータを使ってしまう気がしています。

なので、この修正が必ずしも良いと言えない気がしていますが、どう言う状況でしょうか？必要でしたら直接話したほうが早いかもですね。

[TomokiMochizuki]

こちら、文書で書くとやや煩雑になるので直接話して説明したいです。

[200km]

OKです。明日ミーティング予定だったと思うので、そこで話しましょう。