STTテレメの追加

[seki-hiro]

Issue

#21

詳細

メーカーと議論し、軌道上でのパラメータ調整のために優先度の高いテレメトリを追加した。

検証結果

設定parameter

使用したコマンド

SAGITTA_TELEMETRY.opsとして追加

得られたテレメ

• POWER 0x0b
  • テレメトリは来たが、全ての電流電圧が-1となっている。単位も不明なので、メーカーに問い合わせる。

c0 21 84 0b    00 bf eb cc    77 ec 5c 48    44 01 5d 03    00 00 00 80    bf 00 00 80    bf 00 00 80    bf 00 00 80    bf 00 00 80    bf 00 00 80    bf 00 00 80    bf 00 00 80    bf 00 00 80    bf 00 00 80    bf 00 00 80    bf 00 00 80    bf 00 00 80    bf 00 00 80    bf 00 00 80    bf 00 00 80    bf ad d0 ec    44 c0 

• SOLUTION 0x18
  • 問題なし

c0 21 84 18    00 01 da 99    cc 94 59 2b    5d 01 5d 03    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 08    08 f5 46 ce    c0 

• TEMPERATURE 0x1b
  • CMOSの温度が271度と表示される。以前の問い合わせでは、INTERNAL USEとのことだったが、新しいUSER MANUALにそのような記載はないので、再度確認する。

c0 21 84 1b    00 83 4a 21    99 8c 72 f4    3c 01 5d 03    00 00 00 e8    41 00 80 87    43 cd cc d6    41 bc de c7    6e c0 

• HISTOGRAM 0x1c
  • data部分が144byte、溢れている

[2023/07/26 12:57:07R] sagitta_rx_data: 144 Bytes 
c0 21 84 1c    00 75 ce d2    64 2c eb 00    81 01 5d 03    00 00 00 00    00 00 00 00    00 01 00 00    00 66 05 00    00 45 91 08    00 51 69 07    00 03 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 c3 07 00    00 f0 d1 09    00 4a 26 06    00 03 00 00    00 00 00 00    00 00 00 00    00 05 04 00    00 00 00 00    00 01 00 00    00 f9 00 00    00 1b e8 06    00 dc 12 09    00 0a 00 00    00 00 00 00    00 00 00 00    00 08 04 00    00 0
[2023/07/26 12:57:07R] 1 00 00    00 08 00 00    00 d0 02 00    00 dc e4 08    
DSSC_get_rec_status(stream_config)->status_code: 3
[2023/07/26 12:57:07R] sagitta_rx_data: 22 Bytes 
c0 3b 14 07    00 08 00 00    00 00 00 00    00 00 00 00    00 6a 3a 11    88 c0 
DSSC_get_rec_status(stream_config)->status_code: 1

• BLOBS 0x24
  • 問題なし

c0 21 84 24    00 62 cd 75    85 14 55 bd    4a 01 5d 03    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 f2    b4 d5 23 c0    

• CENTROIDS 0x25
  • data部分が146byte、溢れている

[2023/07/26 12:42:50R] sagitta_rx_data: 144 Bytes 
c0 21 84 25    00 fa 9f 7d    7e 94 19 e9    4d 01 5d 03    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 0
[2023/07/26 12:42:50R] 0 00 00    00 00 00 00    00 00 00 00    00 00 00 00    
DSSC_get_rec_status(stream_config)->status_code: 3
[2023/07/26 12:42:50R] sagitta_rx_data: 24 Bytes 
c0 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 fb    27 46 30 c0    
DSSC_get_rec_status(stream_config)->status_code: 1

• AUTO BLOB 0x27
  • 問題なし

c0 21 84 27    00 8e 0a 6d    55 a6 c3 34    55 01 5d 03    00 00 00 70    41 21 2a 44    1b c0 

• MATCHED CENTROIDS 0x28
  • data部分が321byte、溢れている。bufferの2倍以上に相当するため、status_code（3->0）も他の挙動（3->1）と異なる。

[2023/07/26 12:45:30R] sagitta_rx_data: 144 Bytes 
c0 21 84 28    00 86 03 08    75 14 9c 78    57 01 5d 03    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 0
[2023/07/26 12:45:30R] 0 00 00    00 00 00 00    00 00 00 00    00 00 00 00    
DSSC_get_rec_status(stream_config)->status_code: 3
[2023/07/26 12:45:31R] sagitta_rx_data: 144 Bytes 
00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 00 00 00    00 0
[2023/07/26 12:45:31R] 0 00 00    00 00 00 00    00 00 00 00    00 00 00 00    
DSSC_get_rec_status(stream_config)->status_code: 0

