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 而不必担心网络延迟, 如果需要,我愿意帮助描述基本的测试用例。