-
Notifications
You must be signed in to change notification settings - Fork 70
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
Variable number of targets #11
Comments
Another thought about changing the number of targets: I understand that observing the whole image and waiting for more targets isn't efficient. But I could imaging providing a kind of |
have a look at this https://github.com/gestom/CosPhi |
Ok, I did. But I'm not sure what you're suggesting. I actually managed to modify the reset-Service to take the number of targets as a parameter. So I can adjust the detection by calling reset. |
am suggesting cosphi as it did exactly what you need , take the number of targets as a parameter at the beginning of the program and you can change the number of targets in run time and if one or more target is not detected there is no problem with the detection at all + you can detect the orientation and the id of each target if you need |
I am also interested in this problem. I want to be able to observe a variable number of targets (for now I am not interested in identification). @falkoschindler did you reach to do that with the cosphi package? Thanks in advance. |
@fabrizioschiano: I modified whycon's reset method to set a new number of markers. Here are the changes I made: CMakeLists.txt
srv/SetNumberOfTargets.srv
src/ros/whycon_ros.cpp
src/ros/whycon_ros.h
|
Hi thanks for the reply. So now you can observe a variable number of targets, right? What I would like also to know is, at every cycle you the algorithm performs a detection of the possible markers in the scene? When I first looked at whycon I had in mind that it worked like that: I was fearing that, because of this, a variable number of targets algorithm would be always in detection mode (the heaviest one) and therefore it will be too slow for an ODROID card. What do you think about it? Where did you run your software? |
No, I'm not observing a variable number of targets. That would be pretty expensive and not - as described in the Whycon paper - independent of the image size. I just added a way to change the number N while resetting the tracker. It'll restart by searching for the new number of markers in detection mode and continue tracking these N markers as usual. |
As you mentioned, this implementation assumes fixed number of targets. Resetting triggers a global search which is expensive. If you want to add the functionality described above, a patch is welcome. However, please leave original reset service as is for compatibility. |
I just submitted by changes in form of a pull request #13. I hope it helps to realize this new feature, although backward compatibility is not yet considered. |
I think that the system should be more robust. |
Hi,
the main reason whycon works so fast is that once a target is found, the
next frame detection starts in last known position. When this position is
not know, it can, at worst, go through the whole image, which is much
slower. This, together with the fact that it is not possible to uniquely
identify each target, means that in order to get stable results (ie.
pattern 1 is not detected as pattern 2), all targets need to be present and
will be tracked until lost. In other words, reinitialization cannot
guarantee stable IDs.
Thus, reinitialization using a service is possible (with the expected
computational cost). However, the code is not designed for a variable
number of targets. If you were to extend it for that purpose, I would only
be able to accept it if performance is in general the same.
Please test any modifications accordingly and try to maintain the same code
style and layout if you provide a pull-request. I don't really have much
time to modify or test extensively any changes.
…On Mon, Jun 26, 2017 at 2:25 PM, Ridhwan Luthra ***@***.***> wrote:
I think that the system should be more robust.
Eg. I am working on localising a drone with a front facing camera to a
whycon. I am building a similar functionality to
http://wiki.ros.org/aruco_mapping.
Now, in that, I need to be able to detect 1 or more than one marker all
decided dynamically.
Is there a way to do that?
P.S. Once I have built this functionality I plan to submit a pull request.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#11 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAJ3qkCws3g6rVnqshJnMMxOPcjKGIyzks5sH-mmgaJpZM4Ji5Hc>
.
|
I would be really interested to see this functionality. Thanks. |
can you provide the python code for same? |
@Ridhwanluthra did you create this code? If so, are you able to share it? i am trying to do the same thing.. Thank you! |
@antithing Based on the response by @protobits it didn't make sense to go into building that. I instead used aruco. Another approach that I believe should work is a hybrid of whycon and aruco should work if extremely essential. |
Is there any possibility to detect a variable number of targets?
I observe the following behavior: If I specify the number of targets to be, e.g., 4, I get no detection if there are 3 or less targets visible and 4 out of many targets if there are more.
In my application I want to process a set of 1, 2 or 4 targets. If the number was reconfigurable, I could switch between those detection modes without restarting the ROS node. But ideally I'd somehow get all visible targets (up to the maximum number of 4).
Any help is greatly appreciated! :)
The text was updated successfully, but these errors were encountered: