Services Unavailable in MoveIt

[Manimaran017]

Description:
The program script works in RViz but the services (Set Robot Mode Service and MoveJ Service) are unavailable when running with MoveIt. The script hangs, waiting for the services to become available and eventually fails.

Steps I Followed:

1. Build the workspace using colcon build
2. source install/setup.bash
3. ros2 launch dsr_bringup2 dsr_bringup2_moveit.launch.py mode:=real model:=a0912 host:=192.168.137.100
4. ros2 run example simple

Expected Behavior:
The script should initialize the required services and work with MoveIt to execute robot motions.

Actual Behavior:
The script works correctly in RViz.
When used with MoveIt, it waits indefinitely for the services (Set Robot Mode Service and MoveJ Service) and fails to execute.

Request:
Please investigate why the services are not available with MoveIt, even though the script works in RViz. Any guidance or fixes would be greatly appreciated

[leeminju531]

Thank you for your inquiry
It seems that when launching MoveIt, there is no default namespace. However, in the example file you provided, it appears the namespace is set to 'dsr01'.
Please feel free to reach out if the issues persist!

[Manimaran017]

Hi @leeminju531,

I have followed the instructions to set up my robot with MoveIt, but I am encountering some issues. After launching the robot and running the example, I see the following logs:

It appears that the "Services" are not available and there are errors related to a mismatch between the URDF and SRDF files.

Could you please assist in resolving these issues, specifically the URDF/SRDF mismatch and the unavailable service?

Steps I have taken:
1)Verified that the namespace (dsr01) is set correctly.
2)Ensured that the robot model (a0912) is specified in the launch file.
3)The "Set Robot Mode" service is still not available after waiting for some time. Please see the attached screenshot below for further context.
command: ros2 launch dsr_bringup2 dsr_bringup2_moveit.launch.py mode:=virtual host:=127.0.0.1 port:=12345 model:=a0912 namespace:=dsr01 debug:=true

Thank you for your assistance. I look forward to your support in resolving this issue.

[Manimaran017]

Hi @leeminju531
I wanted to kindly follow up on this issue.

[leeminju531]

Dear @Manimaran017,

Could you make service calls (like SetRobotMode and movejoint) without running the example file through the CLI?
If it works, please describe the example file we could run. If not, please provide what you did and the full log.

[Manimaran017]

Hi @leeminju531,
It's not working. I attached the log files

service commands.txt
MoveIt command.txt

[AstrobotDaniel]

I am having a similar issue. Here are my observations:

1. The service in question seems to be provided via dsr_bringup2_gazebo.launch.py
   a. To call the service, use /dsr01/motion/move_joint instead of /MoveJoint
   b. The service works as expected with dsr_bringup2_rviz.launch.py
   c. However, the Gazebo configuration does not match the Rviz configuration. This seems to be an issue?

2. dsr_bringup2_moveit.launch.py requires namespace:=dsr01 to work (this is missing in the README.md)
   a. With the proper namespace defined, RVIZ launches with Moveit enabled, otherwise it fails to start-up
   b. While the move_joint service can be called with this setup, it results in faulty response initially (success=False):

    ros2 service call /dsr01/motion/move_joint dsr_msgs2/srv/MoveJoint "{pos: [45.0, 30.0, 15.0, 90.0, 45.0, 30.0], 
    vel: 10.0, 
    acc: 5.0, 
    time: 2.0, 
    radius: 0.0, 
    mode: 0, 
    blend_type: 0, 
    sync_type: 0}"
    waiting for service to become available...
    requester: making request: dsr_msgs2.srv.MoveJoint_Request(pos=array([45., 30., 15., 90., 45., 30.]), vel=10.0, acc=5.0, time=2.0, radius=0.0, mode=0, blend_type=0, sync_type=0)
   
    response:
    dsr_msgs2.srv.MoveJoint_Response(success=False)
   

   c. if the motion planner was used once, the gazebo model responds to the service call, but the rviz robot remains where it is:

   ros2 service call /dsr01/motion/move_joint dsr_msgs2/srv/MoveJoint "{pos: [45.0, 30.0, 15.0, 90.0, 45.0, 30.0], 
   vel: 10.0, 
   acc: 5.0, 
   time: 2.0, 
   radius: 0.0, 
   mode: 0, 
   blend_type: 0, 
   sync_type: 0}"
   2025-01-04 12:47:48.256 [RTPS_TRANSPORT_SHM Error] Failed init_port fastrtps_port7421: open_and_lock_file failed ->     Function open_port_internal
   2025-01-04 12:47:48.258 [RTPS_TRANSPORT_SHM Error] Failed init_port fastrtps_port7423: open_and_lock_file failed -> Function open_port_internal
   2025-01-04 12:47:48.259 [RTPS_TRANSPORT_SHM Error] Failed init_port fastrtps_port7427: open_and_lock_file failed ->    Function open_port_internal
   waiting for service to become available...
   requester: making request: dsr_msgs2.srv.MoveJoint_Request(pos=array([45., 30., 15.,  90., 45., 30.]), vel=10.0, acc=5.0, time=2.0, radius=0.0, mode=0, blend_type=0, sync_type=0)
   
   response:
   dsr_msgs2.srv.MoveJoint_Response(success=True)
   

