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.
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:
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:
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, 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.
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.
[LEFT]Just FYI, this is what the CMUcam2 manual has to say about the idle command:[/LEFT]
[LEFT]“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.”[/LEFT]
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.
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.