-
Notifications
You must be signed in to change notification settings - Fork 135
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fiducial pose jumps when in image center #223
Comments
@ivan140 That is very weird, we haven't seen that behavior before. Could you upload a bag file (with the image data) so that we could look a little closer? Thanks for reporting! |
@rohbotics yes sure, here's a bagfile: The included topics are TF, pylon-camera-node images and the fiducials. For some reasons the marker is published tilted, with a rotation around cameras X axis. Maybe this is the reason for the jumps. |
Hello ivan140. We have only published a 'general solution' for ceiling nav so far and there was discovered an issue very similar to what you report in some lab tests about 6 months back as well as in some testing. I cannot say it was your exact issue but it sounds in general very similar to what you are reporting. At that time it was decided to look into ways to minimize the sort of effect you are seeing by attempting to offer less general solutions that may meet many customers needs. I would like to ask you about your application.
Thank you, |
Hello @mjstn , To 2: the robot is driving on a flat surface so the distance to the marker should be the same within +-2mm. In your code you are using OpenCV's solvePnP function to estimate the 3D pose of the marker. My guess would be that for a specific 4 points input it generates a non-unique solution. As a possible solution for cases where the z-distance to the marker is known and remains the same, maybe the solvePnP could be omitted and specified by a z_dist parameter. However, this is just one possible way of handling it. |
Hello ivan140, What you are discussing is actually an extremely common fiducial recognition situation (AKA Amazon most likely). I absolutely am very curious into this effect as it may apply to other modes we do have customers using. Yes I agree we likely have a case of a non-unique solution generates a flip or some trig passes through an undefined point and comes out 180 deg off in it's pose after that. This is then in fact NOT the case I had seen. I had made a test where i rotated a fiducial on a pivot and noted cases where a jump happens. Not what you are reporting. Also I hinted at a mode we are working on but from your answer it would not apply to your situation. This is a good input and we very much thank you for your suggested solution. Because of my timezone I will be signing off now but again, thanks for this entry. |
@ivan140 a quick question: are you using aruco_detect only, or fiducial_slam as well? I am going to take a look at your bag file, this might be something involving angle->quaternion conversion. Thanks for sending the bag file btw. |
@rohbotics I'm using the whole fiducials package. The only difference is, that I set the rosparam for read_only_map to true, so that the predefined values in the map do not change. This way I am able to detect the camera (robot) pose even with a single fiducial. |
I can reproduce the same error on the given bag file, but when i change the input image inside
I manage to get an output without the jumps. Since OpenCV's solvePnP inside |
@JanezCim on my robot I'm using a fisheye cam and I'm not sure, whether solvePnP can interpret it's camera and distortion matrices correctly. Also, but it's only my opinion, it seems that the rectify libraries on ROS already do the undistortion work, so having an other undistortion action could lead to weird results. However, also as a reaction to @mjstn : I added a package named qr_detect to your library which implements the zxing library which supports qr and many other fiducials. There's a small constraint of having a constant z distance to the fiducial (floor, ceiling), but except for this the library is a lot faster than the aruco_detect module and can reach approx camera FPS - 5 FPS. If you're interested I can open a push request. |
@ivan140 Yes, I agree, I think undistorting an already undistorted image is not good. So then if you want to use the already undistorted image image_rect, then you also need to pass the proper camera intrinsics params (that are not for fisheye camera). I would try to do that by creating a new camera_info topic with params for the undistorted image and remapping the launch fille to it. |
@ivan140 Did you solve this then? |
@JanezCim kind of. As I wrote in the previous comment I added a package without usage of solvePnP and set the z distance to a constant value. If you say, that when using the image_raw topic the jumps dissapeared from my perspective the issue is solved. |
oh, alright, closing the issue then |
Hi,
I'm using your library for navigation with on the floor attached markers. It works really well, except for one case:
When the fiducial is in the image center it tends to jump and rotate around x-axis for ~180°.
I'm using dictionary 16 with a 0.048 fiducial length. Here are my launch files for both, aruco_detect and fiducial_slam and the map:
aruco_detect.txt
fiducial_slam.txt
map.txt
Here's how it looks like with a slow moving robot:
And also while standing at this special spot:
I'm using a fisheye camera which I calibrated with camera_calibration, here's my calibration yaml file:
camera_calibration.txt
Did you ever experience a similar behavior? If so, how you solved it?
I can also upload a bag file, if needed.
Thank you in advance for any help.
The text was updated successfully, but these errors were encountered: