Calibrated URDFs

[gavanderhoorn]

This is a continuation of ros-industrial/motoman#459 and #206 (specifically: #206 (comment)).

This OP will be be expanded at a later time.

[gavanderhoorn]

@iydv wrote (in #206 (comment)):

According to this comment ros-industrial/motoman#459 (comment) UR actually extracts 6D parameters of each joint instead of D-H parameters. And use it to directly generate URDF model instead of correcting the default one.

Which information is currently possible to extract from the robot using MotoSDK? Is it possible to extract information of calibrated kinematics from Absolute Accuracy? Is it possible to extract D-H parameters? If true, where information can be found about its definition for Yaskawa robots (similar to UR).

As @ted-miller already mentioned, it is possible to retrieve the D-H parameters for a particular group. See the mentioned GP_getDhParameters(..):

motoros2/src/CmosParameterExtraction.h

Lines 196 to 205 in 10d8f00

	/******************************************************************************/
	/* << 24 >> */
	/* Function name : STATUS GP_getDhParameters() */
	/* Functionality : Retrieves DH parameters for a given control group. */
	/* Parameter : int ctrlGrp - Robot control group (zero based index) [IN] */
	/* DH_PARAMETERS* dh - Value of the DH parameters [OUT] */
	/* Return value : Success = OK */
	/* : Failure = NG */
	/******************************************************************************/
	extern STATUS GP_getDhParameters(int ctrlGrp, DH_PARAMETERS* dh);

At some point during MotoROS2 development, I had an initial implementation of a service which made this information available to the ROS side. That never got merged.

Even though @ted-miller wrote (#206 (comment)):

[..] the DH parameters for the robot never get updated after a calibration. Normally, we only modify the encoder's zero-position when calibrating.

it might still be a good idea to implement that service.

[iydv]

Today we have done some investigation regarding D-H parameters from Absolute Accuracy software. Unfortunately, the values obtained after the calibration are stored in different file and cannot be retrieved using this function.
Either this function has to be updated or we need to use different methods to retrieve updated D-H parameters.

I think there is a system parameter which indicates that Absolute Accuracy is installed. Probably the service would have to check it and load the data from new file instead of the default one.

[gavanderhoorn]

@iydv: could you please describe what you have tried and discovered? It would be valuable to have a log of your efforts here.

[gavanderhoorn]

Friendly 'ping' @iydv and @yeu-geissdoerfer?

[yeu-geissdoerfer]

I want to first share some background information on the possibility to "calibrate URDFs".

If a customer wants to use "Absolute Accuracy Compensation", the robot is surveyed in absolute terms. This measurement results are saved in an ABSPACC.DAT and give information about the "real" DH parameters and the robots spring constant.

This "real" DH parameters are used to generate a "calibrated URDF" that represents a more realistic kinematic description of the robot.

Currently we are testing a "calibrated URDF" and share more information later.

[gavanderhoorn]

thanks for the update.

Currently we are testing a "calibrated URDF" and share more information later.

could you already say something about how you created said URDF? Which parts did you modify? Did you use any existing approaches? Have you already thought about how to deal with IK solvers?

Iteratively prototyping things and testing as much as possible while keeping others in-the-loop avoids potentially having to go back and reimplement things later. It'd be great if we could already discuss approaches.

[yeu-geissdoerfer]

Note: This is the procedure used in an alpha test and doesn't state a final procedure!

The current approach for creating a "calibrated URDF" is as follows:

1. Calculate the DH parameter using the ABSPACC.DAT
2. Calculate the differences of alpha and theta values with the following formula URDF alpha = - (alpha from default DH - alpha from corrected DH)
3. Mapping the DH parameters to URDF
   3.1 alpha = yaw
   3.2 a = z
   3.3 d = x
   3.4 theta = roll
4. Change default DH parameter to calibrated DH parameter in robot controller (only possible with Yaskawa Mode)

Now the question comes up. Why calculating only the difference of alpha and theta and not of a and d?
By looking at a default URDF we can see that roll, pitch, yaw are always 0. So when creating a "calibrated URDF" we only need to account for the rotational difference. a and d represent the absolute link length. Using only the difference for a and d would cause the robot to shrink.

It is important to update the DH parameter in the robot controller. Otherwise the robot controller outputs wrong position values. Unfortunally this is only possible with an Yaskawa Mode. There is the possibility that our Hotline Service can create a ALL.PRM file with calibrated DH parameter, that you can then load without Yaskawa Mode.

[ted-miller]

Calculate the DH parameter using the ABSPACC.DAT

Does this also require a Yaskawa technician? Can it be performed by a standard user?

[yeu-geissdoerfer]

For the calculation of the DH parameter, I provide an executable here in this comment. Simply place the ABSPACC.DAT file in the same folder as the executable and you will receive a DHTable.txt as output. Please do not change the name of ABSPACC.DAT, as the robot controller and the executable expect this name convention.

Note: The zip folder contains the executable, as an exe file cannot be added to a GitHub comment.
DetermineDHParameter.zip

[gavanderhoorn]

Thanks for posting that @yeu-geissdoerfer and thanks for developing the tool.

Could you confirm your description of the process as you gave it in #210 (comment) is still accurate?

Specifically your comments about Yaskawa Mode being required?

[yeu-geissdoerfer]

Note: This is the procedure used in an alpha test and doesn't state a final procedure!
The current approach for creating a "calibrated URDF" is as follows:

This procedure is still valid. The executable is performing only step 1 of this procedure.

Regarding Yaskawa Mode required, is still valid for step 4. Here the workaround would be that you can call the service hotline, tell them the DH parameter you want to get changed, they create an validated ALL.PRM file, which can then be uploaded without Yaskawa Mode.