Drake 中 ROS 类服务通信的最佳实践
Best Practice for ROS-Service-like Communication in Drake
想象一下垃圾箱拣选场景：
- 使用 ManipulationStation 设置模拟。
- RGBA & pointcloud可以通过pub/sub.
通过lcm通道访问
- 使用 RGBA 和点云执行抓取检测。
我想实现抓取检测程序，它会不时被调用一次。这意味着该过程在等待调用时将保持空闲状态，什么也不做。在 ROS 中，我可能会使用 ROS-Service 来实现这一点。我想征求在 Drake 框架中执行此操作的最佳实践建议。
我也考虑了一些设计，但都没有满足我的要求。
- 一个直接的选择是通过 lcm 使用 pub/sub。然而，一个天真的实现最终会在抓取检测中结束，无论是否需要抓取，总是 run/update 在后台。
- 将其实现为 LeafSystem 的子类，类似于 RobotLocomotion/6-881-examples 中所做的。但是，如果我理解正确的话，它最终会检测到总是在后台 run/update。
P.S。这可能与主题没有直接关系。但是为了在上述设置中实现测试的确定性行为，我是否更正
- 通过网络进行通信，在本例中为 lcm，应按照本 lecture 中的建议避免。
- 应该改用连接各个系统的图？
好的。谢谢你的澄清。在单个进程中，时序语义最简单、最清晰。我更喜欢先把这些做对，然后引入 LCM/ROS 只是作为跨多个进程拆分计算的一种手段（为了性能，或者为设备驱动程序使用不同的编译单元，等等）。
您可以将控制器编写为连续时间或离散时间（如 tutorials). In the vast amount of cases, these will be the right semantics. I believe you are imagining a case where you have an occasional event (e.g. "a new object was detected" or "I need to replan") which would often appear as an RPC service call in ROS. We do have provisions for these in Drake (see e.g. "declare forced events" in LeafSystem 中所示），但简单地实现它们通常更清晰，例如一个简单的离散时间系统，检查其导入端口，并且仅在输入端口值发生变化以触发 activity 时才工作。这种方式的开销非常小，语义更简单的好处是可以使用更多工具进行日志分析、规划、控制、验证等
我希望能解决问题。如果您有不适合的特定案例，请告诉我们。
想象一下垃圾箱拣选场景：
- 使用 ManipulationStation 设置模拟。
- RGBA & pointcloud可以通过pub/sub. 通过lcm通道访问
- 使用 RGBA 和点云执行抓取检测。
我想实现抓取检测程序，它会不时被调用一次。这意味着该过程在等待调用时将保持空闲状态，什么也不做。在 ROS 中，我可能会使用 ROS-Service 来实现这一点。我想征求在 Drake 框架中执行此操作的最佳实践建议。
我也考虑了一些设计，但都没有满足我的要求。
- 一个直接的选择是通过 lcm 使用 pub/sub。然而，一个天真的实现最终会在抓取检测中结束，无论是否需要抓取，总是 run/update 在后台。
- 将其实现为 LeafSystem 的子类，类似于 RobotLocomotion/6-881-examples 中所做的。但是，如果我理解正确的话，它最终会检测到总是在后台 run/update。
P.S。这可能与主题没有直接关系。但是为了在上述设置中实现测试的确定性行为，我是否更正
- 通过网络进行通信，在本例中为 lcm，应按照本 lecture 中的建议避免。
- 应该改用连接各个系统的图？
好的。谢谢你的澄清。在单个进程中，时序语义最简单、最清晰。我更喜欢先把这些做对，然后引入 LCM/ROS 只是作为跨多个进程拆分计算的一种手段（为了性能，或者为设备驱动程序使用不同的编译单元，等等）。
您可以将控制器编写为连续时间或离散时间（如 tutorials). In the vast amount of cases, these will be the right semantics. I believe you are imagining a case where you have an occasional event (e.g. "a new object was detected" or "I need to replan") which would often appear as an RPC service call in ROS. We do have provisions for these in Drake (see e.g. "declare forced events" in LeafSystem 中所示），但简单地实现它们通常更清晰，例如一个简单的离散时间系统，检查其导入端口，并且仅在输入端口值发生变化以触发 activity 时才工作。这种方式的开销非常小，语义更简单的好处是可以使用更多工具进行日志分析、规划、控制、验证等
我希望能解决问题。如果您有不适合的特定案例，请告诉我们。