No Ros2 topic found (Difficulties in the installation)

[t-domenigoni]

Hey everyone,

System

• Ros2 Humble
• Ubuntu 22.04 Jammy
• DX 200
• Yaskawa 6-axes robot + linear axe + 2 axes roll-pitch positionner

Context
We are trying to configure a DX200 Yaskawa in order to communicate ros2 topic (such as the joint state of the robot, or the linear translation of the rail) between the robot and our PC. We've follow the full installation guide; we now have our USB key with motoros2 file in it that we plug into the CN106

Our problem

We can't see topics when ros2 topic list (same for nodes) after following the full installation guide.
Furthermore, we are not sure that motoros2 is enable on the teach pendant; and we don't know how to verify it with the normal mode operation. If it is correctly launch, how to know that our PC is well configured ?

Firewall

sudo ufw status 
[sudo] password for domenigoni: 
Status: inactive

Ethernet cable to the robot controller

CN104 (LAN)
When pinging it we have:

Click to expand

ping 192.168.0.1
PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
64 bytes from 192.168.0.1: icmp_seq=1 ttl=59 time=511 ms
64 bytes from 192.168.0.1: icmp_seq=2 ttl=59 time=330 ms
64 bytes from 192.168.0.1: icmp_seq=3 ttl=59 time=70.5 ms
64 bytes from 192.168.0.1: icmp_seq=4 ttl=59 time=89.9 ms
64 bytes from 192.168.0.1: icmp_seq=5 ttl=59 time=83.6 ms
64 bytes from 192.168.0.1: icmp_seq=6 ttl=59 time=72.6 ms
64 bytes from 192.168.0.1: icmp_seq=7 ttl=59 time=80.1 ms
64 bytes from 192.168.0.1: icmp_seq=8 ttl=59 time=46.2 ms
64 bytes from 192.168.0.1: icmp_seq=9 ttl=59 time=66.6 ms
64 bytes from 192.168.0.1: icmp_seq=10 ttl=59 time=56.0 ms
64 bytes from 192.168.0.1: icmp_seq=11 ttl=59 time=74.6 ms
64 bytes from 192.168.0.1: icmp_seq=12 ttl=59 time=72.2 ms
64 bytes from 192.168.0.1: icmp_seq=13 ttl=59 time=64.7 ms
64 bytes from 192.168.0.1: icmp_seq=14 ttl=59 time=83.1 ms
^C
--- 192.168.0.1 ping statistics ---
14 packets transmitted, 14 received, 0% packet loss, time 13008ms
rtt min/avg/max/mdev = 46.237/121.499/510.582/127.141 ms

USB stick

CN106 with 3 directory in it, first one is config with in it motoros2_config.yaml, 2nd robots_job, third a file mr2_dx2_h.out.

We only modified the motoros2_config.yaml

Click to expand

---
# SPDX-FileCopyrightText: 2022-2023, Yaskawa America, Inc.
# SPDX-FileCopyrightText: 2022-2023, Delft University of Technology
#
# SPDX-License-Identifier: Apache-2.0


#-----------------------------------------------------------------------------
# REQUIRED
# IP address and UDP port number of the Micro-ROS Agent PC. All communication
# to/from MotoROS2 will route through the Agent application.
# (There is no default value for these fields. They must be specified by
# the user.)
agent_ip_address: "192.168.0.10"
agent_port_number: 8888


# Any settings that are not specified will be set to their DEFAULT value.


#-----------------------------------------------------------------------------
# The (DDS) domain to join
#
# Please refer to the ROS 2 documentation on DDS domain IDs for more
# information. This setting works exactly like its ROS 2 analogue.
#
# DEFAULT: 0 (the default ROS 2 domain ID)
#ros_domain_id: 0

#-----------------------------------------------------------------------------
# Name under which MotoROS2 should register with the ROS 2 node graph.
#
# DEFAULT: "motoman_xx_yy_zz"  (xyz: last three bytes of robot's MAC address)
#node_name: ""

#-----------------------------------------------------------------------------
# Namespace to use for the MotoROS2 node and all topics.
#
# DEFAULT: ""  (empty string)
#node_namespace: ""

