RViz plugin fails to start when MoveIt2 is run across machines with FastDDS security enabled

[AravindhDeivaG]

Description

Problem Description

In a typical setup using MoveIt2, move_group, robot_state_publisher, and rviz are launched on the same machine.

In our use case we needed to run:

• move_group and robot_state_publisher on Machine A
• rviz on Machine B

Both machines are connected on the same LAN.

Our routers block multicast flooding by default, so ROS2 discovery using multicast did not work. To solve this we configured unicast discovery using FastDDS initial peers via a FastDDS XML profile.

With FastDDS security disabled, the system works correctly:

• RViz launches successfully
• MoveIt plugin loads correctly
• markers and planning interface are initialized

However, when FastDDS security is enabled, RViz launches but the MoveIt plugin does not initialize properly. Specifically the markers are not initialized.

Root Cause Analysis

The issue originates from a service call from MoveGroupInterface inside the MoveIt RViz plugin.

During initialization, the interface queries the query_planner_interface service exposed by move_group to retrieve the list of available planner plugins.

When FastDDS security is enabled, additional latency is introduced due to:

1. DDS participant authentication
2. Secure endpoint matching

Because of this delay, the service client attempts to call the service before it has been discovered.

Currently there is no check to ensure the service is available before issuing the request. As a result, the request is issued prematurely and the thread blocks indefinitely while waiting for a response.

Proposed Fix

Ensure the service client waits for the query_planner_interface service to become available before sending the request.

Adding a check similar to the following for all the services used in MoveGroupInterfaceImpl in it's constructor resolves the issue. I verified that adding this check locally resolves the issue.

while(!service_client->wait_for_service())
{
    std::this_thread::sleep_for(std::chrono::milliseconds(100));
}

ROS Distro

Humble

OS and version

Ubuntu 22.04

Source or binary build?

Source

If binary, which release version?

No response

If source, which branch?

Humble

Which RMW are you using?

FastRTPS

Steps to Reproduce

Initial peers list fastdds profile xml file for Machine A

<?xml version="1.0" encoding="UTF-8" ?>
<profiles xmlns="http://www.eprosima.com/XMLSchemas/fastRTPS_Profiles"> 

    <transport_descriptors>
        <transport_descriptor>
          <transport_id>udp</transport_id>
          <type>UDPv4</type>
        </transport_descriptor>
    </transport_descriptors>
    
    
    
    <participant profile_name="unicast_peer" is_default_profile="true">
        <rtps>
       	    <userTransports>
                <transport_id>udp</transport_id>
            </userTransports>
            <useBuiltinTransports>false</useBuiltinTransports>
            <builtin>
                <initialPeersList>
                    <metatrafficUnicastLocatorList>
                        <locator/>
                    </metatrafficUnicastLocatorList>
                    <locator>
                        <udpv4>
                            <address>"IP of Machine B"</address>
                        </udpv4>
                    </locator>
                    <locator>
                        <udpv4>
                            <address>127.0.0.1</address>
                        </udpv4>
                    </locator>
                </initialPeersList>
            </builtin>
        </rtps>
    </participant>
</profiles>

To create a profile for machine B replace "IP of Machine B" with "IP of Machine A".

All the security artifacts were generated using standard ros2 security commands as given in the documentation. The following environment variables were used in both the systems

export FASTRTPS_DEFAULT_PROFILES_FILE=/path/to/fastdds_profile.xml
export ROS_DOMAIN_ID=100

export ROS_SECURITY_ENABLE=true
export ROS_SECURITY_STRATEGY=Enforce
export ROS_SECURITY_KEYSTORE=/path/to/keystore

Machine A

export FASTRTPS_DEFAULT_PROFILES_FILE=/path/to/fastdds_profile.xml
export ROS_DOMAIN_ID=100

export ROS_SECURITY_ENABLE=true
export ROS_SECURITY_STRATEGY=Enforce
export ROS_SECURITY_KEYSTORE=/path/to/keystore

ros2 launch <moveit_package> move_group.launch.py
ros2 launch <moveit_package> rsp.launch.py

Machine B

export FASTRTPS_DEFAULT_PROFILES_FILE=/path/to/fastdds_profile.xml
export ROS_DOMAIN_ID=100

