Resizing Camera View

[BrianR]

I was wondering if it was possible to resize the viewing area of the camera during operation. Would you have to put a physical lens on the camera, or is it possible to have the camera ignore say, the right half of the image that it takes in as input?

If this is possible, it would make it much easier to focus on a single light when you encounter an orientation that presents two lights in your field of view.

[Binome]

i'm pretty sure there is a way to limit the viewing area through software

[JBotAlan]

First off, after looking at our goal for awhile, I don't think you will find a configuration where the CMUcam's field of view covers two lights.

With that out of the way, I think the VW function is what you seek:
VW [ x y x2 y2 ] \r
This command sets the Virtual Window size of the camera. It accepts the x and y Cartesian coordinates of the upper left corner (1,1) followed by the lower right of the window you wish to set. The origin is located at the upper left of the field of view. VW can be called before an image processing command to constrain the field of view. Without arguments it returns to the default full window size of for the current combination of camera type, down-sampling and resolution mode.

You will need to do some research and digging in the camera code to make this work. I know there's a "write to serial port" function in Kevin Watson's code that you could use for this. My brain is so jelly-fied from this week that any pseudocode I wrote for you would be useless...sorry:ahh:

JBot

[Cuog]

If you turn to page 55 in your CMUcam2 manual you will see the command for adjusting the virtual window size.

If you don't have the manual get it from kevin.org/frc

The command is: VW x y x2 y2

those are the corners of the frame, the default(full) size is 1,1,88,143

Edit: curses, JBotAlan beat me to it

[stevethetinker]

I've tried using the VW command while the camera is streaming data (T packets from Track Color), and often it seems to shut the camera down.

What are the rules for sending a command to the camera? Call Camera_Idle first? Wait for an ACK?

I tried adding a state to Kevin's code between STATE_TWO and STATE_THREE, and the first call to Write_Camera_Module_Register times out. (no ACK returned). That's all I did - add a no-action state. (I want to put a Poll Mode command there but that didn't work so I took out the command and its wait for ack, thus adding a no-action state).

[Kevin Watson]

I've tried using the VW command while the camera is streaming data (T packets from Track Color), and often it seems to shut the camera down.

What are the rules for sending a command to the camera? Call Camera_Idle first? Wait for an ACK?

I tried adding a state to Kevin's code between STATE_TWO and STATE_THREE, and the first call to Write_Camera_Module_Register times out. (no ACK returned). That's all I did - add a no-action state. (I want to put a Poll Mode command there but that didn't work so I took out the command and its wait for ack, thus adding a no-action state).Yes, you need to call Camera_Idle( ) before calling Virtual_Window( ), waiting for ACKs after each.

If you want to call Virtual_Window( ) from the initialization function, this is a fragment from some code I'm working on:



case STATE_SIXTEEN:
// initialize the Noise Filter value
Noise_Filter(Camera_Config_Data.NF);
// next state
state = STATE_SEVENTEEN;
// wait for an ACK before transitioning to the next state
wait_for_ack =1;
break;

case STATE_SEVENTEEN:
// set window size
Virtual_Window(60, 100, 100, 239);
// next state
state = STATE_EIGHTEEN;
// wait for an ACK before transitioning to the next state
wait_for_ack =1;
break;

case STATE_EIGHTEEN:
// send the TC or Track Color command
Track_Color(Camera_Config_Data.R_Min,
Camera_Config_Data.R_Max,
Camera_Config_Data.G_Min,
Camera_Config_Data.G_Max,
Camera_Config_Data.B_Min,
Camera_Config_Data.B_Max);
// next state
state = STATE_NINETEEN;
// wait for an ACK before transitioning to the next state
wait_for_ack =1;
break;

case STATE_NINETEEN:
// signal that we're done
return_value =1;
break;



-Kevin

[Mike Mahar]

Yes, you need to call Camera_Idle( ) before calling Virtual_Window( ), waiting for ACKs after each.

-Kevin

Kevin, Are you sure about waiting for the ACK after Camera_Idle()? When I put in a wait there, I never got it. I noticed in you initialization code that you don't wait for an ACK after Camera_Idle(). When I took out the wait for the ACK, things worked a lot better. I did have to wait for an ACK after the Poll Mode funciton and Virtual_Window funciton that I called.

[Kevin Watson]

Kevin, Are you sure about waiting for the ACK after Camera_Idle()? When I put in a wait there, I never got it. I noticed in you initialization code that you don't wait for an ACK after Camera_Idle(). When I took out the wait for the ACK, things worked a lot better. I did have to wait for an ACK after the Poll Mode funciton and Virtual_Window funciton that I called.I could easilly be wrong (especially if you've tested it and it didn't work as I described :rolleyes:). I'll have a look at it tonight after I get home from the day gig.

-Kevin

[Shinigami2057]

The camera does not send an ACK after going into idle mode (which is kind of the point :p). If you send "\r" again (or any other command that does not sleep the camera) it will "wake up" and ACK.

[Kevin Watson]

Just FYI, this is what the CMUcam2 manual has to say about the idle command:

"This command is used to set the camera board into an idle state. Like all other commands, you should receive the acknowledgment string “ACK” or the not acknowledge string “NCK” on failure. After acknowledging the idle command the camera board waits for further commands, which is shown by the ‘:’ prompt. While in this idle state a \r by itself will return an “ACK” followed by \r and : character prompt. This is how you stop the camera while in streaming mode."

-Kevin

[Shinigami2057]

Nevermind then, I stand corrected :) My apologies for the misinformation!

[stevethetinker]

I found the edubot camera code (http://kevin.org/frc/edu_camera.zip), and it loads and cycles OK. But when I turn on the _DEBUG switch in the camera.h file, the debug output shows that camera initialization is timing out on the first CR command (no ACK or NCK back). I made no changes to the code except to turn on _DEBUG. Does anyone have a notion of what is going on? Here is the sequence of characters going out to the camera: 13, R, M, space, 5, \r, <state 1>, \r, <state 2>, <state 3>, C, R, 2, 41 (COMI), 128.

[stevethetinker]

In my above post, I put some notes in the output sequence going to the camera like this: <state n>. Those don't actually go out to the camera. They note where the state information is listed relative to the characters being written.