ビルドチェック (どちらもチェック)

• SILSでのビルドチェックに通った(CIで確認)
• vMicroでのビルドチェックに通った

動作確認チェック (いずれかをチェック)

• SILSでアルゴリズムが想定通りに動いた
• 実機でアルゴリズムが想定通りに動いた
• (テレコマ試験の場合)コマンドファイルを使った試験をパスした

試験結果詳細記述場所 or 詳細ログ保存場所へのリンク

• 図や表で記述する

補足

NA

[seki-hiro]

テレメDBの更新と実機検証をこの後実施するためWIPとしていますが、ドライバ部分の更新は完了しているので、もしお手隙のタイミングあればご確認お願いします。

[200km]

とりあえず現時点で気になる部分にコメントをつけました。
詳細はテレコマ修正や試験後にみます。

[seki-hiro]

検証結果に記載のとおり、テレメが下りてくることを確認しました。ただし、histogram, centroids, matchedstarsは、それぞれdata部分のサイズが144, 146, 321であり、bufferが溢れています。

このPRでは、histogram, centroids, matchedstarsに関する部分はコメントアウトし、#39 対応後にコメントアウトを外す方針にしたいです。

メモ：現在の受信バッファサイズは、Settings/DriverSuper/driver_super_params.hの#define DS_IF_RX_BUFFER_SIZE (144)で規定されている。

[seki-hiro]

firmwareがアップデートされたことに伴い、既存のパラメータだと検証ができなかったので、commit 06abd52 を加えています。

そのほかのfirmware update対応は別issue https://github.com/ut-issl/6u-aocs-task/issues/41 を切ったので、そちらで行いたいと思います。

[seki-hiro]

POWERの単位・-1埋めされる理由・cmos tempが271degCである理由はメーカーに確認中です。

[seki-hiro]

@chutaro テレコマの変更一旦pushしたので、コンフリクト解除お願いします。

[chutaro]

@seki-hiro コンフリクト解消できた気がします。

[seki-hiro]

@chutaro ありがとうございます！

[seki-hiro]

cmos tempが271degCである理由

We obtain similar values as you. Hence, there seems to be something wrong with the calibration values of the datasheet or the readout on our side. We’ll investigate this further and let you know if we find something.

The FPGA and MCU temperature should be fine. For now, I would suggest ignoring the CMOS temperature in the telemetry.

とのことなので、CMOSテレメはテレコマの方でコメントアウトします。

POWERが-1埋めされる理由

テレコマをメーカーに送信してみてもらっているところですが、テレコマフレーム自体には問題なく、中身の値の問題なので、別issueで切り出したいと思います。 #160

[seki-hiro]

@200km テレコマ回りのマージが遅いとコンフリクトを起こしやすいので、なるべくissueにきりだして、動くところは先にマージしたいと思います。再度レビューお願いします。

[200km]

一点だけ気になる点がありました。他は小さなコメントなので問題ないと思います。
次の修正でapproveになると思います。

[200km]

[Q] この18というのは、FPGAの1.8V電源系統という意味ですかね？同様にその下の25は2.5V系統？この辺り分かっていたら、電圧の正常値がなんなのかというのがわかりそうです。

あと、全体的にコメントの //!<のインデントを揃えてもらえると綺麗かなと思います。

[seki-hiro]

メーカーから、正常値の例が送られてきています。それを見る限り、確かに18は1.8V, 25は2.5Vに相当しそうです。

インデント揃えました。

[200km]

それを見る限り、確かに18は1.8V, 25は2.5Vに相当しそうです

それであれば、コメントも FPGA1.8V系統などの書き方が良いように思います。

[seki-hiro]

こちらも修正しました

[200km]

[MUST] ここ、二行下の下記の記述から書き換わっているのは間違いなのでは？と思いました。ここの意図としてはquaternion_i2cとquaternion_i2bが矛盾なく値が入るべきという意図になっています。

sagitta_driver->info.quaternion_i2b = QUATERNION_product(sagitta_driver->info.quaternion_i2c,
                                                           sagitta_driver->info.frame_transform_c2b);

