kr210: update xacro to comply with actual kinematic chain

[gavanderhoorn]

As reported in #97, the KR 210 L150 xacro in kuka_kr210_support is not correct, in that the origins of the joints don't correspond to the internal model of the robot. This leads to deviations between what the controller reports as the Cartesian pose of the robot (tool, links) and what TF calculates.

This should be fixed.

Easiest is probably to redo transforms in the xacro based on the workspace reachability diagram included in the KR210 datasheet(s).

[jwhendy]

I have been dabbling in robot model creation to learn the process. I thought of doing this one, but am not having luck on the Kuka website to obtain the CAD models. Specifying Kuka Robotics and product name "KR 210 L150" only yields one CAD model, and it's not a robot (part is called a KR2000_Quantec_Pedestal).

SolidWorks doesn't let me import the existing .dae visual models to try and modify those.

Could someone point in the direction of the correct CAD files for this robot?

[gavanderhoorn]

Asking KUKA for these directly is most likely the best way. Unless someone has these lying around, of course.

Getting the models from KUKA would also be a guarantee that you'd get the correct model.

[gavanderhoorn]

I just checked the KUKA download site, and if you filter for the KR 210-2, you should get robots, not pedestals.

[gavanderhoorn]

@jwhendy wrote:

SolidWorks doesn't let me import the existing .dae visual models to try and modify those.

No, that won't work.

For modifying Collada, I always use Blender.

[jwhendy]

...if you filter for the KR 210-2, you should get robots, not pedestals.

I noticed that (and downloaded the CAD) when I posted my comment, but I wasn't confident that the KR 210 L150 == KR 210 L150-2. I looked at each manual and they appear identical, minus joint limit definitions.

L150

L150-2

Lettered dimensions are the same, with the exception of F:

|               |    A |    B |    C |    D |   E |    F |    G |
|---------------+------+------+------+------+-----+------+------|
| KR 210 L150   | 3500 | 4250 | 3100 | 2150 | 950 | 2243 | 1500 |
| KR 210 L150-2 | 3500 | 4250 | 3100 | 2150 | 950 | 2187 | 1500 |

The joint positions appear identical, so the kinematics should be the same, and I would define this with respect to the actual L150 limit conventions. Would you advise to proceed with the L150-2 CAD model?

I would also be happy to contact Kuka for the L150 CAD.

[jwhendy]

Contacted Kuka, who pointed me to the KR 210 L150-2 CAD model. To that, I asked:

Is the KR 210 L150 identical to the KR 210 L150-2?

They replied:

Here is what I was able to obtain from one of our Engineering team.

The link lengths are the same for both robots. The actual axis ranges are slightly different for A2. It appears that the 0 position of A2 was defined different for the KR 210 L150 versus the -2 model, or that it was reported differently in the spec. Nonetheless, the KR 210 L150 seemed to be able of going -5° more than the -2 model.

I will use the CAD for the L150-2 and the joint limits as defined in the drawing above for the L150 to take a shot at this robot definition.

[jwhendy]

Actually, I wonder if I should make the L150 and L150-2 at the same time? I'll create separate .xacro files with different limit definitions, linking to the same visual/collision models.

[gavanderhoorn]

Always preferable to get this sort of info from the mfg itself. +1 for asking them.

re: create both variants: yes, that would be an option, although it would lead to a lot of duplication to only change on joint limit.

I've been playing with the ability of xacro to load yaml files and I feel this might be one of those cases that could be nicely covered by it. If we store all joint limits in a yaml file, we'd need only a single macro, provide it with the path to the yaml and the limits could be loaded from there.

This would probably require some experimentation to get it just right (yaml structure, who is responsible for loading the yaml: the macro or the consumer, etc), so if you're not up for that @jwhendy, I can understand. In that case just go ahead and duplicate the file.

[gavanderhoorn]

See ubi-agni/human_hand/model/human_hand.urdf.xacro for a very good example of how to exploit xacro to the fullest for this sort of work.

[jwhendy]

@gavanderhoorn Finally got to this. I'm about ready to commit the KR210 L150 and submit a PR. One unforeseen catch was the definition of their joint limits. If you compare the two pictures above, the L150 uses x as the reference for joint_a3 limits (-209/+65); the L150-2 uses z (-119/+155).

Could you guide me on these routes (or suggest another)?

1. change the .stl origins for links 3-6 depending on the robot. For the L150, links 3-6 would switch to x along the link; for the L150-2, z is in-line with all links. I think this breaks the idea of using the yaml + xacro idea, as we need unique models per robot.

2. keep the L150-2 origin definitions (z along all links) and adjust the limits appropriately for the L150 on joint_a3. This would result in an entry like this for the L150:

<joint name="${prefix}joint_a3" type="revolute">
    <origin xyz="0 0 1.25" rpy="0 0 0"/>
    <parent link="${prefix}link_2"/>
    <child link="${prefix}link_3"/>
    <axis xyz="0 1 0"/>
    <limit lower="${radians(-209+90)}" upper="${radians(65+90)}" effort="0" velocity="${radians(81)}"/>
</joint>

