picknikrobotics / abb_ros2 Goto Github PK

Hi,
First of all, thank you very much for developing a ROS2 driver for ABB Robots.

I am planning to control an ABB IRB120 robot using ROS2.0 Foxy. I have followed the instructions here, and I receive the following errors (please see the 2 pictures attached) when executing the last COLCON BUILD in my ~/dev_ws workspace (the error is generated when building the abb_hardware_interface package).

Is it because there is not a version for ROS2.0 Foxy released yet, or is it a problem related to my workspace/PC?

Thank you very much in advance!
Regards,
Mikel

Hello @stephanie-eng and @gavanderhoorn,

I've noticed a potentially serious problem with the behavior of this hardware interface which is summarized in the video below. I've detailed the cause and a temporary fix i'm using. But would like to get your thoughts on what a proper fix should look like.

The problem

Say I move the ABB robot to a non-zero joint configuration before starting the EGM client on the robot. In this example, joints 1-3 are set to 30deg or 0.5235rad. You can see the console output in RobotStudio where the robot is waiting to connect to the EGM server.

I then launch the hardware_itnerface and joint_trajectory_controller following the exact command from the README but after replacing the IP address with that of my robot. You can see that as soon as the EGM server starts and registers the client, it moves the robot to all zero joint positions. This is even after I've explicitly set the initial position values to 0.5235rad of the resp state interfaces in the irb1200.ros2_control.xacro file (bottom terminal).

The behavior is dangerous as our robot operates within an enclosure with many obstacles which may collide with it as it moves to 0 joint value configuration on startup. The expected behavior is for the hardware_interface to not move the robot to this configuration at start but instead keep the robot at the initial value specified in the ros2 control xacro.

Root cause of the problem.

The problem lies in the way the initializeMotionData that is called by this hardware interface as seen here is implemented. The implementation hardcodes motion_joint.command.position = 0.0;. Hence, once EGM connects, it commands all the joints to 0.0 rad.

Temporary fix

As a interim solution, i'm using a fork of abb_egm_rws_managers where I hardcode the motion_joint.command.position values in initializeMotion() with initial joint values that my robot starts in. In the video below, you can see that once the EGM server connects with the robot client, it does not command the robot joints to 0rad and i'm able to plan and execute motions from this initial position of the robot.

Proper fix

Here's my proposal for a more general fix. If this sounds ok, I'm happy to open the necessary PRs.

1. Get and store the initial_values for each joint from the hardware_interface::HardwareInfo passed into AbbSystemHardware::on_init()
2. Pass these initial values to initializeMotion() and use the values to set motion_joint.command.position for each joint.
   Let me know your thoughts on this approach. I can try to do this without breaking any API.

On a slightly unrelated note,
I would also like to propose not using RWS to get the RobotControllerDescription as seen here. This works well for RWS1.0 but when interfacing with RWS2.0 on omnicore, it fails. I've resorted to manually creating the RobotControllerDescription object as described in this comment when working with omnicore robots. I think it should be possible construct this description by parsing the HardwareInfo. Or atleast have an option to either use RWS or parse HardwareInfo to get this information. I understand that getting this data from RWS is useful when there are external axes involved.

Greetings,

Congratulations on the latest release! The packages here will greatly benefit a lot of people including myself.

I apologize if this is a misplaced question and should be targeted at abb_libegm instead.

I'm curious about the effort needed to make this driver compatible with newer ABB robots that ship with Omnicore controllers running Robotware >= 7.0. I understand from the description that only IRC controllers with Robotware < 7.0 are presently supported.

It would be great if someone could highlight the exact set of items that need to be accomplished to achieve this goal. (what functionalities to add to which packages for example). I would be happy to contribute development effort on these items assuming I have the capability 😄

The moveit launch file in abb_bringup does not load and pass the joint_limits.yaml file from the moveit config package to the move_group node. Without the use_velocity_limits and use_acceleration_limits params set true, the time optimal trajectory generation will normalize velocity and acceleration of joint trajectory points between [0, 1] resulting in slower motions.

We are interested in integrating an external axis (aka MultiMove). I did some reading at the old ROS1 driver and learned a few things:

• The abb_rws_state_publisher package publishes the JointState and SystemState, including external axis info.
• abb_egm_hardware_interface provides actual control of the axes. It has one EGM channel per "mechanical unit group."

Question: there's a note saying abb_egm_hardware_interface relies on abb_rws_service_provider. Is that a hard requirement or something we could avoid?

Related: ros-industrial/abb_libegm#57

As I'm working through setting up an external axis for use with EGM, I've found that this line of code (and the corresponding line for command interface rather than state) results in the following error:

[ros2_control_node-1] [WARN] [1659383569.189672603] [resource_manager]: (hardware 'ABBMultiInterfaceHardware'): 'joint_1/position' state interface already in available list. This can happen due to multiple calls to 'configure'
[ros2_control_node-1] [WARN] [1659383569.189680699] [resource_manager]: (hardware 'ABBMultiInterfaceHardware'): 'joint_1/velocity' state interface already in available list. This can happen due to multiple calls to 'configure'
[ros2_control_node-1] [WARN] [1659383569.189698133] [resource_manager]: (hardware 'ABBMultiInterfaceHardware'): 'joint_1/position' command interface already in available list. This can happen due to multiple calls to 'configure'
[ros2_control_node-1] [WARN] [1659383569.189704065] [resource_manager]: (hardware 'ABBMultiInterfaceHardware'): 'joint_1/velocity' command interface already in available list. This can happen due to multiple calls to 'configure'

For reference, I'm testing this against the MultiMove Pack and Go file provided with this repo - so the full joint name for the external axis would be "IRB1200_mu25001_joint_1", but this gets cut down to "joint_1" just as the robot's "IRB1200_rob1_joint_1" does.

Does it make sense to change the name of the joints in the URDF to match that which comes from the ABB robot controller (as mentioned in the TODO)?

ros2 launch abb_bringup abb_control.launch.py description_package:=abb_irb1200_support description_file:=irb1200_5_90.xacro launch_rviz:=false moveit_config_package:=abb_irb1200_5_90_moveit_config use_fake_hardware:=false rws_ip:=<ROBOTSTUDIO_IP>

when this is launched, can you tell where in the code does communication with the controller via EGM is setup?

Hi, I'm trying to simulate the robot without using RobotStudio yet.
I launched this first line in the terminal and it's ok.
ros2 launch abb_bringup abb_control.launch.py description_package:=abb_irb1200_support description_file:=irb1200_5_90.xacro launch_rviz:=false moveit_config_package:=abb_irb1200_5_90_moveit_config use_fake_hardware:=true

But for the second one (ros2 launch abb_bringup abb_moveit.launch.py robot_xacro_file:=irb1200_5_90.xacro support_package:=abb_irb1200_support moveit_config_package:=abb_irb1200_5_90_moveit_config moveit_config_file:=abb_irb1200_5_90.srdf.xacro), the rviz starts running but the robot doesn't appear. I tried adding MotionPlanning, PlanningScene and still not work.

I'm using:

• ROS Humble
• Ubuntu 22.04 Jammy