[seki-hiro]

info.telemetry.solution.quaternion_i2cはあくまでテレメの一つなので、memset(&(sagitta_driver->info.telemetry), 0x00, sizeof(sagitta_driver->info.telemetry));で他のテレメ群と一緒に0埋めする方が自然かと思いそうしています。

実際にテレメが来た時に

sagitta_driver->info.quaternion_i2b = QUATERNION_product(sagitta_driver->info.telemetry.solution.quaternion_i2c,
                                                           sagitta_driver->info.frame_transform_c2b);

で対応関係が取られます。テレメが来ていない、かつDI側でsagitta_driver->info.frame_transform_c2bに正しい座標変換が入る前の初期化の時点で、矛盾なく値が入っている必要はないかと思いますが、いかがでしょうか？

[200km]

前の実装意図は、

• quaternionが全て0になるというのはあり得ないので、quaternion_i2cを0埋めするのは不自然である。よって(0,0,0,1)にしている
• quaternion_i2cに値が入っているなら、quaternion_i2bも変換をかませて矛盾ない値にするべき
• テレメが来る前の状態で数値的に明らかにあり得ない値が入っているのは、バグや利用者の誤解の原因になりそうで気になる

という感じです。
他のテレメ群を0埋めしておいて、その後に特定のテレメのみ適切な初期値を入れるという感じで手間なく実装できると思うので、そうして欲しいです。

[seki-hiro]

他のコンポも見てみましたが、sun_vec_compoなどもテレメが来る前から値を入れているんですね。STTだけであれば、0埋めしておくことでテレメが来たかどうかがわかるなどのメリットもありそうですが、全体の方針ということだと思うので、個別に値を入れるようにしたいと思います。

[200km]

はい。定義上あり得ない値は入れない方針です。
テレメがきたかどうかわかるという話は、

• 初期値とfloatレベルで全く同じテレメがくる可能性はかなり低いので、何かしら値が来たことは0埋めしないでも分かる可能性がかなり高いはず
• その他のテレメ情報（特に存在するなら時刻情報やテレメカウンタ）からもテレメが来たかどうかわかる

と思うので、Quaternionを0埋めするメリットにはならないかなと思います。

[200km]

別PR #161 で気になったことですが、STTテレメサイズが大きくなっていますが、STT側のSAGITTA_RX_MAX_FRAME_SIZEは小さな値のままで良いのでしたっけ？

https://github.com/ut-issl/c2a-aobc/pull/137/files#diff-d3edefa0a79876ff5a3f7a19257462c596bdda18873cba462482cc99cd9fcd3fL19

関連して、RWも最近テレメが追加された気がしていて、下記の値に更新がないか気になりました(動作確認されているので大丈夫だと思いますが)。一応確認お願いします。

c2a-aobc/src/src_user/Drivers/Aocs/rw0003.c

Line 38 in 605722a

#define RW0003_RX_MAX_FRAME_SIZE (15) //!< SLIPを考慮した(現時点での)最大テレメフレーム長( 9 + 6 )

[seki-hiro]

DS側の対応が済んだら、SAGITTA_RX_MAX_FRAME_SIZEも大きくして、テレメ解釈できるようにする必要がありそうです。

RWは追加分も温度・回転数テレメと同じfloatなので問題ないと思います。

    if (read_address == RW0003_kReadAddressTemperature_)
    {
      memcpy(&rw0003_driver->info.temperature_degC, decoded_rx_data + pos, sizeof(float));
    }
    else if (read_address == RW0003_kReadAddressSpeed_)
    {
      memcpy(&rw0003_driver->info.speed_rad_s, decoded_rx_data + pos, sizeof(float));
    }
    else if (read_address == RW0003_kReadAddressVDD_)
    {
      memcpy(&rw0003_driver->info.vdd_V, decoded_rx_data + pos, sizeof(float));
    }
    else if (read_address == RW0003_kReadAddressSEUCount_)
    {
      memcpy(&rw0003_driver->info.seu_count, decoded_rx_data + pos, sizeof(float));
    }
    else if (read_address == RW0003_kReadAddressFaultState_)
    {
      memcpy(&rw0003_driver->info.fault_state, decoded_rx_data + pos, sizeof(float));
    }

[seki-hiro]

vMicroビルド再度確認できたので、ご確認お願いします。