No errors thrown when joints are blocked in their movement

[ngeerlingsriwo]

Description Currently we are testing with various cable guiding systems along the joint of the robot. Sometimes when a joint turns, it is blocked by the wiring. You can hear the robot moving through the brakes, causing a discrepancy between the actual joint state, and the joint state ROS 2 thinks the robot is in. ROS 2 does not seem to get any notification, so the robot may keep executing movement cycles, with collision zones that are incorrect due to the incorrect joint states. Once I've rebooted the robot, the correct joint angles are shown again.

Your environment

ROS Distro: Humble
OS Version: Ubuntu 22.04
Branch/Commit hash: humble #aea4f61
Protocol: CPRCANv2
Module Firmware version(s) (CPRCAN only, seen in ROS): 03.03

To Reproduce Let the robot try to make any move, while being restricted.

Expected behavior An error message on the ROS 2 side + blocking of new movement requests. Or if possible, show the correct joint angles (I don't know if they can be detected without a robot reboot)

Actual behavior ROS 2 continues as if nothing happened

[cpr-fer]

Hi @ngeerlingsriwo

Can you upload your terminal output when that happens? If the ROS driver does not recognize any errors it sounds more like a hardware issue to me, e.g. a defective break. In that case I would advise you to test your robot with the igus robot control software for windows

What surprises me is that there is a difference between the real and shown joint values, as there is nothing that should interfere with the data send out by the modules over the CAN bus. If that is an issue with the modules it should be shown in the igus robot control software as well.

In the meantime I will ask a colleague about the likelihood of it being a hardware issue

Edit: Does this happen on multiple joints or is it always the same one?

[cpr-fer]

Hi @ngeerlingsriwo ,

did you already do some testing about this? I asked internally and the opinion is, that is is likely a hardware issue. Moving through activated brakes sounds like something that should not be possible to occur with a healthy axis. If this occurs for different axes and only when the movement is blocked by the external wiring, it still sounds like a hardware issue, as each axis can independently sense the over-current that would occur in that scenario.

The faulty hardware theory would be confirmed if that also happens when using the igus robot control software for windows.

It would be easiest to debug if you can take a video of it and send it to the support email address (support@cpr-robots.com), as they are more knowledgeable about the hardware than I am :)

[cpr-jar]

@ngeerlingsriwo can you tell us in what axis the error occures. The only possible for this would be axis 5 and 6. In some robots the might be slipping on high loads. In this case the motorposition on the can bus is not matching the position of the axis due to slip. I will report the issue to find a solution in firmware for this.