Robot joint 5 calibration is multiple degrees off

[JHeuverRiwo]

Description Robot joint 5 is at -6.8 degrees on the physical robot, when it should be on 0.

Your environment

ROS Distro: Humble
OS Version: Ubuntu 22.04
Branch/Commit hash: humble #3c9b2ab5c8134974398607492abe749b2ce14df3
Protocol: CPRCANv2
Firmware version: 1.14

To Reproduce

1. Start launchfile via 'ros2 launch irc_ros_moveit_config rebel.launch.py rebel_version:=01 gripper:=none use_rviz:=true launch_dio_controller:=false'
2. set robot to zero state

Expected behavior All joints are at 0 degrees, both in the real world, as well as in simulation.

Actual behavior Joint 5 is at -6.8 degrees in the real world. Joints 2 and 3 may be a little offset as well (less than a degree, but enough to sometimes crash the robot if it is asked to joint limit states for these joints). In RViz I can see the joint angles should be at 0.

I think this could be an issue with referencing on the ROS side, since referencing the joints in the Igus control software seems to correctly reflect the physical state of the robot. These joints seems consistently miscalibrated for me, on multiple commits and after restarting the robot and the ROS driver.

[cpr-fer]

You are correct, the irc software configuration specifies a 7.5° offset for joint 5. I remember my robot being a bit off but I thought it was just a calibration issue and changed the firmware settings instead :| I'll create a PR this afternoon to fix the robot description

less than a degree, but enough to sometimes crash the robot if it is asked to joint limit states for these joints This sounds weird, is that issue reproducible? I don't recall having such issues with my setup

[JHeuverRiwo]

Ah I see, that would explain the observed offset in joint 5 then.

For me it is semi-reproducible. I move joint 3 to +119 degrees and observe that the links attached to it are already touching each other. When I then for instance try to move it to +120 degrees, the module may crash with the following message:

[ros2_control_node-2] [INFO] [1683631204.824437985] [iRC_ROS]: Module 0x30: Errorcode: 01000100 [ros2_control_node-2] [INFO] [1683631204.824456905] [iRC_ROS]: Module 0x30: Errors MNE DRV detected, motorstate set to disabled [ros2_control_node-2] [INFO] [1683631204.824460928] [iRC_ROS]: Module 0x30: Reset required [ros2_control_node-2] [ERROR] [1683631204.824466559] [iRC_ROS]: 0x30: Error detected with no recovery option, stopping entire hardware interface for safety reasons

I had varying success trying to reproduce this, it did not crash on the first attempt when moving from further away, say 0 degrees to 120, but it crashed just now moving from 119 degrees to 120 degrees in joint 3. However, then trying to reproduce it another time proves hard. I think the main problem is that the physical limit of joints 2 and 3 seem to be at 119 degrees on our robot right now (-119 for joint 3 only, the link will go into colission before getting to +120 degree by design).

[cpr-fer]

Hm, I see. This was something I tested when I set the limits in software, but I suppose the tollerances are to slim to make it work all the time on all the robots. irc limits joint 2 and 3 to 110° for that reason, now I see that it was not an unnecesseraly precautious setting...

I'll change the joint limits in in the same PR then, thanks for all the bug reports!

[cpr-fer]

@JHeuverRiwo Can you test if the offset and crashing are gone with the branch from your robot? It would do it myself but I don't know how without being able to reproduce the issues here

[JHeuverRiwo]

I tested the code and it seems to resolve the issue for me! I do see that the zero position has changed with the fix however; so while the robot and simulated now correspond, joint 5 has a zero position that has been offset compared to the previous version. This in itself is completely workable for us, but I am not sure whether it was intentional.

[cpr-fer]

Perfect, thanks a lot for testing!

The change was intentional, as the zero position is supposed to be the position where all the joint modules report their actual position over CAN as zero. It is not intended as an upright-ish position or anything, that needs to be added at some point in the future as well I guess