If rmfo is available, connect rmfo' force sensor ports instead of rh's force sensor ports. Otherwise, connect rh's force sensor ports.

[snozawa]

If rmfo is available, connect rmfo' force sensor ports instead of rh's force sensor ports.
Otherwise, connect rh's force sensor ports.

Background:
For Unstable RTC users, off_rfsensor from rmfo and rfsensor from rh are published.
However, unstable rtc users do not use rfsensor (not necessary).

Before this PR:
For unstable rtc users, rmfo's force sensor ports and rh's force sensor ports are connected to HrpsysSeqStateROSBridge and topics such as off_rfsensor and rfsensor are published.

After this PR:
For unstable rtc users, rmfo's force sensor ports are connected to HrpsysSeqStateROSBridge and topics such as off_rfsensor and rfsensor are published.
rmfo's values are copied to rhsensor for backward compatibility.

Behavior for stable rtc users does not change by this PR.

Related with:
fkanehiro/hrpsys-base#1057

[k-okada]

if we have fkanehiro/hrpsys-base#1057 (comment) feature, we do not need this change

[snozawa]

if we have fkanehiro/hrpsys-base#1057 (comment) feature, we do not need this change

I don't think so.
This PR is originally independent with fkanehiro/hrpsys-base#1057.
Connecting rh's force sensor ports are unused for unstable rtc users, so it would be preferable to remove them.

[snozawa]

すいません、
#981 (comment)
にさらに追記したいことがあったので、別途まとめてこちらに書きます。

[snozawa]

RMFOからの出力に関して、変更したい店は以下です。上記も含めて、主に２店あります。
RMFOに関してなので、Stable RTC環境は一切かわらないつもりの変更群です。以下Unstable RTC環境が対象です。
以下でいう「校正」は、RMFOが行っている「力オフセット除去とハンド・フットの質量・重心パラメータをさしひいておく」ことを指すとさせていただきます

• 現状
  • HrpsysSeqStateROSBridgeが、rhから力センサの値(校正なしの生値)を得てrfsensorをpublish, rmfoから力センサの値(校正あり)をえてoff_rfsensorをpublish
  • Eusは、前者を:force-vectorとして、後者を:off-force-vectorとしてアクセスする（subscribe)
• 問題
  • Unstable RTCユーザは、rhからくる生値は、校正されてなくてよくわからない値になってるはずなので、使う必要がない、使ってはいけない、rmfoの値でできてrhの値でできない処理がとくにない、などの問題があります
  • pr2eus/robot-interface.lなどに今は:force-vectorがないですが、後にいれるかもしれないことを考えると、off-force-vectorといったものよりforce-vectorなものがはいる気がしてきた
• 解決
  • Unstable RTC環境（RMFOがfindされたとき）では、rhからの出力ポートを接続しない(このPRの変更です)。シンプルにするために、または通信のオーバーヘッドをなくすの（https://github.com/fkanehiro/hrpsys-base/pull/1057）に関連しています。
  • off-force-vectorなどのoffな名前をつかわず、:force-vectorなどの無印の名前をつかうようにする。互換性のため、rmfoからの校正済みの値をrfsensor, off_rfsensorからpublishしつつ、eusのメソッドも、:off-force-vectorを残す。一方で、deprecatedですよ、とワーニングかエラーを出す（まだ部分的にしかこのPRに含まれないので、含みます）

上記の議論のいくつかは、数年くらい前からありました。
例えば、issueがみつかってないのでアレですが、rfsensorなどの値は、calibratedな値があればデフォルトでそれを出すべき、という議論がありました。
問題の項目であげていることに関しても、（意図せず使ってる場合をのぞいて）rmfoでなくてrhでないといけないというケースを、これまで数年くらいhrpsy + rosbridgeを運用していてなかったので（それ以前のratsのときを含めると５年以上なかったです）、接続しなくて良いのではという気持ちがあります。もちろん、rhでないといけないという具体的ニーズが今後でてきたらまた考えたいと思います。

[snozawa]

#981 (comment)
を満たすようにPRを更新しました。

[k-okada]

そもそも hrpsys から　raw_force_vector, force_vector をだして、rmfoのときはforce_vectorに校正済みで、そうでないときはforce_vectorに生値を出すのはどうでしょうか？

[snozawa]

そもそも hrpsys から　raw_force_vector, force_vector をだして、rmfoのときはforce_vectorに校正済みで、そうでないときはforce_vectorに生値を出すのはどうでしょうか？

