This is the y axis location of the “blob” (the green target) on the cameras view. If there is no blob, it is zero. Theres no specific variable saying if something is in view, but this works just as well.
That’s what I thought too, but in debugging, it looked to me like mx and my DO NOT get cleared when the target is lost. As I noted in another thread, I changed the if(T_Packet_Data.my == 0) tests in tracking.c to if(T_Packet_Data.confidence <= 1) to make the tracking more reliable.
Ehm, where did you get that from? They get cleared when there is new data from the camera, and if the data from the camera contains a y that does not exist, it will be set to 0, as in it can not find it.
That is at least what I got from the code, and the fact that each time the slow loop is run data is retrieved from the camera.
Seriously? I’ve never seen it do that, but I’ll look into it. I’m working on an updated tracking.c and I’ll incorporate the fix(s) when I understand the problem better. BTW, did Rob Steele know about this?
After reading what Greg found in the other thread, Saturday our programmer changed the terminal routine to dump out mx, my, and confidence and we ran tests. We saw non-zero mx, my values with confidence up to 6 or so with the target outside the camera’s field of view. When the target is in the field of view the confidence was as low as 140 but was mostly well over 200.
The room the tests were run in had the camera on a 3’ table, rows of white flourescent lights were 8’-9’ up, and the target was at 3’. We determined the camera was picking up the white lights and putting those in the mx, my values. When we put the target on the floor and limited the tilt up angle the camera no longer picked up the white lights.
Our programmer changed the code to use confidence and it worked perfectly even with white lights in the field of view.
No. Looking at mx, my, or even confidence does not mean the target is centered. Mx and my are undocumented but they are the target centroid in pixels in the sensor grid of IMAGE_WIDTH pixels by IMAGE_HEIGHT pixels which Mike reported. The tracking code which has modes of searching, tracking, and locked is separate. But the default tracking code does not make these modes available for use elseswhere. I modified our tracking code to make these available.
This isn’t possible. The .mx value is only tested when the camera has sent a new t-packet. From what Greg and Keith are saying, it seems as though the camera does spit-out funky t-packets under weird lighting conditions.
Correct. I believe I saw non-zero "my"s with very low confidence (possibly as low as 0.)
I’m not sure if Rob was around when I made the discovery.
What Keith reported corresponds very closely to my experience, although I didn’t attempt controlled experiments. I just noticed that sometimes the camera locked on to a spot well away from the target, and noted that the confidence was zero (or so.)