0
$\begingroup$

Rosanswers logo

Hello, I'm writing rosrun tf tf_echo fiducial_0 tb3_1/camera_rgb_optical_frame in the command line, and then I get this out:

Failure at 4640.886000000
Exception thrown:"fiducial_0" passed to lookupTransform argument target_frame does not exist. 
The current list of frames is:
Frame tb3_0/base_link exists with parent tb3_0/base_footprint.
Frame tb3_0/camera_link exists with parent tb3_0/base_link.
Frame tb3_0/camera_rgb_frame exists with parent tb3_0/camera_link.
Frame tb3_0/camera_rgb_optical_frame exists with parent tb3_0/camera_rgb_frame.
Frame tb3_0/caster_back_left_link exists with parent tb3_0/base_link.
Frame tb3_0/caster_back_right_link exists with parent tb3_0/base_link.
Frame tb3_0/imu_link exists with parent tb3_0/base_link.
Frame tb3_0/base_scan exists with parent tb3_0/base_link.
Frame tb3_1/base_link exists with parent tb3_1/base_footprint.
Frame tb3_1/base_footprint exists with parent tb3_1/odom.
Frame tb3_1/camera_link exists with parent tb3_1/base_link.
Frame tb3_1/camera_rgb_frame exists with parent tb3_1/camera_link.
Frame tb3_1/camera_rgb_optical_frame exists with parent tb3_1/camera_rgb_frame.
Frame tb3_1/caster_back_left_link exists with parent tb3_1/base_link.
Frame tb3_1/caster_back_right_link exists with parent tb3_1/base_link.
Frame tb3_1/imu_link exists with parent tb3_1/base_link.
Frame tb3_1/base_scan exists with parent tb3_1/base_link.
Frame tb3_1/wheel_left_link exists with parent tb3_1/base_link.
Frame tb3_1/wheel_right_link exists with parent tb3_1/base_link.

Failure at 4640.886000000
Exception thrown:"fiducial_0" passed to lookupTransform argument target_frame does not exist. 
The current list of frames is:
Frame tb3_0/base_link exists with parent tb3_0/base_footprint.
Frame tb3_0/camera_link exists with parent tb3_0/base_link.
Frame tb3_0/camera_rgb_frame exists with parent tb3_0/camera_link.
Frame tb3_0/camera_rgb_optical_frame exists with parent tb3_0/camera_rgb_frame.
Frame tb3_0/caster_back_left_link exists with parent tb3_0/base_link.
Frame tb3_0/caster_back_right_link exists with parent tb3_0/base_link.
Frame tb3_0/imu_link exists with parent tb3_0/base_link.
Frame tb3_0/base_scan exists with parent tb3_0/base_link.
Frame tb3_1/base_link exists with parent tb3_1/base_footprint.
Frame tb3_1/base_footprint exists with parent tb3_1/odom.
Frame tb3_1/camera_link exists with parent tb3_1/base_link.
Frame tb3_1/camera_rgb_frame exists with parent tb3_1/camera_link.
Frame tb3_1/camera_rgb_optical_frame exists with parent tb3_1/camera_rgb_frame.
Frame tb3_1/caster_back_left_link exists with parent tb3_1/base_link.
Frame tb3_1/caster_back_right_link exists with parent tb3_1/base_link.
Frame tb3_1/imu_link exists with parent tb3_1/base_link.
Frame tb3_1/base_scan exists with parent tb3_1/base_link.
Frame tb3_1/wheel_left_link exists with parent tb3_1/base_link.
Frame tb3_1/wheel_right_link exists with parent tb3_1/base_link.

At time 4641.670
- Translation: [-0.133, -0.153, 0.715]
- Rotation: in Quaternion [0.994, -0.005, 0.082, -0.066]
            in RPY (radian) [-3.007, -0.163, -0.020]
            in RPY (degree) [-172.305, -9.325, -1.153]
At time 4642.704
- Translation: [-0.133, -0.153, 0.715]
- Rotation: in Quaternion [0.994, -0.005, 0.082, -0.066]
            in RPY (radian) [-3.007, -0.163, -0.020]
            in RPY (degree) [-172.305, -9.325, -1.153]
At time 4643.656
- Translation: [-0.133, -0.153, 0.715]
- Rotation: in Quaternion [0.994, -0.005, 0.082, -0.066]
            in RPY (radian) [-3.007, -0.163, -0.020]
            in RPY (degree) [-172.304, -9.328, -1.154]
