Weird DH parameters reading from ur_calibration

[thachdo]

I'm using UR5 with ROS Kinetic. The result of reading calibrated parameters using ur_calibration is as follows:

dh_theta: [-9.62699668632896e-06 -1.43707039992005 2.02543119975016 -0.588254688694989 4.13647390228702e-05 8.1737464953645e-06 ]

dh_a: [0.000279332356195598 -0.0566854832098269 -0.32646702272051 1.49388687216263e-05 2.23692592990586e-07 0 ]

dh_d: [0.0888794492754001 574.241384579456 -507.363402098168 -66.7676839353205 0.0949734691141216 0.0825625014554953 ]

dh_alpha: [1.57033858830411 -0.000733893428160216 0.00325607356326439 1.57040005185553 -1.57101000328584 0 ]

which is quite different from standard parameters here. Specifically,
dh_a[1] is too small and dh_d[1:4] are too large. Is this abnormal? How could I resolve that issue?

The result of the .yaml file is:

kinematics:
  hash: calib_11914550710326326731
  shoulder:
    x: 0
    y: 0
    z: 0.08887944927540013
    roll: -0
    pitch: 0
    yaw: -9.626996686328957e-06
  upper_arm:
    x: 0.0002793323561955981
    y: 0
    z: 0
    roll: 1.570338588304109
    pitch: 0
    yaw: 2.158839766170508e-05
  forearm:
    x: -0.4252272570400704
    y: 0
    z: 0
    roll: 3.141494820936201
    pitch: 3.140865310247571
    yaw: -3.141502430632191
  wrist_1:
    x: -0.3922288019679848
    y: -0.0003001522770219462
    z: 0.1108071247640628
    roll: 0.002708774761028905
    pitch: 0.001806809986672728
    yaw: -8.11176398879282e-06
  wrist_2:
    x: 1.493886872162628e-05
    y: -0.09497346165709802
    z: 3.763560472995243e-05
    roll: 1.570400051855527
    pitch: 0
    yaw: 4.136473902287017e-05
  wrist_3:
    x: 2.236925929905856e-07
    y: 0.08256249957069076
    z: -1.764166546013033e-05
    roll: 1.570582650303955
    pitch: 3.141592653589793
    yaw: -3.141584479843298

which is more close to the standard values. My target is to get the calibrated DH parameters. Is there any script to convert the .yaml file to DH parameters? Also, can I read the DH params directly from the teaching pendant interface?

[urrsk]

@thachdo Thanks for asking.
The DH notation is a complete notation, but have a singularity when two following joints have parallel rotation axis. This is the case for UR's shoulder, elbow and wrist 1 joints and there by causing the high numbers. And yes the units are meters and radians :-)
So even though the values is high, they are correct.

In the conversion to the yaml file, the 4DoF DH notation are translated to 6DoF in a way so it still represent the correct kinematics but also makes the graphics look right.

[thachdo]

Thanks @urrsk, but how can I convert the dh_a[1] and dh_d[1:4] (meter) into a proper range?

[urrsk]

Thanks @urrsk, but how can I convert the dh_a[1] and dh_d[1:4] (meter) into a proper range?

@thachdo what is your motivation? why would you like to convert it into "proper range"?

[thachdo]

@urrsk, I want to achieve DH parameters that are close to the standard values as in here my calculations, is there any way to get/read/show it?

[urrsk]

@thachdo the DH notation is a minimal notation, there are no other way to represent the same model with other values.
Can you give me an example of you problem? How do you want to use the values and for what?

[danzimmerman]

Specifically,
dh_a[1] is too small and dh_d[1:4] are too large. Is this abnormal? How could I resolve that issue?

@thachdo No, this is normal. The issue is the way that DH parameters are defined. As @urrsk says:

The DH notation is a complete notation, but have a singularity when two following joints have parallel rotation axis.

From this youtube video

You can align the joint frame origins anywhere along subsequent parallel axes, but that's for the special case of mathematically perfect parallel axes. In a real robot, parallel axes are never actually parallel, so the frame origin is uniquely defined AND it is possible for the common normal's intersection with the next axis to be very far away.

The calibrated DH parameters you have look correct and roughly similar in magnitude to the calibrated parameters for my UR5. Approximately +613 and -608 meters for d2 and d3 on mine.

You need to use those numbers, and the elbow joint's frame origin will be nearly 600m away and strangely twisted. DH parameters are an annoying representation for robots with subsequent parallel axes if you are doing anything other than moving the end-effector and you want intermediate reference frames that lie close to the robot's physical joint locations.

The representation used by URDF is much more stable in that regard.

[danzimmerman]

@thachdo See also ros-industrial/universal_robot#414 and related discussion

[thachdo]