[Manimaran017]

Dear @leeminju531,

Just following up on the issue I reported earlier. Have there been any updates on the service call or potential solutions for the errors?

[leeminju531]

@AstrobotDaniel

1. The service in question seems to be provided via dsr_bringup2_gazebo.launch.py

This issue maybe related to dsr_bringup2_moveit.launch.py

2. dsr_bringup2_moveit.launch.py requires namespace:=dsr01 to work (this is missing in the README.md)
   a. With the proper namespace defined, RVIZ launches with Moveit enabled, otherwise it fails to start-up

After further investigation, I found that dsr_bringup2_moveit.launch.py doesn't work when a namespace is set.

b. While the move_joint service can be called with this setup, it results in faulty response initially (success=False):

This could be due to the controller still being in the boot-up process, not fully initailized yet.

c. if the motion planner was used once, the gazebo model responds to the service call, but the rviz robot remains where it is:

This is caused by the namespace issue.

I will create a follow-up issue to add namespace support in dsr_bringup2_moveit.launch.py.
In the meantime, could you try running it without specifying the namespace?
(e.g.: ros2 launch dsr_bringup2 dsr_bringup2_moveit.launch.py mode:=virtual host:=127.0.0.1.)

[leeminju531]

@Manimaran017

Based on the logs you attached, I see that there were two attempts withdsr_bringup2_moveit.launch.py
I'd like to point out a few things:

1. I was able to reproduce the URDF-related logs on my end:

[rviz2-8] 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-8]          at line 253 in /opt/ros/humble/include/class_loader/class_loader/class_loader_core.hpp
[rviz2-8] Error:   Semantic description is not specified for the same robot as the URDF
[rviz2-8]          at line 664 in ./src/model.cpp

While this issue is present, it doesn’t seem to directly affect the services at this time.

2. In your first attempt, the cause of the moveit launch failure is the following error:

[ros2_control_node-2] [ERROR] [1735965227.344591286] [dsr_hw_interface2]: DSRInterface::init() DRCF connecting ERROR!!!

This indicates that the controller was not successfully loaded. I will create a follow-up issue to address this.

3. In your second attempt, the services appear to have loaded successfully. However, the service calls you made were incorrect. You can introspect all available services with ros2 service list. Additionally, Specifying namespace in launch is 'name' not 'namespace'. see launch files

   doosan-robot2/dsr_bringup2/launch/dsr_bringup2_rviz.launch.py

   Lines 35 to 36 in 0460ba7

   	DeclareLaunchArgument('name', default_value = 'dsr01', description = 'NAME_SPACE' ),
   	DeclareLaunchArgument('host', default_value = '127.0.0.1', description = 'ROBOT_IP' ),

Lastly, as mentioned in my previous response, dsr_bringup2_moveit.launch.py works only when the namespace is not specified.Could you try running it without specifying the namespace?

(e.g.
ros2 launch dsr_bringup2 dsr_bringup2_moveit.launch.py mode:=virtual host:=127.0.0.1 port:=12345 model:=a0912
ros2 service call /motion/move_joint dsr_msgs2/srv/MoveJoint ..
ros2 service call /system/set_robot_mode dsr_msgs2/srv/SetRobotMode "robot_mode: 1"
)

[leeminju531]

I believe the initial failure of the move_joint service and the dsr_bringup2_moveit.launch.py failure (due to the connection error) addressed in #144

[AstrobotDaniel]

I updated to 1808c11 in order to test your solution merged with #144. Unfortunately, this makes things worse.

Fist of all, the problem with the missing service remains. If I just start dsr_bringup2_moveit.launch.py without specifying a namespace and then run ros2 service call /motion/move_joint dsr_msgs2/srv/MoveJoint .. the call stays at waiting for service to become available... indefinitely. Am I supposed to start dsr_bringup2_gazebo.launch.py in addition?

