add option to not start DIO modules when not attached

[JHeuverRiwo]

Description When no DIO is attached, the CAN hardware interface still tries to read the DIO modules. This results in the folowing error: [ros2_control_node-2] [INFO] [1683292505.677745882] [iRC_ROS]: Module 0x70: Errors TEMP ESTOP MNE COM LAG LAG DRV OC detected, resetting

In itself there is no problem with functionality, but the message above is spammed to the terminal. Modifying the relevant .ros2_control.xacro to not describe the DIO base and arm modules is my current workaround.

Your environment

ROS Distro: Humble
OS Version: Ubuntu 22.04
Branch/Commit hash: humble #b32613bc2141d03a89bf986993003e2ce6243076

To Reproduce

0. Set can settings: sudo ip link set can0 up type can bitrate 500000 restart-ms 1000
1. Start launchfile via 'ros2 launch irc_ros_moveit_config rebel.launch.py gripper:=none use_rviz:=true launch_dio_controller:=false'
2. [ros2_control_node-2] [INFO] [1683292505.707762469] [iRC_ROS]: Module 0x70: Errors TEMP ESTOP MNE COM LAG LAG DRV OC detected, resetting

Expected behavior When not using the DIO controller, I expect nothing to be read from the modules.

Actual behavior The CAN interface is trying to set up connection to nonexisting DIO modules, resulting in error message spam.

[cpr-fer]

