Camera code does not recognize target

[Lucie365]

The VisionDemo code seems to give us good video on the dashboard but when we ask it to find the target (which we have put in plain sight) it is not very good at it. The majority of the time it says there are no valid targets although some times it will find it. We thought this might be a lighting issue and tried changing the brightness but this did not seem to help. Are there other parameters we need to modify?

[Joe Ross]

Have you reviewed the FRC Vision Whitepaper?

[Greg McKaskle]

If you don't get the hang of it, post images and I can suggest what the problem may be. BTW, the default dashboard saves images from the camera into the documents directory.

Greg McKaskle

[Lucie365]

Thanks for the suggestions. I looked up the Whitepaper and will try some variations. Although I had a little time last night I did not get very far and it will be a few days before I again have a set up where I can play with the camera. I also looked at the LabView code to see how it differed and noticed they were using a different compression and brightness (and possibly minimum line length).

We did notice that when the target analysis drew a purple display circle around the target that the normalized score was too low to be considered a target. So if we lowered the minimum score we could of course get it to detect the target, but I doubt that is the best way to go since that would likely find extraneous things too. I think we were probably about 10 to 12 feet away from the target and we may get better results in general when we are farther away. Again we still have a lot of things to check out.

I will post again when I have some more information. But if anyone else has been playing with this issue it would be great to know what they found to work best.

[Zme]

it may just be our lighting but i increase the minimum match score significantly, then again, we also work in what used to be a school so there are a lot of white lockers with black knobs around and we weren't picking any up so

anyway: try setting up methods to modify the values of the target detection so that you don't have to rebuild, undeploy, download, and reboot, just set up a few buttons to change things around and away you go,


good luck with it,

[Lucie365]

Thanks again for the suggestions. I have tried changing some of the settings and found a somewhat better match for our lighting (lowered compression to 10 and raised brightness to 25). It seemed like lowering compression does affect the video response time making it lag more, so I am not sure I want to go to the setting of 5 which labView uses.

There is still a problem, however, in the near target region where the target is not consistently recognized. I believe the ellipse routine is finding the target circle but the overall score value is too low to be recognized as a target. I plan to do some more testing by printing out the radii and score values to see what is happening but I believe the circle may be slightly distorted such that it significantly lowers the raw score enough to keep it from being detected as a target.

We also have issues of a low ceiling causing the lights to be in view at long distances. I noticed that was discussed in another thread and the suggestion was to use automatic white balance. I will try that as I have currently been using flixed fluorescent 1.

We did try to get the stored images from the classmate but could never find them so please give us more info on where they are located.

[Greg McKaskle]

The stored images should be placed into the Documents directory and named 1.jpg through 59.jpg. The default is to same one image per second and retain the image for sixty seconds before overwriting.

The sample images will help determine it the low scores are due to a glare problem or a distortion problem.

Greg McKaskle

[Lucie365]

Having spent a good bit of time trying to get good target detection, I have found that there seems to be a problem with the C++ code. In the target.cpp file the sort function does not seem to actually sort the targets. So if the real target happens to be first on the list the program will appear successful but otherwise the program will either find something that is not the real target or not find any valid targets.

Another team mentor looked up information about the sort function and thinks the function is looking for a boolean comparison rather than a 1 or -1 integer. I have not had a chance to try changing to a boolean comparison but expect that will likely fix the problem.

[mikets]

Are you referring to this function in target.cpp? It looks fine to me.

/**
 * Compare two targets.
 * Compare the score of two targets for the sort function in C++.
 * @param t1 the first Target
 * @param t2 the second Target
 * @returns (1, 0, or -1) for the scores of t1 > t2, t1 == t2, and t1 < t2
 */
int compareTargets(Target t1, Target t2)
{
        if (t1.m_score > t2.m_score) return 1;
        if (t1.m_score < t2.m_score) return -1;
        return 0;
}

[Lucie365]

I tried changing the compareTargets function to boolean as follows:

bool compareTargets(Target t1, Target t2) {
return (t1.m_score > t2.m_score)
}

This solved the problem. Apparently the sort function is looking for a true/false rather than -1/0/1. Both -1 and 1 were considered true (only 0 is considered false) so no sorting was actually being done.

[Mr. Lim]

Thanks! Hopefully this will resolve of the strange behaviour we were seeing when smaller, seemingly lower quality targets were being identified as the primary target! Our robot seems to like to track random circular objects in the room =).

[Lucie365]

Oops...there should be a ";" at the end of the "return" line.

[mikets]

Originally Posted by Lucie365

I tried changing the compareTargets function to boolean as follows:

bool compareTargets(Target t1, Target t2) {
return (t1.m_score > t2.m_score)
}

This solved the problem. Apparently the sort function is looking for a true/false rather than -1/0/1. Both -1 and 1 were considered true (only 0 is considered false) so no sorting was actually being done.

You are right. I don't know about WindRiver C++ but apparently the standard Microsoft C++ sort function is expecting a bool compare function as well. I didn't realize this either. Long time ago in C, I believe the sort function in C runtime expects a compare function to return +1, 0 or -1. Apparently, C++ expects bool. Good catch.

http://msdn.microsoft.com/en-us/libr...h1(VS.71).aspx

[Mr. Lim]

I tried deciphering the headers of <algorithm> as implemented in the WindRiver libraries, but I still can't 100% put this issue to bed. Can anyone else with more intricate knowledge of <algorithm> as implemented in WindRiver c++ comment on whether the sorting predicate expects a bool or -1,0,1 return?

[mikets]

In the old days with C, the sorting algorithm did use a compare function that returns 0, -1 or 1. Apparently, in C++, it is expecting a bool return. I don't know for sure for Wind River C++ but I checked with the Microsoft Visual C++ and it does say the compare function is expected to return bool. I did change the compare function to return bool and it is much more reliable now.

http://msdn.microsoft.com/en-us/libr...h1(VS.71).aspx

_Comp
User-defined predicate function object that defines the comparison criterion to be satisfied by successive elements in the ordering. A binary predicate takes two arguments and returns true when satisfied and false when not satisfied.