Atlas v4 has a wry2 joint

[osrf-migration]

Original report (archived issue) by DouglasS (Bitbucket: DouglasS).

---

The current model of Atlas v4 in the drcsim-prerelease package has a wry2 joint. It is mostly useless, because its joint limits are very constrained, but the fact that it exists at all is a problem for a lot of reasons. Primarily, any model-based controller that chooses to consume .SDF as a format for its robot descriptions will not have a physically accurate model in its internal state. There are other problems that present themselves to developers; for example it is no longer acceptable to simply iterate over the arm joints from model-based control code that will talk to the real Atlas robot, as a bunch of extraneous safety checks or hacks will need to be performed to make sure that we don't try to execute code that could lead to a crash when we reference something that doesn't exist in the real robot's API.

[osrf-migration]

Original comment by Nate Koenig (Bitbucket: Nathan Koenig).

---

The wry2 joint in Atlas v4 is need for the BDI controller to operate. Would it be acceptable to add another version of Atlas v4 that doesn't have the wry2 joint? You would be able to launch it using:

roslaunch drcsim_gazebo atlas.launch model_args:="_v4_no_wry2"

The caveat is that you wouldn't be able to use BDI's controller.

[osrf-migration]

Original comment by Nate Koenig (Bitbucket: Nathan Koenig).

---

• changed priority from "major" to "blocker"

[osrf-migration]

Original comment by DouglasS (Bitbucket: DouglasS).

---

@nkoenig This is acceptable to us because we don't use the BDI controller in sim. I can't speak for other teams that have expressed the same frustrations. We just need a "correct" .URDF/.SDF to load in to our controller so it has an accurate physical model of the robot's state.

[osrf-migration]

Original comment by David Conner (Bitbucket: dcconner).

---

Did something change with recent drcsim-prerelease 4.2.4-1~trusty.

I'm trying to start roslaunch drcsim_gazebo atlas.launch mode_args:="_v4" extra_gazebo_args:="--verbose"

And I'm seeing joint names: (rosparam get robot_description | grep l_arm)

  \  </gazebo>\n  <gazebo reference=\"l_arm_elx\">\n    <implicitSpringDamper>1</implicitSpringDamper>\n\
  \  </gazebo>\n  <gazebo reference=\"l_arm_ely\">\n    <implicitSpringDamper>1</implicitSpringDamper>\n\
  \  </gazebo>\n  <gazebo reference=\"l_arm_mwx\">\n    <implicitSpringDamper>1</implicitSpringDamper>\n\
  \  </gazebo>\n  <gazebo reference=\"l_arm_shx\">\n    <implicitSpringDamper>1</implicitSpringDamper>\n\
  \  </gazebo>\n  <gazebo reference=\"l_arm_usy\">\n    <implicitSpringDamper>1</implicitSpringDamper>\n\
  \  </gazebo>\n  <gazebo reference=\"l_arm_uwy\">\n    <implicitSpringDamper>1</implicitSpringDamper>\n\

The setup we were using a day or so ago had:

 \  </gazebo>\n  <gazebo reference=\"l_arm_elx\">\n    <implicitSpringDamper>1</implicitSpringDamper>\n\
  \  </gazebo>\n  <gazebo reference=\"l_arm_ely\">\n    <implicitSpringDamper>1</implicitSpringDamper>\n\
  \  </gazebo>\n  <gazebo reference=\"l_arm_wrx\">\n    <implicitSpringDamper>1</implicitSpringDamper>\n\
  \  </gazebo>\n  <gazebo reference=\"l_arm_shx\">\n    <implicitSpringDamper>1</implicitSpringDamper>\n\
  \  </gazebo>\n  <gazebo reference=\"l_arm_shy\">\n    <implicitSpringDamper>1</implicitSpringDamper>\n\
  \  </gazebo>\n  <gazebo reference=\"l_arm_wry\">\n    <implicitSpringDamper>1</implicitSpringDamper>\n\

If we try to start gazebo with our custom launch file it just collapses. (Will dig more on my side before I file another separate bug report)

[osrf-migration]

Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

---

@dcconner can you put ~~~ before and after code blocks? It will make them render differently so that they're more easy to read.

[osrf-migration]

Original comment by David Conner (Bitbucket: dcconner).

---

Yes. I have the technology to do that.

[osrf-migration]

Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

---

Thanks! And looking at the contents of atlas_description/urdf, I belive the l_arm_mwx was only on the first atlas (atlas.urdf or atlas_simple_shapes.urdf).

[osrf-migration]

Original comment by Stefan Kohlbrecher (Bitbucket: Stefan_Kohlbrecher).

---

Note also related earlier question in #467.

Also related, it was proposed to split atlas_description from drcsim, which could make things more modular, and easier to fork and modify: #451 We soft of did this and added a "atlas_v4_no_wry2" model for use with the real robot as Doug suggests. The changes are pretty straightforward, see vigir_atlas_common repo and atlas_v4 -> atlas_v4_no_wry2 changeset

/edit: Note the link pointed to the wrong changeset before, just fixed that.

[osrf-migration]

Original comment by DouglasS (Bitbucket: DouglasS).

---

@Stefan_Kohlbrecher we'll look in to that fork. Can you or anybody from OSRF chime in on the validity of the inertia/mass properties of the link that results from gzsdf stripping out the wry2 fixed joint?

[osrf-migration]

Original comment by David Conner (Bitbucket: dcconner).

---

I found my error. Apparently gazebo was happy to ignore my "mode_args" typo, and load the old model.

[osrf-migration]

Original comment by David Conner (Bitbucket: dcconner).

---

My robot collapsing with our gazebo launch was due to trying to load our atlas_v4_no_wry2 model on start up (specified by default on robot interface computer). (Continually switching API and models between robot and simulation is not fun.)

[osrf-migration]

Original comment by Stefan Kohlbrecher (Bitbucket: Stefan_Kohlbrecher).

---

The intermediate link that gets removed is a 0.1 mass link in without visual or collision geometry:

#!xml

<link name="l_hand">
    <inertial>
      <mass value="0.1"/>
      <origin xyz="0 0 0" rpy="0 0 0"/>
      <inertia ixx="0.0001" ixy="0" ixz="0" iyy="0.0001" iyz="0" izz="0.0001"/>
    </inertial>
  </link>

As visible in the changeset, I removed that one and renamed the previous intermediate link to "[l/r]_hand", which is the same configuration as on previous atlas models. Given the generic mass/inertia parameters of the removed link they probably were only placeholders anyway. The model without the wry2 joints and associated links is in the remove_v4_wry2_joints_and_lfarm_links branch on github. You can look at the latest commits to see what we did.

/edit: I think we might have not patched in the latest collision geom updates into that model however.

[osrf-migration]

Original comment by Stefan Kohlbrecher (Bitbucket: Stefan_Kohlbrecher).

---

I updated our model with latest collision geom from drcsim in the (nicely named) remove_v4_wry2_joints_and_lfarm_links_merge_from_upstream branch. I also also generated a SDF version of the model that can be downloaded here: https://drive.google.com/file/d/0B1hU91jkd7VwcFJDdnE0S0p4dkU/view?usp=sharing. @dljsjr If I understand you correctly, you might be able to directly load that into your system.

[osrf-migration]

Original comment by Nate Koenig (Bitbucket: Nathan Koenig).

---

See pull request #518

[osrf-migration]

Original comment by Nate Koenig (Bitbucket: Nathan Koenig).

---

• changed state from "new" to "resolved"

Resolved in pull request #518