All this text appears in the terminal:
ros2 launch abb_bringup abb_moveit.launch.py robot_xacro_file:=irb1200_5_90.xacro support_package:=abb_irb1200_support moveit_config_package:=abb_irb1200_5_90_moveit_config moveit_config_file:=abb_irb1200_5_90.srdf.xacro
[INFO] [launch]: All log files can be found below /home/bernardo/.ros/log/2024-03-16-19-17-43-537016-bernardo-VirtualBox-18837
[INFO] [launch]: Default logging verbosity is set to INFO
[INFO] [move_group-1]: process started with pid [18838]
[INFO] [rviz2-2]: process started with pid [18840]
[INFO] [static_transform_publisher-3]: process started with pid [18842]
[INFO] [robot_state_publisher-4]: process started with pid [18852]
[static_transform_publisher-3] [WARN] [1710631064.204394288] []: Old-style arguments are deprecated; see --help for new-style arguments
[rviz2-2] Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use QT_QPA_PLATFORM=wayland to run on Wayland anyway.
[static_transform_publisher-3] [INFO] [1710631064.290091235] [static_transform_publisher]: Spinning until stopped - publishing transform
[static_transform_publisher-3] translation: ('0.000000', '0.000000', '0.000000')
[static_transform_publisher-3] rotation: ('0.000000', '0.000000', '0.000000', '1.000000')
[static_transform_publisher-3] from 'world' to 'base_link'
[robot_state_publisher-4] [WARN] [1710631064.563601044] [kdl_parser]: The root link base_link has an inertia specified in the URDF, but KDL does not support a root link with an inertia. As a workaround, you can add an extra dummy link to your URDF.
[robot_state_publisher-4] [INFO] [1710631064.564886401] [robot_state_publisher]: got segment base
[robot_state_publisher-4] [INFO] [1710631064.569183914] [robot_state_publisher]: got segment base_link
[robot_state_publisher-4] [INFO] [1710631064.570969528] [robot_state_publisher]: got segment flange
[robot_state_publisher-4] [INFO] [1710631064.572624551] [robot_state_publisher]: got segment link_1
[robot_state_publisher-4] [INFO] [1710631064.579210824] [robot_state_publisher]: got segment link_2
[robot_state_publisher-4] [INFO] [1710631064.579244279] [robot_state_publisher]: got segment link_3
[robot_state_publisher-4] [INFO] [1710631064.579250923] [robot_state_publisher]: got segment link_4
[robot_state_publisher-4] [INFO] [1710631064.579256368] [robot_state_publisher]: got segment link_5
[robot_state_publisher-4] [INFO] [1710631064.579261401] [robot_state_publisher]: got segment link_6
[robot_state_publisher-4] [INFO] [1710631064.579266460] [robot_state_publisher]: got segment tool0
[move_group-1] Error: Name of virtual joint is not specified
[move_group-1] at line 77 in ./src/model.cpp
[move_group-1] [INFO] [1710631064.605961283] [move_group.moveit.RDFLoader]: Loaded robot model in 0.0282812 seconds
[move_group-1] [INFO] [1710631064.606042206] [move_group.moveit.robot_model]: Loading robot model 'abb_irb1200_5_90'...
[move_group-1] [INFO] [1710631064.606059369] [move_group.moveit.robot_model]: No root/virtual joint specified in SRDF. Assuming fixed joint
[move_group-1] [WARN] [1710631064.693951527] [kdl_parser]: The root link base_link has an inertia specified in the URDF, but KDL does not support a root link with an inertia. As a workaround, you can add an extra dummy link to your URDF.
[move_group-1] [INFO] [1710631064.694284921] [move_group.moveit.kdl_kinematics_plugin]: Joint weights for group 'manipulator': 1 1 1 1 1 1
[move_group-1] [INFO] [1710631064.862480852] [move_group.moveit.planning_scene_monitor]: Publishing maintained planning scene on 'monitored_planning_scene'
[move_group-1] [INFO] [1710631064.862783478] [move_group.moveit.moveit_cpp]: Listening to 'joint_states' for joint states
[move_group-1] [INFO] [1710631064.874187805] [move_group.moveit.current_state_monitor]: Listening to joint states on topic 'joint_states'
[move_group-1] [INFO] [1710631064.875291677] [move_group.moveit.planning_scene_monitor]: Listening to '/attached_collision_object' for attached collision objects
[move_group-1] [INFO] [1710631064.875313110] [move_group.moveit.planning_scene_monitor]: Stopping existing planning scene publisher.
[move_group-1] [INFO] [1710631064.875452899] [move_group.moveit.planning_scene_monitor]: Stopped publishing maintained planning scene.
[move_group-1] [INFO] [1710631064.879158531] [move_group.moveit.planning_scene_monitor]: Publishing maintained planning scene on 'monitored_planning_scene'
[move_group-1] [INFO] [1710631064.879258642] [move_group.moveit.planning_scene_monitor]: Starting planning scene monitor
[move_group-1] [INFO] [1710631064.882525090] [move_group.moveit.planning_scene_monitor]: Listening to '/planning_scene'
[move_group-1] [INFO] [1710631064.882556259] [move_group.moveit.planning_scene_monitor]: Starting world geometry update monitor for collision objects, attached objects, octomap updates.
[move_group-1] [INFO] [1710631064.891540286] [move_group.moveit.planning_scene_monitor]: Listening to 'collision_object'
[move_group-1] [INFO] [1710631064.902579072] [move_group.moveit.planning_scene_monitor]: Listening to 'planning_scene_world' for planning scene world geometry
[move_group-1] [WARN] [1710631064.910069701] [move_group.moveit.occupancy_map_monitor]: Resolution not specified for Octomap. Assuming resolution = 0.1 instead
[move_group-1] [ERROR] [1710631064.910103961] [move_group.moveit.occupancy_map_monitor]: No 3D sensor plugin(s) defined for octomap updates
[move_group-1] terminate called after throwing an instance of 'rclcpp::ParameterTypeException'
[move_group-1] what(): expected [string_array] got [string]
[move_group-1] Stack trace (most recent call last):
[move_group-1] #17 Object "", at 0xffffffffffffffff, in
[move_group-1] #16 Object "/home/bernardo/ws_moveit/install/moveit_ros_move_group/lib/moveit_ros_move_group/move_group", at 0x55d263baf094, in _start
[move_group-1] #15 Source "../csu/libc-start.c", line 392, in __libc_start_main_impl [0x7f07e1629e3f]
[move_group-1] #14 Source "../sysdeps/nptl/libc_start_call_main.h", line 58, in __libc_start_call_main [0x7f07e1629d8f]
[move_group-1] #13 Object "/home/bernardo/ws_moveit/install/moveit_ros_move_group/lib/moveit_ros_move_group/move_group", at 0x55d263bae21e, in main
[move_group-1] #12 Object "/home/bernardo/ws_moveit/install/moveit_ros_planning/lib/libmoveit_cpp.so.2.9.0", at 0x7f07e22b7240, in moveit_cpp::MoveItCpp::MoveItCpp(std::shared_ptrrclcpp::Node const&, moveit_cpp::MoveItCpp::Options const&)
[move_group-1] #11 Object "/home/bernardo/ws_moveit/install/moveit_ros_planning/lib/libmoveit_cpp.so.2.9.0", at 0x7f07e22b627b, in moveit_cpp::MoveItCpp::loadPlanningPipelines(moveit_cpp::MoveItCpp::PlanningPipelineOptions const&)
[move_group-1] #10 Object "/home/bernardo/ws_moveit/install/moveit_ros_planning/lib/libmoveit_planning_pipeline_interfaces.so.2.9.0", at 0x7f07e18fab06, in moveit::planning_pipeline_interfaces::createPlanningPipelineMap(std::vector<std::__cxx11::basic_string<char, std::char_traits, std::allocator >, std::allocator<std::__cxx11::basic_string<char, std::char_traits, std::allocator > > > const&, std::shared_ptr<moveit::core::RobotModel const> const&, std::shared_ptrrclcpp::Node const&, std::__cxx11::basic_string<char, std::char_traits, std::allocator > const&)
[move_group-1] #9 Object "/home/bernardo/ws_moveit/install/moveit_ros_planning/lib/libmoveit_planning_pipeline.so.2.9.0", at 0x7f07e186cdd6, in planning_pipeline::PlanningPipeline::PlanningPipeline(std::shared_ptr<moveit::core::RobotModel const> const&, std::shared_ptrrclcpp::Node const&, std::__cxx11::basic_string<char, std::char_traits, std::allocator > const&)
[move_group-1] #8 Object "/home/bernardo/ws_moveit/install/moveit_ros_planning/lib/libmoveit_planning_pipeline.so.2.9.0", at 0x7f07e18b0e0b, in planning_pipeline_parameters::ParamListener::declare_params()
[move_group-1] #7 Object "/opt/ros/humble/lib/librclcpp.so", at 0x7f07e1ec4863, in
[move_group-1] #6 Object "/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.30", at 0x7f07e1aae4d7, in __cxa_throw
[move_group-1] #5 Object "/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.30", at 0x7f07e1aae276, in std::terminate()
[move_group-1] #4 Object "/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.30", at 0x7f07e1aae20b, in
[move_group-1] #3 Object "/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.30", at 0x7f07e1aa2b9d, in
[move_group-1] #2 Source "./stdlib/abort.c", line 79, in abort [0x7f07e16287f2]
[move_group-1] #1 Source "../sysdeps/posix/raise.c", line 26, in raise [0x7f07e1642475]
[move_group-1] #0 | Source "./nptl/pthread_kill.c", line 89, in __pthread_kill_internal
[move_group-1] | Source "./nptl/pthread_kill.c", line 78, in __pthread_kill_implementation
[move_group-1] Source "./nptl/pthread_kill.c", line 44, in __pthread_kill [0x7f07e16969fc]
[move_group-1] Aborted (Signal sent by tkill() 18838 1000)
[ERROR] [move_group-1]: process has died [pid 18838, exit code -6, cmd '/home/bernardo/ws_moveit/install/moveit_ros_move_group/lib/moveit_ros_move_group/move_group --ros-args --params-file /tmp/launch_params_11623sfv'].
[rviz2-2] [INFO] [1710631065.589322235] [rviz2]: Stereo is NOT SUPPORTED
[rviz2-2] [INFO] [1710631065.589687373] [rviz2]: OpenGl version: 4.5 (GLSL 4.5)
[rviz2-2] [INFO] [1710631065.808109792] [rviz2]: Stereo is NOT SUPPORTED
[rviz2-2] Warning: class_loader.impl: SEVERE WARNING!!! A namespace collision has occurred with plugin factory for class rviz_default_plugins::displays::InteractiveMarkerDisplay. New factory will OVERWRITE existing one. This situation occurs when libraries containing plugins are directly linked against an executable (the one running right now generating this message). Please separate plugins out into their own library or just don't link against the library and use either class_loader::ClassLoader/MultiLibraryClassLoader to open.
[rviz2-2] at line 253 in /opt/ros/humble/include/class_loader/class_loader/class_loader_core.hpp
[rviz2-2] [WARN] [1710631068.120492240] [rcl.logging_rosout]: Publisher already registered for provided node name. If this is due to multiple nodes with the same name then all logs for that logger name will go out over the existing publisher. As soon as any node with that name is destructed it will unregister the publisher, preventing any further logs for that name from being published on the rosout topic.
[rviz2-2] [ERROR] [1710631071.340279875] [rviz2.motion_planning_frame]: Action server: /recognize_objects not available
[rviz2-2] [INFO] [1710631071.553848175] [rviz2.motion_planning_frame]: MoveGroup namespace changed: / -> . Reloading params.
[rviz2-2] Error: Name of virtual joint is not specified
[rviz2-2] at line 77 in ./src/model.cpp
[rviz2-2] [INFO] [1710631071.771768347] [rviz2.RDFLoader]: Loaded robot model in 0.0373119 seconds
[rviz2-2] [INFO] [1710631071.772096890] [rviz2.robot_model]: Loading robot model 'abb_irb1200_5_90'...
[rviz2-2] [INFO] [1710631071.772124858] [rviz2.robot_model]: No root/virtual joint specified in SRDF. Assuming fixed joint
[rviz2-2] [ERROR] [1710631071.915970795] [rviz2.BackgroundProcessing]: Exception caught while processing action 'loadRobotModel': parameter 'robot_description_planning.joint_limits.joint_1.max_velocity' has invalid type: Wrong parameter type, parameter {robot_description_planning.joint_limits.joint_1.max_velocity} is of type {double}, setting it to {string} is not allowed.
[rviz2-2] [ERROR] [1710631088.274824636] [rviz2.motion_planning_frame]: Action server: /recognize_objects not available
[rviz2-2] [INFO] [1710631088.298992860] [rviz2.motion_planning_frame]: MoveGroup namespace changed: / -> . Reloading params.
[rviz2-2] Error: Name of virtual joint is not specified
[rviz2-2] at line 77 in ./src/model.cpp
[rviz2-2] [INFO] [1710631088.388384599] [rviz2.RDFLoader]: Loaded robot model in 0.0619428 seconds
[rviz2-2] [INFO] [1710631088.388412207] [rviz2.robot_model]: Loading robot model 'abb_irb1200_5_90'...
[rviz2-2] [INFO] [1710631088.388418599] [rviz2.robot_model]: No root/virtual joint specified in SRDF. Assuming fixed joint
[rviz2-2] [ERROR] [1710631088.464779299] [rviz2.BackgroundProcessing]: Exception caught while processing action 'loadRobotModel': parameter 'robot_description_planning.joint_limits.joint_1.max_velocity' has invalid type: Wrong parameter type, parameter {robot_description_planning.joint_limits.joint_1.max_velocity} is of type {double}, setting it to {string} is not allowed.
[rviz2-2] Error: Name of virtual joint is not specified
[rviz2-2] at line 77 in ./src/model.cpp
[rviz2-2] [INFO] [1710631094.846597608] [rviz2.RDFLoader]: Loaded robot model in 0.0486437 seconds
[rviz2-2] [INFO] [1710631094.846625774] [rviz2.robot_model]: Loading robot model 'abb_irb1200_5_90'...
[rviz2-2] [INFO] [1710631094.846632519] [rviz2.robot_model]: No root/virtual joint specified in SRDF. Assuming fixed joint
[rviz2-2] [ERROR] [1710631094.916683221] [rviz2.BackgroundProcessing]: Exception caught while processing action 'loadRobotModel': parameter 'robot_description_planning.joint_limits.joint_1.max_velocity' has invalid type: Wrong parameter type, parameter {robot_description_planning.joint_limits.joint_1.max_velocity} is of type {double}, setting it to {string} is not allowed.
[INFO] [rviz2-2]: process has finished cleanly [pid 18840]
^C[WARNING] [launch]: user interrupted with ctrl-c (SIGINT)
[static_transform_publisher-3] [INFO] [1710631112.350659272] [rclcpp]: signal_handler(signum=2)
[robot_state_publisher-4] [INFO] [1710631112.350826488] [rclcpp]: signal_handler(signum=2)
[INFO] [static_transform_publisher-3]: process has finished cleanly [pid 18842]
[INFO] [robot_state_publisher-4]: process has finished cleanly [pid 18852]