The first option preserves the limit conventions (you can go from -209 to 65 for joint_a3), the second allows us to re-use the models, but the user would have to adjust the joint_a3 limits appropriately (they actually become the L150-2's limits of -119 to 155). If you like the second, I'm game to try your yaml loading idea.

Lastly, a caveat on all of the above is that I'm going by the drawings alone. I don't have the robot, so I don't know if the true controller zero configuration differs from what is shown.

[gavanderhoorn]

Sorry for my late reply (too much to do).

I'm not entirely sure I completely understand what you're describing/suggesting here.

Could you perhaps explain again what is the reason you can't reuse the meshes for both variants?

[gavanderhoorn]

🏅 for working on this btw. Much appreciated.

[jwhendy]

No problem, and it took me two weeks to do this anyway :) It's nuanced... the .stl files themselves contain the origins, so based on how the Kuka limits are defined per the L150 vs. L150-2, we either give up all but translation in the joint translations, or we use separate meshes. At least that's the only options I see.

Here's another attempt to call out the two joints of interest, and how I defined them via CAD to preserve only one non-zero entry in the xacro.macro and preserve the Kuka manual definition of the joint limits.

It's crude, but hopefully makes sense. I see two scenarios:

1. we want to follow the convention of the specification. joint_a3 for the L150 should be -219 to +65, with x with respect to the base_link as the reference. To do that, I defined link_3's coordinate frame (inherent to the .stl) to have x along the joint so that from joint_a2 to joint_a3, we only have to move in z from joint_a2.

The L150 doesn't have this problem as they updated the +/- reference for joint_a3 to be with respect to the base_link z. Thus, I would keep z along the link for that config.

2. We abandon the Kuka manual definition of the joint limits for the L150. Instead of going +/- about x, we treat the limits as exactly the same as the Kuka L150-2. In that case, the limits are the same.

3. I lied, I can think of a further option... We could define joint_a3 to be translated along z and a rotation by 90 deg... Now we keep the Kuka conventions, reuse the meshes, but we have two non-zero entries in the xacro.macro

Does that make anymore sense? I like option 2 the best... but I don't know when people are programming if they would get surprised by thinking they can go from -219 to +65 when really it's -119 to +155...

[BrettHemes]

They replied:

Here is what I was able to obtain from one of our Engineering team.
The link lengths are the same for both robots. The actual axis ranges are slightly different for A2. It appears that the 0 position of A2 was defined different for the KR 210 L150 versus the -2 model, or that it was reported differently in the spec. Nonetheless, the KR 210 L150 seemed to be able of going -5° more than the -2 model.

It seems the zero positions are different. That said, reading through the above, I feel the situation is being overly complicated... Ultimately, the urdf should result in a model with the same zero-position and joint limits as defined in the manual. As @gavanderhoorn alluded to, you have several approaches on how to do that varying in complexity.

1. we want to follow the convention of the specification. joint_a3 for the L150 should be -219 to +65, with x with respect to the base_link as the reference. To do that, I defined link_3's coordinate frame (inherent to the .stl) to have x along the joint so that from joint_a2 to joint_a3, we only have to move in z from joint_a2.
   ...

The joint limits in the urdf are with respect to the relative poses defined in the joint element (about the axis defined by the axis child element). The frame assignment in the meshes can be arbitrary but should be meaningful. The "x forward / z up" is a suggested approach (~standard) for ROS-Industrial. I think in this case you share the meshes, have separate OR reconfigurable urdf(s) where one deviates from the "standard". You can even put in a comment to say why you made the decisions you made.

Does that make anymore sense? I like option 2 the best... but I don't know when people are programming if they would get surprised by thinking they can go from -219 to +65 when really it's -119 to +155...

Yes, don't do this... it should match the actual hardware/controller/pendant conventions.

[jwhendy]

Thanks for the clarification. I think I'll prefer the L150-2, which in my opinion looks to be more "standard" (z up, x out for all joints). The L150 would have one additional RPY entry for joint_a3 in the urdf, but that would allow sharing the meshes. (Or I'll explore the .yaml idea, which I haven't dug into yet).

[jwhendy]

I admit that the hand model is a bit over my head, but I'm willing to dig in more.

That said, it dawned on me that the rpy for joint_a3 is handily the same as the joint limit changes that also result between the L150 and L150-2. Is this hokey?

<xacro:macro name="kuka_kr210l150" params="prefix model">
  <xacro:property name="a3_offset" value="90"/>
  <xacro:if value="${model == 2}">
    <xacro:property name="a3_offset" value="0"/>
  </xacro:if>

I added a model param, and if a 2 is passed (intended to represent specifying L150-2), we change the offsets for joint_a3:

<joint name="${prefix}joint_a3" type="revolute">
  <origin xyz="0 0 1.25" rpy="0 ${radians(a3_offset)} 0"/>
  <parent link="${prefix}link_2"/>
  <child link="${prefix}link_3"/>
  <axis xyz="0 1 0"/>
  <limit lower="${radians(-119-a3_offset)}" upper="${radians(155-a3_offset)}" effort="0" velocity="${radians(81)}"/>
</joint>

It seemed like overkill to specify all the joint values in a .yaml just to set one additional rotation transform. You can take a look at this in #124 .