What is T_Packet_Data.my ??

[Greg Ross]

Originally Posted by Mike

If there is no blob, it is zero.

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.

[354.FIRST]

thanks for all the help y'all.
Totally saving my butt.
Can you point me to that other thread you mention? I am not finding it.
-354

Originally Posted by GW (Greg) Ross

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.

[Greg Ross]

Originally Posted by 354.FIRST

thanks for all the help y'all.
Totally saving my butt.
Can you point me to that other thread you mention? I am not finding it.
-354

http://www.chiefdelphi.com/forums/sh...897#post448897

[X-Istence]

Originally Posted by GW (Greg) Ross

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.

[Kevin Watson]

Originally Posted by GW (Greg) Ross

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.

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?

-Kevin

[Kevin Watson]

Originally Posted by GW (Greg) Ross

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.

Greg, are you saying that the CMUcam2 will occasionally send a t-packet with a non-zero value for .my when it does *not* have a tracking solution?

-Kevin

[Mike]

Originally Posted by Kevin Watson

Greg, are you saying that the CMUcam2 will occasionally send a t-packet with a non-zero value for .my when it does *not* have a tracking solution?

-Kevin

I don't think he is saying that it sends a t-packet with a non-zero value for .my/.mx but rather that the .my/.mx that is already stored does not change it's value when the image of a blob is lost.

[X-Istence]

Originally Posted by Mike

I don't think he is saying that it sends a t-packet with a non-zero value for .my/.mx but rather that the .my/.mx that is already stored does not change it's value when the image of a blob is lost.

It however does when it gets new information from the camera, so that would make no sense.

[Kevin Watson]

Originally Posted by Mike

I don't think he is saying that it sends a t-packet with a non-zero value for .my/.mx but rather that the .my/.mx that is already stored does not change it's value when the image of a blob is lost.

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.

-Kevin

[Greg Ross]

Originally Posted by Kevin Watson

Greg, are you saying that the CMUcam2 will occasionally send a t-packet with a non-zero value for .my when it does *not* have a tracking solution?

Correct. I believe I saw non-zero "my"s with very low confidence (possibly as low as 0.)

Originally Posted by Kevin Watson

BTW, did Rob Steele know about this?

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.)

[Kevin Watson]

Originally Posted by GW (Greg) Ross

Correct. I believe I saw non-zero "my"s with very low confidence (possibly as low as 0.)

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.)

Okay, I'll update the code to use the .confidence value as a discriminator instead of .my. Thanks for the information.

-Kevin

[Keith Watson]

Originally Posted by GW (Greg) Ross

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.

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.

[Kevin Watson]

Originally Posted by Keith Watson

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.

I'm altering the tracking code to use the t-packet confidence value as a discriminator. Do you have a better idea of what the default value should be for the code?

-Kevin

[Keith Watson]

Originally Posted by Kevin Watson

I'm altering the tracking code to use the t-packet confidence value as a discriminator. Do you have a better idea of what the default value should be for the code?

-Kevin

When we saw values down to 140 with the green light that was with the target light tilted more than 45 degrees away and objects possibly partially blocking the light. But I consider 140 valid. With white lights we saw a maximum of 6. I would consider up to 10 invalid. That leaves a pretty large unknown range. Our programmer chose a level of 100. I think it was Greg who mentioned using 80 or 90.

[Kevin Watson]

Originally Posted by Keith Watson

When we saw values down to 140 with the green light that was with the target light tilted more than 45 degrees away and objects possibly partially blocking the light. But I consider 140 valid. With white lights we saw a maximum of 6. I would consider up to 10 invalid. That leaves a pretty large unknown range. Our programmer chose a level of 100. I think it was Greg who mentioned using 80 or 90.

Keith,

Can you do me a favor? Can you grab this code and test it under the conditions that caused the camera to send the low confidence t-packets? These are the changes I've made so far:

1) All changes to servo position are now done through two functions, which will make it easier for teams to use the CMUcam2 servo outputs if they desire.

2) Fixed bug in search initialization code where temp_pan_servo was initialized to zero instead of Tracking_Config_Data.Pan_Min_PWM.

3) Altered tracking algorithm to use the t-packet confidence value to determine whether the code should track or search. This value can also the changed on-the-fly from the tracking menu.

4) Added Get_Tracking_State() function, which can be used to determine if the camera is on target. New code in Process_Data_From_Master_uP( ) uses this function to turn on the switch3 LED on the operator interface when the camera is on target.


-Kevin