ROS - 检查节点是否还活着答案

【问题标题】：ROS - check if a node is still aliveROS - 检查节点是否还活着
【发布时间】：2013-09-29 17:11:18
【问题描述】：

我正在为一个有四个轮子的设备实现一个控制节点。到目前为止，我有以下节点：

TALKER:
--Publishes messages for movement of vehicle

LISTENER:
--Listens to messages for movement of vehicle and controls vehicle directly

这两个工作之间的通信，我唯一的问题是如果其中一个关闭，以防止车辆不受控制的移动，该怎么办。 ros::isShuttingDown() 调用 LISTENER 以便它检测到它何时将被杀死。

但是，如果 TALKER 关闭，LISTENER 会根据从 TALKER 收到的最后一条消息继续移动车辆。首先，我尝试在 TALKER 中使用ros::isShuttingDown()，以便向 LISTENER 发送最终的“停止”消息，但似乎一旦节点关闭，就无法进行通信。

因此，我正在寻找一种方法来检查 LISTENER 节点是否还活着（或者是否仍在接收新消息）。

任何人知道如何查看节点（在本例中为 TALKER）是否还活着？或者有没有一种简单的方法可以检测自收到最后一个 ROS 消息以来已经过了多长时间？

【问题讨论】：

回到我刚开始我的机器人之旅时的一个老问题很有趣。对于任何偶然发现这个问题的人：这里的正确答案是重写 LISTENER 以便它检测过时的消息并在来自 TALKER 的消息停止进入 X 秒后停止移动车辆。节点是独立的程序，应该有相应的结构。

标签： communication nodes messages ros

【解决方案1】：

看看bond 包。我相信它完全符合您的需要。

【讨论】：

谢谢，这正是我需要的

【解决方案2】：

发现了另一种有趣且已经内置的方式，包括“ros/network.h”：

// master.h:
....

/**
* \brief Retreives the currently-known list of nodes from the master
*/
ROSCPP_DECL bool getNodes(V_string& nodes);

....

但是，我不知道如何在另一个 cpp 文件中使用它...

【讨论】：

我觉得这很有帮助！我在测试中使用了它，我可以在不同的命名空间下多次运行启动文件，测试不同的配置设置 - 当一个节点死亡时，该命名空间中的所有节点都死亡。为此，我创建了一个名为 ros::master::getNodes(std::vector<std::string>) 的主节点，以低频率运行，检查是否有任何节点消失/死亡，然后使用该命名空间杀死其列表中具有相同命名空间的任何其他节点。它具有很强的可扩展性，并且不需要对现有节点进行任何更改，只需启动文件即可。
为了杀死一个节点，我使用了 (c)stdlib system(): system(("rosnode kill " + node_name_to_kill).c_str()); 来杀死程序，当只剩下主节点（和被忽略的 rosout 节点）时（或者只是杀死这一切，无论出于何种原因），system("killall -2 rosmaster")，其中 -2 用于 SIGINT，这是关闭节点的干净/好方法。对于 SIGTERM，这可以升级到 -15，它仍然有效。
@JWCS 感谢您的评论。但是，ROS 是一个 C++ 库。不得不求助于系统调用似乎是一种非常错误的方法，因为必须有库函数来直接执行所需的操作，而无需通过命令行。我真的希望有比你描述的更好的方法。但我没有关注最近的 ROS 开发。
这几乎是受支持的方式，rosnode kill 发送一个 SIGINT。 ROS 将 ros::shutdown 设计为使用 SIGINT；调用内部（和可覆盖的）关闭处理程序。即使它做得更多，调用 rosnode kill 也是最面向未来的方法：它总是会软退出。但请记住，ROS 的核心目标是一个 linux 平台，它通过 c 提供了非常强大的系统互操作性，因此是 SIGINT。 & c++ 的核心只是一个 c 扩展。我真的很喜欢我们如何通过 ros::network 获取其他节点，但是现在检查了所有标头，我还没有找到更好的杀死方法：/
或者，如果可以的话，我只需将 roslaunch xml 属性 required="true" 或 respawn="true" 添加到 <node> 即可执行 OP 想要的操作。不适用于我的情况，但可以通过在发生崩溃时将其全部关闭来处理 90%，而不仅仅是像我评论的那样选择性地关闭。 (<node> attributes)