ur_controllers build fails with ROS2 Jazzy

[adkoessler]

Affected ROS2 Driver version(s)

Jazzy

Used ROS distribution.

Other

Which combination of platform is the ROS driver running on.

Ubuntu Linux with standard kernel

How is the UR ROS2 Driver installed.

Build both the ROS driver and UR Client Library from source

Which robot platform is the driver connected to.

UR E-series robot

Robot SW / URSim version(s)

5.12

How is the ROS driver used.

Through the robot teach pendant using External Control URCap

Issue details

Summary

The ur_controllers package does not build from source. I tried to update everything. I can see from the frontpage that the build is failing. I tried checking out to former commits without any success.
How do I revert back to something that works? Any help is appreciated.

Steps to Reproduce

update and upgrade apt
update and install rosdep
git clone https://github.com/UniversalRobots/Universal_Robots_ROS2_Driver.git -b jazzy
colcon build

Actual Behavior

See the log output.

Relevant log output

Starting >>> ur_controllers
--- stderr: ur_controllers                             
In file included from /opt/ros/jazzy/include/controller_interface/controller_interface/controller_interface.hpp:21,
                 from /home/lcfcrobots/ur_workspace/src/Universal_Robots_ROS2_Driver/ur_controllers/src/freedrive_mode_controller.cpp:37:
/opt/ros/jazzy/include/controller_interface/controller_interface/controller_interface_base.hpp:26:10: fatal error: hardware_interface/introspection.hpp: No such file or directory
   26 | #include "hardware_interface/introspection.hpp"
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.

Accept Public visibility

• I agree to make this context public

[Alanzelic]

the same question

Starting >>> ur_dashboard_msgs
Starting >>> ur_moveit_config
Finished <<< ur_moveit_config [0.06s]
Finished <<< ur_dashboard_msgs [0.25s]
Starting >>> ur_controllers
--- stderr: ur_controllers
CMake Error at CMakeLists.txt:99 (add_library):
Target "ur_controllers" links to target
"controller_interface::controller_interface" but the target was not found.
Perhaps a find_package() call is missing for an IMPORTED target, or an
ALIAS target is missing?

CMake Error at /opt/ros/humble/share/ament_cmake_gmock/cmake/ament_add_gmock.cmake:69 (add_executable):
Target "test_load_force_mode_controller" links to target
"controller_interface::controller_interface" but the target was not found.
Perhaps a find_package() call is missing for an IMPORTED target, or an
ALIAS target is missing?
Call Stack (most recent call first):
/opt/ros/humble/share/ament_cmake_gmock/cmake/ament_add_gmock.cmake:52 (_ament_add_gmock)
CMakeLists.txt:180 (ament_add_gmock)

CMake Error at /opt/ros/humble/share/ament_cmake_gmock/cmake/ament_add_gmock.cmake:69 (add_executable):
Target "test_load_force_mode_controller" links to target
"controller_manager::controller_manager" but the target was not found.
Perhaps a find_package() call is missing for an IMPORTED target, or an
ALIAS target is missing?
Call Stack (most recent call first):
/opt/ros/humble/share/ament_cmake_gmock/cmake/ament_add_gmock.cmake:52 (_ament_add_gmock)
CMakeLists.txt:180 (ament_add_gmock)

CMake Error at /opt/ros/humble/share/ament_cmake_gmock/cmake/ament_add_gmock.cmake:69 (add_executable):
Target "test_load_force_mode_controller" links to target
"ros2_control_test_assets::ros2_control_test_assets" but the target was not
found. Perhaps a find_package() call is missing for an IMPORTED target, or
an ALIAS target is missing?
Call Stack (most recent call first):
/opt/ros/humble/share/ament_cmake_gmock/cmake/ament_add_gmock.cmake:52 (_ament_add_gmock)
CMakeLists.txt:180 (ament_add_gmock)

CMake Error at /opt/ros/humble/share/ament_cmake_gmock/cmake/ament_add_gmock.cmake:69 (add_executable):
Target "test_load_freedrive_mode_controller" links to target
"controller_interface::controller_interface" but the target was not found.
Perhaps a find_package() call is missing for an IMPORTED target, or an
ALIAS target is missing?
Call Stack (most recent call first):
/opt/ros/humble/share/ament_cmake_gmock/cmake/ament_add_gmock.cmake:52 (_ament_add_gmock)
CMakeLists.txt:188 (ament_add_gmock)

