Open garaemon opened 9 years ago
:+1: いくつかアップデートしました。
計算機のローカルな設定が違うと効率が下がるので共通bashrc/emacsなどをちゃんと決めるべき
これはprog/scripts/dot-filesのものをjsk_commonなどに追加して使ってもらうかんじでしょうか。
欲しいもの1:センサ入力としてビジョン・点群がとれて、ロボットの動作的にはkinematics onlyなシミュレーション(ビジョンあり動作の確認用)
こちらは、現状の候補は
@garaemon
オドメトリが信頼できない SLAM?
オドメトリがマニピュレーションの時にずれるというのは, 認識の姿勢からマニピュレーションの動作中にずれるということでよいでしょうか? マニピュレーション動作中に頭を動かしている時にビジョンでSLAMしていれば, そのずれを小さくできるのではということで合ってますか?
@yoshimalucky 移動量が指令値と違うのでSLAMというかvisual odometoryを使えれば良くなるかもしれない、ということです
計算機のローカルな設定が違うと効率が下がるので共通bashrc/emacsなどをちゃんと決めるべき
これはprog/scripts/dot-filesのものをjsk_commonなどに追加して使ってもらうかんじでしょうか。
はい、そうです。scripts/dot-filesを復活させて、共用アカウント・デモアカウントはそれを使うことを必須にしたいなと思います
@garaemon 移動量が指令値と違うので
移動量と指令値の差は大きければ,目視で確認できることもありますが,ほかにはどういう測り方があるでしょうか?
オドメトリにかんしては、モーションキャプチャで測定しようかという話が出ていますね
@fsugaiさん、@YouheiKakiuchiさん JAXON系のTODO項目がありましたら、trans_systemかどこかに書いておいてもらえると助かります。
@k-okada先生の案で、実はEuslispにしてしまう。個人的にはだいぶアリなきがしてます。
僕はこの案は行っていない気がします.gazeboでやるのでいいはずです.やれば出来るはずで,ちゃんと出来る人がやればすぐに終わる話だと思います.
◉ Kei Okada
2015-06-14 17:25 GMT+09:00 Shunichi Nozawa notifications@github.com:
欲しいもの1:センサ入力としてビジョン・点群がとれて、ロボットの動作的には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 .
僕はこの案は行っていない気がします.gazeboでやるのでいいはずです.やれば出来るはずで,ちゃんと出来る人がやればすぐに終わる話だと思います.
そうでしたっけ?失礼しました。 gazeboで行う方法は古田くんに途中まで作業してもらっていまして、それの報告もお願いしています。
僕はこの案は行っていない気がします.gazeboでやるのでいいはずです.やれば出来るはずで,ちゃんと出来る人がやればすぐに終わる話だと思います. そうでしたっけ?失礼しました。 gazeboで行う方法は古田くんに途中まで作業してもらっていまして、それの報告もお願いしています。
eusにセンサモデルを入れて、、、というのは大変なので、できればgazeboでやりたいです。hrpsysでやる場合は、間のbridgeを作らなくてはいけないので、それもメンテナンスする量がおおいなというきがしています
gazeboでやりたい,kinematics onlyがどういうものなのかイメージが伝わっていない気がしますね. 以下の段階くらいがあって,だんだん面倒になる. hrpsysが入っている前提で,go-posなどの値を直接受け取らないようにすると格段に難しいように思う.
@yoshimalucky 移動量が指令値と違うのでSLAMというかvisual odometoryを使えれば良くなるかもしれない、ということです
slamと言うほどでなくても,移動前と移動後の点群をICPするだけで,ICPが一致すれば,移動量は分かると思います. 今回のマニピュレーションで,同じところが見えているような移動が前提ですけど.
slamと言うほどでなくても,移動前と移動後の点群をICPするだけで,ICPが一致すれば,移動量は分かると思います.
やってみて、コードもあって、5~10cmくらいの精度しか出ませんでした。初期位置に使っているオドメトリにバグがあったので、今やったらもう位置段階よくなるかもしれません
以下を追記しました.
- 歩くのを速くしたい
- 特に,(i)歩幅が長くなる,(ii)go-posのフットステップ計画が賢くなって歩数が少なくなる,と速くなりそう
- 歩くのを途中で止められるようにしたい
- 実機に動作を送る前に,seqの補間の様子やabcの歩行動作を見られるようにしたい
- シミュレーション時にはhrpsys-simulator上で確かめられるが,シミュレータを立ち上げなくてもRviz上などで見られると嬉しい
- angle-vectorを送るときの補間時間を自動でいい感じに設定できるようにしたい
- 関節速度リミットを考慮して自動で決めるモードはありますが,abc,stでバランス補償しきれない運動量変化をだいたいでいいので考慮してくれるモードも欲しい
- self-collisionを検知したときにどのように対処すべきかを考える
- 転んでもPCが落ちないようにしたい
- 電源とPCIの接触が問題?
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に送る→どういうセンサ値を送ればいいか、センサごとに決めないといけないのでプラグインを書くのが煩雑 というところでした。 僕も引き続き調べますが、ちゃんとできる人がいるならすぐできる問題なら引き継いでいただいても大丈夫です。 報告が遅れましてすみません。
hrpsysのkinectics onlyは
はどうやっているのかな.
◉ 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 .
- 歩くのを速くしたい
- 特に,(i)歩幅が長くなる,(ii)go-posのフットステップ計画が賢くなって歩数が少なくなる,と速くなりそう
これをやる前に、一度タスクにかかってる時間の配分を計算してみたいですね。 大まかに「人間の操縦」「動作」「動作停止+認識」のそれぞれが、各動作でどれくらいの時間になってるか。 73B2でデモをやってる分には、「人間の操縦」がない状態でも、「動作」「認識」がそれぞれ半々くらいでした。 今回はそれに輪をかけて、「人間の操縦」もくわわるので、全体を早くするには動作実行時間を短くするよりは全体の構成を見直すのがよさそうです。 そうすると、見ながら歩く、歩きながら見る、バルブをトラッキングしながら歩いてく、などがでてくるといいのかも、と思いました。
ロボットの関節角度を指令通りにする
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 .
今回はそれに輪をかけて、「人間の操縦」もくわわるので、全体を早くするには動作実行時間を短くするよりは全体の構成を見直すのがよさそうです。
ですね、一度タイムチャートを作ってみる必要があります。これは皆であつまって一日くらいかけてやる価値が有りそうですね
こちらは、
hrpsysのkinectics onlyは
- ロボットの姿勢を決める( fix-leg-to-coords 的なことをする?)
- go-pos などしたら,その指示通りに歩く(歩き終わった位置に行く) はどうやっているのかな.
RobotHardwareから
がでてます。 kinematics onlyでないhrpsys-simulatorでは、シミュレータにqRefがはいってきます。 kinemaitcs onlyの場合は、basepos,baseRpyも直接シミュレータに出力して描画します。 basePos, baseRpyはAutoBalancerの歩行生成器、StateHolderなどが出力してきます。
gazeboでのkinematics onlyの作戦も、
をだすとよさそうで、あとはqRef, baesPos, baseRpyを受け取ってそのまま描画するgazeboの何かがあればイケる、というかんじでした。
kinematics onlyモードのOpenHRP3プロジェクトファイルの例は https://github.com/fkanehiro/hrpsys-base/blob/master/sample/SampleRobot/SampleRobot.kinematicsonly.xml.in#L22 で、この行がbasePoseの部分です。
kinematicsモードの作戦としては、大きく2通りかな。
作戦1 現状のhrpsys-gazeboはiob経由でつながっているので、basePos, baseRpyをiob経由で外部に出す
作戦2 gazeboのプラグインをrtcコンポーネント化する -> iob経由をやめてrtcでつなげる(hrpsys-simulator方式)
https://github.com/fkanehiro/hrpsys-gazebo-simulator ここをみると書いてあるような気もする。(思っているのとちょっと違うような気がする)
ようやくjaxon_redでdrcのプログラムが走りそうなところまで復活させました.
$ rosnode list | wc -l
341
全部で341ノード上がっているらしいです
少し更新しました
立ち上げるプログラムが多すぎて全てがちゃんと立ち上がらないことがある
にたいしてcheck_sanityなるもので対応してましたが、
check_sanityよりは常にdiagnosticsが働いているべき rqt_robot_monitor対応
というのが良さそう
check_sanityの結果がdiagnosticsにでてるかんじでしょうか?
check_sanityの結果がdiagnosticsにでてるかんじでしょうか?
はい、今色々と増やしてmultisenseはこんなかんじです
両方ですよね. 立ち上げる前は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 .
DRC終わったので反省点を列挙しましょう