Universal_Robots_ROS2_Driver: Missing state interfaces / command interfaces

I have a setup with MoveIt and a robot_description an UR10e, which is set with UR Simulator in a docker image. This setup was working correctly until I updated to the latest binaries (Humble distro, version 2.2.6-1 from May 11th).

From that moment I am getting these errors, and the controller manager node dies:

[ur_ros2_control_node-4] [INFO] [resource_manager]: Successful initialization of hardware 'bmt_1' (initialize_hardware() at ./src/resource_manager.cpp:118)
[ur_ros2_control_node-4] terminate called after throwing an instance of 'std::runtime_error'
[ur_ros2_control_node-4]   what():  Wrong state or command interface configuration.
[ur_ros2_control_node-4] missing state interfaces:
[ur_ros2_control_node-4] ' ur_speed_scaling/speed_scaling_factor '	' ur_gpio/digital_output_0 '	' ur_gpio/digital_output_1 '	' ur_gpio/digital_output_2 '	' ur_gpio/digital_output_3 '	' ur_gpio/digital_output_4 '	' ur_gpio/digital_output_5 '	' ur_gpio/digital_output_6 '	' ur_gpio/digital_output_7 '	' ur_gpio/digital_output_8 '	' ur_gpio/digital_output_9 '	' ur_gpio/digital_output_10 '	' ur_gpio/digital_output_11 '	' ur_gpio/digital_output_12 '	' ur_gpio/digital_output_13 '	' ur_gpio/digital_output_14 '	' ur_gpio/digital_output_15 '	' ur_gpio/digital_output_16 '	' ur_gpio/digital_output_17 '	' ur_gpio/digital_input_0 '	' ur_gpio/digital_input_1 '	' ur_gpio/digital_input_2 '	' ur_gpio/digital_input_3 '	' ur_gpio/digital_input_4 '	' ur_gpio/digital_input_5 '	' ur_gpio/digital_input_6 '	' ur_gpio/digital_input_7 '	' ur_gpio/digital_input_8 '	' ur_gpio/digital_input_9 '	' ur_gpio/digital_input_10 '	' ur_gpio/digital_input_11 '	' ur_gpio/digital_input_12 '	' ur_gpio/digital_input_13 '	' ur_gpio/digital_input_14 '	' ur_gpio/digital_input_15 '	' ur_gpio/digital_input_16 '	' ur_gpio/digital_input_17 '	' ur_gpio/standard_analog_output_0 '	' ur_gpio/standard_analog_output_1 '	' ur_gpio/standard_analog_input_0 '	' ur_gpio/standard_analog_input_1 '	' ur_gpio/analog_io_type_0 '	' ur_gpio/analog_io_type_1 '	' ur_gpio/analog_io_type_2 '	' ur_gpio/analog_io_type_3 '	' ur_gpio/tool_mode '	' ur_gpio/tool_output_voltage '	' ur_gpio/tool_output_current '	' ur_gpio/tool_temperature '	' ur_gpio/tool_analog_input_0 '	' ur_gpio/tool_analog_input_1 '	' ur_gpio/tool_analog_input_type_0 '	' ur_gpio/tool_analog_input_type_1 '	' ur_gpio/robot_mode '	' ur_gpio/robot_status_bit_0 '	' ur_gpio/robot_status_bit_1 '	' ur_gpio/robot_status_bit_2 '	' ur_gpio/robot_status_bit_3 '	' ur_gpio/safety_mode '	' ur_gpio/safety_status_bit_0 '	' ur_gpio/safety_status_bit_1 '	' ur_gpio/safety_status_bit_2 '	' ur_gpio/safety_status_bit_3 '	' ur_gpio/safety_status_bit_4 '	' ur_gpio/safety_status_bit_5 '	' ur_gpio/safety_status_bit_6 '	' ur_gpio/safety_status_bit_7 '	' ur_gpio/safety_status_bit_8 '	' ur_gpio/safety_status_bit_9 '	' ur_gpio/safety_status_bit_10 '	' ur_gpio/program_running '	' ur_system_interface/initialized '	
[ur_ros2_control_node-4] missing command interfaces:
[ur_ros2_control_node-4] ' ur_speed_scaling/target_speed_fraction_cmd '	' ur_speed_scaling/target_speed_fraction_async_success '	' ur_gpio/standard_digital_output_cmd_0 '	' ur_gpio/standard_digital_output_cmd_1 '	' ur_gpio/standard_digital_output_cmd_2 '	' ur_gpio/standard_digital_output_cmd_3 '	' ur_gpio/standard_digital_output_cmd_4 '	' ur_gpio/standard_digital_output_cmd_5 '	' ur_gpio/standard_digital_output_cmd_6 '	' ur_gpio/standard_digital_output_cmd_7 '	' ur_gpio/standard_digital_output_cmd_8 '	' ur_gpio/standard_digital_output_cmd_9 '	' ur_gpio/standard_digital_output_cmd_10 '	' ur_gpio/standard_digital_output_cmd_11 '	' ur_gpio/standard_digital_output_cmd_12 '	' ur_gpio/standard_digital_output_cmd_13 '	' ur_gpio/standard_digital_output_cmd_14 '	' ur_gpio/standard_digital_output_cmd_15 '	' ur_gpio/standard_digital_output_cmd_16 '	' ur_gpio/standard_digital_output_cmd_17 '	' ur_gpio/standard_analog_output_cmd_0 '	' ur_gpio/standard_analog_output_cmd_1 '	' ur_gpio/tool_voltage_cmd '	' ur_gpio/io_async_success '	' ur_payload/mass '	' ur_payload/cog.x '	' ur_payload/cog.y '	' ur_payload/cog.z '	' ur_payload/payload_async_success '	' ur_resend_robot_program/resend_robot_program_cmd '	' ur_resend_robot_program/resend_robot_program_async_success '	' ur_zero_ftsensor/zero_ftsensor_cmd '	' ur_zero_ftsensor/zero_ftsensor_async_success '	

