Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

DRC反省点 #974

Open
garaemon opened this issue Jun 14, 2015 · 30 comments
Open

DRC反省点 #974

garaemon opened this issue Jun 14, 2015 · 30 comments

Comments

@garaemon
Copy link
Member

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

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

snozawa commented Jun 14, 2015

👍
いくつかアップデートしました。

@snozawa
Copy link
Contributor

snozawa commented Jun 14, 2015

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

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

@snozawa
Copy link
Contributor

snozawa commented Jun 14, 2015 

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

こちらは、現状の候補は

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

@robograffitti
Copy link
Member

@garaemon

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

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

@garaemon
Copy link
Member Author

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

@garaemon
Copy link
Member Author

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

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

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

@robograffitti
Copy link
Member

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

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

@garaemon
Copy link
Member Author

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

@snozawa
Copy link
Contributor

snozawa commented Jun 15, 2015

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

@k-okada
Copy link
Member

k-okada commented Jun 15, 2015

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

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

◉ Kei Okada

2015-06-14 17:25 GMT+09:00 Shunichi Nozawa [email protected]:

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

こちらは、現状の候補は

—
Reply to this email directly or view it on GitHub
#974 (comment)
.

@snozawa
Copy link
Contributor

snozawa commented Jun 15, 2015

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

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

@garaemon
Copy link
Member Author

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

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

@YoheiKakiuchi
Copy link
Member

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

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

@YoheiKakiuchi
Copy link
Member

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

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

@garaemon
Copy link
Member Author

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

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

@mmurooka
Copy link
Member

以下を追記しました．

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

@furushchev
Copy link
Member

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
Copy link
Member

k-okada commented Jun 15, 2015

hrpsysのkinectics onlyは

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

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

◉ Kei Okada

2015-06-15 12:48 GMT+09:00 Yohei Kakiuchi [email protected]:

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

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

—
Reply to this email directly or view it on GitHub
#974 (comment)
.

@snozawa
Copy link
Contributor

snozawa commented Jun 15, 2015 

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

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

@k-okada
Copy link
Member

k-okada commented Jun 15, 2015

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

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 [email protected]:

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
#974 (comment)
.

@garaemon
Copy link
Member Author

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

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

@snozawa
Copy link
Contributor

snozawa commented Jun 15, 2015

こちらは、

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
Copy link
Contributor

snozawa commented Jun 15, 2015

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

@YoheiKakiuchi
Copy link
Member

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

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

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

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

@garaemon
Copy link
Member Author

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

$ rosnode list | wc -l
341

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

@garaemon
Copy link
Member Author

少し更新しました

@garaemon
Copy link
Member Author

garaemon commented Jul 3, 2015

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

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

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

というのが良さそう

@snozawa
Copy link
Contributor

snozawa commented Jul 3, 2015

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

@garaemon
Copy link
Member Author

garaemon commented Jul 3, 2015

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

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

screenshot from 2015-07-03 16 25 16

@k-okada
Copy link
Member

k-okada commented Jul 4, 2015

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

◉ Kei Okada

2015-07-03 14:11 GMT+09:00 Ryohei Ueda [email protected]:

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

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

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

というのが良さそう

—
Reply to this email directly or view it on GitHub
#974 (comment)
.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
7 participants
@garaemon @k-okada @furushchev @YoheiKakiuchi @robograffitti @snozawa @mmurooka