こちらは、

• Stableなとき=RMFOがないとき
  RosBridgeのraw_force_vectorから、RobotHardwareの力のデータポートの値をだす
  RosBridgeのforce_vectorから、RobotHardwareの力のデータポートの値をだす
  結果、ROSBridgeからのraw_force_vectorとforce_vectorがおなじものになる
• Unstableなとき=RMFOがあるとき
  ROSBridgeのforce_vectorから、RMFOの構成済み力のポートの値をだす
  ROSBridgeのraw_force_vectorから、RobotHardwareの力のポートの値をだす
  結果、ROSBridgeからのraw_force_vector, force_vectorは別の値がでる

とすることによって、raw_force_vectorな値はどちらの場合でもだすことにする、ということでしょうか。
確かにこれで、
#981 (comment)
の問題２項目のうち、ROSBridgeからでるポートおよびeuslispのコードには統一感がでそうです。

一方で、使われてないポートが接続されてる問題は残っています。
raw_force_voectorはやはり使わないと思うのですが、いかがでしょうか。
raw_forceな値はどういった場合のために接続をしたほうが良いでしょうか。

[snozawa]

補足します。
ユーザな人からは、力の計測値の生値より、むしろreference値の方がなんパターンかでてたほうがうれしい、という声もありました（referenceとされてる値が、RTCによって違い得て、それらがでてくると嬉しいという声がありました）

[k-okada]

一方で、使われてないポートが接続されてる問題は残っています。

それは、bridge で誰かがsubscribeしたらポートをつなげて、そうでなければ、ポートを一旦切り離す、というのがいい気がします．
想定しているのは、rvizで表示をON/OFFするというレベルです．

で、eusはeusで別に考えるという感じです．

◉ Kei Okada

2016年10月27日 20:50 Shunichi Nozawa [email protected]:

そもそも hrpsys から raw_force_vector, force_vector をだして、rmfoのときはforce_
vectorに校正済みで、そうでないときはforce_vectorに生値を出すのはどうでしょうか？

こちらは、

• Stableなとき=RMFOがないとき
  RosBridgeのraw_force_vectorから、RobotHardwareの力のデータポートの値をだす
  RosBridgeのforce_vectorから、RobotHardwareの力のデータポートの値をだす
  結果、ROSBridgeからのraw_force_vectorとforce_vectorがおなじものになる
• Unstableなとき=RMFOがあるとき
  ROSBridgeのforce_vectorから、RMFOの構成済み力のポートの値をだす
  ROSBridgeのraw_force_vectorから、RobotHardwareの力のポートの値をだす
  結果、ROSBridgeからのraw_force_vector, force_vectorは別の値がでる

とすることによって、raw_force_vectorな値はどちらの場合でもだすことにする、ということでしょうか。
確かにこれで、
#981 (comment)
#981 (comment)
の問題２項目のうち、ROSBridgeからでるポートおよびeuslispのコードには統一感がでそうです。

一方で、使われてないポートが接続されてる問題は残っています。
raw_force_voectorはやはり使わないと思うのですが、いかがでしょうか。
raw_forceな値はどういった場合のために接続をしたほうが良いでしょうか。

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#981 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAeG3AknVsbvXXHwU5PiH_OMOdtUXY_dks5q4JALgaJpZM4Kea68
.

[snozawa]

すいません、遅くなりました。

こちらに関してなのですが、まず
fkanehiro/hrpsys-base#1057 (comment)
の

で、publishしたものは誰が使うんだろう？　ぱっと考えると joint_states, 手先足先の力センサ、ぐらいしか使わない気がするんだけど、

の全員がよく使うポートでないものにも２種類あると思ってまして、
(A) 必要な人はいる(orいた)が、マニアックで全員必要でなさそうなもの(例:controlSwingSupportTime, 歩行指令に燗するもので、ゆう脚着地までの残り時間。@eisoku9618が使って以降あまりつかわれてなさそう)
(B) 機能的に他のものでカバーできるので不要と思われるもの(例:Unstable RTCでRFMO利用時の、RobotHardwareから得られる力の値)

があると思います。
前者（A)に対しては、

それは、bridge で誰かがsubscribeしたらポートをつなげて、そうでなければ、ポートを一旦切り離す、というのがいい気がします．

でご指摘いただいているものを考慮してくのが良いかと思っています。

後者（B)については、

