Camera Works Well with the Balls!

[JHale]

Hey all!

For two years we have struggled intensely with the camera and getting it to work, at all.

Last year we found out that the camera's auto gain function didn't account for the light, and thus the light was simply registered as a white box (overexposure cannot be handled per-wavelength.)

This year we wanted a way to know where one of our balls is in order to knock it down during autonomous very accurately without wasting time sending commands from remote.

Because the balls are just lit, and don't glow, they work well with the camera. However, when we turn over control of the camera to the controller (instead of my computer) we were dissappointed to see absolutely no activity (the code stalls). This lead us to realize that Kevin's code does not work well...no offense to him.

We are writing some new code that gives most of the control to the camera, instead of trying to run the servos with the FRC controller. I will be posting an alpha version of the code for tracking the balls soon.

If you want to help out that would be great. On my team I am the only person doing programming, and thus cant give a whole lot of time to the camera. All you need is a good understanding of how the camera communicates with the controller and how to program C.

Thanks all!
-James

[Greg Marra]

I would recommend you look closer at Kevin's code. I wrote my own camera driver in 2005, and the experience was less than pleasant. Kevin has taken care of all sorts of things that I didn't even know existed in 2005.

Give it another shot before you invest dozens and dozens of hours rewriting it from scratch.

[Chris_Elston]

Originally Posted by JHale

However, when we turn over control of the camera to the controller (instead of my computer) we were dissappointed to see absolutely no activity (the code stalls).

I guess I would question whether or not you have loaded and intialized the camera settings?

It's one thing to "teach" the camera the blue ball, but you've also got to record those values into the code so the software can "recall" your taught settings and intialize those values and beginning tracking the ball.

Are you getting any tracking data? Is the "red" LED on in the front of the camera when you present the ball in front of it?

[Uberbots]

last year, you had to set the camera to CMYK mode, and adjust the red, blue, green, and white gains so that the light appeared as a purple smudge on the camera's vision field.

this year you can keep the gains normal and the mode in RGB, but you have to watch out for the fact that there may be multiple blue/red balls in your field of vision, which will throw your tracking algorithm for a loop, and will not point you at the ball at all (probably somewhere in the middle of the overpass)

be careful, though, with your intended code. external electronics are NOT allowed to control motors, and that includes the servos.

[PhilBot]

Originally Posted by JHale

Hey all!

However, when we turn over control of the camera to the controller (instead of my computer) we were dissappointed to see absolutely no activity (the code stalls). This lead us to realize that Kevin's code does not work well...no offense to him.
-James

I suspect that you aren't calling the Camera_Handler() in the Process_Data_From_Master_uP() loop....

But the easiest way to see what's going on is to turn degugging on in the camera.h file.... as per Kevin's comment:

// To view debugging information on the terminal screen, uncomment the
// "#define _DEBUG" line below.
#define _DEBUG

This will show you the process of initializing the camera and reading data. If this doesn't run then the problem is hardware, or how you are calling the code.

[jgannon]

Originally Posted by JHale

We are writing some new code that gives most of the control to the camera, instead of trying to run the servos with the FRC controller.

Are you sure you're satisfying the parts use and electrical rules? You should definitely double-check <R36> and <R62>.

[JHale]

I have followed all of the troubleshooting tips and instructions given by Kevin and IFI. I can confirm all of the initialization on the camera easily, and it does initialize, however tracking is where the majority of the problem is.

At the moment I have some custom code working the camera quite nicely. It can track the red ball (the only one we have) pretty well. The code only works to ensure that the camera is in tracking mode (not just idiling). Tomarrow I hope to add functionality for searching, register changes on the fly, and manual control.

I will post the code sometime next week. The main difference is turning over servo control to the camera, instead of the controller. In collecting output, I had noticed that the camera would tell the controller that it had sufficient confidence to start tracking, however, if the next packet denies this (perhaps the ball has moved and the confidence is slightly decreased) the code restarts.

Thanks all for the suggestions, but I have struggled with this camera for 2 years, and in 2 days I was able to get it working. Hasta!

[Tytus Gerrish]

using the camera on the big balls makes sense. they look the same shape from any direction and they're enormus. you can't miss them. with all the hussle and bussle of 6 robots zipping arround having an auto aim for picking up balls even would be an advantage

[RyanCahoon]

Originally Posted by JHale

The main difference is turning over servo control to the camera, instead of the controller.

As has been stated previously, you can't have the camera control servos, unfortunately.

Originally Posted by JHale

In collecting output, I had noticed that the camera would tell the controller that it had sufficient confidence to start tracking, however, if the next packet denies this (perhaps the ball has moved and the confidence is slightly decreased) the code restarts.

If you're willing to give Kevin's code another, slightly different, go, try the drop-in replacement for tracking.c here. It's a modification I did last year that deals with just the problem you stated by not dropping the camera lock unless it loses the target for several consecutive frames. Success rate was over 80% (I don't have specific numbers at the moment) tracking last year's lighted targets with no recalibration ever needed, even between venues, so give it a try if you want.

--Ryan

[JHale]

Hey all,

The camera is working great when we hand servos to the board (the way the CMU guys made it to work). Newer boards can do this by getting the servo angle that the camera is desiring and then sending that to the appropriate PWM. We however are using an older board that still has the PWM outs.

Cant post the code because it uses Kevin's serial code. Snippits on the way!

Hasta!

[The Lucas]

Originally Posted by JHale

We however are using an older board that still has the PWM outs.

The older camera board is illegal. You have to use RevA of the CMUCam2 board since it is COTS (sold at IFI).