Variable number of targets
Opened this issue · 16 comments
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! :)
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 ~/reset
service that takes the new number of expected targets. Since it's reinitializing anyway, it shouldn't cost extra to change this parameter.
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
+ add_service_files(
+ FILES
+ SetNumberOfTargets.srv
+ )
+
generate_messages(
- DEPENDENCIES geometry_msgs
+ DEPENDENCIES geometry_msgs std_msgs
)
srv/SetNumberOfTargets.srv
int64 number
---
src/ros/whycon_ros.cpp
+#include "whycon/SetNumberOfTargets.h"
[...]
-bool whycon::WhyConROS::reset(std_srvs::Empty::Request& request, std_srvs::Empty::Response& response)
+bool whycon::WhyConROS::reset(whycon::SetNumberOfTargets::Request& request, whycon::SetNumberOfTargets::Response& response)
{
should_reset = true;
+ targets = (int)request.number;
+ system = 0;
return true;
}
src/ros/whycon_ros.h
-#include <std_srvs/Empty.h>
+#include "whycon/SetNumberOfTargets.h"
[...]
- bool reset(std_srvs::Empty::Request& request, std_srvs::Empty::Response& response);
+ bool reset(whycon::SetNumberOfTargets::Request& request, whycon::SetNumberOfTargets::Response& response);
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:
the user sets the number of markers N he/she wants to track. The algorithm tries to find them all in the image plane. If it finds them ALL it starts tracking them. If it finds only a number < N, it does not results in any tracking.
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.
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?
@v01d
P.S. Once I have built this functionality I plan to submit a pull request.
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.