DRC反省点

[garaemon]

DRC終わったので反省点を列挙しましょう

• HRP2のvの計算機性能が低すぎる。
  • BRIXへ変更予定. JAXONもBRIX二台体制へ --> メールベースで議論へ
• ロボットとfcの間の通信を信頼しすぎた。この間も通信は途切れると考えてシステム構成すべきだった。
  • ここもroscoreを分けるべきか?
• 立ち上げるプログラムが多すぎて全てがちゃんと立ち上がらないことがある
  • check_sanityよりは常にdiagnosticsが働いているべき
  • rqt_robot_monitor対応
• 認識のプログラムがうまく動かないことがあるが、それはなぜか.
• 常時ログ取りの仕組みが必要
• シミュレーション環境の不備
  • ビジョンや点群もシミュレーション出来なくてはダメ
  • :white_check_mark: 欲しいもの１：センサ入力としてビジョン・点群がとれて、ロボットの動作的にはkinematics onlyなシミュレーション（ビジョンあり動作の確認用）
  • 欲しいもの２：普通センサフィードバック入れられるシミュレーション（impedance controller, STなどセンサフィードバックの確認用）
• オドメトリが信頼できない
  • SLAM?
  • エンコーダ情報＋FKでオドメトリ計算できないか？
• 把持できたか、などの確認が不足
• burstのデータを待ちすぎている
• JAXONのモータの温度が高い
• JAXONギアとび
• 転倒しそうなときに動作を止める (特にマニピュレーション時にマニピュレーション動作を止める)
  • :white_check_mark: 両足平の圧力中心をrvizで表示する。
  • 両足圧力中心がエッジにきて危なそうなら、動作を止める（seq, sh系）。
  • 両足圧力中心がエッジにきて危なそうなら、歩行動作を止める（abc）。
  • 圧力中心でなくて重心位置速度を監視する方がよい？
• 計算機のローカルな設定が違うと効率が下がるので共通bashrc/emacsなどをちゃんと決めるべき
  • 現状おすすめ設定をprog/scripts/dot-files/dot.emacsに追加？
• 歩くのを速くしたい
  • 特に，(i)歩幅が長くなる，(ii)go-posのフットステップ計画が賢くなって歩数が少なくなる，と速くなりそう
• :white_check_mark: 歩くのを途中で止められるようにしたい
• 実機に動作を送る前に，seqの補間の様子やabcの歩行動作を見られるようにしたい
  • シミュレーション時にはhrpsys-simulator上で確かめられるが，シミュレータを立ち上げなくてもRviz上などで見られると嬉しい
• RRTのようなプランニングはなくてもいいので、簡単な点群との衝突判定は事前にしたい.
• angle-vectorを送るときの補間時間を自動でいい感じに設定できるようにしたい
  • 関節速度リミットを考慮して自動で決めるモードはありますが，abc,stでバランス補償しきれない運動量変化をだいたいでいいので考慮してくれるモードも欲しい
• self-collisionを検知したときにどのように対処すべきかを考える
• 転んでもPCが落ちないようにしたい
  • 電源とPCIの接触が問題？
• Ether が切れる問題を何とかする
  • 外部のNICカードを使う　（HDDで２スロットつかっているけど，１スロットでなんとかなるようにする）
  • BRIXにする
• 外から電源が切れるようにする
  • Etherが付いているArduinoかなにかで電源スイッチをつなげてリセットをかける

[snozawa]

:+1: いくつかアップデートしました。

[snozawa]

計算機のローカルな設定が違うと効率が下がるので共通bashrc/emacsなどをちゃんと決めるべき

これはprog/scripts/dot-filesのものをjsk_commonなどに追加して使ってもらうかんじでしょうか。

[snozawa]

欲しいもの１：センサ入力としてビジョン・点群がとれて、ロボットの動作的にはkinematics onlyなシミュレーション（ビジョンあり動作の確認用）

こちらは、現状の候補は

