Closed tsukione closed 2 years ago
I don't yet believe this is an rviz issue. Please analyse your TFs in more detail. If you can pinpoint a specific TF message that's causing the issue, I'm happy to have look.
Maybe it's related to a jump in time? You could play your rosbag with --rate=FACTOR
to slow down publishing.
Carefully monitoring the transform map -> body
reveals that this transform changes orientation from time 1579178476.09 to 1579178476.19, resulting in the observed glitch:
header:
seq: 6427
stamp:
secs: 1579178476
nsecs: 90714185
frame_id: "/map"
child_frame_id: "/body"
transform:
translation:
x: 660.9413619666593
y: -171.05490377591923
z: 0.33
rotation:
x: 0.004361930060409506
y: 0.008665464901892255
z: 0.7051528692946266
w: 0.7089889380023765
header:
seq: 6431
stamp:
secs: 1579178476
nsecs: 190715185
frame_id: "/map"
child_frame_id: "/body"
transform:
translation:
x: 660.9240520694293
y: -170.16853572428226
z: 0.33
rotation:
x: 0.009107668952394725
y: 0.003738851780159613
z: -3.405387255255412e-05
w: 0.9999515339224964
There is a incorrect TF transform in a moment,
It could be reproduced by the rosbag and reproduce.rviz in the zip file
incorrect_tf_transform.zip
I have checked the tf data frame by frame in rosbag, the data seems normal.
Your environment
echo "$LANG $LC_NUMERIC"
: Before reporting a rendering issue, try running RViz withLANG=C rviz
!