Whats the right config to use for microROS agent and discovery server?
aditya2592 opened this issue · 6 comments
Issue template
- Hardware description: STM32 Nucleo board
- RTOS: Zephyr
- Installation type:
- Version or commit hash: galactic
Steps to reproduce the issue
- Start microros agent docker agent with fastdds and below config for
FASTRTPS_DEFAULT_PROFILES_FILE
<?xml version="1.0" encoding="UTF-8" ?>
<dds>
<profiles xmlns="http://www.eprosima.com/XMLSchemas/fastRTPS_Profiles">
<transport_descriptors>
<transport_descriptor>
<transport_id>CustomUdpTransport</transport_id>
<type>UDPv4</type>
</transport_descriptor>
</transport_descriptors>
<participant profile_name="super_client_profile" is_default_profile="true">
<rtps>
<userTransports>
<transport_id>CustomUdpTransport</transport_id>
</userTransports>
<useBuiltinTransports>false</useBuiltinTransports>
<builtin>
<discovery_config>
<discoveryProtocol>SUPER_CLIENT</discoveryProtocol>
<discoveryServersList>
<RemoteServer prefix="44.53.00.5f.45.50.52.4f.53.49.4d.41">
<metatrafficUnicastLocatorList>
<locator>
<udpv4>
<address>127.0.0.1</address>
<port>11811</port>
</udpv4>
</locator>
</metatrafficUnicastLocatorList>
</RemoteServer>
</discoveryServersList>
</discovery_config>
</builtin>
</rtps>
</participant>
</profiles>
</dds>
- Enter the docker using
docker exec -it <container_id> bash
- Echo topic list
ros2 topic list
Expected behavior
- Topics from microros on the nucleo are visible
Actual behavior
ros2 topic list
doesn't show any topics that are being published on the nucleo- If discovery server is removed from the XML, then the topics are visible:
<?xml version="1.0" encoding="UTF-8" ?>
<dds>
<profiles xmlns="http://www.eprosima.com/XMLSchemas/fastRTPS_Profiles">
<transport_descriptors>
<transport_descriptor>
<transport_id>CustomUdpTransport</transport_id>
<type>UDPv4</type>
</transport_descriptor>
</transport_descriptors>
<participant profile_name="super_client_profile" is_default_profile="true">
<rtps>
<userTransports>
<transport_id>CustomUdpTransport</transport_id>
</userTransports>
<useBuiltinTransports>false</useBuiltinTransports>
</rtps>
</participant>
</profiles>
</dds>
Additional information
Hello @aditya2592
In order to help you with your issue, we will need more information regarding your scenario and the nodes running.
Configuration file seems fine, and it looks like it is being loaded correctly.
So, I would say the problem here is about reaching the Server (Discovery Server).
The node that works as Discovery Server needs to be running in order for a Super Client to connect with the network (and get discovery information). Do you have a Discovery Server running? If so, are you sure it is listening in the locator you have set 127.0.0.1::11811 and it is recheable from the ros2 daemon (the node in charge of executing ros2 topic list
.
Please, check this tutorial and make sure you are running a Discovery Server and that your ros2 daemon is configured as a super client : #84 (or else, you can configure your ros2 daemon as the Discovery Server if you do not have one in your scenario).
If you have further questions, please let us know and retrieve more information about your specific use case.
Hi @jparisu, yes the discovery server is running through another docker container using the IP address and port in above config. We use the discovery server for all other services, subscribers and publishers that are present on the host PC itself and it works as expected in code and on the daemon. Regarding configuring the daemon as super client, is_default_profile="true"
flag should take care of that right?
Is the DomainParticipant
in the agent code compatible with using a participant
profile that points to discovery server as the discovery
protocol? Or does it mess up its discovery of information coming from the nucleo board running microros?
Adding some more info, discovery server is launched using docker-compose
below:
discovery_server:
image: <custom image built off ros-galactic-ros-base>
container_name: discovery_server
network_mode: host
ipc: host
volumes:
- /dev:/dev
stop_signal: SIGINT
privileged: true
command: fastdds discovery --server-id 0 --ip-address 127.0.0.1 --port 11811
And then the agent + ROS daemon commands are in another docker instance launched through compose:
moveit:
image: <same image as above>
depends_on:
- discovery_server
logging:
driver: "json-file"
options:
max-size: "20m"
max-file: "10"
privileged: true
container_name: moveit
network_mode: host
ipc: host
init: true
environment:
- DISPLAY=$DISPLAY
- QT_X11_NO_MITSHM=1
- PYTHONFAULTHANDLER=1
- NVIDIA_VISIBLE_DEVICES=all
- NVIDIA_DRIVER_CAPABILITIES=all
command: ros2 launch micro_ros_agent micro_ros_agent_launch.py
stop_signal: SIGINT
Both the above instances are using the same super client config that I posed in my earlier message. Then I docker exec
into the moveit
container from above list and try to do ros2 topic list
. In another experiment, I tried to do everything in the same docker instance and I am able to list and echo the topic. However it doesn't work across docker instances.
We have tested the scenario with the expected results:
-
Docker 1:
- Set
FASTRTPS_DEFAULT_PROFILES_FILE
to a file containing your XML file - Instantiate a micro-ROS Agent using
ros2 run micro_ros_agent ...
- Connect a micro-ROS client
- Set
-
Docker 2:
- Set
FASTRTPS_DEFAULT_PROFILES_FILE
to a file containing your XML file - Instantiate a Discovery Server using
fastdds discovery --server-id 0 --ip-address 127.0.0.1 --port 11811
- Check if we can reach the topics using
ros2 topic list
- Set
Both docker has been intantiated using:
docker run \
-it \
--net=host \
- v /dev:/dev \
--privileged \
-e DISPLAY=$DISPLAY \
-v /tmp/.X11-unix:/tmp/.X11-unix \
[image]
Could you provide precise steps for creating a scenario where we can reproduce your issue?
This works now! I had to build the agent package as part of our ROS image and launch the agent through that image using docker-compose