Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Kr210 kinematics update #124

Open
wants to merge 8 commits into
base: melodic-devel
Choose a base branch
from

Conversation

jwhendy
Copy link

@jwhendy jwhendy commented Apr 15, 2018

This surely still needs work, but is a first stab at #98 . Creating the PR so we can talk code instead of theory and pictures! This addresses the kinematics of the original L150 and also attempts to bring in the L150-2, which is the same physical model with different limits/zero position defined for joint_a3.

@gavanderhoorn
Copy link
Member

This looks like a nice cleanup. Thanks for that @jwhendy. 👍

I'm still a bit foggy on why that offset is needed, but I think I'll just have to re-read your previous explanation(s) to figure that out (again).

I think @BrettHemes was more involved here, so perhaps he could also take a look?

@jwhendy
Copy link
Author

jwhendy commented May 4, 2018

@gavanderhoorn I think this is the simplest I've managed to try and explain it:

kuka_joints

Here's one more shot... honestly the time between looking at this has me needing to re-remember as well :) It's down to a balance of three factors:

  • re-using the same CAD for both robots
  • adhering to the Kuka manual convention for joint limits
  • only one non-zero offset between joints

Basically, you can pick any two of the above but you can't have all three. I was under the assumption that re-using the CAD was a definite to include, and all of these questions have been around which to give up among the second two.

  • add an additional pi/2 offset to joint_a3 on the L150 in order to preserve the -219/+65 convention
  • don't use this offset, but define the L150's limits to be -119/+155 like the L150-2.

Lastly, I admit to being hung up on trying something clever like your suggestion on #98. At this point, I think the PR is held up on me figuring that out in order to avoid a separate, mostly redundant .xacro.

I think I'll just create a separate .xacro later tonight and update this. If down the road someone wants to merge them in some clever way, they always can. Thoughts on that?


Edit: also, the guidance from @BrettHemes steered me toward adding the offset and preserving the manual convention, so that's what I did here.

The part of this PR that needs review was what folks thought of the probably stupid attempt shown here at adding a parameter to specify the L150 vs. L150-2 without a separate .xacro. This would require documentation that the user should pass a value for a model param if they want to use the L150-2.

@jwhendy
Copy link
Author

jwhendy commented May 5, 2018

