Atlas controller fails to work properly when (hand) joints are added (using ihmc_gazebo)

Create issue
Issue #52 new
Stefan Kohlbrecher created an issue

I have the robot walking and moving arms now, so the natural thing to try next is doing some manipulation. I thus tried adding hands to the robot, but it appears that this is not supported so far by either the Gazebo plugin, the controller or both.

The robot spawns ok with the added hand. There seems to be an oddity with Gazebo not properly finding resource files (The chest of Atlas has the BDI logo and not the ViGIR logo I added for our model and only primitives for the hand collision geometry are shown as collision geometry, meshes are not). This might be something @hsu can comment on. I think this might be related to the way I have set up my workspace with catkin tools. It would be explained well by drcsim not seeing the atlas_description overlay I use for some reason (and also not the robotiq meshes). Rviz OTOH seems to be able to properly read all resource data.

Note that the model properly goes into IHMC controlled mode as long as no hand is added, however.

If I start the controller with a hand added to the model, the robot does not properly go into the default pose anymore. The joint states written out by the controller suggest that it uses a fixed joint ordering that breaks down when a joint is added in-between, as also evidenced by this rviz screenshot: atlas_ihmc_joint_mixup.png

This is how things look in Gazebo at the same time:



Comments (3)

  1. Stefan Kohlbrecher reporter

    Looking into the resource loading problem, I did this to the run_gazebo script to see if it helps, but it does not:

    # First argument should be a fully-qualified path to a .world file
    # (e.g., `rospack find drcsim_gazebo`/worlds/
    # or a world that's install in $GAZEBO_RESOURCE_PATH/worlds/atlas
    #`rospack find gazebo_worlds`/scripts/gdbrun gzserver -s $1
    . /home/kohlbrecher/vig_t2/devel/setup.bash
    roscd atlas_description
    gazebo -s $@

    The output is (as expected)

    process[gazebo-1]: started with pid [12534]

    but Gazebo doesn't appear to find that package.

  2. DouglasS

    @Stefan_Kohlbrecher sorry for the slow response Stefan. We've actually been working on supporting this for the past few weeks, and we hope to have a release out very shortly that will incorporate this.

  3. Log in to comment