DH Parameters do not Correlate with Pulse Direction

[Mitch-Woodside]

I'm working with a Motoman MH180 and when I retrieve the DH parameters using the parameter extraction library, the axis directions do not correlate with the pulse directions of the robot (see figures below, use axis 2 as an example). I'm not sure if this is purely my misunderstanding of the robot's structure or if the kinematic model in the robot controller is implemented differently for another purpose.

If there is a difference in axis direction between the robot controller and the joint commands then I could see this being problematic when using the extracted DH parameters for trajectory creation or robot control.

Figure 1. Axis Directions from MH180 Manual (167428-1)

Figure 2. DH Table created from MH180 Specification Sheet

Figure 3. DH Table from Parameter Extraction Library

[EricMarcil]

I'm not sure where you got the figure 2 DH table from. I've never seen that on specification sheets in North America. We normally don't put negative signs to the arm link length. There's often more than one way to represent a manipulator using DH parameters.
If ultimately you are trying to make a URDF for the MH180, I suggest that you use the motoman_gp188_support as a base and then simply adjust the arm length, rename the GP188 reference to MH180 and replace the meshes.
For direction of movement, we've standardize the model so that a positive angle sent by ROS, will move the robot in the same direction as what is shown in the figure 1 above.

[gavanderhoorn]

Context for this question: kinetic-devel...Mitch-Woodside:path-correction.

[Mitch-Woodside]

I'm not sure where you got the figure 2 DH table from. I've never seen that on specification sheets in North America. We normally don't put negative signs to the arm link length. There's often more than one way to represent a manipulator using DH parameters.
If ultimately you are trying to make a URDF for the MH180, I suggest that you use the motoman_gp188_support as a base and then simply adjust the arm length, rename the GP188 reference to MH180 and replace the meshes.
For direction of movement, we've standardize the model so that a positive angle sent by ROS, will move the robot in the same direction as what is shown in the figure 1 above.

Figure 2 is one that I have created (in house) using the dimensions and axis directions from the MH180 specification sheet.

I was referring to #238 for URDF creation, but I guess if this DH representation is just used to validate the link lengths then it wouldn't be as big of an issue.

Personally, I was trying to create a jacobian matrix on the controller side which was why the axis direction of the DH parameters does matter to me. I can make it specific for my case, but I couldn't make it generalized based on the returned DH values.

[EricMarcil]

It is difficult to generalize it for all robot models because it varies based on the way the motor and the gear is mechanically mounted. In some cases, the rotation direction of the motor is inverted and that's not necessarily captured in the DH table/gear ratio reported.
I do have a document that I've put together to explain the math and modeling used by our controller. I don't think there is a way to post it here, but if you e-mail me I can send it to you.
[email protected]

[gavanderhoorn]

@EricMarcil: you should be able to attach .pdf or if that fails make a .zip and attach that.

[EricMarcil]

You right. I was looking for an attachment button on the toolbar (clip icon) but I simply need to drop it in. Here's the document:
Motoman Modeling Math Definition v1.1.6 short.pdf

[gavanderhoorn]

Seeing as it would appear this is not actually an issue with how the GetDH functionality is implemented (but a mismatch between the assumption how it should work with how it actually works (and the fact that motor / joint / gearbox rotation direction is not captured in a DH table)), I'm going to close this.

@Mitch-Woodside: please feel free to keep commenting on the issue of course.

If it turns out we do need to fix something, we can re-open.

[Mitch-Woodside]

@EricMarcil Thank you for the information and the documentation! I was going to have to reverse engineer the orientation methodology used, so you have definitely saved me some time.

After reviewing the documentation I do have a couple of questions:

• What is the purpose of providing the DH interface for the ROS user? Since the DH parameters from the controller represent a different mathematical model than what is used to command the robot from ROS (or the teach pendant) I feel like this just makes things a little more confusing than helpful.

• Is there some sort of bit mask that is available that tells the difference in command direction vs model direction? If this is available, then the DH parameters from the controller (Figure 3) could still be used to represent how the robot is commanded.

[EricMarcil]

The document that I posted is not specific to ROS users and DH parameters is usually the reference for most robot representation.
I agree that for ROS it is not the best representation, but we have those values easily accessible so we figured it was better than nothing. The main objective was to identify if a specific robot was modified by calibration in which case something you have modifications on the link length. For example a nominal 300 mm link might show up as 299.023 mm.
The majority of our robots 6-axis robots follow the same model. So if you do a mapping between the DH and the URDF model, it should match for most cases. We considered doing it but we haven't had the time and there hasn't been demand for it so far.