-
Notifications
You must be signed in to change notification settings - Fork 20
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
Different size of the dot pattern #7
Comments
The size actually does not matter anymore (I need to update the docs) as the pattern is found in 2d, and the plane finder rectifies the wrong 3d scale if any. That output you have also only relies on 2d so it's displayed no matter what Your result is really weird as I pointed the camera at my screen with your image and could find the pattern :) (from source or packages). I do not even understand what is being displayed (those two dots). I guess you have the same result when the camera is looking at it straight up ? |
Hmm strange indeed. I get the same result from any camera pose ... OpenCV issue? |
naah, that's pertty standard. But just in case, which OpenCV do you have ? |
I built ecto from source as well, and as ecto doen't depend on any opencv installed, I guess I'm using their version. However, I have OpenCV 2.4.3.2 installed. Btw. running capture with the dot pattern gives me this warning/error.
But the program keeps running anyway. |
I still get the two weird points but after your last commit the dot pattern capture crashes with segfault when the pattern is visible. GDB says:
|
ok, fixed the potential crash. Thx. |
Its the same just without the template input, so the dot patter should be tracked, but still isn't. |
ok, I fixed the crash. If that still does not work, can you please try the samples/dot_poser.py in ecto_opencv ? Thx. |
Can you please send thee full backtrace ? Or at least tell me in which file you have the crash. Thx |
Hm, nope, everything should be up to date. Here comes the backtrace:
But just in case I'll try the capture on another machine. |
ok, other machine:
|
that is really weird. It seems your mask defining the planes is simply empty. The only thing I can think of now is the sensor: what sensor are you using ? We only tested with Asus and Kinect. |
ok, it's weird: cv::Vec3f T_tmp = K*T; |
I am running on 32bit, but with the correct OpenCV version:
|
Further Testing: I printed '
So maybe there is something wrong with cv::Vec3f? Why ever ... |
thx so much for debugging. I know the OpenCV test farm does not have much 32 bit testing these days. |
Actually, I'm not sure how to debug this. I wrote a small test, crunched in the numbers but got only valid results:
I tried a couple constructors/float-double-conversions etc, but erverything produces normal numbers (I used opencv header and libs from groovy of course) |
ok, I really hate this bug :) I had tried to replicate like you to no avail. I tried different compilers, I valgrinded (with memcheck) and everything seems normal ... |
Other suggestion, please dump K and T to a yaml file and maybe we can repeat independently |
Well, I don't know where this comes from, but now I get the following error with any pipeline ...
In rviz the input data looks fine as usual ... any ideas where this is comming from? It seems like no depth image is processed . Running
like most other executables in ecto_image_pipeline as well.
I'm confused ... I'm still on the same code here. Nothing changed except the updates from apt-get ... Maybe the cmake install log is of some help:
|
ok, good (?) news, other people have something similar in totally digferent packages: |
shit ... anything I can do? due to our ros stacks we're still bound to fuerte and 32bit ... If not you can close this issue and I go somewhere crying. |
Some of the samples you mention need fixes but that main bug really is about 32 bit. You seem fairly competent so I am please requesting your help to fix what is not (almost officially) and OpenCV bug for 32 bit. |
talking of competence ... I'm not sure how to convince cmake (in a groovy catkin-workspace) to ignore the groovy opencv package and use the system opencv resp. self-compiled instead ... |
well, you need to look at the cmake variables: just use ccmake or cmake-gui in your build folder and you can change the OpenCV it is using there I think |
btw, I just pushed OpenCV 2.4.5, does that fix anything for you ? |
Where did you push it? |
I pushed 2.4.5 to ROS. It's also on the github website if you want to compile from source. |
How foolish of me to think there was a bug in OpenCV :) I was able to reproduce it and I fixed ecto_opencv, can you please confirm that this does not crash for you anymore ? |
Sorry for the long abstinence, busy times. But yes, runs like a charme with the ros-fuerte stacks! Thanks a lot for the effort. I push the allmighty close-button then :) Where was the bug in the end? |
I was passing a matrix upstream for R and T even when no valid results where found: they contained invalid data that would actually be partly valid sometimes. Now, I send back an empty matrix in such cases, so no more playing with random data. |
I tried to run the object_recognition_capture with the dot pattern. I did not print it to its original size but just chose A3 with automatic scale. When running

rosrun object_recognition_capture capture -o orc_scan.bag
the pattern is not completely recognized:However, two dots, one from the dark and one from the black side, are reprojected.
The wrong pattern size shouldn't affect the pattern recognition, should it? I guess it would just calculate a wrong distance of the pattern.
Anyway, I tried to change the hard coded pattern parameter in fiducial_pose_est.py by multiplying every number concerned with the pattern by 0.5, which didn't improve the recognition.
The text was updated successfully, but these errors were encountered: