Discovery Server Support

[SharmiliRudraraju98]

Robot Model

Turtlebot4 Standard

ROS distro

Jazzy

Networking Configuration

Simple Discovery

OS

Ubuntu 24.04

Built from source or installed?

Installed

Package version

ros-jazzy-turtlebot4-navigation: 2.0.1-1noble.20241028.132320
ros-jazzy-turtlebot4-bringup: 2.0.1-2noble.20241028.133441
ros-jazzy-turtlebot4-node: 2.0.1-1noble.20241018.082137

Type of issue

Networking

Expected behaviour

Requirement: Need to run TurtleBot4 SLAM and Nav2 from a laptop
on a university network where multicast is blocked. The robot and
laptop must communicate over the network without multicast.

Current approach: Using Tailscale VPN with FastDDS ROS_STATIC_PEERS
and initialPeersList XML for unicast DDS discovery.

Expected: With this setup, Nav2 should successfully activate all
lifecycle nodes including local_costmap, with the full TF chain
(map→odom→base_link) available to all ROS 2 nodes on the laptop.

Question: Is Tailscale the recommended approach for this type of
network setup? Are there better alternatives that work reliably
with TurtleBot4 Jazzy without breaking Create3 ↔ RPi communication?

Actual behaviour

Most topics work correctly over Tailscale:

• /scan: ~7.7Hz ✓
• /odom: ~20Hz ✓
• /tf: ~27Hz ✓
• /map: ~1Hz ✓ (slam_toolbox running fine)

However, Nav2 fails to activate every time:

• The odom→base_link transform (published by Create3) takes 15-20
  seconds to be discovered by new DDS participants on the laptop
• Nav2's local_costmap times out after 60 seconds waiting for
  base_link→odom and aborts bringup
• Verified: ros2 topic echo /tf | grep "child_frame_id: base_link"
  takes 15-20 seconds before any output appears on laptop
• Bandwidth loss observed: robot publishes /tf at 12.4 KB/s but
  laptop only receives 8.7 KB/s (~30% loss across Tailscale)
• odom→base_link buffer_length on laptop only ~0.86 seconds
  (confirmed via ros2 run tf2_tools view_frames)

Error messages

[local_costmap.local_costmap]: Timed out waiting for transform from base_link to odom to become available, tf error: Invalid frame ID "base_link" passed to canTransform argument source_frame - frame does not exist
[lifecycle_manager_navigation]: Failed to change state for node: controller_server
[lifecycle_manager_navigation]: Failed to bring up all requested nodes. Aborting bringup.
[local_costmap.local_costmap]: Failed to activate local_costmap because transform from base_link to odom did not become available before timeout

To Reproduce

1. Set up TurtleBot4 Standard on a university network where multicast is blocked
2. Install Tailscale on both robot (RPi4) and laptop
3. Configure FastDDS with ROS_STATIC_PEERS and initialPeersList XML
   pointing to each device's Tailscale IP
4. On laptop: source ROS 2, launch slam.launch.py, wait for
   "Registering sensor: [Custom Described Lidar]"
5. On laptop: launch nav2.launch.py
6. Observe Nav2 repeatedly timing out on base_link→odom transform
   and aborting after 60 seconds
7. Verify issue: run ros2 topic echo /tf | grep "child_frame_id: base_link"
   on laptop — output takes 15-20 seconds to appear

Other notes

Additional context

What I tried:

• Started with ROS_DISCOVERY_SERVER — broke Create3 ↔ RPi communication
• Tried Zenoh bridge (rmw_zenoh_cpp) — also risks breaking Create3 local multicast
• Settled on Tailscale VPN + FastDDS ROS_STATIC_PEERS + initialPeersList XML
  as it preserves Create3 ↔ RPi local multicast while enabling unicast WAN discovery

Key diagnostics:

• ros2 topic bw /tf: robot sends 12.4 KB/s, laptop receives only 8.7 KB/s (~30% loss)
• ros2 run tf2_tools view_frames: odom→base_link buffer_length only ~0.86s on laptop
• ros2 topic echo /tf | grep "child_frame_id: base_link": takes 15-20s to appear