CMake Error at /opt/ros/humble/share/ament_cmake_gmock/cmake/ament_add_gmock.cmake:69 (add_executable):
Target "test_load_freedrive_mode_controller" links to target
"controller_manager::controller_manager" but the target was not found.
Perhaps a find_package() call is missing for an IMPORTED target, or an
ALIAS target is missing?
Call Stack (most recent call first):
/opt/ros/humble/share/ament_cmake_gmock/cmake/ament_add_gmock.cmake:52 (_ament_add_gmock)
CMakeLists.txt:188 (ament_add_gmock)

CMake Error at /opt/ros/humble/share/ament_cmake_gmock/cmake/ament_add_gmock.cmake:69 (add_executable):
Target "test_load_freedrive_mode_controller" links to target
"ros2_control_test_assets::ros2_control_test_assets" but the target was not
found. Perhaps a find_package() call is missing for an IMPORTED target, or
an ALIAS target is missing?
Call Stack (most recent call first):
/opt/ros/humble/share/ament_cmake_gmock/cmake/ament_add_gmock.cmake:52 (_ament_add_gmock)
CMakeLists.txt:188 (ament_add_gmock)

CMake Generate step failed. Build files cannot be regenerated correctly.

Failed <<< ur_controllers [0.40s, exited with code 1]

Summary: 2 packages finished [0.79s]
1 package failed: ur_controllers
1 package had stderr output: ur_controllers
3 packages not processed

[urfeex]

@adkoessler That seems to be originating from a partially out-of-date system. The missing file in the hardware_interface package was added in February. Is your hardware_interfaces package up-to-date?

@Alanzelic Your issue seems to be completely unrelated. It looks like the controller_interface package isn't installed, at all. Did you run the rosdep install ... command as explained in the docs?

May I suggest to both of you to simply install the binary packages using sudo apt-get install ros-jazzy-ur? This is the recommended method of installing the driver unless you want to actually do development on the driver itself (or one of the other packages in this repo).

[Alanzelic]

thanks ,i choose binary packages , but the controller_interface package is installed , i dont know why it cant find.

[urfeex]

@Alanzelic please open a new issue clearly describing what you did.

[adkoessler]

@urfeex, many thanks for your answer.
About the choice of building from source: I have two UR10e arms working together. From the experience I gathered on ROS1, I need to mingle with launch files so that robots do not target the same TCP ports. This explains why I need to modify the source code, but I'd gladly be proven wrong and use a simpler solution.
I could use the binary to test each robot, but I'm not sure how ROS will handle apt delete ros-jazzy-ur if I switch to source code for dual-arm experiments.

Continuing on the compilation problem, the update of the hardware_interfaces worked! However, I'm not quite there in building ur_controllers because a new compilation error has appeared related to pal_statistics_msgs:

Starting >>> ur_controllers
--- stderr: ur_controllers                             
In file included from /opt/ros/jazzy/include/pal_statistics/pal_statistics.hpp:38,
                 from /opt/ros/jazzy/include/pal_statistics/pal_statistics_macros.hpp:36,
                 from /opt/ros/jazzy/include/hardware_interface/hardware_interface/introspection.hpp:20,
                 from /opt/ros/jazzy/include/hardware_interface/hardware_interface/handle.hpp:31,
                 from /opt/ros/jazzy/include/controller_interface/controller_interface/controller_interface_base.hpp:25,
                 from /opt/ros/jazzy/include/controller_interface/controller_interface/controller_interface.hpp:21,
                 from /home/lcfcrobots/ur_workspace/src/Universal_Robots_ROS2_Driver/ur_controllers/src/freedrive_mode_controller.cpp:37:
/opt/ros/jazzy/include/pal_statistics/pal_statistics_utils.hpp:41:10: fatal error: pal_statistics_msgs/msg/statistics.hpp: No such file or directory
   41 | #include "pal_statistics_msgs/msg/statistics.hpp"
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.

I tried reproducing the approach, but much to my dismay, I have no more packages to upgrade. pal_statistics_msgs seems already up-to-date:

$ apt search jazzy-pal-statistics
Sorting... Done
Full Text Search... Done
ros-jazzy-pal-statistics/noble,now 2.6.2-1noble.20250430.001208 amd64 [installed]
  The pal_statistics package

ros-jazzy-pal-statistics-dbgsym/noble 2.6.2-1noble.20250430.001208 amd64
  debug symbols for ros-jazzy-pal-statistics

ros-jazzy-pal-statistics-msgs/noble,now 2.6.2-1noble.20250424.144219 amd64 [installed]
  Statistics msgs package

ros-jazzy-pal-statistics-msgs-dbgsym/noble 2.6.2-1noble.20250424.144219 amd64
  debug symbols for ros-jazzy-pal-statistics-msgs

