Fix for CMU cam initalization code 131 error.

[Alan T]

We had been fighting the Camera: Inititialized abnormally with code 131 error. Sometimes the camera would work perfectly. Then other times it would fail initialization. It was very inconsistant. Sometimes we would have to pull the backup battery and reset the RC to get it to initialize.

When I tried using the cmu cam on a VEX it happened everytime. I thought it was a hardware communication problem.

My theory is that sometimes the camera "misses" the commands sent during boot initialization. Possibly the camera processor is still initializing? I think the problem is worse on a vex because the getdata loop time is only 18ms on the vex vs 26ms on a FRC.

I added a bit of code in the camera initialization routine. If the initialization fails with error 131 it resets the boot initialization flag.

So far this has completely fixed the problem. The initialization will still fail the first time at state 3. The camera then initializes sucessfully at the next call to Initialize_Camera. It now works great on both the FRC and VEX controllers.

I added the below code to the end of the Initialize_Camera routine in Kevin's camera.c. It goes just before return(return_value);

 
 //Added 3/26/2006 AAT
 //If initialization fails after waiting for first ACK
 //in state 3, retry boot initialization.
 if(return_value == 131)
 {
  boot_initialization_flag = 1;
 }

alan

[Mark McLeod]

It looks like you found a good solution to your problem.
We've had success with a similar approach. We also look to handle any case where communication with the camera fails in addition to never happening in the first place.

http://www.chiefdelphi.com/forums/sh...88&postcount=9

I agree it looks like the specific problem you're seeing is probably because the PIC sends out commands before the camera has time to complete it's power-up sequence.
We also use a generic startup delay in our main loop of a few milliseconds, so the code doesn't attempt to do any sensor I/O or even pay attention to the regular OI communication packet until everything's had a chance to settle.

[Don Reid]

I thought of another approach. 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.

So why not power the camera through a relay (spike). That way it gets turned off when the RC resets (or when the code wants it to be). The code can then turn on the camera, wait a while, and know its state.

A single relay could be used to power a lot of other sensors (IR etc.) at the same time.

[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}

[BradAMiller]

Originally Posted by Mark McLeod

It looks like you found a good solution to your problem.
I agree it looks like the specific problem you're seeing is probably because the PIC sends out commands before the camera has time to complete it's power-up sequence.
We also use a generic startup delay in our main loop of a few milliseconds, so the code doesn't attempt to do any sensor I/O or even pay attention to the regular OI communication packet until everything's had a chance to settle.

I had the same problem with WPILib (which is used in EasyC). So WPILib won't send any camera commands until two seconds after power on. This isn't a serious problem since that's the time that the robot is sitting on the field before the match starts. Also, users can initialize everything else before starting the camera and that can often burn up the 2 seconds anyway, then it would start right away.

The library also receives in RAW mode, but always sends commands in ASCII. It didn't seem like a worthwhile optimization, since 99% of what the camera was doing was receiving T-packets, and those were received in binary. That way there was no ambiguity when interrupting the camera and sending commands to it.