Kinematic calibration

[jmirabel]

Dear PAL developers,

we are currently calibrating the 6D position of each joint wrt its parent. At the moment, talos_description_calibration only allows to calibrate an offset for the joint axis.

In order to deploy the result of our calibration, I need to be able to update the URDF. Is is possible to extend this to the full 6D pose of each the joints ? If it is, do you have the resources to do this or do you prefer that I propose my own implementation of this ?

[v-lopez]

Hi @jmirabel,

We were beginning to work on calibrating the 3d position in addition to the joint offset of the arms, but have no ETA yet.

If you submit a proposal, we'll be happy to review it and get it into shape quickly as to not delay your work.

May I ask how are you performing the calibration? Do you have any results yet?

Best regards

[jmirabel]

If you submit a proposal, we'll be happy to review it and get it into shape quickly as to not delay your work.

Before I do anything, I would like to agree with you on the method.

One possibility I have in mind is as follows. At the moment, the URDF chain is something like link -> joint -> link .... We could do something like link -> calibration_frame -> empty_link -> joint_calibration -> link ... where calibration_frame is a fixed joint containing the pose currently in joint and joint_calibration is the revolute joint whose 6D position is close to 0. The pose of the joint_calibration can be parameterized like the current joint offsets.

The discussion might become cumbersome to write. I am open to an oral discussion through any channel.

May I ask how are you performing the calibration? Do you have any results yet?

For the 6D joint pose, we use a motion capture system. We haven't been able to validate the calibration result on the robot yet but it should come soon.

[jmirabel]

Here is a draft of what I meant: jmirabel@569acff

[v-lopez]

Ok, please let me get back to you on Monday.

[v-lopez]

If possible we'd like to avoid extra links on the URDF, it could cause unknown effects on lots of parts of the code.

We were thinking something similar to what we have with the joint offsets.

We'd add 6 variables for x,y,z and r,p,y per joint in the existing calibration urdf file. They would replace the current joint offset variable.

In order to apply this variables, we'd add them here: https://github.com/pal-robotics/talos_robot/blob/kinetic-devel/talos_description/urdf/arm/arm.urdf.xacro#L59

So it would become:

      <origin xyz="${0.00000 + x_offset} ${0.15750*reflect  + y_offset} ${0.23200 + z_offset}"
              rpy="${0.0 * deg_to_rad + roll_offset} ${0.0 * deg_to_rad + pitch_offset} ${0.0 * deg_to_rad}"/>
      <axis xyz="0 0 1" />

Notice that I didn't add + yaw_offset. It is because this offset that coincides with the rotation angle of this joint, and it must be added to the transmission like we do already.

So for each joint, you'd apply 5 offsets here, and the one rotation offset that is aligned with the joint rotation axis must be added to the transmissions here

So this bit would become:

  <xacro:talos_arm_simple_transmission name="${name}" side="right" number="1" reduction="1.0" offset_value="${arm_right_1_yaw_offset}" />
  <xacro:talos_arm_simple_transmission name="${name}" side="right" number="2" reduction="1.0" offset_value="${arm_right_2_roll_offset}" />
  <xacro:talos_arm_simple_transmission name="${name}" side="right" number="3" reduction="1.0" offset_value="${arm_right_3_yaw_offset}" />
  <xacro:talos_arm_simple_transmission name="${name}" side="right" number="4" reduction="1.0" offset_value="${arm_right_4_pitch_offset}" />

Does it make sense? We would develop this in the next weeks.

[jmirabel]

This would work. Thank you for your time.

[jmirabel]

Notice that I didn't add + yaw_offset. It is because this offset that coincides with the rotation angle of this joint, and it must be added to the transmission like we do already.

So for each joint, you'd apply 5 offsets here, and the one rotation offset that is aligned with the joint rotation axis must be added to the transmissions here

After double-thinking about it, this has one slight drawback.

The offset do not have the same meaning depending on the rotation axis. In the calibration file, one will see roll_offset, pitch_offset and yaw_offset. However, the order of application of the offset will not be applied in the same order.