EGMManager.waitForMessage() will sometimes take 15+ ms when trying to run with an update rate of 250 Hz (and EGMActJoint SampleRate of 4 ms).

Using EGMManager.read() without waitForMessage() will sometimes result in reading the same message multiple times - this may cause slightly choppy robot movements.

Diagram of EGM architecture

See related: ros-industrial/abb_libegm#49

Hi, I was trying to go through the simulation instructions, but it failed to move the robot. I've tried to install moveit from binary and source, but neither of them worked.

I'm using:

• Ubuntu 22.04 Jammy
• ROS Humble
• Moveit Humble
• Humble branch of this repo

Before "Plan & Execute"

The controllers were launched properly, and the robot is visible, but some error occured in the terminal launching moveit. Some snippets in the moveit terminal:
[move_group-1] [ERROR] [1712989408.783870240] [moveit.ros.occupancy_map_monitor.middleware_handle]: No 3D sensor plugin(s) defined for octomap updates [move_group-1] [INFO] [1712989408.786487167] [moveit.ros_planning_interface.moveit_cpp]: Loading planning pipeline 'move_group' [move_group-1] [INFO] [1712989408.800953160] [moveit.ros_planning.planning_pipeline]: Using planning interface 'OMPL' [move_group-1] [ERROR] [1712989408.802300586] [moveit.ros_planning.planning_pipeline]: Exception while loading planning adapter plugin 'default_planner_request_adapters/AddTimeParameterization': According to the loaded plugin descriptions the class default_planner_request_adapters/AddTimeParameterization with base class type planning_request_adapter::PlanningRequestAdapter does not exist. Declared types are default_planner_request_adapters/AddRuckigTrajectorySmoothing default_planner_request_adapters/AddTimeOptimalParameterization default_planner_request_adapters/Empty default_planner_request_adapters/FixStartStateBounds default_planner_request_adapters/FixStartStateCollision default_planner_request_adapters/FixStartStatePathConstraints default_planner_request_adapters/FixWorkspaceBounds default_planner_request_adapters/ResolveConstraintFrames