Thanks @urrsk and @danzimmerman, sorry for my late reply.
I want to use the DH parameters to update the URDF file here. Could you suggest a proper way to get and update those values?

[gavanderhoorn]

The driver provides a utility to download the calibration from your controller and generates a .yaml file you can use. Unless something has changed recently, there should be no need to do any of this manually.

See the section in the readme about this.

[thachdo]

This is not about the usage. It's about calibrating. As mentioned above, I need these parameters to update the URDF file for further steps in my work. Reading .yalm using the ur_calibration package can't be useful here.

[gavanderhoorn]

Perhaps we're misunderstanding each other.

The .yaml file is combined with the .xacro to result in a kinematic model which almost perfectly describes the kinematics of your specific robot.

There should not be any need to update anything manually.

Run the calibration extraction and then always load the appropriate .xacro while pointing it to your calibration stored in the .yaml that ur_calibration created for you.

Reading .yalm using the ur_calibration package can't be useful here.

ur_calibration does not read the .yaml file. It generates it based on the DH data it reads from your CB.

[thachdo]

Since I'm using a URDF in here so having the .yaml can't be used in my case. My target is to update the following parameters in that urdf file:

    <xacro:property name="d1" value="0.163" />
    <xacro:property name="a2" value="-0.425" />
    <xacro:property name="a3" value="-0.392" />
    <xacro:property name="d4" value="0.127" />
    <xacro:property name="d5" value="0.100" />
    <xacro:property name="d6" value="0.100" />

The ur_calibration converts the factory DH parameters to x, y, z, roll, pitch, yaw format. Is there any way to get values d1, d4, d5, d6 and a2, a3 as above?

[danzimmerman]

The ur_calibration converts the factory DH parameters to x, y, z, roll, pitch, yaw format. Is there any way to get values d1, d4, d5, d6 and a2, a3 as above?

I do not think you can do it this way. I think those parameters could simply be replaced with the corresponding values from the DH parameters, but it would result in a URDF file where your forearm link frame origin was ~600m away from the robot.

This will cause issues with the placement of the visual, collision, and inertia models, just like the description shown here:

The important thing here is that the picture above is what a DH-based model for the calibrated robot is going to look like (if not worse). So if you managed to convert the x, y, z, r, p, y format back to DH (which I'm not sure can be done strictly algorithmically), you would just get an unusable structure like the picture above.

If you don't use the calibrated robot description generated by the calibration tools and driver, you'll have to manually update the placements of all the inertia, visual, and collision models in a separate step.

The thread here seems to discuss the modeling approach that results in the calibrated URDF for the ROS driver.

I think this comment is also useful:

Basically, we get the (calibrated) full DH parameters from the robot as per this definition. From this, we create a structure, where we split each link into two chain segments in order to allow virtually "dragging" in the segments along their calibrated axes. This works with the way UR calibrations are stored, as explained here.

You need to reproduce all of that work if you want to do this yourself.

Since I'm using a URDF in here so having the .yaml can't be used in my case

I believe you MUST use the calibration_devel branch of @fmauch's fork of the universal_robot repository, then you can use the YAML file when you bring the robot up:

https://github.com/fmauch/universal_robot/blob/calibration_devel/ur_description/launch/load_ur5e.launch#L5

The requirement to use the fork is in the instructions for the Universal Robots ROS Driver but I feel like it's easy to miss.

If you can't use the fork and its YAML-compatible ur_description for some reason, maybe you can use a separate ROS installation that DOES use the fork to process the .xacro and YAML into robot_description. Then you can separately save robot_description as a fully-rendered URDF for later use in your actual system.

[urrsk]

@thachdo can we close this issue or do you have additional questions?

[RealMarco]

Thanks @urrsk and @danzimmerman, sorry for my late reply. I want to use the DH parameters to update the URDF file here. Could you suggest a proper way to get and update those values?

Hi @thachdo , I really understand what u wanna do, i.e., get the calibrated 4DoF DH notation for further processing. I'm also having this issue, have u solve that?

[thachdo]

Hi @RealMarco, I would require some works to convert, I didn't have time to do those before. Please share if you could do then.

[urrsk]

Hi @thachdo and @RealMarco and other people that are looking into to the DH parameters
The reason why some of the calibrated parameters is so big is that the 4D DH notation is a complete but singular notation made for placing rotation axis relative to each other, not objects. You need 6 DoF for placing object on an arbitrary position relative to another one.

To support this. The UR ROS and ROS2 driver also include a calibration packet that can calculate the 6DoF version where the output is return as a YAML files. See https://github.com/UniversalRobots/Universal_Robots_ROS_Driver/tree/master/ur_calibration.

BTW. The mention branches are not needed any more (and is outdated). As it all has been merged into the respective repo's default branches.