(hrpsys_gazebo_atlas) atlas.lにeuscollada-robot.lの内容がcopyされない

[mmurooka]

https://github.com/start-jsk/rtmros_gazebo/blob/master/hrpsys_gazebo_atlas/catkin.cmake#L51 で自動生成されている atlas.lとatlas_v3.l に以下のような行がありますが， 実際にはcollada-robot.lの内容がコピーされておらず eusでloadするとエラーになります．

;; copy euscollada-robot class definition from euscollada/src/euscollada-robot.l
;;
;;

@mmurooka と @core-dump の環境で再現しました．

eusモデルにcollada-robot.lの内容を貼り付けるようにするには compile_collada_modelに何かオプションが必要とかでしょうか．

[mmurooka]

https://github.com/start-jsk/rtmros_gazebo/blob/master/hrpsys_gazebo_atlas/catkin.cmake https://github.com/start-jsk/rtmros_gazebo/blob/master/hrpsys_gazebo_atlas/package.xml の find_package, catkin_package, build_depend, run_depend に euscollada を加えて見ましたが治りませんでした．

[snozawa]

catkin_makeを実行した出力に、 cannot resolve euscollada package path とでてませんか？

[mmurooka]

modelを消して再catkin_makeしましたが， euscollada を含むエラーログは見つかりませんでした．

以下，catkin_makeの出力でモデル変換をしていそうなところの抜粋です．

Generating /home/leus/ros/hydro/src/rtm-ros-robotics/rtmros_gazebo/hrpsys_gazebo_atlas/models/atlas_v3.l
Generating /home/leus/ros/hydro/src/rtm-ros-robotics/rtmros_gazebo/hrpsys_gazebo_atlas/models/atlas_v3.xml
Generating /home/leus/ros/hydro/src/rtm-ros-robotics/rtmros_gazebo/hrpsys_gazebo_atlas/models/atlas_v3.urdf, /home/leus/ros/hydro/src/rtm-ros-robotics/rtmros_gazebo/hrpsys_gazebo_atlas/models/atlas_v3_meshes
Starting omniORB omniNames: cocoa:2972

Fri Jun 20 11:29:56 2014:

Starting omniNames for the first time.
Wrote initial log file.
Read log file successfully.
Root context is IOR:010000002b00000049444c3a6f6d672e6f72672f436f734e616d696e672f4e616d696e67436f6e746578744578743a312e300000010000000000000074000000010102000f0000003139322e3136382e39372e31393000009c0b00000b0000004e616d6553657276696365000300000000000000080000000100000000545441010000001c0000000100000001000100\
01000000010001050901010001000000090101000354544108000000a49ca35301005ba8
Checkpointing Phase 1: Prepare.
Checkpointing Phase 2: Commit.
Checkpointing completed.
;; Adding gazebo description
;; Use assimp export
;; output file is: /home/leus/ros/hydro/src/rtm-ros-robotics/rtmros_gazebo/hrpsys_gazebo_atlas/models/atlas_v3.urdf
;; mesh_prefix is: package://hrpsys_gazebo_atlas/models/atlas_v3_meshes
;; Mesh output directory is: /home/leus/ros/hydro/src/rtm-ros-robotics/rtmros_gazebo/hrpsys_gazebo_atlas/models/atlas_v3_meshes
;; Input file is: /home/leus/ros/hydro/src/rtm-ros-robotics/rtmros_gazebo/hrpsys_gazebo_atlas/models/atlas_v3.dae
torso@5
larm@10
rarm@18
lleg@26
rleg@34
head@42
Number of Visual Scene 1 (= 1)
Number of Nodes 1 (= 1)
Visual_scene atlas
Convert /home/leus/ros/hydro/src/rtm-ros-robotics/rtmros_gazebo/hrpsys_gazebo_atlas/models/atlas_v3.dae to /home/leus/ros/hydro/src/rtm-ros-robotics/rtmros_gazebo/hrpsys_gazebo_atlas/models/atlas_v3.l
 with /home/leus/ros/hydro/src/rtm-ros-robotics/rtmros_gazebo/hrpsys_gazebo_atlas/models/atlas_v3.yaml[ INFO] [1403231396.743651442]: joint l_situational_awareness_camera_joint is passive, but adding to hierarchy

[snozawa]

I fixed this problem with @mmurooka. @mmurooka , please create PR.

The problem was derived from duplicate codes. compile_openhrp_model and compile_collada_model have same codes. One code was upgraded, but the other code was not upgraded and it caused this bug.

Removing duplicate codes is necessary[1]. [1] https://github.com/start-jsk/rtmros_common/issues/498

For more improvement... collada2eus calls rospack in order to obtain euscollada-robot.l path. If we'd like to access A package path in A package's program, is it the best way to use rospack command inside the program?

[k-okada]

collada2eus calls rospack in order to obtain euscollada-robot.l path.

why you read euscollada-robot.l in collada2eus program, instead of just writing (load "euscollada-robot.l") or something?

[snozawa]

why you read euscollada-robot.l in collada2eus program, instead of just writing (load "euscollada-robot.l") or something?

