座標変換をplot_method.pyで行いたい

[rkoyama1623-2021]

センサ座標を手先座標やground座標に変換する際，現在の仕様だと下記の課題があります．
例えば，手先センサの値をground座標にして，x,y,z座標をプロットしたいとすると，
plot.yaml

rmfo_off_rhsensor_world:
  func: rh_force_in_foot_mid_coords
  data:
    - { log: rmfo_off_rhsensor, column: [0-5] } # force vector in sensor coordinate
    - { log: st_q, column: [0-33] } # angle vector

layout.yaml

larm off_force (in world):
  legends:
    - { key: rmfo_off_lhsensor_world, id: [0-2], label: 'fz (world)'}

のように書くと思いますが，以下のような問題が出てきます．

1. plot.yamlのfuncは，"rarm", "ground"など，どの座標からどの座標へ変換するのかという追加の引数を渡せないと，funcの中で，if文の直書きが必要になる．
2. 座標変換を1度行うと，x,y,zの3軸が一度に計算できるが，現在の仕様だと，layout.yamlの[0-2]で3回計算が回ってしまう．
3. 2と似ているが， rmfo_off_lhsensor_world[0]は， rmfo_off_lhsensor[0]から計算されるわけではないのに，現在の仕様だと，入力としてrmfo_off_lhsensor[0]が入力と解釈されてしまう．
4. 左手の座標変換と右手の座標変換がある場合，左手と右手の座標変換それぞれで，angle-vector＋FKの計算が回ってしまう．

この解決策としては，

1. plot.yamlのルールを変更する
2. 現在，plot_xxxの中で，プロット用のデータ生成とプロットを同時におこなっているが，両者を分離する．

が有りえて，2が良いと思っています．
それから，plot.yamlとplot_method.pyは，一つのpythonクラスにまとめて，ロボット毎の差異はクラス継承と，メンバ変数のセット（jointの数など）で対応する方が良いのではないかと最近思っています．

[kyawawa]

データ生成について，決まっていることをこちらでまとめていただいても良いでしょうか？
なんとなくプロット用データ(生値，加工済)を1つの辞書にまとめることは分かるのですが，それをするのにplot.yamlが必要になりそうな気がして，よく分からなくなってしまいました

例えばcapture pointを算出するのに重心位置(x, z)，速度(x)が必要になりますが，その関係をどこに書くか．
辞書としてどのような命名で格納するか，みたいなのは現在のplot.yaml以外の解決法は出ていますか？

[rkoyama1623-2021]

プロトタイプとしては，
https://github.com/rkoyama1623/log_plotter/blob/no-yaml2/src/log_plotter/test_target.py#L53-L55
のような感じを検討していますが，いかがでしょう？

$ python test_target.py

以下はもう少し詳しい内容です．

plot.yamlに書いていることは，

1. ある凡例が依存するログファイルの名前
2. データ生成に必要な関数

なので,関数定義の際にデコレータでその情報を追記するという構成です．
wattの場合は，

@target.TimedTarget.from_func(name='watt', depends={'RobotHardware0_dq','RobotHardware0_tau'})
def calc_watt(index, target_dict, *args, **kwargs):
    dq = target_dict['RobotHardware0_dq'].get_y_data(index)
    tau = target_dict['RobotHardware0_tau'].get_y_data(index)
    return dq * tau

のように書くと，calc_watt関数を用いて凡例用のデータを計算するクラスが裏で生成されて，辞書に登録されます．
上の例では，'watt'という名前で辞書に登録し，depends=...で必要なログファイルを与えています．

複雑な処理をシたい場合は，抽象凡例クラスを継承して，
https://github.com/rkoyama1623/log_plotter/blob/no-yaml2/src/log_plotter/test_target.py#L7-L12
内部処理は各自書いて，個別に辞書に登録するという流れです．

[kyawawa]

すみません，遅くなりました
だいぶpythonを理解していない状態での質問ですが，現在の仕様に比べて良くなったことはfuncが引数を取れるというところでしょうか？
plot.yamlよりも記述量が増えそう？

[kindsenior]

一瞬話したメモとしては

calc_watt関数を用いて凡例用のデータを計算するクラスが裏で生成されて，辞書に登録されます．

の「クラスが裏で生成される」(https://github.com/rkoyama1623/log_plotter/blob/no-yaml2/src/log_plotter/target.py#L110 )が微妙ということ(合ってるかな？)

[rkoyama1623-2021]

plot.yamlよりも記述量が増えそう？

plot.yamlに書いていたのは，デコレータの部分だけなのであまり増えていないと思ったのですが，
plot.yamlを維持することも可能ではあります．
また，現在のplot.yamlのなかのcolumnは無くても用が足りると思い，デコレータの中では書いていないです．

現在の仕様に比べて良くなったことはfuncが引数を取れるというところでしょうか？

それもあります．（layout.yamlからグラフにoffsetを載せるなどの用途）
この部分の実装の目標としては，プロットしたいデータへアクセスしたときに，そのデータを計算する枠組みです．実装上の変更は，

1. 一つの判例(ex. watt)に対して，一つのクラスを割り当てるようにした
2. 判例を束ねる辞書形式のクラスをインスタンス化すると，1回のログのデータの操作に必要な辞書ができる

です．
1の目的は，判例ごとにデータの生成方法と計算結果の保存方法が色々なので，判例クラスのインターフェイスだけ決めておいて，実装は，用途に合わせて変更できるようにしたということです．
2の目的は，例えば，実験Aのログのst_qと実験Bのログのst_qを別の辞書で管理するためです．
あと，実装の構成とは直接関係ないですが，ログをそのままプロットするだけの場合は，何も定義しなくて良いようになっています．

「クラスが裏で生成される」が微妙

クラスの自動生成を使用している箇所は，
https://github.com/rkoyama1623/log_plotter/blob/no-yaml2/src/log_plotter/target.py#L114
https://github.com/rkoyama1623/log_plotter/blob/no-yaml2/src/log_plotter/target.py#L35
https://github.com/rkoyama1623/log_plotter/blob/no-yaml2/src/log_plotter/target.py#L42
です．
https://github.com/rkoyama1623/log_plotter/blob/no-yaml2/src/log_plotter/target.py#L114
では，TimedTarget(x軸が時刻の判例)を継承して，funcメソッドをoverwriteしたクラスをclsに代入しています．
複雑な計算をする判例を追加したい場合は，自分でクラスを定義し，よくある計算方法の判例は，自動でクラスを定義して追加するという構成です．ソースコードを自動生成するわけではないので我慢の範囲内？かなと思いこうしました．

クラスの自動生成を回避する方法としては，データの計算方法を定義するクラスと，データを格納するクラスを分離するという方法がありますが，データの格納方法に対する自由度が減ります．

[rkoyama1623-2021]

https://github.com/spotify/luigi

[rkoyama1623-2021]

前回の話し合いの結果をドキュメント化しました．
https://github.com/rkoyama1623/log_plotter/wiki/structure

すべての凡例は，pathというキーワード引数を受け取ってもバグらないように作る（引数を利用シなくても良い）というのが，追加の制約です．

[rkoyama1623-2021]

！！

[Tnoriaki]

??