I just split the L150 and L150-2 into separate .xacro, _macro.xacro, and test/*.launch files.

  • same CAD
  • preserves Kuka joint limits
  • L150-2 has an additional pi/2 rotation at joint_a3

If you liked the model param... I think you can pull the last commit instead of the most recent.

One uncertainty: are dashes forbidden in file names? I have -2 identifying the L150-2 from the L150. Not sure how much of a foul that is; I can update to _2 if that's preferred.

@jwhendy
Copy link
Author

jwhendy commented May 19, 2018

Okay, after fiddling with the usage of an arg on the lbr_iiwa and thinking that was elegant for the flange, I went back to it here, too. We now have:

  • reusable CAD
  • an arg, variant, that defaults to "" for th KR210 L150 and can be specified as "_2" for the KR210 L150-2
  • the variant arg simply changes the offset for joint_a3 and it's limits so that we match the Kuka manual definitions for each

I think that's pretty reasonable and a nice compromise (all we give up is one additional non-zero joint offset in the case of the L150). Good to go?

@BrettHemes
Copy link
Member

As with the others, (#117 and #118) I like this approach. When I get some time I will load them up and check them unless @gavanderhoorn gets to it first. Hopefully this weekend.

Copy link
Member

@BrettHemes BrettHemes left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • Dashes in file names to underscores (i.e., "-2" to "_2")
  • "-2" Loads/tests don't use new changes
  • Move "variants" file code directly into parent macro.xacro (or rename to avoid confusion)

@@ -0,0 +1,3 @@
<launch>
<param name="robot_description" command="$(find xacro)/xacro --inorder '$(find kuka_kr210_support)/urdf/kr210l150-2.xacro'" />
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This line no loner works with most recent changes.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This file is non-existent now.

@@ -0,0 +1,3 @@
<launch>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would rename this file to load_kr210l150_2.launch (i.e., no dashes)

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This file is non-existent now.

@@ -0,0 +1,8 @@
<launch>
<include file="$(find kuka_kr210_support)/launch/load_kr210l150-2.launch" />
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as above... update to use new variant arguments

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This file is non-existent now.

@@ -0,0 +1,10 @@
<?xml version="1.0" ?>
<launch>
<group ns="load_kr210l150-2__">
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

underscores

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This file is non-existent now.

<include file="$(find kuka_kr210_support)/launch/load_kr210l150-2.launch"/>
</group>

<group ns="test_kr210l150-2__">
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

dash to underscore

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This file is non-existent now.

@@ -0,0 +1,22 @@
<?xml version="1.0"?>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would move this code into the kr210l150_macro.xacro and then delete this file. The variants naming is confusing here.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done. Committed/pushed. I had a tricky time figuring out how to get at the arg from the top level file. From looking around xacro:property seemed like the ticket, so that's what I used. Hopefully that's correct? I admit to not knowing precisely why arg vs. param vs. property...

  <!-- for the KR210 L150, use ""; for the KR210 L150-2, use "_2" -->
  <xacro:arg name="variant" default="" />
  <xacro:property name="variant" value="$(arg variant)"/>

@@ -1,5 +1,5 @@
<?xml version="1.0" ?>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should have a corresponding kr210l150_2.xacro file as well?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was thinking not anymore? I apologize as I flopped back and forth on trying to use an argument, then quasi giving up and just making replicate macro/xacro, launch, and test files, then going back to an argument. So I figured the path was either:

  • no _2 argument, and duplicate everything. The only difference would be the definition of joint_a3 per variant
  • use the _2 argument, but don't replicate all the files with a foo_2.bar shadow

</joint>
<xacro:kuka_kr210l150_a3 prefix="${prefix}" variant="$(arg variant)"/>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As noted above, just put code here (vs separate file)?

<!--degrees to radians-->
<property name="deg" value="0.017453293"/>
<xacro:include filename="$(find kuka_resources)/urdf/common_materials.xacro"/>
<xacro:include filename="$(find kuka_kr210_support)/urdf/kr210_variants_macro.xacro"/>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remove? see below.

@jwhendy
Copy link
Author

jwhendy commented May 19, 2018

I'll look at the reviews more closely tonight; much appreciated. One main question... I see comments on files with -2, which I deleted/moved away from. Do you want those back? With the approach I took on the most recent commit, I assumed we would treat these identically, minus passing _2 to trigger a different zero reference and limits for joint_a3.

I didn't plan to have a _2 namespace via the launch if you're using the L150-2 either... do we need to differentiate these variants via a namespace?

I can look into moving the code into the main _macro.xacro.

@BrettHemes
Copy link
Member

BrettHemes commented May 19, 2018

which I deleted/moved away from

The load/test files for the -2 are still there and as it stands these are broken. If you delete them you can ignore the respective comments.

@jwhendy
Copy link
Author

jwhendy commented May 19, 2018

The load/test files for the -2 are still there and as it stands these are broken.

I missed that last comment before reading all the reviews. Yes, I intended to do completely away with the -2 via any files. I think I goofed and never did git rm... fixed now.

Thanks for the insight to just move top level; I agree for a simple if check, this is much cleaner.

@BrettHemes
Copy link
Member

I was going to comment on removing the mass/inertia values but they all seem wrong (this was also pointed out in #36 it seems but never fixed). I am perfectly fine getting rid of these now and then adding them back later when good approximates are figured out (see discussion in #125)

@storeyp
Copy link

storeyp commented Nov 25, 2019

Hi folks,
New to this world, so apologies if jumping in at the wrong place.
I'm looking to use ROS on our two Kuka KR210 robots. The spanner in the works: they're the variant KR210 R2700, and seeing the length of discussion around L150 and L150-2 variants, I'm wondering if this will be problematic!
I've connected successfully with the robots, and getting data back and forth, but it does seem that I've got problems with axis definition - the real world doesn't match what I see in rviz.

Any further changes since May 2018? What's the best way for me to proceed?

Thanks!

@jwhendy
Copy link
Author

jwhendy commented Nov 25, 2019

Sorry, I'm not sure how to answer. I believe for this, #117 and #118 just need time from @gavanderhoorn . I have not heard anything on these PRs since May 2018, minus similar inquiries.

@simonschmeisser simonschmeisser changed the base branch from indigo-devel to melodic-devel September 23, 2021 15:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

4 participants