kuka_experimental
kuka_experimental copied to clipboard
Kr210 kinematics update
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
.
This looks like a nice cleanup. Thanks for that @jwhendy. :+1:
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?
@gavanderhoorn I think this is the simplest I've managed to try and explain it:
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 tojoint_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.
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 atjoint_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.
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 thKR210 L150
and can be specified as"_2"
for theKR210 L150-2
- the
variant
arg simply changes the offset forjoint_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?
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.
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
.
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.
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.
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)
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!
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.