Universal Robots UR5 & UR10 packages

[Pætur Dal Christiansen]

Hi

I'm not certain this is the right place to post this question, but it's the only one I could find.

I'm currently working with the UR5 and UR10 robots, and their corresponding Moveit configuration packages, as they exist on Github. I've noticed that certain things do not work out of the box. For instance 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 readme file is also out of date, and some other things. It's mostly minor stuff, but I would like to know if I should post these comments / changes somewhere, or if perhaps the problem is on my side. I'm still a beginner with ROS. so it is quite possible I've set thing up a little backwards to the way they ought to be.

[G.A. vd. Hoorn - 3ME]

Pætur Dal Christiansen wrote:
> Hi

Hi Pætur,

> I'm not certain this is the right place to post this question, but it's the
> only one I could find.

this is certainly the right mailinglist for these sort of questions.
Bugs should probably be directly reported to the appropriate issue tracker.

> I'm currently working with the UR5 and UR10 robots, and their corresponding
> Moveit configuration packages, as they exist on Github. I've noticed that
> certain things do not work out of the box. For instance 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 readme file is also out of
> date, and some other things. It's mostly minor stuff, but I would like to
> know if I should post these comments / changes somewhere, or if perhaps the
> problem is on my side. I'm still a beginner with ROS. so it is quite
> possible I've set thing up a little backwards to the way they ought to be.

Yes, please do report any issues you encounter on the github issue
tracker for the universal_robot package [1]. Even if you think these are
only 'minor things', the fact that you came across them while working
with the packages indicates that there is some room for improvement.

Also, the packages you mention were recently updated, so any indication
that we missed something is valuable information.

Thanks,


Gijs
DRI, DBL, TU Delft
The Netherlands

[1] https://github.com/ros-industrial/universal_robot/issues

[Wojtynek, Michael]

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.

[Pætur Dal Christiansen]

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.

[Wojtynek, Michael]

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 

[Pætur Dal Christiansen]

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 worked with earlier, you'll probably want to work in reference to the "base_link". Apart from that, you can pretty much take any sample code from the moveit tutorials, and just replace the names and the numbers, and it should basically work:

#include <moveit/move_group_interface/move_group.h>
#include <moveit/planning_scene_interface/planning_scene_interface.h>

#include <moveit/robot_trajectory/robot_trajectory.h>
#include <moveit/trajectory_processing/iterative_time_parameterization.h>

#include <moveit_msgs/ExecuteKnownTrajectory.h>

int main(int argc, char **argv)
{
  // local variables
  float pi = 3.14159;

  ros::init(argc, argv, "move_cartesian_path");
  ros::NodeHandle node_handle;
  ros::AsyncSpinner spinner(1);
  spinner.start();

  // Setup
  moveit::planning_interface::MoveGroup group("manipulator"); // note the name of the planning group. This is for UR# robots
  moveit::planning_interface::PlanningSceneInterface planning_scene_interface;


  // Getting Basic Information
  // ^^^^^^^^^^^^^^^^^^^^^^^^^
  // We can print the name of the reference frame for this robot.
  ROS_INFO("Reference frame: %s", group.getPlanningFrame().c_str());
 
  // We can also print the name of the end-effector link for this group.
  ROS_INFO("End effector frame: %s", group.getEndEffectorLink().c_str());

  group.setPoseReferenceFrame("ee_link"); // all coordinates are relative to the position of the end effector
  moveit::planning_interface::MoveGroup::Plan my_plan;

 // Planning a Cartesian Path
  // ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  group.startStateMonitor();
  group.setStartStateToCurrentState();
  group.setPlanningTime(12);

  ROS_INFO_STREAM("current EE pose: " << group.getCurrentPose());

    // Cartesian Paths
  // ^^^^^^^^^^^^^^^
  // You can plan a cartesian path directly by specifying a list of waypoints
  // for the end-effector to go through.
  std::vector<geometry_msgs::Pose> waypoints;

  // not sure about this, I think it worked, but I've solved it now by looking up some positions
  geometry_msgs::Pose ROBOT_START_POSE;
  ROBOT_START_POSE.position.x = 0; ROBOT_START_POSE.position.y = 0; ROBOT_START_POSE.position.z = 0;
  ROBOT_START_POSE.orientation.x = 0; ROBOT_START_POSE.orientation.y = 0;
  ROBOT_START_POSE.orientation.z = 0; ROBOT_START_POSE.orientation.w = 0;

  geometry_msgs::Pose cartesian_target = ROBOT_START_POSE;
  waypoints.push_back(cartesian_target); // Start by doing nothing (probably not necessary)
  cartesian_target.position.y = 0.2;
  waypoints.push_back(cartesian_target);

  cartesian_target.position.z = 0.2;
  cartesian_target.position.y = 0.0;
  waypoints.push_back(cartesian_target);

  cartesian_target.position.z = -0.2;
  cartesian_target.position.y = 0.0;
  waypoints.push_back(cartesian_target);

  cartesian_target.position.z = 0.0;
  cartesian_target.position.y = -0.2;
  waypoints.push_back(cartesian_target);
 
  // We want the cartesian path to be interpolated at a resolution of 1 cm
  // which is why we will specify 0.01 as the max step in cartesian
  // translation. We will specify the jump threshold as 0.0, effectively
  // disabling it.
  // moveit_msgs::RobotTrajectory trajectory;
  moveit_msgs::ExecuteKnownTrajectory srv;
  double fraction = group.computeCartesianPath(waypoints,
                                               0.01, // eef_step
                                               0.0, // jump_threshold
                                               srv.request.trajectory, false);

  // The trajectory needs to be modified so it will include velocities as well.
  // First to create a RobotTrajectory object
  robot_trajectory::RobotTrajectory rt(group.getCurrentState()->getRobotModel(), "manipulator");

  // Second get a RobotTrajectory from trajectory
  rt.setRobotTrajectoryMsg(*group.getCurrentState(), srv.request.trajectory);
 
  // Thrid create a IterativeParabolicTimeParameterization object
  trajectory_processing::IterativeParabolicTimeParameterization iptp;
  // Fourth compute computeTimeStamps
  bool success = iptp.computeTimeStamps(rt);
  ROS_INFO("Computed time stamp %s",success?"SUCCEDED":"FAILED");
  // Get RobotTrajectory_msg from RobotTrajectory
  rt.getRobotTrajectoryMsg(srv.request.trajectory);

  ROS_INFO("Visualizing cartesian path plan (%.2f%% acheived)",
        fraction * 100.0);

    ros::ServiceClient client = node_handle.serviceClient<moveit_msgs::ExecuteKnownTrajectory>("/execute_kinematic_path");

    // send trajectory to arm controller
    srv.request.wait_for_execution = true;
    if (!client.call(srv))
    {
      ROS_INFO("Kinematic service call failed!");
    }

    if (srv.response.error_code.val < 1)
    {
      ROS_INFO_STREAM("Kinematic path service call returned error code : " << srv.response.error_code.val);
    } else
    {
      ROS_INFO("Sent Kinematic path to server");
    }

  ros::shutdown();
  return 0;

[Wojtynek, Michael]

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

[Wojtynek, Michael]

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

[Zoss, Jeremy K.]

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

[Zoss, Jeremy K.]

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

 

[Simon Jansen]

In addition to Jeremy's answer:

We didn;t want to change any of the files in the universal_robot, so we created our own launch files, where we renamed the topics.

Note that this is a work-around and renaming the namespace in the moveit config would of course be better

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

[Pætur Dal Christiansen]

I solved this problem simply by removing the reference to "arm_controller" in /config/controllers.yaml. Currently the line just says:

    - name: ""

It works, but I can't tell if this is a bad idea.

To unsubscribe from this group and all its topics, send an email to swri-ros-pkg-d...@googlegroups.com.

[Wojtynek, Michael]

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

>> <http://wiki.ros.org/Industrial/Tutorials/Create_a_MoveIt_Pkg_for_an_Industrial_Robot#Update_Configuration_Files>

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

[GMAIL]

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]

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