$ sudo apt upgrade ros-jazzy-pal-statistics
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
ros-jazzy-pal-statistics is already the newest version (2.6.2-1noble.20250430.001208).

I may be missing the big picture here. I'd be pleased to have your insight.

[urfeex]

This seems a bit odd in total. What I would recommend doing is:

• Update your complete system (sudo apt update && sudo apt dist-upgrade)
• Delete the build and install folders in your colcon workspace
• Open a new shell, source /opt/ros/jazzy/setup.bash
• Build your workspace

Regarding your use case: I would not recommend changing the launchfiles of this package to fit your use case but rather build your own application-specific support package upon this. For exactly that purpose the launchfiles have arguments such as the tcp ports. See UniversalRobots/Universal_Robots_ROS2_Tutorials#3 for a dual-arm setup example. I have yet not come around to review that PR unfortunately, but it should definitively give you an idea.

[adkoessler]

Thanks @urfeex for your answer. I tried the steps you suggested, but I'm not getting there with the source code. There are so many compilation errors. I used the binaries to stop wasting our time. It builds correctly, so that's the problem solved.

I'm still not where I want to be because the robot does not move when I publish commands to the controllers. Are we still supposed to see robot ready to receive control commands when playing the program on the robot side? It's not showing, so I'll explore previous posts on this forum to find a solution.

About the dual-arm setup: I get your ideas, but I don't understand the code in the PR. It's sad that the person who started this couldn't finish their tutorial. Can I stick to the following way?

• create a custom package to launch both robots
• in the main launchfile, call to ur_control.launch.py with different namespaces for robot1 and robot2

[urfeex]

About the dual-arm setup: I get your ideas, but I don't understand the code in the PR. It's sad that the person who started this couldn't finish their tutorial. Can I stick to the following way?

• create a custom package to launch both robots
• in the main launchfile, call to ur_control.launch.py with different namespaces for robot1 and robot2

You'll also have to adapt the port configuration at least for one robot to avoid conflicts.

Are we still supposed to see robot ready to receive control commands when playing the program on the robot side?

Yes, as soon as you start the program on the robot, the driver should output this. If it doesn't the connection isn't established correctly. If the teach pendant doesn't popup an error, I suspect a firewall being in the way. With some configurations it can happen that the request to connect to the script sender isn't rejected by the firewall but never returns.

[adkoessler]

Hi @urfeex and sorry for the delayed answer. I still have some questions which are less related to the original problem, let me know if it's a bother.

1. Regarding the problem where the print ready to receive control commands never occurs: the problem is linked with the particular "left" UR10e I'm using. My other "right" UR10e displays the message consistently. I tried the following thanks to your insight:

• allowed the ports 50001 to 50004 using ufw
• made sure the ports are correctly set in the launch and the URCap
• checked that sensor data is retrieved correctly, which is okay

I'm leaning towards the idea that it's a robot-side problem. Do you think I should investigate the safety configuration of the robot that may disable some features? I changed the safety configuration before this problem occurred and I may have made a mistake.

2. I just achieved creating namespaced launch files that fit my needs. I tested them on the mock hardware to check if I'm not mixing up the names and so on. I tried moving both robots separately robot using the forward_velocity_controller and publishing topics such as

ros2 topic pub -1 /left/forward_velocity_controller/commands std_msgs/msg/Float64MultiArray "data: [0.0, 0.0, 0.0, 0.0, 0.0, 0.0]"

or any nonzero value for the purpose of testing. The commands fail to move/stop the robot randomly. Sometimes I need to send the message 4 or 5 times for the robot to stop.
More concerning even, I reproduced this behavior on a single real UR10e with the standard ur_robot_driver. However, this never seems to happen when the commands are published by a node. Are the CLI tools known for these problems, or should I worry?

3. Edited: I'm also failing to find any informations on how to exploit the kinematic calibration file on the Jazzy branch. It seems to work differently from what was used up to Humble, but the jazzy branch has few documentation compared to the humble one.

[urfeex]

If you use more than one robot, you'll have to use other ports for the second robot. I usually use 50001-50004 for one and 60001-60004 for the other. Obviously, ports for the second robot also need to be allowed in the firewall.

When using mock hardware that is irrelevant, as you experienced.

Regarding calibration extraction on jazzy: The documentation has moved to https://docs.universal-robots.com/Universal_Robots_ROS_Documentation/doc/ur_robot_driver/ur_calibration/doc/usage.html (Though it is still built from the repo). Strictly spoken that is the documentation for Rolling, but most of that should be valid for Jazzy, as well.