export ROS_SECURITY_ENABLE=true
export ROS_SECURITY_STRATEGY=Enforce
export ROS_SECURITY_KEYSTORE=/path/to/keystore
ros2 launch <moveit_package> moveit_rviz.launch.py

Expected behavior

RViz should connect to move_group, initialize the MoveIt plugin correctly, and display markers and planner plugins.

Actual behavior

RViz launches but, markers are not initialized, moveIt interface appears partially initialized

Backtrace or Console output

I'll show the difference in logs as the rviz plugin does not crash as such

Log 1 : Un-successful case

[INFO] [launch]: All log files can be found below /home/sudharshanss/.ros/log/2026-03-06-13-14-26-266628-ATL-HPLT-292-15409
[INFO] [launch]: Default logging verbosity is set to INFO
Using load_yaml() directly is deprecated. Use xacro.load_yaml() instead.
[INFO] [rviz2-1]: process started with pid [15410]
[rviz2-1] Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use QT_QPA_PLATFORM=wayland to run on Wayland anyway.
[rviz2-1] [INFO] [1772783066.432040938] [rcl]: Found security directory: /home/sudharshanss/moveit2_ws/secure_ws/my_keystore/enclaves/rviz
[rviz2-1] [INFO] [1772783066.552674197] [rviz2]: Stereo is NOT SUPPORTED
[rviz2-1] [INFO] [1772783066.552717269] [rviz2]: OpenGl version: 4.6 (GLSL 4.6)
[rviz2-1] [INFO] [1772783066.565591622] [rviz2]: Stereo is NOT SUPPORTED
[rviz2-1] 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-1]          at line 253 in /opt/ros/humble/include/class_loader/class_loader/class_loader_core.hpp
[rviz2-1] [ERROR] [1772783069.657632040] [moveit_ros_visualization.motion_planning_frame]: Action server: /recognize_objects not available
[rviz2-1] [INFO] [1772783069.670440531] [moveit_ros_visualization.motion_planning_frame]: MoveGroup namespace changed: / -> . Reloading params.
[rviz2-1] [INFO] [1772783070.028993202] [moveit_rdf_loader.rdf_loader]: Loaded robot model in 0.305682 seconds
[rviz2-1] [INFO] [1772783070.029032057] [moveit_robot_model.robot_model]: Loading robot model 'robot'...
[rviz2-1] [ERROR] [1772783071.190880472] [moveit_kinematics_base.kinematics_base]: Group 'master_group' is not a chain
[rviz2-1] [ERROR] [1772783071.190903943] [kinematics_plugin_loader]: Kinematics solver of type 'kdl_kinematics_plugin/KDLKinematicsPlugin' could not be initialized for group 'master_group'
[rviz2-1] [ERROR] [1772783071.190914348] [moveit_ros.robot_model_loader]: Kinematics solver could not be instantiated for joint group master_group.
[rviz2-1] [INFO] [1772783074.258797706] [moveit_ros.planning_scene_monitor.planning_scene_monitor]: Starting planning scene monitor
[rviz2-1] [INFO] [1772783074.259348378] [moveit_ros.planning_scene_monitor.planning_scene_monitor]: Listening to '/monitored_planning_scene'
[rviz2-1] [INFO] [1772783078.533318101] [interactive_marker_display_100736250181936]: Connected on namespace: /rviz_moveit_motion_planning_display/robot_interaction_interactive_marker_topic
[rviz2-1] [INFO] [1772783078.595035776] [interactive_marker_display_100736250181936]: Sending request for interactive markers
[rviz2-1] [INFO] [1772783078.626676681] [interactive_marker_display_100736250181936]: Service response received for initialization
[rviz2-1] [INFO] [1772783078.676488616] [moveit_ros_visualization.motion_planning_frame]: group left_arm_group
[rviz2-1] [INFO] [1772783078.676516225] [moveit_ros_visualization.motion_planning_frame]: Constructing new MoveGroup connection for group 'left_arm_group' in namespace ''
[rviz2-1] [INFO] [1772783078.889652869] [move_group_interface]: Ready to take commands for planning group left_arm_group.

Log 2 Successful case