• gazeboは点群が実機と同様にだせるので、gazeboでkinematics onlyモードをつくる＝＞ふるたくんが試していて、むずかしそうだった
• hrpsys-simulatorはkinematics onlyモードがあるので、hrpsys-simulator (かchoreonoid)で点群を出せるようにする＝＞(https://github.com/fkanehiro/hrpsys-base/issues/684)
• @k-okada先生の案で、実はEuslispにしてしまう。個人的にはだいぶアリなきがしてます。

[robograffitti]

@garaemon

オドメトリが信頼できない SLAM?

オドメトリがマニピュレーションの時にずれるというのは， 認識の姿勢からマニピュレーションの動作中にずれるということでよいでしょうか？ マニピュレーション動作中に頭を動かしている時にビジョンでSLAMしていれば， そのずれを小さくできるのではということで合ってますか？

[garaemon]

@yoshimalucky 移動量が指令値と違うのでSLAMというかvisual odometoryを使えれば良くなるかもしれない、ということです

[garaemon]

計算機のローカルな設定が違うと効率が下がるので共通bashrc/emacsなどをちゃんと決めるべき

これはprog/scripts/dot-filesのものをjsk_commonなどに追加して使ってもらうかんじでしょうか。

はい、そうです。scripts/dot-filesを復活させて、共用アカウント・デモアカウントはそれを使うことを必須にしたいなと思います

[robograffitti]

@garaemon 移動量が指令値と違うので

移動量と指令値の差は大きければ，目視で確認できることもありますが，ほかにはどういう測り方があるでしょうか？

[garaemon]

オドメトリにかんしては、モーションキャプチャで測定しようかという話が出ていますね

[snozawa]

@fsugaiさん、@YouheiKakiuchiさん JAXON系のTODO項目がありましたら、trans_systemかどこかに書いておいてもらえると助かります。

[k-okada]

@k-okada先生の案で、実はEuslispにしてしまう。個人的にはだいぶアリなきがしてます。

僕はこの案は行っていない気がします．gazeboでやるのでいいはずです．やれば出来るはずで，ちゃんと出来る人がやればすぐに終わる話だと思います．

◉ Kei Okada

2015-06-14 17:25 GMT+09:00 Shunichi Nozawa notifications@github.com:

欲しいもの１：センサ入力としてビジョン・点群がとれて、ロボットの動作的にはkinematics onlyなシミュレーション（ビジョンあり動作の確認用）

こちらは、現状の候補は

• gazeboは点群が実機と同様にだせるので、gazeboでkinematics onlyモードをつくる＝＞ふるたくんが試していて、むずかしそうだった
• hrpsys-simulatorはkinematics onlyモードがあるので、hrpsys-simulator (かchoreonoid)で点群を出せるようにする＝＞(fkanehiro/hrpsys-base#684 https://github.com/fkanehiro/hrpsys-base/issues/684)
• @k-okada https://github.com/k-okada 先生の案で、実はEuslispにしてしまう。個人的にはだいぶアリなきがしてます。

— Reply to this email directly or view it on GitHub https://github.com/jsk-ros-pkg/jsk_demos/issues/974#issuecomment-111799323 .

[snozawa]

僕はこの案は行っていない気がします．gazeboでやるのでいいはずです．やれば出来るはずで，ちゃんと出来る人がやればすぐに終わる話だと思います．

そうでしたっけ？失礼しました。 gazeboで行う方法は古田くんに途中まで作業してもらっていまして、それの報告もお願いしています。

[garaemon]

僕はこの案は行っていない気がします．gazeboでやるのでいいはずです．やれば出来るはずで，ちゃんと出来る人がやればすぐに終わる話だと思います． そうでしたっけ？失礼しました。 gazeboで行う方法は古田くんに途中まで作業してもらっていまして、それの報告もお願いしています。

eusにセンサモデルを入れて、、、というのは大変なので、できればgazeboでやりたいです。hrpsysでやる場合は、間のbridgeを作らなくてはいけないので、それもメンテナンスする量がおおいなというきがしています

[YoheiKakiuchi]

gazeboでやりたい，kinematics onlyがどういうものなのかイメージが伝わっていない気がしますね． 以下の段階くらいがあって，だんだん面倒になる． hrpsysが入っている前提で，go-posなどの値を直接受け取らないようにすると格段に難しいように思う．

• ロボットの関節角度を指令通りにする
• ロボットの姿勢を決める( fix-leg-to-coords 的なことをする？)
• go-pos などしたら，その指示通りに歩く(歩き終わった位置に行く)

[YoheiKakiuchi]

@yoshimalucky 移動量が指令値と違うのでSLAMというかvisual odometoryを使えれば良くなるかもしれない、ということです

slamと言うほどでなくても，移動前と移動後の点群をICPするだけで，ICPが一致すれば，移動量は分かると思います． 今回のマニピュレーションで，同じところが見えているような移動が前提ですけど．

[garaemon]

slamと言うほどでなくても，移動前と移動後の点群をICPするだけで，ICPが一致すれば，移動量は分かると思います．

やってみて、コードもあって、5~10cmくらいの精度しか出ませんでした。初期位置に使っているオドメトリにバグがあったので、今やったらもう位置段階よくなるかもしれません

[mmurooka]

以下を追記しました．

- 歩くのを速くしたい
 - 特に，(i)歩幅が長くなる，(ii)go-posのフットステップ計画が賢くなって歩数が少なくなる，と速くなりそう
- 歩くのを途中で止められるようにしたい
- 実機に動作を送る前に，seqの補間の様子やabcの歩行動作を見られるようにしたい
 - シミュレーション時にはhrpsys-simulator上で確かめられるが，シミュレータを立ち上げなくてもRviz上などで見られると嬉しい
- angle-vectorを送るときの補間時間を自動でいい感じに設定できるようにしたい
 - 関節速度リミットを考慮して自動で決めるモードはありますが，abc,stでバランス補償しきれない運動量変化をだいたいでいいので考慮してくれるモードも欲しい
- self-collisionを検知したときにどのように対処すべきかを考える
- 転んでもPCが落ちないようにしたい
 - 電源とPCIの接触が問題？

[furushchev]

kinematics only で解決？できる課題としてロボットが立たない・歩かないというのがありますが、これについて atlasのpin modeと同じようにロボットがそのまま平行移動することはできますが、ロボットが動くことを考えると、 gazeboでロボットが立たないのは床と足の反発がおかしい→ODEのシミュレーションが現実と違う(直接的に関連があるかは謎ですが、参照 https://bitbucket.org/osrf/gazebo/issue/680/feet-drift-when-standing-due-commit ) gazeboはdynamicsのシミュレーションがあるだけなので、hrpsys+gazeboだとhrpsysの方にgazeboがセンサ値を送らなくてもhrpsysの動作生成ループが回るようにする必要がある。 hrpsysにSimulatorというRTCがあり、kinematics onlyモードになる気がする→RTCを有効にする方法がわからなかった gazeboでダミーなセンサ値を生成してhrpsysに送る→どういうセンサ値を送ればいいか、センサごとに決めないといけないのでプラグインを書くのが煩雑 というところでした。 僕も引き続き調べますが、ちゃんとできる人がいるならすぐできる問題なら引き継いでいただいても大丈夫です。 報告が遅れましてすみません。

[k-okada]

hrpsysのkinectics onlyは

• ロボットの姿勢を決める( fix-leg-to-coords 的なことをする？)
• go-pos などしたら，その指示通りに歩く(歩き終わった位置に行く)

はどうやっているのかな．

◉ Kei Okada

2015-06-15 12:48 GMT+09:00 Yohei Kakiuchi notifications@github.com:

gazeboでやりたい，kinematics onlyがどういうものなのかイメージが伝わっていない気がしますね． 以下の段階くらいがあって，だんだん面倒になる． hrpsysが入っている前提で，go-posなどの値を直接受け取らないようにすると格段に難しいように思う．

• ロボットの関節角度を指令通りにする
• ロボットの姿勢を決める( fix-leg-to-coords 的なことをする？)
• go-pos などしたら，その指示通りに歩く(歩き終わった位置に行く)

— Reply to this email directly or view it on GitHub https://github.com/jsk-ros-pkg/jsk_demos/issues/974#issuecomment-111912180 .

[snozawa]

- 歩くのを速くしたい
 - 特に，(i)歩幅が長くなる，(ii)go-posのフットステップ計画が賢くなって歩数が少なくなる，と速くなりそう

これをやる前に、一度タスクにかかってる時間の配分を計算してみたいですね。 大まかに「人間の操縦」「動作」「動作停止＋認識」のそれぞれが、各動作でどれくらいの時間になってるか。 ７３B２でデモをやってる分には、「人間の操縦」がない状態でも、「動作」「認識」がそれぞれ半々くらいでした。 今回はそれに輪をかけて、「人間の操縦」もくわわるので、全体を早くするには動作実行時間を短くするよりは全体の構成を見直すのがよさそうです。 そうすると、見ながら歩く、歩きながら見る、バルブをトラッキングしながら歩いてく、などがでてくるといいのかも、と思いました。

[k-okada]

ロボットの関節角度を指令通りにする

gazeboのkinematicsモードはhrpsysとは関係なくODEの代わりにloop-backなdummyなdynamicsエンジンを作ってつければいいと思います． センサはこのレベルで全部つかえるはずです．

ロボットの姿勢を決める( fix-leg-to-coords 的なことをする？) go-pos などしたら，その指示通りに歩く(歩き終わった位置に行く)

この部分はpinもモードみたいにgazeboのpluginをつくって，go-posなどに対応するかしないかが有るんだと思います．drcを見れば解ると思います．

◉ Kei Okada

2015-06-15 13:07 GMT+09:00 Furushchev notifications@github.com:

kinematics only で解決？できる課題としてロボットが立たない・歩かないというのがありますが、これについて atlasのpin modeと同じようにロボットがそのまま平行移動することはできますが、ロボットが動くことを考えると、 gazeboでロボットが立たないのは床と足の反発がおかしい→ODEのシミュレーションが現実と違う(直接的に関連があるかは謎ですが、参照 https://bitbucket.org/osrf/gazebo/issue/680/feet-drift-when-standing-due-commit )

gazeboはdynamicsのシミュレーションがあるだけなので、hrpsys+gazeboだとhrpsysの方にgazeboがセンサ値を送らなくてもhrpsysの動作生成ループが回るようにする必要がある。 hrpsysにSimulatorというRTCがあり、kinematics onlyモードになる気がする→RTCを有効にする方法がわからなかった gazeboでダミーなセンサ値を生成してhrpsysに送る→どういうセンサ値を送ればいいか、センサごとに決めないといけないのでプラグインを書くのが煩雑 というところでした。 僕も引き続き調べますが、ちゃんとできる人がいるならすぐできる問題なら引き継いでいただいても大丈夫です。 報告が遅れましてすみません。

— Reply to this email directly or view it on GitHub https://github.com/jsk-ros-pkg/jsk_demos/issues/974#issuecomment-111916128 .

[garaemon]

今回はそれに輪をかけて、「人間の操縦」もくわわるので、全体を早くするには動作実行時間を短くするよりは全体の構成を見直すのがよさそうです。

ですね、一度タイムチャートを作ってみる必要があります。これは皆であつまって一日くらいかけてやる価値が有りそうですね

[snozawa]

こちらは、

hrpsysのkinectics onlyは

• ロボットの姿勢を決める( fix-leg-to-coords 的なことをする？)
  • go-pos などしたら，その指示通りに歩く(歩き終わった位置に行く) はどうやっているのかな．

RobotHardwareから

• 関節角度指令値(qRef)
• ベースリンク位置姿勢（basePos, baseRpy）

がでてます。 kinematics onlyでないhrpsys-simulatorでは、シミュレータにqRefがはいってきます。 kinemaitcs onlyの場合は、basepos,baseRpyも直接シミュレータに出力して描画します。 basePos, baseRpyはAutoBalancerの歩行生成器、StateHolderなどが出力してきます。

gazeboでのkinematics onlyの作戦も、

• 関節角はqRefにそのまま追従させる
• ベースリンクもbasePos, baseRpyにそのまま追従させる

をだすとよさそうで、あとはqRef, baesPos, baseRpyを受け取ってそのまま描画するgazeboの何かがあればイケる、というかんじでした。

[snozawa]

kinematics onlyモードのOpenHRP3プロジェクトファイルの例は https://github.com/fkanehiro/hrpsys-base/blob/master/sample/SampleRobot/SampleRobot.kinematicsonly.xml.in#L22 で、この行がbasePoseの部分です。

[YoheiKakiuchi]

kinematicsモードの作戦としては、大きく２通りかな。

作戦１ 現状のhrpsys-gazeboはiob経由でつながっているので、basePos, baseRpyをiob経由で外部に出す

作戦２ gazeboのプラグインをrtcコンポーネント化する -> iob経由をやめてrtcでつなげる(hrpsys-simulator方式)

https://github.com/fkanehiro/hrpsys-gazebo-simulator ここをみると書いてあるような気もする。（思っているのとちょっと違うような気がする）

[garaemon]

ようやくjaxon_redでdrcのプログラムが走りそうなところまで復活させました．

$ rosnode list | wc -l
341

全部で341ノード上がっているらしいです

[garaemon]

少し更新しました

[garaemon]

立ち上げるプログラムが多すぎて全てがちゃんと立ち上がらないことがある

にたいしてcheck_sanityなるもので対応してましたが、

check_sanityよりは常にdiagnosticsが働いているべき rqt_robot_monitor対応

というのが良さそう

[snozawa]

check_sanityの結果がdiagnosticsにでてるかんじでしょうか？

[garaemon]

check_sanityの結果がdiagnosticsにでてるかんじでしょうか？

はい、今色々と増やしてmultisenseはこんなかんじです

[k-okada]

両方ですよね． 立ち上げる前はcheck 実行中はdiagnostics

◉ Kei Okada

2015-07-03 14:11 GMT+09:00 Ryohei Ueda notifications@github.com:

立ち上げるプログラムが多すぎて全てがちゃんと立ち上がらないことがある

にたいしてcheck_sanityなるもので対応してましたが、

check_sanityよりは常にdiagnosticsが働いているべき rqt_robot_monitor対応

というのが良さそう

— Reply to this email directly or view it on GitHub https://github.com/jsk-ros-pkg/jsk_demos/issues/974#issuecomment-118237596 .