#-----------------------------------------------------------------------------
# Remap rules to apply to ROS 2 resource names.
#
# This configures the micro-ROS equivalent of the ROS 2 remap functionality.
#
# The current implementation expects all remap rules as a single,
# space-separated string. Whitespace in resource names is not allowed, so
# this should not pose any issues.
#
# Maximum total length of the remap_rules string: 255 chars. Any characters
# beyond that will be ignored (and likely result in parsing failures).
#
# Please refer to the ROS 2 documentation on remapping for more information
# on syntax and contraints.
#
# Example: the following remaps the 'joint_states' topic to 'my_joint_states',
# and the 'read_single_io' service to 'io/read_single':
#
#   "joint_states:=my_joint_states read_single_io:=io/read_single"
#
# DEFAULT: ""  (empty string)
#remap_rules: ""

#-----------------------------------------------------------------------------
# This will ensure that when timestamps are sampled, they will match the clock
# of the Agent PC. This is useful if the date/time of the robot controller is
# not synchronized.
#
# DEFAULT: true
sync_timeclock_with_agent: true

#-----------------------------------------------------------------------------
# Should MotoROS2 monitor the link state of the ethernet port used to
# communicate with the Agent?
#
# If enabled, this will cause immediate notification of loss-of-connection
# when the link goes down, causing MotoROS2 to activate it's shutdown
# behaviour (ie: stop all motion (if enabled), release resources, wait for
# link up and attempt reconnection with the Agent).
#
# If this is disabled, Agent disconnection detection uses an application
# layer based timeout mechanism which takes longer to detect disconnects (but
# might be more robust against intermittent link-layer disconnects which do not
# cause network disconnections).
#
# DEFAULT: true
#userlan_monitor_enabled: true

#-----------------------------------------------------------------------------
# Which port should MotoROS2 monitor, if 'userlan_monitor_enabled' is 'true'?
#
# If not specified, MotoROS2 will attempt to auto-detect the network port
# that is used to connect to the micro-ROS Agent. It will do this by
# comparing the 'agent_ip_address' setting against the IP addresses (and
# netmasks) of all available network interfaces.
#
# If the Agent can be reached directly over a particular interface, or via a
# configured default gateway on the same interface, the associated port will be
# monitored for link drops.
#
# To disable auto-detection, uncomment 'userlan_monitor_port' below and set
# it to the desired port.
#
# NOTE:   this setting only applies to YRC1000 and YRC1000u controllers.
#         DX200 and FS100 controllers only have a single ethernet port, and any
#         value other than 1 will be ignored.
#
# NOTE 2: auto-detection is not perfect. It can't determine whether the Agent
#         might be reachable using multiple hops. Nor can it determine whether
#         any routers have been configured to forward particular types of
#         traffic or firewalls exist between MotoROS2 and the micro-ROS Agent.
#         For deployments with complex network configurations, disable
#         auto-detection by configuring 'userlan_monitor_port' below.
#
# NOTE 3: the port specified here is NOT checked against 'agent_ip_address'.
#         In other words: if 'agent_ip_address' is on 'USER_LAN1', but
#         'userlan_monitor_port' is set to 'USER_LAN2', MotoROS2 will detect
#         link down events on 'USER_LAN2', whether or not that port is used
#         to communicate with the Agent.
#
# OPTIONS: USER_LAN1, USER_LAN2
# DEFAULT: USER_LAN1
#userlan_monitor_port: USER_LAN1

#-----------------------------------------------------------------------------
# If the Agent PC disconnects from the robot while it is in motion, should the
# robot come to a stop?
#
# DEFAULT: true
stop_motion_on_disconnect: true

#-----------------------------------------------------------------------------
# Should MotoROS2 broadcast transforms on '/tf'? This can be disabled if
# the data will interfere with applications such as robot_state_publisher.
#
# DEFAULT: true
publish_tf: true

#-----------------------------------------------------------------------------
# Should the 'tf' topic be namespaced if 'node_namespace' is configured with a
# non-empty string?
#
# Setting this to 'false' will make MotoROS2 broadcast transforms on the '/tf'
# global topic, which cannot be namespaced (due to being an absolute name).
# Otherwise, it will broadcast on 'tf', which can be namespaced.
#
# DEFAULT: true
namespace_tf: true

