Fix for CMU cam initalization code 131 error.

[Dave Flowerday]

Originally Posted by Don Reid

After writing my own PC program to work with the CMUCam, I realized that part of the problem in the robot is that reseting the RC doesn't directly reset the camera. It expects the code to reset the camera over the serial link, but if the camera is in an odd mode (or even raw mode), that may not always work.

The only way to really reset the camera is to cycle its power. With the camera powered by a RC PWM port, that doesn't happen.

Don & others,
We ran into this problem last year with our camera. We do not use any of the provided camera code as our camera is controlled by our custom circuit. This presents an interesting problem because whenever the "reset" button is pushed on the RC the camera seems to get reset as well (apparently power to the PWM ports is disrupted? It doesn't happen when the "RC Reset" button is pressed on the OI.) We use raw mode when communicating with the camera, and so anyway the bottom line is that when our custom circuit initially talks to the camera it can be in either normal or raw mode. Below is my camera_reset() routine which works effectively to reset the camera regardless of it's current state. We haven't had any trouble with it using this reset sequence. camera_send() and camera_recv() are just aliases for sending/reading from the serial port. camera_flush() just flushes the serial input buffer.

Anyway, just posting it in case it is helpful to someone...

CameraReturnType camera_reset(void)
{
    CameraReturnType ret_val = CAM_FAILURE;
    UINT8 buf;

    // Send the reset command to the camera.  If the camera is already in raw
    // mode, then this command should succeed.  If the camera is not in raw
    // mode, the camera will NCK this command.  If we try to send the normal
    // mode reset command first, and the camera is in raw mode, then it gets
    // stuck trying to read in 32 more bytes from us (because the space after
    // RS is decimal 32, which in raw mode indicates the number of arguments
    // that we're sending to the command).  Bottom line is that it needs to be
    // done this way for it to work reliably in either mode.
    camera_send("RS\0\r", 4);

    // Read in the first character of the response from the camera.
    camera_recv(&buf, 1);

    // Take appropriate action depending on whether the camera 'A'cked or
    // 'N'cked the command.
    if(buf == 'N')
    {
        // NCK received.  This likely means we are not in RAW mode, so
        // try a non-raw reset command.
        camera_send("RS\r", 3);

        camera_flush();

        ret_val = CAM_SUCCESS;
    }
    else if(buf == 'A')
    {
        // ACK received.  Camera should now be reset.  Nothing else to do.
        ret_val = CAM_SUCCESS;
    }

    // Flush the input buffer from any garbage that might be remaining.
    // When the CMUcam is reset, it outputs a version string, but also
    // sometimes truncates the previous ACK statement, so it's easiest
    // to just get rid of whatever is in the buffer before continuing.
    camera_flush();

    return ret_val;
}

[Mike Bortfeldt]

Like Dave, we have our own custom camera code. However, we use the raw mode only for the output from the camera (RM 1). This eliminates the need to determine what mode the camera is in before sending commands.

Mike

[Dave Flowerday]

Originally Posted by Mike Bortfeldt

Like Dave, we have our own custom camera code. However, we use the raw mode only for the output from the camera (RM 1). This eliminates the need to determine what mode the camera is in before sending commands.

How do you handle knowing which mode the camera is in when you power up? If the camera was previously initialized, it should be in raw mode, but if it just powered up as well, it'll be in normal mode.
{edit} Sorry, didn't read closely enough - I missed the part about "only for the output", so that obviously changes things. {/edit}