Hello,
I'm also currently working with UR robots. Until now I've set up rviz with the appropriate urdf/xacro model of the UR robot and 3D sensors. Next I would like to move the robot and visualize the motion on the screen in rviz. After starting the ur_driver and running the test_drive.py it is possible to move the robot in an unpredictable way. Thus I'm interested in your experience with the Move Group so far and it would be nice, if you could share this with us.
If some topic names doesn't match as you mentioned, you can try to remap them in launch file like here: http://wiki.ros.org/roslaunch/XML/remap
Questions:
- I would like to know, how to close the gap between rviz and ur_driver to show the real state of the robot in the rviz simulation.
- Which task does the moveit_controller_manager?
- Do you have some example code concerning the ur5 robots, that you can share with us on github?
- Besides the ur_driver I found the deserialize.py. What for is that program?
Greets,
M.W.
--
You received this message because you are subscribed to the Google Groups "swri-ros-pkg-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to swri-ros-pkg-d...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
I'm flying tonight, so I can't give a full answer, but if you launch
Move_group.launch
alongside ur_driver and moveit_rviz.launch
It should set up a controller for the real robot as well as the rviz. I can show you some sample planning code on Monday when I return.
You received this message because you are subscribed to a topic in the Google Groups "swri-ros-pkg-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/swri-ros-pkg-dev/5KBACyQNJro/unsubscribe.
To unsubscribe from this group and all its topics, send an email to swri-ros-pkg-d...@googlegroups.com.
I hope you had a pleasant flight.
It worked actually with Move_group, rviz and ur_driver. Thanks a lot. Nevertheless I am curious to see your code.
During the visualization one error occurred, that I had already with a 3D sensor, which was connected via network.
The data of the 3D sensor or rather the state of the robot flickers between the home position and the active state every few seconds. I suppose visualization error is related to the frequency of the published topics. Maybe there is something like a buffer needed, that buffers the published topics before showing them.
Many greetings,
Michael Wojtynek
Thanks, the /joint_state_publisher was actually running and causes the flickering.
Your code example helped me to get an idea how the application of moveit has to look like. Rviz, moveit and the ur_driver are now communicating well. There is only one gap left, which has to be closed by moveit_controller_manager until the ur robots does its movement. I´ve red that therefore the pr2_controller_manager could be used.
The problem is, that the pr2 package is huge with a lot of dependencies. By trying to compile it with catkin_make I a get lot of errors. Do you have a hint how to solve the problem or some code example from your launch file?
Greets,
Michael Wojtynek
-----Ursprüngliche Nachricht-----
Von: swri-ros...@googlegroups.com im Auftrag von Pætur Dal Christiansen
Gesendet: Fr 23.05.2014 09:12
An: swri-ros...@googlegroups.com
Cc: Wojtynek, Michael
Betreff: Re: [ROS-Industrial] Universal Robots UR5 & UR10 packages
The only occasion I've experienced that flicker in rviz is when I have a
driver running with the real robot and a separate /joint_state_publisher,
usually reserved for simulation. They'll both publish on the same topic and
cause the thing to go "quantum" ;) You can just try
rosnode kill /joint_state_publisher
And see if it helps, I don't know if that's the problem.
As for running the UR5 with moveit, I have only one readable example right
at the moment. Please note that in this code I am using the "ee_link" as my
reference frame, meaning that all pose values are *relative to the current
position of the end effector*. This is just some experimental code that I
> > email to swri-ros-pkg-d...@googlegroups.com <javascript:>.
> > For more options, visit https://groups.google.com/d/optout.
> >
> > --
> > You received this message because you are subscribed to a topic in the
> > Google Groups "swri-ros-pkg-dev" group.
> > To unsubscribe from this topic, visit
> >
> https://groups.google.com/d/topic/swri-ros-pkg-dev/5KBACyQNJro/unsubscribe
> > .
> > To unsubscribe from this group and all its topics, send an email to
> > swri-ros-pkg-d...@googlegroups.com <javascript:>.
> > For more options, visit https://groups.google.com/d/optout.
> >
>
> --
> You received this message because you are subscribed to the Google Groups
> "swri-ros-pkg-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to swri-ros-pkg-d...@googlegroups.com <javascript:>.
The action controller seems to work. Now I have the same issue you mentioned in your first post. Here is the quote:
"[...] I need to change the name of the action controller to be able to execute any motion plans. The controller advertised by ur_driver is called /follow_joint_trajectory ,while the move_group configuration tries to publish to /arm_controller/follow_joint_trajectory."
The error message I get is:
[ERROR] [...]: Action client not connected: arm_controller/follow_joint_trajectory
[ERROR] [...]: No controller handle for controller 'arm_controller'. Aborting.
Could someone tell me where I should rename the topics to publish under the same topic name?
-----Ursprüngliche Nachricht-----
Von: swri-ros...@googlegroups.com im Auftrag von Wojtynek, Michael
Gesendet: Mi 04.06.2014 00:29
An: swri-ros...@googlegroups.com; swri-ros...@googlegroups.com
Betreff: AW: [ROS-Industrial] Universal Robots UR5 & UR10 packages
Michael,
Disclaimer: I haven’t tested this yet, but I’m reasonably confident it should work.
I believe that MoveIt uses the “<moveit_pkg>/config/controllers.yaml” file to define the action name to use for sending motion commands. This file is initially blank, when created by the MoveIt Setup Assistant, and must be populated by the end-user to match their particular robot-interface setup.
As written in the Create_a_MoveIt_Pkg_for_an_Industrial_Robot wiki tutorial, the “name” and “ns” parameters seem backwards to me. We typically create our MoveIt packages with a blank “controller_list[].name” parameter, so that MoveIt is looking for the action in the root namespace. I believe that this is what you’re looking for, given your description below.
That same tutorial page also walks through setting up a moveit_planning_execution.launch file, which is often helpful for us to bring up the robot interface, moveit nodes, and rviz from a single launch file. The default template also provides launch-file parameters to allow you to easily switch between a hardware interface and the industrial_robot_simulator, for testing.
Hope this helps!
Jeremy Zoss
Robotics and Automation Engineering
Southwest Research Institute
Michael,
It is true that MoveIt requires a controller_manager node, to supervise distributing joint commands to various robot/servo-interface nodes. MoveIt does not know how these commands should be distributed, so requires the end-user to create their own controller_manager node. In the case of many industrial robots, this is an unnecessary layer of abstraction, as the joint->robotController mapping is straightforward and trivial.
Rather than develop our own ROS-I controller manager, we initially used the PR2 controller manager, with most of its functionality disabled. This worked, with minimal development/configuration for most industrial robots, but does require installing the large PR2 stack just for a small component.
Somewhat recently, MoveIt has provided a default controller_manager for trivial cases such as our industrial robots. The moveit_simple_controller_manager performs the same functionality as the mostly-disabled pr2_controller_manager, but doesn’t require any additional packages to be installed. The current Create_a_MoveIt_Pkg_for_an_Industrial_Robot wiki Tutorial recommends using the moveit_simple_controller_manager instead of the pr2_controller_manager.
Hope this helps!
Jeremy Zoss
Robotics and Automation Engineering
Southwest Research Institute
<launch> <!-- Launch moveit --> <group> <!-- Remap follow_joint_trajectory --> <remap from="/arm_controller/follow_joint_trajectory/cancel" to="/follow_joint_trajectory/cancel"/> <remap from="/arm_controller/follow_joint_trajectory/feedback" to="/follow_joint_trajectory/feedback"/> <remap from="/arm_controller/follow_joint_trajectory/goal" to="/follow_joint_trajectory/goal"/> <remap from="/arm_controller/follow_joint_trajectory/result" to="/follow_joint_trajectory/result"/> <remap from="/arm_controller/follow_joint_trajectory/status" to="/follow_joint_trajectory/status"/> <include file="$(find ur5_moveit_config)/launch/move_group.launch"/> </group> </launch>
To unsubscribe from this group and all its topics, send an email to swri-ros-pkg-d...@googlegroups.com.
Thank you guys for your help. Finally the ur5 did his first movements via moveit!!
The move_group.launch includes the trajectory_execution.launch.xml, and the trajectory_execution.launch.xml includes ur5_moveit_controller_manager.launch.
The last one is empty, if the moveit_config was built by moveit assistant.
I have included the controllers.yaml like this:
<launch>
<rosparam file="$(find ur5_moveit_config)/config/controllers.yaml"/>
</launch>
and I have replaced the name in the controller like you said Pætur Dal:
- name: ""
Many Greetings,
Michael Wojtynek
-----Ursprüngliche Nachricht-----
Von: swri-ros...@googlegroups.com im Auftrag von Pætur Dal Christiansen
Gesendet: Mi 04.06.2014 17:25
An: swri-ros...@googlegroups.com
Betreff: Re: [ROS-Industrial] Universal Robots UR5 & UR10 packages
>> wiki Tutorial recommends using the moveit_simple_controller_manager instead
>> of the pr2_controller_manager.
>>
>>
>>
>> Hope this helps!
>>
>> Jeremy Zoss
>>
>> Robotics and Automation Engineering
>>
>> Southwest Research Institute
>>
>>
>>
>> *From:* swri-ros...@googlegroups.com *On Behalf Of *Wojtynek,
>> Michael
>> *Sent:* Tuesday, June 03, 2014 5:30 PM
>> *To:* swri-ros...@googlegroups.com;
>> swri-ros...@googlegroups.com
>> *Subject:* AW: [ROS-Industrial] Universal Robots UR5 & UR10 packages
Dear Michael,
after reading about the problems with the MoveIt! Packages for the UR5 and UR10 on the mailing list here, I have made some changes to solve these issues.
(I also was the one updating the X_movit_config packages when preparing the hydro releases ;)
You can check out my branch https://github.com/ipa-fxm/universal_robot/tree/issue/update_readme with the changes related to this discussion (they are not merged yet).
I’d would be great if you could test the changes on your hardware and write a comment to the according issues https://github.com/ros-industrial/universal_robot/pull/73
Thanks,
Felix
Pætur Dal-Christiansen
Thanks, glad to hear it works for you!
I am also happy to let you know that the respective PullRequest https://github.com/ros-industrial/universal_robot/pull/73 has been merged into https://github.com/ros-industrial/universal_robot (branch: hydro-devel) this morning with some more minor changes, i.e. simplification.
As to your questions:
- Yes, the urX_moveit_planning_execution.launch files are a wrapper for move_group.launch simply making sure that you can use the same launch-file both for simulation as well as with a real robot. This was not possible previously due to the namespace inconsistence that you mention.
- Yes, a <group> tag could help remapping the namespaces correctly. There are other ways as well, e.g. use another launch file argument “prefix” and then start urX_moveit_planning_execution.launch twice with different values for it…But that will not be the standard use-case, thus you probably would need to do this in your own fork/sources.
- The ur_kinematics has been developed by Kelsey Hawkins from GeorgiaTech. It holds the analytical IKFast plugins for the universal robots. I haven’t used it recently myself, so I can’t tell whether it is currently working. However, it was meant to be another option beside the numerical KDL IK solver currently used within the moveit_configs https://github.com/ros-industrial/universal_robot/blob/hydro-devel/ur5_moveit_config/config/kinematics.yaml
For the most reliable information contact Kelsey.
One more note on using MoveIt! with the URs (I also mentioned this in the README):
Make sure you use the joint_limited version. Otherwise you won’t be able to find plans most of the time!
Best,
Hi Pætur,
the configuration of which kinematics solver to use for a robot within MoveIt! is done in the kinematics.yaml file within the moveit_config.
See also: http://moveit.ros.org/wiki/Kinematics/Configuration
The currently used solver is the numeric KDL solver that is set up by simply parsing the robot description.
If you want to use another (custom/hardware-specific) kinematics solver, you need to provide it as a kinematics plugin deriving it from the KinematicsBase class (http://moveit.ros.org/doxygen/classkinematics_1_1KinematicsBase.html)
How to add a custom kinematics solver is described here: http://moveit.ros.org/wiki/Kinematics/Custom_Plugin
There is even a documentation for getting a IKFast plugin for your robot using openRAVE: http://moveit.ros.org/wiki/Kinematics/IKFast
My colleague, Matthias Luedtke, indeed once did this for the universal robots. You can find some of his code here: https://github.com/ipa320/cob_manipulation/tree/hydro_dev/cob_kinematics
However, as the API of the KinematicsBase class was changed frequently, we stopped adjusting this package to the latest changes. Also, the install tags and plugin export is not yet correct in Hydro.
If you could get this kinematics plugin working, this would be a great contribution for the universal_robot repository ;-)
As to your second question: the limits you found in the joint_limits.yaml are taken directly from the robot’s URDF (this step is done automatically when I ran the MoveIt-SetupAssistant). As there are no acceleration limits in the URDF, they are disabled by default. In case these values are wrong (I don’t know what the actual hardware-side limits are!), maybe we need to change the URDF and adjust the joint_limits.yaml file.
Can anyone confirm the velocity and acceleration limits?
As above, this would also be a great contribution ;-)
With respect to the pendant issue, I’ll comment on the related github issue.
With best regards,
Felix,
thank you for the comments in the ur_driver and the simplification of the launch files. Now it is much more easier to get through the chain of launch files.
What's the difference between MoveItSimpleControllerManager and Pr2MoveItControllerManager? The only disparity i can see at the moment is line 4 in the controllers.yaml.
--------------------------------
MoveItSimpleControllerManager
1 controller_list:
2 - name: ""
3 action_ns: follow_joint_trajectory
4 type: FollowJointTrajectory
--------------------------------
Pr2MoveItControllerManager
1 controller_list:
2 - name: ""
3 action_ns: follow_joint_trajectory
4 default: true
--------------------------------
Am I right with my assumption?
Another issue I have, is the WallTime Warning because of a lack of calibration offset. Where can I define this calibration to get rid of this warning?
[WARN] [WallTime: 1403022047.979266] No calibration offset for joint "arm_shoulder_pan_joint"
[WARN] [WallTime: 1403022047.981133] No calibration offset for joint "arm_shoulder_lift_joint"
[WARN] [WallTime: 1403022047.982420] No calibration offset for joint "arm_elbow_joint"
[WARN] [WallTime: 1403022047.983888] No calibration offset for joint "arm_wrist_1_joint"
[WARN] [WallTime: 1403022047.985465] No calibration offset for joint "arm_wrist_2_joint"
[WARN] [WallTime: 1403022047.987173] No calibration offset for joint "arm_wrist_3_joint"
[ERROR] [WallTime: 1403022047.987266] Loaded calibration offsets: {}
Last but not least, which kinematic solver are you guys using? I am using the IKfast plugin, because the kinematic solvers from the OMPL lib often delivers no result. At this point I have to mention that I've used the solvers only in Rviz with the "plan & execute" button until now.
Many Greetings,
Michael Wojtynek
-----Original Message-----
From: swri-ros...@googlegroups.com on behalf of Pætur Dal Christiansen
Sent: Mon 6/16/2014 12:57 PM
To: swri-ros...@googlegroups.com
Subject: Re: [ROS-Industrial] Universal Robots UR5 & UR10 packages
Hey Felix
Thanks for the response, it clears up a lot of issues that I've been
struggling to undersand properly until now.
With regard to the kinematics: I don't really understand how to apply the
software. My understanding is that in order for *ur_kinematics *to run
directly through MoveIt, it must be converted to a MoveIt plugin? Kelsey
informed me, that some work had been done to integrate *ur_kinematics *with
MoveIt, be he didn't know how far along that work was. Do you know?
Another small detail: In *ur5_moveit_config/config/joint_limits.yaml* -
there are velocity limits for all joints equal to pi. However, the *ur_driver
*will sometimes complain if it receives velocities higher than 2. From a
cursory glance it looks like this limit is the default value, in case the
correct data is not available on the Parameter Server. Perhaps it would be
a solution to load some parameters from *ur_bringup *launch files?
regards
Pætur Sloan Dal-Christiansen
On 13 June 2014 13:39, GMAIL <felixm...@gmail.com> wrote:
> Thanks, glad to hear it works for you!
>
> I am also happy to let you know that the respective PullRequest
> https://github.com/ros-industrial/universal_robot/pull/73 has been merged
> into https://github.com/ros-industrial/universal_robot (branch:
> hydro-devel) this morning with some more minor changes, i.e. simplification.
>
>
>
> As to your questions:
>
> - Yes, the urX_moveit_planning_execution.launch files are a
> wrapper for move_group.launch simply making sure that you can use the same
> launch-file both for simulation as well as with a real robot. This was not
> possible previously due to the namespace inconsistence that you mention.
>
> - Yes, a <group> tag could help remapping the namespaces
> correctly. There are other ways as well, e.g. use another launch file
> argument "prefix" and then start urX_moveit_planning_execution.launch twice
> with different values for it.But that will not be the standard use-case,
> thus you probably would need to do this in your own fork/sources.
>
> - The ur_kinematics has been developed by Kelsey Hawkins from
> GeorgiaTech. It holds the analytical IKFast plugins for the universal
> robots. I haven't used it recently myself, so I can't tell whether it is
> currently working. However, it was meant to be another option beside the
> numerical KDL IK solver currently used within the moveit_configs
> https://github.com/ros-industrial/universal_robot/blob/hydro-devel/ur5_moveit_config/config/kinematics.yaml
>
> For the most reliable information contact Kelsey.
>
>
>
> One more note on using MoveIt! with the URs (I also mentioned this in the
> README):
>
> Make sure you use the joint_limited version. Otherwise you won't be able
> to find plans most of the time!
>
>
>
> Best,
>
> Felix
>
>
>
>
>
>
>
>
>
> *From:* swri-ros...@googlegroups.com [mailto:
> swri-ros...@googlegroups.com] *On Behalf Of *Pætur Dal Christiansen
> *Sent:* Thursday, June 12, 2014 12:21 PM
> *To:* swri-ros...@googlegroups.com
>
> *Subject:* Re: [ROS-Industrial] Universal Robots UR5 & UR10 packages
>
>
>
> Hello Felix
>
> Love the new readme file, it will help new users immensely.
>
> I've run your updated files on my machine, and everything I've run so far
> still works, although I haven't run much through the MoveIt functionality
> yet. Before I continue, I have a couple of questions:
>
> - If I understand correctly, "*ur5_moveit_planning_execution.launch" *is
> a wrapper for the *"move_group.launch" *file, because the simulation
> still needs the *follow_joint_trajectory *to exist in the *arm_controller
> *namespace, while the actual robot does not, is that correct?
> - If I am running two separate robots, would it be enough to just wrap
> *"**ur5_moveit_planning_execution.launch" *in a separate namespace
> like so:
> <group ns="robot_1"> ... etc ? I've tried this once, but couldn't make
> it work. Either I am not doing things correctly, or somewhere in the *ur5_moveit_config
> *there is a "/" that shouldn't be there.
> - Not really related to the rest, but since you seem to know: what is
> *ur_kinematics* and should I be using it?
>
> Pætur Dal-Christiansen
>
>
> On Wednesday, 11 June 2014 17:59:13 UTC+2, Felix Messmer (IPA) wrote:
>
> Dear Michael,
>
>
>
> after reading about the problems with the MoveIt! Packages for the UR5 and
> UR10 on the mailing list here, I have made some changes to solve these
> issues.
>
> (I also was the one updating the X_movit_config packages when preparing
> the hydro releases ;)
>
> You can check out my branch
> https://github.com/ipa-fxm/universal_robot/tree/issue/update_readme with
> the changes related to this discussion (they are not merged yet).
>
> I'd would be great if you could test the changes on your hardware and
> write a comment to the according issues
> https://github.com/ros-industrial/universal_robot/pull/73
>
>
>
> Thanks,
>
> Felix
>
>
>
>
>
>
>
> *On Behalf Of *Wojtynek, Michael
> *Sent:* Wednesday, June 11, 2014 9:54 AM
--
You received this message because you are subscribed to a topic in the Google Groups "swri-ros-pkg-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/swri-ros-pkg-dev/5KBACyQNJro/unsubscribe.
Hi Michael,
well, the main reason for using the MoveItSimpleControllerManager was to be independent from anything that is PR2-related ;-)
…and from a functionality point of view there seems to be no difference…
The changes in the controller.yaml are then simply to be compatible with this change as well as with deprecation warnings that were given with the old format.
The ur_driver is looking for the calibration_offset in the URDF (see https://github.com/ros-industrial/universal_robot/blob/hydro-devel/ur_driver/src/ur_driver/driver.py#L635)
However, the ur_driver wants to find a xml property “value” within the “calibration_offset” tag. According to http://wiki.ros.org/urdf/XML/joint there only exists a “rising” or “falling” xml property within the “calibration” xml tag.
Maybe there once there was a different syntax in the XML format? I guess this part of the ur_driver is outdated.
However, apparently joint_offsets can also be hardcoded here https://github.com/ros-industrial/universal_robot/blob/hydro-devel/ur_driver/src/ur_driver/driver.py#L28
Also, maybe this commit is related to the calibration_offset issue https://github.com/ros-industrial/universal_robot/commit/2e96f079f93dffcea32287684a4aee6e8953430f
As to IKFast, we have been using a IKFast plugin for both hardware and simulation as well (see https://github.com/ipa320/cob_manipulation/tree/hydro_dev/cob_kinematics and https://github.com/ipa320/cob_manipulation/blob/hydro_dev/cob_moveit_config/raw3-1/config/kinematics.yaml).
However, it was a pain always keeping the plugin up-to-date with the changes in the KinematicsBase class. Thus, and because we currently don’t use the UR hardware that much, we have the KDL plugin loaded in the moveit_config.
Currently, we don’t have a working IKFast plugin for the UR robots. If you are saying that you have the according code around, would it be possible for you to integrate the plugin e.g. into the ur_kinematics package so that others are able to use it as well?
It seem that the KinematicsBase class is not affected by a lot of API changes recently, so it might be worth giving the plugin another chance!
Also, did you use Kelsey’s code for the plugin or OpenRAVE?
Best regards,
Felix
Felix,
thank you for the explanation about MoveItSimpleControllerManager. I´m quite satisfied to be independant from the PR2 packages. :)
The calibration_offset issue:
The driver.py which I´m using has empty braces (joint_offsets = {}) like in linie 28 of your github code. In my URDF I couldn´t find any offsets. Is there any practical use for the triggering of a rising or falling edge?
Ikfast:
Yes Pætur, I`ve used that description (http://moveit.ros.org/wiki/Kinematics/IKFast). Finally I´ve copied the lib_moveit_ikfast_plugin.so from catkin_ws/devel/lib to IKfast folder, that I´ve created for the IKfast plugin. The lib folder inside the IKfast folder has to be created aswell.
Maybe you can show a picture or video from elbow bending, if it´s to hard to explain.
In case that I´ve followed the readme I´ve used OpenRAVE instead if Kelsey´s code. I´ve to take a look at ur_kinematics. It looks very interessting and it´s not a bad idea to implement ikfast at this place. At the moment ikfast is located in my catkin workspace.
Many Greetings
Michael Wojtynek
-----Ursprüngliche Nachricht-----
Von: swri-ros...@googlegroups.com im Auftrag von GMAIL
Gesendet: Mi 18.06.2014 14:31
An: swri-ros...@googlegroups.com
Betreff: RE: [ROS-Industrial] Universal Robots UR5 & UR10 packages
Hi Michael,
well, the main reason for using the MoveItSimpleControllerManager was to be
independent from anything that is PR2-related ;-)
...and from a functionality point of view there seems to be no difference...
Felix
From: swri-ros...@googlegroups.com
[mailto:swri-ros...@googlegroups.com] On Behalf Of Wojtynek, Michael
Sent: Wednesday, June 18, 2014 10:57 AM
To: swri-ros...@googlegroups.com; swri-ros...@googlegroups.com
Subject: RE: [ROS-Industrial] Universal Robots UR5 & UR10 packages