[INFO] [launch]: All log files can be found below /root/.ros/log/2026-03-06-07-50-59-895343-atl-hpz14-15-481
[INFO] [launch]: Default logging verbosity is set to INFO
Using load_yaml() directly is deprecated. Use xacro.load_yaml() instead.
[INFO] [rviz2-1]: process started with pid [482]
[rviz2-1] QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
[rviz2-1] [INFO] [1772783459.988824631] [rcl]: Found security directory: /root/docker_ws/secure_ws/my_keystore/enclaves/rviz
[rviz2-1] [INFO] [1772783460.104053089] [rviz2]: Stereo is NOT SUPPORTED
[rviz2-1] [INFO] [1772783460.104104577] [rviz2]: OpenGl version: 4.6 (GLSL 4.6)
[rviz2-1] [INFO] [1772783460.118544835] [rviz2]: Stereo is NOT SUPPORTED
[rviz2-1] 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-1]          at line 253 in /opt/ros/humble/include/class_loader/class_loader/class_loader_core.hpp
[rviz2-1] [ERROR] [1772783463.187552008] [moveit_ros_visualization.motion_planning_frame]: Action server: /recognize_objects not available
[rviz2-1] [INFO] [1772783463.212200784] [moveit_ros_visualization.motion_planning_frame]: MoveGroup namespace changed: / -> . Reloading params.
[rviz2-1] [INFO] [1772783463.309927823] [moveit_rdf_loader.rdf_loader]: Loaded robot model in 0.0544808 seconds
[rviz2-1] [INFO] [1772783463.309996868] [moveit_robot_model.robot_model]: Loading robot model 'robot'...
[rviz2-1] [ERROR] [1772783464.760880462] [moveit_kinematics_base.kinematics_base]: Group 'master_group' is not a chain
[rviz2-1] [ERROR] [1772783464.760897390] [kinematics_plugin_loader]: Kinematics solver of type 'kdl_kinematics_plugin/KDLKinematicsPlugin' could not be initialized for group 'master_group'
[rviz2-1] [ERROR] [1772783464.760906451] [moveit_ros.robot_model_loader]: Kinematics solver could not be instantiated for joint group master_group.
[rviz2-1] [INFO] [1772783468.596509236] [moveit_ros.planning_scene_monitor.planning_scene_monitor]: Starting planning scene monitor
[rviz2-1] [INFO] [1772783468.597851550] [moveit_ros.planning_scene_monitor.planning_scene_monitor]: Listening to '/monitored_planning_scene'
[rviz2-1] [INFO] [1772783471.221498156] [interactive_marker_display_111240311809728]: Connected on namespace: /rviz_moveit_motion_planning_display/robot_interaction_interactive_marker_topic
[rviz2-1] [INFO] [1772783471.294375801] [interactive_marker_display_111240311809728]: Sending request for interactive markers
[rviz2-1] [INFO] [1772783471.328610565] [interactive_marker_display_111240311809728]: Service response received for initialization
[rviz2-1] [INFO] [1772783471.366665418] [moveit_ros_visualization.motion_planning_frame]: group left_arm_group
[rviz2-1] [INFO] [1772783471.366718012] [moveit_ros_visualization.motion_planning_frame]: Constructing new MoveGroup connection for group 'left_arm_group' in namespace ''
[rviz2-1] [INFO] [1772783471.582690814] [move_group_interface]: Ready to take commands for planning group left_arm_group.
[rviz2-1] [INFO] [1772783471.585939836] [moveit_ros_visualization.motion_planning_frame]: group left_arm_group

The last print statement in log2 will be missing in log1

[riv-mjohnson]

We have a similar setup, and have seen similar problems (albeit much more sporadically). @AravindhDeivaG your solution looks sensible to me. Could you open a PR with this fix?

[AravindhDeivaG]

We have a similar setup, and have seen similar problems (albeit much more sporadically). @AravindhDeivaG your solution looks sensible to me. Could you open a PR with this fix?

Thanks for taking a look! This would actually be my first open source contribution, so I really appreciate the encouragement.

I'll clean up the changes and open a PR shortly. Please let me know if there’s anything specific you'd like me to include or follow in terms of guidelines.