CMUCam2 Camera Code - Are important parts commented out?

Here’s were Team188 is at in terms of the camera:

  1. Enclosure is built
  2. Mounted on Servo
  3. Assembly mounted on last year’s robot (Blizzard 5) - 36" off the ground
  4. Calibrated for Yellow, Green and Red successfully
  5. Successful “Colour Tracking” for the three calibrated colours through the CMUCam2 Java GUI using DB-9 serial cable (i.e. the camera discriminates the coloured target from the background with a nice tight bounding box, and can successfully return its midpoint coordinates)
  6. Loaded the supplied CMUCam2 rev 3 FRC code onto last year’s robot
  7. Connected the FRC controller to the camera via TTL port and supplied TTL to RS232 adapter
  8. Successful camera initialization
  9. Successful camera tracking and servoing (camera pans to point directly at the coloured target and will follow it if either target or robot is moved - BTW green seems to work better than yellow or red by A LOT)

NOW here’s the problem:

The supplied CMUCam2 code is SUPPOSED to also get the robot to navigate towards the coloured target out of the box.

It doesn’t seem to want to for us.

Open user_routines_DDT.c -> Default_Routine()


if (p1_sw_trig > 0 && tracking > 0) { //If vision active and tracking use camera data
	p1_y = speed_control;	//set forward speed
	p1_x = pan_position;	//set turning rate
	p1_x = 255 - p1_x;		//invert turn direction
// Steering Compensation
		if (p1_x > 135 && p1_x < 225 && steering_comp > 0)
			p1_x = p1_x + steering_comp;
		if (p1_x < 120 && p1_x > steering_comp && steering_comp > 0)
			p1_x = p1_x - steering_comp;
	pwm11 = Limit_Mix(2000 + p1_y + p1_x - 127);
	pwm12 = Limit_Mix(2000 + p1_y - p1_x + 127);
}

Straightforward. Hit the trigger, robot goes. But no go.

First problem: I don’t think speed_control is ever assigned a value. It’s declared in user_routines_DDT.c at the top.


unsigned int speed_control;

And the ONLY place where it shows up is in Default_Routine()


	p1_y = speed_control;	//set forward speed

Please someone let me know if I’m hallucinating, or missing something, because I wouldn’t be too crazy about my robot going full speed backwards.

Second problem: tracking and pan_position are presumably defined by our camera handling routines. They technically ARE, but the entire code portion that does this is COMMENTED OUT?

Open user_routines_fast_DDT.c -> process_vision()


pan_position = 0;
for (i = 0; i <j; i++) { // Begin 'pan_position' conversion loop
	if (i==0) {
		transit_char = char_buffer[begin_x+i]; 						// convert character in one's place
		pan_position = (transit_char - 48) * 100;						// copy to 'pan_position'
	}
	if (i==1) {
		transit_char = char_buffer[begin_x+i];						// convert character in ten's place
		pan_position = pan_position + (transit_char - 48) * 10;			// add to 'pan_position'
	}
	if (i==2 ) {
		transit_char = char_buffer[begin_x+i];						// convert character in hundred's place
		pan_position=pan_position + (transit_char-48);				// add to 'pan_position'
	}
}// End 'pan_position' conversion loop

if (j < 3) {
	pan_position = pan_position / 10;
	j = 0;
}


transit_char = char_buffer[1];										// get trracking flag from camera
if (transit_char > 48)												//Check to see if camera is tracking
	tracking = 1;													// if yes then set 'tracking' flag
else
	tracking = 0;													// if not then clear 'tracking' flag

Okay, it’s THERE, but why is the entire process_vision() function commented out? Is there another handler somewhere in another file I’m missing?

In fact, even the call to process_vision() is commented out in Process_Data_From_Local_IO()


*/
/*********************
**  VISION CONTROL  **
**********************/
/*	int i;
if (p1_sw_trig > 0){
	if(data_rdy==1)
		process_vision();
	}
*/

Also, by simply uncommenting them, we haven’t been able to get it to work. I didn’t think it would anyways.

It could be that I’m simply missing all the REAL camera handlers in another file somewhere, and that all these commented out ones are superfluous. But needless to say, right now I’m CONFUSED, and could use a bit of guidance!

Help!

-SlimBoJones…

I am not exactly sure, but do not forget this:
You CAN NOT use the camera servo outputs to power the angling servos for the camera. If you wish to have the camera move on its own, those outputs must go through the FRC Controller, and the FRC Controller must control the servos.

See Section 5: The Robot (http://www2.usfirst.org/2005comp/Section_5-The_Robot.pdf)

<R53> Custom Circuits may not:
• Interfere with the operation of other robots
• Directly affect any output devices on the robot, such as by providing power directly to a motor, supplying a PWM signal to a speed controller or supplying a control signal to a relay module. (Custom high impedance voltage monitoring or low impedance current monitoring circuitry connected to the robot’s electrical system is acceptable, because the effect on the robot outputs should be inconsequential.)
• Be used for wireless communication, such as sending or receiving a signal to and/or from the alliance station
• Connect to the radio or tether ports on the Robot Controller

Just to help you avoid headaches in the future.

anon89183608!

Thanks for the rules info. Is there already a thread discussion on this? Any idea if a Q&A has been asked/answered for this? AURGH!!! If not, can you start a new thread on this particular rule in the Rules section?

Still need help with my original post though!

-SlimBoJones…

Steve,

Your reading of the rules is impeccable. However, I believe that this is an oversight in the rules. Good catch!

I am sure that FIRST intends for the camera PCB to control the servo.

I suggest that you ask Engineer Dave (or whoever has posting authority on the FIRST Q&A) to post your observation for clarification.

Mike

Roger,

It makes sense that FIRST/IFI would comment out code so that it is safe for people to simply “run” on a robot without fully understanding function.

I would suggest that you implement a piece at a time with appropriate debug printf statements to understand what each part does. Note that some code may require modification by you to be compatible with your system.

As an example, I would insure that the camera is giving good information to your controller before I attempted to let it guide the drive system of your robot.

Mike

Although I agree with you, in this particular case it is a misrepresentation to publish and distribute a document like: “Start_Here-CMUcam2_fe.pdf” that gives absolutely no mention to having to uncomment code.

I would suggest that you implement a piece at a time with appropriate debug printf statements to understand what each part does. Note that some code may require modification by you to be compatible with your system.

As an example, I would insure that the camera is giving good information to your controller before I attempted to let it guide the drive system of your robot.

Mike

We are receiving proper T-packets, with good x/y cam co-ordinates. FIRST/IFI already included a printf debug statement in this regard (from user_routines_DDT.c):


	// Put vision processing here, because we have a good frame!
	printf( "Got T packet %d %d %d %d servo: %d %d\r",cam.x,cam.y,cam.size,cam.conf,cam.pan_servo,cam.tilt_servo );
	if (cam.size > 0 && p1_sw_trig>0)	{			//Check to see if camera is tracking
		tracking = 1;								// if yes then set 'tracking' flag
		pan_position = cam.pan_servo;
	}
	else
		tracking = 0;								// if there is no track, clear the flag
	}

EUREKA!!! THERE IT IS!!! AND IT’S NOT COMMENTED OUT!

Thanks Mike! Your post led me to find the real non-commented out camera handler!!!

**It appears the answer is NO, important parts of the camera code ARE NOT commented out. This SHOULD still work out of the box with little to no code modification **

-SlimBoJones…

P.S. My question has been answered! Moderators may close this thread if they wish.