T_Packet_Data.mx vs PAN_SERVO

[Roger]

After scratching our collective heads over getting our turret to point AT the light instead of 20-degrees or so off, we dug into code with some printf's, and searched here to find some sort of answer. We have been using the .mx number for a pan angle, but in Kevin's code where the camera reports out the T_Packet_Data stuff, we find that it's using PAN_SERVO for the number (and converting it to degrees). There was also this tidbit from "Moving robot while tracking with camera questions..." (which I think I can manage to show at http://www.chiefdelphi.com/forums/sh...ad.php?t=42993 -- yes! I did it!) with this answer:

The tracking code automatically moves the servos to get the target in the center of the camera's field of view. The variables that the camera gives you are T_Packet_Data.mx, T_Packet_Data.my, T_Packet_Data.x1, T_Packet_Data.x2, T_Packet_Data.y1, T_Packet_Data.y2, T_Packet_Data.pixels, T_Packet_Data.confidence. mx and my are the coordinates of the center mass of the target. x1, y1, x2, and y2 are the coordinates for the bounding rectangle of the target. pixels is the blob size, and confidence relates to how close the actual target color is to the pre-programmed target color. The servo positions are accessed via PWM. You can use the constants PAN_SERVO and TILT_SERVO to get the positions.

Once we used PAN_SERVO, the skies brightened, the clouds parted, angels sang, and most importantly the camera and the turret both agree where the green light should be. Say it's ain't so, Kevin, that all this time I should use PAN_SERVO instead of T_Packet_Data.mx to find the pan angle!

For the record, we are using the Bells and Whistles version of camera of Feb 20th.

Roger.
who somehow managed to code urls, quoting and bolding for the first time! Better than them angels singing!

[Greg Marra]

Yea, the way Kevin's code behaves is it centers the camera dead onto the vision target. Therefore, the .mx should always be about dead-center (or half of 119). The PAN_SERVO gets adjusted to get the .mx to center. That's why you originally had it backwards.

If you find it's still slightly off center (maybe your camera is mounted crooked), you can tweak the #DEFINEs that set the default center for things in camera.h and tracking.h

[Roger]

Thanks, Greg. But of course the camera guy _says_ the camera isn't mounted crooked, but we all know better. We got the code working (again!) but this one was our #1 problem. Now all we need is a robot to test it out on!

Roger.

[Denz]

When I had centering problems, I just played around with the centre pixel values. I dunno if it was the best solution, but it worked pretty well ! I thought that was the problem for us when the camera was looking about 10 degrees off from the light.

Ah, sorry I didn't see you were talking about your turret, not your camera. Well, maybe it might help others, so I will leave it here. Our camera wasn't centered on the green light. It was strange.

[Kevin Watson]

Originally Posted by Roger

Once we used PAN_SERVO, the skies brightened, the clouds parted, angels sang, and most importantly the camera and the turret both agree where the green light should be. Say it's ain't so, Kevin, that all this time I should use PAN_SERVO instead of T_Packet_Data.mx to find the pan angle!

Well, I'm glad the software Gods are happy, but I don't think anyone here told you to use the .mx value to calculate the pan angle. Using the commanded pan and tilt servo PWM values to derive the heading and range have been discussed here many, many times. BTW, this is the very first parapraph of the tracking_readme.txt file:

The source code in tracking.c/.h contains software to track a colored game object, keeping the center of the tracked object in the center of the camera's image using two servos that drive a pan/tilt platform. When the center of the colored object is centered on the camera's imager, you can use the current commanded pan and tilt PWM values to calculate a heading and range to the colored object.

You did read the documentation, didn't you <grin>.

-Kevin

[Roger]

Kevin, I thought I read the documentation, but the doctor said to stick to the caffene-free Mt. Dew, so it must been forgotten.

I think I misunderstood the T packet .mx description (sorry, don't know from where; I just pulled page 57 out for reference): "The middle of mass x value". I guess I placed too much faith that the T packet reveals all.

And I'm not too worried about the software Gods being happy, I have to answer to a higher authority: the teacher in charge of our robotics club!

Denz, our turret shooter rotates, and the camera sits on top of the shooter, so lined up with the centerline of the shooter the camera should be locked on target. Camera too far off target, the turret turns back to target. Unfortunately, camera and turret were way off from each other, not a few degrees, but 10 or more; not a calibration issue. The group in charge of the camera still has calibration to do, but that waits until we have the robot again in Boston.

Roger.