I was sure that this already worked, but maybe I broke it again without noticing. While trying to reproduce the error I noticed something else, but related. After I updated my moveit install to this package I can't start some combinations of urdf + controller configurations. It turns out I unknowingly exploited a bug (see here) that made it possible to define and not use command interfaces in the urdf file, which was utilised for the gpios. As such instead of fixing the launch_dio_controller argument I'll have to remove it and always start the controller for 00 and 01 rebels, else the ressource manager complains about unused interfaces in the urdf file. (Wrong, see #94)

Are you using a rebel pre version or how come that you don't have the DIO modules? With rebel_version:=pre the DIO controllers should not launch either way. If 00 or 01 exist without them I suppose I'll have to add a xacro parameter for the gpio interfaces and keep (& fix) the launch_dio_controller parameter

[JHeuverRiwo]

According to the tag on the robot we have a Rebel 6DOF v01. Using the pre tag does fix this issue (but raises other issues for the obvious reasons).

Maybe my issue was a little vague/worded badly, sorry. We do have DIO modules on the robot, but currently there's nothing attached to those, so there's nothing to be read. I don't know whether that should normally be fine, but currently it looks like it's reading an error state and resetting the module continuously, which to me looks like unwanted behaviour.

[cpr-fer]

Hm, normally that error message should only appear once or twice. When initialising the module class all errorstates are set to active until the modules report their actual state over CAN. Until then the error resets happen. If the spamming doesnt stop quickly something else is likely amiss. I'll try to see if I can reproduce your error once I figure out how to resolve the bug I described above.

Edit: I found a quick workaround for my issue and checked the behaviour of the DIO modules. For me there is no constant spamming, instead it looks like this:

[ros2_control_node-2] [INFO] [1683549255.094977405] [iRC_ROS]: Module 0x10: Firmware version is 03.03
[ros2_control_node-2] [INFO] [1683549255.094990104] [iRC_ROS]: Module 0x80: Errors TEMP ESTOP MNE COM LAG LAG DRV OC detected, resetting
[ros2_control_node-2] [INFO] [1683549255.095018860] [iRC_ROS]: Module 0x80: Resetting
[ros2_control_node-2] [INFO] [1683549255.095135862] [iRC_ROS]: Module 0x70: Errors TEMP ESTOP MNE COM LAG LAG DRV OC detected, resetting
[ros2_control_node-2] [INFO] [1683549255.095146870] [iRC_ROS]: Module 0x70: Resetting
[ros2_control_node-2] [INFO] [1683549255.104841159] [iRC_ROS]: Module 0x60: Errorcode: 00001100 
[ros2_control_node-2] [INFO] [1683549255.104912918] [iRC_ROS]: Module 0x50: Errorcode: 00001100 
[ros2_control_node-2] [INFO] [1683549255.104941998] [iRC_ROS]: Module 0x30: Errorcode: 00001100 
[ros2_control_node-2] [INFO] [1683549255.104963568] [iRC_ROS]: Module 0x20: Errorcode: 00001100 
[ros2_control_node-2] [INFO] [1683549255.104984671] [iRC_ROS]: Module 0x40: Errorcode: 00001100 
[ros2_control_node-2] [INFO] [1683549255.105000466] [iRC_ROS]: Module 0x10: Errorcode: 00001100 
[ros2_control_node-2] [INFO] [1683549255.105017993] [iRC_ROS]: Module 0x80: Errors TEMP ESTOP MNE COM LAG LAG DRV OC detected, resetting
[ros2_control_node-2] [INFO] [1683549255.105093430] [iRC_ROS]: Module 0x70: Errors TEMP ESTOP MNE COM LAG LAG DRV OC detected, resetting
[ros2_control_node-2] [INFO] [1683549255.114779573] [iRC_ROS]: Module 0x80: Errorcode: 00000100 
[ros2_control_node-2] [INFO] [1683549255.114812458] [iRC_ROS]: Module 0x70: Errorcode: 00000100 
[ros2_control_node-2] [INFO] [1683549255.114932841] [iRC_ROS]: Module 0x80: Errors MNE detected, resetting
[ros2_control_node-2] [INFO] [1683549255.114943746] [iRC_ROS]: Module 0x80: Enabling motor
[ros2_control_node-2] [INFO] [1683549255.115006308] [iRC_ROS]: Module 0x70: Errors MNE detected, resetting
[ros2_control_node-2] [INFO] [1683549255.115014051] [iRC_ROS]: Module 0x70: Enabling motor
[ros2_control_node-2] [INFO] [1683549255.124846595] [iRC_ROS]: Module 0x80: Errors MNE detected, resetting
[ros2_control_node-2] [INFO] [1683549255.124922955] [iRC_ROS]: Module 0x70: Errors MNE detected, resetting
[ros2_control_node-2] [INFO] [1683549255.134816326] [iRC_ROS]: Module 0x80: Errorcode: 00000000 
[ros2_control_node-2] [INFO] [1683549255.134887674] [iRC_ROS]: Module 0x70: Errorcode: 00000000 

Have you used the DIOs before successfully, e.g. with the igus control software or a previous version of this ros package?

[JHeuverRiwo]

Interesting, so even without anything attached to the DIO, the expected behaviour is that it shows a message saying "Enabling motor" and then one with Errorcode 0x00, for both DIO interfaces? On further inspection it does seem to show this behaviour for the dio_arm..

We have not tried to use DIO before, but will attempt to get it up and running this week. I myself have no access currently to the igus control software, but I could ask my colleague to test when he installs our dummy IO setup this week.

In the meanwhile I will check whether the issue is absent for me on a previous commit.

[JHeuverRiwo]

The issue is present on all the commits I checked, I sampled a few, going as far back as 21st of march, so the code did not break with a recent commit, but it's rather a persistent bug.

Do you have any other ideas on things to test for to see where the issue may lie?

[cpr-fer]

Yes that is the expected behaviour. The message is a bit missleading, but the enable command is called "motor enable" in the protocol description both for motor and for DIO modules. I suppose I should still change the output text to make it less confusing.

If the spamming occurs only with the dio_base but not with the dio_arm and the testing with the igus software also doesn't work out of the box I would suggest to write an email to support@cpr-robots.com as this sounds like a non-ros problem them.

Edit: Regarding your post just now, you have two rebels if I remember correctly, can you test if it works with the other arm?

[cpr-fer]

Oh and regarding the messages for 0x70 and 0x80 in general: These come from the hardware interface themselves, as such they are always present as long as the urdf contains the entries for the gpios. The DIO controller is on a layer above this, as such starting the dio controller or not does not change whether the hardware interface connects to these modules, only if you have access to the state/cmd interfaces via topics and services

[JHeuverRiwo]

I see, that is a valid point regarding the controller.

We do indeed have two rebels, however we currently have only one of them set up for testing, so I cannot test it on the other one right now. It does sound like a good idea to compare them if we cannot resolve it in another way.

I did asked for a copy of the Igus control software for windows just now, and will try to test whether the DIO works in there as soon as possible. If it does not I will forward this issue to the support link you sent, thanks.

edit: I am seeing a Module dead/Module missing error in the Igus control software, so I forwarded the question to support.

[JHeuverRiwo]

I will close this issue for now, considering it may most likely not be a ROS issue.