Questions for maintainers:

1. Is Tailscale the recommended VPN for TurtleBot4 on restricted networks?
2. Is there a better FastDDS configuration for WAN/unicast setups?
3. Can Nav2's local_costmap activation timeout be increased via parameters?
4. Is there any known fix for slow DDS participant discovery over VPN/WAN?
5. Open to hear any better approach to handle this network condition where multicast is blocked

Configuration files attached:

laptop_fastdds_tailscale.xml
robot_fastdds_tailscale.xml

• Robot /etc/turtlebot4/setup.bash additions:
  export ROS_STATIC_PEERS="<LAPTOP_TAILSCALE_IP>"
  export FASTRTPS_DEFAULT_PROFILES_FILE="/home/ubuntu/fastdds_tailscale.xml"

  Laptop /.bashrc additions:
  export ROS_DOMAIN_ID=0
  export RMW_IMPLEMENTATION=rmw_fastrtps_cpp
  export ROS_STATIC_PEERS="<ROBOT_TAILSCALE_IP>"
  export FASTRTPS_DEFAULT_PROFILES_FILE=~/fastdds_tailscale.xml

[RustyCPR]

Hi @SharmiliRudraraju98,
Thanks for writing in, and I want to commend you for the depth of investigation and the number of configurations you’ve already tried - there’s clearly been a lot of thoughtful effort put into this.
At the moment, the combination of Tailscale VPN + FastDDS ROS_STATIC_PEERS + initialPeersList XML isn’t a configuration we’re able to officially support. You’re absolutely welcome to continue experimenting with it, but support from our side would necessarily be limited for that setup.

Reviewing the TurtleBot4 issue history, I didn’t see any prior issues from you related to a DDS Discovery Server configuration or to Create3 / Raspberry Pi communication failures resulting from that approach. Because of that, I don’t believe we’ve had a chance to walk through that option together yet.
If you’re open to revisiting a Discovery Server based setup, we’d be happy to help support and guide you through that configuration.
Please let me know,
Rusty

[SharmiliRudraraju98]

Hi @RustyCPR,

Thanks for the response.

I'd love to revisit the Discovery Server setup with your guidance. I did attempt it earlier but abandoned it because it broke the Create3 ↔ RPi communication where the battery and comm lights went off and the robot became unresponsive.

Does the Discovery Server approach work on a university network where multicast is completely blocked? And is there a way to configure it without breaking the local Create3 ↔ RPi communication?

[RustyCPR]

HI @SharmiliRudraraju98
If this is something you’d like to revisit, please start by setting up a standard ROS 2 Jazzy TurtleBot 4 configuration using the Discovery Server, and we can take it from there.
If you run into any issues during setup, please share the following so we can take a closer look:

• Create3 logs: https://iroboteducation.github.io/create3_docs/webserver/logs/
• Output from: journalctl -u turtlebot4 -r
• Full terminal outputs of what you are running in text file.

Once we have those, we’ll be better positioned to help troubleshoot.
Best regards,
Rusty

[RustyCPR]

Hi there @SharmiliRudraraju98
Any updates on this?
Thanks,
Rusty

[SharmiliRudraraju98]

Hi Rusty,

Sorry for the late reply! Great news though — it's working! The Discovery Server setup resolved the issue and Nav2 is running smoothly now.

I do have a follow-up question: I'm mapping a long corridor that has glass walls in the middle. I'm noticing some bending/distortion in the map along that stretch. Is there a recommended way to handle this? I'm guessing the lidar reflections off the glass might be causing it, but not sure how to mitigate it.

Thanks again for your help!
Sharmili

[RustyCPR]

Hi there @SharmiliRudraraju98
Glass / Windows are a very common cause of map distortion with 2D lidar, especially in long corridors.

Fixes:

• Add non-glass features: tape, posters, foam strips on glass or even temporary markers help.
• Limit max range of the lidar: range_max: 12.0 set to 6.0 or 5.0
• Avoid hugging the glass wall and stay centered in corridor
• Map in both directions (forward + backward pass)

Best regards,
Rusty