euclidean cluster が不安定

[TakakiNishio]

kinect_second からの点群をクラスタリングにかけるために、 クライアントPCで

$ roslaunch kinect2_bridge kinect2_bridge.launch base_name:=kinect_second

を実行し、

$ roslaunch motoman_euclidean_cluster euclidean_cluster.launch

を実行すると高確率で以下のエラーが発生します。

Failed to find match for field 'x'.
Failed to find match for field 'y'.
Failed to find match for field 'z'.
[pcl::KdTreeFLANN::setInputCloud] Cannot create a KDTree with an empty input cloud!
[pcl::KdTreeFLANN::setInputCloud] Cannot create a KDTree with an empty input cloud!
[ERROR] [1516716918.579003555]: Lookup would require extrapolation into the future.  Requested time 1516716918.508084928 but the latest data is at time 1516716914.150147893, when looking up transform from frame [kinect_second_rgb_optical_frame] to frame [world]

上記のエラーは以前から見られますが、私の知っている解決策は

• 放置（一定時間待つと直る場合と直らない場合がある）
• プログラムの立ち上げ直し
• クライアントPCの再起動
• ntpdate -q ...でマスタPCへの時刻合わせを行う（意味があるのかは不明）

です。
ご指摘や不明な点があればよろしくお願いします。

[Ry0]

最後のエラーはタイプスタンプあたりなので箇条書きの一番最後が怪しいね．
あと平面除去はしっかり効いてる？

[TakakiNishio]

回答ありがとうございます。
時刻合わせを行うと直ることは多いです。
ただ、ほぼ毎回このエラーが出るので、私の立ち上げ方が悪いのかもしれません。

平面除去が効いているかは、どのように確かめれば良いのでしょうか..?

[Ry0]

一番最後のエラーとそれ以外のエラーはまったく別物ではなさそうかな？
PointCloudのトピックに平面除去したものがPublishされてるはずのなので
それを見て

ってかクラスタリングが全くされないってことでいいんよね

[NishidaTakeshiLab]

今、ntpdate して euclidean_cluster.launch を立ち上げ直したところ、プログラムが正常に動作しました。
やはり時間ずれが原因ということですかね．．

トピックを確認したとこと平面除去も効いているようです。
現在はクラスタリング出来ています。

昨日 ntpdate しても直らないことがあったので本 issue を立てたのですが..
夜遅くまで申し訳ありません。

[Ry0]

ntpdateした後反映されるタイミングがよくわからんよね
あるあるやわ
ってかそんなに時間合わせって頻繁にしなくても大丈夫なもんだけど
大丈夫かな．．．

[NishidaTakeshiLab]

最近になって触りはじめたので色々と設定を間違っているかもしれません．．．
とりあえず今動いているので、このまま進めたいと思います。
また何か分かったことがあればこちらに報告させていただきます。

[AriYu]

TFを使っているので時刻が合ってないとエラーが起こる
TFでエラーが起こるとworld座標系に点群が変換されないので変換後の点群は0になる。
点群がないのにも関わらずKDツリーに入れようとしてエラーが起こる。
多分こんな感じだと思います。適当言ってるかもしれないので確認してみて下さい。

[TakakiNishio]

回答ありがとうございます。やはり時間ずれが原因のようですね..
ntpdate しても直らなかった問題は、修正が反映されていない段階で
プログラムを実行したことに起因するということでしょうか。

今動いている状態なので、またここからシステムの再起動などで
どうなるか確認したいと思います。

[RyodoTanaka]

TFの問い合わせ時間を Bounding Box に記録されている時間で問い合わせているのが原因でした．
そのタイミングでworld->対象のBounding BoxまでのTFのツリーを辿れる場合は良いのですが，結果としてはかなりの確率で失敗しているという状態でした．
なので，Time(0)をつかって可能な限り新しいかつ取得可能なTFデータを取得することでとりあえずエラーでスタックすることを回避しました．
が，時間管理の問題はかなりシビヤにやらないといけないので今後対策する必要が有ると思います．
というか，Euclidean Clusterは結果出てくるのが遅すぎなので，そもそものプログラムを修正すべき時期にあると思います．