Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Three changes:
(-length/2, 0, height/2)
. The mistake was that we are not applying this transform inside the vehicle's frame (child_scene_node
), but we are setting this node. So we need to apply its rotation to the transformation.UTM_32N
and have thus huge numbers inside the position fields. As RVIZ internally renders stuff using OGRE, which (by default) only uses single precision floats, these tend to flicker a lot due to rounding errors. If the UTM frame is our fixed frame, there's nothing we can do about this (except from building OGRE from source with double precision by settingOGRE_DOUBLE_PRECISION
inOgreConfig.h
to1
, but this would then require to build RVIZ from source, which we might want to do in future, but not in this MR). But if the fixed frame is amap
frame somewhere near the ETSI messages, we can first compute all the transformations in tf, which uses double precision, and then give the resulting (small) numbers to OGRE w/o loss of precision.(Minor change: If sim time is used, but the time source (e.g. rosbag) sends first a CAM and then a clock message, the first CAM is now discarded by checking for
current_time==0
)Screenshot showing the old plugin: (CAM in blue vs ground truth position in red)
and with this fix: