如何最好地处理有关主题，服务等的依赖性，以优雅地处理启动和错误恢复？ （ROS2）
我们应该使用标准方法来处理对主题和服务的依赖性吗？我们的系统有许多节点，一些节点为外部传感器提供了接口。我们希望能够干净处理启动和错误恢复条件。
我们正在考虑一些不同的情况，并寻求建议，
如果我们有一个节点“ a”，该节点取决于其他节点，节点“ b”和“ c”提供的主题和服务应该上网吗？
“ a”是否应该等待完成启动，直到看到“ B”和“ C”提供数据值的主题？例如。节点“ a”有一些标志，并在数据进来时将它们翻转为True，而当它们都被翻转时，“ A”可以在线上？
我们希望我们的系统能够合理地处理传感器。
也许不是在所有情况下，但对于特定传感器，这很重要。如果我们的传感器消失了，我们如何向提供对这些传感器访问的节点的用户表示信息？
例如，如果传感器消失，节点“ b”是否应该停止发布其主题？在这种情况下，应该节点“ a”跟踪“ b”提供的主题的最后更新时间，如果计时器到期，则可以使用缺乏数据来检测传感器脱机并脱机，等待直到等到在恢复操作之前可以使用数据吗？
我们环顾四周，似乎无法在此方面找到任何指导，但是我们怀疑这可能是由于我们没有使用正确的术语或遗漏或误解ROS2的设计意图所致。
我们将感谢您可能拥有的任何提示或指示。
Is there a standard approach we should be using to handle dependencies on topics and services? Our system has a number of nodes and some nodes provide interfaces to external sensors. We'd like to be able to cleanly handle startup and error recovery conditions.
We are considering a few different situations and looking for advice
If we have a node 'A' that depends on topics and services provided by other nodes, nodes 'B', and 'C' how should node 'A' determine when it is ready and should go online?
Should 'A' wait to complete its startup until it sees the topics provided by 'B' and 'C' providing data values? Eg. node 'A' has some flags and flips them to true when data comes in and when they are all flipped node 'A' can go online?
We'd like our system to reasonably handle sensors going away.
Maybe not in all cases but for particular sensors this is important. If we have sensors that go away, how do we indicate that information through to the users of the node that provides access to those sensors?
For example should node 'B' stop publishing its topics if its sensor goes away? In that case should node 'A' be tracking the last update time for the topic provided by 'B' and if a timer expires node 'A' can use the lack of data to detect the sensor going offline and itself go offline, waiting until data is available before resuming its operation?
We've looked around and can't seem to find any guidance on this, however we suspect this may be due to our not searching using the correct terminology or missing or misunderstanding the design intent of Ros2.
We'd appreciate any tips or pointers you might have.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
一些快速的地方看：
您可以查看QoS策略中的主题和服务，QoS将帮助您在订户能够从出版商那里获取数据的情况下确定数据，但据我了解，您想要的不仅仅是这些。对于主题，我会说这不那么方便。但是，对于服务，您具有辅助功能，例如（
this-＆gt; client.wait_for_server（））。通常，您在
package.xml中声明软件包的依赖项（构建和执行时间），但这只是为了确定包装的正确构建和执行，这意味着它没有知识当该主题或服务上网的时候。但是，对于节点的更确定性行为，您可以在ROS2中使用
lifecyclenodes概念。这样，您将状态（例如，活动性，不配置，不活动等）明确分配给节点，并且有了一些腿部工作，您可以决定何时是时候该节点具有active/not活动。您可以随时使用ROS消息的时间邮票来确定它是否对您有用。如果您在回调中接收和处理传感器数据之后发布这些主题，则自然而然的是，如果没有传感器数据，则节点将停止发布，因为无法触发回调。此外，您可以定义计时器回调，以定期检查最新收到消息的时间戳记，并让用户知道这一点。
A few quick places to look:
You may check the Qos Policies for topics and services, Qos would help you to establish under what circumstances a subscriber is able to get data from a publisher, but to my understanding, you want something more than that. For the topics, I would say it isn't as convenient. For services, though, you have helper functionalities such as (
this->client.wait_for_server()).Typically, you declare the dependencies (build and execution time) of your package in
package.xmlbut this is just to determine the correct build and execution of your package, meaning that it does not have the knowledge of when it is time for a topic or service to go online.But, for more deterministic behavior of your nodes, you may use
LifeCycleNodesconcept in ROS2. This way, you explicitly assign a state (e.g., active, unconfigured, inactive, etc) to your node, and with some legwork, you can decide when it is time for the node to be active/inactive. You can always use the the timestampof a ROS message to determine if it is still useful to you.If you are publishing these topics after you receive and process sensor data in a callback, naturally the node will stop publishing if no sensor data is available since the callback won't be triggered. Additionally, you can define a timer callback to periodically check the time stamp of latest received message and let the user know about this.