Yet even worse, the update seams to break the controller. If I use the RViz GUI to call Plan & Execute, the robot is not following the plan and the service returns with a timeout.

For comparison, I initiated the planner through the GUI twice, once with the new version 1808c11 and once with the previous working version 0460ba7. Both output files are attached here for your review.

new failing version: 1808c11.txt
old working version: 0460ba7.txt

[Manimaran017]

@leeminju531
I’m encountering similar issues with the controller not following the planned trajectory and the service call timing out. Both real-time and virtual modes seem to be affected with RViz working in real-time but not in virtual mode and MoveIt not working in either mode. Let me know if you find a solution and I’ll continue testing on my end as well.

[leeminju531]

@AstrobotDaniel

Am I supposed to start dsr_bringup2_gazebo.launch.py in addition?

No, you only need to start dsr_bringup2_moveit.launch.py.

@AstrobotDaniel @Manimaran017
The PR I sent has been reverted—sorry for the inconvenience and thanks for your investigations.

I believe the issues occurred due to two main points:

1. The controller needs to be fully invoked, which is related to the two issues mentioned:

• Moveit timeout failure (100 % related)
  [ros2_control_node-2] [ERROR] [1735965227.344591286] [dsr_hw_interface2]: DSRInterface::init() DRCF connecting ERROR!!!
• move_joint service call related (might be related)

2. dsr_bringup2_moveit.launch.py needs to support namespace arguments.

I’ll open separate follow-up issues for this. Thanks again!

[Manimaran017]

Hi @leeminju531,

Thank you for your update regarding the issues you’ve identified. I appreciate your thorough investigation and your plan to open separate follow-up issues.

I would like to revisit the URDF-related warnings that we discussed earlier. The warnings indicate the following:

1. Namespace Collision Warning:
   [rviz2-8] Warning: class_loader.impl: SEVERE WARNING!!! A namespace collision has occurred with the plugin factory for class rviz_default_plugins::displays::InteractiveMarkerDisplay. A new factory will OVERWRITE the existing one. This situation occurs when libraries containing plugins are directly linked against an executable (the one running currently that generates this message). Please separate plugins into their own library or don't link against the library; use either class_loader::ClassLoader/MultiLibraryClassLoader to open.
   [rviz2-8] at line 253 in /opt/ros/humble/include/class_loader/class_loader/class_loader_core.hpp

2. Error on Semantic Description:
   [rviz2-8] Error: Semantic description is not specified for the same robot as the URDF.
   [rviz2-8] at line 664 in ./src/model.cpp

These warnings suggest a potential issue with library linking that could complicate our setup. This might need addressing to ensure that all robot descriptions are properly aligned.

Additionally, I have a concern regarding the virtual environment. I’m uncertain if I need to run a program in a virtual setup to verify how the robot moves. However, when I do run a program in the virtual environment, I don’t see any movement in RViz or Gazebo, although the services do seem to function correctly. If you have any insights into how to run a program in virtual mode, it would be greatly appreciated.

While you mentioned that the initial warnings do not currently affect the services, I believe it is still important to resolve them to prevent any future complications, especially as we work towards a stable integration.
Thank you again for your efforts and I look forward to your updates on the follow-up issues.

[leeminju531]

@Manimaran017,

While you mentioned that the initial warnings do not currently affect the services, I believe it is still important to resolve them to prevent any future complications, especially as we work towards a stable integration.
Thank you again for your efforts and I look forward to your updates on the follow-up issues.

I totally agree. I’ve also opened a separate URDF-related issue as well.

Additionally, I have a concern regarding the virtual environment. I’m uncertain if I need to run a program in a virtual setup to verify how the robot moves. However, when I do run a program in the virtual environment, I don’t see any movement in RViz or Gazebo, although the services do seem to function correctly. If you have any insights into how to run a program in virtual mode, it would be greatly appreciated.

Regarding your concern with the virtual environment, I think you’re approaching it the right way.
However, it seems like it’s not working due to a lack of resources. If you're running it on a virtual machine, that could be the issue.
In my opinion, at the very least, it should provide a notification indicating the cause, even with resource limitations.
Unfortunately, I’m not sure I can address this in a follow-up issue since I can't diagnose the exact reason at the moment.
For now, I’ll focus on investigating the Moveit timeout failure issue, which might be somewhat related to this. Once get merged, I’ll let you know.

[leeminju531]

@Manimaran017
Apologies for the late notice. The Moveit timeout failure might be addressed in #151 first. Thanks!