Currently euscollada-robot.l is not included in *load-path*. Moreover, for non-ROS environments, we ware not able to use (load "package://euscollada/src/euscollada-robot.l).

But (load "euscollada-robot.l) is preferable.

[k-okada]

ok, so why we need euscollada-robot.l

;; fix all links' mass properties ;; root link relative (collada) -> link local (euslisp) https://github.com/jsk-ros-pkg/jsk_model_tools/blob/master/euscollada/src/euscollada-robot.l#L10 seems to be done in euscollada conversion,

(:fullbody-inverse-kinematics redefined?

https://github.com/jsk-ros-pkg/jsk_model_tools/blob/master/euscollada/src/euscollada-robot.l#L33

On Sat, Jun 21, 2014 at 10:15 AM, Shunichi Nozawa notifications@github.com wrote:

why you read euscollada-robot.l in collada2eus program, instead of just writing (load "euscollada-robot.l") or something?

Currently euscollada-robot.l is not included in load-path. Moreover, for non-ROS environments, we ware not able to use (load "package://euscollada/src/euscollada-robot.l).

But (load "euscollada-robot.l) is preferable.

— Reply to this email directly or view it on GitHub https://github.com/start-jsk/rtmros_gazebo/issues/75#issuecomment-46740646 .

[snozawa]

Totally, almost all codes should be removed from euscollada-robot.l as you said. Hoever, even if we can remove fix all links .... and (:fullbody-inverse-kinematics, I think we need to use euscollada-robot.l because of these lines: https://github.com/jsk-ros-pkg/jsk_model_tools/blob/master/euscollada/src/euscollada-robot.l#L23 These links are used to consider virtual links or fixed joints.

To improve current situation, we can write the contents of euscollada-robot.l into collada2eus*.cpp directly and remove euscollada-robot.l. At the first version of euscollada, the contents of euscollada-robot.l are written in collada2eus*.cpp. Because direct writing was hard to maintain, we extracted these codes as euscollada-robot.l. However, currently managing of euscollada-robot.l path is harder than direct writing because we should maintain for all environments (groovy, hydro, deb, source...etc). So it would be better to write these codes in collada2eus*.cpp instead of euscollada-robot.l.

How do you think about this?

For other comments:

;; fix all links' mass properties ;; root link relative (collada) -> link local (euslisp)

seems to be done in euscollada conversion,

Current collada2eus*.cpp codes do not calculate such kinds of conversion. Frames mass properties in collada model is root-link relative. If we want to add these conversion, collada2eus_urdfmodel.cpp will be easier because we can use Pose type and we can reduce codes and bugs.

(:fullbody-inverse-kinematics redefined?

This overwriting includes practical modifications:

1. tuned parameter for cog-gain and stop
2. 6dof weight calculation based on legs weight

For 1, I think it is possible to remove these parameter tuning by considering COG-jacobian as first priority task. Currently, COG-jacobian are used as null-space and convergence of cog position is quite slow. So we need to tune cog-gain and stop. If we use COG-jacobian as first priority task as end-effector tasks, it will be removed. Anyway, to reduce these codes, we have to wait for downstream travis passing https://github.com/jsk-ros-pkg/jsk_pr2eus/pulls.

[k-okada]

How do you think about this?

removeing euscollada-robot.l (and do not write lisp code directory into cpp files as much as possible) are fine. this is euscollada robot, not humonaid robot class, so adding any code that related to cog is strange. .

[snozawa]

removeing euscollada-robot.l (and do not write lisp code directory into cpp files as much as possible) are fine.

Thanks, I'll try it.

this is euscollada robot, not humonaid robot class, so adding any code that related to cog is strange.

Humm, this is quite important discussion.

1. cog cog is the generic term for all rigid-body, even if frying robot and wheel-based robot. So programs using cog is not so strange in terms of robotics theory and software. Altough it is actually rare for wheeled robots to use such kinds of programs, for example, it is necessary for HSR which has small support area to push something.
2. Humanoid robot specific code However, some codes practically assume leg information. This is biped humanoid dependent codes. Do you mean this?

Currently, euscollada-robot class is subclass of robot-model class. However, robot-model class has leg information such as lleg-end-coords...etc.

Introducing legged-robot class under the robot-model class can be one solution, but I have painful memory about this. For example, rbrain's hrp2w class is derived from biped-robot class...

[k-okada]

I agree, so fullbody-xx or cog- code should be in robot-model class, not euscollada-robot calss.

On Mon, Jun 23, 2014 at 2:21 PM, Shunichi Nozawa notifications@github.com wrote:

removeing euscollada-robot.l (and do not write lisp code directory into cpp files as much as possible) are fine.

Thanks, I'll try it.

this is euscollada robot, not humonaid robot class, so adding any code that related to cog is strange.

Humm, this is quite important discussion.

1. cog cog is the generic term for all rigid-body, even if frying robot and wheel-based robot. So programs using cog is not so strange in terms of robotics theory and software. Altough it is actually rare for wheeled robots to use such kinds of programs, for example, it is necessary for HSR which has small support area to push something.
2. Humanoid robot specific code However, some codes practically assume leg information. This is biped humanoid dependent codes. Do you mean this?

Currently, euscollada-robot class is subclass of robot-model class. However, robot-model class has leg information such as lleg-end-coords ...etc.

Introducing legged-robot class under the robot-model class can be one solution, but I have painful memory about this. For example, rbrain's hrp2w class is derived from biped-robot class...

— Reply to this email directly or view it on GitHub https://github.com/start-jsk/rtmros_gazebo/issues/75#issuecomment-46807145 .

[snozawa]

Sorry, I misunderstood your previous comment, but I understand what you mean.

[mmurooka]

一旦Closeします． 続きがありましたらReopenお願いします．