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

Added cr7ial support #33

Merged
merged 21 commits into from
Jul 28, 2017
Merged

Added cr7ial support #33

merged 21 commits into from
Jul 28, 2017

Conversation

dniewinski
Copy link
Contributor

Added a cr7ia support library and a urdf and moveit configuration for a cr7ial. Tested on a real arm and in roboguide

@gavanderhoorn
Copy link
Member

Thanks again for the PR.

Unfortunately, Travis is failing:

FAILURE:
[/root/catkin_ws/src/fanuc_experimental/fanuc_cr7ia_support/tests/roslaunch_test.xml]:
	while processing /root/catkin_ws/src/fanuc_experimental/fanuc_cr7ia_support/launch/load_cr7ia.launch:
Invalid roslaunch XML syntax: [Errno 2] No such file or directory: u'/root/catkin_ws/src/fanuc_experimental/fanuc_cr7ia_support/launch/load_cr7ia.launch'

It should probably be load_cr7ial.launch?

Copy link
Member

@gavanderhoorn gavanderhoorn left a 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>
Copy link
Member

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?

Copy link
Contributor Author

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

Copy link
Member

@gavanderhoorn gavanderhoorn Jul 21, 2017

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.

Copy link
Contributor Author

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

Copy link
Member

@gavanderhoorn gavanderhoorn Jul 21, 2017

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?

Copy link
Member

@gavanderhoorn gavanderhoorn Jul 21, 2017

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.

Copy link
Contributor Author

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

</ul>
<p>
Joint limits and maximum joint velocities are based on the information in
the FANUC Robot CR-7iA Mechanical Unit Operator's Manual.
Copy link
Member

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).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Updated

</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>
Copy link
Member

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.

Copy link
Contributor Author

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
Copy link
Member

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>
Copy link
Member

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?

Copy link
Contributor Author

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

Copy link
Contributor Author

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">
Copy link
Member

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.

Copy link
Contributor Author

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" />
Copy link
Member

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.

Copy link
Contributor Author

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

Copy link
Member

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
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 actually recommend you use the trac_ik plugin for this setup.

Copy link
Contributor Author

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

Copy link
Member

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.

Copy link
Contributor Author

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

Copy link
Member

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
Copy link
Member

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.

Copy link
Contributor Author

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>
Copy link
Member

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
@gavanderhoorn
Copy link
Member

@dniewinski: I think you just reverted all my changes. Was that intentional?

@dniewinski
Copy link
Contributor Author

dniewinski commented Jul 21, 2017

@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

@gavanderhoorn
Copy link
Member

I'll see if I can rebase mine.

Would be nice if you could look at my remaining comments in the mean time.

@dniewinski
Copy link
Contributor Author

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" />
Copy link
Member

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.

Copy link
Contributor Author

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

Copy link
Member

@gavanderhoorn gavanderhoorn Jul 21, 2017

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?

@dniewinski
Copy link
Contributor Author

I think I got all of the requested changes

@dniewinski
Copy link
Contributor Author

Just following up. Is there anything left to be done with this before it is merged?

@gavanderhoorn
Copy link
Member

I just want to test it under Indigo before I merge.

@gavanderhoorn
Copy link
Member

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?

@dniewinski
Copy link
Contributor Author

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

@gavanderhoorn
Copy link
Member

I'm not too happy with the limits of joint_3, as in all other support pkgs we have specified the actual limits. I understand the linked kinematics problem, but I feel the joint limits in a xacro are not the place to work around that. For now we'll leave it like this though.

Testing was successful, so I'll wait on Travis to be happy and then I'll merge.

Thanks for the contribution 👍

@gavanderhoorn
Copy link
Member

We'll probably have to fix-up the collision meshes for link_2 and possibly link_4, similar to what was reported for the basic 200iD (#34), but I'll do that later.

@gavanderhoorn
Copy link
Member

Everything passed. Merging.

@gavanderhoorn gavanderhoorn merged commit af1f83f into ros-industrial:indigo-devel Jul 28, 2017
gavanderhoorn pushed a commit to gavanderhoorn/fanuc that referenced this pull request Feb 28, 2019
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.

2 participants