At time 4644.586
- Translation: [-0.021, 0.142, 0.721]
- Rotation: in Quaternion [0.991, -0.003, 0.006, 0.134]
            in RPY (radian) [2.872, -0.012, -0.004]
            in RPY (degree) [164.572, -0.709, -0.218]
At time 4645.623
- Translation: [-0.022, 0.142, 0.721]
- Rotation: in Quaternion [0.991, -0.003, 0.006, 0.134]
            in RPY (radian) [2.872, -0.012, -0.004]
            in RPY (degree) [164.573, -0.709, -0.218]
At time 4646.529
- Translation: [0.125, -0.162, 0.715]
- Rotation: in Quaternion [0.993, 0.004, -0.094, -0.072]
            in RPY (radian) [-2.995, 0.187, 0.021]
            in RPY (degree) [-171.614, 10.711, 1.211]
At time 4647.634
- Translation: [0.125, -0.162, 0.715]
- Rotation: in Quaternion [0.993, 0.004, -0.094, -0.072]
            in RPY (radian) [-2.995, 0.187, 0.021]
            in RPY (degree) [-171.614, 10.711, 1.211]
At time 4648.538
- Translation: [0.118, -0.163, 0.718]
- Rotation: in Quaternion [0.993, 0.004, -0.089, -0.072]
            in RPY (radian) [-2.995, 0.177, 0.021]
            in RPY (degree) [-171.626, 10.121, 1.192]

Wondering why it fails two times first and then starts working again. I've checked some of the other transforms and they work fine from the start. Here is the tf tree: image description


Originally posted by Roshan on ROS Answers with karma: 51 on 2021-10-08

Post score: 0


Original comments

Comment by tryan on 2021-10-08:
The other transforms are static and published on startup, but perhaps it takes some time for aruco_detect to find and publish the transform. Does that not fit with your experience/expectation?

Comment by Roshan on 2021-10-08:
I don't have much experience with this, so I can't really tell. But that does make sense, so thank you. That might be why it doesn't show up when I rostopic echo /tf_static too

Comment by tryan on 2021-10-08:
Happy to help. And yes, I would only expect to see fixed transforms (e.g., base_link -> imu_link) on /tf_static. I will post an answer. If you're satisfied that the problem is resolved, please, mark it as accepted, but feel free to ask for further clarification.

Comment by Roshan on 2021-10-08:
It seems pretty clear now, so static transforms are the transforms that are there from the start, but because the transforms to fiducial isn't static is because it is only there if a marker is detected. One other question I have is about the sudden changes in the translation of the transform, that seems a little weird especially since the robots are standing still

Comment by tryan on 2021-10-08:
I can't speak to the accuracy of the algorithm (maybe +/- 15 cm is expected?), but I suspect it depends on several details, e.g., marker arrangement/number/size, camera calibration/resolution, simulation vs. real robot, etc. I would ask the package maintainers, but you could also try posting a separate question concerning accuracy. You may get an answer here, but if you find a forum more specific to ArUco markers, you may have better luck. Sorry, I can't help more with that one.

$\endgroup$

1 Answer 1

0
$\begingroup$

Rosanswers logo

I'm not very familiar with the aruco_detect package, but because the transform is between an optical frame and a fiducial frame, I assume that it's a transform the node figures out at runtime. As such, there may be a delay before it first publishes the resulting transform, while the node does the necessary calculations. As soon as the transform is available in the tf tree, you should be able to echo it without error.

The reason the other transforms are all available immediately is that they are predefined static transforms and don't require any calculations. The statistics for such transforms look like this:

Average rate: 10000.0
Buffer length: 0.0
Most recent transform: 0.0
Oldest transform: 0.0


Originally posted by tryan with karma: 1421 on 2021-10-08

This answer was ACCEPTED on the original site

Post score: 1


Original comments

Comment by Roshan on 2021-10-08:
Just a question after I checked through the TF tree again. Shouldn't the transforms between odom and base_footprint also have the same problem?

Edit: After testing, it does actually happen for them. Another weird thing is that after trying to run the tf echo several times, it only fails sometimes

Comment by tryan on 2021-10-08:
Good catch. Yes, any transform that isn't static may run into timing issues. The tf2 tutorial on listeners may provide more insight (I recommend all of the tf2 documentation actually), but basically, every listener must fill its internal buffer with transforms. If it tries to query a particular transform before it's in the buffer, the lookup will fail. Depending on the exact timing of when the listener initializes then starts querying vs. when the transform is next published, the transform may not be in the buffer for some amount of time, causing failed lookups at first.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.