[rviz2-2] Warning: class_loader.impl: SEVERE WARNING!!! A namespace collision has occurred with plugin factory for class rviz_default_plugins::displays::InteractiveMarkerDisplay. New factory will OVERWRITE existing one. This situation occurs when libraries containing plugins are directly linked against an executable (the one running right now generating this message). Please separate plugins out into their own library or just don't link against the library and use either class_loader::ClassLoader/MultiLibraryClassLoader to open. [rviz2-2] at line 253 in /opt/ros/humble/include/class_loader/class_loader/class_loader_core.hpp [rviz2-2] [ERROR] [1712989412.290795067] [moveit_ros_visualization.motion_planning_frame]: Action server: /recognize_objects not available [rviz2-2] [INFO] [1712989412.309354962] [moveit_ros_visualization.motion_planning_frame]: MoveGroup namespace changed: / -> . Reloading params. [rviz2-2] Error: Name of virtual joint is not specified [rviz2-2] at line 77 in ./src/model.cpp

After"Plan & Execute"

In the moveit terminal:
[move_group-1] [INFO] [1712990535.023803560] [moveit.simple_controller_manager.follow_joint_trajectory_controller_handle]: joint_trajectory_controller started execution [move_group-1] [WARN] [1712990535.023870835] [moveit.simple_controller_manager.follow_joint_trajectory_controller_handle]: Goal request rejected [move_group-1] [ERROR] [1712990535.023905674] [moveit.simple_controller_manager.follow_joint_trajectory_controller_handle]: Goal was rejected by server [move_group-1] [ERROR] [1712990535.024029339] [moveit_ros.trajectory_execution_manager]: Failed to send trajectory part 1 of 1 to controller joint_trajectory_controller [move_group-1] [INFO] [1712990535.024042082] [moveit_ros.trajectory_execution_manager]: Completed trajectory execution with status ABORTED ... [move_group-1] [INFO] [1712990535.031561068] [moveit_move_group_default_capabilities.move_action_capability]: Solution found but controller failed during execution [rviz2-2] [INFO] [1712990535.033060957] [move_group_interface]: Plan and Execute request aborted [rviz2-2] [ERROR] [1712990535.033182323] [move_group_interface]: MoveGroupInterface::move() failed or timeout reached

In the controller terminal:
[ros2_control_node-1] [INFO] [1712990535.023239545] [joint_trajectory_controller]: Received new action goal [ros2_control_node-1] [ERROR] [1712990535.023350523] [joint_trajectory_controller]: Time between points 0 and 1 is not strictly increasing, it is 0.000000 and 0.000000 respectively

Hi,

First of all, thank you very much for creating the Foxy branch for abb_ros2, I have tested it by controlling my ABB IRB120 in Robot Studio with MoveIt!2 in Foxy and it works :)

Unfortunately, I am having some problems when trying to manipulate the Controller I/O-s with ABB-RWS in ROS2 Foxy. I wanted to test the ROS2-RobotStudio connection by calling a simple service, and this is what happens:

1. I launch the RWS client, and it connects to the robot correctly:
   

2. I call "ros2 service list", and the ROS2 Services provided by abb_rws appear on the screen.

3. I try to call a ROS2 Service, but ROS2 cannot detect the ROS2 Service, and therefore nothing is executed. This happens with every single ROS2 Service on the list:
   

I have followed the same exact steps in my ROS2 Rolling machine, and it works properly:

I believe something could be missing, which blocks all ABB RWS ROS2 Services from being executed or initialised...
Any help with this would be much appreciated, thank you very much in advance!