This is quite strange, as I only have enabled joint_state_broadcaster and joint_trajectory_controller in the ur_ros2_control_configuration.yaml file. Moreover, launcher file has all the unneeded controllers disabled:

    nodes_to_start = [
        # control_node,
        ur_control_node,
        dashboard_client_node,
        # tool_communication_node,
        # controller_stopper_node,
        joint_state_broadcaster_spawner,
        joint_trajectory_controller_spawner,
        # io_and_status_controller_spawner,
        # speed_scaling_state_broadcaster_spawner,
        # force_torque_sensor_broadcaster_spawner,
        # forward_position_controller_spawner_stopped,
        # initial_joint_controller_spawner_stopped,
        # initial_joint_controller_spawner_started,
    ]

I’ve been looking for that error message through the source code (both in ur_robot_driver and ros2_control) with the hope that I could understand the origin of the issue.

Can anyone point me where to look to better understand this problem?

About this issue

  • Original URL
  • State: closed
  • Created a year ago
  • Reactions: 4
  • Comments: 37 (7 by maintainers)

Most upvoted comments

Regarding the source build:

I’ll propagate the necessary changes to the humble branch over the weekend. However, the humble branch will fail as long as https://github.com/ros-controls/ros2_control/pull/1030 isn’t merged. I expect that to happen soon, though.

Regarding the binary build:

Things got broken in the binary build which should not happen. We are very sorry for that. Our tests should have spotted that, but they didn’t, we’ll have to improve on that.

Things should be back to working normally right now. I’ll do some manual tests using humble and rolling and then trigger binary releases.

I just verified this using a binary install (from the testing repo):

[ur_ros2_control_node-1] terminate called after throwing an instance of 'std::runtime_error'
[ur_ros2_control_node-1]   what():  Wrong state or command interface configuration.
[ur_ros2_control_node-1] missing state interfaces:
[ur_ros2_control_node-1]
[ur_ros2_control_node-1] missing command interfaces:
[ur_ros2_control_node-1] ' gpio/tool_voltage_cmd '      ' zero_ftsensor/zero_ftsensor_cmd '     ' zero_ftsensor/zero_ftsensor_async_success '

First of, thank you all for the work you put into this! 💯
In an urDriver-only workspace I can confirm, that the source build as described in the readme works flawlessy. ✔️