#-----------------------------------------------------------------------------
# Similar to the 'frame_prefix' parameter of the ROS 2 'robot_state_publisher'
# node. All published TF frames will be prefixed with this string.
#
# Example: with this parameter set to "left/", the "r1/tool0" frame would be
# published as "left/r1/tool0".
#
# NOTE: the prefix must include a separator (fi: '/') if one should be included
#       in the final name of the TF frames. Such a separator is not added
#       automatically.
#
# DEFAULT: ""  (empty string)
#tf_frame_prefix: ""

#-----------------------------------------------------------------------------
# Joints in this configuration file must be listed in the order of Robots,
# Base-axes, Station-axes.
#
# Example: R1+B1+R2+S1 system
#
# joint_names:
# - [r1_s_axis, r1_l_axis, r1_u_axis, r1_r_axis, r1_b_axis, r1_t_axis]
# - [r2_s_axis, r2_l_axis, r2_u_axis, r2_r_axis, r2_b_axis, r2_t_axis, r2_e_axis]
# - [b1_axis]
# - [s1_axis_1, s1_axis_2]
#
# When using a 7 axis robot arm with an elbow joint (E) in the middle of the
# arm, the elbow axis should be listed last (SLURBTE).
#
# DEFAULT: "group_x/joint_y"
#joint_names:
#- [group_1/joint_1, group_1/joint_2, group_1/joint_3, group_1/joint_4, group_1/joint_5, group_1/joint_6]

#-----------------------------------------------------------------------------
# Logging settings
logging:
  # All log messages are broadcast on the network on port UDP 21789.
  # Additionally, the messages can be printed to the standard output stream of
  # the robot controller. This would be visible over a telnet connection, or by
  # attaching a VGA debug monitor to the robot controller.
  #
  # NOTE: this WILL slow down the application.
  #
  # DEFAULT: false
  log_to_stdout: false

#-----------------------------------------------------------------------------
update_periods:
  # The delay between checks for incoming activity on the network. A lower
  # number will result in quicker responsiveness to received messages.
  # Additionally, it determines the rate at which the feedback_publisher timers
  # are checked.
  # This value should be <= to action_feedback_publisher_period as executor_sleep_period
  # is the rate at which the action-feedback timer is checked. If the value for
  # action_feedback_publisher_period is < executor_sleep_period, it will effectively
  # be treated as having the same value executor_sleep_period at runtime.
  #
  # DEFAULT: 10 milliseconds
  executor_sleep_period: 10

  # The delay between each publish of feedback position and status information.
  # A lower number will publish the feedback data more frequently.
  # This value should be >= to executor_sleep_period and
  # controller_status_monitor_period.
  #
  # DEFAULT: 20 milliseconds
  action_feedback_publisher_period: 20

  # The delay between each poll of the robot I/O and controller status data.
  # This value should be <= to action_feedback_publisher_period.
  #
  # DEFAULT: 10 milliseconds
  controller_status_monitor_period: 10

#-----------------------------------------------------------------------------
# QoS profile to use for various publishers MotoROS2 creates.
# The default values here are based on tests and inspection of the source code
# of typical consumers of messages on these topics.
#
# NOTE : RViz2 expects/requires 'tf' to use the 'default' profile (ie: reliable).
# NOTE2: MoveIt2 expects/requires 'joint_states' to use the 'default' profile.
publisher_qos:
  # DEFAULT: sensor_data
  robot_status: sensor_data

  # DEFAULT: sensor_data
  joint_states: sensor_data

  # DEFAULT: default
  tf: default

#-----------------------------------------------------------------------------
# Name of the INFORM job to be used (and monitored) by MotoROS2.
#
# Maximum length: 32 UTF-8 characters. 16 Japanese (Shift-JIS) characters.
#
# Set this to a custom value when using a custom INFORM job with a different
# name.
#
# NOTE: do NOT include the file extension here (ie: '.JBI'). Only the name
#       of the job should be specified.
#
# DEFAULT: "INIT_ROS"
#inform_job_name: "INIT_ROS"

#-----------------------------------------------------------------------------
# Allow custom INFORM job.
#
# If MotoROS2 detects that the specified INFORM job is not formatted properly
# then an alarm will be raised at startup.
# This flag indicates that the job is intentionally configured and will
# suppress the alarm.
#
# When this flag is set to 'true', then MotoROS2 will not validate whether the
# job is compatible. It is the responsibility of the user to make sure the
# custom job includes the required INFORM statements and in the expected order
# (refer to the provided INFORM job files for the general structure).
#
# DEFAULT: false
#allow_custom_inform: false