The rotation matrix of a joint will be

• for a joint rotating around X: Rx(q+roll_offset) * Rz (yaw + yaw_offset) * Ry (pitch + pitch_offset) * Rx (roll),
• for a joint rotating around Y: Ry(q+pitch_offset) * Rz (yaw + yaw_offset) * Ry (pitch) * Rx (roll + roll_offset),
  where q is the joint parameter.

This makes the API slightly awkward. Computing the offsets is still possible but requires to play around with Euler angles conventions. This will for sure give a headache to the developer.

Is there a specific reason to keep the calibration of the transmission ?

[v-lopez]

I hadn't thought of that.

The reason for keeping it in the transmission, is that while we don't expect big changes in the roll, pitch and yaw in the physical location of the joint due to assembly, it is expected that the joints might have some offset at the actuator level, some encoder mounting difference or any similar thing. That's why that joint offset was there in the first place.

It's important to differentiate between that external and internal offset. For an external offset we just adjust the x,y,z or r,p,y transform and that's good.

But if the arm is supposed to be moving from 0º to 90º, and it is instead moving from 5º to 95º due to some internal actuator tolerances, we need to correct this 5º offset at the joint level. Otherwise the arm might hit the mechanical limits or cause self collisions.

If we have two separate processes to determine the internal joint offset, and the external mounting offset, then it may make sense to apply all x,y,z and r,p,y at the joint origin transform, and the internal offset at the transmission level.

Please let me know what you think, while we move this internally a bit more.

[jmirabel]

But if the arm is supposed to be moving from 0º to 90º, and it is instead moving from 5º to 95º due to some internal actuator tolerances, we need to correct this 5º offset at the joint level. Otherwise the arm might hit the mechanical limits or cause self collisions.

Adjusting the xyz and rpy of the joint should be sufficient to handle this issue, shouldn't it ?

What about providing 7 parameters (xyz_offset, rpy_offset and transmission_offset) and let the one who calibrates choose the method that suits its need ?

For a new robot, you need to calibrate xyz_offset and rpy_offset using a precise (but time consuming) method (like MoCap). At this step, you leave the transmission offset to zero.
Later on, after some usage of the robot, a transmission offset may appear and one could use another simpler method to estimate those offsets (like finding when the bounds are hit on each side of each joint)

[v-lopez]

Adjusting the xyz and rpy of the joint should be sufficient to handle this issue, shouldn't it ?

No, because the motor is still moving outside it's operating range, at maybe when going over 90º it might be hitting a mechanical limit and not reaching the desired position and therefore overheating.

What about providing 7 parameters (xyz_offset, rpy_offset and transmission_offset) and let the one who calibrates choose the method that suits its need ?

You need both, because they correct different problems. The transmission_offset corrects the motor range of motion. The other compensates for deviations from the manufacturing process.

For a new robot, you need to calibrate xyz_offset and rpy_offset using a precise (but time consuming) method (like MoCap). At this step, you leave the transmission offset to zero.
Later on, after some usage of the robot, a transmission offset may appear and one could use another simpler method to estimate those offsets (like finding when the bounds are hit on each side of each joint)

Agree 100%

[v-lopez]

Alright, we had one more discussion about this.

The joint offset we can apply at a lower level, at the motor configuration files of each joint.
Therefore on the talos_description_calibration only the XYZ and RPY remains.

These motor calibration files are also accessible to you in case you needed to modify, but ideally after we've calibrated them they should not need to be touched anymore.

[jmirabel]

I needed to move forward. You may take inspiration from 362fcb8.

I did not remove the transmission offsets (I'll keep them to zero) and I did not add offsets to the legs, which we won't calibrate (at least in a first phase).

[v-lopez]

Looks good, sorry we couldn't get on this before next week. It's most going to look very similar to this.
Very nice idea to use one file per arm to avoid having to deal with side as part of the variable name.

[v-lopez]

We merged your changes with slight modifications: d788118