Regards,
Mikel

When/if abb_ros2_msgs is incorporated as rhe ros2 branch of https://github.com/ros-industrial/abb_robot_driver_interfaces, the link in the .repos file will need to be updated.

ros-industrial/abb_robot_driver_interfaces#4

The Ompl add time parameterization had a name change from

AddTimeParameterization to AddTimeOptimalParameterization.

At the top of the ompl_planning.yaml it should look like this instead:

planning_plugin: ompl_interface/OMPLPlanner request_adapters: >- default_planner_request_adapters/AddTimeOptimalParameterization default_planner_request_adapters/ResolveConstraintFrames default_planner_request_adapters/FixWorkspaceBounds default_planner_request_adapters/FixStartStateBounds

hello,

also i want to try it on IRB1200_7_70 real robot, thank you.

Simulating a robot in ROS2：
For this simulation, ROS2 simulates the robot controllers. RobotStudio or a physical robot are not needed.
ros2 launch abb_bringup abb_control.launch.py description_package:=abb_irb1200_support description_file:=irb1200_5_90.xacro launch_rviz:=false moveit_config_package:=abb_irb1200_5_90_moveit_config use_fake_hardware:=true

After launching the controllers, launch MoveIt:
ros2 launch abb_bringup abb_moveit.launch.py robot_xacro_file:=irb1200_5_90.xacro support_package:=abb_irb1200_support moveit_config_package:=abb_irb1200_5_90_moveit_config moveit_config_file:=abb_irb1200_5_90.srdf.xacro

