-
Notifications
You must be signed in to change notification settings - Fork 52
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
Added cr7ial support #33
Added cr7ial support #33
Conversation
Thanks again for the PR. Unfortunately, Travis is failing:
It should probably be |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've pushed some fixup commits already for the minor things. There are some others I've commented on here, could you take a look?
Thanks again for taking the time to contribute this.
</p> | ||
<p><b>Specifications</b>:</p> | ||
<ul> | ||
<li>CR-7iA/L - Normal Range</li> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just making sure: have you verified this? What did you choose in the initial robot setup?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Verifying this now. J3 limits on Fanuc change depending on J2, and since it's linked-arm, the J3 value is also tied to J2. Is there any way to have the limits of J3 updated based on the current value of J2? Unless the limits are set small enough that they are always within the actual limits, there will always be cases where you can plan outside of actual limits
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
re: limits based on J2-J3: true, but normal range only refers to the range of motion of J1 in this case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Limits have been update as of manual. I don't see any reference to max joint speeds in the manual though
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, Fanuc doesn't do that for their CR range. Where'd you get the joint speed limits that you have in there now?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you get me a copy of all sy*.va
files on the controller? Either simulated or real, doesn't matter. A zip file to my email would be very much appreciated.
FTP is probably easiest.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will get a backup to you shortly
fanuc_cr7ia_support/package.xml
Outdated
</ul> | ||
<p> | ||
Joint limits and maximum joint velocities are based on the information in | ||
the FANUC Robot CR-7iA Mechanical Unit Operator's Manual. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you please be exact about which version of the manual you used? Fanuc documents are versioned, so I'd like this to be as specific as possible. It should be something like B-NNNNNLL/VV
(with NNNNN
the doc id, LL
the language and VV
the revision).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated
fanuc_cr7ia_support/package.xml
Outdated
</description> | ||
<author>Dave Niewinski</author> | ||
<maintainer email="dniewinski@clearpathrobotics.com">dniewinski@clearpathrobotics.com</maintainer> | ||
<maintainer email="g.a.vanderhoorn@tudelft.nl">G.A. vd. Hoorn (TU Delft Robotics Institute)</maintainer> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've added myself as maintainer, as we do that for all ROS-I packages.
Are you actually planning to maintain this? I'd very much welcome that, but it is a committment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can maintain, but you would likely be better-suited. I'll just contribute
URDF: | ||
package: fanuc_cr7ia_support | ||
relative_path: urdf/cr7ial.xacro | ||
use_jade_xacro: true |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've added this to make MoveIt enable Jade+ xacro on Indigo.
<joint name="joint_4" value="0" /> | ||
<joint name="joint_5" value="-1.4311" /> | ||
<joint name="joint_6" value="0" /> | ||
</group_state> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This group_state
seems rather specific to your setup on the Ridgeback, could you remove it from this config?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe that is standard shipping position on this arm. Took it from the default ship program
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll remove this
<chain base_link="base_link" tip_link="tool0" /> | ||
</group> | ||
<!--GROUP STATES: Purpose: Define a named state for a particular group, in terms of joint values. This is useful to define states like 'folded arms'--> | ||
<group_state name="all-zeroes" group="manipulator"> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not a native speaker, but I believe the plural of zero
is zeros
. zeroes
would be the verb.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yup. English is a wonderful language
<joint name="joint_6" value="0" /> | ||
</group_state> | ||
<!--VIRTUAL JOINT: Purpose: this element defines a virtual joint between a robot link and an external frame of reference (considered fixed with respect to the robot)--> | ||
<virtual_joint name="MountPoint" type="fixed" parent_frame="arm_mount_point" child_link="base_link" /> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could I ask you to change the name
of the virtual_joint
to FixedBase
? That is a ROS-I convention.
Additionally, the parent_frame
would be world
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If this is the convention, not a problem. I'm not a fan of the mounting point being called "world" because a robot's world isn't necessarily there (ie. fanuc), but that is just a personal opinion
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's really just a convention, and I don't expect people to re-use MoveIt configs as-is anyway, apart from some initial testing maybe (who has a single robot in complete isolation to plan for).
The "world" frame that you are referring to is what Fanuc calls the World Frame, which is modelled with the base
frame in the urdf.
kinematics_solver: kdl_kinematics_plugin/KDLKinematicsPlugin | ||
kinematics_solver_search_resolution: 0.005 | ||
kinematics_solver_timeout: 0.005 | ||
kinematics_solver_attempts: 3 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would actually recommend you use the trac_ik
plugin for this setup.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just curious, but what are the differences between the two? I've had decent success with KDL so far
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please see traclabs/trac_ik.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In my very minimal testing, KDL seems less likely to switch arm configurations than trac, or when it does, they are more minor swings
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You are probably using the Speed
solve_type
. You'll want to configure Distance
. See the trac_ik
docs.
- PRMkConfigDefault | ||
- PRMstarkConfigDefault | ||
projection_evaluator: joints(joint_1,joint_2) | ||
longest_valid_segment_fraction: 0.05 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you please add a default_planner_config
entry here? See fanuc_lrmate200ib_moveit_config for an example.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not a problem
</description> | ||
<author email="dniewinski@clearpathrobotics.com">Dave Niewinski</author> | ||
<maintainer email="dniewinski@clearpathrobotics.com">Dave Niewinski</maintainer> | ||
<maintainer email="g.a.vanderhoorn@tudelft.nl">G.A. vd. Hoorn (TU Delft Robotics Institute)</maintainer> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See earlier comment about maintainer
in fanuc_cr7ia_support
.
… a cr7ial. Tested on a real arm and in roboguide. Actually made the tests worthwhile
@dniewinski: I think you just reverted all my changes. Was that intentional? |
@gavanderhoorn That was not intentional. I had the tests fixed up last night and forgot to push. Pushed right when I got in without checking first. Sorry about that. Feel free to blow mine away, they were very minor |
I'll see if I can rebase mine. Would be nice if you could look at my remaining comments in the mean time. |
Welcome back changes :) Sorry again about that |
@@ -1,5 +1,6 @@ | |||
<?xml version="1.0" ?> | |||
<robot xmlns:xacro="http://ros.org/wiki/xacro"> | |||
<xacro:property name="pi" value="3.1415926535897931" /> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure this should've been part of this commit?
Is it still necessary on your machine? Jade+ xacro should already have this defined.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm using Indigo, so I need it there for testing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you start xacro
with the --inorder
command line option (which I added: 4618626, and the load_cr7ial.launch
already had) then it uses Jade+ xacro. Does that not work for you?
I think I got all of the requested changes |
Just following up. Is there anything left to be done with this before it is merged? |
I just want to test it under Indigo before I merge. |
One more thing btw: the joint position limits for J2 and J3 that you set in b80aab5 seem to be different from the ones in the system variables. Where did you find those values? |
The joint limits in the controller won't match the URDF because their kinematics are different. When you move J2, the J3 link should also move, but it doesn't. This means that the value of that joint won't match, same with the limits. Since the URDF is not setup as a linked-arm, it makes the J3 limits easier to do, but they won't match what the controller "thinks" its limits are. As far as J2, the limits I have set are from the manual, not from my machine, just in case my robot is different |
I'm not too happy with the limits of Testing was successful, so I'll wait on Travis to be happy and then I'll merge. Thanks for the contribution 👍 |
We'll probably have to fix-up the collision meshes for |
Everything passed. Merging. |
Added a cr7ia support library and a urdf and moveit configuration for a cr7ial. Tested on a real arm and in roboguide