Post

ROS 2のQoS (Quality of Service) を試す (2)

先日のROS 2のQoS (Quality of Service) を試す (1)の続きです。

本日は、以下に従って、実際にこのQoSの効果を検証するデモを動かしてみます。

https://github.com/ros2/ros2/wiki/Quality-Of-Service

demos/image_tools

http://ros.youtalk.jp/post/161037507746/ros2-install

に従って、ROS 2をインストール済みの方は、すでにcam2imageshowimageコマンド(ノード)が存在するはずです。

cam2image

カメラ画像(もしくはダミー画像)をimageトピックとしてPublishします。

$ cam2image -h
Usage:
 -h: This message.
 -r: Reliability QoS setting:
    0 - best effort
    1 - reliable (default)
 -d: Queue depth. 10 (default)
 -f: Publish frequency in Hz. 30 (default)
 -k: History QoS setting:
    0 - only keep last sample
    1 - keep all the samples (default)
 -s: Camera stream:
    0 - Do not show the camera stream
    1 - Show the camera stream
 -x WIDTH and -y HEIGHT. Resolution.
    Please type v4l2-ctl --list-formats-ext
    to obtain a list of valid values.
 -b: produce images of burgers rather than connecting to a camera

showimage

imageトピックをSubscribeして、その画像をウィンドウに表示します。

$ showimage -h
Usage:
 -h: This message.
 -r: Reliability QoS setting:
    0 - best effort
    1 - reliable (default)
 -d: Queue depth. 10 (default)
 -f: Publish frequency in Hz. 30 (default)
 -k: History QoS setting:
    0 - only keep last sample
    1 - keep all the samples (default)
 -s: Camera stream:
    0 - Do not show the camera stream
    1 - Show the camera stream

QoSの効果検証

それぞれのコマンドには、QoSを制御するオプションがあり、それらを変更することで、QoSの効果を見ることができます。

動画中では、まず始めにping localhostを実行して、パケットロスがないことを確認しています。 次に、cam2image, showimageを実行します。


最初のshowimage実行では、QoSのRelialbilityオプションがReliableの状態です。 ネットワークにパケットロスがない状況にもかかわらず、かなりSubscribeが詰まってしまう原因はよくわかっていません。 しかし、ReliabilityオプションをBest effortに変更すると、詰まることなくSubscribeできていることがわかります。

次に、tc qdiscコマンドを使って、擬似的にパケットロスを発生させます。 パケットロスが発生すると、確かにping localhostが通りづらくなりますが、ROS 2の通信自体は、上記と同様に詰まることなくSubscribeできています。

パケットロスを90%にしてもSubscribeに影響が見えないため、tc qdiscのパケットロスはROS 2のUDP通信には効果がない可能性もありますが、TCP通信を使うROSでは、通信は困難でしょう(ROSの roscppの場合には、ROSUDPを使うこともできますが)。 UNIXコマンドに造詣が深いわけではないため、tcコマンドの使い方が間違っているかもしれません。検索しても、わかりませんでした。もしUDPパケットロスの正しい発生方法がお分かりの方はコメントいただけると嬉しいです。

本実験では、Depthオプションを変えたりもしましたが、効果はありませんでした。 今回はウィンドウ表示しているだけで計算負荷がなく、キューに溜まる前にSubscriberのコールバックが終わるためだと思われます。

パケットロスの疑似実験に関しては、一抹の疑問も残りますが、確かにBest effortの効果が絶大であることがわかりました。 これから勉強していく過程で、Depthオプション、Durabilityオプションの効果に関しても、検証していこうと思います。

This post is licensed under CC BY 4.0 by the author.

Comments powered by Disqus.