想定しているのは、rvizで表示をON/OFFするというレベルです．

が多分後者（B)の力センサの利用例としてrvizをあげていただいていると思ってるのですが、
こちらもrvizに表示するものはUnstable環境でRMFO利用可能な場合には、校正後のものを表示すれば良いのでやはりいらないと思うのですが、いかがでしょうか。
また
#981 (comment)
で話を進めさせていただいているとおり、Unstable, Stableで力センサに対して同じプログラムが動くように

• Stableの場合はrfsensorなどにRobotHardwareからのポートがくる
• Unstabelの場合はrfsensorなどにRMFOからのポートがくる

としていることを想定してますので、unstableのときいにrvizの場合もraw_forceでなく校正済みのforceをいれたほうが同じプログラムで動くと思います（rvizのconfigにrfsensorとだけかくことになる。raw_rfsensorでなくて）

ちなみに、RobotHardwareから出している力センサの値とRMFOから出している力センサの値の違いは、
ざっくりいうとハンド・フットの重さを差し引いてるか、の違いです。ですので、

• ハンド・フットの重さを特に設定してなければ、RobothardwareとRMFO同じ値になります
• ハンドフットの重さパラメタは定数なので、RMFOの校正済みの値から姿勢を考慮しつつハンド・フットなどの重さを足し込むと、RobotHardwareの生値が再現できます。

という特徴があります。後者は、もしRobothardwareからの生値ポートがなくなっても、どうしても欲しい人はRMFOからのポートの値にオフセットを足し込めば同等のものが得られます。

以上長文で失礼しましたがまとめますと、どれくらい使ってるかでポートには(A)、（B)の２種類あり、（A）はおっしゃる方法を考慮していく必要があると思っていまして、（B)は不要なようですので削除するのはいかがでしょうか、という提案になります。

ちなみに（A)向けにsubscribeに応じてポート接続をいいかんじにする方法を考えてみてますが、

• 初期起動時以降でポートのconnect自体をオンラインでやると、実時間スレッドを止めてしまう状況がある
• ポート接続はいままでどおり初期起動時にやり、データポートの通信方法をpush型でなくpull型にするとできそう。ただし、pull型にしたらスレッドセーフでないかもしれなくて、Add a data port to output state values as a serialized data fkanehiro/hrpsys-base#1057 (comment) などを追っていく必要がありそう

といったかんじのことを考えてみています。

[k-okada]

(A) 必要な人はいる(orいた)が、マニアックで全員必要でなさそうなもの(例:controlSwingSupportTime, 歩行指令に燗するもので、ゆう脚着地までの残り時間。@eisoku9618が使って以降あまりつかわれてなさそう)
(B) 機能的に他のものでカバーできるので不要と思われるもの(例:Unstable RTCでRFMO利用時の、RobotHardwareから得られる力の値)

一般論として、不要か不要でないか、は、結局不要だと思っても、そもそも最初に作った段階では必要だったわけで、今は必要ないように思って重、後で必要です、とかなったりするので、使えるようにはしておくのでいいと思うのと、
研究室に限った話では、この人が卒業したら誰も使わないなぁ、というのは、そもそも作らない／マージしない、というのもあると思います．

[snozawa]

一般論として、不要か不要でないか、は、結局不要だと思っても、そもそも最初に作った段階では必要だったわけで、今は必要ないように思って重、後で必要です、とかなったりするので、使えるようにはしておくのでいいと思うのと、

これは先ほどのケース２とおりで違うと思っていて、
(A) 必要な人はいる(orいた)が、マニアックで全員必要でなさそうなもの(例:controlSwingSupportTime, 歩行指令に燗するもので、ゆう脚着地までの残り時間。@eisoku9618が使って以降あまりつかわれてなさそう)
(B) 機能的に他のものでカバーできるので不要と思われるもの(例:Unstable RTCでRFMO利用時の、RobotHardwareから得られる力の値)

の(A)は、そのポートがないと同じことをやるポート・方法の代替がないので、一時的に不要と思っても議論が必要だと思いますし、そもそもそれをマージしない、というところの判断もおっしゃるとおり重要だと思います。
(B)は、古い方法は完全にdeprecatedで新しいもので置き換えられるものでになるので、残しとくのにデメリットがないのであれば残しで良いと思いますが、今回は通信で実時間スレッドが圧迫される現象がでてきてしまったので、一考の余地がありなのかなと思いました。