rviz ignoring transforms

asked 2017-03-21 05:24:12 -0500

tompe17
140 ●16 ●22 ●27

updated 2017-03-22 05:10:18 -0500

With the lates update of Kinetic the display of laser scan data in some old bag files stopped working. I get the message

[ERROR] [1490090873.307973855]: Ignoring transform for child_frame_id "uav0/vicon_laser" from authority "unknown_publisher" because of an invalid quaternion in the transform (-0,018510 0,706860 -0,018510 0,706860)

in the terminal where rviz is started. This transform might be generated from a ros2 static transform but it worked before the latest update.

Is the quaternion invalid or is the check here buggy? And it did display properly before so can I disable this new check?

The launch file line generaing the transform that do now work is:

<node  pkg="tf2_ros" type="static_transform_publisher" name="laser_frame_publisher" args="0.12 0 -0.1 -0.01851 0.70686 -0.01851 0.70686 /uav0/vicon /uav0/vicon_laser" />

edit retag flag offensive close merge delete

Comments

You cannot disable the check (what would it do with what it thinks is an invalid quaternion). This would not be in rviz, but rather in tf2 or tf. Do you mean tf2 or ros2? @tfoote that quaternion looks valid, do you know of recent changes that might affect this?

William ( 2017-03-21 13:16:07 -0500 )edit

add a comment

2 Answers

Sort by » oldest newest most voted

answered 2017-03-21 17:34:16 -0500

tfoote

58457 ●128 ●550 ●526 http://www.ros.org/

We recently added this assertion in #196 Plugging the values into the calculator the quaternion appears to be just outside the epsilon threshold of 10e-6.

0.018510^2 + 0.706860^2 + 0.018510^2 + 0.706860^2 = 0.9999873594

That's a larger error than I would expect for a quaternion based on floating point calculation errors. There's currently not a way to adjust or change this check.

edit flag offensive delete link

Comments

These numbers are computed by a program (Python or C++) and then printed. Then the numbers are taken from the printout to be arguments to the static transform program. So of course the whole double precision is not preserved because of truncation in the printing.

tompe17 ( 2017-03-21 18:10:04 -0500 )edit

I think it is unreasonable to expect the double precision to be kept since this small error will not influence the measurments at all from the laser. I cannot be the only person that have used a program to compute the quaternion for a simple rotation and put it into a static transform.

tompe17 ( 2017-03-21 18:12:24 -0500 )edit

OK, saw you said floating point precision but I think my argument is still valid.

tompe17 ( 2017-03-21 18:13:30 -0500 )edit

Can you post a bag file with the raw float values? Or do the calculations yourself and show them here, avoiding the truncation of precision due to printing? Ultimately, I think you'll want to raise this on the issue tracker of tf: https://github.com/ros/geometry2/pull...

William ( 2017-03-21 18:52:36 -0500 )edit

I am not sure how I got the values I have above in the launch file line that starts the static transform publisher. One theory is that I computed it from the angles -90, -87, -90 and then just used 5 of the decimals that was printed. In Python more decimals are printed. Maybe C++ gives 5 decimals.

tompe17 ( 2017-03-22 04:56:50 -0500 )edit

Here is the Python calculation with the order messed up somewhat:

HPR: -90.0 -87.0 -90.0
[-0.70686447  0.0185099  -0.70686447  0.0185099 ]

tompe17 ( 2017-03-22 04:59:24 -0500 )edit

I added a comment on https://github.com/ros/geometry2/pull...

tompe17 ( 2017-03-22 05:05:53 -0500 )edit

I tried to publish TF from IMU via Arduino, here is the data: Q = 0.001404 -0.001587 -0.903198 0.42926 printed from Arduino 2560. and resulting the epsilon 3.52645890000502e-5 which still larger then 10e-6 and RVIZ confirms error. How do we solve this issue, otherwise Arduino devices are unusable