#-----------------------------------------------------------------------------
# Ignore missing calibration data on multi-group systems with TF broadcast
# enabled.
#
# MotoROS2 will raise an alarm (8013[16]) on a multi-group controller if it
# is unable to load any calibration data and broadcasting of TF frames is
# enabled.
# This calibration data is needed to correctly disambiguate multiple distinct
# TF trees which would otherwise potentially (partially) overlap each other.
#
# Set this flag to 'true' to prevent the alarm from being raised, for instance
# in cases where uncalibrated multi-group systems should still broadcast TF.
#
# DEFAULT: false
#ignore_missing_calib_data: false

192.168.0.10 which is indeed the IP of our PC; in the same subnet as our Robot (IProbot: 192.168.0.1)

Micro agent

We've follow the installation from source of the micro-ros agent and when running it we have:

domenigoni:~/micro_ros_agent_ws$ ros2 run micro_ros_agent micro_ros_agent udp4 --port 8888 
[1739978312.205965] info     | UDPv4AgentLinux.cpp | init                     | running...             | port: 8888
[1739978312.206159] info     | Root.cpp           | set_verbose_level        | logger setup           | verbose_level: 4

Best.

[gavanderhoorn]

Hi @t-domenigoni

starting with this:

Furthermore, we are not sure that motoros2 is enable on the teach pendant; and we don't know how to verify it with the normal mode operation.

You could either look at the PANELBOX.LOG file (via a backup on a usb stick) or find the information on loaded MotoPlus applications in the system information on the Programming Pendant directly. @ted-miller: could you mention the sequence of menus to follow to get to that information?

If you don't see something like this:

//MOTOPLUS APP
01: MotoROS2 (humble)                0.1.3            micro-ROS based ROS 2 interface 

MotoROS2 is not installed on your controller.

USB stick

CN106 with 3 directory in it, first one is config with in it motoros2_config.yaml, 2nd robots_job, third a file mr2_dx2_h.out We only modified the motoros2_config.yaml

I understand the confusion, but mr2_dx2_h.out should not be on the USB stick after installation.

You should load it as a MotoPlus application in Maintenance Mode as described in the Installing MotoROS2 out file section.

After installation, for a DX200, the only file on the USB in CN106 would be motoros2_config.yaml.

Nothing else.

(note: technically, it doesn't really matter whether mr2_dx2_h.out is on your USB stick after installation. I just wanted to clarify that your DX200 will not start mr2_dx2_h.out from the USB stick. You really must install it as a MotoPlus application for that)

The robot jobs are also not needed, unless you have a special controller setup which needs a custom INFORM job.

Could you please try the steps in the Installing MotoROS2 out file section and verify you can load the .out using the [MotoPlus APL]→[Load (User App)] menus?

[gavanderhoorn]

Something else I just noticed:

64 bytes from 192.168.0.1: icmp_seq=6 ttl=59 time=72.6 ms

can you say anything about your network configuration?

For a direct cable connection between your PC and the DX200, a ping time of 72ms is extremely high.

Are you using wireless somewhere, or is this a connection over a very busy network, or are you perhaps using a VPN of some sort?

For a direct connection I would expect a ping time of 10 ms maximum.

Please verify your network setup.

[ted-miller]

You could either look at the PANELBOX.LOG file (via a backup on a usb stick) or find the information on loaded MotoPlus applications in the system information on the Programming Pendant directly. @ted-miller: could you mention the sequence of menus to follow to get to that information?

In normal operation mode, touch System Info > Version. Then on the pendant keypad, press PAGE two or three times.

[t-domenigoni]

Thank you for your reactivity, very appreciate.

So, we removed the following files from the USB stick (CN106): INIT_ROS.JBI, IONAME.DAT, mr2_dx2_h.out; so that only motoros2_config.yaml is still on the USB key before plug it in again in the controller (with the following parameters modify)

Then, by following @ted-miller instruction; we can see on the teach pendant:

Click to expand

Concerning the ethernet connection; we were directly link between our PC and the CN104 (LAN) port with an ethernet cable. However we just changed the port for another one; and now we get ping time of 1ms !

Click to expand

~$ ping 192.168.0.1
PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
64 bytes from [192.168.0.1](http://192.168.0.1/): icmp_seq=1 ttl=64 time=1.13 ms
64 bytes from [192.168.0.1](http://192.168.0.1/): icmp_seq=2 ttl=64 time=0.528 ms
64 bytes from [192.168.0.1](http://192.168.0.1/): icmp_seq=3 ttl=64 time=0.387 ms
64 bytes from [192.168.0.1](http://192.168.0.1/): icmp_seq=4 ttl=64 time=0.356 ms
64 bytes from [192.168.0.1](http://192.168.0.1/): icmp_seq=5 ttl=64 time=0.390 ms
64 bytes from [192.168.0.1](http://192.168.0.1/): icmp_seq=6 ttl=64 time=0.357 ms
64 bytes from [192.168.0.1](http://192.168.0.1/): icmp_seq=7 ttl=64 time=0.351 ms
64 bytes from [192.168.0.1](http://192.168.0.1/): icmp_seq=8 ttl=64 time=0.401 ms
64 bytes from [192.168.0.1](http://192.168.0.1/): icmp_seq=9 ttl=64 time=0.356 ms
64 bytes from [192.168.0.1](http://192.168.0.1/): icmp_seq=10 ttl=64 time=0.391 ms
64 bytes from [192.168.0.1](http://192.168.0.1/): icmp_seq=11 ttl=64 time=0.410 ms
64 bytes from [192.168.0.1](http://192.168.0.1/): icmp_seq=12 ttl=64 time=0.394 ms
c^C
--- 192.168.0.1 ping statistics ---
12 packets transmitted, 12 received, 0% packet loss, time 11238ms

We then run again the micro-ros agent:

domenigoni:~/micro_ros_agent_ws$ ros2 run micro_ros_agent micro_ros_agent udp4 --port 8888 
[1739978312.205965] info     | UDPv4AgentLinux.cpp | init                     | running...             | port: 8888
[1739978312.206159] info     | Root.cpp           | set_verbose_level        | logger setup           | verbose_level: 4

Is this correct for the micro_ros agent ?

And finally ros2 topic list; we only see /rosout and /parameter_events so no motoman or joint_states.

Best.

[t-domenigoni]

We've follow your instruction; please find the log file attached to this post.
20250220T101923_motoros2_debug_log.txt

[t-domenigoni]

Okay thats very strange I just reboot again the DX200; and I think I can now read the robot sate:

ros2 topic echo /ctrl_groups/b1/joint_states give me:

  frame_id: ''
name:
- group_3/joint_1
position:
- 1.5743955600585937
velocity:
- 0.0
effort:
- 0.0
---
header:
  stamp:
    sec: 1740044573
    nanosec: 342121029
  frame_id: ''
name:
- group_3/joint_1
position:
- 1.5743955600585937
velocity:
- 0.0
effort:
- 0.0
---
header:
  stamp:
    sec: 1740044573
    nanosec: 351121029
  frame_id: ''
name:
- group_3/joint_1
position:
- 1.5743955600585937
velocity:
- 0.0
effort:
- 0.0
---

And when changing the position of the robot from the rail, I can see values changing !
However, ros2 run micro_ros_agent micro_ros_agent udp4 --port 8888 give me an error:

[1740044432.028016] error    | UDPv4AgentLinux.cpp | init                     | bind error             | port: 8888, errno: 98
Error while starting IPvX agent!
[1740044432.028062] info     | UDPv4AgentLinux.cpp | fini                     | server stopped         | port: 8888

But I can still see the ros2 topics without running this micro agent node (that I do not understand the purpose of).

Can you confirm that we are getting all the topics and nodes we should received please ?

ros2 topic list
/ctrl_groups/b1/joint_states
/ctrl_groups/b2/joint_states
/ctrl_groups/r1/joint_states
/ctrl_groups/r2/joint_states
/ctrl_groups/s1/joint_states
/joint_states
/parameter_events
/robot_status
/rosout
/tf

ros2 node list
/motoman_09_e8_57

Thx you again for your reactivity; and you can find attached the new log file after the last DX200 reboot !

20250220T103517_motoros2_debug_log.txt

[t-domenigoni]

Hey again;

We tested it we another PC, same subnet 192.168.0.10 and port 8888; ping is good, and now we can see the micro ros agent running properly from what I understand:

 ros2 run micro_ros_agent micro_ros_agent udp4 --port 8888
[1740046902.842427] info     | UDPv4AgentLinux.cpp | init                     | running...             | port: 8888
[1740046902.842660] info     | Root.cpp           | set_verbose_level        | logger setup           | verbose_level: 4
[1740046902.857990] info     | ProxyClient.cpp    | ProxyClient              | session hard timeout enabled | client_key: 0x7909E857, timeout: 10000 ms
[1740046902.858012] info     | Root.cpp           | create_client            | create                 | client_key: 0x7909E857, session_id: 0x81
[1740046902.858049] info     | SessionManager.hpp | establish_session        | session established    | client_key: 0x7909E857, address: 192.168.0.1:31955
[1740046902.873403] info     | ProxyClient.cpp    | create_participant       | participant created    | client_key: 0x7909E857, participant_id: 0x000(1)
[1740046902.946177] info     | ProxyClient.cpp    | create_topic             | topic created          | client_key: 0x7909E857, topic_id: 0x000(2), participant_id: 0x000(1)
[1740046902.949838] info     | ProxyClient.cpp    | create_publisher         | publisher created      | client_key: 0x7909E857, publisher_id: 0x000(3), participant_id: 0x000(1)
[1740046902.951745] info     | ProxyClient.cpp    | create_datawriter        | datawriter created     | client_key: 0x7909E857, datawriter_id: 0x000(5), publisher_id: 0x000(3)
[1740046903.050252] info     | ProxyClient.cpp    | create_topic             | topic created          | client_key: 0x7909E857, topic_id: 0x001(2), participant_id: 0x000(1)
[1740046903.053407] info     | ProxyClient.cpp    | create_publisher         | publisher created      | client_key: 0x7909E857, publisher_id: 0x001(3), participant_id: 0x000(1)
[1740046903.057070] info     | ProxyClient.cpp    | create_datawriter        | datawriter created     | client_key: 0x7909E857, datawriter_id: 0x001(5), publisher_id: 0x001(3)
[1740046903.058719] info     | ProxyClient.cpp    | create_topic             | topic created          | client_key: 0x7909E857, topic_id: 0x002(2), participant_id: 0x000(1)
[1740046903.062022] info     | ProxyClient.cpp    | create_publisher         | publisher created      | client_key: 0x7909E857, publisher_id: 0x002(3), participant_id: 0x000(1)
[1740046903.066231] info     | ProxyClient.cpp    | create_datawriter        | datawriter created     | client_key: 0x7909E857, datawriter_id: 0x002(5), publisher_id: 0x002(3)
[1740046903.069014] info     | ProxyClient.cpp    | create_topic             | topic created          | client_key: 0x7909E857, topic_id: 0x003(2), participant_id: 0x000(1)
[1740046903.070864] info     | ProxyClient.cpp    | create_publisher         | publisher created      | client_key: 0x7909E857, publisher_id: 0x003(3), participant_id: 0x000(1)
[1740046903.073457] info     | ProxyClient.cpp    | create_datawriter        | datawriter created     | client_key: 0x7909E857, datawriter_id: 0x003(5), publisher_id: 0x003(3)
[1740046903.076880] info     | ProxyClient.cpp    | create_topic             | topic created          | client_key: 0x7909E857, topic_id: 0x004(2), participant_id: 0x000(1)
[1740046903.078884] info     | ProxyClient.cpp    | create_publisher         | publisher created      | client_key: 0x7909E857, publisher_id: 0x004(3), participant_id: 0x000(1)
[1740046903.081120] info     | ProxyClient.cpp    | create_datawriter        | datawriter created     | client_key: 0x7909E857, datawriter_id: 0x004(5), publisher_id: 0x004(3)
[1740046903.085297] info     | ProxyClient.cpp    | create_topic             | topic created          | client_key: 0x7909E857, topic_id: 0x005(2), participant_id: 0x000(1)
[1740046903.089048] info     | ProxyClient.cpp    | create_publisher         | publisher created      | client_key: 0x7909E857, publisher_id: 0x005(3), participant_id: 0x000(1)
[1740046903.091369] info     | ProxyClient.cpp    | create_datawriter        | datawriter created     | client_key: 0x7909E857, datawriter_id: 0x005(5), publisher_id: 0x005(3)
[1740046903.095223] info     | ProxyClient.cpp    | create_topic             | topic created          | client_key: 0x7909E857, topic_id: 0x006(2), participant_id: 0x000(1)
[1740046903.099089] info     | ProxyClient.cpp    | create_publisher         | publisher created      | client_key: 0x7909E857, publisher_id: 0x006(3), participant_id: 0x000(1)
[1740046903.102368] info     | ProxyClient.cpp    | create_datawriter        | datawriter created     | client_key: 0x7909E857, datawriter_id: 0x006(5), publisher_id: 0x006(3)
[1740046903.105277] info     | ProxyClient.cpp    | create_topic             | topic created          | client_key: 0x7909E857, topic_id: 0x007(2), participant_id: 0x000(1)
[1740046903.109404] info     | ProxyClient.cpp    | create_publisher         | publisher created      | client_key: 0x7909E857, publisher_id: 0x007(3), participant_id: 0x000(1)
[1740046903.111359] info     | ProxyClient.cpp    | create_datawriter        | datawriter created     | client_key: 0x7909E857, datawriter_id: 0x007(5), publisher_id: 0x007(3)
[1740046903.114559] info     | ProxyClient.cpp    | create_replier           | replier created        | client_key: 0x7909E857, requester_id: 0x000(7), participant_id: 0x000(1)
[1740046903.117417] info     | ProxyClient.cpp    | create_replier           | replier created        | client_key: 0x7909E857, requester_id: 0x001(7), participant_id: 0x000(1)
[1740046903.119323] info     | ProxyClient.cpp    | create_replier           | replier created        | client_key: 0x7909E857, requester_id: 0x002(7), participant_id: 0x000(1)
[1740046903.122171] info     | ProxyClient.cpp    | create_topic             | topic created          | client_key: 0x7909E857, topic_id: 0x008(2), participant_id: 0x000(1)
[1740046903.125277] info     | ProxyClient.cpp    | create_publisher         | publisher created      | client_key: 0x7909E857, publisher_id: 0x008(3), participant_id: 0x000(1)
[1740046903.127305] info     | ProxyClient.cpp    | create_datawriter        | datawriter created     | client_key: 0x7909E857, datawriter_id: 0x008(5), publisher_id: 0x008(3)
[1740046903.129041] info     | ProxyClient.cpp    | create_topic             | topic created          | client_key: 0x7909E857, topic_id: 0x009(2), participant_id: 0x000(1)
[1740046903.132845] info     | ProxyClient.cpp    | create_publisher         | publisher created      | client_key: 0x7909E857, publisher_id: 0x009(3), participant_id: 0x000(1)
[1740046903.135417] info     | ProxyClient.cpp    | create_datawriter        | datawriter created     | client_key: 0x7909E857, datawriter_id: 0x009(5), publisher_id: 0x009(3)
[1740046903.185229] info     | ProxyClient.cpp    | create_replier           | replier created        | client_key: 0x7909E857, requester_id: 0x003(7), participant_id: 0x000(1)
[1740046903.189960] info     | ProxyClient.cpp    | create_replier           | replier created        | client_key: 0x7909E857, requester_id: 0x004(7), participant_id: 0x000(1)
[1740046903.195949] info     | ProxyClient.cpp    | create_replier           | replier created        | client_key: 0x7909E857, requester_id: 0x005(7), participant_id: 0x000(1)
[1740046903.198598] info     | ProxyClient.cpp    | create_replier           | replier created        | client_key: 0x7909E857, requester_id: 0x006(7), participant_id: 0x000(1)
[1740046903.201611] info     | ProxyClient.cpp    | create_replier           | replier created        | client_key: 0x7909E857, requester_id: 0x007(7), participant_id: 0x000(1)
[1740046903.205488] info     | ProxyClient.cpp    | create_replier           | replier created        | client_key: 0x7909E857, requester_id: 0x008(7), participant_id: 0x000(1)
[1740046903.207461] info     | ProxyClient.cpp    | create_replier           | replier created        | client_key: 0x7909E857, requester_id: 0x009(7), participant_id: 0x000(1)
[1740046903.209590] info     | ProxyClient.cpp    | create_replier           | replier created        | client_key: 0x7909E857, requester_id: 0x00A(7), participant_id: 0x000(1)
[1740046903.212222] info     | ProxyClient.cpp    | create_replier           | replier created        | client_key: 0x7909E857, requester_id: 0x00B(7), participant_id: 0x000(1)
[1740046903.214598] info     | ProxyClient.cpp    | create_replier           | replier created        | client_key: 0x7909E857, requester_id: 0x00C(7), participant_id: 0x000(1)
[1740046903.217580] info     | ProxyClient.cpp    | create_replier           | replier created        | client_key: 0x7909E857, requester_id: 0x00D(7), participant_id: 0x000(1)
[1740046903.219334] info     | ProxyClient.cpp    | create_replier           | replier created        | client_key: 0x7909E857, requester_id: 0x00E(7), participant_id: 0x000(1)

However we can't see the topics we saw on the first PC (Cf last post).

20250220T112933_motoros2_debug_log.txt

I've source everything, but still nothing appears which is very confusing as the first PC was publishing everything even without the micro ros agent running.

luca@luca-TravelMate-TCO:~$ source micro_ros_agent_ws/install/setup.bash 
luca@luca-TravelMate-TCO:~$ ros2 topic list
/parameter_events
/rosout
luca@luca-TravelMate-TCO:~$ source ros2_
ros2_humble/ ros2_ws/     
luca@luca-TravelMate-TCO:~$ source ros2_
ros2_humble/ ros2_ws/     
luca@luca-TravelMate-TCO:~$ source ros2_ws/sick/install/setup.bash 
luca@luca-TravelMate-TCO:~$ ros2 topic list
/parameter_events
/rosout
luca@luca-TravelMate-TCO:~$ source /opt/ros/humble/setup.bash 
luca@luca-TravelMate-TCO:~$ ros2 topic list
/parameter_events
/rosout

[t-domenigoni]

Ok I find the culprit; I was in a different ROS_DOMAIN_ID ! Putting back export ROS_DOMAIN_ID=0 in the bashrc fixed the problem !

So I think we are good here; we'll try to play a little with it and see if there is any error left, If so, be sure that we will try to reach you again ahah. I would like to thank you for your reactivity, which is very appreciate with such complicated installation.

Have a nice day,

Best.

Luca & Thomas

[gavanderhoorn]

Good to hear you got things to work.

re: domain ID: yes, that has to match. Unfortunately there isn't really any way we can easily detect mismatches on the MotoROS2 side. Hence the debug process.

re: Agent: the Agent is required as MotoROS2 does not 'speak' DDS natively. It uses a slightly different protocol and the Agent translates between DDS and MotoROS2.

Without the Agent no communication can take place. The fact you still saw some topics in the ros2 topic output was probably due to caching (on the ROS 2 side).

The output you show looks like what I would expect for a DX200 with that amount of motion groups.

re: ROS_DOMAIN_ID=0: that is actually the default value, so you would not necessarily have to set it yourself. But it is of course OK to do so.

If so, be sure that we will try to reach you again

Please feel free to post other support requests on this forum.

[t-domenigoni]

Thank you for all your answers;

Yes so for PC-luca; it works fine ty !

Still for PC-thomas there is the agent error, nevertheless we can received topics correctly so atm this is not so much of an issue, but we would like to know if it could lead to problems and errors later on ?

domenigoni@naval-group:~$ ros2 run micro_ros_agent micro_ros_agent udp4 --port 8888
[1740054095.717979] error    | UDPv4AgentLinux.cpp | init                     | bind error             | port: 8888, errno: 98
Error while starting IPvX agent!
[1740054095.718045] info     | UDPv4AgentLinux.cpp | fini                     | server stopped         | port: 8888
domenigoni@naval-group:~$ ros2 topic list
/ctrl_groups/b1/joint_states
/ctrl_groups/b2/joint_states
/ctrl_groups/r1/joint_states
/ctrl_groups/r2/joint_states
/ctrl_groups/s1/joint_states
/joint_states
/parameter_events
/robot_status
/rosout
/tf

20250220T131705_motoros2_debug_log.txt

[gavanderhoorn]

To clarify: you only need 1 Agent, on one PC. MotoROS2 will also only connect to one Agent. It can't connect to more than 1 Agent.

But if you have two PCs on the same network, and one runs the Agent, PC1 and PC2 can communicate using regular ROS 2 DDS RMW. That could be the reason why you can still see the topics despite not having a running Agent.

If you are not running the Agent on the other PC, the error seems to imply you already have something using UDP port 8888.

If that is another Agent running already that you started earlier, that could also explain why you can still list the topics despite it appearing you don't have an Agent running (but one is running in the background).