i launch MoveIt with the guide above,when i plan&execute the robot to move,get an error like this:
[move_group-1] [ERROR] [1657782273.093466545] [moveit.simple_controller_manager.follow_joint_trajectory_controller_handle]: Action client not connected to action server: joint_traj_compliance_controller/follow_joint_trajectory
[move_group-1] [ERROR] [1657782273.093486026] [moveit_ros.trajectory_execution_manager]: Failed to send trajectory part 1 of 1 to controller joint_traj_compliance_controller

@Yadunund I am unable to get the controller to be recognized with this change if I do a fresh install. Am I doing something wrong that you can tell?

See below and it says that it says that there are zero controllers in the list. If I revert this commit, it works as normal.

I tried to launch the abb_bringup package, but I encountered the error 'Failed to collect complementary mechanical unit info.' Even though I can log in to RWS using the robot's IP address and default username and password. How can I fix this?

Hi @stephanie-eng

I had a chance to try this hardware_interface with a real IRB manipulator. The AbbHardwareInterface class was able to successfully initializeand the EGM client on the robot was successfully connected. The robot's state in RViz matched that of the physical robot's current pose. No joint trajectory commands were sent. But after 10 seconds or so of idle operation, the ABB controller throws this error below

The Probable case in the error description hinted that it might be due to speed limitations. I figured the hardware_interface is sending higher than expected speed values to the joints and so I increased the \MaxSpeedDeviation parameter in rapid to 100. The rest of the RAPID code is the same. But now the robot violently jerks after the same 10 seconds and comes to a halt with the error below.

I'm not able to replicate this behaviour with the exact same robot+controller running in RobotStudio. I'm able to successfully plan and execute trajectories when connected to RobotStudio.

Hence, I'm wondering if you or your team might have any debugging suggestions for this problem. Would it be related to joint speeds in the urdf? Or something in the ros2_control.xacro file? Would modifying the PID values used by the joint_trajectory_controller help? Any advise would be much appreciated.

We plan to contribute the description package of our robot and launch files to this repo once we can confirm everything works with the real robot. We're having no issues in RobotStudio simulation.

Hi,
I am trying to control an ABB robot in simulation with the command interface in velocity with ROS2 foxy. The values of the joint velocities states, in simulation, are changing but the robot is not moving. While if I try to move the robot using the position command interface I can do it.
Is it possible to move the robot only using the velocity command interface? If so, is there any example on how to do it?
Thanks.