[GMAIL]

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,

[Pætur Dal Christiansen]

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

[Pætur Dal Christiansen]

Oh and one more thing: I sometimes need to move the robot using Universal Robots' own interface, and that will sometimes cause the ur_driver node to crash. I've found that messing around with the timeout variable in ur_drive.py will solve this issue - I think what happens is, when the timeout is set too low, ur_driver and the native UIControl will both try to control the robot at the same time. I don't know if you know the reason for setting the timeout value the way it is in ur_driver.py?

p.

[G.A. vd. Hoorn - 3ME]

On 16-6-2014 13:04, Pætur Dal Christiansen wrote:
> Oh and one more thing: I sometimes need to move the robot using Universal

> Robots' own interface, and that will sometimes cause the *ur_driver *node

> to crash. I've found that messing around with the timeout variable in
> ur_drive.py will solve this issue - I think what happens is, when the

> timeout is set too low, *ur_driver *and the native *UIControl *will both

> try to control the robot at the same time. I don't know if you know the
> reason for setting the timeout value the way it is in ur_driver.py?

This is a known issue with the current implementation, see [1].


Gijs

[1] https://github.com/ros-industrial/universal_robot/issues/54

[GMAIL]

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,

[Pætur Dal Christiansen]

Hello Felix

i don't know the actual hardware limits, but I believe the issue I am encountering is cause by the sequence of events of loading:

    max_velocity = rospy.get_param("~max_velocity", 2.0)

If you load ur_driver then there is no max_velocity on the parameter server, and the driver just substitutes 2.0 (I think that is what happens). Becaude the joint_limits.yaml only gets loaded once you start move_group.

As for custom kinematics, I would love to try to implement it, but I don't know if I can make it a part of my thesis, and so I might not have the time.

p.

[Wojtynek, Michael]

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

> *From:* swri-ros...@googlegroups.com [mailto:swri-ros...@googlegroups.com]

> *On Behalf Of *Wojtynek, Michael

> *Sent:* Wednesday, June 11, 2014 9:54 AM

[G.A. vd. Hoorn - 3ME]

On 18-6-2014 10:57, Wojtynek, Michael wrote:
[..]

> What's the difference between MoveItSimpleControllerManager and Pr2MoveItControllerManager? The only disparity i can see at the moment is line 4 in the controllers.yaml.

This was explained by Jeremy Zoss in an earlier email:

https://groups.google.com/forum/?_escaped_fragment_=msg/swri-ros-pkg-dev/5KBACyQNJro/FZVwn6Mo7h0J#!msg/swri-ros-pkg-dev/5KBACyQNJro/FZVwn6Mo7h0J


Gijs

[Pætur Dal Christiansen]

Hello Michael

Did you generate the IKFast plugin using the method described here:
http://moveit.ros.org/wiki/Kinematics/IKFast
??

Because when I use that solution, it insists on bending the "elbow" the wrong way. Hard to explain, but it's not working great.

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

[GMAIL]

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

[Wojtynek, Michael]

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