Open CesMak opened 6 years ago
Hi, @CesMak , We found out that the orientation issue is caused due to a rotation matrix described in aruco_ros_utils.cpp see these code lines. You could modify the rotate_to_ros cv::Mat object and use it as an identity matrix to undo the rotation. (Actually not perform a rotation at all). So your TF data will be the same as the one found by ARuco.
If you change this take into account that the simple_double.cpp has to be modified too, in order to avoid the same issue (this only affects the simple_double.cpp file). So you will have to change this line to mDetector.detect(inImage, markers, camParam, marker_size,false);
since the default value of setYPerpendicular
is set to true in the .h file.
I have the same question about that. So witch axis is right ? Displayed in /aruco_single/result OR displayed in rviz ?
Hi, @CesMak , We found out that the orientation issue is caused due to a rotation matrix described in aruco_ros_utils.cpp see these code lines. You could modify the rotate_to_ros cv::Mat object and use it as an identity matrix to undo the rotation. (Actually not perform a rotation at all). So your TF data will be the same as the one found by ARuco.
If you change this take into account that the simple_double.cpp has to be modified too, in order to avoid the same issue (this only affects the simple_double.cpp file). So you will have to change this line to
mDetector.detect(inImage, markers, camParam, marker_size,false);
since the default value ofsetYPerpendicular
is set to true in the .h file.
I have the same question about that and still don't understand by your reply. So witch axis are right ? Displayed in /aruco_single/result OR displayed in rviz ? Is the TF data right ? Or i should do things as you say then the TF data will be right? thank you
You can also test with the ARuco 3.0.4 branch: https://github.com/pal-robotics/aruco_ros/tree/aruco-3.0.4
I tried to adapt the package conventions to the library convention. The problem is that if we merged this, a lot of code that relies on the orientation would stop working as expected.
@nevermore0127 Answering your questions,
which axis are right?
The Z axis (the blue one) must be "going out" of the ARuco tag.
Displayed in /aruco_single/result OR displayed in rviz ?
So following the ARuco convention, the /aruco_single/result has the correct orientation. Notice that this not affect translation at all.
Is the TF data right ?
As I said above, the orientation issue doesn't affect the pose estimation. So, yes the TF data is right the only difference is that it has an additional rotation. So in Rviz you see the y-axis pointing out of the tag.
Or i should do things as you say then the TF data will be right?
Is not necessary it is just for convention, according to your needs you may need a different orientation. Or you can publish a static transform with a new rotation. (this is is the simplest solution).
Notice that the TF data is only correct if your camera is correctly calibrated.
If I am not clear enough, please let me know.
@nevermore0127 Answering your questions,
which axis are right?
The Z axis (the blue one) must be "going out" of the ARuco tag.
Displayed in /aruco_single/result OR displayed in rviz ?
So following the ARuco convention the /aruco_single/result has the correct orientation. Notice that this not affect translation at all.
Is the TF data right ?
As I said above, the orientation issue doesn't affect the pose estimation. So, yes the TF data is right the only difference is that it has and additional rotation. So in Rviz you see the y-axis pointing out of the tag.
Or i should do things as you say then the TF data will be right?
Is not necessary it is just for convention, according to your needs you may need a different orientation. Or you can publish a static transform with a new rotation. (this is is the simpliest solution).
Notice that the TF data is only correct if your camera is correctly calibrated.
If I am not clear enough, please let me know.
Thanks,clear about that.
Hi, I also found it is a bit confusing the TF axis direction is different from the detection result. I made a PR for this problem.
@nevermore0127 Answering your questions,
which axis are right?
The Z axis (the blue one) must be "going out" of the ARuco tag.
Displayed in /aruco_single/result OR displayed in rviz ?
So following the ARuco convention the /aruco_single/result has the correct orientation. Notice that this not affect translation at all.
Is the TF data right ?
As I said above, the orientation issue doesn't affect the pose estimation. So, yes the TF data is right the only difference is that it has and additional rotation. So in Rviz you see the y-axis pointing out of the tag.
@ctaipuj To make it more clear, if we want to use tf to transform a vector from marker frame to camera frame, we have to use the frame in Rviz. For example, I specify the four corners in the marker frame, [[-0.5, 0, -0.5], [-0.5, 0, 0.5], [0.5, 0, -0.5], [0.5, 0, 0.5]], then use the tf to transform it to camera frame and get a correct result. if I use the frame indicated by the result image, it is wrong.
by the way, how can I directly get the corner position?
Hey there,
I just wonder the following:
In the picture it looks like the y axis (green) is going out of the red plate but actually this should be the blue z - axis or??
does that mean the marker axis are displayed wrong?!
This is my code:
Just tested the same thing again with this pack: https://github.com/joselusl/aruco_eye
and got a whole different output picture which seems to be right:![screenshot - 05292018 - 01 38 41 pm](https://user-images.githubusercontent.com/20240718/40656787-c93081f6-6345-11e8-95a5-72f9c57e2edb.png)
so I now guess that with this lib here the axes are just drawn wrong in the result pic!
Think I know my error I just should make the
to NONE not to LINES .....
Anyway does anyone has a description of the corner_refinement parameter?