CR-7iA(L) J3 joint limits incorrect

[buhln]

I had some trouble with the J3 axis of a CR-7iAL in real life. The robot stops the execution in the extreme positions. So I checked the limits in the cr7ial_macro.xacro file and compared it with the maximum value of the robot. I checked the maximum position three times each and get different max/min angles. I used the minimum plus and the maximum minus value in the xacro file and tested again. This time without problems. So I think the limits for J3 are still incorrect.
The same should be relevant for the CR-7iA model: cr7ia_macro.xacro

Better values for J3 would be:
<limit effort="0" lower="-0.7864" upper="3.0949" velocity="7.1558" />

rqt shows also values in this span during error-free operation...
Furthermore, the actual limits are in sum 373 deg. This is much more than technical possible of the joint.

All other limits seems to be correct.

[gavanderhoorn]

I believe what you're describing are the usable limits. Those are not the same as the actual joint limits.

From the system variables of a CR-7iA/L:

    lowerlims:
      - -2.967060e+00
      - -1.151917e+00
      - -2.439795e+00
      - -3.316125e+00
      - -2.094395e+00
      - -6.283185e+00
    upperlims:
      - 2.967060e+00
      - 1.745329e+00
      - 4.258603e+00
      - 3.316125e+00
      - 2.094395e+00
      - 6.283185e+00

note the values for J3: (-2.439795e+00; 4.258603e+00).

[buhln]

I do not understand the difference between usable limits and acutal joint limits. The actual limits for J3 are mechanical impossible for the robot.

All other limits seems to be correct and correspond exactly to the max/min values of our robot. Perhaps there is some misunderstanding due to the J2/J3 coupling? I am aware of this and checked definitiv the J3 limits on the TP (J2/J3 interaction item).

[gavanderhoorn]

The actual limits for J3 are mechanical impossible for the robot.

that could be, but this is what Fanuc specifies.

We opted for consistency when creating that model: we always use the limits specified in the system variables in the xacro:macros.

The situation for J3 is complex in any case, as it's not always just a single set of limits. The values can depend on the pose of J2 (this is different from the coupling you mention).

If you'd like to specify a different set of limits (more restrictive for instance), you could do that by modifying the joint_limits.yaml file in your MoveIt configuration (which I believe you are using, based on your previous questions/posts).

All other limits seems to be correct [..]

technically, all limits are correct, as they correspond to the system variables.

Whether there are/is other systems/logic in place on the controller which further changes those limits is a different discussion.

[buhln]

I can follow your argumentation but I do not understand it 100%. But this is okay.
I will use the joint_limits.yaml for specify my limits because with the actual available driver and the kinematic description in the cr7ial_macro.xacro file the native robot controller stops execution in both extreme positions of J3. I think this is interaction of the MoveIt collision matrix, the limits in the xacro-file and the limits in the native controller.

[gavanderhoorn]

for MoveIt specifically, what could help would be to update the collision mesh to model the space between the two prongs of the link, instead of covering it completely with the convex hull:

MoveIt's ACM is probably set to 'ignore, due to always in collision', which prevents it from actually checking whether a pose would be in collision, and thereby avoiding it 'naturally'.

[buhln]

I think this had to be extreme accurate and so is not practicable for using with a real robot.
My test with the (real) robot shows, that the limits of J3 (and J3 only) fluctuate some decimal places if the joint is multiple times moved to the extreme positions by TP. Like I mention before, this is the reason why I am using the minimum plus and the maximum minus value of the experimental determined limits.
Theses limits are independent from J2 (but I will confirm this again, when I am back in the lab). If the planning algorithm of MoveIt addresses one waypoint just a few tenth part of a degree of J3 to far, the native robot controller stops (because the encoder of the servo say so...) without the possibility to return this information for replanning.
From my point of understanding the most practicable way is to limit the joint by configuration and not by the collision matrix. The collision matrix should be used to limit the mechanical freedom of movement and not the "electronical" one.