However, we use the UR5 Driver in a bigger workspace where our URDF assembles the robot components, where the UR5 is just one of them. Here, the source build only works with all the upstream repos built from source as well (repos file Universal_Robots_ROS2_Driver.humble.repos), as described by @WaReStu .

After trying both I can confirm that building from source works, but only if one uses the repo for the semi-binary builds, i.e:

vcs import src --skip-existing --input src/Universal_Robots_ROS2_Driver/Universal_Robots_ROS2_Driver.humble.repos

Additionally, we usually give the UR a tf_prefix string ur5/, so that all links, joints etc. are prefixed by that. I had to remove any namespacing in our URDF (removing all the ur5/ prefixes) to get the full-source build to work with our current workspace.

I can confirm the behaviour @WaReStu observed with the humble semi-binary build following the readme, which uses the binary packages for the controllers (repos file Universal_Robots_ROS2_Driver-not-released.humble.repos does not contain additional sources apart from the UR-description). If I use those steps from the readme to install all dependencies in the semi-binary build in our custom workspace, i get the error described:

If you run:

ros2 launch ur_robot_driver ur_control.launch.py ur_type:=<ur_type> robot_ip:=192.168.56.101 launch_rviz:=true –>see error in @WaReStu post

I hope this helps a bit in tracking down the bug, if you need me to run a test, please let me know 😃

Ok I found the issue. In #688 @fmauch forgot to remove the workaround for the command interfaces. I fixed it in #692

… Builds from source should work, however.

After trying both I can confirm that building from source works, but only if one uses the repo for the semi-binary builds, i.e:

vcs import src --skip-existing --input src/Universal_Robots_ROS2_Driver/Universal_Robots_ROS2_Driver.humble.repos

This kind of makes sense to me, as this seems to build some packages outside of the ur-driver itself and overwrites those? So do I understand this correctly that there was some sort of change in the humble branch of ROS that lead to the driver not working? Because if I try to build from source as described in the readme.md of this humble branch (this ur-driver) it would do a binary build which has the following errors still: (I’m going to write this out so if someone searches for this error they might be lead here:)

If you run:

ros2 launch ur_robot_driver ur_control.launch.py ur_type:=<ur_type> robot_ip:=192.168.56.101 launch_rviz:=true

And get the following errors:

[INFO] [ur_ros2_control_node-1]: process started with pid [15414] [ERROR] [ur_ros2_control_node-1]: process has died [pid 15414, exit code -6, cmd ‘/home/tallarean/ws_ur/ros_ur_driver/install/ur_robot_driver/lib/ur_robot_driver/ur_ros2_control_node --ros-args --params-file /tmp/launch_params_1snf_0q_ --params-file /home/tallarean/ws_ur/ros_ur_driver/install/ur_robot_driver/share/ur_robot_driver/config/ur3e_update_rate.yaml --params-file /home/tallarean/ws_ur/ros_ur_driver/install/ur_robot_driver/share/ur_robot_driver/config/ur_controllers.yaml’]. [INFO] [robot_state_publisher-4]: process started with pid [15420]

followed later by:

[ur_ros2_control_node-1] terminate called after throwing an instance of ‘std::runtime_error’ [ur_ros2_control_node-1] what(): text not specified in the tf_prefix tag

Read above and issue carefully.

Anyway, we now have a somewhat working system to write code for so I am happy. I’ll try the set up process using binary packages once the sync has propagated. @fmauch and everyone else: thanks for the help!

With Humble being synchronized and the packages available in mainline with the versions noted above I’ll go ahead and close this as completed. A full binary installation should work again now.

Just to add: The humble branch is fine now given a recent enough ros2_control. To achieve this either build ros2_control from sources, use the testing repo or wait until after the next sync, which should be happening tomorrow.

First of all please note that I am not the maintainer, just the guy who wrote #594 and the other multiarm support patches. Perhaps @fmauch (who is the maintainer) has some more input about this issue.

@WaReStu I think you are right about this being an issue with the current binary build. I just tested it on my own setup where I run humble with two UR16e and built the UR driver from scratch. There everything worked fine.

The issue with building on humble is also known #674 @leander2189 . A solution is to comment out the scaled JTC in the CMakeLists.txt or fix the call to publish_state to use the old signature as present in the JTC in humble