通过ROSBridge和下层XBot进行topic订阅和发布

[DinnerHowe]

移动端接收：/speak_done (std_msg/Bool)
pad端接收：/stop_run (std_msg/Bool)
具体的实现方法见test_pub2.py，在test_pub2.py中假设了语言运行的函数是speakCB，计数50次，完成语音说话。
xbot_navigation/Xbot/src/nav_staff/src/test_pub2.py
https://github.com/DinnerHowe/xbot_navigation/blob/master/Xbot/src/nav_staff/src/test_pub2.py

[lazyparser]

Hi，

stop_run 之后，需要考虑恢复到解说词中断的地方么？还是直接可以等pad自己再次识别？

[lazyparser]

另外这里没有看到WP之前说的topic，如何告诉移动底盘开始运动呢？

[DinnerHowe]

/stop_run 是告诉pad说话的
/speak_done是告诉底盘移动的
这个解说词中断的地方，我想的是我这是没发知道那个地方要说哪个以及说的顺序的，我能提供的是一个顺序的停滞动作。但是你知道在哪说哪个，所以在顺序的停滞下，你那边看看能不能顺序的给出来，或者你做个坐标映射和语音编号的映射，然后按顺序调用

[lazyparser]

目前的通信是这样子的：

/speaker_done

• 按照10Hz发布Topic；
• App启动之后默认发布False；
• 当摄像头捕捉到了人脸，并在后台进行了ID识别之后，不管检测出来的是游客还是已知用户，都开始播放解说词，在播放解说词之前，将topic的消息内容变为True；
• 将解说词播放结束，改变topic内容为False；

所以下位机只需要检测/speaker_done从False变为True的改变即可；

[DinnerHowe]

最好不要这么频繁的发布消息，毕竟这个不要求实时性，按给你的demo那样子就行，不然通信量太大，容易出问题，而且如果按你这个通信方式，我得重构代码的架构，我之前给你的是触发式的test_pub2.py那样，不是实时监控式的

[lazyparser]

这个issue先实现 /speaker_done。实现 /stop_run 拆分到了 #9

[lazyparser]

OK 降低到 1 Hz 也是可以的；可能不能只是发布一次，websocket在实际环境中可能没有那么稳定