discourse.ros.org/t/fastdds-without-discovery-server/26117/9
有疑问如下：
我一直在以多种方式与 FastDDS（在 ROS2 Humble 上）作斗争——但最大的问题是发现。
对于我的机器人，我有一个用于驱动程序的启动文件，第二个用于定位，第三个用于导航——它们都在机器人计算机上运行。如果我按顺序启动它们，一切正常 - 但然后说我必须重新启动导航才能更改配置 - 大约 75% 的时间，它无法连接某些主题（尤其是 tf 似乎是一个问题），然后我必须重新启动驱动程序启动文件 - 我会注意到我认为问题在于发现，因为现有连接（例如定位节点到驱动程序）继续起作用。切换到 CycloneDDS 也使问题消失。
当我开始研究解决方案时 - 一切似乎都表明“解决方案”是发现服务器：
eProsima 发现服务器
新发现服务器
将 ROS 2 与 Fast-DDS 发现服务器一起使用
ROS2 最受吹捧的“特性”之一，即没有单点故障 (rosmaster)，是否真的不适用于更大的系统和默认的 DDS？
还是开箱即用的配置不起作用，我需要以某种特定方式配置 FastDDS？
在这里寻找反馈/帮助 - 因为根据技术评估报告 1一半的受访者表示他们喜欢 FastDDS 而不是 CycloneDDS——但我无法让事情顺利进行。
Fergs
我有点认为这就是我在这里所做的 - 鉴于我没有在一些大型花哨的商业产品中使用它，我的期望是我将依赖社区支持。我什至不确定我会在哪里发布问题（rmw 实现，FastDDS 本身？）。鉴于这更像是一个“系统”问题，我没有一个可重现的最小示例来分享。
我的问题实际上是：我正在寻找有关如何让更大的系统（25 个以上节点）工作的见解，因为我运气不太好。我什至不完全确定从哪里开始。我希望您的许多用户中的一些可能能够指向一个资源/帖子，上面写着“嘿，这就是我们使事情变得真正可靠的方式” - 到目前为止，一切似乎都指向发现服务器（这似乎违反直觉，因为过去几年围绕 ROS2 进行营销，但也许这是正确的答案，我应该去使用它）。
我与 RMW 报告的链接更多的是它告诉我，那里有一半的用户正在让它非常可靠地工作——我想知道他们的技巧/提示。
smac
即使这是答案，也应该作为默认配置文件而不是用户处理。您正在尝试做的是非常基本的/基本的-我很震惊 Fast-DDS 存在问题。
我将 Cyclone 用于涉及硬件机器人的大多数事情，我发现它在启动/常规服务调用中更稳定，但自从我认真研究 Fast-DDS 以来已经有一段时间了。现在它是默认设置，我将开始更多地使用它，因为我需要支持 Nav2 用户，但这对于移动机器人社区来说并不是一个很好的第一印象。
我现在也开始在 Nav2 中看到 RMW/DDS 相关票证的增加，这是自 Foxy 时代以来我从未见过的，上次 Fast-DDS 是默认设置，令人不安的是，我们可能已经退步了即用即用行为，即使 TSC RMW 报告指标未捕获该信息。还值得注意的是 Fast-DDS 报告的 RMW 问题：在运行时使用专用回调组创建的订阅者不起作用 · 问题 #613 · ros2/rmw_fastrtps · GitHub 5对于我所在的世界特定角落来说，这是一个非常关键的回归。
我想我很清楚，由于 Fast-DDS 现在是默认设置，我想确保处理任何零碎的事情，以便 ROS 2 中的 Nav2 和移动机器人用户获得良好的体验，因为我希望每个人都能关于同一页。
没有人建议任何激进的措施。这是一个讨论潜在问题和收集反馈的论坛，这就是这里发生的一切。
jaime
非常有趣的时间家伙。
如果您遇到可重现的问题，可以很容易地联系到 Fast DDS 背后的团队。为什么不发布问题？我在这里看不到任何真正的问题。许多用户确实会见我们并与我们一起评论他们的架构。你为什么不试试那个频道？GitHub？打电话给我们？
有了 Foxy、Galactic 和现在的 Humble，我们的主要 Fast DDS 存储库每月有大约 50K 的克隆。此外，我们的商业客户也在稳步增长。我们有很多用户，他们中的大多数，无论是直接使用 ROS 2 还是 DDS，都是满意的用户。
不幸的是，在某些情况下，我们可能会遇到错误，或者其他实现对于特定用例可能会表现得更好。因为在中间件中，所有的决策都需要权衡，而且我们肯定不是所有潜在用例的最佳选择。
目前，选择 RMW 默认值的过程是透明的：技术报告和 TSC 成员的职业，他们都是 ROS 2 的重度用户和重要贡献者。@smac认为旋风更好，他可能投票给旋风。但是我们也有非常重的ROS 2用户支持Fast DDS，在生产系统和商业机器人中使用ROS 2和Fast DDS，我们赢得了投票。我喜欢这样：投票基于可重复的技术论点和公正的测量，以及民主。
我的团队非常愿意讨论任何发现场景。我们甚至对可扩展性进行了非常大规模的研究，您可以在此处查看：
快速 DDS 发现机制分析 2
如果您需要解决方案，请在技术上讨论您的方案，与我们会面等。很容易找到我们。给我留言吧。或者，如果您想要公开讨论，可重现的问题是一个很好的起点。我们总是愿意改进我们的实施。
25+ 个节点，并不是一个真正的大系统。我们有更大的生产部署，其中一些使用默认发现，其中一些使用发现服务器。
是的，大型系统中可能会发生发现问题：这不是特定的实现，也不是 DDS，而是架构的本质。然后，您需要微调您的系统，使用 Discovery Server 等工具
我的个人经验来自一家没有多少资源可花费也没有 DDS 配置专业知识的公司：
我们使用 Fast DDS 开始了我们在 ROS2 galactic 中的工作。当时我们遇到了非常令人沮丧的问题，即服务没有响应、没有被发现或以巨大的延迟响应 + 一些高 CPU 使用率（所有这些都被报告了）。而且它不是一个分布式系统：一切都在 Ubuntu 20.04 下的强大 x86 计算机上运行（再标准不过了）。没什么太花哨的：定制的 nav2 堆栈、使用组合避免序列化的 3D 点云处理管道和硬件接口。
切换到 Cyclone DDS 后，我们所有的问题都神奇地消失了。
回想起来，对我们来说，从 ROS1 切换到 ROS2 的最高成本是解决 DDS 相关问题（另一个例子：localhost only 需要在环回接口上启用多播才能工作以及如何激活它，即“ip link set lo multicast on ”，该信息很难找到）。
从我在这篇文章中读到的内容来看，与默认 DDS 供应商更改相关的核心 ros 功能（发布/订阅/主题/服务/操作）似乎仍然存在一些不稳定性。从这个意义上说（单台计算机上的节点到节点通信），ROS2 仍然与 ROS1 不同。在 ROS1 中它可以正常工作。
作为一个“天真”的 ros 用户，我的反馈是：我相信有一些质量系统测试缺少针对 DDS 功能的测试。我们在 Galactic 下遇到的有关服务的问题被忽视是不正常的。对于影响 Humble 下回调组订阅的当前问题也是如此。如果是 DDS 配置问题，那么默认配置应该至少在标准系统（x86 Ubuntu LTS）上适用于标准 ROS 接口（发布/订阅/主题/服务/操作）。我认为等待非滚动发布来测试和迭代这些问题是不可接受的。我完全可以理解需要深入研究异国用例的配置，但请记住，绝大多数用户在单台计算机上运行 ROS 而不必担心网络延迟，
如果需要，我愿意帮助描述基本的测试用例。